Sliver - Part 3 - Detecting an Attack Chain

Using native Windows logs and Sysmon to detect an Attack Chain

Sliver Attack Chain

Following on from Part 2 we will now dissect a number of valuable detections that can be implemented in any SIEM product using native Windows logs as well as some Sysmon logs. For Windows logging there may be a requirement to adjust your Group Policy to actually turn on some of the logs seen in this article. It is still disappointing that some of the most valuable logs in Windows are not turn on by default.

For deploying Sysmon there are some very good articles and a number of configuration options. We have used a combination of 2 Sysmon config files and they are linked at the end of this article.

For detections we will examine in this article we will choose the following phases of the attack. Not all of these can actually be detected through logs and we will explain why;

  • Establish Session - This is us executing the beacon and for Sliver this produces limited logs. We do not currently attempt to detect, via Windows logs, the execution of a Sliver beacon.
  • Initial User and Domain Recon - We did not attempt to mimic the initial access vector for this test. We simply dropped our Sliver beacon to disk and executed as a low privileged user.
  • Local Admin Escalation - For this particular UAC bypass there are very distinct log artefacts produced that we can get high quality detections built for.
  • Domain Escalation - Kerberoasting is very common to see as an escalation technique as it is available to attempt in the vast majority of Windows Domain environments.

Detection Advice

Across all of this testing our SOC has learnt some valuable lessons about building detections and hopefully the below advice will help. Even still there are exceptions to all of the guidance below.

  • Don’t rely on a single test to create your detection - When testing don’t assume that just because you’ve detected something with a single test that you have everything covered. A great example of this is Regular Expressions that are too precise. There is a big difference between a log containing whoami.exe or whoami (Both of which will work in Windows as shown on the right) if your regex is crafted to require the extension such as whoami\.exe. This works both ways where a precise regex may be needed to filter out false positives or a more generic regex is needed to capture different ways of executing the same thing.

  • Don’t rely on a single log field just because it looks unique - So many times I have put together a top shelf detection only for it to fire 1000’s of times in the first minutes after being deployed into a production environment. Usually it’s due to relying on what looks to be a unique value in a field that is actually extremely common outside of our research environment. The named pipe example below in the Establish Sessions Detection is a great example of an “almost-detection”.

  • Search around the obvious logs for other related logs - This one can help get a detection from false positive prone to very accurate. For example when a process is spawned always search for any DLL load events, registry changes or Process Access events in Sysmon as these may also have unique and detectable characteristics. Pivoting around the user Session can be invaluable within Domain logs and will often allow you to directly relate two logs which do not immediately appear related.On the right are all the different Sysmon log types created when we execute a default HTTP Sliver beacon.

  • Where possible test every rule in both test and production environments - This one is pretty simple but we always test every rule we can in both our research environment and then all production environments where it is deployed. This will uncover any logging irregularities or missing logs which we can fix before they become a larger issue.

Establish Session Detection

Initial access and execution of a beacon can occur in variety of ways, for the sake of simplicity we have taken a default HTTP Sliver beacon and run this as a non-admin user to establish the initial foothold. As we can see in the process creation event from Sysmon there are very few distinguishing features to be able to base a detection on.

  • Metadata - There is very little default metadata included in the Sliver binary. Not that this is always available but every so often we may get really specific information such as the authors name (Mimikatz) or the original filename.
  • File Hash - The hash for each binary we create will be different, it will be a good value for later investigation but for initial detection it is unlikely to be possible.
  • Current Directory - Some generic rules for execution from Downloads or Outlook folders may catch this activity but there is nothing specific for Sliver to detect here.

Below shows all of the logs that are related to the initial execution of PERFECT_ACCOMPANIST.exe (Sliver HTTP beacon binary). In total there are twelve logs generated by Sysmon and native Windows logging. The two that stand out are the references for notepad.exe and the named pipe event for \wkssvc.

