Potential AdFection Targets Stay Powered On but Off the Network

Cisco says CVE-2026-76519 is actively exploited through crafted attachments, enabling arbitrary file writes and potentially unauthenticated root command execution, but describes only a limited number of affected customers. You previously argued that exposed Ivanti appliances should be presumed compromised because the observed chain evaded integrity checks. Take a firm position on whether that same presumption is justified for internet-reachable Cisco Secure Email Gateways. Separate confirmed mechanics from inference, identify the telemetry that could rebut compromise, and give the 30-minute CISO decision for tonight. Explicitly argue where urgency could be overstated.

Halil, no—a blanket “internet-reachable equals compromised” presumption is not justified. Fact: this path requires File Reputation to be enabled and assigned to a mail policy, with Content Scanner Tools earlier than 25.3.0.5525. Cisco describes unauthenticated arbitrary file writes through crafted attachments and says successful exploitation can reach root command execution; CISA lists the flaw as exploited. An exposed gateway outside those configuration conditions is not vulnerable through this path. For an exposed gateway that meets them, contain it immediately—but reachability alone does not prove compromise. That would confuse an unlocked door with footprints inside. Cisco (opens in new tab) CISA (opens in new tab)

Confirmed mechanics: relative path traversal enables arbitrary file placement, potentially closing into root execution. Inference: Cisco’s “limited number” of affected customers says something about observed campaign breadth, not whether another vulnerable gateway is safe. Unknown: the evidence available does not establish the exact post-write execution sequence, a public weaponized PoC, or campaign prevalence. So urgency is overstated if someone declares every Cisco SEG breached or demands an automatic fleet-wide rebuild. It is not overstated for a gateway matching both prerequisites: unauthenticated delivery, root potential, active exploitation, and no workaround make that an urgent containment case. Cisco (opens in new tab) BleepingComputer (opens in new tab)

The best rebuttal is historical configuration evidence proving the gateway was never vulnerable during the exposure window. Next best is complete, immutable off-box coverage—message tracking and retained attachments plus firewall, DNS, proxy, and flow telemetry—showing neither exploit delivery nor unexpected gateway downloads or uploads. Run grep "System Security" system_logs on every cluster member, but a local “No compromise indicator” result is weak reassurance because root-level access can hide or remove local evidence. A suspected-compromise result, incomplete scan, integrity failure, or suspicious off-box traffic crosses the rebuild threshold. Cisco (opens in new tab) CERT-EU (opens in new tab)

Tonight’s 30-minute CISO decision: identify every internet-facing SEG meeting both prerequisites; preserve logs and snapshots; reroute mail and isolate those systems; begin the fixed-version rollout. Do not mistake patching for eradication. Escalate to incident response, Cisco TAC, trusted rebuild, and relevant credential or cluster-key rotation when compromise indicators appear or the security scan cannot complete. The decision is contain every exposed vulnerable gateway now, but do not label every one compromised without evidence.

Unknown attackers reportedly manipulated internet-exposed refrigeration controllers at hundreds of French supermarkets, raising temperatures, triggering defrost cycles, suppressing alarms, and contributing to spoilage and reported fires; 1,506 Danfoss StoreView panels were observed exposed, but investigators have not tied the attacks to CVE-2025-41450, CVE-2025-41451, or CVE-2025-41452. Define the safest containment sequence that avoids turning a cyber response into a food- or fire-safety incident. State when to disconnect, when to use manual/local control, what evidence to preserve, and what operational thresholds require disposal or shutdown. Challenge the simplistic advice to 'take everything offline.'

Halil, “take everything offline” is the wrong move. The reported incident affected refrigeration and was associated with food losses and fires under investigation; indiscriminate power-down could stop compressors, fans, alarms, and local control at once. Treat StoreView/AK-SM as the exposed supervisory layer—roughly Purdue Level 2/3—not as the refrigeration plant itself. The objective is to sever hostile remote control while keeping validated Level 1 case and rack controllers operating locally.

Safest containment sequence:

1. Put life safety first. If there is smoke, fire, electrical overheating, suspected refrigerant release, or unsafe pressure, evacuate the affected area and use the site’s emergency shutdown and fire procedures. Cyber evidence becomes secondary.
2. Freeze operations, not refrigeration. Stop remote setpoint changes, scheduled defrost commands, and nonessential maintenance. Place affected food on hold and deploy independent, calibrated temperature probes.
3. Preserve state if conditions are stable: photograph HMI displays, temperatures, setpoints, alarm status, clock time, and device labels; export StoreView alarms, audit/event logs, configuration and user records; preserve firewall/VPN logs and available traffic captures. Record every operator intervention. Do not reboot or upgrade yet.
4. Disconnect the hostile path first. Block internet ingress/egress, vendor access, port forwarding, and StoreView remote-management sessions at the firewall or OT DMZ. If commands continue, disconnect the StoreView/AK-SM management interface from the upstream network. Leave local refrigeration controllers powered and communicating only if operators verify stable automatic or manual/local control.
5. Escalate to cabinet/rack isolation only when local control cannot be trusted. Transition circuit by circuit under refrigeration-engineer supervision, watching suction/discharge pressure, compressor cycling, coil temperature, and defrost termination. Any firewall or segmentation change must first be checked against required controller communications; severing the wrong path can create the very heating or pressure event being contained.

For food disposition, use the store’s approved HACCP limits and measured product temperature/time, not the compromised controller display. EU guidance uses −18°C as the reference temperature for quick-frozen food, with only defined tolerances during distribution and retail display. Quarantine and obtain food-safety approval whenever independent records show a product exceeded its validated limit, or when the time-temperature history cannot be established; dispose when the HACCP decision rule or competent authority requires it. Operational shutdown is mandatory for fire/smoke, refrigerant or pressure danger, loss of stable local control, repeated uncommanded defrost, or inability to monitor the process independently. Move unaffected stock to verified cold storage before any planned shutdown where safely possible.

Do not assume the named CVEs were the entry route. Danfoss identifies CVE-2025-41450 as improper authentication; CVE-2025-41451 as post-authentication command injection leading to possible remote code execution; and CVE-2025-41452 as a post-authentication denial-of-service condition. Danfoss recommends current software, with 4.3.1 addressing the latter two, but upgrading belongs after stabilization, evidence capture, backup, and testing during a controlled maintenance window—not during an active temperature excursion.

Citizen Lab links Discover-Tech's AdFection operation to targeted advertising that profiled selected users and delivered zero-click Candiru infections at Al Jazeera, with advertising IDs and carrier weaknesses supporting reconnaissance and deanonymization. Break the chain into ad targeting, selection, exploit delivery, and spyware execution. Which parts are strongly evidenced, what device or network traces might survive, and what can defenders realistically hunt after a zero-click infection? End with a decision-ready response for media organizations and other high-risk users, not generic mobile hygiene.

The chain does not have equal evidentiary strength:

• Ad targeting — strong: Citizen Lab reports that Discover-Tech’s advertising system was used as a delivery pipeline for the attacks.
• Victim selection — strong: At least 45 Al Jazeera devices were targeted during 2024–2025. Advertising IDs can act as stable correlation handles, but they are reconnaissance artifacts—not malware indicators.
• Exploit delivery — strong, at campaign level: Citizen Lab links the zero-click attacks with high confidence to Candiru spyware delivered through Discover-Tech ads.
• Spyware execution — less certain per device: “Targeted” does not automatically mean successful code execution. I found no public sample hash, unpacked payload, or sandbox/static-analysis record here that would let me validate the final Candiru stage instruction by instruction. Per-device compromise therefore requires forensic confirmation.

The likely surviving evidence is distributed across several layers. Assessment: ad-platform records may retain advertising IDs, campaign-selection events, creative requests, and redirect timestamps; enterprise DNS, proxy, TLS, and mobile-network telemetry may retain short-lived delivery contacts. Device acquisition may recover browser or WebView diagnostics, crash records, network databases, and timing-correlated system events even if the payload was memory-resident. Carrier signalling data is especially important for reconstructing reconnaissance: Citizen Lab separately documented location-discovery activity using telecom signalling and noted that leased or third-party signalling access can conceal the operator. That supports the feasibility of carrier-assisted profiling, but it should not be treated as proof that every such event belonged to AdFection.

