{
	"id": "93e6a3d9-37b6-4c32-852b-b7f235a2b187",
	"created_at": "2026-04-06T00:20:15.300393Z",
	"updated_at": "2026-04-10T03:30:33.059939Z",
	"deleted_at": null,
	"sha1_hash": "e42ea09a81cc35cccd432370e49a6504d308f698",
	"title": "Active Exploitation of Two Zero-Day Vulnerabilities in Ivanti Connect Secure VPN",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 667172,
	"plain_text": "Active Exploitation of Two Zero-Day Vulnerabilities in Ivanti\r\nConnect Secure VPN\r\nBy mindgrub\r\nPublished: 2024-01-10 · Archived: 2026-04-05 13:56:28 UTC\r\nVolexity has uncovered active in-the-wild exploitation of two vulnerabilities allowing unauthenticated remote\r\ncode execution in Ivanti Connect Secure VPN devices. An official security advisory and knowledge base article\r\nhave been released by Ivanti that includes mitigation that should be applied immediately. However, a mitigation\r\ndoes not remedy a past or ongoing compromise. Systems should simultaneously be thoroughly analyzed per\r\ndetails in this post to look for signs of a breach.\r\nDuring the second week of December 2023, Volexity detected suspicious lateral movement on the network of one\r\nof its Network Security Monitoring service customers. Upon closer inspection, Volexity found that an attacker was\r\nplacing webshells on multiple internal and external-facing web servers. These detections kicked off an incident\r\nresponse investigation across multiple systems that Volexity ultimately tracked back to the organization’s Internet-facing Ivanti Connect Secure (ICS) VPN appliance (formerly known as Pulse Connect Secure, or simply Pulse\r\nSecure). A closer inspection of the ICS VPN appliance showed that its logs had been wiped and logging had been\r\ndisabled. Further review of historic network traffic from the device also revealed suspect outbound and inbound\r\ncommunication from its management IP address. Volexity found that there was suspect activity originating from\r\nthe device as early as December 3, 2023.\r\nAt this point in its incident response investigation, Volexity suspected a zero-day exploit was likely at play but did\r\nnot yet have enough evidence to support this theory. Volexity and its customer worked closely with Ivanti in order\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 1 of 11\n\nto obtain disk and memory images from the impacted devices. Forensic analysis of the collected data provided\r\ninsight into a variety of the attacker’s tools, malware, and methods for operating.\r\nMost notably, Volexity analyzed one of the collected memory samples and uncovered the exploit chain used by the\r\nattacker. Volexity discovered two different zero-day exploits which were being chained together to achieve\r\nunauthenticated remote code execution (RCE). Through forensic analysis of the memory sample, Volexity was\r\nable to recreate two proof-of-concept exploits that allowed full unauthenticated command execution on the ICS\r\nVPN appliance. These two vulnerabilities have been assigned the following CVEs:\r\nCVE-2023-46805 – an authentication-bypass vulnerability with a CVSS score of 8.2\r\nCVE-2024-21887 – a command-injection vulnerability found into multiple web components with a CVSS\r\nscore of 9.1\r\nWhen combined, these two vulnerabilities make it trivial for attackers to run commands on the system. In this\r\nparticular incident, the attacker leveraged these exploits to steal configuration data, modify existing files,\r\ndownload remote files, and reverse tunnel from the ICS VPN appliance. Volexity observed the attacker modifying\r\nlegitimate ICS components and making changes to the system to evade the ICS Integrity Checker Tool. Notably,\r\nVolexity observed the attacker backdooring a legitimate CGI file ( compcheckresult.cgi ) on the ICS VPN\r\nappliance to allow command execution. Further, the attacker also modified a JavaScript file used by the Web SSL\r\nVPN component of the device in order to keylog and exfiltrate credentials for users logging into it. The\r\ninformation and credentials collected by the attacker allowed them to pivot to a handful of systems internally, and\r\nultimately gain unfettered access to systems on the network.\r\nThis blog post covers key findings from Volexity’s forensic analysis and incident response investigation, as well as\r\nadvice for detecting successful exploitation. Volexity currently attributes this activity to an unknown threat actor it\r\ntracks under the alias UTA0178. Volexity has reason to believe that UTA0178 is a Chinese nation-state-level\r\nthreat actor.\r\nIncident Investigation\r\nVolexity’s customer has permitted the sharing of this incident investigation in order to shed light on the attacker’s\r\nactions and potentially assist other organizations in jump-starting their investigations. Volexity used telemetry\r\nfrom its own Network Security Sensors, client EDR software, and forensic data collected from multiple systems to\r\npaint a thorough picture of the attacker’s actions. As noted, Volexity’s investigation did not start with the ICS VPN\r\nappliance, but both forensic and network traffic analysis quickly led to that device. This allowed Volexity to zero\r\nin and scrutinize activity associated with the ICS VPN appliance.\r\nBelow are the highlights of Volexity’s observations when analyzing network traffic from ICS VPN appliances\r\nover the course of this incident:\r\nOutbound connections via curl to an IP Geolocation service via ip-api[.]com and to Cloudflare’s 1.1.1.1 IP\r\naddress on multiple occasions\r\nReverse SOCKS proxy and SSH tunnel connections back through compromised Cyberoam appliances\r\nDownload of tooling from a compromised Cyberoam appliance\r\nReconnaissance of internal websites through proxied connections\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 2 of 11\n\nLateral movement using compromised credentials to connect to internal systems via RDP, SMB, and SSH\r\nTransfer of multiple webshell variants, which Volexity calls GLASSTOKEN, to Internet-accessible web\r\nservers and systems that were only internally accessible.\r\nOnce the ICS VPN appliance had been identified as compromised, Volexity collected key evidence from it. This\r\nincluded data collected from the device using the Integrity Checking Tool Ivanti provides to identify mismatched\r\nfiles on the device. Customers are encouraged to open a support ticket with Ivanti in the event they see any signs\r\nof compromise, including new or mismatched files as identified by the Integrity Checker Tool. Volexity worked\r\nclosely with Ivanti to obtain a decrypted version of the snapshot produced by the Integrity Checker Tool, as well\r\nas memory and disk images. Over the course of the incident, Volexity obtained multiple memory and disk images\r\nfrom multiple devices.\r\nVolexity used a combination of memory and disk forensics, combined with the results of the Integrity Checker\r\nTool, to quickly zero in on multiple malicious files placed on the compromised Ivanti Connect Secure VPN\r\nappliance. Below is a list of key files Volexity identified*.\r\nFilename Description Purpose\r\n/home/perl/DSLogConfig.pm Modified Perl module\r\nDesigned to\r\nexecute  sessionserver.pl\r\n/home/etc/sql/dsserver/sessionserver.pl\r\nPerl script to remount\r\nthe filesystem with\r\nread/write access\r\nMake  sessionserver.sh\r\nexecutable, execute it, then restore\r\noriginal mount settings\r\n/home/etc/sql/dsserver/sessionserver.sh\r\nScript executed\r\nby  sessionserver.pl\r\nUses regular expressions to\r\nmodifycompcheckresult.cgito\r\ninsert a webshell into it; also\r\ncreates a series of entries into files\r\nassociated with the In-build\r\nIntegrity Checker Tool to evade\r\ndetection when periodic scans are\r\nrun\r\n/home/webserver/htdocs/dana-na/auth/compcheckresult.cgi\r\nModified legitimate\r\ncomponent of the ICS\r\nVPN appliance, with\r\nnew Perl module\r\nimports added and a\r\none-liner to execute\r\ncommands based on\r\nrequest parameters\r\nAllows remote code execution\r\nover the Internet if the attacker\r\ncan craft a requests with the\r\ncorrect parameters\r\n/home/webserver/htdocs/dana-na/auth/lastauthserverused.jsModified legitimate\r\nJavaScript component\r\nModified to harvest entered\r\ncredentials and send them to a\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 3 of 11\n\nFilename Description Purpose\r\nloaded by user login\r\npage of the Web SSL\r\nVPN component of\r\nICS\r\nremote URL on an attacker-controlled domain\r\n*Analysis of additional files is ongoing, and Volexity will update this blog post if necessary.\r\nVolexity also believes the attacker created and executed a number of files from the system’s /tmp/ directory that\r\nwere no longer on disk at the time of analysis. Based on entries related to the exclusions list designed to evade the\r\nIn-build Integrity Checker Tool, Volexity believes the following files were previously on disk at the following\r\npaths:\r\n/tmp/rev\r\n/tmp/s.py\r\n/tmp/s.jar\r\n/tmp/b\r\n/tmp/kill\r\nBy carving files from the disk images, despite the file having been deleted, Volexity was able to recover a Python-based proxy utility it believes was likely s.py . This was discovered to be a copy of PySoxy, a SOCKS5 proxy\r\nwritten in Python, which is available on GitHub.\r\nMalware, Tools, and Living off the Land\r\nWhile Volexity largely observed the attacker essentially living off the land, they still deployed a handful of\r\nmalware files and tools during the course of the incident which primarily consisted of webshells, proxy utilities,\r\nand file modifications to allow credential harvesting. Once UTA0178 had access into the network via the ICS\r\nVPN appliance, their general approach was to pivot from system to system using compromised credentials. They\r\nwould then further compromise credentials of users on any new system that was breached, and use these\r\ncredentials to log into additional systems via RDP. Volexity observed the attacker obtaining credentials in a variety\r\nof ways, as detailed below:\r\nIn multiple instances, the attacker was able to use credentials they had compromised to log into various\r\nworkstations and servers and dump the memory of the LSASS process to disk using Task Manager. The\r\nattacker then exfiltrated this output to extract further credentials offline.\r\nThe attacker was able to access a system containing Virtual Hard Disk backups, which included a backup\r\nof a domain controller. They mounted this virtual hard disk and extracted the Active Directory database\r\nntds.dit file from it, and compressed it using 7-Zip.\r\nThe attacker discovered an instance of Veeam backup software that was in use and used a script available\r\non GitHub to dump credentials from it.\r\nAs previously noted, the attacker modified JavaScript loaded by the Web SSL VPN login page for the ICS\r\nVPN Appliance to capture any credentials entered in it.\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 4 of 11\n\nUsing this access in the network, Volexity largely observed mostly reconnaissance and exploration of systems by\r\nUTA0178. This primarily consisted of looking through user files, configuration files, and testing access to\r\nsystems. The primary notable activity beyond that was deployment of webshells to multiple systems. Volexity has\r\nnot yet observed UTA0178 deploying any more advanced malware implants or persistence mechanisms outside of\r\nwebshells.  Below is a summary of the type of webshell activity Volexity observed:\r\nThe attacker modified a legitimate ICS VPN component ( compcheckresult.cgi ) to support execution of\r\nremote command.\r\nThe attacker deployed Version 1 of a webshell Volexity calls GLASSTOKEN to multiple Internet-accessible webservers.\r\nThe attacker deployed Version 2 of the GLASSTOKEN webshell to an internal, non-Internet-accessible\r\nserver.\r\nOutside of the ability to execute commands on the ICS VPN appliance, these webshells appear to be the primary\r\nmethod the attacker would rely on for persistent access to the network. Additional details on some of the various\r\nobserved malware and tools are described below.\r\nGLASSTOKEN: A Custom Webshell\r\nUTA0178 planted webshells on external-facing web servers in order to grant persistence to the customer\r\nenvironment. They could then use the webshells to execute commands on those devices. Only two variations of\r\nthe same webshell were used in the attack.\r\nVersion 1\r\nThis version of the webshell has two code paths depending on the parameters present in the request. The first code\r\npath is almost identical to the “tunnel” template present in ReGeorg, which was used to relay a connection. The\r\nsecond code path is a classic code execution case where content from the request parameters is decoded from hex\r\nand then base64 decoded before being passed to Assembly.Load(). Based on evidence discovered, this was\r\nprimarily used to execute arbitrary PowerShell commands. The full code from the webshell is available here.\r\nVersion 2\r\nThe second version of the webshell is almost exactly the same as the first, but it contains only the second code\r\npath to allow code execution. This version omits the native tunneling capability. The full code for this version is\r\navailable here.\r\nJS Credential Theft\r\nAs previously mentioned, to gain access to user credentials the attacker modified the\r\nfile  lastauthserverused.js , a legitimate component of the web app, modifying the “Login” function to POST\r\nuser credentials to an attacker-controlled domain. This was done by adding the following code to the beginning of\r\nthe function:\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 5 of 11\n\nThis would result in a GET request from the user’s browser back to the attacker website with the victim’s\r\nusername and password being base64 encoded in the request.\r\nvisits.py modification – GIFTEDVISITOR\r\nThe attacker also modified another inbuilt component of Ivanti Connect Secure named  visits.py adding a\r\nwebshell component Volexity refers to as GIFTEDVISITOR. The code in this function is called whenever users\r\naccess  /api/v1/cav/client/visits . The modification to this code was to add the following additional code to\r\nthe handler for POST requests:\r\nDetecting Compromise\r\nThere are three primary methods organizations can use to detect activity associated with a compromised Ivanti\r\nConnect Secure VPN appliance:\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 6 of 11\n\nNetwork traffic analysis\r\nVPN device log analysis\r\nExecution of the Integrity Checker Tool\r\nThe sections that follow describe what organizations can do to look for signs of compromise across these different\r\ncategories. Any of these methods can provide strong evidence that the ICS VPN appliance is compromised.\r\nShould signs of compromise be identified, the section titled Responding to Compromise can be used for what to do\r\nnext.\r\nNetwork Traffic Analysis\r\nOne method organizations can use to look for signs of compromise is examine anomalous traffic originating from\r\ntheir VPN appliances. This includes both traffic destined for the Internet from the appliance and traffic from it to\r\nsystems internally. While these devices are configured to allow remote users access into the network, IP addresses\r\nassigned to VPN users are typically separate from IP addresses used by the VPN appliance itself. Organizations\r\ncan examine outbound network traffic from the VPN appliance to look for connections atypical of the device.\r\nFrom Volexity’s Network Security Monitoring of client networks, it typically sees the VPN appliance connect\r\nback to download.pulsesecure[.]net and to any other customer-configured integrations, such as to an SSO or\r\nMFA provider. Example activity that Volexity observed from compromised VPN appliances that was irregular\r\ninclude the following:\r\ncurl requests to remote websites\r\nSSH connections back to remote IPs\r\nEncrypted connections to hosts not associated with SSO/MFA providers or device updates\r\nFurther, Volexity was able to detect threat activity by observing inbound network traffic from IP addresses\r\nassociated with the VPN appliances. There is likely an expected amount of internal traffic associated with these\r\ndevices for DNS services, directory integrations, and other related traffic that should be consistently seen.\r\nHowever, other internal traffic that Volexity observed that was not expected included the following:\r\nRDP and SMB activity to internal systems\r\nSSH attempts to internal systems\r\nPort scanning against hosts to look for systems with accessible services\r\nVolexity works with its customer to monitor their networks both internally and externally. At a minimum, any\r\ntraffic analysis is likely to detect externally destined traffic. However, internal monitoring or hunting can also be\r\naccomplished by leveraging endpoint detection and response (EDR) products should the attacker attempt to\r\nconnect to a system running the software. Searching or monitoring EDR products for this activity is another\r\nmethod to detect this threat.\r\nVPN Device Log Analysis\r\nAnother great method for detecting threats on ICS VPN appliances is to monitor its logs. The good news is that\r\nthese devices log quite a bit. These logs can be accessed via System -\u003e Log/Monitoring from the admin interface.\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 7 of 11\n\nThe logs can then be viewed on the web or exported for offline analysis. A SYSLOG server can also be configured\r\nto ensure these logs are sent to another destination and cannot be wiped or tampered with.\r\nVolexity recommends organizations enable the setting to log “Unauthenticated Requests”. This can be configured\r\nby accessing the Log Settings page under User Access from within the Log/Monitoring page. With this setting\r\nconfigured, unauthenticated web requests made to the ICS VPN appliance are recorded in the user logs. This can\r\npotentially help spot exploitation, data exfiltration, or other events related to an attacker attempting gain\r\nunauthorized access to the device. In a previous blog post, Volexity covered how these logs could be used to\r\nobserve exploitation of Pulse Secure appliances. In that case, attackers were taking advantage of a vulnerability to\r\nsteal database files that contain credentials and session information.\r\nVolexity found the following cases to be useful for detecting compromise when examining logs from ICS VPN\r\nappliances:\r\nLogs are wiped and/or disabled. In at least one case, Volexity observed the threat actor clearing logs and\r\ndisabling further logging. This can be a strong indicator of compromise, especially if you know logging\r\nshould be and was previously working.\r\nRequests for files in valid but atypical paths. Unauthenticated request logging will capture requests\r\nmade for any sort of web scanning. However, examining requests for valid ICS VPN appliance paths that\r\nare valid but not commonly seen can be a potential indicator of compromise. On multiple occasions,\r\nVolexity observed the threat actor accessing files they stored data exfiltration in via files found in\r\nthe /dana-na/help/  directory.\r\nDetections from the In-build Integrity Checker Tool. Starting with PCS 9.1R12, ICS VPN appliances\r\nhave a built-in version of the integrity checker tool. This tool can be scheduled to run automatically and\r\nwill log if new or mismatched files are detected. This can be an extremely strong indicator that your ICS\r\nVPN appliance is compromised. In the web interface, under Event Logs in Log/Monitoring, these events\r\nwill show up as SYS32039 and SYS32040. These IDs only show up in the web interface, will only appear\r\nas a “critical” event in the downloaded log, and will display text such as “Integrity Scan Completed:\r\nDetected 2 new files“. If any new or mismatched files are listed, the device should be considered\r\ncompromised.\r\nThe image below shows an example of what would be displayed in the web console if the In-build Integrity\r\nChecker Tool finds new files (SYS32039). A similar message will be displayed if mismatched files are identified\r\n(SYS32040).\r\nNow for the bad news. At least as of the time of writing, the web requests associated with the exploits being used\r\nin the wild will not appear in the logs, even with the Unauthenticated Request setting enabled. This means that\r\nyou cannot tell from logs if the server is being exploited.\r\nExecuting the Integrity Checker Tool\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 8 of 11\n\nIn addition to the built-in version, Ivanti has an enhanced version of the Integrity Checker Tool that can be run on\r\nICS VPN appliances, which organizations can download. Once saved locally, the tool is run by uploading a\r\npackage to the server and installing it as a Service Pack. The tool will then run and display its results on screen.\r\nThis includes whether or not any new or mismatched files are discovered. Note: Running the Integrity Checker\r\nTool will reboot the ICS VPN appliance, which will result in the contents of system memory largely being\r\noverwritten. If you have indicators of compromise prior to running this tool, it is recommended to not run the tool\r\nuntil you can collect memory and other forensic artifacts.\r\nThe image below shows an example of what it looks like when the Integrity Checker Tool is run on a\r\ncompromised system.\r\nAs highlighted in the image, a strong indicator of potential compromise can be seen in Steps 8 and 9. These fields\r\nshow values for “Mis-matched Files = ” and “Newly detected Files = ” that are greater than 0. Once the ICS VPN\r\nappliance reboots, an encrypted snapshot of the unexpected files is saved and accessible for download. This file\r\ncan be provided to Ivanti to be decrypted and will contain an archival copy of the unexpected files identified.\r\nAdditional details about the tool, how to download it, and how deploy it can be found in KB44755.\r\nResponding to Compromise\r\nIf you discover that your ICS VPN appliance is compromised, it is important to take immediate action. You do not\r\nwant to simply wipe and rebuild the ICS VPN appliance. Collecting logs, system snapshots, and forensics artifacts\r\n(memory and disk) from the device are crucial. Pivoting to analyzing internal systems and tracking potential\r\nlateral movement should be done as soon as possible. Further, any credentials, secrets, or other sensitive data that\r\nmay have been stored on the ICS VPN appliance should be considered compromised. This may warrant password\r\nresets, changing of secrets, and additional investigations.\r\nVolexity strongly recommends that organizations look for signs of lateral movement internally from their ICS\r\nVPN appliance that is not consistent with expected behavior from the device. Proactive checks of any externally\r\nfacing infrastructure may also be warranted if internal visibility is limited.\r\nIf any organization needs assistance validating or responding to a breach, please feel free to contact Volexity\r\nfor breach assistance.\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 9 of 11\n\nConclusion\r\nAs organizations continue to improve and harden their defense, attackers are continually looking for ways to\r\nbypass them. Internet-accessible systems, especially critical devices like VPN appliances and firewalls, have once\r\nagain become a favorite target of attackers. These systems often sit on critical parts of the network, cannot run\r\ntraditional security software, and typically sit at the perfect place for an attacker to operate. Organizations need to\r\nmake sure they have a strategy in place to be able to monitor activity from these devices and quickly respond if\r\nsomething unexpected occurs.\r\nIt is critically important that organizations immediately apply the available mitigation from Ivanti and the patch\r\nthat will follow. However, applying mitigations and patches will not resolve past compromise. It is important that\r\norganizations running ICS VPN appliances review their logs, network telemetry, and Integrity Checker Tool\r\nresults (past and present) to look for any signs of successful compromise.\r\nValue Entity_type Description\r\n206.189.208.156 ipaddress DigitalOcean IP address tied to UTA0178\r\ngpoaccess[.]com hostname\r\nSuspected UTA0178 domain discovered via domain registration\r\npatterns\r\nwebb-institute[.]com\r\nhostname\r\nSuspected UTA0178 domain discovered via domain registration\r\npatterns\r\nsymantke[.]com hostname\r\nUTA0178 domain used to collect credentials from compromised\r\ndevices\r\n75.145.243.85 ipaddress UTA0178 IP address observed interacting with compromised device\r\n47.207.9.89 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n98.160.48.170 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n173.220.106.166 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n73.128.178.221 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n50.243.177.161 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n50.213.208.89 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 10 of 11\n\nValue Entity_type Description\r\n64.24.179.210 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n75.145.224.109 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n50.215.39.49 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n71.127.149.194 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\n173.53.43.7 ipaddress\r\nUTA0178 IP address observed interacting with compromised device\r\ntied to Cyberoam proxy network\r\nRelated indicators can also be downloaded from the Volexity GitHub page:\r\nYARA rules\r\nSingle value indicators\r\nAcknowledgements\r\nVolexity would like to acknowledge the Ivanti team for their support in helping with the discovery, triage, and\r\nverification of the vulnerabilities discussed in this blog post. Throughout the incident response investigation and\r\nsubsequent forensic analysis, Ivanti provided support that will ultimately protect organizations using the Ivanti\r\nConnect Secure software.\r\nSource: https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nhttps://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"MISPGALAXY",
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/"
	],
	"report_names": [
		"active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn"
	],
	"threat_actors": [
		{
			"id": "b2e48aa5-0dea-4145-a7e5-9a0f39d786d8",
			"created_at": "2024-01-18T02:02:34.643994Z",
			"updated_at": "2026-04-10T02:00:04.959645Z",
			"deleted_at": null,
			"main_name": "UNC5221",
			"aliases": [
				"UNC5221",
				"UTA0178"
			],
			"source_name": "ETDA:UNC5221",
			"tools": [
				"BRICKSTORM",
				"GIFTEDVISITOR",
				"GLASSTOKEN",
				"LIGHTWIRE",
				"PySoxy",
				"THINSPOOL",
				"WARPWIRE",
				"WIREFIRE",
				"ZIPLINE"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "6ce34ba9-7321-4caa-87be-36fa99dfe9c9",
			"created_at": "2024-01-12T02:00:04.33082Z",
			"updated_at": "2026-04-10T02:00:03.517264Z",
			"deleted_at": null,
			"main_name": "UTA0178",
			"aliases": [
				"UNC5221",
				"Red Dev 61"
			],
			"source_name": "MISPGALAXY:UTA0178",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434815,
	"ts_updated_at": 1775791833,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e42ea09a81cc35cccd432370e49a6504d308f698.pdf",
		"text": "https://archive.orkl.eu/e42ea09a81cc35cccd432370e49a6504d308f698.txt",
		"img": "https://archive.orkl.eu/e42ea09a81cc35cccd432370e49a6504d308f698.jpg"
	}
}