Open Source Toolset Of An Ivanti Csa Attacker

In recent incident responses where the root cause was an Ivanti CSA compromise, Synacktiv's CSIRT came across multiple open-source tools used by threat actors. This article dives into each of these tools, their functionalities and discusses efficient detection capabilities.

In September and October 2024, Ivanti published multiple 1 security 2 advisories 3 regarding security policy bypasses and remote code execution vulnerabilities in their Cloud Services Appliance (CSA) product. It was later revealed by FortiGuard Labs Threat Research's work 4 that some threat actors had been actively chaining these vulnerabilities as early as September 9, 2024, before any security advisory or patch was publicly released by Ivanti.

In some compromise scenarios, even though the initial access stemmed from the exploitation of zero-day vulnerabilities, later stages were short of such proficient attacker tradecraft. Threat actors were seen using known malicious tools and noisy payloads for lateral movement, persistence and credential dumping.

Synacktiv's CSIRT was recently in charge of different forensic investigations where the root cause was a vulnerable CSA appliance exposed to the internet. During these engagements, we found a set of open-source tools used by the attacker to achieve its goals. In this article, we take a tour of the OSS toolset from an Ivanti CSA exploiter and related detection capabilities.

After initial compromise of the Ivanti CSA appliance, the attacker managed to move to an internet-facing Exchange Server used for OWA connections. They planted an HTTP proxy tunnel going by the name of suo5 . Available publicly on GitHub , with an initial commit dated February 2023, this tool is presented as a more performant alternative to other tunnelling tools such as reGeorg and Neo-reGeorg .

Interestingly enough, the GLASSTOKEN custom webshell, used during intrusions linked to the exploitation of 0-day vulnerabilities in Ivanti Connect Secure VPN 5 in January 2024, was based on the Neo-reGeorg tool. Additionally, the reGeorg tool was used as a commodity webshell in attacks linked to the exploitation of 0-day vulnerabilities in Microsoft Exchange 6 in March 2021.

The suo5.aspx webshell was dropped on the Exchange Server at the location C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\OutlookEN.aspx . This name could be a reference to HAFNIUM-related activities during post-exploitation of the Microsoft Exchange vulnerabilities 7 in March 2021.

For suo5 to work, an attacker-accessible web server (usually a server exposed to the internet) must run suo5 server-side code, available in .NET, Java or PHP (experimental). In our test case, the OutlookEN.aspx page run by the IIS component of the Exchange Server is the .NET-flavor of suo5 server-side code.

On the attacker's side, a SOCKS5 proxy must be set up and the suo5 binary communicates with the server-side code to transmit TCP data encapsulated in the HTTP(S) communication.

Using a tool like proxychains , the attacker can then communicate with any system accessible by the Exchange Server. This enables him to get a foothold inside the internal network of the victim. In our test case, using suo5 enables us to connect to a system ( 192.168.123.15 ) on another subnet, which would have been otherwise inaccessible:

The blog post associated with the tool 8 explains how suo5 achieves better performance than its competitors: it uses the chunked directive for the Transfer-Encoding HTTP/1.1 header 9 . This essentially means that the request's sender can keep the connection open until it notifies the recipient that the entire message has been sent. In this mode, all encapsulated TCP packets are contained in a single HTTP connection, reducing overhead of multiple HTTP requests and responses. This is the " full duplex " mode advertised in the GitHub project's README :

Due to a limitation in .NET HTTP request processing 10 , the "full-duplex" mode cannot be used. The tool then falls back to " half-duplex " mode, where only the response is sent as a continuous data stream, but requests are sent as separate HTTP requests. The goal of "half-duplex" mode is also to bypass restrictions of an Nginx reverse proxy that would stand between the suo5 client and the server-side code. By default, Nginx buffers requests 11 , a limitation that cannot be circumvented without modifying the reverse proxy's configuration. However, Nginx also buffers responses by default except if the X-Accel-Buffering: no header field is sent as part of the response 12 (which is the case for the suo5 webshell). This results in a connection still having better performance than Neo-reGeorg:

To detect the server-side file (either on disk or loaded in memory), we want to create a YARA rule that avoids using easily changeable data like function and variable names. We want to focus on detecting functionalities of the webshell. One contextual IOC that we could use, however, is the User-Agent that acts as a kind of "password" so that only the client is authorized to connect to the webshell. Careless attackers might leave the default value:

