MALware FORensics SECurity: September 2022

As a big fan of “The Pyramid of Pain” and “Detection Maturity Levels” I have had good faith in building robust detection and upping my chances to detect adversary behavior in my networks.

The Pyramid of Pain does a great job in painting a clear picture on what to focus on to make sure my detection is relevant now and in the foreseeable future: TTPs.

Tactics, Techniques and Procedures, not Tools, Techniques and Procedure and not Tools, Tools and Pools either ;). Only thing I would like to change is that it should be named PTTs: Procedures, Techniques and Tactics to make sure that the stuff to detect, and what adversaries really would struggle to change, was Tactics. The Queen of TTPs and the saviour of our CERT, SOC and CSIRT teams.

The TTPs are explained in detail by Ryan Stillions in his Detection Maturity Level blog post and they are split up into their own DML levels. Procedures are level 4, Techniques are level 5 and Tactics are on level 6. (Note DML level 8 is Goals). So according to the DML model detecting on level 6 Tactics would be excellent.

The advanced DML model presented by Siri Bromander et al does add an upper level 9, Identity, to the DML model but that is not relevant for this rant, ehm blog post.

So this should be pretty easy then. Find tools that detect on DML level 6, even 5 could be acceptable in some cases, install, test , tune and head for the pub to get some beers and wait for the adversaries to get caught with their network operations. Straight forward right? Bummer. No tools detect on this level. The favorite for detection tools seem to be detecting other tools. Commandlines are very much looked for by detection tools in my experience. Detecting LOLbins seem to be a special favorite. LOLBINS and LOLBAS are great stuff, mainly for offensive purposes, but having the knowledge of them and alerting or at least logging when they are used might be very helpful in an IR setting. But there is a lot of them and writing good detection becomes extra hard as these binaries are used daily in our infrastructure and always being one ^ away from missing the execution of a ”YOLO commandline” makes for a lot of work in creating signatures and also tuning away false positive alerts from that kind of detection.

No tools readily available to fix my detection needs then, I am afraid. We need to look into building our own detection to reach nirvana at DML level 6 !

Best practice should be to look into which adversaries we should be most afraid of, or at least who we think is most likely to visit our networks, and start making sure we will catch them red handed if they as much as use one of their Tactics in our infrastructure. Lets say we do find which threat actors we need to be on the lookout for (probably some of them are in the ransomware business). So we pick up the best threat intel reports we can find and start looking for TTPs and in particular for Tactis. Lots of IOCs to find, hashes all over the place, even some malware names pop up(tools that is). Most common being Cobolt Strike Beacon maybe. A lot of reports confuse TTPs with IOCs, tools and other artifact that we are not willing to bet our lives on when creating detection. Almost all TI report do have a MITRE Att&ck reference table of some sorts today with at least Technique references.

That brings me over to my frustration with the MITRE Att&ck framework. Because MITRE Att&ck is another part in the detection pussle that confuses me, and it seem to be confusing a lot of others as well. The excellent speech by Martin Eian at this years FIRST conference in Dublin inspired me to write this post. MITRE Tactics are indeed goals not DML Tactics. We can not write detection for Tactics like “Defense Evation”, “Execution” and “Credential Access”.

MITRE Techniques, on the other hand, can be made into detection, at least some of them.

Lets look at a much used example: OS Credential dumping T.1003 is not good enough, but the sub technique T1003.0001 LSASS memory is a good candidate. I am not sure if this is a technique or a tactic according to the DML model. But to confuse me even more in the detection section things like “Monitor executed commands and arguments that may attempt to access credential material stored in the process memory of the Local Security Authority Subsystem Service (LSASS). Remote access tools may contain built-in features or incorporate existing tools like Mimikatz. PowerShell scripts also exist that contain credential dumping functionality, such as PowerSploit's Invoke-Mimikatz module”. Not so much help there either, Back to detecting Tools again.

To me it looks like we have this huge framework that help us detect the stuff that we really should not care too much about.

