We live in a time where it’s easier and easier to simulate all sorts of things. Computer-generated images, music, and even conversations are achieving ever-higher levels of fidelity, and the explosion of computing power over the last few decades means that scientists, soldiers, pilots, engineers, and all sorts of other practitioners have access to simulation tools of unprecedented fidelity and quality… and then there’s the IT world, where tabletop simulation is sometimes the best alternative to doing no testing at all. (Tabletop exercises are fascinating and I should write about them some other time!)
Wouldn’t it be great if we could benefit from better simulation when it comes to security? It turns out we can, but this capability comes with strings attached.
One way to reinforce learning is to put someone in a situation, observe their reaction, and then give them feedback. This primarily works if the subject has already learned whatever it is you’re testing, and isn’t necessarily a way to teach from first principles. It follows that if you want to test whether someone understands how to respond to a phishing message, you could try sending them fake messages and observing what they do, in fact, phishing simulations are a common tool used to test enterprise security.
The white-hat way to do this is to use a tool such as the attack simulation tools included in Microsoft 365 E5 or Defender for Office 365 P2. Microsoft refers to these simulated exercises as “benign cyberattacks,” and they provide a library of sample attacks comprising six different social engineering techniques and a variety of payloads. You can also create your own payloads, and both your and Microsoft’s payloads can be customized in different languages. The available message templates range from obvious to subtle, and, because you can target individual groups and then measure the response and click rates, you can run fairly sophisticated tests to see just who in your organization is the most gullible.
There are other similar tools, including suites from phished.io and ESET. Whichever tool you choose, you should carefully think through what you’re trying to learn and what behavior you’re trying to teach. For example, a few years ago a large publishing company ran an internal phishing test where the phishing email promised employees a large cash bonus—and they were decidedly not amused when they learned that the realistic-looking email was a fake created by the internal IT team.
Users are exposed to phishing messages as a matter of daily life (which itself is a sad commentary on the overall state of Internet security), so it’s worth asking yourself whether additional phishing tests are going to tell you anything you don’t already know about your users’ willingness to click on shady links.
The Microsoft 365 Kill Chain and Attack Path Management
An effective cybersecurity strategy requires a clear and comprehensive understanding of how attacks unfold. Read this whitepaper to get the expert insight you need to defend your organization!Learn More
Getting The Security Teams’ Attention
The conventional wisdom is that everyone’s afraid of ransomware and that every organization is frantically applying security measures of all types to protect against it. Based on the number of successful attacks highlighted in the press, and a lot of back-channel discussions, I’d have to say that this conventional wisdom isn’t entirely true. Some organizations are very afraid of ransomware and are taking multiple measures to reduce their risk… but some aren’t.
Security expert Tim MalcolmVetter (who, among other things, started the first red team at Walmart) has a solution: fake ransomware. His GitHub repository contains source code for a realistic-looking piece of fake malware that, when installed, puts up a scary-looking window but doesn’t actually hurt anything. However, the fake malware uses many of the same techniques that real ransomware does: it installs using an innocuous-looking Windows service, its binaries are obfuscated, and it attempts to evade detection. Its purpose is to give you a realistic way to test several parts of the kill chain that an attacker might exploit in your environment… and to make it super obvious when your efforts fail to stop the attack. For example, you could test putting the fake ransomware installer on USB keys and leave them lying around, or you could try to distribute them via phishing tools as described above, or you could drop the binaries but not execute them and see if anyone noticed unusual activities. Because MalcolmVetter includes the source code, you could customize the final product to leave specific signs whose presence you could test for—that is, you could simulate data exfiltration or lateral movement and see if your XDR or SIEM systems catch it. There are all sorts of ways to build a tool like this into your security testing if you’re brave enough.
Of course, it has to be said that just dropping ransomware-looking executables on your organizational network is not something to be done lightly. It’s a bit like live-fire training for military forces: a marvelous way to provide a very realistic experience, but one that carries a degree of danger that must be respected. The danger, of course, doesn’t come from the fake ransomware itself, it comes from the violation of organizational security rules and policies that you may be tempted to commit as part of your testing.
Let’s be Real
In general, I am strongly in favor of this kind of realistic testing, provided you clearly define what you’re testing for. Putting users through phishing simulations is useful if you want to better understand how your organization’s people behave, and thus to understand how you might better train them; ransomware simulations are useful if you want a high-visibility, low-risk way to test your detection and incident response capabilities. Whether these specific simulations, or others, are right for your environment is something you’ll have to decide on your own, but they’re certainly worth a good look.