> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # So Your CFO's Phone Has Been Pwned: A DFIR Journey - URL: https://f4n6.co.uk/security-feed/so-your-cfos-phone-has-been-pwned-a-dfir-journey/ - Published: 2026-09-01T14:24:45.000Z - Updated: 2026-09-01T14:24:45.000Z - Author: Jeff Davies - Tags: #security-feed --- ## 1\. Executive summary Censys ARC (researcher: Aidan Holland) has published a DFIR walkthrough — the two incidents are fictional, but the malware families and infrastructure observations are real — covering two mobile compromise patterns relevant to EMEA financial services: an Android banking trojan of the ERMAC/HookBot lineage delivered as a sideloaded "Chrome Update" APK, and an iOS compromise involving the DarkSword commercial exploit chain (six chained vulnerabilities spanning iOS 18.4–18.7) deploying GHOSTBLADE credential-dumping modules. Both scenarios target exactly the executive population — CFO-class users with banking apps, corporate identity, and MFA on one device — that financial institutions struggle most to contain. The Android case turns a single device alert into an identity, financial-fraud, and corporate-access incident within minutes via accessibility-service overlay attacks on banking apps; the iOS case shows credential harvesting and full exploit-chain staging co-located on the same host, with infrastructure that rotates fast enough that current-state blocklists miss it. No CISA-KEV exploitation state, CVSS scores, or MITRE-attributed actors are recorded for this item in our verified reference data; the DarkSword vulnerability chain is not enumerated by CVE in the source, and no actor attribution is offered — treat both as unconfirmed. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 19: reporting of major ICT-related incidents to competent authorities | A CFO-class device with access to banking apps, corporate identity, MFA and password resets is compromised, plausibly exposing corporate credentials and enabling financial fraud — the incident's potential impact on the entity itself makes the major-incident classification assessment non-trivial | Run the Art. 19 classification assessment early; document the decision either way, because executive-device compromise with banking-app overlay tooling is exactly the fact pattern supervisors will ask about | | DORA Art. 17: ICT-related incident management process | The source demonstrates that mobile IR requires preserving the device, revoking sessions, resetting credentials, and retrospective scoping across historical telemetry — capabilities many financial entities lack for mobile endpoints | Verify your Art. 17 process actually covers supervised mobile devices: preservation before wipe, loaner issuance, credential-reset runbooks for executive mobile | No NIS2 or UK NIS article is engaged at a level beyond generic incident-handling duties; the item is a research/walkthrough piece, not a confirmed incident at a specific entity. ## 3\. Technical analysis & attack chain **Scenario 1 — Android (ERMAC/HookBot lineage).** Confirmed steps as described in the source: 1. **Initial access:** Social engineering — the user is convinced to install an app from a link, delivered outside the official app store. In the scenario, the package presents as "Chrome Update," installed as a **sideloaded APK**. Microsoft Defender for Endpoint (mobile threat defense on Android) raises the alert: malicious application, install source sideloaded APK, device risk high. Defender preserves installation source, path, timestamps, permissions, and threat metadata. 2. **Privilege acquisition on device:** The user is induced to grant **Android accessibility permissions**. The malware uses those privileges to watch and interact with other applications. 3. **Credential theft:** When the victim opens a targeted banking or cryptocurrency app, the malware places a **fake login interface (overlay) over the real one**. Credentials go to the attacker; **SMS messages and 2FA codes can be captured alongside**. 4. **Extended capabilities (Hook lineage):** Remote screen control, file management, and **WhatsApp manipulation**. 5. **Impact:** The single device alert immediately becomes an identity incident, a financial-fraud incident, and potentially a corporate-access incident. Scale indicator: Censys ARC found **484 prepared application overlays** in leaked panel software, spanning **more than 40 countries**, covering banks (SMBC named), wallets (PayPal named), and **more than 30 cryptocurrency applications** (Coinbase named). The source is explicit that this is tooling capability, not confirmed victim hits. **Infrastructure behaviour (HookBot C2):** The scenario device's mobile VPN logs show communication with `118.107.45[.]29`. Censys carried a **HookBot threat label on this host from mid-July through 13 August 2026**; it belonged to a **three-host CTG cluster**. Later scans no longer showed the expected panel port — not because the server died, but because the operators enabled an **IP-whitelist security gate**. The leaked HookBot source contains firewall logic that hides the **panel, API, and implant-facing socket** from anyone not on the allowlist. Operational lesson: a server can look dead to a scanner while functioning normally for the operator and infected devices. **HookBot infrastructure stack (from leaked deployment):** Laravel API, WebSocket relay, APK builder, MySQL, operator panel. Recurring ports shipped with the stack: **8089, 8088, 8000, 3434**. The most durable pivot is the **builder itself**: its bundled obfuscation pipeline contains strings operators cannot rename without breaking the build, and the **builder port is omitted from HookBot's own security gate** — i.e., it remains externally visible when the panel is gated. Panel names, IPs, and ports are weaker signals (mutable/gated). **Scenario 2 — iOS (DarkSword / GHOSTBLADE).** Confirmed steps as described: 1. **Initial access:** While travelling, the user receives a link on the phone and opens it in Safari. The page presents as an Apple sign-in prompt; the user enters their Apple ID. Something anomalous occurs; the page is closed. No mobile-malware alert fires — the investigation starts **downstream**, from a suspicious identity-team session involving the CFO's account from infrastructure inconsistent with normal activity. 2. **Telemetry path:** The device is supervised/MDM-managed with **Zscaler Client Connector** enforced, so all traffic (HQ, hotel Wi-Fi, cellular) transits Zscaler cloud. At incident time the destination was **not yet categorised as threatening**, so the transaction was allowed and logged like any other web request. Zscaler web/mobile telemetry preserves user, mobile-device information, URL/destination, and destination server IP. 3. **Infrastructure identification:** SIEM search scoped to the CFO's identity and iPhone around the link-open timestamp surfaces a connection to `103.106.190[.]217`. 4. **Threat capability:** Censys ARC observed this host as part of a **DarkSword cluster**. DarkSword is a **commercial iOS exploit chain built around six chained vulnerabilities spanning iOS 18.4 through 18.7**. A successful chain deploys **GHOSTBLADE** modules capable of **dumping keychain, iCloud, and Wi-Fi credentials and exfiltrating files**. The chain includes **cleanup behaviour intended to remove artifacts when finished**. 5. **Aggravating factor:** The same host (`103.106.190[.]217`) served an **Apple ID credential-harvesting page directly alongside DarkSword exploit-chain staging**, plus a **C2 Control Panel**, with a **TLS certificate issued for `ng28jt[.]xyz`**. Per the source, it was the first host in the ARC investigation combining a credential-harvesting decoy and exploit-chain staging on one IP. 6. **Key IR question:** Whether credentials were merely phished, or the device was exploited — which turns on **whether the phone was running a vulnerable iOS version (18.4–18.7) at the time of the connection**. **DarkSword infrastructure rotation and pivots:** Infrastructure rotates quickly, so the researcher pivoted on the **SHA-256 body hash of the DarkSword Admin page**. That single artifact surfaced **seven hosts across three countries**, the same panel appearing on **:3000, :8443, :8888** across unrelated networks; **five of the seven hosts had not been serving it one week earlier**. Deeper pivots found hosts co-located with other exploit panels, **exposed MinIO**, **open directories containing `.bash_history` and `ffuf` artifacts**, and certificates revealing additional domains. **Confidence caveats.** This entire item is **single-sourced** (one vendor blog, Censys, drawing on its own ARC research by one named researcher). The two incidents are explicitly **fictional scenarios**; the malware families, exploit infrastructure, and Censys observations are stated as real, but we cannot independently corroborate them. No CVE identifiers are given for the six chained DarkSword vulnerabilities, so affected iOS versions cannot be mapped to patches from this source alone. No threat-actor attribution is made and no MITRE profile exists in our verified data — any attribution discussion around ERMAC/HookBot or DarkSword should be treated as unconfirmed. The 484-overlay figure demonstrates operator tooling intent, not victim compromise. Verify before enforcement. ## 4\. Mitigation & containment ### P1 — within 24 hours (active compromise of an executive mobile device) - Block the compromised device from corporate resources; revoke all active sessions for the affected user (both scenarios). - Preserve the phone for mobile forensics **before wiping or rebuilding** — especially in the iOS case, where GHOSTBLADE cleanup behaviour may have already removed artifacts and forensics is time-sensitive. - Issue a loaner device; ensure any replacement iPhone is running a **patched version of iOS (above 18.7)** before handover. - Reset corporate credentials used from or accessible via the phone; evaluate passwords stored in any password manager accessible from the device; **treat SMS-based MFA as potentially exposed** and migrate affected accounts to non-SMS MFA. - In the Android case: extract the APK, its hash, install timestamp, and retained network telemetry from Defender for Endpoint; confirm whether accessibility permissions were granted and to which package. - In the iOS case: determine the iOS version running on the device **at the time of the connection** to `103.106.190[.]217` — this decides whether the response is a credential reset or a full exploitation investigation. Review Apple ID activity. - Block the observed infrastructure (`118.107.45[.]29`, `103.106.190[.]217`, `23.248.212[.]122`, `156.234.84[.]242`, `ng28jt[.]xyz`) at proxy/DNS/firewall — recognising this is a floor, not a fix, given rotation. ### P2 — within 72 hours (scoping) - Search proxy, DNS, firewall, and mobile telemetry — **including historical logs** — for the known infrastructure and related domains. The source is explicit: if the infrastructure rotated last week, today's threat list will not save you. Look for other devices that contacted the uncovered hosts. - Trace Active DNS resolutions of the C2 hosts to previous IPs and check whether those appear in your logs (the source's worked example: `23.248.212[.]122` and `156.234.84[.]242`). - In the Zscaler case, scope SIEM searches to the affected identity and device around the suspected window using user, device, URL, and destination-IP fields. - Determine what corporate secrets or credentials were accessible through the device (executive email, Slack, expense accounts, password resets, travel, investor correspondence). - For Android fleets: audit for sideloaded APKs and unexpected accessibility-service grants across all managed devices, not just the alerting one. ### P3 — within 7 days (durable detection and hardening) - Build detections around **infrastructure characteristics** rather than disposable IPs: for HookBot, the recurring stack ports (8089, 8088, 8000, 3434) and the builder's obfuscation-pipeline strings (which survive operator renaming and are not covered by the security gate); for DarkSword, the admin-page body hash and panel ports :3000/:8443/:8888. - Track the identified clusters in a threat-intelligence collection and feed new observations back into SOC tooling. - Harden the mobile estate: block sideloading on managed Android devices via policy; enforce supervised/MDM-managed web filtering on iOS so all traffic is logged (the Zscaler deployment in the scenario is what made the iOS case investigable at all); ensure iOS fleet patch levels are above 18.7. - Update the IR plan to cover executive mobile devices explicitly — the source's core observation is that these devices concentrate banking apps, identity, MFA, and password resets and are routinely absent from IR runbooks. ## 5\. Indicators of compromise All indicators are single-sourced (Censys ARC / Aidan Holland research). Verify before enforcement. | Type | Value | Confidence | Source | | ------ | ------------------- | ----------------------------------------------------------------------------------------------------------------- | ----------- | | ipv4 | 118.107.45\[.\]29 | Medium — Censys-observed HookBot-labelled host, mid-July to 13 Aug 2026; panel later gated | Censys blog | | ipv4 | 103.106.190\[.\]217 | Medium — Censys-observed DarkSword cluster host; Apple ID harvesting page + exploit staging + C2 panel co-located | Censys blog | | ipv4 | 23.248.212\[.\]122 | Low — historical DNS resolution pivot from HookBot infrastructure; relationship stated as investigative example | Censys blog | | ipv4 | 156.234.84\[.\]242 | Low — historical DNS resolution pivot from HookBot infrastructure; relationship stated as investigative example | Censys blog | | domain | ng28jt\[.\]xyz | Medium — TLS certificate on 103.106.190\[.\]217 | Censys blog | ```iocs ipv4 118.107.45[.]29 ipv4 103.106.190[.]217 ipv4 23.248.212[.]122 ipv4 156.234.84[.]242 domain ng28jt[.]xyz ``` **Behavioural indicators** (no atomic artefacts; these are the observable patterns the source describes): | Behaviour | Where to observe | Confidence | | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Sideloaded APK installed on managed Android device, presented as "Chrome Update" | MDM / Defender for Endpoint mobile threat defense — install source, path, timestamps, permissions | Medium (scenario construct; sideload delivery is consistent with the family) | | Android accessibility service granted to a non-store application | Android device policy / MDM accessibility audit | Medium | | Overlay/fake login interface displayed over banking or crypto apps | On-device; EDR mobile telemetry; user report | Medium | | Mobile device communicating with C2 on ports 8089, 8088, 8000, 3434 (HookBot stack) | Mobile VPN/proxy/DNS logs | Medium — ports ship with the leaked stack but are mutable | | Admin panel served on :3000, :8443, :8888 (DarkSword) | External scanning / proxy logs | Medium | | Suspicious identity session from infrastructure inconsistent with user's normal activity, with clean laptop and no phishing email | IdP / SIEM session logs | High as a detection pattern (source's stated iOS detection path) | | iOS device on version 18.4–18.7 contacting DarkSword-staging infrastructure | MDM patch-level inventory correlated with web proxy telemetry | High as a risk condition (source states chain spans these versions) | ## 6\. Detection The sources contain usable infrastructure and behavioural artefacts. Note the constraint: the HookBot builder's obfuscation-pipeline strings are described as existing but are **not reproduced in the source**, and the DarkSword admin-page SHA-256 body hash is likewise **not published** — so neither can be embedded in a rule without fabrication. What the source does give us verbatim: port numbers, panel names, certificate domain, and the "Chrome Update" package lure. The YARA rule below targets the lure string as it would appear in a malicious APK's resources; the Sigma rules target the observable log behaviours. ```yara rule MOBILE_Android_BankingTrojan_ChromeUpdate_Lure { meta: author = "Adverse Trace" date = "2026-09-01" reference = "https://censys.com/blog/so-your-cfos-phone-has-been-pwned-a-dfir-journey/" description = "Detects sideloaded Android APKs presenting as a Chrome update lure, consistent with ERMAC/HookBot-lineage banking trojan delivery described by Censys ARC. Lure string only - not family-specific." confidence = "medium" strings: $lure1 = "Chrome Update" wide ascii $lure2 = "Chrome_Update" wide ascii condition: all of them } ``` ```yaml title: Android Sideloaded APK with Accessibility Service Grant on Managed Device id: 7b0d3f4a-2c1e-4f8b-9a6d-1e5c8f2b7a30 status: experimental description: > Detects installation of a sideloaded APK followed by an accessibility-service grant, the delivery-and-privilege pattern used by ERMAC/HookBot-lineage Android banking trojans per Censys ARC (AT-2026-09-01-699). Tune to your MDM's event IDs. references: - https://censys.com/blog/so-your-cfos-phone-has-been-pwned-a-dfir-journey/ author: Adverse Trace date: 2026-09-01 logsource: category: application_install product: android service: mdm detection: selection_install: EventID: - 'application_install' # map to your MDM install event InstallSource: 'sideloaded' selection_accessibility: EventID: - 'accessibility_service_enabled' # map to your MDM/EDR event condition: selection_install and selection_accessibility timeframe: 24h falsepositives: - Legitimate sideloaded enterprise apps granted accessibility (accessibility tools) level: high ``` ```yaml title: Mobile Device Communication to HookBot-Stack or DarkSword-Panel Ports id: 3f9c2e1d-8a4b-4c7e-b5d6-9e0f1a2b3c4d status: experimental description: > Flags outbound mobile traffic to ports associated with the leaked HookBot deployment stack (8089, 8088, 8000, 3434) and DarkSword admin panels (3000, 8443, 8888) per Censys ARC (AT-2026-09-01-699). High false-positive rate on generic services - use as a hunt, not an alert, and enrich with destination reputation. references: - https://censys.com/blog/so-your-cfos-phone-has-been-pwned-a-dfir-journey/ author: Adverse Trace date: 2026-09-01 logsource: category: proxy detection: selection: DestinationPort: - 8089 - 8088 - 8000 - 3434 - 3000 - 8443 - 8888 filter_legitimate: DestinationHostname|endswith: - '.google.com' - '.apple.com' condition: selection and not filter_legitimate falsepositives: - Any legitimate service on these common ports; requires destination enrichment level: low ``` ## 7\. Sources - Censys, "So Your CFO's Phone Has Been Pwned: A DFIR Journey" — https://censys.com/blog/so-your-cfos-phone-has-been-pwned-a-dfir-journey/ — 2026-08-31 ## 8\. Adverse Trace position This is a capability-and-infrastructure advisory, not a confirmed campaign against a named victim: the incidents are fictional, the underlying malware families and infrastructure observations are real, and everything rests on a single vendor's research — we assess the technical detail as credible but single-sourced, and clients should verify before enforcement action. Severity for EMEA financial services is **high as a risk condition, not as an active incident**: the tooling demonstrably targets banking apps (SMBC, PayPal, Coinbase named among 484 overlays across 40+ countries), the iOS chain covers versions 18.4–18.7 with credential-dumping payloads and anti-forensic cleanup, and both patterns concentrate impact on executive devices that sit outside most IR runbooks. The operationally valuable takeaway is the pivot methodology — infrastructure history, stack ports, builder artefacts, body hashes — which outlives the specific IPs listed here. Our verified reference data resolves no CVSS, KEV state, or actor attribution for this item, and we will not manufacture any. Next: we are monitoring for independent corroboration of the DarkSword chain and any CVE enumeration of its six vulnerabilities; if the iOS versions map to published CVEs with KEV entries, we will reissue with an updated regulatory framing. Clients should treat this as a prompt to test mobile IR readiness — device preservation, session revocation, historical telemetry scoping — against DORA Art. 17 incident-management expectations. --- [Read the original source →](https://censys.com/blog/so-your-cfos-phone-has-been-pwned-a-dfir-journey/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*