During a recent penetration test at a client in the Toronto area, we were asked about “non-malware” attacks in the enterprise, and how to spot them. For those not familiar with “non-malware”, it is an attack that leverages existing software, trusted applications and permitted protocols to perform malicious activities. On top of that, these types of attacks can typically bypass Anti-virus checks as they are file-less and memory-based attacks that further complicate the job of security controls.
An example of this is the usage of PowerShell. Nearly every single malicious hacking activity imaginable can be executed using PowerShell in a Windows environment. Although this tool is the best friend of sysadmins and threat hunters alike, it will also allow malicious activities such as privileged escalation, lateral movement, credential theft, data exfiltration, establishment of persistence, data tampering, etc. To make things quite a bit worse, an attacker can inject the required .NET assemblies directly into Windows system memory, allowing PowerShell functionality even if the PowerShell executable (powershell.exe) has been removed or blocked throughout the network.
Another nasty example (as discussed recently by the Cisco threat intel team Talos) is a recent Brazilian banking trojan that exploited a fundamental flaw in many security products…the security trust chain. Basically, many endpoint security solutions assume that if the first executed binary in an application is a trusted one, then any subsequent libraries and dependencies that are called by the “trusted binary” must also be trusted.
In this case, a user clicks the wrong HTML link and a few re-directs later, a trusted VMWare PNG file gets used in the attack sequence which calls a malicious DLL (vmwarebase.DLL) that was able to inject more malicious code into explorer.exe which then allowed the trojan to kill various analyst processes like taskmgr.exe and establish autorun persistence, letting the trojan do its job of targeted web injects that were focused on people navigating their banking websites at specific Brazilian banks (yes…lot’s of complex steps to this one and this is the abbreviated version). Now, this attack STILL came in the usual way…a phishing email with an attachment….and it should have been filtered or the end user should know better than to click an HTML attachment, but that’s another story.
The main takeaway here is that, once an attacker has successfully penetrated your network, if you don’t continuously hunt for the things that are successfully evading your traditional security tools and monitoring solutions, you may be in for a nasty surprise.
These things CAN be detected, and as part of a thorough cyber-hygiene program, regularly scheduled threat hunting is the way to do it. Whether it is PowerShell script-blocks or latent binaries hiding in memory for months on end, a threat hunt is an excellent way to enhance a vulnerability assessment or penetration testing engagement. Augmenting a VA / Pen Test with a cyber threat hunt brings actual operational risk measurement to these necessary, but theoretical activities.
Hunt often, and start today.
