Cisco Talos is aware of UAT-4356's continued active targeting of Cisco Firepower devices’ Firepower eXtensible Operating System (FXOS). UAT-4356 exploited n-day vulnerabilities (CVE-2025-20333 and CVE-2025-20362) to gain unauthorized access to vulnerable devices, where the threat actor deployed their custom-built backdoor dubbed “FIRESTARTER.” FIRESTARTER considerably overlaps with the technical capabilities of RayInitiator’s Stage 3 shellcode that processes incoming XML-based payloads to endpoint APIs.

In early 2024, Cisco Talos attributed ArcaneDoor, a state-sponsored campaign focused on gaining access to network perimeter devices for espionage, to UAT-4356.

Customers are advised to refer to Cisco’s Security Advisory for mitigation and detection guidance, indicators of compromise (IOCs), affected products, and applicable software upgrade recommendations.

The FIRESTARTER backdoor

FIRESTARTER is a malicious backdoor implanted by UAT-4356 that allows remote access and control to execute arbitrary code inside the LINA process, a core component of Cisco’s ASA and FTD appliances running FXOS.

Persistence

UAT-4356 established persistence for FIRESTARTER on compromised devices by manipulating the mount list for Cisco Service Platform (CSP), namely “CSP_MOUNT_LIST”, to execute FIRESTARTER. The mount list allows programs and commands to be executed as part of the device’s boot sequence. The persistence mechanism triggers during graceful reboot (i.e., when a process termination signal is received). FIRESTARTER also checks the runlevel for value 6 (indicating device reboot) and in case of a match, writes itself to backup location “/opt/cisco/platform/logs/var/log/svc_samcore.log" and updates the CSP_MOUNT_LIST to copy itself back to “/usr/bin/lina_cs” and then be executed. When FIRESTARTER runs after a reboot, it restores the original CSP_MOUNT_LIST and removes the trojanized copy. Because the runlevel triggers establishment of this transient persistence mechanism, a hard reboot (for example, after the device has been unplugged from power) effectively removes the implant from the device.

FIRESTARTER has used the following commands to establish persistence for itself using the transient persistence mechanism:

When the implant injects itself into the LINA process, it removes the traces of its persistence mechanism by restoring the CSP_MOUNT_LIST from a temporary copy (“CSP_MOUNTLIST.tmp”), then removing the temporary copy and the FIRESTARTER file from disk (“/usr/bin/lina_cs”).

FIRESTARTER’s backdoor capabilities

FIRESTARTER can run arbitrary shellcode received by the device. A pre-defined handler function specified by a hardcoded offset in the LINA process’ memory is replaced by an unauthorized handler routine that parses the data being served to it. FIRESTARTER specifically looks for a WebVPN request XML. If the request data received matches a specific pattern of custom-defined prefixing then the shellcode that immediately follows it is executed in memory. If the prefixing bytes are not found, then the data is treated as regular request data and passed to the original handler function (if any).

FIRESTARTER’s loading mechanism, Stage 2 shellcode (i.e., the actual request handler component), handler function replacement, XML parsing for magic bytes, and final payload execution display considerable overlaps with RayInitiator’s Stage 3 deployment actions and accompanying artifacts.

Injecting and activating the malicious shellcode in LINA

FIRESTARTER first reads the LINA process’ memory to search for and verify the presence of the bytes (long) 0x1, 0x2, 0x3, 0x4, 0x5 at specific locations in memory. If found, FIRESTARTER will then query the process’ memory to find an “r-xp” memory range for the shared library “libstdc++.so”. It then copies the next stage shellcode (Stage 2) to the last 0x200 bytes of the memory region. FIRESTARTER then overwrites an internal data structure in the LINA process’ memory to replace a pointer to a WebVPN-specific, legitimate XML handler function with the address of the malicious Stage 2 shellcode.

The malicious shellcode is triggered as part of the authentication API’s request handling process and parses the incoming request data for magic markers signifying an executable payload. If found, the executable payload is then executed on the compromised device.

Detection guidance

The presence of the following artifacts - specifically the filenames “lina_cs” and “svc_samcore.log” - though somewhat brittle indicators, may indicate the presence of the FIRESTARTER on a Firepower device:

• Any output from the commands:
  • show kernel process | include lina_cs
• The presence of the following files on disk:
  • /usr/bin/lina_cs
  • /opt/cisco/platform/logs/var/log/svc_samcore.log

For more comprehensive detection guidance, please refer to Cisco’s Security Advisory here. Please also refer to CISA’s update to V1: Emergency Directive (ED) 25-03: Identify and Mitigate Potential Compromise of Cisco Devices and FIRESTARTER Backdoor Malware Analysis Report for more information and guidance.

