Dell SecureWorks, one of our MSSP partners, recently released details of an interesting piece of malware they call “Stegoloader.”
What’s interesting is that this modular malware downloads its main module as a PNG graphic with the code hidden inside, and that the various pieces attempt to evade debugging and reverse engineering attempts.
So why are we talking about this now? Well, for two reasons.
- You don’t know what “bad” will look like. Is “bad” a really nasty binary with lots of calls to various API functions that grab credentials, take photos with the webcam, and exfiltrate data? Is “bad” a PowerShell Script? Is “bad” PsExec, a valid, signed binary that is being used maliciously? Is “bad” a user logging into a system and typing commands into a cmd.exe shell?Since “bad” can take so many forms, you need to record events and the relationships between them and look for things that shouldn’t be happening. Find the anomalies. Hunt the suspicious and malicious behavior. Remember, you don’t know what every malicious attack will look like.Further, because you’re recording, you can have an internal cyber “black box” like an airplane. When a plane goes down, recovery efforts can span months of scouring to recover the valuable black box of flight and instrumentation data. Can you rewind the tape and see what the root cause of your incident was, and then see everything that it did? Are you learning about TTPs, are you capturing binaries and other events before the malware or malicious attacker cleans up? I hope so.
- You can’t solely rely on binaries. Sure, static analysis and dynamic (detonation) analysis of binaries either entering your environment or attempting to execute is going to help find some bad stuff. However, there will be plenty of things that use techniques such as steganography, encryption, and other evasive techniques that are really hard to analyze in an artificial sandbox or by doing it statically without seeing what it actually does. And, again, as mentioned above, what if the tools used are valid tools but are being used in a malicious manner? What are you doing about it?By default-denying all binaries, modules and scripts from executing that are not trusted in your policies you will reduce the number of times you go through the incident management lifecycle. And because you will inevitably still go through it, you should record what is going on so that you can triage quickly, remediate with confidence, and learn from that recorded history to appropriate update prevention policies and detection rules.