DEV Community: Etairos.ai

Trezor Confirms Cellular Implants in CryptoBilis-Sold Safe 5 Wallets That Steal Recovery Phrases

Etairos.ai — Sun, 15 Nov 2026 15:06:05 +0000

TL;DR

what: Trezor confirmed that three Safe 5 wallets bought from reseller CryptoBilis carry an extra circuit board that reads the recovery phrase from the screen and sends it to an attacker server over a mobile network.
impact: Any recovery phrase or passphrase shown or typed on an implanted device is compromised, and Ledger has already tied implants from the same reseller to a coordinated wallet-draining operation.
fix: Trezor firmware 2.13.1 for the Safe 7, Safe 5, Safe 3 and Model T stops the known implants from capturing data, and Trezor tells CryptoBilis buyers to move funds to a new wallet with a new recovery phrase and contact Trezor Support for a free replacement.
who: Anyone who bought a Trezor from CryptoBilis since March 2026, including through its Tokopedia and Shopee stores, and anyone who is unsure where their device came from.

Trezor has confirmed that three Safe 5 hardware wallets sold by CryptoBilis, which until recently was an official Trezor reseller in Southeast Asia, contain a hidden circuit board. The board copies recovery phrases off the device screen and sends them over a mobile network to a server run by the attackers. Trezor disclosed the finding on November 12, 2026. The implant does not touch the wallet firmware or the Secure Element. Every software integrity check on the device therefore passes, even while the seed is being sent out over cellular.

Trezor is now the second hardware wallet maker to confirm implants in devices from this reseller. Ledger had already confirmed tampered Ledger units sold by CryptoBilis, and said the attackers drained wallets in a single coordinated operation. Trezor says its implants work the same way as Ledger's, adapted to the Safe 5 display.

What the Implant Does

Trezor engineers examined one wallet in the company's lab, then extracted and analyzed the implant's firmware. They identified the other two from photos sent in by the owners. All three wallets were bought between August 20 and September 23, 2026. Trezor reports the following behavior:

Placement: the board sits between the Safe 5 main board and its screen. It captures what the screen shows and leaves the wallet's own components untouched.
Capture points: it copies the recovery phrase when the wallet displays it during backup creation, and when a user types it in to restore an existing wallet onto the device.
Passphrase capture: it also copies any passphrase that appears on the screen, so the optional extra layer of protection is captured too.
Exfiltration: it encrypts the captured data and sends it to attacker infrastructure over a mobile network. It does not need the host computer or the user's network.
Persistence: if it cannot connect, it stores the data and keeps retrying until the upload succeeds.

The store-and-retry behavior means a wallet kept somewhere with no signal after setup is still exposed. The phrase stays on the implant until the device gets a connection.

⚠️ Integrity checks cannot see this — Trezor found the firmware and Secure Element unmodified on the analyzed device. Firmware signature checks and device authenticity flows only confirm the components the implant leaves alone. A device can pass every software check and still leak its seed.

Timeline

August 20 to September 23: the three affected Safe 5 units are purchased from CryptoBilis.
October 9: Ledger starts investigating fund losses among CryptoBilis customers. Trezor removes CryptoBilis as an official reseller the same day.
October 13: Trezor announces on X that it is cutting its reseller network by about 80%.
October 28: a buyer reports a suspected implant to Trezor.
October 30: Trezor publishes a warning before its lab has examined the device.
Week of November 9: Trezor releases firmware 2.13.1 for the Safe 7, Safe 5, Safe 3 and Model T.
November 12: Trezor confirms implants in three Safe 5 wallets.

The Vendor Fix and Its Limits

Trezor says firmware 2.13.1 stops the implants found so far from capturing anything on wallets that run it. The company has not said how the protection works. It is withholding technical details that could help attackers or put customers at risk. The release has one hard limit, in Trezor's words: "the update can't protect a wallet backup that was captured before it." Any phrase shown or typed on an implanted device before the update has to be treated as known to the attacker. Restoring that phrase on a clean device does not help, because the attacker already has it.

Trezor's guidance has not changed for anyone who bought a Trezor from CryptoBilis since March 2026, including through the reseller's Tokopedia and Shopee stores. The company says to move funds to a new wallet with a new recovery phrase. It says not to set up an unused wallet from the reseller and never to type an existing phrase into one. Buyers should keep the device and contact Trezor Support, which offers a replacement wallet to every CryptoBilis buyer since March. Trezor also says weighing or opening the device is not a reliable test. The company will never ask for a recovery phrase, and it warns that scammers may pose as Trezor to offer replacements or refunds.

What Is Confirmed and What Is Not

Confirmed so far: three implanted wallets, all Safe 5, all sold by CryptoBilis. After the October reports, 48 CryptoBilis buyers contacted Trezor. The company is checking their wallets in its lab or from photos of the insides, but it has not said how many it has checked. It has found no implants in wallets from its other resellers or in its other models. None of the three owners has reported lost funds. Trezor wallets are self-custodial, though, so the company cannot see balances and depends on what owners tell it.

Trezor has not said who fitted the implants or where in the supply chain that happened. It will publish an update if it confirms an implant outside CryptoBilis stock or the Safe 5, gets a report of losses linked to the implants, or ships new protections. Ledger's case had already gone past capture to actual draining. That makes the lack of reported Trezor losses a point-in-time fact, not evidence that the Trezor implants were never used.

The Reseller Cut

Trezor announced the roughly 80% cut to its reseller network on October 13. That was more than two weeks before the first implant report involving its own wallets. The company says the cut dropped trustworthy partners that posed no immediate threat but did not meet its stricter new rules. A partner letter sent that day told the dropped resellers they would get no new stock, could sell existing inventory until January 1, 2027, and would then come off the authorized seller list. Stock from those channels can therefore keep reaching buyers for about seven more weeks, under rules Trezor itself has now judged too loose.

Authorized did not mean safe — CryptoBilis was an official, listed Trezor reseller while the affected units were sold. Buying from an authorized channel was the standard advice, and here it failed. The compromise happened inside the trusted channel.

RedEye Analysis

This campaign targets the gap between a device's secure core and its display. The secure element and signed firmware did their job, and none of it mattered: the secret appeared on a screen, and the attacker owned the wire leading to that screen. The same design gap exists in any hardware that shows or accepts secrets through a peripheral the trusted chip does not authenticate. The implant uses its own cellular link instead of the host network, so network monitoring and endpoint telemetry would not have seen the exfiltration.

For organizations that hold treasury, signing keys or custody keys on hardware wallets, the lesson is about procurement as much as technology. Two major vendors have now confirmed physical implants from one regional reseller within about a month of each other. Hardware that holds high-value secrets needs chain-of-custody records from the manufacturer to the person who sets it up. A reseller's authorized status is not enough to establish that.

Originally published on RedEye Threat Intelligence.

PHP2Shell and CVE-2026-123039: Check Point Gateways Hit With TSGA Backdoor, Then ESXi Wiper

Etairos.ai — Sat, 14 Nov 2026 21:04:34 +0000

TL;DR

what: Attackers used PHP2Shell (CVE-2026-109618, CVE-2026-109619) to break into Check Point Mobile Access portals, then used a new Gaia OS flaw, CVE-2026-123039, to get root and install the TSGA backdoor.
impact: About two dozen customers were hit by the root exploit, and some Israeli victims lost VMware ESXi data to the destroy_v6 wiper after the attackers moved from the gateway over SSH.
fix: Install Check Point's fixes for CVE-2026-123039 and the PHP2Shell CVEs on R81 through R82.20; CISA requires federal agencies to patch by November 16, 2026.
who: Any organization running unpatched Check Point Security Gateways with Mobile Access exposed, and anyone running affected Management, Log, Multi-Domain or Maestro Orchestrator builds.

An unknown threat actor has broken into unpatched Check Point Security Gateways, taken root on the appliance, installed a gateway-specific backdoor, and in some cases used that foothold to wipe VMware ESXi hosts further inside the network. Check Point says the root escalation step, CVE-2026-123039, was used against about two dozen customers. CISA added it to the Known Exploited Vulnerabilities catalog on November 13, 2026, and gave federal agencies until November 16 to patch.

The campaign began on October 30, 2026, against Israeli organizations, about one week after a fix for the PHP2Shell flaws was released. A second, wider wave on November 2 hit organizations in several countries and sectors with no clear targeting pattern, which points to an opportunistic push for initial access.

The Intrusion Chain

Check Point traced the first wave to 130.94.19[.]204 scanning Mobile Access portals on Security Gateways. The activity matched PHP2Shell, tracked as CVE-2026-109618 and CVE-2026-109619, and some of those attempts led to confirmed compromises. PHP2Shell gave the attacker code execution as the portal service account. That is not root, so a second bug was needed.

That second bug is CVE-2026-123039, a missing authorization flaw in the Gaia OS DynamicCLI process. Any authenticated local user can run arbitrary commands as root by writing a single request to the DynamicCLI socket. On its own it is a local escalation and needs existing code execution on the box. Chained after PHP2Shell, it turns an exposed web portal into full control of the firewall.

Initial access: PHP2Shell (CVE-2026-109618, CVE-2026-109619) through Mobile Access portals
Privilege escalation: CVE-2026-123039 through the DynamicCLI socket, portal service account to root
Persistence: PHP web shells with command execution and file upload
Implant: TSGA, deployed as slot_CPconfigdaemon, with its embedded TSProxy component
Discovery: the gogo scanner, run from the gateway to map internal assets and services
Lateral movement: SSH to a VMware ESXi host using the vpxuser service account
Impact: the destroy_v6 wiper plus DREAM_ANNEXATION.txt notes

Affected Versions