Mitigation and coverage

We recommend that Cisco customers follow the steps recommended in Cisco's advisory, with particular attention to any applicable software upgrade recommendations. Organizations impacted can initiate a TAC request for Cisco support.

A FIRESTARTER infection may be mitigated on all affected devices by reimaging the devices.

On Cisco FTD software that is not in lockdown mode, there is also the option of killing the lina_cs process then reloading the device:

> expert
$ sudo kill -9 $(pidof lina_cs)
$ exit
> reboot

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

The following Snort rules cover the vulnerabilities CVE-2025-20333 and CVE-2025-20362: 65340, 46897.

Snort rules covering FIRESTARTER: 62949

The following ClamAV signatures detect this threat: Unix.Malware.Generic-10059965-0

By Diana Brown

• Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
• These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
• By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
• In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved. 
• During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity. 

Platform abuse, social engineering, and SaaS notification hijacking 

Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos' analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering. 

The PaaP model 

The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform's own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a "seal of approval" that few security gateways are configured to challenge. 

Anatomy of GitHub campaign: Abusing automated notification pipelines 

The GitHub vector is a pure "notification pipeline" abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.  

By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page. 

The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.  

The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the "invoice" lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set. 

Abusing workflow and invitation logic (Jira) 

The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a "pipeline" of activity, but an abuse of the collaborative invitation feature.  

Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious. 

In this example, the attacker sets the "Project Name" to "Argenta." When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees "Argenta" as the sender or the subject, which the platform has verified as the project name. 

The attacker placed their malicious lure subject into the "Welcome Message" or "Project Description" field. They use the "Invite Customers" feature and input the victim's email address. Atlassian’s backend then generates the email. Because the system is designed to be a "Service Desk," the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.  

Strategic implications 

The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform's own reputation to launder their malicious content. 

How do we fundamentally change the trust model? 

Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.  

Identity and instance-level verification: We must move from "global domain trust" to "instance-level authorization." Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization's internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action. 

Upstream API-level monitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform "precursor activities" within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a "Project Creation" event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack. 

Semantic intent and behavioral profiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional "Communication Baseline." GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect "semantic discontinuity," when the content of a notification (e.g., urgent financial billing) is incongruent with the platform's primary utility. Any notification that deviates from the expected functional profile should trigger an automated "Suspicious" banner or be routed for manual review, regardless of its technical validity. 

Mitigating cognitive automation fatigue: PaaP attacks exploit "automation fatigue," where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the "reflexive trust" that attackers rely on. This ensures that the platform’s "seal of approval" is validated by a deliberate human action. 

Automated takedown orchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable. 

By adopting this framework, the security posture evolves from "Is this email authenticated?" to "Is this platform activity authorized and consistent with our business logic?" This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline. 

Acknowledgements 

Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors. 

Indicators of compromise (IOCs) 

IOCs for this threat can be found on our GitHub repository here. 

The 2025 Talos Year in Review is now available to view online.

The pace and scale of adversary activity in 2025 placed sustained pressure on security teams across industries. As with each annual report, our goal at Talos is to provide the security community with a clear analysis of the tactics, techniques, and procedures that shaped adversary operations, and to help organizations prioritize the actions that reduce exposure and strengthen defenses.

What defined 2025

Three themes emerged consistently across Talos’ threat research, telemetry, and incident response engagements:

1. Exploitation at both extremes

New large-scale vulnerabilities were operationalized almost immediately, but adversaries also continued to exploit CVEs that have been exposed for years. This rapid operationalization of new vulnerabilities reflects a rise in automated exploit development, public proof-of-concept code, and mature adversary coordination.

React2Shell, released in December, ranked first by year’s end only three weeks after disclosure, while a vulnerability disclosed 12 years ago ranked seventh. That range tells a story about organizational technical debt: Long-standing exposure continues to be reliably and successfully exploited.

2. The architecture of trust

In 2025, adversaries focused on the systems that manage authentication, authorization, and device trust.

Attackers who gained access through compromised credentials stealthily extended that access through internal phishing and abuse of identity controls within network infrastructure. Control of identity often meant control of the environment.

3. Targeting centralized systems for more leverage

Threat actors targeted centralized infrastructure, management platforms, and shared frameworks to expand the impact of a single compromise.

Approximately 25% of the vulnerabilities in the Top 100 targeted list affected widely used frameworks and libraries that are embedded deep within the software stack. Because these components underpin applications and network appliances across vendors, a single CVE can create mass exploitation potential across industries. Compromising these shared foundations enabled lateral movement across environments. 

Read the full report

