A Click-Response Checklist for a Phishing Report

You want the machine off the network and still running. Pull the network cable or disable the Wi-Fi adapter. Do not shut it down, do not run a "clean up" tool, and do not let the user keep working on it. Memory holds running processes, injected code, and the contents of the browser session, and all of that disappears on a clean shutdown. If you have endpoint detection and response tooling, use its network isolation feature instead of physically pulling the cable, because it keeps the agent reporting while cutting connectivity.

Two cautions on that approach. First, some isolation features block the management channel too, so confirm the endpoint can still check in before you rely on it. Second, if the user has already closed the browser, do not reopen the phishing page to "see what it was". You will fetch the page again from your own network, and you will lose the cached copy.

If the click happened on a personal phone or a home machine, you cannot isolate it, and you should not try. Instead, treat every account that device can reach as exposed and move directly to the credential steps below.

Here is the sequence, in order, with the reason attached to each step:

Step one deserves emphasis. Getting the full message with its headers lets you see what the authentication checks said. SPF checks the envelope sender, DKIM checks a cryptographic signature, and DMARC is what ties those results back to the visible From address and tells the receiving server what to do with a failure as described by Cloudflare. A DMARC failure on an inbound message that still reached the inbox is a filtering gap worth fixing, and it tells you the lure was likely spoofed rather than sent from a compromised partner account. The header block shows the results; most clients expose it under "Show original" or "Show details" per Cloudflare's walkthrough.

Pull these four queries and save the output. You are not reading everything, you are looking for the answer to one question: did anyone use this account after the click?

Mail logs. Search for the sender address and the subject line across all mailboxes. This gives you the full recipient list, which is your real scope. Search for outbound messages from the clicked user's mailbox after the click time, because a compromised mailbox is often used to send the next round of phishing to colleagues and contacts. Internal phishing delivered from a real internal account is much harder for a filter to catch, and the FBI's description of business email compromise notes that attackers often use a compromised mailbox to move to other accounts and to time requests convincingly on the FBI business email compromise page.

Sign-in and identity logs. Look for successful authentications for the clicked account from a location your organization has never used, from a new device, or from a hosting provider rather than a residential or mobile network. Check the time against the click time, because the gap is diagnostic: a login two minutes after the click from an unfamiliar address is a replay of harvested credentials, while a login the following morning from a nearby city is more likely the user on a different network. Also look for new MFA device registrations, new mail rules, new forwarding addresses, and new OAuth application consents. A password change does not remove any of those, which is why you should check them before you declare the account clean.

Proxy and DNS logs. Search for the domain in the link. You want to know which devices on your network resolved or requested it, not just the one that reported. A phishing campaign that hits a shared inbox usually hits several people, and the first reporter is rarely the only clicker. A blocking DNS service turns this step into a quick check and prevents later clicks at the same time; protective DNS is one of the technical mitigations the joint guidance recommends in the CISA phishing guidance. The NSA's release summary lists phishing-resistant MFA, link and attachment filtering, protective DNS, application allow-lists and remote browser isolation among the controls it recommends in the NSA release. One sentence on this for a small team: if you can only afford one, buy the DNS filtering, because it catches the second click for you.

Endpoint telemetry. Search for the browser process on the affected host, then for child processes spawned from it. You are looking for an installer, a script interpreter, or a background process that started within a few minutes of the click. If your endpoint tool records file writes, search for files written to the downloads folder or to temporary directories in that window. If the click only opened a credential-harvesting page, you will usually find nothing here, and that null result is itself worth writing down.

A worked example makes the timing concrete. Suppose the user reports at 09:40 that they clicked at 09:12. Identity logs show a successful sign-in for the account at 09:14 from an address in a country your company has no presence in, followed by a new inbox rule that moves messages containing the word "invoice" into an archive folder. That is a confirmed compromise. The mailbox was read for roughly 26 minutes before anyone noticed, outbound mail from the account must be treated as attacker-authored, and the scope is every external party who emailed that user in that window. Contrast that with a report at 09:40 for a click at 09:35, no unfamiliar sign-in, no new rules, and the proxy log showing the link was blocked before the page rendered. That is a near miss, and it closes with a password reset and a filter update.

The instinct is to reset everything. Resist it for a moment and reset in this order, because the order reflects who else is exposed by each account.