CVE-2026-123039 affects R82.20, R82.10, R82, R81.20, R81.10 and R81 on Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator. The PHP2Shell entry point needs Mobile Access exposed. Because the escalation works on any affected build, any other route to local code execution on these appliances leads to the same root result.

⚠️ Patch Window Was About One Week — Exploitation of PHP2Shell started about seven days after the fix shipped. Any gateway with Mobile Access exposed that was still unpatched on October 30 should be handled as possibly compromised, not just vulnerable. Patching closes the hole but does not remove TSGA, web shells or stolen configuration data.

TSGA and TSProxy: Built for Check Point

TSGA is a standalone passive Linux backdoor written specifically for Check Point appliances. It provides encrypted remote access, steals configuration, survives through backup and snapshot persistence, injects into processes, and tampers with binary firewall logs. That last capability matters most for defenders: the device that is supposed to record the intrusion can be made to hide it.

TSProxy is a library that TSGA injects into selected appliance processes. It hooks networking functions so that connections carrying the attacker's marker go to the implant, while normal traffic passes through as usual. In Check Point's words, this pairs "a persistent standalone backdoor with concealed access through existing appliance services." The attacker gets no new listening port to find, only legitimate services that quietly respond to a second set of clients.

From Firewall to Hypervisor

Once root on the gateway, the attackers ran the gogo scanner to map the internal network, then moved over SSH to a VMware ESXi host by logging in as vpxuser, the account vCenter uses to manage ESXi. There they staged destroy_v6, a Linux ELF wiper that walks the target directory recursively, tries to overwrite each file with zeros, and deletes everything regardless of file extension. Each directory it processed got a DREAM_ANNEXATION.txt note with political content tied to the Israeli-Palestinian conflict.

The destructive stage hit some of the organizations from the first, Israel-focused wave. Wiping a hypervisor takes out every guest VM on it at once, which explains why the attackers went after ESXi instead of individual servers.

Attribution Is Unresolved

TSGA and TSProxy are assessed to be Check Point-specific parts of PhiliKit, a toolkit ESET documented in June 2026 and attributed to Armory Castle, the China-nexus espionage group formerly tracked as UNC5221. Other clues fit a China-aligned operator: LightNode VPS infrastructure, and scanning concentrated between 12 and 9 a.m. UTC, which lines up with Chinese working hours.

Check Point still declines to attribute the campaign. Wipers and Israel-focused political messaging do not fit the known behavior of Armory Castle or other China-nexus espionage groups. The company lists several possibilities: the identified actor ran the whole operation, acted only as an initial access broker, or took part in a false flag. It also notes the destruction may have been a smoke screen to cover the espionage.

RedEye Assessment — Whoever was at the keyboard, the tooling is mature and built for one vendor, and the gap between patch and exploitation was one week. Gateway implants that hook legitimate services and alter firewall logs defeat log-based detection on the device itself. Evidence of compromise is more likely to show up in off-box telemetry: NetFlow, upstream logs and ESXi authentication records.

Vendor Fix and Federal Deadline

Check Point has released fixes for the PHP2Shell flaws and for CVE-2026-123039 across the affected R81 and R82 branches, and has published the technical details and indicators, including 130.94.19[.]204, the slot_CPconfigdaemon implant name, the destroy_v6 wiper, and the DREAM_ANNEXATION.txt note. CISA's KEV listing requires federal civilian agencies to remediate CVE-2026-123039 by November 16, 2026. Patching blocks new compromises. Gateways exposed during the window need a compromise assessment, because TSGA was designed to persist through backups and snapshots.

RedEye Security can assess whether your Check Point estate and connected virtualization infrastructure show signs of this campaign. Contact our team for a compromise assessment.

Originally published on RedEye Threat Intelligence.

Poisoned QBase Update Grounds German Military Drones: The Update Server Is Now a Weapons System

Etairos.ai — Sat, 14 Nov 2026 15:06:07 +0000

TL;DR

what: Quantum Systems confirmed a late October cyberattack by hostile actors, and Der Spiegel and the Financial Times report that a malicious QBase update was pushed to customers from the vendor's update distribution server.
impact: The German armed forces reportedly grounded Quantum Systems drones, including missions planned with QBase for the Vector (Falke) reconnaissance drone, and left the company's systems out of a recent military exercise.
fix: Quantum Systems says it worked with authorities so its unmanned systems could safely resume operations, and the source names no patched version, CVE or published remediation.
who: Operators of Quantum Systems drones and QBase, plus any defense supplier whose public support for Ukraine makes its software distribution chain a target.

In late October, customers running QBase, the ground-control and mission-planning software from German defense technology company Quantum Systems, received an update nobody had scheduled. According to Der Spiegel and the Financial Times, citing internal sources, it was malicious, and it came from the vendor's own update distribution server. The German armed forces reportedly grounded Quantum Systems drones as a precaution and left the company's systems out of a recent military exercise.

So the attacker never had to touch an aircraft to keep a fleet on the ground. Compromising the channel the vendor uses to keep that fleet up to date was enough.

What happened

Quantum Systems builds reconnaissance and interceptor drones, other unmanned systems, and the software that controls them. Germany's military flies its drones. Der Spiegel named the Vector reconnaissance drone, called Falke in German service, as one of the aircraft whose missions are planned in QBase.

The company confirmed it detected an incident in late October that was part of an active cyberattack by "hostile actors." It says it worked with the relevant authorities to resolve the issue and make sure its unmanned systems could safely resume operations. Three federal bodies are reportedly involved: the military counterintelligence service (MAD), the domestic intelligence service (BfV), and the federal cybersecurity agency (BSI).

The gaps in the record matter as much as the facts. Der Spiegel reports that the unscheduled update raised alarms inside Quantum Systems, but it is unclear how many customers installed it. Nobody has publicly described what the payload did. Quantum Systems has not attributed the attack to any specific actor.

Confirmed vs. reported vs. unknown — Confirmed by Quantum Systems: an incident detected in late October, an active attack by hostile actors, and work with state authorities. Reported by Der Spiegel and the Financial Times from internal sources: a malicious QBase update delivered through the update distribution server, the grounding of drones, and their exclusion from an exercise. Still unknown: how many customers installed it, what the payload did, and who was behind it.

Why Quantum Systems

Quantum Systems believes it was targeted because it recently announced support for Ukraine. The timing fits. In October, Germany announced funding to build tens of thousands of Quantum Systems interceptor drones in Ukraine for Ukrainian forces. "The European defense industry has been facing persistent cyberattacks for years," the company said. "Companies at the forefront of supporting Ukraine are being targeted precisely because our work is critically relevant to customers' security."

There is also a pattern. In July, Australian drone maker CubePilot, which also openly supports Ukraine, was hit by a DNS hijacking attack that caused severe operational disruption. BleepingComputer notes that DNS hijacking could be used to send malicious updates to CubePilot's downstream users, but that level of compromise was never confirmed. That makes two drone vendors that publicly back Ukraine, each hit through the infrastructure between the vendor and its customers, about four months apart.

The RedEye take

For a defense supplier, the update server is now a weapons-adjacent system and should be defended like one. It is the shortest path to every customer in the field at the same time. The attacker's most dependable effect here was doubt, not code running on a drone. Once a customer cannot trust the last update, the rational move is to ground the fleet, and that is reportedly what happened. Forcing a military to stand down an asset during an exercise is an operational result, and the attacker got it without proving that a single implant was installed.

Every vendor with a public political position should take this personally. Announcing support for Ukraine is a legitimate business and policy decision. It also changes the company's threat model overnight, and the security budget has to move as fast as the press release. Quantum Systems caught an off-cycle update and raised the alarm internally, which means detection worked. The failure is further upstream: an attacker got to the point where the vendor's own channel could ship a malicious file at all.

Credit where it is due: an internal alarm on an unscheduled update, and a customer willing to ground assets on suspicion, is what mature response looks like. The weak point was prevention, not reaction.

⚠️ The availability trap — A poisoned update channel does damage even if almost nobody installs the file. Not knowing who installed it is enough to take dependent systems offline for the whole investigation.

What defenders should learn

An unscheduled update is an incident signal, not a convenience. Quantum Systems reportedly noticed because the push was off-cycle. Organizations that accept vendor updates on any schedule give that signal up entirely.
Your supplier's geopolitics is your risk. When a vendor takes a public position, such as backing Ukraine, attacks on that vendor and on everyone downstream can rise. Vendor risk reviews should be reopened when a supplier's public posture changes, not only at contract renewal.
Budget for the cost of distrust. The reported grounding shows that an unconfirmed install can still cost operational capacity. Continuity plans should assume a compromised update channel can take a dependent system offline for as long as the investigation runs.
Knowing who has which build is a security control. Reporting says no one can yet say how many customers installed the file. Vendors and customers who can answer that within hours shrink the grounding window from weeks to days.
The distribution path includes DNS. CubePilot shows the same goal can be pursued by hijacking DNS instead of breaching a server. Domain integrity and update server integrity belong in the same threat model.

The bottom line

The Quantum Systems incident is still under investigation by MAD, BfV and BSI, and important facts, including install count and payload, are not public. The strategic point does not depend on them. Pro-Ukraine defense suppliers are being targeted through the channels their customers trust most, and a single poisoned update was enough to ground drones in military service. Any organization that relies on vendor-pushed software for critical operations should assume its suppliers are in the same position.

Source: BleepingComputer, "German military drone operations disrupted by cyberattack," Bill Toulas, November 13, 2026, citing reporting by Der Spiegel and the Financial Times. https://www.bleepingcomputer.com/news/security/german-military-drone-operations-disrupted-by-cyberattack/

Originally published on RedEye Threat Intelligence.

SilentAir Hijacks Signaling Gear in Asian Mobile Operators to Steal SMS 2FA Codes from Taiwanese Targets

Etairos.ai — Fri, 13 Nov 2026 15:04:47 +0000

