Blog
/
Network
/
January 26, 2024

Post-Exploitation Activities of Ivanti CS/PS Appliances

Darktrace’s teams have observed a surge in malicious activities targeting Ivanti Connect Secure (CS) and Ivanti Policy Secure (PS) appliances. Learn more!
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Sam Lister
SOC Analyst
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
26
Jan 2024

What are 'Unknown Unknowns'?

When critical vulnerabilities in Internet-facing assets are not yet publicly disclosed, they can provide unfettered access to organizations’ networks. Threat actors’ exploitation of these vulnerabilities are prime examples of “unknown unknowns” – behaviors which security teams are not even aware that they are not aware of.  

Therefore, it is not surprising that zero-day vulnerabilities in Internet-facing assets are so attractive to state-linked actors and cybercriminals. These criminals will abuse the access these vulnerabilities afford them to progress towards harmful or disruptive objectives. This trend in threat actor activity was particularly salient in January 2024, following the disclosure of two critical vulnerabilities in Ivanti Connect Secure (CS) and Ivanti Policy Secure (PS) appliances. The widespread exploitation of these vulnerabilities was mirrored across Darktrace’s customer base in mid-January 2024, with Darktrace’s Security Operations Center (SOC) and Threat Research teams observing a surge in malicious activities targeting customers’ CS/PS appliances.

Vulnerabilities in Ivanti CS/PS

On January 10, 2024, Ivanti published a Security Advisory [1] and a Knowledge Base article [2] relating to the following two vulnerabilities in Ivanti Connect Secure (CS) and Ivanti Policy Secure (PS):

  • CVE-2023-46805 (CVSS: 8.2; Type: Authentication bypass vulnerability)
  • CVE-2024-21887 (CVSS: 9.1; Type: Command injection vulnerability)

Conjoined exploitation of these vulnerabilities allows for unauthenticated, remote code execution (RCE) on vulnerable Ivanti systems. Volexity [3] and Mandiant [4] reported clusters of CS/PS compromises, tracked as UTA0178 and UNC5221 respectively. UTA0178 and UNC5221 compromises involve exploitation of CVE-2023-46805 and CVE-2024-21887 to deliver web shells and JavaScript credential harvesters to targeted CS/PS appliances. Both Volexity and Mandiant linked these compromises to a likely espionage-motivated, state-linked actor. GreyNoise [5] and Volexity [6] also reported likely cybercriminal activities targeting CS/PS appliances to deliver cryptominers.

The scale of this recent Ivanti CS/PS exploitation is illustrated by research findings recently shared by Censys [7]. According to these findings, as of January 22, around 1.5% of 26,000 Internet-exposed Ivanti CS appliances have been compromised, with the majority of compromised hosts falling within the United States. As cybercriminal interest in these Ivanti CS/PS vulnerabilities continues to grow, it is likely that so too will the number of attacks targeting them.

Observed Malicious Activities

Since January 15, 2024, Darktrace’s SOC and Threat Research team have observed a significant volume of malicious activities targeting customers’ Ivanti CS/PS appliances. Amongst the string of activities that were observed, the following threads were identified as salient:

  • Exploit validation activity
  • Exfiltration of system information
  • Delivery of C2 implant from AWS
  • Delivery of JavaScript credential stealer
  • SimpleHelp usage
  • Encrypted C2 on port 53
  • Delivery of cryptominer

Exploit Validation Activity

Malicious actors were observed using the out-of-band application security testing (OAST) services, Interactsh and Burp Collaborator, to validate exploits for CS/PS vulnerabilities. Malicious use of OAST services for exploit validation is common and has been seen in the early stages of previous campaigns targeting Ivanti systems [8]. In this case, the Interact[.]sh exploit tests were evidenced by CS/PS appliances making GET requests with a cURL User-Agent header to subdomains of 'oast[.]live', 'oast[.]site', 'oast[.]fun', 'oast[.]me', 'oast[.]online' and 'oast[.]pro'.  Burp Collaborator exploit tests were evidenced by CS/PS appliances making GET requests with a cURL User-Agent header to subdomains of ‘collab.urmcyber[.]xyz’ and ‘dnslog[.]store’.

Figure 1: Event Log showing a CS/PS appliance contacting an 'oast[.]pro' endpoint.
Figure 2: Event Log showing a CS/PS appliance contacting a 'collab.urmcyber[.]xyz' endpoint.
Figure 3: Packet capture (PCAP) of an Interactsh GET request.
Figure 4: PCAP of a Burp Collaborator GET request.

Exfiltration of System Information

The majority of compromised CS/PS appliances identified by Darktrace were seen using cURL to transfer hundreds of MBs of data to the external endpoint, 139.180.194[.]132. This activity appeared to be related to a threat actor attempting to exfiltrate system-related information from CS/PS appliances. These data transfers were carried out via HTTP on ports 443 and 80, with the Target URIs ‘/hello’ and ‘/helloq’ being seen in the relevant HTTP POST requests. The files sent over these data transfers were ‘.dat’ and ‘.sys’ files with what seems to be the public IP address of the targeted appliance appearing in each file’s name.

Figure 5: Event Log shows a CS/PS appliance making a POST request to 139.180.194[.]132 whilst simultaneously receiving connections from suspicious external endpoints.
Figure 6: PCAP of a POST request to 139.180.194[.]132.

Delivery of Command-and-Control (C2) implant from Amazon Web Services (AWS)