View the full report online (it’s not gated and never will be) to see where attackers are gaining ground, and how to disrupt their playbook. 

Read the 2025 Cisco Talos Year in Review

Download now

Update history

Date	Description of updates
March 13, 2026	Talos’ assessment of the cyber attack on Stryker and the elevated threat landscape. Key findings and background on Handala, the Iranian-linked threat group.
March 10, 2026	Updated guidance and recommendations, IOCs, and timelines.
March 2, 2026	Initial Blog

Blog update: March 13, 2026 

Executive summary 

Cisco Talos assesses that the recent cyber attack on the medical equipment manufacturing firm, Stryker, likely represents an opportunistic compromise rather than a systematic shift toward targeting the health care sector specifically. Nevertheless, the broader threat landscape remains elevated due to ongoing military operations in Iran, necessitating that all organizations increase vigilance and strengthen their defensive capabilities against destructive cyber activity. 

Key findings 

• Cisco Talos assesses that the publicly reported cyber attack on a U.S.-based medical equipment manufacturer, Stryker, likely does not indicate that the health care sector is at any higher or specific risk of targeting by Iran-linked threat actors. We make this assessment with high confidence based on our understanding of the motivation and capability of threat groups like Handala, which have historically compromised targets of opportunity. Talos has not observed any recent increase in systematic or elevated targeting of health care or health care-adjacent sectors over any other industry.
• Handala is an Iranian threat actor, which cybersecurity firms have linked to Iran’s intelligence and security services, that conducts disruptive and destructive cyber operations under the guise of pro-Palestinian and pro-Iranian activism. The group combines low-level hacktivist activities with sophisticated techniques, including custom-made wiper malware and administrative tool hijacking, to execute high-impact attacks against global organizations. 
• Despite our assessment that the health care sector is not at a higher risk specifically, the broader threat landscape remains elevated across all sectors amid ongoing military operations in Iran. Consequently, organizations are encouraged to reinforce their defensive postures and remain alert to destructive threats. Organizations should increase vigilance and evaluate their capabilities, encompassing planning, preparation, detection, and response for such an event. 

Background

On March 11, 2026, the global medical technology firm Stryker was targeted in a cyber attack claimed by the Iran-linked threat group Handala, resulting in a severe disruption of its worldwide operations. The group asserts it deployed a destructive wiper attack to erase data from more than 200,000 systems — including servers, laptops, and employee mobile devices — and allegedly exfiltrated 50 terabytes of sensitive information in retaliation for recent military actions in Iran. This claim has not been officially verified. While Stryker has acknowledged a "global network disruption" to its Microsoft environment and is working with security partners to restore access, reports from its major hubs in the U.S. and Ireland indicate that the attack has effectively halted production and administrative functions, with many employees locked out of their devices.  

We assess the attack was almost certainly executed by compromising high-level administrative accounts, based on our identification of hundreds of leaked Stryker credentials on the dark web. The threat actors likely gained access to Stryker’s Microsoft Intune management console, within which they reportedly weaponized the platform's native remote wipe feature to simultaneously reset connected corporate devices. This living-off-the-land (LOTL) technique allowed the group to cause widespread destruction and data loss, possibly without the need for traditional wiper malware.

Handala: A state-linked threat group 

The Handala group, also known as the Handala Hack Team, first emerged in December 2023, positioning itself as a pro-Palestinian hacktivist collective. Despite its hacktivist branding, leading cybersecurity firms assess the group as a persona operated by Void Manticore (also known as Storm-0842 or Banished Kitten), a threat actor affiliated with the Iranian Ministry of Intelligence and Security (MOIS). This persona possibly allows the Iranian government to conduct destructive cyber operations while maintaining a degree of plausible deniability. 

The group’s operational history is defined by a rapid escalation from symbolic attacks to high-impact destructive campaigns. Initially, Handala focused almost exclusively on Israeli targets, claiming to have breached military weather servers, intercepted security feeds in Jerusalem, and compromised Telegram accounts allegedly associated with high-profile officials like former Prime Minister Naftali Bennett in "Operation Octopus." By 2025 and early 2026, the group expanded its scope to target Western organizations perceived as supporting Israel, culminating in the massive March 2026 attack on the medical technology giant Stryker. 