TL;DR

what: A state-level group Enea calls SilentAir took over signaling equipment inside Asian mobile operators and used it to send forged SS7 and Diameter location updates that diverted targets' calls and texts.
impact: Some diversions worked, and Enea saw 2FA codes intercepted right after they took effect, with victims mostly in Taiwan and including political and government VIPs.
fix: Enea has told the affected operators where the SilentAir sources are and says the group is disrupted for now, but the report does not confirm that the hacked equipment has been cleaned up.
who: Subscribers of Taiwanese and other Asian mobile networks, especially government and political figures and anyone whose accounts depend on SMS one-time codes.

A state-level espionage group has been using hacked equipment inside mobile operators in at least six Asian countries to divert the calls and texts of selected subscribers, mostly in Taiwan. Enea, the Stockholm-based telecom security company that named the group SilentAir this week, saw two-factor authentication codes being intercepted right after some diversions took effect. Interception made up 18.3% of the SilentAir attacks Enea observed. In Enea's earlier research, the share for a typical commercial surveillance firm was 2.1%, so SilentAir's rate is almost nine times higher.

Enea assesses with high confidence that SilentAir is a state-level actor. It links the group to China only with low confidence. Enea has told the affected operators where it found SilentAir sources and says the group is disrupted for now but could return. The report does not name any countries, operators or targets, and it does not say whether the hacked equipment has been cleaned up.

How the Interception Works

Mobile operators exchange signaling messages over SS7 and Diameter. These messages route calls and texts and make roaming possible. The traffic crosses the IPX, a shared interconnect network that runs on a high level of trust between operators. SilentAir did not spoof its way into that network. It sent its attacks from equipment inside real operators that it had already compromised.

To intercept a target, SilentAir sent the target's home network an UpdateLocation message, or the Diameter equivalent, claiming that the hacked equipment was now serving the target's phone. When the home network accepted the message, calls and texts for that subscriber were sent to the attackers. Some of these attacks worked. For some targets, Enea saw 2FA codes intercepted right after the diversion took effect, which points to attempts to break into other accounts registered to those people. The report has no similar evidence for voice calls and does not say whether any account was actually taken over.

⚠️ SMS 2FA is the payload — While a diversion is active, every one-time code sent to the victim's number goes to the attacker's equipment, and the victim's phone gives no sign that anything is wrong. Any account protected only by SMS codes is exposed for as long as the diversion lasts. The victim's own device security does not help, because the attack happens inside the carrier network.

Targets and Tempo

Some targets were political and government VIPs in their own countries. In rare cases, SilentAir equipment in several countries worked together against a single target, which Enea says points to one controller. Activity came in bursts. A burst could cover anything from one or a few subscribers to several thousand over a month, and bursts were separated by gaps of up to several months or longer. Outside Taiwan, most targets were on other Southeast and East Asian networks, with some in East Africa, Central Asia, the Middle East and Europe. Subscribers on the hacked operators' own networks may also have been targeted, but Enea could not see that traffic.

Silent SMS as a Diversion Check

SilentAir also sent silent SMS at very large scale, mostly to subscribers in Taiwan. A silent SMS is a text the phone does not display or alert on. During the day, most of these went to subscribers on other networks, such as Southeast Asian ones. Enea says one of their main uses appears to have been checking whether a diversion had worked: if the test text arrived at the hacked equipment instead of the phone, the attackers knew they were receiving that person's messages.

Most silent SMS went out at night, and most of the night traffic went to people in Taiwan. Enea has not confirmed what those messages were for. One possibility is a bulk check that earlier diversions were still in place, since phones are least likely to re-register to their real location at night. The texts contained spam-like motivational or promotional lines, often in English. Enea believes this was a disguise: if an operator along the route stripped the silent setting, the recipient would see what looked like spam and ignore it.

Inside the Operators, Not Spoofing Them

Enea found SilentAir by studying attacks on the links between operators. Since early 2025, it had been tracking unusual attacks, mostly over SS7 and sometimes over Diameter, from Asian operators that would not normally send attacks. Later analysis found suspicious activity going back even earlier. The host networks handled follow-up messages for diverted targets in odd and inconsistent ways. That left two explanations: someone outside was faking those networks' signaling addresses, or equipment inside each network had been taken over. Enea then saw equipment inside one operator both send and receive attack commands, which confirmed the second explanation. That equipment behaved exactly like SilentAir sources in other networks.

In some countries, SilentAir attacks came from more than one operator. Detection and blocking were hard at first because the attackers understood mobile networks and signaling defenses well. After containment, Enea recovered traces of unauthorized access, but it could not analyze the malware it believes SilentAir used.

Attribution: China, Liminal Panda and SCTPE

Enea's low-confidence link to China rests on several signs. SilentAir focused on Taiwan and did not target Chinese networks or subscribers. Its tracking and interception followed a working day in UTC+8, which is China Standard Time: activity started at 9 a.m., almost stopped on weekends, and paused or slowed around Chinese holidays.

Enea calls a link to Liminal Panda, a group behind earlier telecom intrusions, possible but unconfirmed. In several hacked operators, SilentAir attacks took place during a known Liminal Panda infection, and both groups went after operators in the same part of Asia. At other times, however, the two showed no sign of working together, and Liminal Panda has no known focus on Taiwan.

SilentAir's behavior also partly matches SCTPE, a little-known Linux kernel trojan built to send and receive SS7 and Diameter traffic. A Singapore IMDA advisory describes the same tool under the name SIGweaver. According to that advisory, CrowdStrike identified it on January 21 and links it to Liminal Panda with moderate confidence. Enea points to one difference: SilentAir answered messages it had not sent itself, and the known SCTPE program cannot do that.

What the report does not say — Enea does not name the countries, operators or targets. It does not confirm that the compromised equipment has been cleaned up, it has not analyzed the malware, it has no evidence of voice call interception, and it has not confirmed any account takeover. Treat those as open questions, not as signs that the threat is over.

RedEye Assessment

SilentAir shows the weak point in signaling defenses that check where a message comes from. When the sender is legitimate operator equipment that has been compromised, its traffic carries the trust the IPX gives to that operator. The 18.3% interception share points to collection of specific people's communications rather than broad location tracking. The SMS 2FA captures show the goal reached past phones to the accounts tied to those numbers. Enea's notifications to operators and the disruption it reports are the only mitigation it describes, and Enea expects SilentAir could come back.

Attack surface: signaling equipment inside operators in 6+ Asian countries, sometimes more than one operator per country.
Technique: forged SS7 UpdateLocation and Diameter equivalents sent over the IPX to divert calls and texts.
Validation: large-scale silent SMS disguised as spam, sent mostly to Taiwan and mostly at night.
Attribution: state-level with high confidence; China with low confidence; possible overlap with Liminal Panda and partial overlap with SCTPE (SIGweaver).

Originally published on RedEye Threat Intelligence.

CVE-2026-119618: Critical Apache mod_http2 Flaw Allows Unauthenticated Remote Code Execution

Etairos.ai — Thu, 12 Nov 2026 21:05:11 +0000

TL;DR

what: CVE-2026-119618 is a code execution flaw in Apache HTTP Server's mod_http2 module that affects versions 2.4.55 through 2.4.70 and standalone mod_h2 2.0.8 through 2.0.42.
impact: An unauthenticated attacker who can reach a server with HTTP/2 enabled can take full control of the server process, according to Red Hat.
fix: Apache HTTP Server 2.4.71 fixes the flaw, Red Hat has shipped patched mod_http2 packages for RHEL 9 and 10, and Wiz advises restricting the Protocols directive to http/1.1 where no fix is available yet.
who: Organizations that run Apache with h2 or h2c enabled, especially on Debian stable, Amazon Linux, Red Hat JBoss Core Services, Red Hat Hardened Images or standalone mod_h2 builds, where no fix has been published.

A critical flaw in Apache HTTP Server's HTTP/2 module, mod_http2, lets an unauthenticated remote attacker run code on the server. Tracked as CVE-2026-119618 and rated 9.8 out of 10 on the CVSS scale by Red Hat, it affects Apache HTTP Server 2.4.55 through 2.4.70. The Apache HTTP Server project fixed it in version 2.4.71, released November 11. Only servers with HTTP/2 enabled are exposed.

The upstream patch is out, but many downstream packages are not. As of November 12, the stable Debian releases, every tracked Amazon Linux version and two Red Hat products had no fixed package, and Ubuntu had not published a status page for the CVE. The standalone mod_h2 module has no fix, and its archived project may never release one.

What the flaw does

Red Hat ships Apache HTTP Server as part of Red Hat Enterprise Linux. It says an attacker who can reach the server needs no authentication and could take full control of the server process. The attack runs over HTTP/2, so any listener that offers HTTP/2 is part of the attack surface.

The affected code covers Apache HTTP Server 2.4.55 through 2.4.70. Standalone builds of the module, released on GitHub as mod_h2, are affected from 2.0.8 through 2.0.42. Because the affected range is so wide, many servers that are otherwise kept up to date are still vulnerable.

⚠️ Patched in May is not patched now — An earlier HTTP/2 flaw, CVE-2026-23918, was fixed in Apache 2.4.67 on May 4. Servers updated to 2.4.67, or to any later release up to 2.4.70, still run a version affected by CVE-2026-119618. Teams that closed out the May advisory need to reopen it.

Conflicting signals on exploitability

Red Hat's assessment, published November 11, says "public research has demonstrated a reliable exploit" against a server in its default configuration with mod_http2 enabled. Red Hat does not name or link that research. Later the same day, Wiz said no exploit was available and no exploitation in the wild had been reported.