In many of the compromises observed by Darktrace, the malicious actor in question was observed delivering likely Rust-based ELF payloads to the CS/PS appliance from the AWS endpoints, archivevalley-media.s3.amazonaws[.]com, abode-dashboard-media.s3.ap-south-1.amazonaws[.]com, shapefiles.fews.net.s3.amazonaws[.]com, and blooming.s3.amazonaws[.]com. In one particular case, these downloads were immediately followed by the delivery of an 18 MB payload (likely a C2 implant) from the AWS endpoint, be-at-home.s3.ap-northeast-2.amazonaws[.]com, to the CS/PS appliance. Post-delivery, the implant seems to have initiated SSL beaconing connections to the external host, music.farstream[.]org. Around this time, Darktrace also observed the actor initiating port scanning and SMB enumeration activities from the CS/PS appliance, likely in preparation for moving laterally through the network.

Figure 7: Advanced Search logs showing a CS/PS appliance beaconing to music.farstream[.]org after downloading several payloads from AWS.

Delivery of JavaScript credential stealer

In a small number of observed cases, Darktrace observed malicious actors delivering what appeared to be a JavaScript credential harvester to targeted CS/PS appliances. The relevant JavaScript code contains instructions to send login credentials to likely compromised websites. In one case, the website, www.miltonhouse[.]nl, appeared in the code snippet, and in another, the website, cpanel.netbar[.]org, was observed. Following the delivery of this JavaScript code, HTTPS connections were observed to these websites.  This likely credential harvester appears to strongly resemble the credential stealer observed by Mandiant (dubbed ‘WARPWIRE’) in UNC5221 compromises and the credential stealer observed by Veloxity in UTA0178 compromises.

Figure 8: PCAP of ‘/3.js’ GET request for JavaScript credential harvester.
Figure 9: Snippet of response to '/3.js’ GET request.
Figure 10: PCAP of ‘/auth.js’ GET request for JavaScript credential harvester.
Figure 11: Snippet of response to '/auth.js’ GET request.
Figure 12: Advanced Search logs showing VPN-connected devices sending data to www.miltonhouse[.]nl after the Ivanti CS appliance received the JavaScript code.

The usage of this JavaScript credential harvester did not occur in isolation, but rather appears to have occurred as part of a chain of activity involving several further steps. The delivery of the ‘www.miltonhouse[.]nl’ JavaScript stealer seems to have occurred as a step in the following attack chain:  

1. Ivanti CS/PS appliance downloads a 8.38 MB ELF file over HTTP (with Target URI ‘/revsocks_linux_amd64’) from 188.116.20[.]38

2. Ivanti CS/PS appliance makes a long SSL connection (JA3 client fingerprint: 19e29534fd49dd27d09234e639c4057e) over port 8444 to 185.243.112[.]245, with several MBs of data being exchanged

3. Ivanti CS/PS appliance downloads a Perl script over HTTP (with Target URI ‘/login.txt’) from 188.116.20[.]38

4. Ivanti CS/PS appliance downloads a 1.53 ELF MB file over HTTP (with Target URI ‘/aparche2’) from 91.92.240[.]113

5. Ivanti CS/PS appliance downloads a 4.5 MB ELF file over HTTP (with Target URI ‘/agent’) from 91.92.240[.]113

6. Ivanti CS/PS appliance makes a long SSL connection (JA3 client fingerprint: 19e29534fd49dd27d09234e639c4057e) over port 11601 to 45.9.149[.]215, with several MBs of data being exchanged

7. Ivanti CS/PS appliance downloads Javascript credential harvester over HTTP (with Target URI ‘/auth.js’) from 91.92.240[.]113

8. Ivanti CS/PS appliance downloads a Perl script over HTTP (with Target URI ‘/login.cgi’) from 91.92.240[.]113

9. Ivanti CS/PS appliance makes a long SSL connection (JA3 client fingerprint: 19e29534fd49dd27d09234e639c4057e) over port 11601 to 91.92.240[.]71, with several MBs of data being exchanged

10. Ivanti CS/PS appliance makes a long SSL connection (JA3 client fingerprint: 19e29534fd49dd27d09234e639c4057e) over port 11601 to 45.9.149[.]215, with several MBs of data being exchanged

11. Ivanti CS/PS appliance makes a long SSL connection (JA3 client fingerprint: 19e29534fd49dd27d09234e639c4057e) over port 8080 to 91.92.240[.]113, with several MBs of data being exchanged

12. Ivanti CS/PS appliance makes a long SSL connection (JA3 client fingerprint: 19e29534fd49dd27d09234e639c4057e) over port 11601 to 45.9.149[.]112, with several MBs of data being exchanged  

These long SSL connections likely represent a malicious actor creating reverse shells from the targeted CS/PS appliance to their C2 infrastructure. Whilst it is not certain that these behaviors are part of the same attack chain, the similarities between them (such as the Target URIs, the JA3 client fingerprint and the use of port 11601) seem to suggest a link.  

Figure 13: Advanced Search logs showing a chain of malicious behaviours from a CS/PS appliance.
Figure 14: Advanced Search data showing the JA3 client fingerprint ‘19e29534fd49dd27d09234e639c4057e’ exclusively appearing in the aforementioned, long SSL connections from the targeted CS/PS appliance.
Figure 15: PCAP of ‘/login.txt’ GET request for a Perl script.
Figure 16: PCAP of ‘/login.cgi’ GET request for a Pearl script.

SimpleHelp Usage