The named pipe is a good example of something that appears unique and would be suitable for a detection. However when we dig into this we find that named pipes with \wksscv as their name are an almost constant occurrence within even an environment with little to no activity.

We can see on the right that there were ~34,000 named pipe events where the pipe name is \wksscv which wouldn’t be feasible to detect on. However, the process which creates the named pipe is also part of the log. This is something we could consider for detections or finetunes to get only the named pipe events we want.

Unfortunately as we can see there is a huge variety of processes that utilise this particular named pipe. Adding 10’s or 100’s of finetunes to a rule such as this is not ideal and we begin to play a long-term game of chicken.

Below are some repositories with code for testing Named Pipes:

win32-named-pipes-example

https://github.com/peter-bloomfield/win32-named-pipes-example
Simple example code for working with named pipes in C++ using the Win32 API.

named-pipes-examples

https://github.com/sovprene/named-pipe-examples

Initial User and Domain Recon

Now we can move onto some items that are easier to generate logs and get detections applied to our Windows log sources.

We’ll start with a favourite of mine where we detect the use of whoami by any user as this will often give attackers a great idea of group membership and initial privilege escalation that can be achieved.

The standard whoami will only return the username and so often we’ll see the /all or the /priv flags used to get specific information. This is especially abnormal for a normal user running in a non-admin context. This non-admin context is denoted by the 'IntegrityLevel' = Medium in the log below.

Raw Log

<System>
 <Provider Name='Microsoft-Windows-Sysmon'/>
 <EventID>1</EventID>
 <Version>5</Version>
 <Level>Information</Level>
 <Task>Process Create (rule: ProcessCreate)</Task>
 <Opcode>Info</Opcode>
 <Keywords></Keywords>
 <TimeCreated SystemTime='2023-01-17T07:13:29.799805100Z'/>
 <EventRecordID>6949806</EventRecordID>
 <Correlation/>
 <Execution ProcessID='1984' ThreadID='2120'/>
 <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
 <Computer>sv011-test.corp1.local</Computer>
 <Security UserID='NT AUTHORITY\SYSTEM'/>
</System>
<EventData>
 <Data Name='RuleName'>-</Data>
 <Data Name='UtcTime'>2023-01-17 07:13:29.798</Data>
 <Data Name='ProcessGuid'>{f3183221-4a99-63c6-53e5-4b5b02000000}</Data>
 <Data Name='ProcessId'>6704</Data>
 <Data Name='Image'>C:\Windows\System32\whoami.exe</Data>
 <Data Name='FileVersion'>10.0.14393.0 (rs1_release.160715-1616)</Data>
 <Data Name='Description'>whoami - displays logged on user information</Data>
 <Data Name='Product'>Microsoft® Windows® Operating System</Data>
 <Data Name='Company'>Microsoft Corporation</Data>
 <Data Name='OriginalFileName'>whoami.exe</Data>
 <Data Name='CommandLine'>whoami /all</Data>
 <Data Name='CurrentDirectory'>c:\Attack Tools\</Data>
 <Data Name='User'>CORP1\tboss</Data>
 <Data Name='LogonGuid'>{f3183221-8cf4-63b7-9dac-4f0000000000}</Data>
 <Data Name='LogonId'>0x4fac9d</Data>
 <Data Name='TerminalSessionId'>2</Data>
 <Data Name='IntegrityLevel'>Medium</Data>
 <Data Name='Hashes'>MD5=AA1E17EA3DB5CD9D8BC061CAEC74C6E8</Data>
 <Data Name='ParentProcessGuid'>{f3183221-455f-63c6-79ad-405a02000000}</Data>
 <Data Name='ParentProcessId'>5336</Data>
 <Data Name='ParentImage'>C:\Attack Tools\PERFECT_ACCOMPANIST.exe</Data>
 <Data Name='ParentCommandLine'>PERFECT_ACCOMPANIST.exe</Data>
</EventData>

Detection Logic