Taken together, there is no confirmed public exploit and no confirmed attack, but one vendor says reliable exploitation is possible. The fixed 2.4.71 source is public, so attackers can compare it with 2.4.70 to find the bug. Plan for an exploit appearing within days, not weeks.

Where exposure comes from

According to the module documentation, HTTP/2 runs only where the Protocols directive enables it. The directive uses h2 for HTTP/2 over TLS and h2c for HTTP/2 over plain TCP. It can be set for the whole server or for a single virtual host, so a server whose global setting allows only HTTP/1.1 can still offer HTTP/2 on one virtual host.

h2 on a TLS listener: the most common deployment, often enabled by default templates and hardening guides that recommend HTTP/2 for performance.
h2c on a plain TCP listener: less common, but it exposes the same module without TLS in front of it.
Virtual host overrides: a single site configured for HTTP/2 exposes the whole server process, not just that site.

Distribution patch status

Distributions ship their own builds with their own package version numbers, so the upstream version string alone does not show whether a server is fixed. Status as of November 12:

Apache HTTP Server project releases: fixed in 2.4.71.
Red Hat Enterprise Linux 9: fixed in mod_http2-2.0.26-7.el9_9.1 (RHSA-2026:98981).
Red Hat Enterprise Linux 10: fixed in mod_http2-2.0.29-5.el10_3.1 (RHSA-2026:98978).
RHEL 9.4 Update Services for SAP Solutions, and 9.6, 9.8, 10.0 and 10.2 Extended Update Support: fixed under RHSA-2026:98968, 98954, 98982, 98953 and 98979.
Red Hat Enterprise Linux 6, 7 and 8: not affected, because they do not contain the vulnerable code.
Red Hat JBoss Core Services and Red Hat Hardened Images: affected, no fix listed.
Debian unstable (sid): fixed in apache2 2.4.71-1. Debian bookworm, trixie and forky: vulnerable, no fix listed.
Amazon Linux 2 (Core), Amazon Linux 2023 and Amazon Linux 2027 Preview: fix pending.
Ubuntu: no CVE status page published.

Red Hat rates the flaw Important on RHEL 9 and 10 rather than Critical. Its mod_http2 packages give each HTTP/2 stream its own memory allocator, which the vendor says makes an attack much harder. That rating applies to Red Hat's own builds only. Upstream builds, builds compiled from source and other distributions' packages should be treated as Critical.

Mitigation where no fix exists

The Apache HTTP Server advisory offers no workaround. In its vulnerability analysis, Wiz advises admins who cannot update yet to remove h2 and h2c from the Protocols directive and leave Protocols http/1.1. This closes the attack path because clients fall back to HTTP/1.1. The vulnerable code is still installed, and the change has to cover the server-wide setting and every virtual host.

Standalone mod_h2 is orphaned — The mod_h2 GitHub repository was archived on June 9 and has been read-only since then. Its release list ends at 2.0.42, the last affected version. No fixed release has been published, so restricting the Protocols directive is the only published mitigation for servers that use these builds, short of moving to Apache 2.4.71 or a patched distribution package.

Also fixed in 2.4.71

The release also fixes a crash in mod_md, which Apache rates important, and a one-byte overwrite of stack memory in mod_vhost_alias, which Apache rates low. Servers that use mod_md for automatic ACME certificate management benefit from the update even if HTTP/2 is disabled.

How it was found

Anthropic's OSS Scanner, a free service that uses the company's AI models to scan open-source projects, reported the flaw on October 26. Anthony Weems and Simon Scannell of Google Cloud Vulnerability Research reported it independently last week. Two separate teams, one using AI-driven scanning, found the same bug in a core web server module within about two weeks. This suggests the bug was not hard to find for anyone looking, including attackers.

RedEye assessment

The highest risk sits with internet-facing Apache servers that offer HTTP/2 on Debian bookworm, trixie or forky, on any Amazon Linux release, on JBoss Core Services or Red Hat Hardened Images, and on any upstream or container build from 2.4.55 through 2.4.70. These servers have no vendor package to install today. Disabling HTTP/2 is the only published protection until one ships. Red Hat says a reliable exploit exists and the fixed source is public, so we expect exploitation attempts to begin soon. The patch gap on Debian and Amazon Linux leaves defenders less time than the 2.4.71 release date suggests.

Originally published on RedEye Threat Intelligence.

4,837 Hijacked GitHub Accounts Planted a CI Secret Stealer in 1,806+ Repositories

Etairos.ai — Thu, 12 Nov 2026 15:04:33 +0000

TL;DR

what: An attacker used stolen credentials for 4,837 GitHub accounts to push a CI secret stealer into repositories those accounts could write to, starting Tuesday, November 10, 2026.
impact: The stealer ran in at least 1,806 repositories, took every secret, token and cloud credential the workflows could reach, and can leave AWS and Azure backdoors that survive token rotation.
fix: Aikido Security and SafeDep advise treating every secret and cloud role available to affected workflows as compromised, revoking the commit author's tokens, OAuth grants, SSH keys and sessions, enabling 2FA, and hunting for wfx-prefixed cloud identities.
who: Any organization whose GitHub repositories grant write access to outside collaborators or org members, especially those using GitHub OIDC federation into AWS, GCP, Azure or Vault, or self-hosted runners.

An attacker holding stolen credentials for 4,837 GitHub accounts spent roughly 40 hours pushing a CI secret stealer into every repository those accounts could write to. Aikido Security counts at least 1,806 repositories where the stealer executed and likely sent out credentials. SafeDep counted 8,093 repositories that received malicious commits between 12:46 UTC on Tuesday, November 10 and 04:36 UTC on Thursday, November 12, and that count covers only the default branches of public repositories. The real number is higher, and new test pull requests were still appearing at 05:38 UTC Thursday.

This is not a poisoned package waiting for downloads. The attacker went straight to the CI layer, where secrets, cloud roles and publishing rights sit together, and built a payload that turns one workflow run into persistent cloud access.

How the Campaign Worked

Each intrusion began with a probe. The attacker opened a pull request titled "docs: dependency audit notes" from a branch named wfx-docs to confirm the account had write access. These test pull requests reached 61,764 repositories. Of those, 10,431 were submitted through collaborator or organization access, which means the compromised accounts were reaching into repositories they did not own. When Aikido checked, 92% of those collaborator pull requests were still open.

Where the probe succeeded, the stealer followed. SafeDep found it delivered two ways. In 7,309 repositories it was injected into an existing workflow, typically via a commit labeled "ci: refresh build cache" that added about 1,500 lines. In 771 repositories it arrived as an npm postinstall hook pointing at a .ci-xxxxxx.sh script, which also executes on any developer machine that runs npm install against that commit. Other variants added a new build-audit workflow on a short-lived chore/ branch or seeded empty repositories with "chore: initial commit" before dropping a workflow file.

The attacker usually reverted the change within minutes, using commits such as "ci: restore" and "ci: cleanup". Where the stealer ran, its logs were deleted, and usually the workflow run itself. That cleanup is why Aikido says a missing run number on the attacker's commit is a more reliable sign of execution than the presence of wfx-loot artifacts, wfx- cache entries or WFX-BEGIN step summaries.

⚠️ A test PR alone means the account is compromised — Aikido states that any account that opened one of the attacker's wfx-docs test pull requests is compromised, even if the stealer never ran. Its analysis does not explain how the attacker obtained the 4,837 credentials.

What the Stealer Takes

The payload is built to empty the runner. According to the researchers, it collects:

GitHub Actions secrets and variables, the workflow GITHUB_TOKEN, and OIDC and Actions runtime tokens
Keys for AI services and secrets held in the memory of the runner's own processes
Credential files for AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH and other tools from their default locations
A copy of the repository, its last 100 commits and recent workflow artifacts
On self-hosted runners: cloud credentials from instance metadata, Docker container state and systemd units

Exfiltration goes by HTTP POST to 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil or 153.75.82[.]159:8080, or to a Telegram chat. In a SafeDep sample of 200 payload commits, about a fifth used Telegram only, so network blocking on the three IPs will not catch every case. The stealer also carries settings for private repositories, which Aikido reads as a sign it is running there too, outside what any public search can count.

From CI Token to Persistent Cloud Access

The most damaging part of the payload runs after collection. The stealer exchanges GitHub OIDC tokens for live AWS, GCP and Azure sessions. On AWS it can create long-lived access keys for IAM users and rewrite a role's trust policy to open the role to any AWS account. In Azure it can add federated identity credentials prefixed wfx-ci- to Entra ID applications, which lets workflows in the compromised repository sign in to Azure without a stored secret.

Those steps are designed to survive credential rotation. Rotating GitHub secrets does not remove a rewritten trust policy, a new IAM access key or a rogue federated credential. Organizations that rotate and stop there may still be exposed.

Cloud persistence indicators reported by researchers — Entra ID federated credentials named wfx-ci-* that the owner did not create. AWS CloudTrail AssumeRoleWithWebIdentity or AssumeRole sessions named wfx-*, followed by CreateAccessKey or UpdateAssumeRolePolicy. GCP GenerateAccessToken and SignJwt calls from the GitHub workload identity pool. Vault JWT logins from the GitHub OIDC issuer.

Downstream Spread

Because the stealer runs inside CI, it also reaches whatever CI publishes. The researchers confirmed it reached at least one Packagist package and one Go module through automated publishing triggers. Any repository whose workflows publish on push or tag could have released a build that carries attacker changes, and the npm postinstall variant puts developer laptops in scope alongside runners.

Indicators of Compromise

Branches: wfx-docs; chore/ followed by 8 lowercase alphanumerics (short-lived); ci-check- followed by 4 digits
Pull request title: docs: dependency audit notes
Commit messages: ci: refresh build cache; chore: add ci helper; chore: add dependency audit workflow; chore: initial commit; ci: restore; ci: cleanup
Files: .github/workflows/build-audit-xxxxxx.yml; .ci-xxxxxx.sh with a matching postinstall entry in package.json
Stealer script SHA-256: 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf
Exfil endpoints: 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil, 153.75.82[.]159:8080, plus Telegram