After gaining a foothold on vulnerable CS/PS appliances, certain actors attempted to deepen their foothold within targeted networks. In several cases, actors were seen using valid account credentials to pivot over RDP from the vulnerable CS/PS appliance to other internal systems. Over these RDP connections, the actors appear to have installed the remote support tool, SimpleHelp, onto targeted internal systems, as evidenced by these systems’ subsequent HTTP requests. In one of the observed cases, a lateral movement target downloaded a 7.33 MB executable file over HTTP (Target URI: /ta.dat; User-Agent header: Microsoft BITS/7.8) from 45.9.149[.]215 just before showing signs of SimpleHelp usage. The apparent involvement of 45.9.149[.]215 in these SimpleHelp threads may indicate a connection between them and the credential harvesting thread outlined above.

Figure 17: Advanced Search logs showing an internal system making SimpleHelp-indicating HTTP requests immediately after receiving large volumes of data over RDP from an CS/PS appliance.
Figure 18: PCAP of a SimpleHelp-related GET request.

Encrypted C2 over port 53

In a handful of the recently observed CS/PS compromises, Darktrace identified malicious actors dropping a 16 MB payload which appears to use SSL-based C2 communication on port 53. C2 communication on port 53 is a commonly used attack method, with various malicious payloads, including Cobalt Strike DNS, being known to tunnel C2 communications via DNS requests on port 53. Encrypted C2 communication on port 53, however, is less common. In the cases observed by Darktrace, payloads were downloaded from 103.13.28[.]40 and subsequently reached back out to 103.13.28[.]40 over SSL on port 53.

Figure 19: PCAP of a ‘/linb64.png’ GET request.
Figure 20: Advanced Search logs showing a CS/PS appliance making SSL conns over port 53 to 103.13.28[.]40 immediately after downloading a 16 MB payload from 103.13.28[.]40.

Delivery of cryptominer

As is often the case, financially motivated actors also appeared to have sought to exploit the Ivanti appliances, with actors observed exploiting CS/PS appliances to deliver cryptomining malware. In one case, Darktrace observed an actor installing a Monero cryptominer onto a vulnerable CS/PS appliance, with the miner being downloaded via HTTP on port 8089 from 192.252.183[.]116.

Figure 21: PCAP of GET request for a Bash script which appeared to kill existing cryptominers.
Figure 22: PCAP of a GET request for a JSON config file – returned config file contains mining details such as ‘auto.3pool[.]org:19999’.
Figure 23: PCAP of a GET request for an ELF payload

Potential Pre-Ransomware Post-Compromise Activity

In one observed case, a compromise of a customer’s CS appliance was followed by an attacker using valid account credentials to connect to the customer’s CS VPN subnet. The attacker used these credentials to pivot to other parts of the customer’s network, with tools and services such as PsExec, Windows Management Instrumentation (WMI) service, and Service Control being abused to facilitate the lateral movement. Other Remote Monitoring and Management (RMM) tools, such as AnyDesk and ConnectWise Control (previously known as ScreenConnect), along with certain reconnaissance tools such as Netscan, Nmap, and PDQ, also appear to have been used. The attacker subsequently exfiltrated data (likely via Rclone) to the file storage service, put[.]io, potentially in preparation for a double extortion ransomware attack. However, at the time of writing, it was not clear what the relation was between this activity and the CS compromise which preceded it.

Darktrace Coverage

Darktrace has observed malicious actors carrying out a variety of post-exploitation activities on Internet-exposed CS/PS appliances, ranging from data exfiltration to the delivery of C2 implants and crypto-miners. These activities inevitably resulted in CS/PS appliances displaying patterns of network traffic greatly deviating from their typical “patterns of life”.

Darktrace DETECT™ identified these deviations and generated a variety of model breaches (i.e, alerts) highlighting the suspicious activity. Darktrace’s Cyber AI Analyst™ autonomously investigated the ongoing compromises and connected the individual model breaches, viewing them as related incidents rather than isolated events. When active and configured in autonomous response mode, Darktrace RESPOND™ containted attackers’ operations by autonomously blocking suspicious patterns of network traffic as soon as they were identified by Darktrace DETECT.

The exploit validation activities carried out by malicious actors resulted in CS/PS servers making HTTP connections with cURL User-Agent headers to endpoints associated with OAST services such as Interactsh and Burp Collaborator. Darktrace DETECT recognized that this HTTP activity was suspicious for affected devices, causing the following models to breach:

  • Compromise / Possible Tunnelling to Bin Services
  • Device / Suspicious Domain
  • Anomalous Server Activity / New User Agent from Internet Facing System
  • Device / New User Agent
Figure 24: Event Log showing a CS/PS appliance breaching models due to its Interactsh HTTP requests.
Figure 25: Cyber AI Analyst Incident Event highlighting a CS/PS appliance's Interactsh connections.

Malicious actors’ uploads of system information to 139.180.194[.]132 resulted in cURL POST requests being sent from the targeted CS/PS appliances. Darktrace DETECT judged these HTTP POST requests to be anomalous, resulting in combinations of the following model breaches:

  • Anomalous Connection / Posting HTTP to IP Without Hostname
  • Anomalous Server Activity / Outgoing from Server
  • Anomalous Server Activity / New User Agent from Internet Facing System
  • Unusual Activity / Unusual External Data Transfer
  • Unusual Activity / Unusual External Data to New Endpoint
  • Anomalous Connection / Data Sent to Rare Domain
