{ "id": "a01bdda9-e25e-4e6d-bd8e-f878bb06b1e2", "created_at": "2026-04-29T02:22:15.888875Z", "updated_at": "2026-04-29T08:21:44.575Z", "deleted_at": null, "sha1_hash": "66f85176a55fbfa291cddb9edf387f831f001945", "title": "Stryker Cyber-Attack: What we Know so Far About the Remote Wipe Attack", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 94930, "plain_text": "Stryker Cyber-Attack: What we Know so Far About the Remote\r\nWipe Attack\r\nBy David Ketler\r\nPublished: 2026-03-27 · Archived: 2026-04-29 02:01:52 UTC\r\nTable of Contents\r\nStryker Cyber-Attack: What we Know so Far About the Remote Wipe Attack\r\nWhat happened in the Stryker cyber-attack?\r\nChronological post-attack activity\r\nWhat we know about Handala\r\nWhat this means for defenders\r\nDefender strategies\r\nHow Specops helps\r\nstryker cyber-attack vsphere control panel\r\nTable of Contents\r\nStryker Cyber-Attack: What we Know so Far About the Remote Wipe Attack\r\nWhat happened in the Stryker cyber-attack?\r\nChronological post-attack activity\r\nWhat we know about Handala\r\nWhat this means for defenders\r\nDefender strategies\r\nHow Specops helps\r\nDavid Ketler\r\nOn March 11, 2026, the Iranian hacktivist group Handala Hack Team claimed responsibility for a cyber-attack\r\nagainst the American healthcare technology company Stryker. According to public reporting, the attackers claimed\r\nto have impacted more than 200,000 systems and exfiltrated approximately 50 terabytes of data. While these\r\nfigures remain unverified, the operational disruption alone places this incident among the more significant\r\nenterprise cyber-attacks of the year so far.\r\nWhat happened in the Stryker cyber-attack?\r\nMedia reporting indicates that the attackers obtained Global Administrator-level access within Stryker’s Microsoft\r\nenvironment, giving them control over core administrative services, including endpoint management.\r\nhttps://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nPage 1 of 6\n\nBleeping Computer, citing an anonymous source described as familiar with Stryker’s internal response, reported\r\nthat the attackers may have used Microsoft Intune to issue remote wipe commands between approximately 5:00\r\nand 8:00 a.m. UTC on March 11. An estimated 80,000 devices enrolled in Stryker’s unified endpoint management\r\nservice were reportedly impacted.\r\nBecause these actions appear to have been carried out through a legitimate administrative system, the disruption\r\nspread quickly. Employees across multiple regions reported devices being wiped overnight. Enrolled personal\r\ndevices were also reportedly affected, resulting in the loss of personal data. As the activity became apparent,\r\nemployees were instructed to power down devices in an attempt to limit further impact.\r\nStryker stated on March 15, 2026 that it remained confident its products and services were safe to operate and that\r\nno connected products had been compromised:\r\n“This was not a ransomware attack, and there is no evidence of malware deployed to our systems. The incident\r\nhas been contained, and we are now in the restoration process, which is progressing steadily.”\r\nHow did Handala access Stryker?\r\nHow the attackers first gained access has not been confirmed. One possible explanation is the use of compromised\r\ncredentials, potentially sourced from infostealer activity or other exposed authentication pathways. Supporting\r\nthat possibility, threat intelligence researchers at Outpost24, Specops’ parent company, identified compromised\r\ncredentials associated with the stryker.com domain within its telemetry.\r\nBetween October 2025 and March 2026, a total of 278 compromised credentials were observed, with 138 linked\r\nto activity in 2026. Of these, 83 were observed in the pre-incident window between February 15 and March 11,\r\ncorresponding to 31 unique email accounts. This shows a concentration of credential exposure in the weeks\r\nleading up to the attack, although it does not establish a direct link to the intrusion.\r\nThe majority of this activity was tied to Microsoft authentication endpoints, including:\r\nmicrosoftonline.com: 248 instances, primarily login.microsoftonline.com\r\noffice365.com: 29 instances\r\nmicrosoft.com: 1 instance\r\nThis does not confirm the initial access vector, but it does show that exposed credentials linked to the organization\r\nwere in circulation prior to the incident. It is also worth noting that Microsoft enforced multi-factor authentication\r\non administrative accounts in late 2025.\r\nIf an administrative account was involved, the attackers may have needed to steal a valid session or token or\r\nsocially engineer an administrator into approving or surrendering MFA access. However, the exact sequence of\r\nevents remains unconfirmed.\r\nThe incident reflects a broader pattern in which attackers abuse trusted administrative tools after gaining\r\nprivileged access, instead of relying on ransomware or other traditional malware. In this case, the available\r\nreporting suggests that access to a privileged account, or successful privilege escalation, may have enabled remote\r\nwipe activity at scale.\r\nhttps://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nPage 2 of 6\n\nChronological post-attack activity\r\nMarch 16 2026\r\nHandala published additional screenshots claiming significantly higher levels of impact, including the wiping of\r\n12 petabytes of data and access to Rubrik Secure Vault backups and vSphere control panels.\r\nRubrik secure vault\r\nvsphere control panel\r\nstryker cyber-attack vsphere control panel\r\nStryker’s Rubrik Secure Vault and VSphere Control Panel that Handala supposedly accessed\r\nThese claims remain unverified and should be treated with caution. As with many incidents involving destructive\r\nactivity, attacker claims may be exaggerated to increase perceived impact.\r\nIt remains unclear whether Stryker was deliberately targeted or opportunistically compromised. Reporting by The\r\nWashington Post suggests the attack may have been framed by the group as part of a broader geopolitical\r\nnarrative, although this has no bearing on the technical execution of the intrusion.\r\nMarch 19 2026\r\nInfrastructure associated with the group’s public communications was seized by US law enforcement, including\r\ndomains used to publish updates. While this may disrupt their ability to distribute messaging, it is unlikely to\r\naffect their operational capability.\r\nfbi takedown notice\r\nFBI takedown notice\r\nHandala statement on website seizure\r\nScreen shot of Handala’s response to its website take-down\r\nA second domain, Handala RedWanted, was also seized. In response, the group signaled its intent to continue\r\noperations and establish new infrastructure. Subsequent posts on its replacement site included retaliatory\r\nmessaging linked to regional tensions, including threats of further action if Iranian power infrastructure was\r\ntargeted and imagery claiming to identify Israeli critical infrastructure.\r\nHandala’s site has since returned, on the same registrar (with the same top-level domain) with a new domain\r\nname. On March 24, the group further escalated its rhetoric by publishing an unverified $50 million bounty threat\r\nagainst US President Donald Trump and Israeli Prime Minister Benjamin Netanyahu. These posts are more\r\nappropriately assessed as influence and intimidation activity than as reliable indicators of capability or intent.\r\nMarch 26 2026\r\nhttps://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nPage 3 of 6\n\nIn an escalation of activity targeting US organizations, Handala claimed via Telegram to possess sensitive data\r\nlinked to Lockheed Martin, a major US-based aerospace and defense company that designs, builds, and supports\r\nmilitary and government systems.\r\nIn a related post, the group published personal data of 28 employees based in the Middle East, including names,\r\naddresses, and passport images. It alleged these individuals were involved in “critical” projects, including F-35\r\nand F-22 maintenance, and shared supposed direct communications warning them to leave within 48 hours.\r\nHandala Telegram post signaling alleged Lockheed Martin targeting\r\nHandala Telegram post signaling alleged Lockheed Martin targeting\r\nSeparately, a group identifying as APT Iran also claimed a breach of Lockheed Martin, alleging the exfiltration of\r\n375 terabytes of data and demanding a $400 million ransom. The group claims to have copies of blueprints of F-35 aircraft, which is America’s most advanced jet fighter, and other corporate information, according to\r\nFlashpoint.\r\nA spokesperson for Lockheed Martin said the company is aware of the alleged claims.\r\n“We are aware of the reports and have policies and procedures in place to mitigate cyber threats to our business,”\r\nthe spokesperson told Cybersecurity Dive via email. “We remain confident in the integrity of our robust,\r\nmultilayered information systems and data security.”\r\nWhat we know about Handala\r\nHandala is an online persona associated with a broader Iranian threat cluster linked to the Ministry of Intelligence\r\nand Security (MOIS). The group is also tracked by some vendors under names including Void Manticore and has\r\nbeen linked to a wider set of coordinated operations aligned with Iranian state interests.\r\nThe actor operates under other personas, including Homeland Justice and previously Karma, which have been\r\nused in campaigns targeting government, telecommunications, and critical infrastructure sectors, particularly in\r\nAlbania and Israel.\r\nThe group’s activity is characterized by the use of compromised credentials, manual access within victim\r\nenvironments, and the deployment of destructive actions such as wiping, deletion, and disk encryption. These\r\noperations are often accompanied by public claims and data leak activity.\r\nIts reliance on widely available tooling and anonymized infrastructure, including commercial VPN services,\r\nmakes its activity harder to attribute and limits the effectiveness of static indicators. Its operations tend to be short-lived, with a focus on speed and impact rather than persistence.\r\nWhat this means for defenders\r\nAttackers are shifting away from brute force and toward infostealer malware, which extracts high-value identity\r\ndata directly from compromised endpoints, including credentials, session tokens, and access to SaaS and\r\nadministrative portals.\r\nhttps://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nPage 4 of 6\n\nThese credentials are then sold or reused, allowing attackers to bypass perimeter defenses entirely. When a valid\r\ncredential is used, especially one with administrative privileges, activity often appears legitimate and may not\r\ntrigger controls such as MFA.\r\nDefenders should review how conditional access and device compliance policies are enforced. In many\r\nenvironments, these controls are inconsistently applied or relaxed to reduce friction, allowing unmanaged or non-compliant devices to access corporate systems.\r\nThis incident also highlights a key limitation of tools like Microsoft Entra ID Password Protection. While effective\r\nat blocking weak passwords, they do not account for real-time credential exposure. As shown in Specops research,\r\npasswords that meet complexity requirements continue to appear in infostealer datasets.\r\nDefender strategies\r\n1. Enforce least privilege and privileged access governance\r\nAdministrative privileges should be minimized and segmented wherever possible. Implement just-in-time access,\r\napproval workflows, and session monitoring to reduce the risk of persistent high-level access being abused.\r\n2. Validate device trust before granting access\r\nAccess decisions should not rely on identity alone. Devices requesting access to corporate resources should be\r\ncontinuously assessed for security posture, including patching status, configuration, and risk signals. This helps\r\nprevent compromised or unmanaged devices from being used as a launch point for further activity.\r\nSpecops Device Trust delivers that validation by authenticating both user and device at the point of access and\r\nthroughout each session. Devices are checked continuously for issues like threats, outdated software and disabled\r\nsecurity controls, giving teams full visibility into every device connecting to internal networks. Devices can be\r\nbound to specific identities, mitigating the risk of attackers using legitimate credentials on their own hardware.\r\n3. Monitor and restrict use of administrative tooling\r\nEnterprise management platforms such as endpoint management and remote administration tools should be treated\r\nas high-risk systems. Logging, alerting, and behavioral monitoring should be in place to detect unusual or large-scale actions, such as mass device wipes or configuration changes.\r\n4. Improve visibility across identity and endpoint activity\r\nSecurity teams should correlate identity events with endpoint and management plane activity to identify\r\nsuspicious patterns early. Rapid detection of anomalous behavior, such as privilege escalation or unusual\r\ncommand execution, is key to limiting impact.\r\n5. Plan, test, and rehearse for a worst-case scenario\r\nOrganizations should ensure that backups are secure, segmented, and regularly tested. Recovery plans should\r\naccount for scenarios where administrative tools are abused, not just ransomware encryption events.\r\nhttps://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nPage 5 of 6\n\nHow Specops helps\r\nThe Stryker incident highlights a fundamental issue; access decisions are still too heavily reliant on identity alone.\r\nSpecops addresses this by combining breached password detection, secure resets, enforced MFA, and device-based access controls. This means that even if credentials are exposed, access is restricted to trusted users on\r\ntrusted devices.\r\nBy validating both identity and device posture at login and throughout the session, these controls reduce the risk\r\nof administrative tooling being misused after initial access.\r\nDownload our white paper The Missing Piece in Zero Trust: Device Trust at Every Access Point to see how device\r\ntrust strengthens access decisions across the full session lifecycle. Or contact us to learn how Specops can support\r\nyour identity security strategy.\r\nLast updated on March 30, 2026\r\nDavid Ketler\r\nWritten by\r\nDavid Ketler\r\nDavid Ketler is a cybersecurity consultant based in Toronto, Canada with 10+ years of experience in software\r\ndevelopment and cybersecurity. He writes about password cracking, dark web activity, and password\r\nmanagement.\r\nSource: https://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nhttps://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://specopssoft.com/blog/stryker-cyber-attack-what-we-know-remote-wipe/" ], "report_names": [ "stryker-cyber-attack-what-we-know-remote-wipe" ], "threat_actors": [ { "id": "d0fef355-9eb9-4adc-8d90-a8c7494c4a81", "created_at": "2024-01-18T02:02:34.735032Z", "updated_at": "2026-04-29T06:58:58.319199Z", "deleted_at": null, "main_name": "Handala Hack Team", "aliases": [ "Operation HamsaUpdate" ], "source_name": "ETDA:Handala Hack Team", "tools": [ "Hamsa Wiper", "Handala", "Hatef Wiper" ], "source_id": "ETDA", "reports": null }, { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-29T06:58:58.13853Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null }, { "id": "13e58cc3-9acc-4564-8f84-b8cc0082ee4a", "created_at": "2024-05-23T02:00:03.982213Z", "updated_at": "2026-04-29T06:58:56.874742Z", "deleted_at": null, "main_name": "Void Manticore", "aliases": [], "source_name": "MISPGALAXY:Void Manticore", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "4134675e-5b72-4b50-8d70-1a8f18aafbb4", "created_at": "2024-10-04T02:00:04.766263Z", "updated_at": "2026-04-29T06:58:56.933227Z", "deleted_at": null, "main_name": "Handala", "aliases": [], "source_name": "MISPGALAXY:Handala", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "704af71f-d1ed-4252-88a9-d23a17e4b7b4", "created_at": "2026-04-29T02:00:04.621965Z", "updated_at": "2026-04-29T06:58:57.779286Z", "deleted_at": null, "main_name": "VOID MANTICORE", "aliases": [ "VOID MANTICORE", "COBALT MYSTIQUE", "Handala Hack", "Homeland Justice", "Karma", "Karmabelow80", "BANISHED KITTEN", "Red Sandstorm" ], "source_name": "MITRE:VOID MANTICORE", "tools": null, "source_id": "MITRE", "reports": null }, { "id": "7f25e108-e694-49b6-a494-c8458b33eb3f", "created_at": "2024-01-09T02:00:04.199217Z", "updated_at": "2026-04-29T06:58:56.744414Z", "deleted_at": null, "main_name": "HomeLand Justice", "aliases": [], "source_name": "MISPGALAXY:HomeLand Justice", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "20c759c2-cd02-45bb-85c6-41bde9e6a7cf", "created_at": "2024-01-18T02:02:34.189827Z", "updated_at": "2026-04-29T06:58:57.946937Z", "deleted_at": null, "main_name": "HomeLand Justice", "aliases": [ "Banished Kitten", "Karma", "Red Sandstorm", "Storm-0842", "Void Manticore" ], "source_name": "ETDA:HomeLand Justice", "tools": [ "BABYWIPER", "BiBi Wiper", "BiBi-Linux Wiper", "BiBi-Windows Wiper", "Cl Wiper", "LowEraser", "No-Justice Wiper", "Plink", "PuTTY Link", "RevSocks", "W2K Res Kit" ], "source_id": "ETDA", "reports": null }, { "id": "b3ebf51d-8f64-48a9-bbfb-674db872cccb", "created_at": "2025-08-07T02:03:24.769383Z", "updated_at": "2026-04-29T06:58:57.629299Z", "deleted_at": null, "main_name": "COBALT MYSTIQUE", "aliases": [ "Banished Kitten ", "DEV-0842 ", "Druidfly ", "Handala Hack Team", "Homeland Justice", "Karmabelow80", "Red Sandstorm ", "Storm-0842 ", "Void Manticore " ], "source_name": "Secureworks:COBALT MYSTIQUE", "tools": [ "AllinOneNeo", "Bibi", "GramPy", "GramPyLoader" ], "source_id": "Secureworks", "reports": null } ], "ts_created_at": 1777429335, "ts_updated_at": 1777450904, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/66f85176a55fbfa291cddb9edf387f831f001945.pdf", "text": "https://archive.orkl.eu/66f85176a55fbfa291cddb9edf387f831f001945.txt", "img": "https://archive.orkl.eu/66f85176a55fbfa291cddb9edf387f831f001945.jpg" } }