One common misconception I hear from IT security teams is that simulating a specific threat, say the Dridex Trojan, is more ‘real’ than simulating a proprietary (dubbed “Dummy”) version of the Trojan that mimics the underlying attack method that is so critical to that very Trojan’s success.
Simulating Cyber Attacks
Case in point, one strain of the Dridex Trojan was found to hide its code in a Microsoft spreadsheet.
To protect against that specific strain of Dridex, simulating the attack’s indicators of compromise (IoCs) would enable security teams to challenge and verify whether their preventive controls can catch that specific variant, including the organization’s email gateway, web proxy, firewall, AV, EDR, and other endpoint security controls.
But tomorrow, a new version of Dridex may be released, with new IoCs. How do you know if your security controls can detect it? Plus, the latest strain may feature even newer techniques and system exploitation methods, that make yesterday’s simulation irrelevant.
This is where simulating the underlying attack method becomes critical. Why? Because while you need preventive controls to catch a specific strain, (e.g. blacklists, FW, AV), your detective controls will ultimately determine if you can catch any strain that exhibits the same underlying attack method or technique.
Preventive controls rely on static IoCs, while detection controls rely on behavior-based tools, machine learning, and AI to identify malicious activity. They are the ones that will let you catch a fileless, zero-day attack, or a yet-unknown threat that has managed to infiltrate your company.
The Cyber Attack Techniques Method
Back to the Dridex Trojan. One strain found in the wild injects specific code into a macro within an excel spreadsheet. When the file is opened, it will run, and execute system exploitation code that is specific to that strain; for example, opening a PowerShell command line UI and connecting to a specific C&C server. While the IoC simulation will ensure that your preventive controls will block comms with that C2 server, they will not help in dealing with the strain’s modus operandi.
One option is to simulate arbitrary code execution launched by a spreadsheet macro—the same exploitation technique used by that strain. But the simulation would be unequivocally more effective if it simulated code execution launched by any macro in any Office suite file because that is the fundamental underlying attack method that can save your company from iterations of the same attack technique when performed by other threats, be they dridex or other Trojans or ransomware.
In fact, if I can launch a picture of a fairy, or a calculator, from a spreadsheet macro, chances are I’ll be able to inject anything I want into ANY Office file macro. And as 94% of attacks start from phishing emails, an employee that opens a malicious file attachment may well become someone’s ‘patient zero.’
In my pen-testing days, I didn’t even inject malicious code into attack simulations. Why? Because if a potential attacker has enough wiggle room to plant proprietary, arbitrary code into an Office macro, instead of a picture of a fairy, it could be a worm next time.
So, yes, there are specific IoCs and behaviors that the Dridex Trojan utilizes, and they keep evolving. That is why it is equally important to simulate the IoCs of a specific attack AS WELL AS the broader infiltration and exploitation techniques it uses to be successful in the first place.
Try to differentiate between a real attack and real attack methods.
Cymulate’s breach and attack simulation platform is the only solution that can do both. Each attack vector allows you to test the real attack methods AND the immediate threat assessment simulates real attacks.
Get started by testing the breach and attack simulation platform for yourself. Our free trial is 14-days, takes minutes to set up, and doesn’t require a credit card.