One Fake Video Call, 193 Days Inside: A macOS Backdoor, a Fake Google Docs Extension, and a Stolen Telegram Account

The short version:

• One meeting invite put a root backdoor on a Mac in about four minutes. No zero-day was involved. All it took was a fake Teams waiting page and a fake system password prompt.
• The backdoor ran quietly for 193 days. On day 31 it installed a spyware Chrome extension disguised as “Google Docs Offline” that sent every website cookie out every 30 seconds.
• Telegram was taken over even with two-step verification (2FA) on, because the attacker stole an already logged-in session, not the password.
• If you think you were hit: from a separate clean device, log out every session first, then change passwords, then reinstall. The order matters.

This post is based on a real forensic investigation. The victim’s hostname, username and personal software inventory have been removed, and all times are UTC. It is written for a general audience; the full forensic detail is in the incident report and research paper linked at the end.

Last year I wrote about Telegram session hijacking, where a fake Zoom installer stole Telegram Desktop’s session. This case is the upgraded version of the same playbook: instead of stealing once, the attacker moved in and stayed.

How it started

On 24 April 2026, the victim received a business-style video meeting invite on Telegram. The link opened a fake Microsoft Teams waiting page saying “Someone in the meeting should let you in soon.” The victim remembered it as Zoom, until a screenshot taken at the time turned up during the investigation and showed Teams. A convincing fake page makes even the brand hard to recall.

The page then claimed the audio component or SDK needed an update. The victim ran the download, and a password prompt that looked like it came from macOS appeared. Typing the password handed the attacker administrator rights.

File creation times reconstruct those four minutes:

The password prompt appears before any root-owned file is written, which fits the model of “run sudo with the password the user just typed.” The only thing the whole chain needed was for the victim to enter a password once.

sequenceDiagram
    autonumber
    actor A as Attacker
    actor U as Victim
    participant W as Fake meeting page
    participant OS as macOS
    participant BD as cloudsync backdoor
    participant C2 as C2 check02id.com

    A->>U: Meeting invite on Telegram
    U->>W: Opens link, lands on fake Teams waiting page
    W->>U: "Audio / SDK update required"
    U->>OS: Runs the download
    OS->>U: Fake system password prompt
    U->>OS: Enters login password
    OS->>BD: Writes backdoor and launch item as root
    loop Every 60 seconds
        BD->>C2: Beacon (TCP 5202)
    end

What the attacker did over 193 days

Once the backdoor was in place, the attacker expanded in stages:

Look at the names: com.safari.sync.service, com.apple.google.auth, .apple.auth. Every one borrows Apple, Safari or Google branding, so a normal user scrolling through login items would assume they belong to the system.

Two layers of control: system backdoor plus browser spyware

The most notable design choice is that the attacker held two independent control channels:

• System layer (cloudsync): root, starts at boot, can read and write anything on the machine. But logged-in browser sessions are encrypted and not easy to use from here.
• Browser layer (the fake extension): lives inside Chrome, with direct access to cookies, page content and every keystroke.

Each layer talks to the C2 on its own, so removing one leaves the other alive. That is exactly what happened: after the first cleanup removed cloudsync, the extension kept talking to the C2 until a second, machine-wide scan for unsigned binaries found it.

What the fake “Google Docs Offline” extension can do

The extension calls itself Google Doc Sheets Offline (v1.97.1) with ID ppconlkbhfnachephglhgbhdgeapgjoj. The real Google Docs Offline has ID ghbmnnjooekpmoecnnnilnnbdlolhkhi and is only installed from the Chrome Web Store.

It requests <all_urls> plus cookies, history, tabs, scripting, desktopCapture and nativeMessaging. Its source code shows:

Two combinations are especially nasty:

1. Wipe cookies plus keylogging: kill your session on a site, then capture the new password you type when you log back in.
2. JavaScript injection: run scripts on exchange or wallet sites, for example to silently swap a withdrawal address.