Handala’s tactics, techniques, and procedures (TTPs) blend state-sponsored capabilities with opportunistic hacktivist methods. They primarily gain initial access by accessing valid accounts, often through spear-phishing campaigns that exploit current events (such as the 2024 CrowdStrike outage) or by searching dark web sources for leaked credentials. Once inside, they often use hands-on-keyboard techniques to move laterally, reportedly demonstrating the ability to hijack administrative tools like Microsoft Intune to trigger remote factory resets on thousands of corporate devices simultaneously. Their arsenal includes custom-built wiper malware, such as Hatef (for Windows) and Hamsa (for Linux), often delivered via multi-stage loaders to evade detection. The group has also reportedly used commercial infostealer malware such as Rhadamanthys, according to industry reporting. To maximize psychological impact, they frequently pair these destructive acts with hack-and-leak operations, defacing victim websites and leaking sensitive data on their Telegram and dark web channels. 

Recommendations for protection  

Defend against destructive malware 

Destructive malware, often leveraged by Iranian threat actors, can present a direct threat to an organization’s daily operations, impacting the availability of critical assets and data. Disruptive cyber attacks against organizations in a target country may unintentionally spill over to organizations in other countries. Organizations should increase vigilance and evaluate their capabilities encompassing planning, preparation, detection, and response for such an event. Refer to CISA’s best practices for responding to destructive malware, outlined on pages 5 – 9 of their 2022 alert.  

General best practices 

Adhere to security fundamentals 

An influx of threat actors of varying skill levels to this threat space may lead to unsophisticated methods being used to compromise victims, as we often see during times of conflict. Defenders should ensure security fundamentals are being adhered to, such as robust patching for known vulnerabilities, visibility into end-of-sale (EoS)/end-of-life (EoL) devices in your network with a plan to upgrade, and requiring multi-factor authentication (MFA) for remote access and on critical services. Patches for critical vulnerabilities that allow for remote code execution or denial-of-service on externally facing equipment should be prioritized. Organizations can also implement a patch management program that enables a timely and thorough patching cycle. Talos’ top security practices, including those to guide MFA deployment, can be found in our 2024 Year in Review report.

Blog update: March 10, 2026

Executive summary

On Feb. 28, 2026, the United States and Israel launched coordinated strikes against Iranian military and leadership targets, prompting Iranian missile and drone retaliation across the Middle East. Cisco Talos is closely monitoring the evolving cyber threat landscape associated with the conflict and collecting tactics, techniques, and procedures (TTPs); threat actor identifiers; and other intelligence to help inform defensive efforts and maintain situational awareness.

On March 8 2026, Iran’s government selected Mojtaba Khamenei, the son of the late leader, as the new Supreme Leader; signaling a continuity of the regime’s hardline policies. Talos assesses that, for the duration of this conflict, pro-Iranian cyber actors will likely continue targeting entities allied with the U.S. and Israel, primarily those located in the Middle East, with low-level attacks like denial-of-service (DoS), web defacements, and data leak campaigns. Furthermore, while the degree to which Iran's state-sponsored offensive capabilities have been degraded remains ambiguous, the regime maintains a historical capability and intent to execute disruptive ransomware and destructive wiper malware attacks against critical infrastructure (CI).

Outlook

Cyber operations are likely to play a supporting but strategically significant role in the ongoing conflict involving Iran, Israel, and the U.S. Given Iran’s inability to match U.S. and Israeli conventional military capabilities, Tehran has historically relied on cyber operations conducted by both state-linked actors and aligned proxy groups as an asymmetric means of retaliation and influence. This pattern is again evident in the current conflict, with Iranian-aligned groups employing network-based intrusions to target adversary infrastructure and advance strategic objectives.

U.S. and Israeli operations reportedly compromised segments of Iran's information systems, yet the distributed nature of Iran's electronic warfare program across numerous agencies and proxies has likely provided a level of distributional resilience against these disruptions. While these targeted strikes likely slowed the overall operational tempo and forced a further shift in how capabilities are allocated across decentralized units, Iran likely retains some of its offensive online capacity and will likely continue leveraging digital intrusions as an asymmetric countermeasure.

Timeline

Though select hacktivist operations are highlighted below, hundreds of attacks have been claimed by numerous collectives since the beginning of the conflict. Talos cautions against accepting these claims at face value, emphasizing that defenders should independently verify them since older leaks and previously public information can be used to influence perceptions. The timeline below highlights higher-profile and more credible incidents.

• February
  • Between February and March 2026, the Iranian advanced persistent threat (APT) group Seedworm, who we track as MuddyWater (aka Temp Zagros, Static Kitten), targeted networks of multiple U.S. companies, including a bank, airport, and non-profit, as well as the Israeli operations of a U.S. software company. Seedworm deployed a previously unknown custom backdoor, named Dindoor, which leverages Deno, the secure runtime for JavaScript and TypeScript, to execute. They also deployed a Python backdoor named Fakeset.
  • Throughout February, Talos observed tools associated with Seedworm in the energy, education, and government sectors in Western countries. The tools include the aforementioned Dindoor, Fakeset, a backdoor named Darkcomp, and Stagecop (the loader for Darkcomp). A list of indicators of compromise (IOCs) associated with these tools can be found in the IOC section.
