From Fake Video Meetings to In-Browser Espionage: A Forensic Case Study

Author: Anonymous (de-identified case study) Version: November 2026, public edition Subject areas: Digital forensics; Malware analysis; Social engineering; Browser security

Abstract

Advanced persistent threat (APT) actors targeting cryptocurrency holders increasingly use video-meeting invitations as their initial access vector. This paper reconstructs, through live-response forensics on a compromised macOS host, an intrusion that began with a Telegram meeting invitation and went undetected for 193 days. The attacker used a counterfeit Microsoft Teams lobby and a fake system password dialog to obtain the user’s password, and within about four minutes installed a root-privileged backdoor with LaunchDaemon persistence. Thirty-one days later, the backdoor planted a Manifest V3 extension masquerading as “Google Docs Offline” in all four Chrome profiles, paired with an unsigned Native Messaging Host. The extension exfiltrated every cookie every 30 seconds and provided keystroke and clipboard logging, screen capture, arbitrary script injection and remote shell execution, which explains how the victim’s Telegram account was taken over without any compromise of two-factor authentication. Using DNS name hashes in the unified log, we show that the system-level backdoor and the browser extension shared a single C2 domain, and we document anti-forensic timestomping of the extension. We conclude with actionable detection heuristics and a discussion of why session-theft-centred attacks defeat conventional password-plus-2FA defences. All victim-identifying information has been removed, and all times are given in UTC.

Keywords: macOS malware, social engineering, browser extensions, Native Messaging, session hijacking, BlueNoroff, digital forensics, cryptocurrency

1. Introduction

1.1 Motivation

Attacks on Web3 professionals and cryptocurrency holders have moved from bulk phishing email to highly tailored, real-time social engineering. Public reporting describes the DPRK-nexus group BlueNoroff using fake video meetings against macOS users since at least 2023 [1][2]. A 2025 incident added deepfake video participants and a lure to download a supposed “Zoom extension” that was actually an AppleScript [3][4].

Existing public material concentrates on the initial infection chain and first-stage payloads. Far less has been documented about how attackers expand their foothold during long dwell periods, and how a system-level backdoor and browser-level components cooperate. This case study helps fill that gap.

1.2 Research Questions

• RQ1: How did the attacker turn a single meeting invitation into root access and persistence on a macOS host?
• RQ2: Which additional components were deployed during the dwell period, and how did they interact?
• RQ3: Why was the victim’s messaging account taken over despite two-factor authentication?
• RQ4: Which observable host-level artefacts can defenders use to detect similar attacks?

1.3 Contributions

1. A complete timeline and kill chain for a 193-day macOS intrusion (Sections 4.1–4.2).
2. A source-level analysis of a browser spyware extension that combines Native Messaging with a remote shell (Section 4.4).
3. A method for correlating C2 across processes using DNS name hashes in the unified log (Section 4.5).
4. Documentation of extension timestomping and the evidence used to detect it (Section 4.6), and of a root-level mirror directory found only by the whole-disk IoC sweep (Section 4.7).
5. Six practical detection heuristics (Section 6.3).

2. Background and Related Work

2.1 BlueNoroff and Fake-Meeting Operations

BlueNoroff (also tracked as TA444 and associated with APT38) is generally regarded as the Lazarus sub-group focused on financial and crypto-asset theft. Kaspersky’s October 2025 research on GhostCall and GhostHire reports that GhostCall primarily targets macOS, approaches victims over Telegram and LinkedIn, and uses fake Zoom and Microsoft Teams clients across multiple infection chains to deploy a stealer suite [1][2]. In an incident handled by Huntress in June 2025, the attacker hosted a meeting on a lookalike Zoom domain and, citing a microphone problem, persuaded the victim to run an AppleScript named zoom_sdk_support.scpt, which led to several payloads including a keylogger and backdoors [3][4].

2.2 Browser Extensions and Native Messaging

Chrome extensions can exchange JSON messages over stdin/stdout with a locally registered native program through Native Messaging. On macOS, the host manifest sits in a user-level or system-level directory and lists, in allowed_origins, which extension IDs may call it [5]. The mechanism exists for legitimate software such as password managers. If an attacker controls both the extension and the native host, however, the browser sandbox is effectively bypassed: the extension can run arbitrary commands on the machine.