It also hooks Google Meet’s “Join now” button and asks for screen recording permission at the moment you join a call, when the request looks completely reasonable.

Why the browser sandbox did not help

Chrome’s Native Messaging exists so that software like password managers can talk to a local program¹. When an attacker controls both the extension and the local program, the extension can effectively run any command on the machine and the sandbox no longer matters. Here the Native Host was called google.chrome.diagnostics: another Google-branded name on an unsigned binary.

The attacker also faked timestamps

Some files in the extension folder show a creation date of 2025-10-16, and Chrome recorded an install date of 2025-08-13. Both are earlier than the real intrusion. Taken at face value, they suggest the extension had nothing to do with this incident.

The real install date came from one file: the extension’s data.js contains the victim’s username and hostname, so it could only have been created on the victim’s machine, and its creation time is 2026-05-25. The later whole-disk sweep also found a copy of the extension’s background.js in Chrome’s Service Worker cache, created five seconds after data.js, which is exactly when the extension first loaded and ran. Timeline-only forensics can miss key components.

Why Telegram was taken over despite 2FA

This is the question most people ask. The answer: 2FA protects the act of logging in. It does not protect a session that is already logged in.

After you log in, a site stores a login credential in your browser’s cookies or localStorage. Every time you return, the browser presents it and the site knows it is you, without asking for a password or 2FA again.

Web apps like Telegram Web keep their login tokens in localStorage. This extension uploaded localStorage on every tab switch, so the attacker could load it into their own browser and simply be you, with no password and no 2FA prompt. MITRE ATT&CK calls this T1539 (Steal Web Session Cookie) plus T1550.004 (Use Web Session Cookie)².

That is also why changing your password afterwards does not help: the session the attacker holds does not expire because you changed the password. You have to actively terminate all other sessions.

The Telegram account was taken over while the extension was active. Session or localStorage theft is the explanation best supported by the evidence, but because the relevant logs had aged out, it cannot be pinned to a specific upload.

What about BlueNoroff?

Public reporting describes the North Korea-linked BlueNoroff group (generally considered the Lazarus sub-group focused on financial and crypto theft) using fake video meetings against macOS users for years:

• Kaspersky’s October 2025 research on GhostCall and GhostHire says GhostCall mainly targets macOS, approaches victims via Telegram, and uses fake Zoom and Teams clients to deploy stealers³⁴.
• In a June 2025 incident handled by Huntress, attackers used deepfaked participants in a meeting, then claimed the victim’s microphone was broken and had them run an AppleScript named zoom_sdk_support.scpt⁵⁶.

This case matches on the Telegram invite, the fake Zoom or Teams page, the fake system password prompt, the Apple and Google naming, and the focus on crypto holders. However, the samples were not reverse engineered or compared against threat intelligence platforms, so this is a technique match with medium confidence, not a formal attribution.

The “system backdoor plus extension plus Native Host” combination was not described in detail in any of the public material we reviewed.

How to check your own Mac

These commands only read; they change nothing. Paste them into Terminal.

1. Look for the known files from this case

ls -la /Library/LaunchDaemons/com.safari.sync.service.plist \
  ~/Library/LaunchAgents/com.apple.google.auth.plist \
  ~/Library/CloudSync \
  ~/Library/Identification \
  ~/Library/Staging \
  "$HOME/Library/Application Scripts/ammad.Mac-Password-Popup" \
  /Users/Shared/.authds /Users/Shared/.apple.auth /Users/Shared/.com.apple.better.env \
  /Users/root \
  2>/dev/null

No output means none of these files exist, which is good news.

A word on /Users/root: on macOS the root home directory is /var/root, so a normal Mac has no /Users/root. In this case the backdoor, running as root, created one there with a copy of the same state files it kept in the victim’s home (Identification/ and Authorization/auth.db).

2. Check Chrome extensions and Native Hosts

