The Real Story of What Goes On After Someone at Your Institution Falls for a Phish
In The Art of Phishing, I walked through how we build a phishing campaign: recon, psychology, lures, and the numbers. That was us playing attacker in a controlled test.
This is the real world. What happens when it isn’t us, and a real employee clicks a real malicious link? Because eventually someone does. Training lowers the odds, but it never gets them to zero. So the question that actually matters isn’t will someone click. It’s what happens in the minutes and hours after they do.
Most of the time, it starts with a simple message: “Someone clicked on a link, can you check it out?”
And every so often, it starts with something louder. I’ll show you a real example of that further down. Two of them, actually, anonymized but otherwise exactly as they happened.
The Report Is the Trigger
Here’s something people don’t expect: the vast majority of the phishing we look into doesn’t set off any alarm at all.
A credential page, the kind that just wants a username and password, doesn’t download anything, doesn’t execute anything, and doesn’t trip the endpoint. Technically, nothing “malicious” ever runs. The user just types into a convincing fake. There’s no siren, no automatic block, no flashing red light. From the machine’s point of view, nothing happened.
So how do we find out? Someone tells us. An employee thinks “that didn’t look right,” or realizes after the fact that they entered their password somewhere they shouldn’t have, and it gets reported to us: they clicked, please take a look. That report is the trigger for nearly everything we investigate.
Which is worth pausing on: the person who speaks up is doing something no tool on the market can do for you. This is why we push to make reporting fast and blameless. The employee who reports in two minutes hands us a head start. The one who’s too embarrassed to say anything hands the attacker time instead. A strong reporting culture isn’t a soft, feel-good thing. It’s a real layer of detection, and for pure credential phishing, it’s usually the only one that catches it.
We Look Into It
Once that report reaches us, our analysts pull up the workstation and reconstruct what actually happened, walking the timeline from just before the click through everything after.
We’re answering the questions the Client is about to ask:
- What did they click, and where did it take them? The URL, the page, the browser that opened it.
- Did anything run? We look for child processes that shouldn’t be there, like PowerShell, mshta, wscript, rundll32, or an unexpected command shell.
- Did anything land? New files in Downloads, Temp, or the browser cache.
- Did anything reach out? Outbound connections to anywhere it shouldn’t be talking to.
- Was it a credential page, and did they give something up? We work to determine whether a password was entered, whether it would actually work, and whether there’s any sign it’s been used since.
The tooling tells us where to look. It doesn’t tell us what it means, whether it’s truly over, or what to say to leadership. That part takes a person, and that’s the part we own.
The Occasional Loud One: Two Real Detections
A couple of times a year, a click doesn’t stay quiet. Instead of a harmless login page, the employee ends up downloading something that actually tries to run. We pulled two of these straight from our own monitoring, from two different community banks, months apart, and side by side, they’re plainly the same campaign.
(Details below are anonymized. The behavior is exactly as it happened.)
Both started the same, boring way: an employee followed a link from their browser expecting a legitimate login page. Instead of the real thing, each browser session ended with a file quietly dropping into the Downloads folder:
- At the first bank: a file we’ll call KitchenCanvas_[###].exe
- At the second, months later: FoodFormula_[###].exe
Bland, random, harmless-sounding names, and that’s on purpose. Both files were digitally signed by the same fictitious little “software company,” a shell that exists for no reason other than to make malware look legitimate enough to survive a casual glance. And both traced back through the browser to a page dressed up to look like a routine, trusted login. That’s exactly what makes these lures effective: they impersonate the everyday, and people click through the everyday on autopilot.
Here’s where the two cases split, and why the difference is the whole point.
Case one was already known. The moment that file hit the disk, our endpoint intelligence recognized it on sight as ransomware, a known-bad file it had seen before. Flagged immediately, caught before it could get anywhere. The easy kind.
Case two was sneakier, and far more instructive. This wasn’t a simple “clicked and downloaded.” It was a drive-by, a malicious web flow that quietly did the work for the user. The browser was steered to a throwaway “version check” site that fingerprinted the machine behind the scenes, then handed off to a delivery site that served up a dropper disguised as an ordinary app. No “are you sure you want to run this,” no obvious prompt. The file simply arrived in Downloads looking like harmless software, carrying that same fake digital signature.
From there it ran itself and went to work. The chain looked like this:
- The browser walked through a decoy “version check” domain, then hit a delivery site with a rapid burst of obfuscated requests. That’s the fingerprint-and-serve handoff.
- The disguised installer finished downloading and executed silently, with no user interaction.
- It dropped a second, hidden program into a temp folder and launched it.
- That program called out to attacker-controlled infrastructure for instructions and updates.
- It unpacked a bundled archive and installed a persistent, unwanted “browser” application deep in the user’s profile.
- It set itself up to stick around, adding a Start Menu shortcut and an uninstall registry entry, so it looked and behaved like software the user had installed on purpose.
- Then it cleaned up after itself, deleting the temporary files it used along the way to cover its tracks.
That’s not clumsy junk. That’s a multi-stage delivery chain built to fingerprint, evade, install, persist, and phone home. And to stay hidden while doing it, it leaned on the kind of evasion tradecraft you’d expect from serious malware: hijacking a legitimate program’s DLLs to run under its cover, hollowing out a running process to hide inside it, injecting code through the browser. That tradecraft is exactly what tripped our behavioral detection.
And here’s the part that matters most. That machine was in a detect-and-alert configuration, not auto-block. The tool raised its hand. It did not stop the chain. Stopping it was on us.
Our analysts caught the alert and pulled the whole sequence apart step by step: the decoy domain, the silent execution, the dropped payload, the outbound connections, the persistence entries, the self-cleanup. They confirmed it was genuinely malicious, removed the payload, tore out its persistence, and verified it hadn’t spread or left anything behind. No spread. No lasting foothold. No institution-wide incident. Just an alert, an analyst, and a quiet resolution the same day.
That second case is the entire argument for human monitoring in a single event. A tool in detect mode is only as valuable as the people watching what it flags. Left alone, that alert is just one more unread line in a console, and the story ends very differently.
What We Found (and Didn’t)
Across the cases we’ve worked, the ending is a quiet one, and that’s the goal:
- No credentials compromised. Where a user reported clicking, we confirmed nothing was harvested or misused.
- No successful compromise. Even on the genuinely dangerous downloads above, the endgame never landed. No ransomware, no data touched, no lasting foothold. Where a payload did install itself, our analysts tore it out and confirmed the machine was clean.
- No spread. Nothing moved to another machine or reached deeper into the institution.
- No surprise weeks later. Because we confirmed each one was closed the same day, not after the fact.
That outcome is the whole chain working together: a user who spoke up, a tool that flagged what it could, and a team that investigated instead of assuming. Take any one of those away, especially on that second detection, and the story gets a lot worse.
We Close the Loop
Even when it ends clean, a click is worth learning from. After one, we:
Tell the Client plainly what happened: what the employee clicked, what it tried to do, and how it was handled.
Give the employee a quiet, blameless heads-up. Not a scolding. A “this one got you, here’s the tell you missed.”
Check whether the same email or lure hit anyone else. One click usually means several people received it, and as those two detections show, the same campaign hits more than one institution.
Watch for repeats. If a lure, a site, or a signed-malware pattern keeps showing up, we get ahead of it across the staff and across our other clients.
What These Cases Teach Us
Most phishing is invisible to your tools. A credential page doesn’t run, download, or trip anything. If nobody reports it, nobody knows, which is why the report matters so much.
The person who speaks up is doing real security work. Their two-minute “hey, I clicked something” is the detection layer for the threats software can’t see.
Tools flag. People decide. Endpoint protection is great at killing a known-bad file on sight. But in detect mode, or against something brand new, it raises a hand and waits. Someone has to investigate the alert, confirm the environment is clean, and brief your board. That’s the human layer, and it’s not optional.
Signed doesn’t mean safe. Both of those malicious files carried a valid digital signature from a throwaway “company.” A signature is a claim, not a guarantee.
The best incidents are the boring ones. Nothing hit the board. Nobody’s day got ruined. That quiet is what good defense actually looks like.
What This Means for Your Institution
Make reporting effortless and blameless. It’s the layer that catches the phishing your tools never will. Reward the people who use it… loudly.
Have someone who investigates the alerts and the reports. A detection nobody reads is the same as no detection at all. The second case above is what that difference looks like in real life.
Know what mode your endpoint protection is in. Detect-and-alert is only as strong as the team behind it. If no one’s watching around the clock, “alert” just means “logged.”
Keep training, but treat it as one layer, not the whole plan. It reduces clicks. Something has to handle the ones that get through.
Wrapping Up
In the first article I said phishing is an art and defense is a discipline. This is the discipline in practice, and most of the time it doesn’t start with an alarm. It starts with an employee doing the right thing: “I clicked something, can you check it out?” And occasionally it starts with a signed file sliding into a Downloads folder, quietly trying to take an institution apart from the inside.
Both endings looked the same from the outside: nothing happened. That’s not luck. That’s a reporting culture, a tool doing its job, and a team ready to look, all working together so the story stays boring.
Think before you click, and report it when you do.
So, here’s the honest question to leave you with. If a signed file slipped into one of your employees’ Downloads folders today, would anyone catch it?
If you’re not sure, that’s exactly the gap we fill.
Don’t have EDR watching your endpoints at all? That’s the gap that turns a click like the ones above into a real incident. We can get modern endpoint detection and response onto your machines, with real analysts behind it, so an alert at 2 a.m. gets worked, not just logged.
Not sure how your people would hold up against a convincing lure? Let us run a phishing test built the way real attackers build them, and show you not just who clicked, but what we’d do next.
Either way, the time to find out is before the click, not after.
Contact us to talk about endpoint protection, a phishing test, or both, and let’s make sure your institution’s next click stays a boring one.
