On January 10, 2024, Volexity reported an active exploitation of two zero-day vulnerabilities in Ivanti VPN devices. The 9.x, 22.x versions of Connect Secure (ICS), also known as Pulse Connect Secure and Ivanti Policy Secure gateways are affected by the CVE-2023-46805 and the CVE-2024-21887.
While the CVE-2023-46805 allows for Authentication Bypass in the web component of Ivanti Connect Secure (ICS), the CVE-2024-21887 is a command injection vulnerability. As the exploitation of these two combined vulnerabilities allow for remote execution across the VPN devices, it represents a serious risk of compromission, including keylogging, configuration data exfiltration, existing files modification, reverse tunnel enabling from the Virtual Private Network (VPN) appliance, and so on.
Source: Volexity
How the Incident and the Forensics analysis revealed the attack chain
During the second week of December 2023, Volexity detected suspicious lateral movement on the network of one of his customers. During their analysis, the Volexity Incident responders found webshells on multiple internal and external-facing web servers. Their incident response investigation revealed that the logs of the Ivanti VPN appliances had been wiped and their logging features had been disabled. After analyzing suspicious inbound and outbound communications from its management IP address, Volexity found that this activity originated from the device itself.
Following an acquisition of disk and memory images, the forensic examination of the gathered data revealed valuable information about the attacker’s tools, malware, and operating methods. This forensics analysis uncovered two zero-day vulnerabilities, and allowed Volexity to discover the timeline of the attack and recreate two proof-of-concept exploits. Moreover, based on the tools and techniques used, such as the GLASSTOKEN webshell and specific credential harvesting techniques, Volexity attributes this attack to an unknown threat actor it tracks under the alias UTA0178.
MITRE ATT&CK
- T1056.001 – Keylogging
- T1068 – Privilege Escalation
- T1021 – Lateral Movement
- T1212 – Credential Access
- T1211 – Defense Evasion
- T1003 – Credential Access
- T1005 – Collection
- T1056 – Collection, Credential Access
- T1002 – Defense Evasion
IOCs
IP addresses and hostnames
| Value | Entity type | Description |
|---|---|---|
| 206.189.208.156 | ipaddress | DigitalOcean IP address tied to UTAO178 |
| gpoaccess[.]com | hostname | Suspected UTA0178 domain discovered via domain registration patterns |
| webb-institute[.]com | hostname | Suspected UTA0178 domain discovered via domain registration patterns |
| symantke[.]com | hostname | UTAO178 domain used to collect credentials from compromised devices |
| 75.145.243.85 | ipaddress | UTA0178 IP address observed interacting with compromised devices |
| 47.207.9.89 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 98.160.48.170 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 173.220.106.166 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 73.128.178.221 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 50.243.177.161 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 50.213.208.89 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 64.24.179.210 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 75.145.224.109 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 50.215.39.49 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 71.127.149.194 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
| 173.53.43.7 | ipaddress | UTA0178 IP address tied to Cyberoam proxy network |
Yara Rule
The Yara rule is available here.
Conclusion and Remediation steps
So, what should you do now?
Volexity said: “It is critically important that organizations immediately apply the available mitigation from Ivanti and the patch that will follow. However, applying mitigations and patches will not resolve past compromise. It is important that organizations running ICS VPN appliances review their logs, network telemetry, and Integrity Checker Tool results (past and present) to look for any signs of successful compromise.”
Wiped logs and disabled log features are an easy to check and solid indication of compromise of the appliance. Also, Integrity Checker should return only SYS32100 events. If the integrity checker returns events such as SYS32039 and SYS32040, the chances are very high that the appliance is compromised.
Mitigation actions can also be taken at the firewall level by denying traffic coming and going from/to the known IP IOCs. Appliances that are not used or with very low legit traffic should be disabled.
Ivanti Remediation steps (source: Ivanti)
If exploitation has occurred, we believe it is likely that the threat actor has taken an export of your running configurations at time of exploit and left behind a Web shell file enabling backdoor future access. The mitigation we have provided blocks both the vulnerabilities and the webshell currently being used in the post-advisory activity we are currently tracking. We highly recommend doing the following:
- Backup the configuration of the appliance
- Factory reset the appliance
- Once factory reset is complete, upgrade the appliance to the same version that you were running prior to factory reset.
- Restore the appliance configuration from backup
- Revoke and reissue any stored certs that were on the appliance(s) impacted
- Reset the admin enable password
- Reset API keys stored on the appliance
- Reset the password of any local user defined on the gateway
- Reset license server credentials
ELCASecurity and Senthorus continue to monitor the situation and are fully available to their customers for technical support and incident response if necessary.