oast[.]fun

As firewall rule sets grow in complexity, security teams face a common challenge: manual log analysis is used to determine which rules are actively matching traffic and which are consuming capacity without being triggered. This lack of visibility creates operational and compliance gaps. Organizations with governance policies that require removal of dormant rules after a defined period have no mechanism to identify them. Teams responsible for compliance frameworks such as Payment Card Industry (PCI) 4.0 and Digital Operational Resilience Act (DORA) can’t provide evidence that specific controls are actively functioning. Central teams managing firewalls on behalf of multiple business units have no way to determine which rules are unused or need updating. In this post, you learn how a new AWS Network Firewall capability—rule hit count—addresses these challenges by providing traffic match data for stateful rules across both custom and managed rule groups. With this data, you can identify and remove unused rules, accelerate incident response, and validate security control effectiveness for compliance. How it works Rule hit counts track how often each stateful rule matches network traffic. The hit counter increments only when a rule match results in an alert log being created. This means any rule with an alert , drop , or reject action will increment the hit counter, because these actions generate alert logs. However, rules configured with a pass action don’t generate alert logs by default, meaning they won’t appear in the rule hit count metric. To gain visibility into traffic matching pass rules, you can include the alert keyword within the pass rule. This generates an alert log while still permitting the traffic to its intended destination. The following Suricata rule demonstrates this approach: pass tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Pass and Log HTTPS traffic"; alert; sid:1000001; rev:1;) This rule passes HTTPS traffic to its destination while also generating an alert log, making sure the rule appears in the hit count metric. The rule hit count feature adds the following metadata to each alert log. Metadata is included by default and doesn’t require additional configuration: “aws_metadata": { “resource_arn": “arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup” } The following example shows a complete alert log with this metadata included: { "firewall_name": "egress-and-east-west-firewall", "availability_zone": "us-east-1a", "event_timestamp": "1786112515", "event": { "tx_guessed": true, "aws_category": "", "tx_id": 0, "app_proto": "http", "ip_v": 4, "src_ip": "10.2.1.205", "src_port": 46240, "event_type": "alert", "alert": { "severity": 3, "signature_id": 10000003, "rev": 0, "signature": "Egress HTTP but not port TCP/80", "action": "blocked", "category": "" }, "ts_progress": "request_complete", "flow_id": 927132830538451, "dest_ip": "3.226.253.175", "proto": "TCP", "verdict": { "action": "drop" }, "http": { "hostname": "3.226.253.175", "http_port": 4444, "url": "/", "http_user_agent": "curl/8.17.0", "http_method": "GET", "protocol": "HTTP/1.1", "length": 0 }, "tc_progress": "response_started", "dest_port": 4444, "pkt_src": "geneve encapsulation", "aws_metadata": { "resource_arn": "arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup" }, "timestamp": "2026-08-07T14:21:55.611810+0000", "direction": "to_server" } } The alert log data in the preceding example is the source for rule hit count metrics. Network Firewall pushes these alert logs to your Amazon CloudWatch Logs or Amazon Simple Storage Service (Amazon S3) . To identify the specific rule that generated an alert, you can search using the combination of the sid (signature ID) and resource_arn fields. The firewall monitoring dashboard uses these fields to generate hit counts for each rule, so you can review rule activity directly on the dashboard without querying logs. You can also access and analyze this data by querying those logs directly using CloudWatch Logs Insights for logs stored in CloudWatch, or Amazon Athena for logs stored in Amazon S3. Getting started Network Firewall rule hit count is enabled by default, so you don’t need to perform any additional configuration to start tracking rule hits on your firewall policies. This means that as soon as you deploy your firewall rules, you can begin to monitor which rules are being triggered, helping you gain visibility into your traffic patterns and identify potential security concerns. Prerequisites This walkthrough requires an existing network firewall configured to inspect traffic from your Amazon Virtual Private Cloud (Amazon VPC) . If you don’t have one set up yet, follow the Getting started with AWS Network Firewall guide. Additionally, ensure the following: Alert log delivery must be configured: The firewall must have alert logging enabled. Note that rule hit count metadata is captured regardless of log destination; however, the native dashboard feature requires logs to be sent to CloudWatch Logs or Amazon S3. Firewall monitoring must be enabled: To see the dashboard widget shown in figure 1, you must enable detailed monitoring through the firewall’s logging configuration or the Monitoring tab in the AWS Management Console for AWS Network Firewall. However, if you have a custom dashboard solution, the metadata required for rule hit count analysis is automatically included in the firewall logs regardless of whether detailed monitoring is enabled—so you can build your own visualizations using the log data directly. Pass rules must include the alert keyword to appear in hit count metrics: Rules configured with a pass action don’t generate alert logs by default. To track pass rule activity in the hit count metric, include the alert keyword in your pass rules, as demonstrated in the How it works section of this post. The Top Rule Hits dashboard shows aggregated hit counts per firewall across all Availability Zones within the AWS Region where that firewall is deployed. To view rule hit count metrics, open the Network Firewall console and select your firewall. Navigate to the Monitoring and observability section. Under Top analysis , you will see the Top Rule Hits metric. Select a lookback period to view rule activity within that timeframe. Figure 1: Rule hit count from the dashboard Figure 1 shows the Top Rule Hits panel from the AWS Network Firewall console, displaying the most frequently triggered stateful rules. It includes columns for Hit Count (with bar chart and fraction), percentage of total hits, Resource ARN, Signature ID, Description (the msg field from the Suricata rule), and Last Occurrence (UTC). Signature IDs 2, 4, 6, and 8 are system-generated signatures corresponding to the firewall policy’s strict order default actions. Because these signatures originate from the policy rather than a rule group, the resource_arn field displays the firewall policy Amazon Resource Name (ARN) instead of a rule group ARN. They appear in the Top Rule Hits when the policy has default actions such as Drop established , Alert established , or their application-layer variants configured. These signatures fire on established connection packets that don’t match any explicit rule, enforcing the policy’s default deny posture. The following examples demonstrate how rule hit counts help you address common operational challenges. Identifying unused rules: Figure 1 shows all rule signature IDs and their descriptions (the msg field from the Suricata rule) that actively matched traffic during the selected lookback period. Any rule in your firewall policy whose signature ID doesn’t appear in this metric hasn’t matched any traffic during the specified timeframe. These rules are either stale or not ordered correctly within your rule group. Accelerating incident response: Figure 1 shows signature ID 2525124575 ( traffic_to_oast [oast[.]fun] ) with six hits and a last occurrence of August 7, 2026, at 6:28:44 PM UTC. This rule is detecting traffic to an out-of-band application security testing (OAST) domain, which could indicate an attacker attempting to exfiltrate data or validate a vulnerability in your environment. By filtering the top rule hits metric to the timeframe of a suspected incident, your team can quickly identify this type of suspicious activity and scope the impact without manually parsing thousands of log entries. Validating a newly added rule: Figure 1 shows signature ID 100000010 ( Domain Category is AI/ML ) with five hits and a last occurrence of August 7, 2026, at 6:28:21 PM UTC. After adding this rule to monitor or restrict traffic to AI/ML related domains, the hit count confirms the rule is actively matching traffic as intended. Similarly, signature ID 100000009 ( Drop traffic to countries other than US ) shows four hits, validating that the geofencing rule is functioning and blocking outbound connections to destinations outside the United States. These hit counts provide security teams with concrete evidence that newly deployed controls are working. Pricing Rule hit counts are included with Network Firewall at no additional cost. However, standard charges apply for storing and querying log data. If you configure log delivery to CloudWatch Logs, CloudWatch pricing applies. If you store logs in Amazon S3 and query them with Athena, standard Amazon S3 storage and Athena query charges apply. For complete pricing details, see AWS Network Firewall pricing . Considerations Keep the following in mind when you use rule hit counts: To manage costs, review your log utilization and configure log filtering or retention policies. Rule hit counts apply to stateful rules. Stateless rules don’t support hit count tracking at this time. Rule hit counts are available in all AWS Regions where AWS Network Firewall is supported, except Middle East (UAE) and Middle East (Bahrain). Conclusion In this post, you learned how rule hit counts in AWS Network Firewall give you visibility into your firewall rule utilization and effectiveness. By tracking how frequently each rule matches traffic, you can identify unused or redundant rules, optimize rule ordering, validate security controls for compliance, and respond faster during security investigations. For more information, see AWS Network Firewall . If you have feedback about this post, submit comments in the Comments section below. Preetkumar Shah Preetkumar is a Technical Account Manager at AWS, based in Atlanta, GA. He specializes in helping customers design and operate secure, scalable network architectures in the cloud. At AWS, he works with SMB customers and collaborates closely with service teams to proactively resolve complex challenges and ensure customers get the most from their AWS environment. Outside of work, his interests include spending time with family and going on trails. Amit Gaur Amit, a Cloud Infrastructure Architect at AWS, brings his passion for technology and knowledge-sharing to the networking community. Specializing in network architecture design, he helps customers build highly scalable and resilient environments on AWS. Through technical guidance and architectural expertise, Amit enables customers to accelerate their cloud adoption journey while making sure their systems are built for scale and reliability. Santosh Shanbhag Santosh is a seasoned product leader, specializing in security, data protection, and compliance. At AWS, he focuses on securing workloads through Network and Application Security services, including AWS Network Firewall and active threat defense. Srivalsan Mannoor Sudhagar Srivalsan is a Sr. Cloud Infrastructure Architect at Amazon Web Services Professional Services who brings expertise in Cloud Infrastructure and MLOps solutions. He is passionate about networking, container technologies and loves to innovate to help solve customer problems. He enjoys architecting solutions and providing technical guidance to help customers and partners achieve their technical and business objectives. Cheriyan Mundapuzha Cheriyan, a Cloud Infrastructure Architect at AWS, brings his infrastructure experience to some of the most complex migration challenges in the enterprise space. Through published architectural patterns, hands-on technical leadership, and mentorship of fellow professionals, he enables customers to accelerate their modernization journey while ensuring their systems are built for resilience and operational excellence.

Unit 42 stopped monitoring this threat and updating the brief on May 19, 2026. Please refer to the BeyondTrust website for the latest information. On Feb. 6, 2026, BeyondTrust released a security advisory regarding CVE-2026-1731. BeyondTrust is an identity and access management platform. This specific vulnerability involves a pre-authentication remote code execution (RCE) issue within BeyondTrust remote support software. It could allow attackers to execute operating system commands in the context of the site user, which may lead to system compromise, including unauthorized access, data exfiltration and service disruption. Unit 42 is actively investigating exploitation of this vulnerability and has observed attacker activity consistent with the following: Network reconnaissance and account creation Webshell deployment Command-and-control (C2) traffic Backdoor and remote management tool deployment Lateral movement Data theft The campaign tracked by Unit 42 has so far affected the following sectors in the U.S., France, Germany, Australia and Canada: Financial services Legal services High technology Higher education Wholesale and retail Healthcare Due to the severity of the risk and confirmed active exploitation, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added this vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog on Feb. 13, 2026. This addition mandated immediate remediation for federal agencies and signaled urgent prioritization for the private sector. At the time of publication, Palo Alto Networks Cortex Xpanse has identified the presence of 16,400-plus exposed instances potentially vulnerable to CVE-2026-1731 based on our telemetry. Palo Alto Networks customers are better protected from CVE-2026-1731 through the following products: Palo Alto Networks also recommends that BeyondTrust self-hosted customers of Remote Support and Privileged Remote Access manually patch any instances that are not subscribed to automatic updates in the appliance interface in accordance with their February 2026 advisory. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. CVE-2026-1731 is a critical RCE vulnerability affecting the thin-scc-wrapper component of unpatched versions of BeyondTrust remote support software. This component is exposed to the network and handles incoming WebSocket connections. The flaw allows unauthenticated remote attackers to execute arbitrary operating system commands with high privileges. The vulnerability has been assigned a CVSS score of 9.9, reflecting its low attack complexity and the immediate threat to system integrity and confidentiality. Characteristics of this vulnerability include: Type: OS Command Injection (CWE-78) Severity: Critical (CVSS v4 Score: 9.9) Vector: Network/Pre-authentication Affected Component: thin-scc-wrapper script (reachable via WebSocket interface) The vulnerability is triggered during the WebSocket handshake process. The backend script, thin-scc-wrapper, is designed to parse and evaluate the remoteVersion value provided by the connecting client. This value is ostensibly used for version compatibility checks. The script uses bash arithmetic contexts (such as (( ... )) or let) to compare the version numbers. In bash, these contexts are not strictly limited to integer values. These contexts can also treat operands as expressions. Consequently, if input is not rigorously sanitized, an arithmetic context will evaluate and execute embedded commands — such as command substitutions $(command) — before performing the intended comparison. While previous patches for this component reportedly introduced numeric coherence checks, our analysis indicates these measures were not fully comprehensive. They failed to prevent the bash interpreter from evaluating expressions within the input string, leaving the endpoint exposed to injection. Successful exploitation requires no prior authentication or user interaction. The attack sequence typically follows this trajectory: Connection: The attacker initiates a standard WebSocket connection to the target appliance, directing traffic to /nw [path] or endpoints associated with get_portal_info. Injection: During the handshake phase, the attacker submits an intentionally crafted, malformed remoteVersion value that contains the malicious payload. The payload leverages a specific format, observed in proof-of-concept (PoC) code as a[$(cmd)]0, to force the arithmetic evaluation. Payload execution: The thin-scc-wrapper script processes the remoteVersion value, inadvertently triggering the malicious payload, which is an injected shell command. The injected commands execute in the context of the “site user.” While this account is distinct from the root user, compromising it effectively grants the attacker control over the appliance's configuration, managed sessions and network traffic. Unit 42 is actively investigating multiple compromises related to the exploitation of CVE-2026-1731. We have observed successful exploitation of the vulnerability followed by attackers leveraging their access to: Create domain accounts Install remote management tools to perform reconnaissance of domain administrators and trusts Create local administrator accounts Deploy a backdoor Attempt to install additional remote management tools (i.e., SimpleHelp and AnyDesk) and/or tunneling tools (i.e., Cloudflare) Data theft We have observed attackers using a custom Python script for temporary account takeover, granting access to an administrative account (User ID 1) for 60 seconds before deleting the file to minimize artifact recovery. The Python script functions by querying the target's database to back up the existing password hash for the primary administrator (User ID 1). It leverages the application's own authentication binary (check_auth) to generate a valid hash for the password string password and injects the hash into the database. After sleeping for one minute, the script restores the original password hash and self-destructs, effectively hiding the intrusion from the legitimate administrator and minimizing forensic artifacts on disk. Figure 1 shows this Python script. Unit 42 identified attackers installing multiple web shells across directories, including a password-protected one-line PHP web shell. This compact PHP backdoor uses the eval() function to execute raw PHP code submitted via the POST['1'] parameter, contingent on the presence of the GET['aaaa'] parameter. This structure allows attackers to execute post-exploitation tasks such as file uploads or database dumps without writing additional files to disk. Figure 2 shows an example of this one-line PHP web shell. We recovered a compact, multi-vector PHP web shell (aws.php) designed to function as a stealthy execution gate for an automated C2 client. It aggregates all incoming HTTP data sources (POST, GET and Cookie) to locate a specific parameter named 'ASS', which serves as the payload carrier. The script Base64-decodes this parameter and executes it via eval(), allowing the attacker to run arbitrary PHP code without writing new files to disk. The distinct echoing of DQo= (CRLF characters) before and after execution acts as a data delimiter, a signature trait of C2 tools like China Chopper or AntSword. These delimiters enable the client software to programmatically extract command output from the noisy HTML response of the compromised page. This PHP web shell is shown below in Figure 3. Attackers also used a bash dropper that employs a “config STOMPing” technique to establish a persistent web shell. The script first writes a password-protected PHP backdoor (file_save.php) to the web root directory, which executes arbitrary system commands only when the query parameter key equals vjwr. It then momentarily injects a malicious Location directive into the active Apache configuration file, forcing requests for the backdoor to be handled by a specific Unix socket (/ns/tmp/php-fpm.sock). The script restarts the Apache service to load this malicious configuration into memory and immediately overwrites the configuration file on disk with a clean backup. This leaves the backdoor fully functional in the running process while ensuring the configuration file on disk appears unmodified to forensic investigators. Figure 4 below shows this bash dropper. Unit 42 observed numerous instances of SparkRAT backdoor activity across a wide swath of environments. SparkRAT was originally identified in 2023 as being used in a series of attacks nicknamed DragonSpark. This backdoor is a cross-platform, open-source remote access Trojan (RAT) written in the Go programming language. The tool has been used in various attacks since 2022. Attackers have also been leveraging VShell, a stealthy Linux backdoor [PDF] and RAT characterized by its evasion techniques, including fileless memory execution and the ability to masquerade as legitimate system services. Along with PowerShell scripts designed to download and install a Nezha monitoring agent, we also observed a multi-method "download and execute" cradle. This strategy is designed to guarantee payload delivery across diverse Linux environments (from servers to IoT devices) by chaining redundant commands (wget, curl, python, busybox). This strategy retrieves a malicious script (blue.drx) from a legitimate file transfer service and pipes the content directly into sh for immediate execution. Additionally, Unit 42 observed attackers attempting reverse shells to infrastructure consistent with the default Metasploit Meterpreter over port 4444. Attackers used out-of-band (OAST) techniques targeting the Burp Suite Collaborator service oastify[.]com to validate successful code execution and fingerprint compromised systems. Unlike traditional C2 channels that may be blocked by egress filtering, these attacks leverage the DNS protocol to bypass network firewalls. By encoding the victim's hostname into the subdomain of a DNS query (e.g., [encoded_hostname].[attacker_domain]), the attacker attempts to disguise the data leaving the network as legitimate-looking DNS traffic. The receiving OAST server logs the query, allowing the attacker to confirm the breach and identify the specific machine without establishing a TCP/HTTP connection. The script used in this attack captures the system hostname, converts it to a hexadecimal string and transmits it via nslookup queries to the attacker's OAST domain. Figure 5 below shows an example. These attacks have used the PowerShell command shown in Figure 6 to handle the BitConverter encoding and manage DNS label limits (chunking data into 63-character segments) to ensure successful transmission through strict DNS resolvers. Unit 42 observed attackers leveraging a remoteVersion parameter injection to execute a complex chain of commands designed to stage, compress and exfiltrate sensitive data. The attackers targeted configuration files, internal system databases and a full PostgreSQL dump, attempting to transmit data to an attacker-controlled C2 server. The relationship between CVE-2026-1731 and CVE-2024-12356 highlights a localized, recurring challenge with input validation within distinct execution pathways. CVE-2024-12356's insufficient validation was using third-party software (postgres), while CVE-2026-1731's insufficient validation problem occurred in the BeyondTrust Remote Support (RS) and older versions of the BeyondTrust Privileged Remote Access (PRA) codebase. In the case of CVE-2024-12356, attackers identified insufficient input validation within a WebSocket endpoint handling logic. By manipulating the remoteVersion parameter, they successfully bypassed existing validation checks to execute command lines via the thin-scc-wrapper. This evolution underscores that exposed input-handling pathways remain a primary, high-value target for adversaries seeking pre-authenticated initial access. The significance of this attack surface is underscored by historical precedent. The original vulnerability (CVE-2024-12356) was exploited by the threat actor Silk Typhoon (aka APT27, UNC5221, Emissary Panda) in high-profile campaigns, including a breach of the U.S. Treasury in 2024. This history suggests that CVE-2026-1731 could be a target for sophisticated threat actors seeking similar leverage. A February 2026 Beyond Trust advisory recommends that self-hosted customers of Remote Support and Privileged Remote Access manually patch any instances that are not subscribed to automatic updates in the appliance interface. Customers on a Remote Support version older than 21.3 or on Privileged Remote Access older than 22.1 will need to upgrade to a newer version to apply this patch. Self-hosted customers of Privileged Remote Access may also upgrade to 25.1.1 or a newer version to remediate this vulnerability. A patch has been applied to all Remote Support SaaS and Privileged Remote Access SaaS customers as of Feb. 2, 2026, that remediates this vulnerability. Self-hosted customers of Remote Support may also upgrade to 25.3.2 to remediate this vulnerability. The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation. CVE-2026-1731 is a vulnerability that attackers are actively exploiting in systems running unpatched versions of BeyondTrust remote support software. Successfully exploiting this vulnerability can allow attackers to gain RCE privileges. CVE-2026-1731 is related to a similar vulnerability from 2024 that was also noted as exploited in the wild. The recurrence of this type of vulnerability underscores the necessity of defense-in-depth architecture for high-value remote access platforms. Rather than relying solely on patch management, organizations should prioritize architectural containment by strictly limiting administrative interfaces to internal, segmented management networks or zero trust network access gateways. This approach ensures that even if specific code paths remain vulnerable or new variants emerge, the management plane remains shielded from both opportunistic and targeted exploitation attempts. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available. Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM help protect against post-exploitation activities using the multi-layer protection approach. Cortex Xpanse has the ability to identify exposed BeyondTrust Secure Remote Access systems on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that the BeyondTrust Secure Remote Access Attack Surface Rule is enabled. Identified findings can either be viewed in the Threat Response Center or in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module. While there are no known indications of the exploitation of this vulnerability within cloud infrastructure, Cortex Cloud customers are better protected from, and can detect and remediate, vulnerable cloud infrastructure by using Cortex Cloud’s vulnerability monitoring. Additionally, the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment helps detect and prevent the malicious operations, configuration alterations or exploitation at runtime providing sustained defenses of the cloud environment. 23.162.40[.]187 37.19.221[.]180 45.61.150[.]96 70.23.0[.]66 82.29.53[.]187 82.29.72[.]16 83.138.53[.]139 85.155.186[.]121 92.223.44[.]134 98.10.233[.]76 134.122.13[.]34 138.197.14[.]95 142.111.152[.]50 144.172.103[.]200/4444 155.2.215[.]64 178.128.212[.]209 179.43.146[.]42 45.61.150[.]96/4444 138.197.14[.]95/ws (SparkRAT) hxxp[:]//64.31.28[.]221/support aliyundunupdate[.]xyz:8084/slt (VShell) d65sb7ngveucv5k2nm508abdsjmbn7qmn.oast[.]pro q0r2e5q2dzbykcox9qmkptm12s8mwb.oastify[.]com hxxp[:]//134.122.13[.]34:8979/c (SparkRAT) hxxp[:]//82.29.53[.]187:8778/app_cli hxxps[:]//transfer.weepee[.]io/7nZw7/blue.drx hxxp[://]85.155.186[.]121/access (SimpleHelp) hxxps[:]//temp[.]sh/tQTSs/storm.exe hxxps[:]//64.95.10[.]115:23011/update.sh hxxps[:]//judiemkqjajsfzpidfjlowgl8nyrtd49x.oast[.]fun hxxps[:]//raw.githubusercontent[.]com/nezhahq/scripts/main/agent/install.ps1 hxxp[:]//39uchxifap4cvgzsuirom0szrrg.d65lre9sfqnlcv49317gcis6pyjsatzho.oast[.]pro hxxps[:]//85.155.186[.]121/access/Remote%20Access-linux64-offline.tar?language=en&app=76049110434275449312180081368257747094 hxxps[:]//github[.]com/nicocha30/ligolo-ng/releases/download/v0.8.2/ligolo-ng_agent_0.8.2_linux_amd64.tar.gz 9f431d5549a03aee92cfd2bdbbe90f1c91e965c99e90a0c9ad5a001f4e80c350 (SparkRAT) 98a7b0900a9072bb40af579ec372da7b27af12b15868394df51fefe290ab176b (VShell) 66cceb2c2f1d9988b501832fd3b559775982e2fce4ab38fc4ffe71b74eafc726 (maintenance.php) 679ee05d92a858b6fe70aeb6072eb804548f1732e18b6c181af122b833386afb (d6) 4762e944a0ce1f9aef243e11538f84f16b6f36560ed6e32dfd9a5f99e17e8e50 (Installer for SimpleHelp) 98442387d466f27357d727b3706037a4df12a78602b93df973b063462a677761 (aws.php) cc2bc3750cc5125a50466f66ae4f2bedf1cac0e43477a78ed2fd88f3e987a292 (Bash Script) cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce (file_save.php) 0ecc867ce916d01640d76ec03de24d1d23585eb582e9c48a0364c62a590548ac Updated Feb. 20, 2026, at 9:50 a.m. PT to adjust the number of exposed instances identified by Cortex Xpanse.