Researcher Guidance and RedEye Assessment

Aikido's position is that in any repository where the stealer ran, every secret and cloud role available to its workflows is compromised. SafeDep advises affected owners to revoke the commit author's tokens, OAuth app grants, SSH keys and sessions, turn on 2FA, and rotate every secret and variable the repository can read. Machines that ran npm install on an affected commit are treated as compromised, with their keys rotated. In most repositories that received only a test pull request, nothing was pushed or the stealer was blocked by repository settings or account permissions, but the account behind the probe is still burned.

The figures here are a floor. They cover public repositories on default branches, the stealer has private repository settings, and the attacker was still opening pull requests after both research teams finished counting. The cloud persistence mechanisms mean the incident does not end at token rotation, and the wide use of collaborator access means an organization can be hit through an outside contributor's account it never directly controlled.

RedEye Security can assess GitHub organization exposure to this campaign, review OIDC trust relationships across AWS, Azure, GCP and Vault for wfx-prefixed persistence, and scope what left your runners. Contact RedEye for an assessment.

Originally published on RedEye Threat Intelligence.

Microsoft Patches 1,259 Flaws as Outlook Zero-Day CVE-2026-124194 Leaks NTLMv2 Hashes

Etairos.ai — Wed, 11 Nov 2026 21:04:40 +0000

TL;DR

what: Microsoft's November 2026 Patch Tuesday fixed 1,259 vulnerabilities, including CVE-2026-124194, an actively exploited Outlook flaw that suppresses the external-content warning.
impact: One opened message file can make Outlook connect to an attacker-controlled server and hand over the user's NTLMv2 hash, which attackers can use to impersonate that user across the network.
fix: Microsoft's November 2026 security update fixes CVE-2026-124194, and CISA has added it to the KEV catalog with a November 24, 2026 deadline for federal agencies.
who: Any organization running affected Microsoft Outlook versions, which covers nearly every Microsoft 365 and Exchange shop, plus teams exposed to the Windows Search, LDAP, Schannel and Azure OpenAI flaws in the same release.

Microsoft shipped fixes for 1,259 vulnerabilities on November 10, 2026, the second consecutive month that Patch Tuesday has crossed 1,000 CVEs. Buried in that volume is the one that matters most this week: CVE-2026-124194, a Microsoft Outlook flaw that Microsoft confirms is being exploited in the wild. A single opened message file can cause Outlook to reach out to an attacker's server without the usual warning and leak the user's NTLMv2 hash. CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a federal remediation deadline of November 24, 2026.

The Exploited Outlook Flaw: CVE-2026-124194

Microsoft rates CVE-2026-124194 as Moderate with a CVSS score of 6.5 and classifies it as spoofing. Its advisory describes the root cause as a product UI that "does not warn users of unsafe actions." In practice, an unauthenticated attacker sends a specially crafted message file and persuades the target to open it in an affected Outlook build. Outlook then connects to an attacker-controlled network location and skips the external-content warning that would normally stop or flag that connection.

That outbound connection carries authentication material. Microsoft states it can disclose information such as the user's NTLMv2 hash, which an attacker can use to impersonate the user. Exploitation requires network connectivity and one user action: opening the file. Microsoft credited a researcher named Nono and Anthropic's Benoît Sevens, who used Claude, with discovering and reporting the issue.

⚠️ Severity label vs. real risk — CVE-2026-124194 carries a Moderate rating and a 6.5 CVSS score, but it is confirmed exploited, needs no authentication, requires only one opened file, and targets Outlook, which nearly every enterprise runs. Treat it as a priority item regardless of the label.

Why a Leaked NTLMv2 Hash Is a Big Deal

Forced NTLM authentication is a well-worn technique because the payoff is an identity, not just a mailbox. Jack Bicer, director of vulnerability research at Action1, summarized it: "Email is the easiest door into any company, and this flaw turns one opened file into a stolen identity." A captured hash gives an attacker several options:

Offline cracking of the NTLMv2 response to recover weak or reused passwords.
Relay of the authentication to other internal services that still accept NTLM, letting the attacker act as the victim without ever knowing the password.
Access to the victim's data and lateral movement to any system the victim's account can reach.
A foothold that bypasses perimeter controls, since the initial lure arrives through normal email delivery.

Bicer added that "the Moderate label undersells this one," pointing to the combination of active exploitation, one-click delivery and near-universal deployment. The blast radius scales with the privileges of whoever opens the file. A help desk technician or IT administrator falling for the lure is a very different incident than a single sales mailbox.

What Microsoft Has Not Disclosed

Microsoft has not attributed the in-the-wild activity to any threat actor and has published no technical details on how attackers are delivering or weaponizing the flaw. The advisory also does not say whether the researchers found the bug before or after exploitation began. That leaves defenders without vendor-supplied indicators of compromise, lure samples or infrastructure to hunt for. Detection today depends on generic signals of outbound NTLM authentication to external hosts rather than a known campaign signature.

The Rest of the 1,259

The release breaks down to 726 flaws in Windows, 174 in Office, 59 in SQL Server, 27 in SharePoint Server and dozens in Developer Tools, plus 165 CVE identifiers issued by third parties. More than 500 are elevation of privilege bugs, followed by remote code execution and information disclosure. According to Satnam Narang of Tenable, Microsoft has now addressed more than 5,100 CVEs in 2026. Notable non-exploited flaws include:

CVE-2026-116928: remote code execution in Windows Search.
CVE-2026-119958: remote code execution in Lightweight Directory Access Protocol (LDAP), relevant to every domain controller.
CVE-2026-119952: remote code execution in Windows Schannel, the TLS stack used across Windows services.
CVE-2026-95962: remote code execution in the Windows Virtual Filtering Platform.
CVE-2026-112967: remote code execution in the Windows Xbox Live Networking Service.
CVE-2026-119990: elevation of privilege in Azure OpenAI.

The LDAP and Schannel bugs deserve attention because they sit in core infrastructure that is often reachable from wide parts of the network. Microsoft has not reported exploitation for any of them.

Patch Fatigue Is Now an Operational Risk

Two consecutive months above 1,000 CVEs is a structural shift, not a spike. Jake Knott, head of threat intelligence at watchTowr, noted that most teams "haven't quite recovered from the last month of bumper-to-bumper critical vulnerabilities" and are struggling to work out what actually matters. His recommended order is internet-exposed assets first, then flaws already exploited in the wild, then everything else, after confirming whether the vulnerable component is even present and whether exploitation prerequisites are met.

Where CVE-2026-124194 lands in that order — It is confirmed exploited, it is delivered through email that reaches every user, and Outlook is present on nearly every endpoint. By any prioritization model, it belongs at the top of this month's queue alongside internet-facing systems.

The volume problem also cuts against defenders in a quieter way. When a release contains 1,259 entries, a 6.5 Moderate rating is easy to filter out of a dashboard sorted by CVSS. Attackers do not sort by CVSS. They pick the flaw that gets them credentials with the least friction, and this month that is an Outlook bug most scoring systems will rank below hundreds of others.

RedEye Assessment

CVE-2026-124194 is the priority item from this release. It turns routine email into a credential theft channel, and the stolen NTLMv2 hash can carry an attacker well past the inbox into file shares, internal applications and administrative systems. Microsoft's November 2026 update is the fix, and the CISA KEV listing confirms the federal government considers it an active threat. Organizations should also expect the LDAP and Schannel remote code execution flaws to draw researcher and attacker interest in the coming weeks. RedEye Security can assess your Outlook and NTLM exposure, validate patch coverage across this release, and identify where a single stolen hash would lead in your environment. Contact RedEye for an assessment.

Originally published on RedEye Threat Intelligence.

CopperDragon: One Chinese Quartermaster Arms Three Espionage Campaigns Across 3 Continents

Etairos.ai — Wed, 11 Nov 2026 15:04:36 +0000

TL;DR

what: Check Point Research linked three China-nexus espionage clusters, SilentDelivery, OceanGate and DarkWire, through a shared malware ecosystem called Sparrow, built by a digital quartermaster it tracks as CopperDragon.
impact: Telecommunications providers, government bodies, military entities, research institutions and critical infrastructure across Latin America, Asia and Europe have been targeted over the past year with backdoors, keyloggers, credential stealers and kernel rootkits.
fix: No single vendor patch applies: the main exposures are internet-facing Linux servers, weak administrator passwords reachable over RDP, and users persuaded by fake Chrome certificate warnings, and Check Point and Positive Technologies have published technical reports on the tooling.
who: Telecoms, government, defense, shipping, IT and research organizations in Latin America, Asia and Europe are most at risk, along with any organization whose staff regularly visit sector websites in those regions.

Three espionage campaigns that looked unrelated turn out to share one supplier. Check Point Research has linked the SilentDelivery, OceanGate and DarkWire clusters through a common malware ecosystem called Sparrow. Over the past year these clusters have hit telecommunications providers, government organizations, military entities, research institutions and critical infrastructure in Latin America, Asia and Europe. The developer behind Sparrow, tracked as CopperDragon, is assessed to be a digital quartermaster that supplies tools to at least five China-nexus groups: FamousSparrow, Earth Estries, Tropic Trooper, UAT-9244 and UAT-8302.

This matters for defenders. When one supplier arms several operators, an intrusion by one group can share code, infrastructure and behavior with another group's intrusion. Treating each cluster as a separate threat leaves those links unseen.

The Quartermaster Model

