You are browsing the archive for Compromise Detection.

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

August 18, 2018 in Anti-Forensics, Compromise Detection, Lateral Movement

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).

Reusigned Binaries – Living off the signed land, Part 3

August 4, 2018 in Anti-*, Anti-Forensics, Compromise Detection, Forensic Analysis, Living off the land, LOLBins, Reusigned Binaries

When I wrote two first parts of this series I used the title ‘reusigned binaries’. The title is of course very cheesy because it’s a portmanteau of ‘reuse’ and ‘signed’. How predictable…

Now… while in the meantime there was a lot going on in this space f.ex. the LOLBIN/LOLBAS ‘movement’ took off culminating in many cool Twitter posts and an excellent repo of LOLBin ideas and recipes collected by @Oddvarmoe, there is always… more.

Seasoned pentesters use reusigned binaries for a long time so it’s not a new concept.

The most obvious case scenarios are:

  • use native OS programs, and scripts that are signed and make them do something they are not supposed to (–> ‘traditional’ LOLBins helping to break detection rules focusing on process trees, offering various ways of side-loading, persistence, bypassing filters, etc.)
  • use popular, legitimate (and often signed) dual purpose tools and abuse them (e.g. nmap, netcat, psexec, etc.)
  • use common, legitimate non-OS software components (that are NOT dual purpose, and are very often signed) to do something they are not supposed to (–>LOLBins/Other sections e.g. NVidia’s nvuhda6.exe, PlugX abusing lots of legitimate apps for sideloading purposes; vulnerable /unpatched/ drivers that are signed, load beautifully and can be exploited, etc.)

The last item is very interesting. I believe this is potentially a part of the arsenal (and should be a subject of some serious research) of any futuristic offensive security team.

Let me give you an example…

While looking at a large corpora of driver installers (note: not drivers in a sense of kernel mode drivers, but more like drivers for peripherals like printer, scanner, etc.) I noticed the following

  • many of them reuse the same libraries/executables across many products of the same vendor
  • some of them do like using many modules that are often split across many files/libraries (atomic operations/library)
  • there are often no security checks in place – programmers write the modules in a context of their projects w/o thinking too much about security implications (why should they…, right?)
  • code is often ‘funny’ and includes debugging/verbose flags, test code, offensive, or anti-tampering code, etc. (if you need specific examples, just google ‘Conexant Keylogger’, ‘Sony rootkit’, ‘Denuvo protection’, etc.)
  • the code is SIGNED – let me repeat that!!!

So… when I first started thinking of this I did some poking around, combing through libraries and lots of code and I quickly found a number of signed DLL libraries that can be very easily abused to intercept keystrokes (i.e. build a foundation of a proper Keylogger!). Typically, one has to create a shared memory section named in a specific way, create a window receiving messages, sometimes create an event/mutex, sometimes prepare some structure in memory, call the API named something along the lines of ‘InstallHook’  and… a keylogger is born.

You know where it is heading…

I believe that further analysis of ‘clean’ software – no matter how popular as long as signed – will result in toolkits being developed that reduce the amount of ‘own’ offensive code and leveraging existing signed binaries to deliver the ‘bad’ part of the offensive work – one that modern blue teams try to find so much. Using signed binaries to do that is a really step forward as it may potentially fool many security products that so heavily rely on signing, reputation, whitelisting, and virustotaling. There is obviously a need to develop a binder code that makes it all work, but I guess this can be achieved either via VBS, VBA, mshta, msbuilder, powershell, c# snippets, or even instrumented execution of code that can be driven using signed binaries relying on scripts (e.g. windbg script, debugging via powershell, etc.). And of course, the opportunities of using unsigned plug-ins, documented and undocumented command line switches, etc.

It’s perhaps not a very practical post – I’ve been actually thinking a lot whether I should post a PoC of a keylogger based on one of the legitimate signed DLLs I found – but in the end I decided not to enter a dubious legal area I don’t have much experience with (I don’t’ want vendors to come after me, basically); still, I hope the post provides enough food for thought to carry on with your own experiments. All you need is a lot of clean signed samples (drivers, software), and some creative research ideas…