2.3 Session Hijacking and the Limits of 2FA

Two-factor authentication protects the act of logging in. After login, websites maintain the session with tokens stored in cookies or localStorage. An attacker who steals those tokens can reuse the victim’s session without knowing the password and without passing 2FA. MITRE ATT&CK classifies this as T1539 (Steal Web Session Cookie) and T1550.004 (Use Alternate Authentication Material: Web Session Cookie) [6].

3. Methodology

3.1 Subject and Context

The subject is an Apple laptop running macOS 26.x with a single administrator account. The victim reported being invited to a video meeting over Telegram in April 2026 and installing software, after which their Telegram account was hijacked. The investigation took place in November 2026, while the machine was still in daily use.

3.2 Forensic Approach

We used live-response forensics in four phases:

1. Read-only collection: data was read before anything was changed; every artefact was hashed with SHA-256 and archived in encrypted form before removal.
2. Hypothesis-driven analysis: starting from the time window reported by the victim, file-system birth times were used to build candidate events.
3. Exhaustive sweep: independent of that hypothesis, we systematically checked every persistence location, every unsigned Mach-O binary on disk, the code-signature integrity of every application, the TCC privacy database, network settings and trusted certificates.
4. Iterative re-examination: after remediation, three independent review rounds were run, each from a different detection angle.

3.3 Data Sources

3.4 Ethics and De-identification

Hostnames, usernames, victim-specific identifiers, personal software inventory and evidence paths have been removed; all times are given in UTC. Imagery from the victim’s screenshot is not reproduced. Malware samples are available to researchers and law enforcement on private request only.

4. Case Analysis

4.1 Intrusion Timeline

timeline
    title Intrusion timeline (UTC)
    2026-04-24 08h03 : Fake password-popup component created
                     : Staging directory created
    2026-04-24 08h04 : Victim screenshot - fake Teams lobby
    2026-04-24 08h06 : Root backdoor cloudsync written
    2026-04-24 08h07 : LaunchDaemon persistence created
    2026-05-05 : Stage-2 encrypted data
    2026-05-25 03h40 : Spyware extension and Native Host planted
    2026-06-03 : Stage-2 binary .authds
    2026-06-23 : LaunchAgent updated
    2026-11-03 : Detection, containment and eradication

Table 1: Key events (UTC)

Table 2: Dwell-period metrics

4.2 Kill Chain (RQ1)

sequenceDiagram
    autonumber
    actor A as Attacker
    participant TG as Telegram
    actor U as Victim
    participant W as Fake meeting page
    participant OS as macOS
    participant BD as cloudsync backdoor
    participant CH as Chrome spyware extension
    participant NH as Native Host
    participant C2 as C2 check02id.com

    A->>TG: Business-themed meeting invitation
    TG->>U: Meeting link
    U->>W: Lands on fake Teams lobby
    W->>U: Prompts for audio component or SDK update
    U->>OS: Runs downloaded content
    OS->>U: Fake system password dialog
    U->>OS: Enters login password
    Note over OS: Password captured then sudo escalation
    OS->>BD: Writes root backdoor and LaunchDaemon
    loop every 60 s
        BD->>C2: Beacon over TCP 5202
    end
    BD->>CH: Day 31 plants extension in 4 profiles
    BD->>NH: Plants and registers Native Host
    loop 162 days
        CH->>C2: Cookies, localStorage, keylog, screenshots
        C2-->>CH: Real-time tasks over WebSocket
        CH->>NH: Remote shell commands
    end
    A->>TG: Takes over account with stolen session

One feature of the chain stands out: the password was captured before privilege escalation. The fake password dialog (Mac-Password-Popup) appeared at 08:03, and root-owned files were written at 08:06. This is consistent with the attacker running sudo using the password the user typed. No zero-day vulnerability was involved; the intrusion relied entirely on the user’s trust.

4.3 Malware Architecture (RQ2)