Check Point first assessed the three clusters as independent. Each used its own backdoors, its own post-exploitation tooling and its own way in. Shared infrastructure and code similarities later tied them to the Sparrow ecosystem. The best-known Sparrow family is SparrowDoor, along with its variants Crowdoor and TernDoor. FamousSparrow also deploys SparroWocky and HemiGate. FamousSparrow has some overlap with Salt Typhoon, the group behind well-known telecom intrusions, but the exact relationship is unclear.

⚠️ Why the shared supplier matters — Five named China-nexus groups draw on one tool developer. Detection logic written for SparrowDoor in one campaign may catch activity from a different operator, and a gap in that logic is a gap against all of them.

SilentDelivery: Fake Certificate Warnings on Trusted Sites

SilentDelivery has been active since early 2026 and runs highly selective watering hole attacks against targets in Europe and Asia. The operators inject heavily obfuscated JavaScript into legitimate websites their targets visit. The compromised sites belong to government, shipping, IT and research organizations in the Czech Republic, Germany, France, Taiwan, Nepal, Hong Kong and Indonesia. A Positive Technologies report from August 2026 adds signs of targeting in Egypt and the Philippines.

The script is obfuscated with jsjiami, a public JavaScript obfuscation service. It checks that the visitor runs Windows and, in some cases, that the page is on the intended compromised domain. It then sends repeated status checks to a command-and-control server, which fingerprints the visitor by IP address and geolocation and decides whether to continue. Visitors who pass see a fake Google Chrome SSL certificate warning telling them to install a "Certificate Fix" utility. That utility is a trojanized MSI installer that delivers either SquadC or a SparrowDoor variant.

SquadC, also known as SquawkDoor, is a Windows backdoor written in C/C++. It persists through a Registry Run key disguised as a Windows update assistant. Check Point also found it spreading by phishing against Indonesian organizations. Those emails carry an LNK shortcut disguised as a PDF. Opening it abuses the legitimate ftp.exe binary to run a batch script, which shows an empty decoy file and launches SquadC through DLL sideloading.

OceanGate: From Linux Edge to Windows Domain

OceanGate ran from 2025 to 2026 and focused mainly on Asian organizations. Initial access came through internet-facing Linux servers. Two previously undocumented Linux backdoors held that foothold:

AnnobinDoor: a Go-based backdoor with remote access, an interactive shell, file management, SOCKS proxying, SSH tunneling, port forwarding and reverse connections. It turns the infected host into both a remote shell and an internal network pivot.
SparrowShell: a modular Linux backdoor that overlaps with its Windows counterpart, SparrowDoor.

After collecting credentials from several Linux users, the operators moved into Windows. They tried RDP logins on several Windows machines, cycling through passwords until one administrator account worked. They then deployed a SparrowDoor variant and four custom post-exploitation tools:

CopperAdu: configures a compromised Windows machine for remote administrative access.
CopperList: reconnaissance that collects host details, disk information and a recursive file inventory with paths, sizes and timestamps.
CopperLogger: a Raw Input keylogger that also records clipboard activity, active window titles and the associated process names and paths.
CopperLsa: collects passwords, hashes and authentication tokens from NTLM and Kerberos.

Check Point also reports that the actor has added kernel rootkits and kernel-level access to SparrowDoor and SparrowShell to evade defenses. Kernel-level tooling makes host-based detection much less reliable once the implant is in place.

DarkWire: Latin American Telecoms and Government

DarkWire dates to mid-2025 and targets telecommunications providers and government organizations across Latin America. It uses two backdoors, CopperDoor (also known as SparroWocky) and CopperDNS. Because SparroWocky is already tied to FamousSparrow, DarkWire is the most direct link between the quartermaster's output and a known operator.

Three ways in, one toolbox — SilentDelivery uses watering holes and phishing, OceanGate uses exposed Linux servers and RDP password guessing, and DarkWire goes after telecom and government networks. The entry points differ, but the implants come from the same Sparrow lineage.

Assessment

No CVE ties this activity together, so there is no single patch to apply. The exposures are structural. Internet-facing Linux servers gave OceanGate its first foothold. An administrator password that could be guessed over RDP let it cross into Windows. Users who trust a browser-style certificate warning on a familiar site gave SilentDelivery its foothold. The watering holes are narrowly targeted and filter visitors by OS, domain, IP and location, so most visitors to a compromised site never see the payload. That makes the compromise harder to spot from outside.

For telecoms, government agencies and research institutions in the affected regions, the key point is attribution. An alert for SparrowDoor, SquadC or a Copper tool should not be scoped to one campaign. It points to an ecosystem that supplies at least five operators with credential theft, keylogging, network pivoting and kernel-level persistence. Check Point and Positive Technologies have published technical detail on the tooling for teams that want to compare it against their own telemetry.

RedEye Security tracks China-nexus activity against telecom, government and critical infrastructure environments. If your organization runs internet-facing Linux infrastructure or operates in the sectors and regions named here, a RedEye assessment can determine whether Sparrow ecosystem tooling is present and how far an intrusion like OceanGate could reach in your environment.

Originally published on RedEye Threat Intelligence.

Default admin:admin on ForgeRock Console Let Researchers Unlock and Start Two Automakers' Cars

Etairos.ai — Tue, 10 Nov 2026 21:04:47 +0000

TL;DR

what: Researchers reached the Apache Felix admin console on two automakers' ForgeRock OpenIDM servers by bypassing an edge block with a path parsing mismatch, then logged in with the default admin:admin password.
impact: Code execution on the identity server let them take over any customer account on the affected servers and send unlock and engine start commands to connected cars, with nothing visible to the owner.
fix: Both automakers closed the hole about two hours after the February 2026 report; there is no CVE, and ForgeRock's hardening guidance for what is now PingIDM is to remove the /system/console admin page or change its default credentials before going live.
who: Owners of the two affected brands' connected cars in the US, Canada and Australia, plus any organization running ForgeRock OpenIDM or PingIDM with the Felix console still deployed.

The login systems behind two car brands' mobile apps could be taken over completely through an identity server admin console that still accepted the default username and password admin:admin. Security researchers Shubham Shah and Sam Curry used it to reach any customer account on the affected servers. On test cars, with the owners' consent, they unlocked the doors and started the engine remotely. Both systems were fixed about two hours after the researchers reported the problem in February 2026. The research was published in early November.

There is no CVE and no vendor advisory. The product had no new bug. The failure was in deployment: a default password that has been documented for years, left in place behind an edge filter that did not read URLs the same way the backend did.

The Stack: ForgeRock, OpenIDM and the Felix Console

Both brands signed customers in through ForgeRock, an identity platform now part of Ping Identity. Its identity management component is sold today as PingIDM. The platform runs in two parts: one handles login, and OpenIDM holds customer records. OpenIDM ships with an admin console built on Apache Felix, served at /system/console.

ForgeRock's production hardening guide tells operators to remove that console or protect it before going live, because it keeps its own password separate from the rest of the platform. On both brands' servers the console was still deployed and still used the documented default: admin for the username and admin for the password.

The Attack Chain

The console was blocked from the open internet. The researchers got around the block with a parser mismatch: the edge that guards the site and the Java application server behind it interpreted the same web address differently.

Path confusion: encoded slashes and extra characters made the edge treat the request as a harmless static file, while the Java server resolved it to the Felix console.
Default credentials: admin:admin authenticated to the console.
Code execution: the console's built-in scheduler ran small scripts, giving the researchers a command prompt on the OpenIDM server that holds customer records for both brands.
Account takeover: customer records sat behind the same edge block, but code running inside the server reached them directly. The researchers changed a target account's email address and password.
Token issuance: they signed in as that customer through the normal mobile app and received the same access tokens the real app uses.
Vehicle commands: using the account's own vehicle commands, they unlocked a test car and started its engine with the owner standing beside it, then stopped the engine and locked it again.

⚠️ Silent to the owner — Changing the email and password did not log the owner out of their app. The researchers could also route the account's alerts to their own phone, keeping them off the owner's phone. An attacker using this path would have left the victim very little to notice.

A Second Way In: Australia

Shah published a separate attack on the Australian systems behind the same brands. The entry point was different: admin credentials for the identity server had been left in the mobile app's code, apparently meant for a test setup. With both attacks combined, the researchers said they could send unlock and engine start commands to the brands' cars in the United States, Canada and Australia. The Australia write-up does not say when those systems were fixed.

Scope and Limits

The researchers reported being able to open a session for any customer account on the affected servers. They ran vehicle commands only on cars they owned or had permission to use, and said they tested the complete chain only with US accounts and vehicles. They restored the real email address after testing. Neither write-up says whether anyone else found or used the path before it was closed.

Why This Matters Beyond Automotive

The car is the dramatic endpoint, but this was an identity infrastructure failure. One identity server held customer records for two brands, so a single console compromise reached both. Customer identity platforms now act as the control plane for physical devices: cars, smart locks, building systems, medical devices. Whoever controls an account's email and password controls the device attached to it.

Two patterns here show up again and again. First, vendor admin interfaces with their own credential stores tend to fall outside normal password rotation, SSO and monitoring. The Felix console's separate password is exactly that kind of blind spot. Second, edge and WAF path rules are not access control. When the proxy and the origin server normalize paths differently, encoded characters get through. Path normalization and request parsing mismatches have defeated this pattern many times before, across many products.

Vendor guidance and remediation — There is no patch because there is no product flaw. ForgeRock, now Ping Identity, guidance for PingIDM production deployments is to remove the Apache Felix console at /system/console or replace its default credentials before going live. The researchers also stress that edge or WAF path rules should not be relied on to hide admin pages. Both automakers fixed their US-facing systems about two hours after notification.

The Researchers' Track Record