This is a low-risk detection that we can apply to all Windows Security and Sysmon logs. It will give a fair amount of false positives for admin users but very few for normal users. Knowledge of all the different flags and what they return is essential for an analyst to understand. We can also use this to feed into other rules linked to the same user such as discovery activities related to both systems and the network. 

Log Source:
Windows Security OR Sysmon
Event ID:
4688 OR 1
CommandLine:
CONTAINS REGEX whoami.*\/
To split the rule into Admin and Normal User versions add one of the below to each rule. 
Mandtory Label:
Admin - High
Normal User - Medium

Attacker Use

As can be seen in the evaluation of a number of DFIR reports the whoami command is not used a large number of times (Length of the bar in the graph) but it is seen being used in the large number of reports (The individual colours in the bar graph)

The DFIR Report

https://thedfirreport.com/
Real Intrusions by Real Attackers, The Truth Behind the Intrusion

Local Admin Escalation

Since we know that the user account we have temporary use over is part of the local admins group all we need to get a high privileged session is get past User Account Control (UAC).

There are still a number of UAC bypasses and for this one we will use a variant that abuses Connection Manager Profile Installer (CMSTP). Once successful we will get another session calling back to Sliver which will have a High mandatory label, this indicates local admin level access and opens up the ability for further escalations locally.

There are two separate detections which are closely linked;

  • Server - Suspicious Commands – CMSTP - Detects the use of Microsoft Connection Manager Profiler Installer (CMSTP) which may be used to bypass AppLocker due to it being a signed Microsoft application.
  • Attack - Possible UAC Bypass – cmstplua - Detects a possible UAC bypass based on abusing the CMSTPLUA COM interface.

Raw Log - CMSTP Execution

<System>
	<Provider Name='Microsoft-Windows-Sysmon' Guid='{5770385f-c22a-43e0-bf4c-06f5698ffbd9}'/>
	<EventID>1</EventID>
	<Version>5</Version>
	<Level>Information</Level>
	<Task>Process Create (rule: ProcessCreate)</Task>
	<Opcode>Info</Opcode>
	<Keywords></Keywords>
	<TimeCreated SystemTime='2023-01-18T08:35:46.801470200Z'/>
	<EventRecordID>6964964</EventRecordID>
	<Correlation/>
	<Execution ProcessID='1984' ThreadID='2120'/>
	<Channel>Microsoft-Windows-Sysmon/Operational</Channel>
	<Computer>sv011-test.corp1.local</Computer>
	<Security UserID='NT AUTHORITY\SYSTEM'/>
</System>
<EventData>
	<Data Name='RuleName'>-</Data>
	<Data Name='UtcTime'>2023-01-18 08:35:46.795</Data>
	<Data Name='ProcessGuid'>{f3183221-af62-63c7-72c3-c49a02000000}</Data>
	<Data Name='ProcessId'>7744</Data>
	<Data Name='Image'>C:\Windows\System32\cmstp.exe</Data>
	<Data Name='FileVersion'>7.2.14393.0 (rs1_release.160715-1616)</Data>
	<Data Name='Description'>Microsoft Connection Manager Profile Installer</Data>
	<Data Name='Product'>Microsoft(R) Connection Manager</Data>
	<Data Name='Company'>Microsoft Corporation</Data>
	<Data Name='OriginalFileName'>CMSTP.EXE</Data>
	<Data Name='CommandLine'>"c:\windows\system32\cmstp.exe" /au C:\windows\temp\h5yaimw5.inf</Data>
	<Data Name='CurrentDirectory'>c:\Attack Tools\</Data>
	<Data Name='User'>CORP1\tboss</Data>
	<Data Name='LogonGuid'>{f3183221-8cf4-63b7-9dac-4f0000000000}</Data>
	<Data Name='LogonId'>0x4fac9d</Data>
	<Data Name='TerminalSessionId'>2</Data>
	<Data Name='IntegrityLevel'>Medium</Data>
	<Data Name='Hashes'>MD5=3A6BDA23988B72A24458551CCE0449A5</Data>
	<Data Name='ParentProcessGuid'>{f3183221-af62-63c7-2eb1-c49a02000000}</Data>
	<Data Name='ParentProcessId'>2468</Data>
	<Data Name='ParentImage'>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Data>
	<Data Name='ParentCommandLine'>powershell c:\tempy\sliver_seamless.ps1</Data>