• February 28
  • Hacktivist group Sylhet Gang-SG claimed to have launched DDoS attacks targeting several entities, including: the Port of Los Angeles in the U.S.; the Qatari government’s online portal, Ministry of Foreign Affairs, Ministry of Education, Ministry of the Interior, and Government Communications Office; Bahrain's airport and Information and eGovernment Authority; and the Abu Dhabi Civil Defense Authority in the United Arab Emirates (UAE).
  • Between February 28 and March 2, 2026, a coordinated surge of 149 hacktivist-attributed DDoS attacks targeted 110 organizations across 16 countries, occurring in the immediate aftermath of the U.S.–Israel military campaign against Iran.
  • Beginning on February 28, Iranian cyber actors significantly increased efforts to exploit internet-connected surveillance cameras in Israel and several Gulf states, leveraging known vulnerabilities to gain unauthorized access to live video feeds. Researchers assess the campaign likely sought to provide real-time situational awareness, reconnaissance, and battle damage assessment to support Iranian or proxy military operations.
• March 1
  • "Handala Hack,” a hacktivist persona linked to Iran’s Ministry of Intelligence and Security (MOIS), claimed to compromise Jordan Modern Oil & Fuel Services Co. Ltd. at the “mgc-gas[.]jo” website.
  • The Islamic Cyber Resistance in Iraq (aka 313 Team) claimed to have launched DDoS attacks targeting the official portal of the Jordanian government at “jordan[.]gov[.]jo” and the Kuwait Armed Forces website at “kuwaitarmy[.]gov[.]kw”.
  • Hacktivist user “RipperSec” claimed to have launched a DDoS attack targeting the Israeli drone services provider at “propeller-drones[.]com”.
  • “Investigation Anonymous” posted on their Telegram channel what they claim is an archive of leaked data of Israeli Defense Forces (IDF) personnel, including records from IDF training programs and personnel management systems.
  • Pro-Palestinian hacktivist group DieNet claimed to have launched DDoS attacks targeting several entities in the Middle East, including the Sharjah airport in the UAE, the Riyad and Al Rajhi banks in Saudia Arabia, the Oman government, and the Ras Al Khaimah airport in the UAE.
• March 2
  • The Iranian APTIran hacktivist group claimed on its Telegram channel to have compromised the state‑owned food security agency Jordan Silos and Supply General Co. at the “josilos[.]com” website. The breach allegedly occurred about a month earlier.
  • The Russia-aligned hacktivist group NoName057(16) pledged its solidarity with the Iranian regime in the ongoing armed conflict and claimed it started a DDoS attack campaign against Israel-based entities under the designator #OpIsrael. Targets include websites of political parties, local authorities, and telecommunications companies.
• March 8
  • Iran’s government selected Mojtaba Khamenei, the son of the late leader, as the new Supreme Leader, signaling a continuity of the regime’s hardline policies. He was considered the preferred candidate of the Islamic Revolutionary Guards Corps (IRGC), one of the most powerful political and military organizations in Iran, created to protect the regime's ideology and power.

Recommendations

Defend against destructive malware

Destructive malware, which Iranian threat actors often leverage, can present a direct threat to an organization’s daily operations, impacting the availability of critical assets and data. Disruptive cyberattacks against organizations in a target country may unintentionally spill over to organizations in other countries. Organizations should increase vigilance and evaluate their capabilities encompassing planning, preparation, detection, and response for such an event. Refer to CISA’s best practices for responding to destructive malware, outlined on pages 5 - 9 of their 2022 alert. 

Limit publicly available data 

The current conflict may prompt increased intelligence-gathering activity from cyber actors seeking to identify and exploit valuable targets. Espionage-focused actors often perform reconnaissance on targets’ resources with the intent of gaining further information about their networks. Organizations should therefore consider minimizing the amount and sensitivity of data that is available to external parties. This can include scrubbing user email addresses and contact lists from public websites, which can be used for social engineering; sharing only necessary data with third parties; and monitoring and limiting third-party access to the network. Active scanning efforts can also be identified by monitoring network traffic for sources associated with botnets and adversaries, based on threat intelligence.  

Enhance DDoS and website defacement protections

A more active hacktivist landscape inherently increases the threat of DDoS and website defacement attacks. To improve defenses against DDoS attacks, organizations should ensure they have a business continuity plan in place, assess their external attack surfaces, and confirm that critical systems have healthy, usable backups. For website defacement/redirect protection, ensure that websites are protected against the most commonly exploited security vulnerabilities, all forms or user inputs do not allow the injection of code into internal systems, secure application databases, and limit file uploads and the use of add-ons and plugins.