Shah and Curry have a long record of this work, usually breaking into the web systems behind connected-car apps rather than the vehicles themselves. They have shown remote access to vehicles from Honda, Kia and Subaru, among others. A Subaru flaw they reported exposed owners' accounts and their cars through that carmaker's connected-car service. A 2023 study they took part in covered 16 brands and found the same class of web weakness across much of the industry. This latest finding shows the pattern continuing: the vehicle's own security can be solid while the cloud identity layer that issues its commands is left exposed.

RedEye Assessment

A two hour fix is fast, and both automakers deserve credit for it. But the exposure came from a default that the vendor's own hardening guide flags, sitting in production for an unknown length of time. Organizations whose identity platform issues tokens that control physical assets should treat that platform's admin surfaces, credential stores and edge parsing behavior as critical attack surface. The test should be what an attacker can actually reach, not what the WAF rules say should be blocked.

Originally published on RedEye Threat Intelligence.

Able2Shell: N-able Pulls N-central Cloud Offline After 33 Zero-Days Drop With Working Exploits

Etairos.ai — Tue, 10 Nov 2026 15:04:18 +0000

TL;DR

what: Independent researcher Sean Bales publicly disclosed more than 30 N-able N-central zero-days, collectively called Able2Shell, along with working proof-of-concept exploits tested against N-central Appliance 2026.4.0.31.
impact: The flaws chain into anonymous credential theft, rogue administrator creation and command execution as root on the platform that manages customer endpoints.
fix: No patch is available yet: N-able has taken Hosted N-central offline, is urging on-premises customers to shut down their servers until further notice, and says a hot fix is in progress.
who: Every organization running N-central hosted or on-premises in the Americas, APAC or Europe, plus every downstream endpoint those consoles manage.

It is rare for a software vendor to tell its customers to switch its product off. On November 10, 2026, N-able did exactly that. The company took its Hosted N-central environments offline in all three regions and urged on-premises customers to shut down their servers "until further notice." The trigger was a public dump of more than 30 vulnerabilities, branded Able2Shell, published with working proof-of-concept exploits before any patch existed.

For organizations that depend on N-central to manage endpoints, the choice is now between losing their management console and leaving a root-level path into it exposed. Within hours, the second option got more dangerous: watchTowr reported that it "observed exploitation attempts against N-able N-central honeypots overnight" after the disclosure.

What was disclosed

Independent security researcher Sean Bales published the findings and said he tested them against N-able N-central Appliance 2026.4.0.31. The flaws cover most of the standard web and appliance bug classes: credential disclosure, arbitrary file writes, directory traversal, cross-site scripting, XML external entity injection and remote code execution.

The individual bug classes matter less than the chains Bales built from them. According to the disclosure, the chains lead to:

Anonymous credential theft and creation of new administrator accounts, with no prior access required
Remote code execution as the nable user and as root
XXE combined with NCI trust abuse, support-token theft and execution of unsigned NSP content
XSS escalated to OGNL injection, plus authenticated reverse shells
MDM impersonation, audit log tampering and privileged-helper injection
A native GenericTCP stack overflow that also reaches root command execution

⚠️ Audit tampering is in the chain — One of the disclosed capabilities is audit tampering. If a console was compromised before it went offline, its own logs may not show what happened. Treat the platform's internal audit trail as possibly unreliable evidence until it has been checked against independent records.

N-able's response

N-able described the hosted shutdown as precautionary: "we are temporarily taking our Hosted N-central environment offline while we take the necessary actions to secure the environment and implement appropriate remediation." Customers cannot reach Hosted N-central classic while it is down. The company says its Ecoverse services under N-able Login stay online, including Asset View, Patching, Vulnerability Management, scripting, policies and tagging.

The affected services are N-central hosted and N-central on-premise in the Americas, APAC and Europe. N-able says it has seen no signs of active exploitation and is working on a hot fix. watchTowr's honeypot data shows attackers tried anyway. Together with the vendor's own guidance, watchTowr is telling users to audit for signs of compromise, restrict access and follow N-able's mitigation steps.

The RedEye take

N-able made the right call, and it made it fast. Taking a revenue-generating cloud service offline across three regions, and telling on-premises customers to turn their servers off, is the kind of decision vendors usually avoid until it is too late. Here it happened on the day of disclosure. Other vendors should follow that example.

Still, the speed of the response does not erase what the disclosure showed. These were not one or two edge-case bugs. Thirty-three issues, several of which reach root on their own, point to systemic weaknesses in input handling, trust boundaries between components, and privilege separation on the appliance. A hot fix can close known paths. It cannot quickly rebuild trust in an architecture that produced this many of them.

The disclosure model also deserves attention. Publishing working exploits with no patch available put every N-central customer on a clock they did not set, and watchTowr's overnight honeypot activity shows how short that clock is. Whatever one thinks of how it was handled, defenders should plan for this as the normal case: exploit code first, patch later.

Finally, this is a supply chain story, not a product bug story. A remote management console is privileged by design. It pushes scripts, policies and patches to every endpoint it manages. Root on the console is effectively root everywhere the console reaches.

What is still open — N-able has not given a hot fix timeline or version number. Until one ships and is verified, the vendor's position stands: hosted is offline, and on-premises servers should be shut down.

What defenders should learn

Plan for losing the management plane. Many teams lost console access overnight. Patching, scripting and remote support processes that depend on one RMM console need a documented fallback that does not depend on that vendor.
Treat management consoles as tier-zero assets. A platform that can create administrators and run commands on every managed endpoint needs the same network isolation, access restriction and monitoring as a domain controller, not the treatment usually given to an internal web app.
Check compromise from outside the box. Because the disclosed chains include audit tampering, the platform's internal logs are not enough. Network telemetry, identity provider logs and endpoint records from managed devices are the evidence that matters.
Expect disclosure without a patch. The time between public exploit and observed attack here was one night. Incident playbooks should cover "shut it down and wait" as a planned option with owners and communication paths, not something improvised.
Ask vendors about blast radius before you buy. Ask how the product separates privileges, signs the content it pushes and limits what a compromised console can do downstream. Unsigned NSP execution was one of the disclosed chains.

Bottom line

Able2Shell turned a single management platform into a possible root path into every environment it touches, and attackers tested it within hours. N-able's shutdown buys time. Use that time to confirm your N-central exposure, check for signs of compromise using independent evidence, and decide how much of your operation should depend on any single management console. Source: The Hacker News, "N-able Takes N-central Cloud Offline After Researcher Discloses 33 Zero-Days with PoC Exploits," November 10, 2026.

Originally published on RedEye Threat Intelligence.

Attacker Rides Qubole's Trusted AWS Account Into Customer Environments, Steals Secrets and S3 Data

Etairos.ai — Mon, 09 Nov 2026 21:04:13 +0000

TL;DR

what: An attacker used credentials for Qubole's own AWS account (805246085872) to assume vendor IAM roles in multiple customer AWS accounts from October 14 to October 26.
impact: The attacker pulled secrets from Lambda environment variables, Secrets Manager and SSM Parameter Store, validated AWS, Entra ID and Okta credentials with TruffleHog, and copied S3 data, sometimes entire buckets.
fix: Wiz advises rotating everything a compromised Qubole role could reach, revoking active sessions, removing unused Qubole roles, and restricting vendor trust policies by source IP or VPC endpoint; Qubole and its owner Idera had not published a statement at the time of writing.
who: Any organization that has ever connected Qubole to AWS, including former customers whose Qubole IAM roles still trust the vendor account.

An attacker spent 12 days inside the AWS accounts of multiple Qubole customers, harvesting stored secrets and copying S3 data, without ever touching a customer credential to get in. Cloud security firm Wiz disclosed on November 9 that the attacker used credentials for AWS account 805246085872, the account Qubole's data lake platform uses to reach its customers, and assumed the IAM roles those customers had created to let Qubole in. The activity ran from October 14 to October 26. How the attacker obtained Qubole's credentials has not been disclosed, and Wiz did not say whether the credentials have been disabled or whether the activity has stopped.

Qubole, owned by Idera, had not posted a statement on the incident when The Hacker News checked on publication day. Sentra first spotted the activity across several of its own customers' environments and alerted Wiz.

Why the Roles Let the Attacker In

Qubole operates inside its customers' AWS accounts. To enable that, each customer creates an IAM role whose trust policy allows Qubole's AWS account to assume it. Every AssumeRole request must carry a matching External ID supplied by Qubole. Every request tied to the attacker included the correct External ID and was accepted.

That is the design working as intended. AWS's own guidance states the External ID is not a secret: anyone with access to the role can view it, it is logged in plain text in CloudTrail, and vendors and infrastructure-as-code repositories routinely store it. Once the attacker held credentials for the trusted account, the External ID check offered no real resistance.

⚠️ Unused roles were still open doors — Wiz found that most of the roles the attacker assumed were otherwise unused. Customers who had connected Qubole and moved on never removed the role or the trust relationship, so the vendor account kept standing access to their environments.

What the Attacker Did Inside

The objective was credentials first, data second. In the accounts Wiz examined, the attacker:

Read environment variables from Lambda functions.
Pulled secrets from AWS Secrets Manager.
Read values from SSM Parameter Store.
Ran the harvested material through TruffleHog to confirm which credentials worked, including the victims' own AWS access keys, Entra ID client secrets and Okta client credentials.
Copied data out of S3 from any bucket the role could reach, without targeting specific data, in some cases downloading an entire bucket in one session.

The indiscriminate S3 collection points to opportunistic theft rather than an intelligence mission. Wiz has not linked the campaign to any other publicly reported activity and says the targeting does not match what state-backed groups usually pursue. The validated Entra ID and Okta secrets matter beyond AWS: they extend the blast radius into identity providers and every SaaS application those identities reach.

A Second, Separate Campaign