Figure 26: Event Log showing the creation of a model breach due to a CS/PS appliance’s POST request to 139.180.194[.]132.
Figure 27: Cyber AI Analyst Incident Event highlighting POST requests from a CS/PS appliance to 139.180.194[.]132.

The installation of AWS-hosted C2 implants onto vulnerable CS/PS appliances resulted in beaconing connections which Darktrace DETECT recognized as anomalous, leading to the following model breaches:

  • Compromise / Beacon to Young Endpoint
  • Compromise / Beaconing Activity To External Rare
  • Compromise / High Volume of Connections with Beacon Score

When enabled in autonomous response mode, Darktrace RESPOND was able to follow up these detections by blocking affected devices from connecting externally over port 80, 443, 445 or 8081, effectively shutting down the attacker’s beaconing activity.

Figure 28: Event Log showing the creation of a model breach and the triggering of an autonomous RESPOND action due to a CS/PS appliance's beaconing connections.

The use of encrypted C2 on port 53 by malicious actors resulted in CS/PS appliances making SSL connections over port 53. Darktrace DETECT judged this port to be uncommon for SSL traffic and consequently generated the following model breach:

  • Anomalous Connection / Application Protocol on Uncommon Port
Figure 29: Cyber AI Analyst Incident Event highlighting a ‘/linb64.png’ GET request from a CS/PS appliance to 103.13.28[.]40.
Figure 30: Event Log showing the creation of a model breach due to CS/PS appliance’s external SSL connection on port 53.
Figure 31: Cyber AI Analyst Incident Event highlighting a CS/PS appliance’s SSL connections over port 53 to 103.13.28[.]40.

Malicious actors’ attempts to run cryptominers on vulnerable CS/PS appliances resulted in downloads of Bash scripts and JSON files from external endpoints rarely visited by the CS/PS appliances themselves or by neighboring systems. Darktrace DETECT identified these deviations in device behavior and generated the following model breaches:

  • Anomalous File / Script from Rare External Location
  • Anomalous File / Internet Facing System File Download

Darktrace RESPOND, when configured to respond autonomously, was subsequently able to carry out a number of actions to contain the attacker’s activity. This included blocking all outgoing traffic on offending devices and enforcing a “pattern of life” on devices ensuring they had to adhere to expected network behavior.

Figure 32: Event Log showing the creation of model breaches and the triggering of autonomous RESPOND actions in response to a CS/PS appliance’s cryptominer download.
Figure 33: Cyber AI Analyst Incident Event highlighting a CS/PS appliance’s cryptominer download.

The use of RDP to move laterally and spread SimpleHelp to other systems resulted in CS/PS appliances using privileged credentials to initiate RDP sessions. These RDP sessions, and the subsequent traffic resulting from usage of SimpleHelp, were recognized by Darktrace DETECT as being highly out of character, prompting the following model breaches:

  • Anomalous Connection / Unusual Admin RDP Session
  • Device / New User Agent
  • Anomalous Connection / New User Agent to IP Without Hostname
  • Compromise / Suspicious HTTP Beacons to Dotted Quad
  • Anomalous File / Anomalous Octet Stream (No User Agent)
  • Anomalous Server Activity / Rare External from Server
Figure 34: Event Log showing the creation of a model breach due to a CS/PS appliance’s usage of an admin credential to RDP to another internal system.
Figure 35: Event Log showing the creation of model breaches due to SimpleHelp-HTTP requests from a device targeted for lateral movement.
Figure 36: Cyber AI Analyst Incident Event highlighting the SimpleHelp-indicating HTTP requests made by an internal system.

Conclusion

The recent widespread exploitation of Ivanti CS/PS is a stark reminder of the threat posed by malicious actors armed with exploits for Internet-facing assets.

Based on the telemetry available to Darktrace, a wide range of malicious activities were carried out against CS/PS appliances, likely via exploitation of the recently disclosed CVE-2023-46805 and CVE-2024-21887 vulnerabilities.

These activities include the usage of OAST services for exploit validation, the exfiltration of system information to 139.180.194[.]132, the delivery of AWS-hosted C2 implants, the delivery of JavaScript credential stealers, the usage of SimpleHelp, the usage of SSL-based C2 on port 53, and the delivery of crypto-miners. These activities are far from exhaustive, and many more activities will undoubtedly be uncovered as the situation develops and our understanding grows.

While there were no patches available at the time of writing, Ivanti stated that they were expected to be released shortly, with the “first version targeted to be available to customers the week of 22 January 2023 and the final version targeted to be available the week of 19 February” [9].

Fortunately for vulnerable customers, in their absence of patches Darktrace DETECT was able to identify and alert for anomalous network activity that was carried out by malicious actors who had been able to successfully exploit the Ivanti CS and PS vulnerabilities. While the activity that followed these zero-day vulnerabilities may been able to have bypass traditional security tools reliant upon existing threat intelligence and indicators of compromise (IoCs), Darktrace’s anomaly-based approach allows it to identify such activity based on the subtle deviations in a devices behavior that typically emerge as threat actors begin to work towards their goals post-compromise.

In addition to Darktrace’s ability to identify this type of suspicious behavior, its autonomous response technology, Darktrace RESPOND is able to provide immediate follow-up with targeted mitigative actions to shut down malicious activity on affected customer environments as soon as it is detected.

Credit to: Nahisha Nobregas, SOC Analyst, Emma Foulger, Principle Cyber Analyst, and the Darktrace Threat Research Team