1. The clicked account, plus session revocation. Reset the password and revoke all active sessions and refresh tokens, not just the password. A stolen session token outlives a password change, and a reset that leaves sessions alive leaves the attacker inside. This is the step people skip.
2. The email account that receives password resets for everything else. If the clicked account is not the primary email account, the primary one is now the most valuable target in the organization, because it can reset everything else.
3. Every password saved in that browser profile. Export the saved password list from the browser before you wipe it, and reset each account. A harvested credential plus a saved password list is a complete inventory of the user's working life. Prioritize anything holding money or customer data: banking, payroll, payment processors, the CRM, the cloud admin console.
4. Any account where the same password was reused. This is a search problem, not a judgment problem. Ask the user, check your password manager's audit report if you have one, and reset every match. The IC3 prevention guidance is blunt about this: use a unique password for every service and change them periodically per the IC3 business email compromise advisory.
5. Shared and service accounts the user can reach. These are the ones nobody owns, which makes them the ones an attacker keeps.

Then fix the second factor. If the account uses push notifications without number matching, an attacker with a valid password can send approval prompts until someone taps accept out of fatigue. The joint guidance names push MFA without number matching, SMS and voice codes, and MFA that lacks FIDO or certificate-based authentication as the weak implementations that credential phishing still defeats per the CISA phishing guidance. For the clicked user, move to a phishing-resistant method now, while the incident has everyone's attention. That one change is the highest-value hour of work in the whole response.

You will not get certainty in the first hour, and you should not pretend to. You get a confidence level and the evidence behind it. Use three tiers and say which one you are in.

Confirmed compromise. There is a successful sign-in you cannot attribute to the user, or a new mail rule, forwarding address, MFA device, or OAuth consent you did not create. In this tier, assume the mailbox was read. Pull the mailbox audit log for the window, list every message accessed or exported, and identify the external parties in that thread. Move to containment on money: tell finance and accounts payable that any payment instruction from that person needs verbal confirmation on a number you already have, not a number in an email. The FBI's own advice on payment requests is to verify in person or by calling the person directly and never to rely on email alone per the FBI business email compromise guidance, and the IC3 stresses that time is critical if a fraudulent transfer has gone out per the IC3 advisory.

Probable credential exposure, no evidence of use. The user typed credentials into the page but logs show no unfamiliar sign-in, and you have checked mailbox rules, forwarding, MFA registrations and consents. Treat as contained after the password reset and session revocation, and keep the account under review for a defined period. Attackers frequently wait, and a clean first hour does not mean a clean week.

Click only. The link was blocked, or the page loaded and nothing was entered, and there is no download and no unusual process. Document it, remove the message, and close.

One more check belongs in every tier: did the page ask for anything other than credentials? A fake invoice portal that collects a card number, or a fake document-sharing page that asks for a one-time code to "view the file", is a different loss with different reporting duties. The FBI's spoofing and phishing guidance describes exactly this shape of attack, where a link leads to a lookalike site asking for passwords, card numbers or banking PINs per the FBI spoofing and phishing page. If financial details were entered, your obligations run to your bank and possibly to regulators, not just to your IT team.

This is the part to tape inside a cabinet door. It assumes one reporter, one responder, and no dedicated security team.

• 0:00 Reporter calls the named contact. Capture time of click, what was typed, what was downloaded, whether a code or push was approved.
• 0:05 Save the message as a file. Note the sender, subject, link domain and the SPF, DKIM and DMARC results from the headers.
• 0:10 Isolate the machine from the network. Leave it powered on. Tell the user to stop using it and not to touch the browser.
• 0:15 Search all mailboxes for the sender and subject. Purge the message. Note every recipient.
• 0:25 Query identity logs for the account: unfamiliar locations, new devices, new MFA registrations, new mail rules, forwarding, OAuth consents.
• 0:30 Query proxy and DNS logs for the link domain across all devices.
• 0:40 Reset the clicked account's password and revoke all sessions. Then reset saved browser passwords and any reused passwords, money and customer data first.
• 0:50 Decide the tier: confirmed compromise, probable exposure, or click only. Write one paragraph and name the evidence.
• 0:55 If the tier is confirmed compromise, notify finance and any external party in the exposed threads. Change the account's MFA method to a phishing-resistant one.
• 1:00 Open a timeline document with timestamps for every action. Keep the saved message file and the log exports with it.

Two additions make the checklist survive contact with a real week. First, test the queries before you need them: run the identity log search for a colleague's account on a normal day so you know what a clean result looks like. Second, check your log retention. If identity logs roll off in a window shorter than your slowest possible report, the investigation has a hard ceiling, and that is a finding for your next planning conversation.

If the response raises questions your team cannot answer alone, a structured review of your identity and mail configuration is the natural next step, and a free discovery call is a reasonable way to scope it: Quanta Consulting.