flowchart TB
    subgraph Host["Victim host (macOS)"]
        direction TB
        subgraph P["Persistence"]
            LD["LaunchDaemon<br/>com.safari.sync.service"]
            LA["LaunchAgent<br/>com.apple.google.auth"]
        end
        subgraph S1["Stage 1 (root)"]
            CS["cloudsync<br/>unsigned Mach-O 7.26MB"]
            ENV[".com.apple.better.env<br/>encrypted config"]
        end
        subgraph S2["Stage 2"]
            AD[".authds<br/>unsigned Mach-O 5.24MB"]
            AA[".apple.auth<br/>encrypted data"]
        end
        subgraph B["Browser layer"]
            EXT["Fake Google Docs Offline<br/>MV3 extension"]
            NMH["google.chrome.diagnostics<br/>unsigned Native Host"]
        end
    end
    C2[("C2<br/>check02id.com")]
    LD -->|boot| CS
    CS --> ENV
    CS -->|download| AD
    CS -->|download| AA
    CS -->|install| EXT
    CS -->|install| NMH
    EXT <-->|nativeMessaging| NMH
    CS <-->|TCP 5202| C2
    EXT <-->|TCP 5078 / 8443| C2

The architecture can be read as two complementary control planes:

• System layer (cloudsync): has root privileges and persistence, but cannot see the browser’s encrypted sessions.
• Browser layer (extension): has direct access to cookies, page content and user input, and gains local command execution through the Native Host.

Because each layer has its own channel to the C2, removing one layer leaves the attacker partial control through the other. The investigation confirmed this in practice: after the system-level backdoor was removed in the first round, the extension kept talking to the C2 until it was found in the second round.

4.4 Spyware Extension Analysis (RQ3)

classDiagram
    class FakeDocsOfflineExtension {
        +id ppconlkbhfnachephglhgbhdgeapgjoj
        +manifest_version 3
        +location 4 not from Web Store
        +host_permissions all_urls
        +permissions cookies history tabs scripting desktopCapture pageCapture nativeMessaging
    }
    class ContentScript1 {
        +keydown keylogger
        +copy_paste clipboard capture
        +click triggers screenshots
        +visibilitychange uploads localStorage
    }
    class ContentScript2 {
        +hooks Google Meet join button
        +lures user into granting screen recording
    }
    class BackgroundWorker {
        +f3 uploads all cookies every 30 s
        +keylog uploads every 60 s
        +capture screenshot every 6 s
        +cmd4 wipes a site session
        +cmd11 uploads browsing history
        +cmd13 injects arbitrary JavaScript
        +cmd14_15_16 remote shell
        +cmd17 MHTML page capture
    }
    class NativeHost {
        +unsigned x86_64
        +executes payload
    }
    FakeDocsOfflineExtension *-- ContentScript1
    FakeDocsOfflineExtension *-- ContentScript2
    FakeDocsOfflineExtension *-- BackgroundWorker
    BackgroundWorker --> NativeHost : sendNativeMessage

Static analysis of the extension source identified three capabilities that are central to RQ3:

1. Session theft (f3, cmd3): every 30 seconds the extension calls chrome.cookies.getAll({}) to collect every cookie, including HttpOnly cookies, then Base64-encodes and exfiltrates them.
2. localStorage exfiltration: each time a page is shown, that site’s localStorage is uploaded. Single-page applications such as Telegram Web keep their login tokens in localStorage, which makes this the most likely route by which the victim’s Telegram account was taken over.
3. Forced re-login (cmd4): the attacker can wipe a chosen site’s cookies and storage, forcing the victim to log in again while the keylogger records the new password. This is a combined “invalidate the session, then harvest the credentials” tactic.

In addition, content-script2.js hooks the “Join now” button in Google Meet and uses that moment to prompt for screen-recording permission. The attacker deliberately exploits the moment the user is about to join a meeting, when such a request looks reasonable.

4.5 C2 Infrastructure Correlation

The macOS unified log masks DNS query names with hashes. Within a single boot session, we found that the name hash queried by cloudsync (PID 543) was identical to a name hash that Chrome queried 14,202 times. The extension’s configuration file had already confirmed that Chrome name as check02id.com.