For media organizations, the decision is straightforward: place identified targets into suspected compromise, not merely “phishing exposure.” Preserve the device before wiping it, remove it from sensitive communications, obtain a specialist forensic acquisition, and rotate privileged credentials and active sessions from clean hardware. Request timestamped ad-delivery records from advertising partners and signalling records from the carrier; correlate those with DNS, proxy, identity, email, and messaging logs. After preservation, replace or fully reprovision the handset. Do not wait for mobile antivirus or a YARA hit—without a recovered payload, the best hunt is a joined timeline across ad delivery, carrier activity, device diagnostics, and account access.

The board now contains active root-level compromise paths through Ivanti Connect Secure, Cisco Secure Email Gateway, PAN-OS, and BeyondTrust Remote Support. Focus only on the identity and trust-chain blast radius. Which credentials, sessions, certificates, API keys, federation relationships, and downstream administrative paths should be considered exposed for each appliance class, and in what order should containment, rebuilding, session invalidation, and rotation occur? Give one prioritized playbook and identify any case where mass rotation would create more risk than it removes.

The trust boundary is the whole appliance, not merely its administrator password. Fact: reporting on Ivanti describes root access plus theft of LDAP domain credentials, Active Directory password searches, and password spraying. Reporting on Cisco describes unauthenticated root command execution, possible erasure of local evidence, and rebuilding for suspected virtual-appliance compromise. Unknown: the evidence available here does not establish exactly which secrets were extracted from the PAN-OS or BeyondTrust systems. Assessment: every secret the appliance could store, issue, decrypt, relay, or observe after compromise must be treated as exposed.

• Ivanti Connect Secure: LDAP bind/domain credentials are confirmed in scope. Also presume exposure of local administrators; RADIUS/TACACS shared secrets; SAML service-provider signing/decryption private keys; OIDC client secrets where configured; VPN session cookies or tokens; client-certificate trust material; and monitoring/API credentials. Downstream scope includes Active Directory and every internal service reachable through the VPN.
• Cisco Secure Email Gateway: presume exposure of appliance administrators and sessions, directory-bind credentials, SMTP relay authentication, TLS private keys, DKIM signing keys, API credentials, and service accounts for mail, SIEM, ticketing, or remediation integrations. Treat administrative trust into downstream mail infrastructure as compromised.
• PAN-OS: presume exposure of local and Panorama administrator credentials, XML/API keys, LDAP bind credentials, RADIUS secrets, SAML service-provider keys, OIDC client secrets where configured, GlobalProtect sessions or authentication cookies, portal/gateway TLS private keys, device certificates, site-to-site VPN preshared keys, and cloud-management integrations. The downstream administrative blast radius includes Panorama and any environment reachable through management, GlobalProtect, or trusted tunnels.
• BeyondTrust Remote Support: presume exposure of representative and administrator sessions, local credentials, SAML/OIDC integration secrets, API tokens, endpoint or jump-item credentials available to the appliance, integration service accounts, and endpoint trust certificates or keys. Scope every endpoint and administrative plane reachable through Remote Support—not just accounts stored locally.

The prioritized playbook is: (1) establish clean break-glass identities and a management channel that does not traverse any affected appliance; preserve centralized evidence, then isolate each appliance from users, management networks, and downstream systems. (2) At the consuming systems, immediately disable its federation, certificate, API, and administrative trust; invalidate VPN, web, API, representative, and privileged downstream sessions. Password rotation alone is inadequate. (3) Rebuild or reimage from trusted vendor media and import only reviewed configuration—not an opaque full-state backup. (4) Generate replacement secrets from the clean control plane and install them only on rebuilt systems, rotating in order: directory/Tier-0 and management credentials, federation private keys and API tokens, privileged endpoint credentials, then lower-impact integration accounts and transport keys. (5) Re-establish each trust relationship explicitly, perform a second session revocation after cutover, and move human administrators to WebAuthn/FIDO2 while replacing static service keys with short-lived workload identity where supported.

Mass rotation becomes counterproductive when it destroys the only clean recovery path or causes uncontrolled dependency failure. The clearest cases are rotating all PAN-OS tunnel keys or management certificates simultaneously, rotating Cisco DKIM/TLS keys before DNS and mail peers are staged, or changing every BeyondTrust-managed service account at once. Quarantine the old trust first, stage and verify replacements dependency by dependency, then revoke the old material. The exception is a federation signing or decryption key known or reasonably presumed stolen: consumers should stop trusting that key immediately rather than retain dual-key acceptance for convenience.

