Multiple mechanisms were enabled through Vestige on the compromised machine, so that even in the event of a reboot, control is still maintained. First, registry keys were created in HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run for Java Update Scheduler, Qexer, and Update. When the user then logs in again, the Java Update Scheduler relaunches the impostor Java.exe again to make sure all of the persistence methods remain or are re-added to the machine. Update is a malicious .bat file that re-establishes the link to the attacker machine through the reverse TCP shell.
Next, a Scheduled Tasks for Java.exe was added through an obfuscated PowerShell command, where the scheduled task runs the Vestige program again when the machine has been idle for a specific amount of time. This persistence set has an added bonus, whereby, it runs the process with full SYSTEM privileges. This negates the need for the UAC-TokenMagic script.
PowerShell command for Scheduled Task:
“$action = New-ScheduledTaskAction -Execute ‘Java.exe’; $settings = New-ScheduledTaskSettingsSet -RunOnlyIfIdle -IdleDuration 00:02:00 -IdleWaitTimeout 02:30:00 -Hidden; $prin = New-ScheduledTaskPrincipal -GroupId ‘BUILTIN\Administrators’ -RunLevel Highest; Register-ScheduledTask -Action $action -settings $settings -Principal $prin -TaskName ‘Java’ -Force”
Last, a new user, OwnedUser, was created and added to the local administrators group. This was done so that UAC is no longer an obstacle for lateral movement, to allow easier creation of additional persistence mechanisms, and to provide layered persistence of existing methods, adding one more possibility that even if detected, persistence may still be maintained.
What to do:
There are multiple methods for investigating and detecting the malicious persistence methods, the ones we chose were to utilize Dave Hull’s PowerShell incident response framework, Kansa, which has a multitude of different scanning options for incident response, breach hunts, and environmental baselines on a domain. And we enabled a Group Policy with PowerShell script block logging to capture full contents of code executed in PowerShell.
Before running, we wanted Kansa to also capture suspicious ASEPs using the Sysinternals Autorunsc.exe. This requires downloading Sysinternals and then placing Autorunsc.exe in \Kansa-master\Modules\bin as well as C:\Windows. Then, either remove the comment “#” in front of Get-AutorunscDeep.ps1 in the Modules.conf file found in \Modules.
When we ran Kansa, we wanted verbose scanning and the ASEP scan, which necessitated copying Autorunsc.exe to ADMIN$ on each machine during the scan, then removing when finished. This is done with “-Pushbin #BINDEP .\Modules\Bin\Autorunsc.exe -rmbin”. BINDEP tells Kansa where to copy the binary from and -rmbin is what removes the binary when scans complete.
Kansa then found all of the machines currently running on the domain and and ran scans on each:
Examining the Results:
Parsing through the CSVs for the scans on each machine, the below results show that Kansa was able to detect the Administrator account “OwnedUser” was that was created by Vestige.
The malicious scheduled task, Java.exe, was also detected and runs as an Administrator, something Java.exe shouldn’t need to do.
The results of the AutorunscDeep scan show the CurrentVersion\Run keys that were added as a persistence method. The description for Java Updater Scheduler as “COM Surrogate” should stand out. Update, however, is a little less obvious that it is a malicious .bat file created as a persistence methods. This highlights how deep investigation for CurrentVersion\Run keys is often required to find the hidden malicious processes.
Script Block Logging GPO
An additional method of detecting and logging suspicious PowerShell commands is to enable script block logging through a Group Policy. This is enabled through the Group Policy Management Editor then navigating to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell. Then linking that GPO to the proper OU. The log files for these events are written to the PowerShell operational log Microsoft-Windows-PowerShell%4Operational.evtx.