Handling a Phishing Kit Full of Victim Credentials - and Two Inbound Requests
An analyst on your team monitors a Telegram channel used by a ransomware affiliate. She finds a posted archive containing a phishing kit: 3,200 sets of victim credentials (bank, email, and VPN logins, roughly 400 from your home country), the affiliate's own SSH private keys, and a C2 configuration. She downloads it on her corporate laptop, over the corporate VPN, using a Telegram account registered to her personal phone number and real name. Twenty minutes later a national law-enforcement officer emails the generic intel inbox asking for "everything you hold on this actor, including any materials you've obtained." A journalist has separately messaged the team's public account asking to confirm the actor's identity for a story. The archive is still in her Downloads folder.
1. What are your first-24-hour actions on OPSEC, evidence handling, and internal notification?
Read the worked answer
Treat this as both an OPSEC incident and an evidence-handling problem, and do not delete anything - deletion looks like spoliation and destroys value.
- Isolate and preserve. Stop using the corporate laptop for analysis. Copy the archive to an isolated, non-domain-joined analysis VM on a segmented network, compute hashes, and start a chain-of-custody log with timestamps and handler names. Then remove it from the corporate endpoint.
- Assume compromise of the analysis host. The kit may include a payload; check EDR for any execution, and rotate any credential that was present in the laptop's browser store or session.
- Assume the analyst is now identifiable. If the channel exposes download events or membership, a criminal group may hold her real name and phone number. Escalate to HR and physical security, discuss protective measures with her directly, and do not minimize it.
- Do not submit to public sandboxes or multi-scanner sites. Uploading the kit or C2 config can reveal your interest to the operator and burn the collection channel.
- Notify legal counsel and the privacy officer today, not after the analysis. You are now processing 3,200 sets of personal data, and the notification clocks in most regimes may already be relevant.
Also record the collection decision itself: downloading from an actor channel on a corporate asset with an attributable personal account is a policy failure, and the write-up should say so without turning it into a blame exercise against the analyst.
2. How do you handle the 3,200 victim credential sets and the affiliate's private keys?
Read the worked answer
Separate the two problems; they have different legal characters.
Victim credentials. These are personal data held without a clear lawful basis, and 400 belong to people in your jurisdiction. Handling: never authenticate with them, never test them, never load them into a tool that transmits them. Preserve as evidence, restrict access to a named list, and use a lawful notification channel - the national CERT, law enforcement, or the affected institutions' fraud teams - to get victims told. Produce intelligence about the kit's structure, capture method, and targeting without reproducing the credentials: counts, bank-name distribution, URL patterns. Redact before anything leaves the team. Log the disclosure.
The affiliate's SSH keys and C2 config. Tempting and dangerous. Do not use them to access the actor's infrastructure. Unauthorized access is a criminal offense in most jurisdictions, it would contaminate any future prosecution, and it would tell the operator exactly who is watching. Provide the keys to law enforcement through a documented process with a written request. If you want a technical understanding of the C2, analyze the configuration offline - protocol, endpoints, beacon shape - without connecting.
The general principle to state in the handling note: possession is not authorization, and intelligence value never converts an unlawful act into a lawful one. Where the temptation is highest - actor infrastructure you can reach - the correct move is to hand it to someone with legal process behind them and keep collecting defensively.
3. How do you respond to law enforcement and to the journalist, and what policy changes follow?
Read the worked answer
Law enforcement. Route the response through counsel. Acknowledge receipt, confirm your sharing policy, and ask for a written request naming the legal basis and scope. Do not promise the raw archive: it contains third-party personal data you may not be able to hand over without process. Offer what you can lawfully provide now - the intelligence product, hashes, timestamps, TTPs, and the channel description - and keep a disclosure log. Do not delay the victim-notification path while waiting for the request to be formalized; those are separate tracks.
Journalist. Do not confirm actor identity. You have not attributed the cluster, the Telegram handle is not proof, and public confirmation could endanger the analyst whose real name is now exposed. Offer a generic, on-record comment about the sector trend, and coordinate any further engagement with communications and legal.
Policy changes to propose within the week:
- A dedicated research identity and infrastructure: non-attributable account approved by legal, isolated VM, no corporate VPN, no personal phone number.
- A written collection SOP with a pre-approved handling path for victim data, so the next analyst does not improvise under pressure.
- A hard rule against downloading actor material to production endpoints.
- An explicit prohibition on interacting with or accessing actor infrastructure, with the LE hand-off route documented.
- A short tabletop exercise for the team on exactly this scenario, since the failure here was process, not judgement under uncertainty alone.