New Cyberthreat Replaces Operating System with a “Fake”. Part 1

As we mentioned in our previous article, RMRF Technology faced with 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 detailed explanation will be later).

It looks like APT attack (Advanced Persistent Threat) with presence of full life-cycle:

1. Reconnaissance for information gathering and preparation to attack a specific Target.
2. Initial intrusion for gaining initial foothold within the Target infrastructure.
3. Persistence for implementation of backdoors.
4. C&C for maintaining active connections with Target network via establishing a Command and Control (C&C) infrastructure.
5. Privilege escalation for spreading through Target infrastructure.
6. Lateral movement within Target-infrastructure.
7. Asset discovery for growing up in access to specific systems within the Target organization’s network.
8. Data exfiltration for transferring collected information from Target production network.

ShadowThreat Life Cycle

But it’s only a first impression…

Below we described only overall behaviour, because the threat is continuously modifying and depends on Target infrastructure.

Summary

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 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 behavioural, ShadowThreat isn’t a common APT. It looks like a Cyber Threat.

ShadowThreat Life Cycle

The Reconnaissance phase of ShadowThreat isn’t something unique:

• external recon;
• passive information gathering;
• active information gathering;
• port scanning;
• service enumeration;
• network/application vulnerability identification.

But on the second phase of ShadowThreat’s scenario we have a mix of common Initial intrusion technics such as:

• exploit Vulnerabilities;
• malicious USB Media;
• spear Phishing;
• wireless;
• uPnP.

And something more interesting — using Microsoft Windows logic:

• PS/PSRemoting + CIM cmdlets;
• WMI components;
• 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 STOPABLE (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;
• COM hijacking;
• virtual container as a bootstrapper for SHADOW’s code;
• SHADOW’s licensing (KMS-activation);
• compromise updates and components of OS Windows (SHADOWS’s TrustInstaller & WMI/CIM providers — don’t forget about specialty of WMI launches as a SYSTEM);
• suppress errors from Applications;
• try to clean events;
• continuously debugging SHADOW’s code on fly;
• 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);
• Remote Registry;
• settling SHADOW’s WMI Providers;
• uPnP.

At this moment a logical question can appear “For what do they so huge work?”. As you already have noticed in ShadowThreat’s scenario, compromised host is a mix of hosting malicious code and can acts as a RAT for connected devices. This “work” is needed for automation 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 WMI-objects we can get internal network Reconnaissance information:

• 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 do Data exfiltration from its “hostings”. And it isn’t only user’s data from compromised hosts. They gather:

• 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 Technology

1. 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 file and 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 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 these info. Of course, you can see another location.

For further details please check our Github repo, you can find there continuously updating IoCs.