We therefore infer that the system-level backdoor (port 5202) and the browser extension (ports 5078 and 8443) shared one C2 domain, separated only by port. This method allows cross-process infrastructure correlation even when packed binaries cannot be reverse-engineered.

4.6 Anti-forensics: Timestomping

Some files inside the extension directory show a birth time of 2025-10-16, and the install time recorded in Secure Preferences is 2025-08-13; both predate the initial intrusion. We judged these timestamps to be forged on four grounds:

1. No malicious activity or suspicious download exists anywhere on the disk on 2025-10-16.
2. data.js, which embeds the victim’s hostname, and the Native Host binary were both created at 2026-05-25 03:40:46. These files could only have been produced on the victim’s machine.
3. A sub-directory has an earlier birth time than its parent, which fits extraction from an archive that preserved original timestamps rather than native creation on the host.
4. The whole-disk IoC sweep found a cached copy of the extension’s background.js in Chrome’s Service Worker script cache, created at 2026-05-25 03:40:51, five seconds after data.js. This is consistent with the extension’s first load and execution.

The implication is that forensics relying on extension install times alone can badly misjudge the start of an intrusion.

4.7 Persistence State Mirrored Under Root

The whole-disk IoC sweep also found a directory that two rounds of manual review had missed: /Users/root/Library/. On macOS the root home directory is /var/root; a normal system has no /Users/root. The directory is root-owned and its layout exactly mirrors the malicious files in the victim’s home: an empty Identification/ and an Authorization/auth.db whose content points to Identification/.verify.

It was created at 2026-06-23 03:17:32 UTC, in the same second as a new entry in the TCC ad-hoc signature cache; when auth.db was modified at 05:39:36 UTC, another cache entry appeared simultaneously. A plausible explanation is that the malware, running as root, built its home path as “/Users/ plus the current user name” instead of querying the system, and so recreated its state files under a non-existent /Users/root. No persistence item referenced the directory at the time of investigation.

This finding shows two things: a whole-disk sweep for IoC strings fills blind spots left by manual review, and detection rules should not look only at real users’ home directories, since directories under /Users/ that match no account are also worth flagging.

5. Remediation and Verification

stateDiagram-v2
    state "Detection" as D
    state "Contain system layer" as C1
    state "Eradicate system layer" as E1
    state "Review 1" as R1
    state "Contain browser layer" as C2s
    state "Eradicate browser layer" as E2
    state "DNS block" as B
    state "Reviews 2 and 3" as R2
    [*] --> D
    D --> C1: Masquerading LaunchDaemon found
    C1 --> E1: Root backdoor terminated
    E1 --> R1: No residue confirmed
    R1 --> C2s: Unsigned Native Host and live C2 session found
    C2s --> E2: Extension quarantined from 4 profiles
    E2 --> B: C2 domain sink-holed in hosts
    B --> R2: Signatures, injection, scripts, logs reviewed
    R2 --> [*]

Table 3: Verification scope and results

Notably, the first remediation round was incomplete. The initial, timeline-driven analysis missed the browser-layer components, precisely because of the timestomping described in Section 4.6. Only the second round, which used a whole-disk sweep for unsigned Mach-O binaries, found the Native Host and from there the extension.

6. Discussion

6.1 Session Theft Defeats 2FA

This case shows the fundamental limit of 2FA once the endpoint is compromised. Changing the password after the takeover does not invalidate sessions the attacker already holds; access is only cut off by actively revoking all sessions from a clean device. We recommend:

• Service providers: bind sessions to device characteristics, detect anomalous session migration, and require re-authentication for high-risk actions.
• Users: on suspicion of compromise, sign out of all devices first, and only then change passwords.

6.2 Engineered Context in Social Engineering

The attacker engineered context at three levels: the messaging platform (Telegram), the meeting brand (the victim remembered Zoom, while the screenshot shows Teams), and the timing of the permission request (the moment of clicking “Join” in Google Meet). That the victim later misremembered the meeting brand suggests that branding details on a fake meeting page are hard for users to notice.

6.3 Detection Heuristics (RQ4)