Adhere to security fundamentals  

An influx of threat actors of varying skill levels to this threat space may lead to unsophisticated methods being used to compromise victims, as we often see during times of conflict. Defenders should ensure security fundamentals are being adhered to, such as robust patching for known vulnerabilities and requiring multi-factor authentication (MFA) for remote access and on critical services. Patches for critical vulnerabilities that allow for remote code execution or DoS on externally facing equipment should be prioritized. Organizations can also implement a patch management program that enables a timely and thorough patching cycle. Talos’ top security practices, including those to guide MFA deployment, can be found in our 2024 Year in Review report.

Guidance on securing critical infrastructure

Network security teams should proactively monitor their traffic for APT-associated IP addresses. It is highly recommended to implement the hardening guidelines found in CISA’s ST10-001 documentation and the Cybersecurity Resources Road Map, as these provide a foundational framework for securing network infrastructure against unauthorized access. Any traffic originating from malicious sources — particularly attempts to access remote work services like VPNs, webmail, or administrative interfaces for network hardware — should be treated as a confirmed threat. Furthermore, be aware of the risk posed by the technique identified as MITRE ATT&CK T0835. This involves the manipulation of Programmable Logic Controllers (PLCs), where an adversary alters the device's input/output data. This can cause the controller to ignore safety protocols or perform unintended physical actions, effectively breaking the link between digital control and physical reality. IRGC-affiliated threat actors have in the past exploited in multiple sectors in the U.S.

IOCs

The IOCs are also available on our GitHub repository here.

Seedworm domains/URLs:

• hxxps://iuumfgrrnuhb[.]zhivachkapro[.]com/pobor
• hxxp://terymar[.]com/install/Spf.ps1
• Elvenforest[.]s3.us-east-005.backblazeb2[.]com
• Uppdatefile[.]com
• Gitempire[.]s3.us-east-005.backblazeb2[.]com
• Moonzonet[.]com
• Serialmenot[.]com

Seedworm Loader Script:

• 29b777e7c5470d557e34f3b7b76d2ee291c2dfe7fbaee72821b53eb50a4062c8

Seedworm SHA256 associated with Dindoor:

• 0f9cf1cf8d641562053ce533aaa413754db88e60404cab6bbaa11f2b2491d542
• 1d984d4b2b508b56a77c9a567fb7a50c858e672d56e8cf7677a1fca5c98c95d1
• 2a00705cfd3c15cf8913e9eb4e23968efd06f1feceaef9987d26c5518887d043
• 2a09bbb3d1ddb729ea7591f197b5955453aa3769c6fb98a5ef60c6e4b7df23a5
• 42a5db2a020155b2adb77c00cbe6c6ad27c2285d8c6114679d9d34137e870b3f
• 7467f326677a4a2c8576e71a832e297e794ea00e9b67c4fcbe78b5aec697cec4
• 7c30c16e7a311dc0cdb1cdfd9ea6e502f44c027328dbe7d960b9bcd85ccf5eef
• b0af82de672d81f3c2f153977923b3884a8a9e7045b182c2379b19a1996931a0
• bd8203ab88983bc081545ff325f39e9c5cd5eb6a99d04ae2a6cf862535c9829a
• c7cf1575336e78946f4fe4b0e7416b6ebe6813a1a040c54fb6ad82e72673478e

Seedworm SHA256 associated with Fakeset:

• 077ab28d66abdafad9f5411e18d26e87fe43da1410ee8fe846bd721ab0cb52de
• 15061036c702ad92b56b35e42cf5dc334597e7311e98d2fdd3815a69ac3b1d84
• 2b7d8a519f44d3105e9fde2770c75efb933994c658855dca7d48c8b4897f81e6
• 4aef998e3b3f6ca21c78ed71732c9d2bdcc8a4e0284f51d7462c79d446fbc7be
• 64263640a6fdeb2388bca2e9094a17065308cf8dcb0032454c0a71d9b78327eb
• 64cf334716f15da1db7981fad6c81a640d94aa1d65391ef879f4b7b6edf6e7f1
• 94f05495eb1b2ebe592481e01d3900615040aa02bd1807b705a50e45d7c53444
• a4bd1371fe644d7e6898045cc8e7b5e1562bdfd0e4871d46034e29a22dec6377
• a5d4d6be3bfe0cba23fe6b44984b5fc9c7c7e10030be96120bb30da0f2545d4c
• ddceade244c636435f2444cd4c4d3dc161981f3af1f622c03442747ecef50888
• 74db1f653da6de134bdc526412a517a30b6856de9c3e5d0c742cb5fe9959ad0d

