ShadowThreat Initial Intrusion
RMRF Technology faced with a very complex attack in its latest investigations. The way of injection has been previously described by Palo Alto Networks and Cisco Talos. We called it ShadowThreat (of course, there are some reasons for such name, but the detailed explanation will be later).
But it’s only a first impression…
Below we described only overall behavior because the threat is continuously modifying and depends on Target infrastructure.
It’s worth to say that as usual, processes of described threat are almost automated — gathering information about new Target (Application/Services/drivers enumeration) constructs some schema of catching on a fly. ShadowThreat performs continuously Reconnaissance and Data Exfiltration for deeper intrusion and protection own persistence. If you change something — threat accommodates with new environment quickly enough. According to such extraordinary behavioral, ShadowThreat isn’t a common APT. It looks like a Cyber Threat.
ShadowThreat Life Cycle
The Reconnaissance phase of ShadowThreat isn’t something unique:
passive information gathering;
active information gathering;
network/application vulnerability identification.
But in the second phase of ShadowThreat’s scenario, we have a mix of common Initial intrusion technics such as:
malicious USB Media;
And something more interesting — using Microsoft Windows logic:
PS/PSRemoting + CIM cmdlets;
exploit “features” of Windows Defender.
For example, winrm.exe (WMI component) can be used to enumerate WMI object instances, invoke methods, create and remove object instances on local and remote machines running the WinRM service. Also, winrm.exe can be used to configure WinRM settings (WMI protocol for remote access). The ideal method of interacting with WMI over WinRM is PowerShell + CIM cmdlets.
The third phase stands out by several extraordinary approaches. Especially Persistence begins from work with RAM:
PSRemoting + hack tools (one of the most favorite bundles of ShadowThreat is RAT plugX&mimikatz&kiwi);
disabling diagtrack (Windows telemetry service);
bypass Windows security mechanism (with Protected Process Light includes);
upload obfuscated code via PS and execute in RAM (file-less malware);
remote code injection in Windows Defender and legitimate processes;
add privileges for legitimate processes with a malicious goal.
For example, even in RedStone3 with Windows Protection Level: Windows Light service diagtrack is still STOPPABLE (before, in RedStone2 diagtrack has Windows Protection Level: NONE):
Note. As usual, at the end of this step, ShadowThreat leaves PS as a suspended process.
Than — work with HardDisk begins:
using RESERVED volume, BadClusters and Volume Shadow Storage (VSS) for hosting SHADOW’s auto-recovery code;
hosting hack tool as system driver on File System;
upload additional PowerShell modules.
Work with OS:
using native for Windows languages: JS, VBScripts, C++ (especially via stdin/stdout we can write/read from BadClusters), FSO, WQL;
virtualcontainer as a bootstrapper for SHADOW’s code;
SHADOW’s licensing (KMS-activation);
compromise updates and components of OS Windows (
SHADOWS’sTrustInstaller & WMI/CIM providers — don’t forget about the specialty of WMI launches as a SYSTEM);
suppress errors from Applications;
try to clean events;
continuously debugging SHADOW’s code on
updating malicious code in background mode.
Also in parallel with upper actions ShadowThreat tries to escalate privileges using:
malicious remote code injection in LSASS (don’t forget about PS & mimikatz+kiwi);
transfer via ‘ms-update’ SHADOW’s ntdll.dll and ntoskrnl.exe (yes, these guys have some passion of catching kernel callbacks and using Direct Kernel Object Manipulation attack);
add privilege of uploading drivers for Windows Defender.
It isn’t such unbelievable as you can think — in our next article we will give more technical details for each phase.
Okay, let’s move on C2C phase, where the ShadowThreat uses a combination of IPv4&IPv6 protocols for connecting a Target to its own SHADOW NETWORK. And after success backdooring on Persistence stage — SHADOW’s processes are continuously waiting on commands from C2C. Yes, from this moment host is compromised, so attacker goes on to lateral movement across Target infrastructure with next technics:
PS + CIM cmdlets;
WMI components on client’s side and WinRM, DCOM as remote protocol access;
using Terminal Servers & SMB for further distribution of SHADOW’s code;
using uploaded hack tools on the compromised host (here these guys love to use Trojan.Meterpreter, which is made hidden from defense-decision);
remote code injection from the compromised host (don’t forget about bundle mimikatz+kiwi);
settling SHADOW’s WMI Providers;
At this moment a logical question can appear “For what do they so huge work?”. As you already have noticed in ShadowThreat’s scenario, the compromised host is a mix of hosting malicious code and can act as a RAT for connected devices. This “work” is needed for automation of the process of total infection and connection to SHADOW NETWORK. Also, such behave takes easier the phase of Asset discovery, which consists of:
Internal Network Recon;
Network Security Recon.
In ShadowThreat’s scenario we can highlight such sequence of infection in Target infrastructure:
Domain Recon (it is needed for further Asset discovery, spread SHADOW’s code using GPO, gain legitimate remote access to Target network);
SCCM Recon (it is convenient for further spreading SHADOW’s code and configuration for WMI, modifying Windows-images with embedding backdoors);
WSUS Recon (spreading SHADOW’s code via compromised ms-updates).
Please, don’t underestimate WMI power on this phase. It can be used as a legal RAT — especial WinRM and DCOM. Also with using
Host/OS information: Win32_ComputerSystem, Win32_OperatingSystem;
File/directory listing: CIM_DataFile;
Disk volume listing: Win32_Volume;
Registry operations: StdRegProv;
Running processes: Win32_Process;
Service listing: Win32_Service;
Event log: Win32_NtLogEvent;
Logged on accounts: Win32_LoggedOnUser;
Mounted shares: Win32_Share;
Installed patches: Win32_QuickFixEngineering;
Note. WMI logging is disabled by default.
Is that all extraordinary? No. ShadowThreat continuously
Telemetry (don’t think that this is only worrying about ‘client’);
RAM dumps (yes, there can be interesting hashes…);
Memory dump of “dangerous for SHADOW” tools (acts as protection method).
Recommendations from RMRF
At a first — check, please, ms-updates in your Microsoft Windows OS (don’t trust indexing, we will speak about this later):
Command Prompt (cmd) -> run as Administrator (move down, please);
dism /online /get-packages (look at Install Time, also you can write output in
fileand save it — ok, let’s move down);
systeminfo.exe (you can see installed hotfixes);
dism /online /get-packages | findstr KB4022405 (try to find package of Windows hotfix).
You can see something like that:
Ok, here we couldn’t speak about ‘where is KB4038788?’ — let’s find the KB packages (if you have more KBs — try to check the most recent):
Now you can move to location and analyze your KB-packages on file system (FS) with the same KB-packages on Microsoft Windows support-portal. Please, take your attention on next file information: name, version, size, date — compare this info. Of course, you can see another location.
For further details please check our Github repo, you can find there continuously updating IoCs.