Appendices

List of IoCs Possible IoCs:

-       curl/7.19.7 (i686-redhat-linux-gnu) libcurl/7.63.0 OpenSSL/1.0.2n zlib/1.2.3

-       curl/7.19.7 (i686-redhat-linux-gnu) libcurl/7.63.0 OpenSSL/1.0.2n zlib/1.2.7

Mid-high confidence IoCs:

-       http://139.180.194[.]132:443/hello

-       http://139.180.194[.]132:443/helloq

-       http://blooming.s3.amazonaws[.]com/Ea7fbW98CyM5O (SHA256 hash: 816754f6eaf72d2e9c69fe09dcbe50576f7a052a1a450c2a19f01f57a6e13c17)

-       http://abode-dashboard-media.s3.ap-south-1.amazonaws[.]com/kaffMm40RNtkg (SHA256 hash: 47ff0ae9220a09bfad2a2fb1e2fa2c8ffe5e9cb0466646e2a940ac2e0cf55d04)

-       http://archivevalley-media.s3.amazonaws[.]com/bbU5Yn3yayTtV (SHA256 hash: c7ddd58dcb7d9e752157302d516de5492a70be30099c2f806cb15db49d466026)

-       http://shapefiles.fews.net.s3.amazonaws[.]com/g6cYGAxHt4JC1 (SHA256 hash: c26da19e17423ce4cb4c8c47ebc61d009e77fc1ac4e87ce548cf25b8e4f4dc28)

-       http://be-at-home.s3.ap-northeast-2.amazonaws[.]com/2ekjMjslSG9uI

-       music.farstream[.]org  • 104.21.86[.]153 / 172.67.221[.]78

-       http://197.243.22[.]27/3.js

-       http://91.92.240[.]113/auth.js

-       www.miltonhouse[.]nl • 88.240.53[.]22

-       cpanel.netbar[.]org • 146.19.212[.]12

-       http://188.116.20[.]38/revsocks_linux_amd64

-       185.243.112[.]245:8444

-        http://188.116.20[.]38/login.txt

-       http://91.92.240[.]113/aparche2 (SHA256 hash: 9d11c3cf10b20ff5b3e541147f9a965a4e66ed863803c54d93ba8a07c4aa7e50)

-       http://91.92.240[.]113/agent (SHA256 hash: 7967def86776f36ab6a663850120c5c70f397dd3834f11ba7a077205d37b117f)

-       45.9.149[.]215:11601

-       45.9.149[.]112:11601

-       http://91.92.240[.]113/login.cgi

-       91.92.240[.]71:11601

-       91.92.240[.]113:8080

-       http://45.9.149[.]215/ta.dat (SHA256 hash: 4bcf1333b3ad1252d067014c606fb3a5b6f675f85c59b69ca45669d45468e923)

-       91.92.241[.]18

-       94.156.64[.]252

-       http://144.172.76[.]76/lin86

-       144.172.122[.]14:443

-       http://185.243.115[.]58:37586/

-       http://103.13.28[.]40/linb64.png

-       103.13.28[.]40:53

-       159.89.82[.]235:8081

-       http://192.252.183[.]116:8089/u/123/100123/202401/d9a10f4568b649acae7bc2fe51fb5a98.sh

-       http://192.252.183[.]116:8089/u/123/100123/202401/sshd

-       http://192.252.183[.]116:8089/u/123/100123/202401/31a5f4ceae1e45e1a3cd30f5d7604d89.json

-       http://103.27.110[.]83/module/client_amd64

-       http://103.27.110[.]83/js/bootstrap.min.js?UUID=...

-       http://103.27.110[.]83/js/jquery.min.js

-       http://95.179.238[.]3/bak

-       http://91.92.244[.]59:8080/mbPHenSdr6Cf79XDAcKEVA

-       31.220.30[.]244

-       http://172.245.60[.]61:8443/SMUkbpX-0qNtLGsuCIuffAOLk9ZEBCG7bIcB2JT6GA/

-       http://172.245.60[.]61/ivanti

-       http://89.23.107[.]155:8080/l-5CzlHWjkp23gZiVLzvUg

-       http://185.156.72[.]51:8080/h7JpYIZZ1-rrk98v3YEy6w

-       http://185.156.72[.]51:8080/8uSQsOTwFyEAsXVwbAJ2mA

-       http://185.156.72[.]51:8080/vuln

-       185.156.72[.]51:4440

-       185.156.72[.]51:8080

-       185.156.72[.]51:4433

-       185.156.72[.]51:4446

-       185.156.72[.]51:4445

-       http://185.156.72[.]51/set.py

-       185.156.72[.]51:7777

-       45.9.151[.]107:7070

-       185.195.59[.]74:7070

-       185.195.59[.]74:20958

-       185.195.59[.]74:34436

-       185.195.59[.]74:37464

-       185.195.59[.]74:41468    

References

[1] https://forums.ivanti.com/s/article/CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US

[2] https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US

[3] https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/

[4] https://www.mandiant.com/resources/blog/suspected-apt-targets-ivanti-zero-day

[5] https://www.greynoise.io/blog/ivanti-connect-secure-exploited-to-install-cryptominers

[6] https://www.volexity.com/blog/2024/01/18/ivanti-connect-secure-vpn-exploitation-new-observations/

[7] https://censys.com/the-mass-exploitation-of-ivanti-connect-secure/

[8] https://darktrace.com/blog/entry-via-sentry-analyzing-the-exploitation-of-a-critical-vulnerability-in-ivanti-sentry