</EventData>

Raw Log - UAC Bypass

<System>
	<Provider Name='Microsoft-Windows-Sysmon' Guid='{5770385f-c22a-43e0-bf4c-06f5698ffbd9}'/>
	<EventID>1</EventID>
	<Version>5</Version>
	<Level>Information</Level>
	<Task>Process Create (rule: ProcessCreate)</Task>
	<Opcode>Info</Opcode>
	<Keywords></Keywords>
	<TimeCreated SystemTime='2023-01-18T08:35:47.165276900Z'/>
	<EventRecordID>6964968</EventRecordID>
	<Correlation/>
	<Execution ProcessID='1984' ThreadID='2120'/>
	<Channel>Microsoft-Windows-Sysmon/Operational</Channel>
	<Computer>sv011-test.corp1.local</Computer>
	<Security UserID='NT AUTHORITY\SYSTEM'/>
</System>
<EventData>
	<Data Name='RuleName'>-</Data>
	<Data Name='UtcTime'>2023-01-18 08:35:47.163</Data>
	<Data Name='ProcessGuid'>{f3183221-af63-63c7-4ed3-c49a02000000}</Data>
	<Data Name='ProcessId'>4168</Data>
	<Data Name='Image'>C:\Windows\System32\dllhost.exe</Data>
	<Data Name='FileVersion'>10.0.14393.0 (rs1_release.160715-1616)</Data>
	<Data Name='Description'>COM Surrogate</Data>
	<Data Name='Product'>Microsoft® Windows® Operating System</Data>
	<Data Name='Company'>Microsoft Corporation</Data>
	<Data Name='OriginalFileName'>dllhost.exe</Data>
	<Data Name='CommandLine'>C:\Windows\system32\DllHost.exe /Processid:{3e5fc7f9-9a51-4367-9063-a120244fbec7}</Data>
	<Data Name='CurrentDirectory'>C:\Windows\system32\</Data>
	<Data Name='User'>CORP1\tboss</Data>
	<Data Name='LogonGuid'>{f3183221-8cf4-63b7-3dac-4f0000000000}</Data>
	<Data Name='LogonId'>0x4fac3d</Data>
	<Data Name='TerminalSessionId'>2</Data>
	<Data Name='IntegrityLevel'>High</Data>
	<Data Name='Hashes'>MD5=DA63852A2B0340E94D74EAF0CD444979</Data>
	<Data Name='ParentProcessGuid'>{f3183221-8c51-63b7-4598-000000000000}</Data>
	<Data Name='ParentProcessId'>748</Data>
	<Data Name='ParentImage'>C:\Windows\System32\svchost.exe</Data>
	<Data Name='ParentCommandLine'>C:\Windows\system32\svchost.exe -k DcomLaunch</Data>
</EventData>

Detection Logic

For this part of the attack chain we have two related detections. There are also other UAC bypass techniques out in the wild that can be used. The same process of testing can be followed to develop detections. These detections are deceptively simple but took significant work to test and ensure they were accurate enough to actually use.

  • Server - Suspicious Commands – CMSTP - For this one we detect any use of cmstp.exe on the command line. This is infrequently used these days and anything that does use it regularly can be excluded. In the command line argument we can see the use of the randomly generated .inf file. We do not correlate on this as it can easily be changed but anything run from the temp directory may result in a better detection in your environment.
  • Attack - Possible UAC Bypass – cmstplua - This detection looks for a very specific CLISD value being called by dllhost.exe . This CLSID value belongs to CMSTPLUA. This is the call in which the custom process is spawned while being auto-elevated to bypass UAC.

Detection Logic - CMSTP Execution