Seedworm SHA256 associated with Darkcomp:

• 1319d474d19eb386841732c728acf0c5fe64aa135101c6ceee1bd0369ecf97b6
• 3df9dcc45d2a3b1f639e40d47eceeafb229f6d9e7f0adcd8f1731af1563ffb90

Seedworm SHA256 associated with Stagecomp:

• 24857fe82f454719cd18bcbe19b0cfa5387bee1022008b7f5f3a8be9f05e4d14
• a92d28f1d32e3a9ab7c3691f8bfca8f7586bb0666adbba47eab3e1a8faf7ecc0

Original Blog - March 2, 2026

Cisco Talos continues to monitor the ongoing conflict in the Middle East. As always, we will be watching closely for any cyber-related incidents that are tied to the conflict. At this time we have not seen any significant cyber impacts, with some small incidents such as web defacements and small-scale distributed-denial-of-service (DDoS) attacks occurring. As with any highly fluid or dynamic situation, we are focused on providing our customers with highly accurate and timely intelligence and information.

Iranian groups involved in this conflict have historically operated primarily in the espionage, destructive attack, and hack-and-leak landscapes. We expect these, along with the mentioned activity, to be the most likely avenues in the near term.

Please see the following Talos research into regional actors in this area:

• Muddy Water, multiple campaigns
• Shrouded Snooper

Outlook on cyber activity

The data has thus far supported the belief that this will be a regional war with a large focus on kinetic activity, but that can change, we’ll continue to monitor and will update accordingly. Currently there does not appear to be any significant increase in cyber activity associated with state-sponsored or state-affiliated groups.

Any possible impacts will likely be from sympathetic groups like hacktivists, some of whom have already launched website defacement and DDoS campaigns in support of Iran. Additionally, cyber criminals are likely to take advantage of the war to try and increase their scope of infections through the use of lures and other social engineering avenues. Users are reminded to be vigilant when clicking links and opening documents, as it is common for criminals to leverage these conflicts as cover for monetary gain.

Talos is well-versed in monitoring wartime environments with our ongoing work in Ukraine and across the globe. We will remain vigilant looking to identify any cyber related activity relevant to the region. If and/or when more relevant information becomes available, we will update this blog accordingly.

Guidance

Recommendations for organizations are currently focused on security hygiene, to include having multi-factor authentication (MFA) enabled, being diligent around any links or documents that are circulating, and ensuring you have proper monitoring in place to ensure you are prepared for any collateral impacts as they arise.

Since this activity appears to be regionally focused, making sure enterprises are aware of any impacts to partners and third-party suppliers in the region will be paramount. Additional inspection or controls may be warranted to insulate potential larger impacts to the wider organization.

Employee awareness: Beware of "hacktivist" lures

• Warn employees against clicking on unsolicited links related to the Middle East conflict, whether news or humanitarian. These are often infostealers or backdoors in disguise and meant to take advantage of emotions.
• Increase the frequency of phishing simulations that use current geopolitical lures to keep staff vigilant against social engineering.

Third-party risk assessment

• Map your dependencies. Identify any vendors, service providers, or developers located in or heavily connected to the Middle East conflict zone.
• Enforce strict MFA for all third-party access and conduct "zero-trust" audits on any administrative tools that have deep access to your environment.

Mitigate "nuisance" attacks and defacements

• Protect your public-facing brand. Use a Content Delivery Network (CDN) with robust DDoS mitigation and ensure all web content management systems (CMS) are fully patched.

As always, ensure all software has been updated to the latest versions to minimize the attack surface and ensure you have a robust patching process. Many updated software versions have improvements in security and visibility capabilities that can help in cyber defense.

Cisco Talos is tracking the active exploitation of CVE-2026-20127, a vulnerability in Cisco Catalyst SD-WAN Controller, formerly vSmart, that allows an unauthenticated remote attacker to bypass authentication and obtain administrative privileges on the affected system by sending a crafted request to an affected system. Successful exploitation may allow the attacker to gain administrative privileges on the Controller as an internal, high privileged, non-root, user account.

Talos clusters this exploitation and subsequent post-compromise activity as “UAT-8616” whom we assess with high confidence is a highly sophisticated cyber threat actor. After the discovery of active exploitation of the 0-day in the wild, we were able to find evidence that the malicious activity went back at least three years (2023). Investigation conducted by intelligence partners identified that the actor likely escalated to root user via a software version downgrade. The actor then reportedly exploited CVE-2022-20775 before restoring back to the original software version, effectively allowing them to gain root access.