[9] https://forums.ivanti.com/s/article/CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US  

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Sam Lister
SOC Analyst

More in this series

No items found.

Blog

/

Email

/

May 29, 2025

Why attack-centric approaches to email security can’t cope with modern threats

Default blog imageDefault blog image

What’s the problem with an attack-centric mindset?

For decades, traditional email security strategies have been built around an attack-centric mindset. Secure Email Gateways (SEGs) and other legacy solutions operate on the principle of identifying and blocking known threats. These systems rely heavily on predefined threat intelligence – blacklists, malware signatures, and reputation-based analysis – to filter out malicious content before it reaches the inbox.

While this approach was sufficient when email threats were relatively static and signature-based, it’s increasingly ineffective against the sophistication of modern attacks. Techniques like spear phishing, business email compromise (BEC), and supply chain attacks often bypass traditional SEG defenses because they lack obvious malicious indicators. Instead, they leverage social engineering, look-alike domains, and finely tuned spoofing tactics that are designed to evade detection.

The challenge extends beyond just legacy SEGs. Many modern email security providers have inherited the same attack-centric principles, even if they've reimagined the technology stack. While some vendors have shifted to API-based deployments and incorporated AI to automate pattern recognition, the underlying approach remains the same: hunting for threats based on known indicators. This methodology, though it’s undergone modernization using AI, still leaves gaps when it comes to novel, hyper-targeted threats that manipulate user behavior rather than deploy predictable malicious signatures. Attack-centric security will always remain one step behind the attacker.

By the way, native email security already covers the basics

One of the most overlooked realities in email security is that native solutions like Microsoft 365’s built-in security already handle much of the foundational work of attack-centric protection. Through advanced threat intelligence, anti-phishing measures, and malware detection, Microsoft 365 actively scans incoming emails for known threats, using global telemetry to identify patterns and block suspicious content before it even reaches the user’s inbox.

This means that for many organizations, a baseline level of protection against more obvious, signature-based attacks is already in place – but many are still disabling these protections in favour of another attack-centric solution. By layering another attack-centric solution on top, they are effectively duplicating efforts without enhancing their security posture. This overlap can lead to unnecessary complexity, higher costs, and a false sense of enhanced protection when in reality, it’s more of the same.

Rather than duplicating attack-centric protections, the real opportunity lies in addressing the gaps that remain: the threats that are specifically crafted to evade traditional detection methods. This is where a business-centric approach becomes indispensable, complementing the foundational security that’s already built into your infrastructure.

Introducing… the business-centric approach

To effectively defend against advanced threats, organizations need to adopt a business-centric approach to email security. Unlike attack-centric models that hunt for known threats, business-centric security focuses on understanding the typical behaviors, relationships, and communication patterns within your organization. Rather than solely reacting to threats as they are identified, this model continuously learns what “normal” looks like for each user and each inbox.

By establishing a baseline of expected behaviors, business-centric solutions can rapidly detect anomalies that suggest compromise, such as sudden changes in sending patterns, unusual login locations, or subtle shifts in communication tone. This proactive detection method is especially powerful against spear phishing, business email compromise (BEC), and supply chain attacks that are engineered to bypass static defenses. This approach also scales with your organization, learning and adapting as new users are onboarded, communication patterns evolve, and external partners are added.

In an era where AI-driven threats are becoming the norm, having email security that knows your users and inboxes better than the attacker does is a critical advantage.

Why native + business-centric email security is the winning formula

By pairing native security with a business-centric model, organizations can cover the full spectrum of threats – from signature-based malware to sophisticated, socially engineered attacks. Microsoft 365’s in-built security manages the foundational risks, while business-centric defense identifies subtle anomalies and targeted threats that legacy approaches miss.

Layering Darktrace on top of your native Microsoft security eliminates duplicate capabilities, costs and workflows without reducing functionality

Rather than layering redundant attack-centric solutions on top of existing protections, the future of email security lies in leveraging what’s already in place and building on it with smarter, behavior-based detection. The Swiss Cheese Model is a useful one to refer to here: by acknowledging that no single defense can offer complete protection, layering defenses that plug each other’s gaps – like slices of Swiss cheese – becomes critical.

This combination also allows security teams to focus their efforts more effectively. With native solutions catching broad-based, known threats, the business-centric layer can prioritize real anomalies, minimizing false positives and accelerating response times. Organizations benefit from reduced overlap, streamlined costs, and a stronger overall security posture.

Download the full guide to take the first step towards achieving your next-generation security stack.

[related-resource]

Continue reading
About the author
Carlos Gray
Senior Product Marketing Manager, Email

Blog

/

Network

/

May 30, 2025

PumaBot: Novel Botnet Targeting IoT Surveillance Devices

password login screen on computerDefault blog imageDefault blog image

Introduction: PumaBot attacking IoT devices

Darktrace researchers have identified a custom Go-based Linux botnet named “PumaBot” targeting embedded Linux Internet of Things (IoT) devices. Rather than scanning the Internet, the malware retrieves a list of targets from a command-and-control (C2) server and attempts to brute-force SSH credentials. Upon gaining access, it receives remote commands and establishes persistence using system service files. This blog post provides a breakdown of its key functionalities, and explores binaries related to the campaign.

Technical Analysis

Filename: jierui

md5: cab6f908f4dedcdaedcdd07fdc0a8e38