All six rules can be implemented in osquery or an EDR, with an expected low false-positive rate. H5 and H6 deserve particular attention because they target the browser layer, which traditional EDR products often do not inspect in depth.

6.4 Attribution Assessment

Table 4: Comparison with public reporting

The overlap in tradecraft is strong, and we assess the link with medium confidence. Because we did not reverse-engineer the samples or correlate them with threat-intelligence platforms, this is not a formal attribution.

7. Limitations

1. Single case: the findings may not generalise to all attacks of this type.
2. No reverse engineering: cloudsync, .authds and the Native Host are packed binaries; only their behaviour and external characteristics were analysed.
3. Log retention: the macOS unified log and Chrome browsing history (about 90 days) no longer covered April, so the original lure URL and first-stage download could not be recovered.
4. Missing LaunchAgent payload: ~/Library/Identification/.verify no longer existed at investigation time, so its function could not be analysed.
5. Whole-disk sweep coverage: the sweep skipped files that exist only in iCloud and were not downloaded locally. Such files cannot run on the host, so their exclusion has limited bearing on the conclusions.
6. Attribution: as discussed in Section 6.4.

8. Conclusion

Through a 193-day macOS intrusion, this study shows how a modern fake-meeting attack obtains root within minutes and then extends its control into the browser during the dwell period. The main findings are:

• The attack relied on trust, not vulnerabilities: no zero-day was used; everything hinged on the user entering a password.
• Two control planes back each other up: the system-level backdoor and the browser spyware extension each talked to the C2 independently, so removing one layer was not enough.
• Session theft defeats 2FA: this is the most likely mechanism behind the messaging-account takeover.
• Timestamps can lie: the attacker forged the extension’s timestamps, and timeline-only forensics can miss critical components.

Future work could reverse-engineer the Native Host command protocol, turn the heuristics in Section 6.3 into publicly shareable detection rules, and test across multiple cases how common the “system layer plus browser layer” dual control plane really is.

References

[1] Kaspersky GReAT. BlueNoroff APT campaigns GhostCall and GhostHire. Securelist, Oct. 2025. https://securelist.com/bluenoroff-apt-campaigns-ghostcall-and-ghosthire/

[2] Kaspersky. “GhostCall and GhostHire: hunting for crypto assets.” Kaspersky Daily, Oct. 2025. https://www.kaspersky.com/blog/bluenoroff-ghostcall-ghosthire-lazarus/54681/

[3] The Hacker News. BlueNoroff deepfake Zoom scam (news coverage citing the Huntress incident analysis). Jun. 2025. https://thehackernews.com/2025/06/bluenoroff-deepfake-zoom-scam-hits.html

[4] BleepingComputer. North Korean hackers deepfake execs in Zoom call to spread Mac malware (news coverage). Jun. 2025. https://www.bleepingcomputer.com/news/security/north-korean-hackers-deepfake-execs-in-zoom-call-to-spread-mac-malware/

[5] Google. “Native messaging.” Chrome for Developers. https://developer.chrome.com/docs/extensions/mv3/nativeMessaging

[6] MITRE. “ATT&CK Enterprise Matrix.” https://attack.mitre.org/

Appendix A: Indicators of Compromise

Network

File hashes (SHA-256)

Host paths and identifiers

/Library/LaunchDaemons/com.safari.sync.service.plist
~/Library/LaunchAgents/com.apple.google.auth.plist
~/Library/CloudSync/cloudsync
~/Library/Identification/.verify
~/Library/Staging/
~/Library/Application Scripts/ammad.Mac-Password-Popup/
~/Library/Application Support/Authorization/auth.db
/Users/root/Library/Identification/
/Users/root/Library/Application Support/Authorization/auth.db
/Users/Shared/.authds
/Users/Shared/.apple.auth
/Users/Shared/.com.apple.better.env
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/google.chrome.diagnostics
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.google.chrome.diagnostics.json
Chrome extension ID: ppconlkbhfnachephglhgbhdgeapgjoj ("Google Doc Sheets Offline" v1.97.1)
Hard-coded extension token prefix: jfweibd234HFIDhfiwef…

Appendix B: MITRE ATT&CK Mapping