On the heels of my first post with this subject, I thought I'd continue adding tips as they came to mind...
I've been engaged with EDR frameworks for some time now. I first became aware of Carbon Black before it was "version 1.0", and before "carbonblack.com" existed. Since then, I've worked for several organizations that developed EDR frameworks (Secureworks, Nuix, CrowdStrike, Digital Guardian), and others that made use of frameworks created by others. I've also been very happy to see the development and growth of Sysmon, and used it in my own testing.
One thing I've been acutely aware of is the visibility afforded by EDR frameworks, as well as the extent of that visibility. This is not a knock against these tools...not at all. EDR frameworks and tools are incredibly powerful, but they are not a panacea. For example, most (I say "most" because I haven't seen all EDR tools) track process creation telemetry, but not process exit codes. As such, it can be detrimental to assume that because the EDR telemetry shows a process being created, that the process successfully executed and completed. Some EDR tools can block processes based on specific criteria...I saw a lot of this at CrowdStrike, and shared more than a few examples in public speaking events.
In other instances, the process may have failed to execute all together. For example, it may be been detected by AV shortly after it started executing. I've actually been caught by Windows Defender; prior to initiating testing, I'll disable real-time monitoring, but leave Defender untouched other than that. I'll then go about my testing, and then at some point in the future (sometimes around 4 hrs), I'll be continuing my testing, only to have Windows Defender recover (real-time monitoring is automatically re-enabled), and what I was working on was quarantined.
Did the executable throw an error shortly after launch, with a WER record, or an Application PopUp message, being generated in the Windows Event Log?
Were you able to validate the impact of the executable or command? For example, if the threat actor was seen running a command that would impact the Windows Registry and result in Windows Event Log records being generated, were those artifacts validated and observed on the system?
The overall point is that while EDR frameworks provide a tremendous amount of visibility, but they do not provide ALL visibility.
What's Old Is New Again
Something a bit more on the deeper forensicy-technical side...
I ran across a couple of things recently that reminded me that what I found fascinating and dug into deeply twenty years ago may not be that well known today. For example, last year, Windows Defender/MpCmdRun.exe was identified as an LOLBin, and that was accompanied by the fact that files could be written to alternate data streams (ADSs).
I also ran across something "new" regarding the "zone.identifier" ADSs associated with downloads (Edge, Chrome); specifically, the ZoneID ADSs are no longer 26 or 29 bytes in size, now they're much larger because they include more information, including HostURL and RefererURL entries, as illustrated in fig 1.
 |
| Fig 1: ZoneID ADS contents |
This clearly provides some useful information regarding the source of the file. The ADS illustrated in fig 1 is from a PDF document I'd downloaded to my desktop via Chrome; as such, it wasn't found in my Downloads folder (a dead giveaway for downloads...), but the existence and contents of the ADS clearly demonstrate that the file was indeed downloaded to the system.
Now, we'll just need to see if other means for downloading files...BITS jobs, LOLBins, etc...produce similar results.
No comments:
Post a Comment