Rank the evidence—not the CVSS—for the active-exploitation claims involving PAN-OS CVE-2026-0322, BeyondTrust CVE-2026-102764, FortiClient EMS CVE-2026-35616, and the FortiManager/FortiOS PEERSTITCH intrusion. Identify which claims rest on vendor or government confirmation versus one secondary source, and distinguish observed exploitation from public PoC or KEV status. Make the editorial call: which one joins Cisco and Ivanti in tonight's executive action list, which become quick hits, and which should remain monitoring. Push back on the source pack where its urgency outruns its evidence.

Evidence ranking:

1. PAN-OS CVE-2026-0322 — high confidence: The pack marks this as vendor/official-body corroborated and provides multiple reports. This is observed exploitation, not merely PoC availability or KEV inference. It joins Cisco and Ivanti on tonight’s executive action list.
2. PEERSTITCH — moderate-low confidence: The report describes an observed FortiManager/FortiOS intrusion campaign, but the pack has only one secondary source and no visible Fortinet or government confirmation. Keep it in monitoring, with targeted hunting where those products are exposed.
3. BeyondTrust CVE-2026-102764 — low confidence: “Active exploitation” currently rests on one CyberKendra article. Make this a quick-hit exposure and patch check, not an executive-level confirmed campaign.
4. FortiClient EMS CVE-2026-35616 — low confidence: Despite the pack’s “must lead” designation, the claim rests on one GBHackers article. That urgency outruns the evidence; treat it as a quick-hit inventory/advisory check.

The visible evidence does not independently establish public-PoC or KEV status for these four claims, so neither should be implied. KEV would confirm exploitation, not identify an actor; no actor attribution is supportable here.

Maya assesses the AdFection ad-targeting and victim-selection stages as strongly evidenced, while the technical evidence is not equally complete across every device. Al Jazeera was targeted and Discover-Tech has reported Israeli links, but location and victim profile do not establish state direction. State the strongest geopolitical inference the evidence supports, the inference it does not support, and what additional evidence would be required to connect this to government tasking. Then explain what changes now for media organizations operating amid regional conflict even if attribution remains unresolved.

Maya, the strongest geopolitical inference is a commercial-surveillance nexus with Israeli roots operating against a politically sensitive media target. Citizen Lab reports that Discover-Tech, an Israeli company with years of spyware-industry links, purchased the advertisements that enabled Candiru spyware infections on Al Jazeera devices. That supports an assessment of intelligence-oriented targeting shaped by the regional information struggle: journalists’ sources, movements, and editorial planning may be more valuable than the devices themselves. It does not establish Israeli government direction, authorization, or even knowledge. Vendor nationality, victim profile, and strategic alignment identify a nexus—not the taskmaster. Citizen Lab (opens in new tab)

Connecting this operation to government tasking would require a much shorter evidentiary chain: customer or procurement records, payment trails, export-licensing documents naming the end user, customer-tenant or operator-panel logs, tasking lists matching the victims, infrastructure attributable to a government unit, or communications showing officials directing Discover-Tech, Candiru, or an intermediary. Without that, the responsible customer remains unknown; plausible state benefit is not proof of state control.

For media organizations, however, unresolved attribution changes little operationally. Conflict reporting should now assume that ordinary advertising inventory can function as surveillance infrastructure, bypassing phishing awareness entirely. High-risk newsrooms should separate sensitive reporting from general browsing, use tightly managed and rapidly patched devices, retain DNS/proxy/ad-delivery telemetry, investigate unexplained advertising redirects, and compartmentalize source identities, travel plans, and editorial communications. The provocative but necessary conclusion is that ad-tech is no longer merely a privacy problem for journalists—it is part of the contested intelligence terrain.

Sara warns that indiscriminate shutdown of compromised refrigeration controls can itself stop compressors, fans, alarms, and local control. Translate the French supermarket incident into concrete business decisions. Specify the operational thresholds for quarantining stock, closing a store area, invoking manual control, and escalating to executive crisis management when controller readings or alarms are untrusted. Give a small set of board metrics—no wide ranges—and identify the costliest mistaken assumption retailers could make tonight.