This is the User-Agent of a Chrome browser (version 109.1.2.3) on an LG Nexus 5 smartphone (Android 6.0 - Marshmallow).

Stealthier attackers will change the User-Agent checked by the server:

They will then pass that User-Agent string as an argument to the suo5 client, via the --ua flag:

Due to the nature of this string, which goal is to discriminate against other suo5 clients or unintentional connections to the webshell, there is a high chance that it will be relatively unique, leaving an interesting IOC for DFIR and SOC analysts.

The following YARA rule focuses on key characteristics of the webshell:

X-Accel-Buffering: no response header.

User-Agent-based authentication.

Usage of TCP client to proxy communications.

Binary serialization and de-serialization.

Byte XORing and random key generation.

Security professionals wishing to set up an IDS/IPS rule to detect HTTPS suo5 traffic are out of luck. Except for having TLS interception, their best bet would have been to detect specific client JA3 13 /JA4 14 fingerprints, but suo5 uses the Randomized TLS Client Hello Fingerprint functionality of the uTLS 15 Go library:

The attacker wished to keep a foothold inside the victim's network that would last even after patches were applied on the Ivanti CSA appliance. They proceeded to deploy another tunnel named iox , directly on the internet-facing appliance.

In its GitHub page , iox is presented as a better alternative to two other port forwarding tools: lcx (also known as HTran 16 for HUC Packet Transmit Tool ) and ew (also known as Earthworm 17 ).

The lcx tool is a piece of history linked to Chinese hacking culture in the early 2000s. It is a port forwarding tool, created around 2003 18 by a Chinese hacker going by the name "Li0n" which is the founder of a nationalist hacking group called Honker's Union of China (HUC) 19 . It has been used 20 in numerous 21 attacks 22 attributed to Chinese threat actors 23 over the years.

The Earthworm tool came as a more powerful replacement to the ageing lcx/Htran one. It incorporated lcx 's core concepts (different modes of port forwarding) and added SOCKS5 proxy and reverse SOCKS5 proxy functionalities. Its versatility made it an interesting tool to make complex forwarding chains, abstracting connection from a source to a destination host through multiple hops and taking advantage of the few open ports of each firewall in the way 24 . It was used as a commodity tunnelling tool in different attacks such as the active exploitation of the ProxyShell vulnerability by UNC2980 25 or the attack on US critical infrastructure by Volt Typhoon 26 .

iox has similar functionalities to Earthworm , with a cleaner syntax and some network code optimizations. It adds optional traffic encryption and UDP traffic forwarding.

iox 's port forwarding capabilities can be used to circumvent network flow restrictions (using well-known ports) and obfuscate the true source of network connections when a foothold has been established inside the victim's LAN. In the following example, the edge server (second hop — hop2 ) can communicate with outside hosts via port 443, so it establishes a connection to the first hop ( hop1 ). The third hop in the chain ( hop3 ) runs a SOCKS5 proxy. From the point of a view of the victim's network, requests that are coming from the attacker seem to originate from the third hop ( hop3 ).

Communications that are forwarded inside the victim's internal network are encrypted with symmetric encryption algorithm XChaCha20. This encryption is not meant to be a bullet-proof protection of the privacy of forwarded content, but an evasion technique against NIDS/NIPS.

A reverse SOCKS5 proxy can also be established. In the following scenario, traffic coming from the attacker machine seems to originate from the second hop ( hop2 ).

In this scenario, traffic encryption, which is an optional feature, is not activated.

Existing public detection rules rely on function and library names 27 or on arguments passed to the command line 28 . In the interest of adding complementary rules to the open-source community, we worked on detection rules relying on different identifiers.

During our engagement, we found an obfuscated sample of iox. Function names, library names, arguments and most of the strings had been removed or obfuscated. We then worked on a detection logic that would rely on discriminating patterns in the code. We needed homemade functions which logic would not rely on standard libraries. We focused on the homemade iox/crypto library.

Two constructs were chosen for our detection logic:

in function ExpandKey and

in function shuffle .

Extracting small chunks of assembly code from the disassembled sample respectively gives the following patterns to detect:

In order to make our rule more effective while limiting false positives and maintaining sufficient performance, we structured it to detect patterns of assembly instructions regardless of registers used. For example, the instruction cmp rbx, 20h could use any register for integer arguments and results specified in the Go internal ABI specification 29 : RAX, RBX, RCX, RDI, RSI, R8, R9, R10, R11 . While making sure to use 4-byte patterns as much as possible (to improve performance with the YARA/YARA-X engine), this results in the following hexadecimal string:

The resulting YARA/YARA-X detection rule is as follows:

This rule was tested with YARA , YARA-X and yaraQA to assess its performance. It helped us detect other in the wild obfuscated samples of the tool.

For the sake of completeness, the following rule, based only on strings found in the unobfuscated samples, was also created:

The atexec.py 30 script is a well-known lateral movement tool leveraging Impacket 31 classes to gain remote code execution on an endpoint through the Task Scheduler service.

The attacker executed commands on the Active Directory Domain Controller from another host inside the network using a variation of this script called atexec-pro.py 32 .

The original atexec.py script first establishes an RPC connection over an SMB named pipe 33 targeting the \pipe\atsvc 34 endpoint, and then uses this connection to specifically bind to the ITaskSchedulerService 35 interface for subsequent operations. It then creates a scheduled task, with a name made up of 8 random characters, which is configured to run a single command through the Command Prompt ( cmd.exe ) with the highest permissions available ( NT AUTHORITY\SYSTEM ) and to redirect the output to %WINDIR%\Temp\ .tmp .

The script triggers the task's execution, deletes the task, reads the content of the .tmp file through an SMB connection to the ADMIN$ and then deletes this file. This means the script only communicates with port 445 throughout its execution.

The atexec-pro.py script works quite differently. First of all, an alternative to RPC over SMB is offered, relying on RPC over TCP/IP 36 for task manipulation. This protocol uses the RPC Endpoint Mapper, listening on port 135, to resolve the dynamic endpoint (high ports, ranging typically from 49152 to 65535 37 ) of the ITaskSchedulerService interface. While it is interesting to have another option, most Windows Firewall configurations will, by default in AD domain networks, block incoming requests to dynamic ports, rendering this method of connection useless.

Once the connection is established, the tool presents itself as a shell:

Remote command execution works as follows:

It works similarly for .NET assembly execution. For upload and download, the file's content is encoded and read from or placed into the task's description.

Overall, the following functionalities are available:

Command Prompt command execution.

PowerShell command execution.

.NET assembly execution.

Interaction with ITaskSchedulerService via RPC over SMB or RPC over TCP/IP.

Due to the way files are transferred (via the Description field of the task), file upload, file download and .NET assembly execution only support files up to 1 MB in size.

What atexec-pro.py makes up for in functionality, it lacks in stealth. Every command launched through the Task Scheduler first goes through a PowerShell script, as defined in the task XML definition:

where {ps_command} is replaced by atexec-pro.py with a base64-encoded PowerShell script. The default scripts provided for each command of the tool can easily be flagged as suspicious:

Base 64 encoding and decoding.

AES encryption and decryption.

Interaction with the Task Scheduler service via the Task Scheduler Scripting Objects 38 .

As such, even on default Windows Event Log configurations where Script Block Logging is not fully enabled and only suspicious scripts are logged, Event ID 4104 events are generated in Microsoft-Windows-PowerShell\Operational for each execution of an atexec-pro 's command.

This results in the following Sigma rule:

A similar rule can be created based on command line content if process creation is logged.

As for forensic artefacts left by the execution of the original atexec.py script, the following article explores them (and many more remote code execution tools ;).

Throughout this article, we discovered three tools actively used by threat actors to tunnel traffic to and from the internal network ( suo5 , iox ) and to execute code remotely ( atexec-pro ). We analysed their core capabilities and used them to create YARA and Sigma detection rules, focusing on broad detection, harder defence evasion and low false positive rates.

All detection rules created for this article will be maintained in the following GitHub repository .

If your organization needs assistance in removing doubt or responding to a security incident, please feel free to Synacktiv's CSIRT.

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

29.

30.

31.

32.

33.

34.

35.

36.

37.

38.