# The fake extension ID from this case
find "$HOME/Library/Application Support/Google/Chrome" -maxdepth 3 -type d \
  -name ppconlkbhfnachephglhgbhdgeapgjoj 2>/dev/null

# List every registered Native Messaging Host
ls -la "$HOME/Library/Application Support/Google/Chrome/NativeMessagingHosts/" 2>/dev/null

Then open chrome://extensions in every Chrome profile and look for:

• Extensions with Google-looking names whose ID is not the official one.
• Extensions not installed from the Web Store (the details page shows the source).
• Extensions that can “read and change all your data on all websites”, and whether you really need that.

Each .json under NativeMessagingHosts points to a binary. Run codesign -dv <path> on it to see whether it is properly signed. Something called google.chrome.diagnostics without a Google signature is a red flag.

3. Look for C2 connections

lsof -nP -i | grep -E ':(5202|5078|8443)\b'
grep check02id /etc/hosts

4. General warning signs

These rules still apply if the attacker renames everything:

Also look out for any folder under /Users/ that matches no account on the machine, such as /Users/root.

To list every launch item, run sudo sfltool dumpbtm, or go through System Settings → General → Login Items & Extensions.

If you were compromised

Order matters: cut off the attacker’s sessions first, then clean the machine. Any new password typed on an infected Mac will be captured too.

Immediately (within 24 hours, from a separate clean device)

1. Telegram: Settings → Devices → “Terminate all other sessions”; set or change the two-step verification password and check the login email.
2. Google account: Security → sign out of all other devices, change the password, move to passkeys or a hardware security key.
3. Crypto: create a wallet with a brand-new seed phrase on a clean device and move everything; revoke token approvals on the old addresses.
4. Exchanges, banks, email, cloud services: log out all sessions, then change passwords, and check API keys and withdrawal whitelists.
5. Change your macOS login password and Apple Account password.

Cleaning the infected Mac

In this case the steps were:

1. Unload the launch items: sudo launchctl bootout system/com.safari.sync.service and launchctl bootout gui/$(id -u)/com.apple.google.auth.
2. Kill the cloudsync and .authds processes.
3. Before deleting anything, record each file’s SHA-256 and archive the samples encrypted for law enforcement or researchers.
4. Delete every file and directory listed in step 1 of the self-check.
5. Quit Chrome completely, remove the fake extension and Native Host from all 4 profiles, then confirm in chrome://extensions.
6. Add 0.0.0.0 check02id.com to /etc/hosts to block the C2.

Before deleting /Users/root, check that it holds only the files from this case and nothing else.

But be honest with yourself: manual cleanup only removes what you already know about. This case proves it: the first pass missed the entire browser layer, and two rounds of manual review missed /Users/root, which only turned up when a sweep of about 610,000 files for the IoC strings was run. So:

Within a week

1. Back up documents only (not applications, not ~/Library), then erase the disk and reinstall macOS.
2. On the fresh install, do not sync old extensions into Chrome; reinstall what you need from the Web Store.
3. Report to local law enforcement and your national CERT, with the IoCs and samples.

Staying safe

• Join meetings only through the official app. Any meeting page asking you to “update the SDK”, “install an audio plugin” or “fix your microphone” is an attack. Zoom, Teams and Google Meet never need extra installs to join a call.
• Never type into a system password prompt you did not trigger yourself. Cancel first, then work out who asked.
• Keep crypto in a hardware wallet and never type a seed phrase into a computer.
• Check chrome://extensions now and then, especially for official-looking extensions you do not remember installing.
• If you suspect a compromise, log out of all devices first, then change passwords.

Indicators of Compromise (IoC)

For security teams and EDR rules.

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…

Key MITRE ATT&CK mappings

Further reading: the full reports

The full forensic data, timeline, UML diagrams and verification scope are in two de-identified documents (switch to Traditional Chinese from the footer):

• Incident Report
• Research Paper

The samples are live malware and are not publicly distributed. Security researchers and law enforcement can request them privately.

References