Sara is right: do not issue a fleet-wide shutdown command. The reported attack pushed refrigeration systems as high as 50°C, while reported losses at two Alsace stores totaled €270,000. France’s official limits vary by product—for example, +2°C for minced meat, +4°C for poultry and meat preparations, and generally −18°C for many frozen products. The exact temperature history and losses at each store remain unknown.

My decision thresholds would be:

• Quarantine stock immediately when readings or alarms become untrusted. Include every affected lot back to the last trusted timestamp; restored temperature does not release it.
• Close the affected aisle or cold room to sales if an independent calibrated probe cannot confirm compliant temperatures within 15 minutes, or immediately for smoke, overheating, or electrical anomalies. Close the whole store if compromised control crosses multiple departments or affects safe operation.
• Invoke manual control by isolating remote access—not necessarily equipment power—and using local control only after a refrigeration technician verifies compressors, fans, defrost cycles, and safety interlocks. Log independent readings every 15 minutes. If trusted local operation is not established within 30 minutes, transfer stock to validated storage or keep it quarantined.
• Escalate to executive crisis management when two stores are affected, anticipated stock loss exceeds €100,000 at one store, monitoring remains untrusted for 60 minutes, potentially exposed food may have been sold, or any fire, injury, authority notification, or recall is possible. Those are management thresholds, not statutory food-safety limits.

The board dashboard tonight needs only five numbers: stores with untrusted controls; minutes since last trusted reading; percentage of affected zones independently verified; euros of quarantined and destroyed inventory; and units potentially sold after the last trusted timestamp. The costliest mistaken assumption is that “temperature restored” means “food safe and system clean.” Re-cooling can conceal an unsafe exposure history; releasing that stock converts an inventory write-off into a potential customer-harm, recall, liability, and reputation event.

Close the operational loop. Alex finds that Cisco CVE-2026-76519 exposure is conditional on AMP File Reputation being enabled and assigned to a mail policy with vulnerable Content Scanner Tools, so internet reachability alone does not prove compromise. Sara says hard shutdown is unsafe for refrigeration controls; Maya says AdFection leaves uneven device telemetry; Marcus says a root-compromised security appliance invalidates downstream identity trust. Build a strict first-four-hours plan for a CISO covering Cisco, Ivanti, PAN-OS, BeyondTrust/FortiClient as applicable, French refrigeration systems, and high-risk media devices. Separate: isolate now, patch now, preserve evidence first, rotate trust later, and monitor only. If the panel is overreacting anywhere, say where.

First four hours — preserve in parallel; do not wait for perfect attribution.

• 0–30 minutes: Establish one incident commander and freeze nonessential appliance changes. Export configurations, logs, authentication records, DNS/NetFlow and firewall telemetry off-box before rebooting or upgrading anything suspicious. Inventory exact versions and exposure conditions. For Cisco, confirm AMP File Reputation is enabled, assigned to a mail policy, and Content Scanner Tools is below 25.3.0.5525; internet reachability alone is insufficient. Do not shut down refrigeration controllers: place site engineering in local/manual control and remove only remote or Internet access.
• 30–120 minutes — isolate now: Quarantine Cisco systems meeting all vulnerable conditions and reroute mail through a clean relay. Remove affected, externally exposed Ivanti Connect Secure appliances from service because CVE-2026-104935 permits unauthenticated command execution and may leave only memory-resident evidence. Restrict PAN-OS management interfaces to dedicated administrator addresses; fully isolate appliances showing suspicious management activity. Remove affected BeyondTrust Remote Support appliances from public access and suspend brokered privileged sessions. For FortiClient EMS, block untrusted access and isolate systems showing certificate-header anomalies, unexpected accounts, policy changes or fleet-wide script execution. Segment French refrigeration remote-management paths without interrupting local control. Keep suspected media devices powered, disconnect them from sensitive networks and accounts, and preserve them for specialist acquisition—no factory resets.

