...
[*] Started HTTPS reverse handler on https://192.168.51.50:443
[*] https://192.168.51.50:443 handling request from 192.168.51.10; (UUID: xzrlbcgs) Staging x64 payload (201308 bytes) ...
[*] Meterpreter session 1 opened (192.168.51.50:443 -> 127.0.0.1 ) at 2021-10-29 15:33:44 -0400
meterpreter >
With these actions in mind, we could search for RegistryEvent, FileCreate, and ProcessCreate events — an attacker usually would need to upload their own malicious executable, hence the FileCreate events. If the service executed, we could also search for NetworkConnect events, assuming it's a shell.
Persisting via Scheduled Tasks
Queryin ga schedule task
C:\Windows\system32>schtasks /query /tn MicrosoftEdgeUpdateTaskMachineCore
Folder: \
TaskName Next Run Time Status
======================================== ====================== ===============
MicrosoftEdgeUpdateTaskMachineCore 11/8/2021 8:38:35 AM Ready
Scheduled tasks are stored in C:\Windows\System32\Tasks.
Search for FileCreate, ProcessCreate, DNSEvent, and NetworkConnect events.
Persisting by DLL-Sideloading/Hijacking
Most applications do not check the integrity of DLLs, thus a savvy attacker could introduce a malicious replacement.
This idea of DLL replacement can have devastating consequences. In 2020, adversaries deployed a malicious DLL to the SolarWinds Orion update repository. Every customer update incorporated this new DLL, which gave the adversary access to those machines after the update.
This vulnerability lies in the DLL search order. The order of checks is as listed:
Is the DLL loaded in memory?
Is the DLL in teh list of known DLLs shown in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs?
IF SafeDllSearchMode is enabled, Windows will search for the dll in the directory the program was executed from. If disabled, Windows will search where the program was executed as well as the current directory of the user, before System directories and the Windows directory.
Copying the malicious DLL for On-Screen Keyboard to a new directory for hijacking purposes
After rebooting the target, we can execute osk.exe. The On-Screen Keyboard won't appear due to the DLL not providing the normal functionality, however the code inside that DLL is still executed.
Catching the reverse shell from the malicious dll being executed
...
[*] Started HTTPS reverse handler on https://192.168.51.50:443
[*] https://192.168.51.50:443 handling request from 192.168.51.10; (UUID: tk31ip8a) Staging x64 payload (201308 bytes) ...
[*] Meterpreter session 1 opened (192.168.51.50:443 -> 127.0.0.1 ) at 2021-11-18 12:19:35 -0500
meterpreter >
Search for FileCreate, ProcessCreate, DNSEvent, and NetworkConnect events. Because we know osk.exe is the binary with the DLL hijacking, we could also search for events where osk.exe is in the ParentImage value.
Persistence in Registry
Using Run Keys
The Run and RunOnce keys are commonly used for persistence. They can be located here:
There is a third type of Run key, RunOnceEx. The program listed in this key will run once, but it will not be cleared until the program has completed execution. By contrast, the RunOnce key will delete itself at the moment of execution.
HKEY_CURRENT_USER (HKCU) run keys run only when the specific user logs in.
HKEY_LOCAL_MACHINE (HKLM) run keys run when any user logs in.
Searching for events around the time of our changes
[192.168.51.10]: PS C:\Users\offsec\Documents> Get-SysmonEvent $null "11/15/2021 8:49:00" "11/15/2021 8:50:00"
ProviderName: Microsoft-Windows-Sysmon
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
11/15/2021 8:49:17 AM 11 Information File created:...
11/15/2021 8:49:17 AM 1 Information Process Create:...
11/15/2021 8:49:12 AM 13 Information Registry value set:...
11/15/2021 8:49:12 AM 1 Information Process Create:...
PowerShell's New-ItemProperty is one of several cmdlets that can update the Windows Registry. If used, there would be no ProcessCreate event for reg.exe, but the Registry event's Image field would contain powershell.exe.
Using Winlogon Helper
When authentication to a Windows endpoint, the OS relies on the Windows Logon (Winlogon) process. Winlogon controls everything between the load of a user profile and the unlocking of the workstation.
Winlogon's configuration is stored in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.
Modifying the Shell subkey to also execute our malicious binary