Log Source:
Windows Security OR Sysmon
Event ID:
4688 OR 1
Process Name:
EXACT MATCH cmstp.exe

Detection Logic - UAC Bypass

Log Source:
Windows Security OR Sysmon
Event ID:
4688 OR 1
CommandLine:
CONTAINS REGEX 3e5fc7f9
AND Process Name:
EXACT MATCH dllhost.exe

Reference

The below reference is what we used to build the DLL and then link that to a PowerShell script that executes our Sliver beacon.

https://0x00-0x00.github.io/

https://0x00-0x00.github.io/research/2018/10/31/How-to-bypass-UAC-in-newer-Windows-versions.html
How to bypass UAC in newer Windows versions

Domain Escalation

Kerberoasting is a common way to attempt to gain further privileges in the Domain. If done sneakily you can evade most detections and also products such as Defender for Identity. However most tools go for gold and Kerberoast all accounts with a Service Principal Name (SPN). Doing them one at a time is still detectable through Windows native logging.

The following are 3 examples of how we attempt to detect Kerberoasting. More than this may trigger depending on the privileges of the account which has been targeted. More detections means more confidence, something like that anyway.

  • Attack - Kerberos Ticket Requested - HoneyTicket - Create a honey account with an SPN and a great password. If a tool is used that kerberoasts all users then this will trigger.
  • Attack - Kerberos Ticket Requested - High Privilege - Any accounts which a high level of privilege such as SQL service accounts or others that may be local admin over the server fleet can be added here. Running Bloodhound will give you a great idea of any accounts on the path to Domain Admin which may not be a direct Domain Admin, add any of these.
  • Attack - Kerberos Ticket Requested - Domain Admin - Any accounts that have Domain Admin rights and an SPN can be monitored with this rule.

Raw Log - Honey Ticket Request

<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
	<Provider Name='Microsoft-Windows-Security-Auditing' Guid='{54849625-5478-4994-a5ba-3e3b0328c30d}'/>
	<EventID>4769</EventID>
	<Version>0</Version>
	<Level>Information</Level>
	<Task>Kerberos Service Ticket Operations</Task>
	<Opcode>Info</Opcode>
	<Keywords>Audit Success</Keywords>
	<TimeCreated SystemTime='2023-01-18T09:31:24.727321400Z'/>
	<EventRecordID>32815274</EventRecordID>
	<Correlation/>
	<Execution ProcessID='732' ThreadID='5352'/>
	<Channel>Security</Channel>
	<Computer>SV001-DC.corp1.local</Computer>
	<Security/>
</System>
<EventData>
A Kerberos service ticket was requested.

Account Information:
	Account Name:		tboss@CORP1.LOCAL
	Account Domain:		CORP1.LOCAL
	Logon GUID:		    {05c81286-86f8-08c4-6091-8da118b0f941}

Service Information:
	Service Name:		svc_http_admin
	Service ID:		    CORP1\svc_http_admin

Network Information:
	Client Address:		::ffff:192.168.3.15
	Client Port:		18561

Additional Information:
	Ticket Options:		    0x800000
	Ticket Encryption Type:	0x17
	Failure Code:		    0x0
	Transited Services:	    -
</EventData>
</Event>

Detection Logic

Once you have identified the accounts for each variant of the rule the logic is quite simple. We just need to look for the service name for the SPN on each account we want to monitor.

Detection Logic - Honey Ticket

Log Source:
Windows Security
Event ID:
4769
Service Name:
EXACT MATCH svc_http_admin (Will be different in your environment.)

Summary

Hopefully that gives a glimpse into how we test and what some of the logs look like. I had planned on adding more detections but even the simple ones added in here took a lot longer than expected. If there are any particular detections/logs from our full attack chain in Part 2 please reach out and we can add them in here or do a Part 4. The main point of these articles was to highlight the effort involved in actually testing, logging and building detections. Too often it’s not as simple as throw the new Sigma rule you found on Github into your SIEM product and hope for the best.