The Go-based botnet gains initial access through brute-forcing SSH credentials across a list of harvested IP addresses. Once it identifies a valid credential pair, it logs in, deploys itself, and begins its replication process.

Overview of Jierui functions
Figure 1: Overview of Jierui functions.

The domain associated with the C2 server did not resolve to an IP address at the time of analysis. The following details are a result of static analysis of the malware.

The malware begins by retrieving a list of IP addresses of likely devices with open SSH ports from the C2 server (ssh.ddos-cc[.]org) via the getIPs() function. It then performs brute-force login attempts on port 22 using credential pairs also obtained from the C2 through the readLinesFromURL(), brute(), and trySSHLogin() functions.

Within trySSHLogin(), the malware performs several environment fingerprinting checks. These are used to avoid honeypots and unsuitable execution environments, such as restricted shells. Notably, the malware checks for the presence of the string “Pumatronix”, a manufacturer of surveillance and traffic camera systems, suggesting potential IoT targeting or an effort to evade specific devices [1].

Fingerprinting of “Pumatronix”.
Figure 2: Fingerprinting of “Pumatronix”.

If the environment passes these checks, the malware executes uname -a to collect basic system information, including the OS name, kernel version, and architecture. This data, along with the victim's IP address, port, username, and password, is then reported back to the C2 in a JSON payload.

Of note, the bot uses X-API-KEY: jieruidashabi, within a custom header when it communicates with the C2 server over HTTP.

The malware writes itself to /lib/redis, attempting to disguise itself as a legitimate Redis system file. It then creates a persistent systemd service in /etc/systemd/system, named either redis.service or mysqI.service (note the spelling of mysql with a capital I) depending on what has been hardcoded into the malware. This allows the malware to persist across reboots while appearing benign.

[Unit]
Description=redis Server Service

[Service]
Type=simple
Restart=always
RestartSec=1
User=root
ExecStart=/lib/redis e

[Install]
WantedBy=multi-user.target

In addition to gaining persistence with a systemd service, the malware also adds its own SSH keys into the users’ authorized_keys file. This ensures that access can be maintained, even if the service is removed.

A function named cleankill() contains an infinite loop that repeatedly attempts to execute the commands “xmrig” and “networkxm”. These are launched without full paths, relying on the system's PATH variable suggesting that the binaries may be downloaded or unpacked elsewhere on the system. The use of “time.Sleep” between attempts indicates this loop is designed to ensure persistence and possibly restart mining components if they are killed or missing.

During analysis of the botnet, Darktrace discovered related binaries that appear to be part of a wider campaign targeting Linux systems.

Filename: ddaemon
Md5: 48ee40c40fa320d5d5f8fc0359aa96f3

Ddaemon is a Go-based backdoor. The malware begins by parsing command line arguments and if conditions are met, enters a loop where it periodically verifies the MD5 hash of the binary. If the check fails or an update is available, it downloads a new version from a C2 server (db.17kp[.]xyz/getDdaemonMd5), verifies it and replaces the existing binary with a file of the same name and similar functionality (8b37d3a479d1921580981f325f13780c).

The malware uses main_downloadNetwork() to retrieve the binary “networkxm” into /usr/src/bao/networkxm. Additionally, the bash script “installx.sh” is also retrieved from the C2 and executed. The binary ensures persistence by writing a custom systemd service unit that auto starts on boot and executes ddaemon.

Filename: networkxm
Md5: be83729e943d8d0a35665f55358bdf88

The networkxm binary functions as an SSH brute-force tool, similar to the botnet. First it checks its own integrity using MD5 hashes and contacts the C2 server (db.17kp[.]xyz) to compare its hash with the latest version. If an update is found, it downloads and replaces itself.

Part of networkxm checking MD5 hash.
Figure 3: Part of networkxm checking MD5 hash.
MD5 hash
Figure 4: MD5 hash

After verifying its validity, it enters an infinite loop where it fetches a password list from the C2 (/getPassword), then attempts SSH connections across a list of target IPs from the /getIP endpoint. As with the other observed binaries, a systemd service is created if it doesn’t already exist for persistence in /etc/systemd/system/networkxm.service.

Bash script installx.sh.
Figure 5: Bash script installx.sh.

Installx.sh is a simple bash script used to retrieve the script “jc.sh” from 1.lusyn[.]xyz, set permissions, execute and clear bash history.

Figure 6: Snippet of bash script jc.sh.

The script jc.sh starts by detecting the operating system type Debian-based or Red Hat-based and determines the location of the pam_unix.so file. Linux Pluggable Authentication Modules (PAM) is a framework that allows for flexible and centralized user authentication on Linux systems. PAM allows system administrators to configure how users are authenticated for services like login, SSH, or sudo by plugging in various authentication modules.

Jc.sh then attempts to fetch the current version of PAM installed on the system and formats that version to construct a URL. Using either curl or wget, the script downloads a replacement pam_unix.so file from a remote server and replaces the existing one, after disabling file immutability and backing up the original.

The script also downloads and executes an additional binary named “1” from the same remote server. Security settings are modified including enabling PAM in the SSH configuration and disabling SELinux enforcement, before restarting the SSH service. Finally, the script removes itself from the system.

Filename: Pam_unix.so_v131
md5: 1bd6bcd480463b6137179bc703f49545