Qubole also lets customers connect using static AWS access keys instead of a role. From October 8 to October 11, an attacker used customers' own AWS access keys, which Wiz believes had been created for Qubole, and compromised a few of those cloud environments. Wiz has not linked this activity to the AssumeRole abuse, but it hits the same customer base through the same vendor integration.

Indicators Published by Wiz

Wiz's hunting guidance covers CloudTrail from October 1 onward in every AWS account that holds a Qubole role. Wiz observed legitimate Qubole traffic originating only from AWS address space, which makes source address the strongest single signal.

Account: AssumeRole calls where userIdentity.accountId is 805246085872 and sourceIPAddress is not an AWS address.
IAM principal AIDA3W7DIFLYOLTK63SFS: used only by the attacker in the accounts Wiz examined; any activity is suspect.
IAM principal AIDAJYRRH5Y3A7AAJM2HW from a non-AWS address: attacker use began October 18, but Qubole's normal traffic also uses this principal.
OVH-hosted attacker IPs: 57.129.54[.]120 and 2001:41d0:70d[:]7800::.
Mullvad VPN IPs: 45.83.220[.]211, 185.209.199[.]73 and 89.37.63[.]175, shared with other VPN users, so a match alone is not proof.
Role session names beginning with quiam-, such as quiam-enum.
TruffleHog user agent on GetCallerIdentity calls from the IPs above, and the same user agent in identity provider sign-in logs.

The logging gap — CloudTrail management events record each AssumeRole and bucket listing, but not which S3 objects were read. That requires S3 data events or S3 server access logs. Several victims lacked them, so responders could not determine which objects the attacker had taken.

Researcher Mitigation Guidance

Wiz's recommendations center on treating any assumed Qubole role as a full credential compromise. Rotating a secret does not end sessions already issued, so Wiz pairs rotation of every secret, parameter and Lambda environment variable the role could reach with revocation of the role's active sessions. Beyond the incident, Wiz recommends removing Qubole roles that are no longer needed, replacing the account-wide :root principal in trust policies with Qubole's specific IAM principal where supported, and adding aws:SourceIp or aws:SourceVpce conditions tied to the vendor's documented network ranges. On that last point Wiz was blunt: "a source IP condition alone would have blocked every role assumption we observed."

Wiz also flags overbroad vendor permissions as a root cause. Qubole's own setup guide includes a sample S3 policy granting read access to every bucket in the account, and vendor roles commonly receive Lambda configuration, Secrets Manager, SSM and wide S3 read rights for convenience. Wiz further recommends rotating the External ID after an incident, using distinct values per role, and alerting on vendor-account AssumeRole requests that arrive through VPN infrastructure.

RedEye Assessment

This is a supply chain compromise without a poisoned package. The trusted artifact was a cross-account trust policy, and it was trusted by organizations that had long since stopped using the product. The External ID, widely treated as a security boundary, functioned as a routing label. Expect attackers to repeat this pattern against other SaaS platforms that hold standing AssumeRole access into customer clouds, and expect the same gaps to determine impact: dormant vendor roles, :root trust principals, no network conditions, broad S3 and secrets permissions, and missing S3 data event logging. Until Qubole or Idera explains how account 805246085872 was compromised and confirms containment, any organization with a Qubole trust relationship should treat its exposure as unresolved. RedEye can assess your third-party cloud trust relationships, review CloudTrail for these indicators, and scope what a compromised vendor role could have reached.

Originally published on RedEye Threat Intelligence.

BOSSAI: One Attacker's AI Agents Pulled Taipei 119 Dispatch Records and Exposed Patient Data

Etairos.ai — Mon, 09 Nov 2026 15:12:35 +0000

TL;DR

what: A single Taiwan-based attacker used BOSSAI, a 12-agent AI setup running mostly on safety-stripped local models, to scan and attack hundreds of organizations and pull Taipei 119 emergency dispatch records.
impact: About 10 organizations in Taiwan, Mexico and Thailand were reached, including street-level dispatch case data, a fire department patient platform exposed since 2018, a lender's account table, three Thai universities and 206,800 Mexican phone records.
fix: No CVE or vendor patch applies: the agents succeeded only against unauthenticated APIs, default credentials, open ports, SQL injection and unpatched Oracle databases, and failed wherever logins, valid sessions and endpoint filtering were enforced.
who: Emergency services, dispatch technology vendors, financial lenders and universities with long-standing internet-facing exposure are most at risk from low-cost AI-driven scanning at scale.

A single attacker running a homemade group of AI agents pulled 119 emergency dispatch records covering seven Taipei districts. The same agents found a Taipei fire department platform exposing patient data, including ECG readings and ambulance video footage, with no login required. Acronis's Threat Research Unit says it is highly confident the operation, called BOSSAI, was run by one person based in Hualien City, Taiwan. The agents were aimed at hundreds of organizations in at least 11 countries, including emergency services, banks, universities and military systems. They collected data or accessed systems at about 10 of them in Taiwan, Mexico and Thailand.

The evidence came from the attacker's own infrastructure. A server that first looked like a misconfigured development system turned out to be his operational attack platform. It held more than 90,000 files: agent conversations, command history, hacking tools, credentials and victim data. Researchers watched the operation for 12 days.

Emergency Services Took the Hardest Hit

Taiwan was targeted far more heavily than any other country. The most serious confirmed harm involved a city system for 119, Taiwan's fire and ambulance number. The agents pulled the dispatch records directly from the system's public-facing API. The records include incident times, response types, case status and street-level locations. They are case records, not live ambulance tracking. Street-level incident data tied to medical calls is still sensitive.

The Taipei patient platform had exposed medical data dating back to 2018. The report is inconsistent on what happened to it. The summary says breaches at emergency services led to theft of medical data, while the detailed account says only that the records were exposed. The report also does not say whether the affected organizations or Taiwanese authorities were notified, or whether the data can still be reached.

The agents also went after five other targets tied to Taiwan's emergency services:

Fire-dispatch technology vendor: logged into its database admin panel with default root credentials and reached 18 or more tables. A web shell attempt through a known CVE failed.
Emergency management information system: found a hardcoded AES-256 key in front-end JavaScript that exposed session-cookie contents, including an administrator's identity. No confirmed compromise.
National disaster-response center: a scanning tool reported a critical Apache remote code execution flaw that did not exist.
National fire agency single sign-on portal: brute-force login attempts with no confirmed access.
Fire-department systems in five cities: scanned to identify the software they run. No confirmed compromise.

⚠️ Default credentials at a dispatch vendor — The fire-dispatch technology vendor's database admin panel accepted default root credentials, which gave the agents 18 or more tables. One weak vendor serving several dispatch centers puts every one of its customers at risk.

Targets Beyond Emergency Services

In Taiwan, the agents used SQL injection to pull data from an account table at a lending firm that had 16 injection points. In Thailand, they selected 489 potential targets across 45 institutions and collected data from three universities through SQL injection against unpatched Oracle databases. In Mexico, they collected about 206,800 home phone records with names and addresses by combining government statistics, postal code lists and telecom authority data.

About 15 more organizations were attacked without a confirmed break-in. In at least eight other countries, targets were only scanned or queued for attacks that had not run by the time researchers looked.

How BOSSAI Was Built

BOSSAI had 12 AI agents, 9 of them in use. Some built and maintained the attacker's servers and tools. Others scanned targets and carried out attacks. The agents could not talk to each other, so the attacker pasted one agent's output into another by hand.

Commercial cloud models did most of the building, with Grok as the main builder. When the attacker asked them directly to attack, Grok and MiniMax M3 refused and requested written proof of authorization. The researchers say it is unclear whether a forged authorization letter would have changed that. Grok made one exception: it repaired a broken proof-of-concept script, which the attacker then handed to an attack agent.

The attack agents ran almost entirely on abliterated models, meaning versions of DeepSeek, GLM and Qwen run locally with their safety training removed. The attacker also pointed the coding agents Claude Code and Codex at an abliterated model, though they mostly did infrastructure work. Cursor, another coding agent, attacked a Taiwanese emergency-services site while running on one of these models.

Refusals moved the attack instead of stopping it — Commercial model refusals pushed the offensive work onto self-hosted abliterated models. A provider's safety controls stop applying once an agent framework is pointed at a local model the attacker controls.

The Agents Got Things Wrong

The agents were unreliable. One scanning tool invented CVEs, and more than half of its high and critical findings were false positives or wrongly classified. The nonexistent Apache RCE at the disaster-response center is one example. The main attack agent also reported results that had not happened.

For defenders, this kind of activity shows up as heavy scanning with poor precision. Logs may show attempts against vulnerabilities the target never had, mixed in with real SQL injection and credential attacks that work on poorly protected systems.

Attribution Through OPSEC Failures

Acronis based its attribution on mistakes the attacker made while hiding his identity, combined with public information. He used the same identity for his legitimate businesses and his attack servers, including a GitHub profile, a logo, an SSH key name and an email address. His home IP address appeared in an SSH session inside one of his Grok conversations.

His motive is less clear. Some attacks on government, emergency and military targets resembled state-backed activity, while others looked like ordinary cybercrime. The researchers think he was probably after money, and it is unclear whether he works for anyone.

RedEye Assessment

BOSSAI did not create a new class of attack. Nearly everything it reached was already poorly protected: a medical data port open since 2018, dispatch records on an unauthenticated public API, a lender with 16 SQL injection points and universities running unpatched Oracle databases. The agents failed wherever logins were enforced, paywalls required a valid session and endpoints were properly filtered.

What changed is the cost. One person with a dozen loosely connected agents and local models with safety training removed scanned hundreds of organizations in 11 countries and reached about 10 of them. For critical infrastructure operators and their vendors, old exposure that nobody had bothered to exploit can now be found and reached cheaply. The 2018 patient data exposure was never secure. AI made it cheap to find.

Originally published on RedEye Threat Intelligence.