UAT-8616's attempted exploitation indicates a continuing trend of the targeting of network edge devices by cyber threat actors looking to establish persistent footholds into high value organizations including Critical Infrastructure (CI) sectors.

Customers are strongly advised to follow the guidance published in the security advisories discussed below. Additional recommendations specific to Cisco are available here. Customers support is also available by initiating a TAC request.  Talos strongly recommends that customers and partners using Cisco Catalyst SD-WAN technology follow the steps outlined in this advisory to help protect their environments.

Initial Peering Event Analysis

The initial and most critical activity to look for is any control connection peering event identified in Cisco Catalyst SD-WAN logs, as this may indicate an attempt at initial access via CVE-2026-20127. All such peering events require manual validation to confirm their legitimacy, with particular focus on vManage peering types. Threat actors who compromise Cisco Catalyst SD-WAN infrastructure often establish unauthorized peer connections that may appear superficially normal but occur at unexpected times, originate from unrecognized IP addresses, or involve device types inconsistent with the environment's architecture. A comprehensive review process is essential to distinguish between legitimate network operations and potential indicators of compromise.

Validation Checklist Items Include

• Verify the timestamp of each peering event against known maintenance windows, scheduled configuration changes, and normal operational hours for your environment.
• Confirm the public IP address corresponds to infrastructure owned or operated by your organization or authorized partners by cross-referencing against asset inventories and authorized IP ranges.
• Validate the peer system IP matches documented device assignments within your Cisco Catalyst SD-WAN topology.
• Review the peer type (vmanage, vsmart, vedge, vbond) to ensure it aligns with expected device roles in your deployment.
• Correlate multiple events from the same source IP or system IP to identify patterns of reconnaissance or persistent access attempts.
• Cross-reference event timing with authentication logs, change management records, and user activity to establish whether the connection was initiated by authorized personnel.

Sample Log Entry

Feb 20 22:03:33 vSmart-01 VDAEMON_0[2571]: %Viptela-vSmart-VDAEMON_0-5-NTCE-1000001: control-connection-state-change new-state:up peer-type:vmanage peer-system-ip:1.1.1.10 public-ip:192.168.3.20 public-port:12345 domain-id:1 site-id:1005 

Log Analysis

In the identified example, the peer-system-ip should be validated as matching the expected IP address schema in-use, the timestamp should be validated as matching any events which might cause a peering event to occur and the public-ip should be validated as being an expected source for a peering event.

Additional Investigative Guidance

The following may be high-fidelity indicators of a successful compromise by UAT-8616 in an SD-WAN infrastructure setup:

• Creation, usage and deletion of malicious user accounts including otherwise absent bash_history and cli-history.
• Interactive root sessions on production systems including unaccounted SSH keys, known hosts and bash history. For example:
  • Notification: system-login-change severity-level:minor host-name:"<node_name>" system-ip:<IP> user-name:""root""
  • SSH Keys in: /home/root/.ssh/authorized_keys with “PermitRootLogin” set to “yes” in /etc/ssh/sshd_config
  • Known hosts in: /home/root/.ssh/known_hosts
• Unauthorized or unaccounted SSH keys (“authorized_keys”) for the “vmanage-admin” account: /home/vmanage-admin/.ssh/authorized_keys/
• Abnormally small logs including absent or size 0/1/2 byte logs.
• Evidence of log and history clearing or truncation including:
  • syslog
  • wtmp
  • lastlog
  • cli-history
  • bash_history
  • Logs residing in /var/log/
• Presence of cli-history file for a user without the bash history.
• Indications of unexplained peers being dropped or added to the environment.
• Unexpected and unauthorized version downgrades and upgrades accompanied by a system reboot. For example (log entries):
  • Waiting for upgrade confirmation from user. Device will revert to previous software version <version> in '100' seconds unless confirmed.
  • Software upgrade not confirmed. Reverting to previous software version
• Evidence of exploitation of CVE-2022-20775 such as specially crafted username path traversal string (E.g. “/../../” or “/\n&../\n&../”).

Recommendations

We strongly recommend that you perform the steps outlined in this document. Cisco has also published a hardening guide for Cisco Catalyst SD-WAN deployments located at https://sec.cloudapps.cisco.com/security/center/resources/Cisco-Catalyst-SD-WAN-HardeningGuide. It is strongly recommended that any customers who are utilizing the Cisco Catalyst SD-WAN technology follow the guidance provided in this hardening guide. We also recommend referring to advisories here and here and the Cisco Catalyst SD-WAN threat hunting guide released by our intelligence partners for additional detection guidance.

Talos Coverage

Talos is releasing the following Snort coverage for this threat and associated vulnerability:

• 65938, 65958