Threat-based testing: rehearsing the attack your real adversary would run
A standard security test checks systems against a general list of known weaknesses. Real attackers follow their own habits and tools, and a bank that passes the general test can still be open to them. A commercial bank asked us to find out how it would fare against the specific ransomware group that appeared to be watching it.
INTEL
Sector TTPs
SCENARIO
ATT&CK chain
TEST
Emulate & validate
A bank on a ransomware group’s radar
The bank had recently been mentioned in chatter on a ransomware leak site, where criminal groups advertise their targets, in connection with attacks on Southeast Asian finance. Its existing vulnerability assessment said systems were patched and in good order. The board was not reassured, and asked a direct question: “Could they get in?”
Planning the test around the attacker
Instead of a generic checklist, we built the test around what this kind of group actually does. Security teams call this its TTPs: the tactics, techniques and procedures an attacker habitually uses, catalogued in a public framework called MITRE ATT&CK. We covered each stage of an attack relevant to a bank, from getting in and staying hidden to stealing data and causing damage.
- We profiled the crews targeting the finance sector, the brokers who sell access to company networks, and recent incidents in Indonesia. From that we shortlisted the techniques to test, including phishing, VPN exploits, misuse of built-in Windows tools, attacks on the company directory (Active Directory) and data theft disguised as normal web traffic.
- We ran four scenarios, each starting a different way: through phishing, a VPN weakness, a vendor, or an insider. Each was scoped, authorized and watched together with the bank’s security operations center (SOC), with the option of running it as a joint purple-team exercise.
- For every technique we recorded whether the bank’s defenses blocked it, raised an alert, or missed it entirely.
- The output was a set of threat-informed test cases and a map of detection gaps against MITRE ATT&CK.
How far the emulated attackers got
The phishing scenario reached domain admin, meaning full control of the bank’s internal network, in 26 hours. It began with a shortcut file sent as a Teams message, which slipped past email and file filtering. From there our testers evaded the Windows malware scanning interface, collected staff credentials, and abused a directory setting called unconstrained delegation to take over the domain. The SOC missed 7 of the 11 steps along the way.
The VPN scenario showed that patching alone had not closed the door. The VPN itself was up to date, but an old, still-exposed network relay service leaked the same directory credentials through a technique known as NTLM relay.
On average it took the SOC nine hours to detect an attack step. Two of the persistence mechanisms our testers planted (footholds that let an attacker return) survived the bank’s own “clean-up” reboot drill.
What the bank changed
The bank tightened its endpoint protection policy and mail gateway, and hardened its directory. It removed unsafe delegation settings, gave every machine a unique local admin password, and separated admin accounts into tiers. When we re-ran the same attack, it was stopped early in the chain and the SOC raised an alert. We also delivered detection rules and response runbooks for the seven techniques that had been missed. The board’s risk committee joined a tabletop exercise, a guided walk-through of how the organization would respond to a real attack. The test plan is now refreshed every quarter from an updated threat profile.
Organizations that know which group is likely to come after them have a real advantage, because they can rehearse against that group’s playbook before it arrives.