Do we as a community(IT Security/Sec analyst) lack the understanding of techniques and tactics? And does the MITRE Att&ck framework confuse us, the CSIRTs, SOCs and CERTs, in creating robust and reliable detection? Some has tried to say that Procedures is the correct level for detection: The TTP pyramid by Cristopher Peacock. I do not believe that this is the correct way to look at this problem. Maybe procedures are an OK detection level(4 that is). But ignoring Techniques and Tactics that should be even better, feels wrong.

Is the correct way to do this then to come up with our own Techniques and Tactics?

Massive job but probably doable. Especially since there, in theory, should be fewer detections to create at this level. They should also be relevant for longer. It would of course be much better if this was covered in a framework like MITRE Att&ck as it would be scrutinized by people much smarter than me. And also by more security analysts(detection engineers) than one organization can hire.

One other thing is that when we create our own detection based on our own tactics it is harder to test and verify that our detection work properly. Frameworks for that mainly adhere to MITRE Att&ck, so there will be a job mapping things if testing should be automated, but also more manual work in purple team situations.

Finding tactics from TI reports is no easy task. As they are kind of hidden in the language and not explicitly mentioned as detection opportunities or described by MITRE Att&ck.

Lets try a couple of examples:

TA007 using mimikatz to dump credentials from LSASS
The tactic might be “Get credentials from LSASS memory”. The goal here is credential access. This tactic is not directly detectable in it self. The closest we come, at least I get, is to detect reading LSASS process memory or if I want trying to read LSASS process memory. This can be achieved by detecting when a read operation is performed on on the LSASS object. Detecting when a handle to the sass object with read permissions is asked for will give us both successful and non successful tries to read the LSASS process memory. Detecting this will detect all TOOLS used for the purpose, any Procedure and all Techniques used while performing the LSASS dump. Not even Mohamed Salah can get that pass through to Roberto Firminio unseen :)

Event and Tracing Windows (ETW) logs can help us with this: EventCode 4656 - “A handle to an object was requested” will give info when an application wants to access LSASS and EventCode 4663 - “An attempt was made to access an object” will give us info on when access to LSASS actually was performed.
The threat actor utilized the “-r” option in PsExec to define a custom name (“mstdc”) of the remote service created on the target host (Thedfirreport)
I propose “Running service on remote host” as a tactic. This is a lateral movement goal. To be able to detect this tactic we need to look into service executions and figure out if a network logon was performed or what other methods is used to execute something remotely.

ETW logs will cover this one too with something like: EventCode 4697 - “A Service was installed on the system” and EventCode 4624 - “An account was successfully logged on”.

Are these really tactics and am I able to detect them correctly and reliably?

Am I not understanding the Pyramid of Pain, DML model, MITRE Att&ck and the detection challenges?

Too NOOB to figure out the right tools for the job?

Can we climb almost to the top of the DML model and reach level 6? Or is that not doable for us mere mortals? Is that for the ML and AI Gods only?

Please if you have a solution to my detection challenges let me know.

Also good detection material like the book by Andrei Miroshnikov: “Windows Security Monitoring: Scenarios and Patterns“ are really welcome.

Threat Hunters Playbookbook have done much right. Making things available as notebooks is a really good idea.

I like listening to the podcast “detection challenging paradigms” … Which makes for good input when pondering on detection challenges.

Hopefully Martin Eian will have a breakthrough with MITRE and save my day. In the mean time I will be making my own detection and trying to figure out the best way to test it reliably…

Happy ignoringing YOLO ^c^o^mandlin^e^s!!

References:

There is no TTP, by Martin Eian at The FIRST conference in Dublin

https://www.youtube.com/watch?v=KnFtekfyysA

Pyramid of pain by Davi Bianco

http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html

Detection Maturity Levels by Ryan Stillions

http://ryanstillions.blogspot.com/2014/04/the-dml-model_21.html

On TTPs by Ryan Stillions

http://ryanstillions.blogspot.com/2014/04/on-ttps.html

The TTP pyramid by Christopher Peacock

https://www.scythe.io/library/summiting-the-pyramid-of-pain-the-ttp-pyramid