Lateral Movement and Persistence: tactics vs techniques

Now that Mitre Att&ck is present pretty much in every single preso related to threat hunting & sales pitch of many vendors it is going to be pretty interesting to see what the future holds for it. I personally like the framework, and I believe in the benefits of its adoption. Despite all this I do remain skeptical (I did talk about its potential limitations in the past – some points I listed there no longer stand), but at the moment I don’t know any better way of structured approach for developing a foundation of any threat hunting program.

In this post I am not going to talk about the framework per se, or even threat hunting, or alert fatigue, but about… tactics.

Why?

We are so focused on techniques that we often forget to take a step back and look at the big picture. Yup, you are reading it right, we are going a bit ‘holistic’ here and the focus is the relationship between tactics and techniques 😉

The two tactics I mentioned in the title: lateral movement and persistence, draw my attention for two reasons:

  • I have extensively researched many persistence mechanisms on Windows and am pretty confident that there is at least 2, if not 5 times more of these than we know about
  • Lateral Movement is in my opinion heavily ‘under-researched’

The first point is easy. The second one – probably less.

I think there is a perception (and this may be just my biased opinion) that to run code on remote systems one has to use some sort of magic unicorn trick – known tricks include: remote service (psexec), WMI, DCOM, WSHRemote, phishing, drive-by/good old exploits, etc..

The truth is that with the proper creds and remote access to the file system/Registry the number of Lateral movement techniques becomes almost instantly a superset of all known unicorn tricks + many persistence techniques that are well-known and available (probably 100+ on Windows at the moment of writing). If you can modify Registry, a file (e.g. viral, or change the config), or add new file in a specific location then …. you can move laterally, except in some cases it will take a bit longer. For instance, one could add desktop shortcuts, .local files, .manifest files, phantom DLLs, plug-ins, etc., or modify one of many Registry keys and point to either remote (e.g. via UNC) or local (copied over) file.

Think of it: even temporarily swapping popular executables on a remote system may allow to execute code on that system when e.g. user opens that swapped popular program (office, conference applications, browsers, their less important plugins, etc.). Sky is the limit (okay, some limitations exist for systems that are not attended to by users, use EDR, whitelisting, and other factors, but it’s not the point – depending on the target you have the whole gamut of lateral movement/persistence techniques to use!).

I am obviously not the first one to spot the ‘persistence can create a lateral movement’ opportunity, but I don’t recall seeing any post that tries to look at this as a whole, and especially with regards to the Mitre framework. The described approach to leverage same techniques for different purpose is not new, but such a ‘bulk’ addition to the (currently) relatively small, ‘unicorn’ lateral movement tactic’ arsenal may significantly affect the way we look at tactics and techniques. They are not that atomic, independent, or limited to the scope that we are led to believe due to an error of availability (most presos talking about lateral movement completely ignore the persistence tricks providing possible lateral movement opportunities).

I think tactics as a leading force for the framework may end up being inadequate to represent clusters of techniques as this leads to many duplicate entries. Perhaps a way to approach it is to focus on techniques as a leading force of defense, and then label each technique with the available ‘tactic’ tags? I don’t know. It is one of the things that requires more people to come together and discuss…

Perhaps there is a Mitre Att&ck 2.0 in the making that will address that ‘bulk’ duplicity.

Update: coincidentally, after I posted this piece I saw this post (‘Draw.io for threat modeling’) on Twitter that describes a more detailed (and perhaps more traditional) threat modeling approach that I find pretty interesting in this context.

Beyond good ol’ Run key, Part 88

This is one more post to describe a case where I came across a Windows feature and then wanted to analyze how the whole thing works only to find out someone already did it before…

Windows Error Reporting allows the applications to register ‘custom runtime exception handler that is used to provide custom error reporting for crashes’ via WerRegisterRuntimeExceptionModule API.

In practice, the application needs to add a name of the DLL under this key:

  • HKLM\SOFTWARE\Microsoft\Windows\
    Windows Error Reporting\
    RuntimeExceptionHelperModules

and then call the WerRegisterRuntimeExceptionModule API.

When crash occurs the WER engine enumerates all the registered runtime exception handlers for the application and loads them via LoadLibrary and calls their functions exported allowing them to ‘claim’ this particular crash. It only loads the DLLs registered via WerRegisterRuntimeExceptionModule  though. This is a bit of a limitation, but one could discover the presences of such exception helper module and swap it so that next time the other application (the one that registered it) crashes, the swapped DLL will be loaded.

This allows to not only achieve a persistence (although not very reliable as it depends on a crash of some application), but also load the code into the space of WER process – most likely under the nose of many security applications/reversers. As such, it could be a potential sandbox/EDR evasion — register the DLL, call WerRegisterRuntimeExceptionModule, crash your app, the DLL will be loaded under WerFault.exe process. In another scenario one .exe could add the registry entry only, launch the second stage .exe and quit. The second stage would call WerRegisterRuntimeExceptionModule and crash. Both applications would do almost nothing while it’s the exception handler DLL that would do the main work under the Werfault.exe process.

You can see the full example here and an old article on the same topic.