• 120–240 minutes — patch and recover: Patch clean-but-vulnerable Cisco, Ivanti and PAN-OS systems to vendor-fixed releases after a rapid staging test; FortiClient EMS 7.4.5/7.4.6 has an out-of-band hotfix reported as not requiring downtime. For suspicious or confirmed-execution appliances, patching is not eradication: rebuild from trusted media after preservation. BeyondTrust should likewise be isolated and preserved before upgrading; the evidence available here does not establish the exact fixed build. Rotate appliance SSH keys, certificates, API tokens, administrative credentials and invalidate sessions only after rebuilding or establishing a clean control plane—otherwise the attacker can capture the replacements. Systems demonstrably outside the affected configuration/version scope go into monitor-only, with retained network and identity telemetry.

The panel would be overreacting by isolating every Internet-reachable Cisco SEG regardless of its AMP policy, hard-stopping refrigeration, wiping every high-risk media device, or rotating credentials through a potentially root-compromised appliance. It would be underreacting to leave conditionally vulnerable Cisco, exposed Ivanti, affected BeyondTrust, or suspicious FortiClient EMS online merely because local logs look clean.

Claim: PAN-OS CVE-2026-0322 joins Cisco and Ivanti on tonight's executive action list with high-confidence observed exploitation; the remaining appliance stories should be ranked lower according to evidence strength. Counter-evidence: The handoff labels PAN-OS strongly, but its visible source lineage is largely secondary reporting. BeyondTrust CVE-2026-102764 and the FortiManager/FortiOS PEERSTITCH case each rely on a single eligible source, while FortiClient EMS combines reported zero-day exploitation, public PoC, and KEV status—three signals that are not equivalent. Rebuild the ranking using the underlying claim type rather than the handoff score: vendor-confirmed exploitation, government catalog status, researcher-observed intrusion, public PoC, and secondary reporting. State what a CISO should do tonight even where confidence is only adequate.

Halil, the contradiction is real: I gave the PAN-OS handoff label more weight than its visible primary evidence supports. The correct evidence hierarchy is vendor-confirmed exploitation > CISA KEV confirmation > researcher-observed intrusion > public PoC > secondary reporting. A PoC establishes feasibility; KEV establishes exploitation, but neither establishes campaign scale or attribution.

• FortiClient EMS CVE-2026-35616 — high confidence: reported Fortinet confirmation plus KEV status supports exploitation; the later public PoC increases copycat risk but is not proof of attacks. This replaces PAN-OS as the item joining Cisco and Ivanti tonight. Patch or isolate EMS, restrict management exposure, preserve logs, and hunt for unknown sources sending X-SSL-CLIENT-VERIFY: SUCCESS.
• PEERSTITCH — moderate confidence: a researcher-observed intrusion is stronger than a PoC, but the campaign currently has one eligible secondary source. Quick hit: patch affected FortiManager/FortiOS systems and conduct a scoped IOC/log review; do not infer actor or campaign scale.
• PAN-OS CVE-2026-0322 — moderate confidence: several reports repeat active exploitation, but the visible lineage lacks the direct Palo Alto or government artifact needed for my earlier high-confidence call. Quick hit: identify exposed systems, patch, and review exploitation telemetry; keep it below the executive-confirmed tier until the primary confirmation is produced.
• BeyondTrust CVE-2026-102764 — low confidence: one secondary report is insufficient to establish active exploitation. Monitoring: verify exposure and vendor patch status tonight, but do not declare an active campaign without vendor, government, or researcher corroboration.

All four plausibly map to MITRE ATT&CK T1190, Exploit Public-Facing Application, but no actor attribution is currently supportable.

Convert your uneven-evidence assessment into a containment and hunt plan for a media organization tonight. Separate actions for potentially targeted mobile devices, corporate ad-tech identifiers and accounts, carrier-facing risks, and browser/network telemetry. Be explicit about what not to do: when does wiping a device destroy the only useful evidence, and when is replacement safer than continued use? Keep attribution separate from remediation.

Halil, tonight I would run four parallel workstreams:

1. Potentially targeted phones: Stop using them immediately, but do not reboot, update, reset, or wipe them. Record owner, device model, OS version, SIM/eSIM, last-use time, and targeting reason; then keep each device powered, charged, and network-isolated for specialist acquisition. Issue a clean replacement and rotate sensitive credentials and sessions from clean hardware. Do not restore the old device wholesale onto the replacement. Wiping can destroy browser databases, crash logs, transient network records, and the only evidence connecting ad delivery to execution. After acquisition, or when forensic preservation is impossible and immediate personal safety dominates, erasure is reasonable—but replacement is safer than continued use whenever there is a credible targeting notification, matching ad-delivery record, or strong timeline correlation.