Based on the PAM version that is retrieved from the bash query, the new malicious PAM replaces the existing PAM file. In this instance, pam_unix.so_v131 was retrieved from the server based on version 1.3.1. The purpose of this binary is to act as a rootkit that steals credentials by intercepting successful logins. Login data can include all accounts authenticated by PAM, local and remote (SSH). The malware retrieves the logged in user, the password and verifies that the password is valid. The details are stored in a file “con.txt” in /usr/bin/.

Function storing logins to con.txt
Figure 7: Function storing logins to con.txt

Filename: 1

md5: cb4011921894195bcffcdf4edce97135

In addition to the malicious PAM file, a binary named “1” is also retrieved from the server http://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/jc/1. The binary “1” is used as a watcher for the malicious PAM file using inotify to monitor for “con.txt” being written or moved to /usr/bin/.

Following the daemonize() function, the binary is run daemonized ensuring it runs silently in the background. The function read_and_send_files() is called which reads the contents of “/usr/bin/con.txt”, queries the system IP with ifconfig.me, queries SSH ports and sends the data to the remote C2 (http://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/api/).

Command querying SSH ports.
Figure 8: Command querying SSH ports.

For persistence, a systemd service (my_daemon.service) is created to autostart the binary and ensure it restarts if the service has been terminated. Finally, con.txt is deleted, presumably to remove traces of the malware.

Conclusion

The botnet represents a persistent Go-based SSH threat that leverages automation, credential brute-forcing, and native Linux tools to gain and maintain control over compromised systems. By mimicking legitimate binaries (e.g., Redis), abusing systemd for persistence, and embedding fingerprinting logic to avoid detection in honeypots or restricted environments, it demonstrates an intent to evade defenses.

While it does not appear to propagate automatically like a traditional worm, it does maintain worm-like behavior by brute-forcing targets, suggesting a semi-automated botnet campaign focused on device compromise and long-term access.

[related-resource]

Recommendations

  1. Monitor for anomalous SSH login activity, especially failed login attempts across a wide IP range, which may indicate brute-force attempts.
  2. Audit systemd services regularly. Look for suspicious entries in /etc/systemd/system/ (e.g., misspelled or duplicate services like mysqI.service) and binaries placed in non-standard locations such as /lib/redis.
  3. Inspect authorized_keys files across user accounts for unknown SSH keys that may enable unauthorized access.
  4. Filter or alert on outbound HTTP requests with non-standard headers, such as X-API-KEY: jieruidashabi, which may indicate botnet C2 communication.
  5. Apply strict firewall rules to limit SSH exposure rather than exposing port 22 to the internet.

Appendices

References

1.     https://pumatronix.com/

Indicators of Compromise (IoCs)

Hashes

cab6f908f4dedcdaedcdd07fdc0a8e38 - jierui

a9412371dc9247aa50ab3a9425b3e8ba - bao

0e455e06315b9184d2e64dd220491f7e - networkxm

cb4011921894195bcffcdf4edce97135 - 1
48ee40c40fa320d5d5f8fc0359aa96f3 - ddaemon
1bd6bcd480463b6137179bc703f49545 - pam_unix.so_v131

RSA Key

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0tH30Li6Gduh0Jq5A5dO5rkWTsQlFttoWzPFnGnuGmuF+fwIfYvQN1z+WymKQmX0ogZdy/CEkki3swrkq29K/xsyQQclNm8+xgI8BJdEgTVDHqcvDyJv5D97cU7Bg1OL5ZsGLBwPjTo9huPE8TAkxCwOGBvWIKUE3SLZW3ap4ciR9m4ueQc7EmijPHy5qds/Fls+XN8uZWuz1e7mzTs0Pv1x2CtjWMR/NF7lQhdi4ek4ZAzj9t/2aRvLuNFlH+BQx+1kw+xzf2q74oBlGEoWVZP55bBicQ8tbBKSN03CZ/QF+JU81Ifb9hy2irBxZOkyLN20oSmWaMJIpBIsh4Pe9 @root

Network

http://ssh[.]ddos-cc.org:55554

http://ssh[.]ddos-cc.org:55554/log_success

http://ssh[.]ddos-cc.org:55554/get_cmd

http://ssh[.]ddos-cc.org:55554/pwd.txt

https://dow[.]17kp.xyz/

https://input[.]17kp.xyz/

https://db[.]17kp[.]xyz/

http://1[.]lusyn[.]xyz

http://1[.]lusyn[.]xyz/jc/1

http://1[.]lusyn[.]xyz/jc/jc.sh

http://1[.]lusyn[.]xyz/jc/aa

http://1[.]lusyn[.]xyz/jc/cs

http://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/api

http://dasfsdfsdfsdfasfgbczxxc[.]lusyn[.]xyz/jc

Detection Rule

rule Linux_PumaBot

{

  meta:

      description = "Rule to match on PumaBot samples"

      author = "tgould@cadosecurity.com"

  strings:

      $xapikey = "X-API-KEY" ascii

      $get_ips = "?count=5000" ascii

      $exec_start = "ExecStart=/lib/redis" ascii

      $svc_name1 = "redis.service" ascii

      $svc_name2 = "mysqI.service" ascii

      $uname = "uname -a" ascii

      $pumatronix = "Pumatronix" ascii

  condition:

      uint32(0) == 0x464c457f and

      all of (

          $xapikey,

          $uname,

          $get_ips,

          $exec_start

      ) and any of (

          $svc_name1,

          $svc_name2

      ) and $pumatronix

}

Continue reading
About the author
Tara Gould
Threat Researcher
Your data. Our AI.
Elevate your network security with Darktrace AI