Category Archives: Lateral Movement

Lateral Movement and Persistence: tactics vs techniques

Posted on by

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.

Lateral Movement using WSHController/WSHRemote objects (IWSHController and IWSHRemote interfaces)

Posted on by

Re-discovering old tricks is fun, especially in a context of learning the very desirable know-how about all the possible evasion tricks and stealth techniques that should be well known to both red and blue teams. And especially tricks that allow lateral movement.

If you are wondering why I am saying ‘re-discovering’ it is because what I am going to cover in this post has been used in the past a lot, and googling around you can find references to code as early as 1989!

I came across it while reading about various Windows interfaces and these 2 caught my attention:

(or WSHController and WSHRemote as they are referred all over the place), and immediately realized that it’s yet another, not so well-known, lateral movement technique.

After few unsuccessful tries, I made it work and am presenting to you a quick & dirty recipe so you can try to replicate it in your lab.

This is the trick in action (left side – target system, right side – attacker):

You can re-use the code pasted on Microsoft site, and adapt it to your needs (a.k.a. edit the name of the remote computer and file name of the script):

strRemoteComputer = "RASServer01"
strWorkerScript = "MapNetworkDrive.vbs"
Set objWshController = WScript.CreateObject("WshController")
Set objRemoteScript = _
objWshController.CreateScript(strWorkerScript, strRemoteComputer)
objRemoteScript.Execute

Do While Not objRemoteScript.Status = 2
   Wscript.Sleep(100)
   Wscript.Echo "Remote script not yet complete."
Loop

When you try it for the first time, you will fail.

Why?

Lots of reasons. It turns out this feature needs a bit of preparation before it can be used.

After poking around and reading what other people did to make it work, I put these ideas together:

  • Use Admin account to execute the two actions described next (wscript doesn’t return an error if it can’t write Registry keys!)
  • Run the following command on both server and client (some sites suggest client only, but you do need to register it on the server too!)
    • wscript -regserver
  • Ensure that the client (target machine) has the following Registry setting enabled:
    • HKLM\SOFTWARE\Microsoft\Windows Script Host\
      Settings\Remote=1 (Reg_SZ)

That’s it. Now the script should work.

If you are worrying that running the ‘wscript -regserver’ puts this trick in a catch 22 department (we need to run one process remotely first to run our script) don’t worry. The ‘wscript -regserver’ adds a bunch of Registry keys, and values – they can be as well added using remote Registry functions and this doesn’t require running processes remotely at all!

Here’s a high-level list of these keys – if you want detailed values you can grab them from a regshot session on your test lab box:

  • HKLM\SOFTWARE\Classes\CLSID\{6F201542-B482-11D2-A250-00104BD35090}
  • HKLM\SOFTWARE\Classes\Interface\{6F201541-B482-11D2-A250-00104BD35090}
  • HKLM\SOFTWARE\Classes\Interface\{83EA33C0-CD14-11D2-A252-00104BD35090}
  • HKLM\SOFTWARE\Classes\Interface\{8A9EA2C0-D348-11D2-A253-00104BD35090}
  • HKLM\SOFTWARE\Classes\TypeLib\{6F201540-B482-11D2-A250-00104BD35090}
  • HKLM\SOFTWARE\Classes\WSHRemote

From a forensic perspective you will want to pay attention to these artifacts:

  • Registry artifacts described above (Remote value + Classes entries)
  • Files created in a user temporary directory – if launched on the localhost
    • %TEMP%\wsh*.tmp
    • %TEMP%\wsh*.tmp.vbs
  • Files created in a Windows temporary directory of the target system (if launched on the remote host)
    • C:\Windows\Temp\wsh*.tmp
    • C:\Windows\Temp\wsh*.tmp.vbs
  • Presence of a process wscript.exe spawn via svchost.exe:
    • C:\WINDOWS\system32\wscript.exe -Embedding

In terms of Event Logs, the only activity I see is a number of Events logged in the Security logs:

  • 4672: Special privileges assigned to new logon.
  • 4624: An account was successfully logged on.
  • 4634: An account was logged off.

So, seeing this triplet in a short time span may be a good indicator of ongoing lateral movement using this technique.

There is also another bit. Since you can use this trick on the localhost it could be used to break the process tree (as seen by e.g. EDR solutions), and potentially evade some sandbox analysis (processes not spawn directly by the analyzed sample(s) or their child processes may be sometimes ignored unless the sandbox is aware of the evasion trick and monitors its use).