1. Ad-tech identifiers and accounts: Place legal and technical holds on bid-request, campaign, creative, redirect, administrator-audit, and API-access logs before normal retention deletes them. Export mappings involving advertising IDs, cookies, device fingerprints, IP addresses, and login tokens; Discover-Tech’s reported identity graph used those data classes. After export, revoke unexplained API keys and sessions and rotate account credentials from clean systems. Do not reset advertising IDs or delete campaign objects first—that may sever the correlation between a person, the winning ad request, and the delivery timestamp.

1. Carrier-facing risk: Ask carriers to preserve signalling and subscriber-management records, including location-discovery requests, roaming activity, profile changes, and SIM/eSIM or porting events. Apply account PINs and port freezes through a clean channel. Treat unusual signalling as evidence of reconnaissance, not proof of handset execution: Citizen Lab’s telecom research shows that legitimate operator identifiers and third-party access can obscure who initiated signalling activity. Do not replace the SIM inside an evidentiary phone before acquisition; provision the replacement separately.

1. Browser and network hunt: Freeze DNS, proxy/SASE, VPN, firewall, MDM, mobile-threat-defense, browser diagnostic, and crash telemetry. Build one UTC timeline around each suspected ad impression and search for redirect bursts, rare destinations, browser-process failures, and immediate account activity. Use Citizen Lab’s published infrastructure indicators where available, but do not expect a file hash or YARA match: no recovered AdFection payload was available in the evidence reviewed here. Remediation should proceed on exposure confidence, while Candiru/AdFection attribution remains a separate analytical judgment and must not be inferred merely from advertising IDs or carrier anomalies.

One final quick treatment for the item we deliberately kept below the active-appliance incidents: if Aoki infostealer is suspected on a developer workstation, which developer credentials, tokens, signing keys, repository sessions, CI/CD secrets, AI coding-assistant tokens, and cloud identities must be revoked or rotated first? What downstream repositories, builds, artifacts, and releases must be checked before... [arg clipped]

Halil, fact: recent Aoki variants target credential and session files for Claude, Codex, Cursor, Codeium, Gemini, GitHub Copilot, JetBrains AI Assistant and Kiro; reporting also identifies AWS credentials. Unknown: that does not prove every signing key or CI/CD secret on the workstation was stolen. Assessment: anything readable by the developer account—or loaded into its browser, shell, SSH agent, IDE or credential helper during the compromise window—belongs in scope.

The priority order is:

1. Isolate and reimage first. Rotating secrets while the stealer remains active simply exposes their replacements.
2. From a clean workstation, revoke credentials capable of changing source or publishing output: repository sessions, personal access tokens, OAuth grants, SSH/deploy keys, Git credential-helper entries, CI administrator tokens, runner-registration tokens, package-registry credentials, release credentials, and code-signing or provenance keys. Remove unknown deploy keys, webhooks, OAuth applications and runner registrations.
3. Revoke cloud-console/CLI sessions, AWS keys and cached federation sessions, then investigate associated role assumptions. Do the equivalent for any Azure, GCP, Kubernetes or production identities present.
4. Revoke AI-assistant tokens and every connected MCP or plugin credential. These are not “just AI subscriptions”; their OAuth grants may reach repositories, cloud services and engineering tools.
5. Reset the developer’s workforce account, invalidate all IdP and downstream sessions, and re-enrol with FIDO2/WebAuthn. Rotate passwords last because passwords are only one credential class.

Before restoring trust, inspect every accessible repository for unauthorized commits, tags, releases, branch-protection changes, collaborators, deploy keys, webhooks and OAuth grants across the complete suspected window. Review CI definitions, secret changes, runner activity, caches, artifacts and package publications. Match releases to reviewed commits and clean build logs; validate provenance independently, because a valid signature proves little if its private key was exposed. Rebuild affected artifacts on clean ephemeral runners, replace compromised signing keys, republish only verified outputs, and examine cloud audit logs for token issuance, role assumptions and deployment changes.