A fake interview does not become dangerous only when malware runs.

In Episode 8 of The Fake Interview, we step back from the repository, the workstation, and the Google Mirror to look at the behavioral layer that made the campaign work: cooperation.

The recruiter message, the plausible company, the broken call, the shared repository, the real browser, the login prompt, the screen share — none of these has to look malicious by itself. Together, they move a developer from suspicion into trust.

This episode asks when the compromise really begins, why developer identity is an access path, and why suspicious interviews should never touch the same environment where real credentials, source-control sessions, cloud consoles, wallets, and work accounts already live.

No victim data, credentials, live endpoints, reusable access steps, or operational exploit details are included.

Last episode, The Fake Interview followed OtterCookie inside the developer workstation. Episode 7 moves one step outward.

The Google Mirror is about a different layer of the same operation: not the repository, not the payload, not the screenshot loop, but the trusted identity path around the machine. The investigation found infrastructure positioned to proxy Google services, with behavior specific enough to separate it from ordinary command-and-control infrastructure and from a generic phishing page.

This episode is careful about what the evidence does and does not support. It does not claim Google was compromised. It does not claim a certificate authority was compromised. It does not claim the delivery path into the mirror was confirmed.

What it does show is more precise: the campaign had infrastructure for the identity layer around developer compromise.

A Google account is not one account. For a developer, it can be mail, calendar, documents, OAuth, password recovery, browser sync, shared drives, cloud access, source-control recovery, and the map of where work goes next.

The repository asked the developer to run code.
OtterCookie waited for the developer to keep working.
The mirror waited for the developer to trust the browser.

This was The Fake Interview.

Every five seconds, OtterCookie took another look at the workstation.

Episode 06 of The Fake Interview examines OtterCookie, a second-stage malware family associated with DPRK-linked Contagious Interview activity. Where earlier stages helped explain how fake technical interviews moved developers from conversation to code execution, OtterCookie shows what the operation wanted after the code was already running.

This episode focuses on the real target: the developer workstation.

Not an empty sandbox. Not a clean analysis VM. The real machine, with browser history, terminal residue, clipboard activity, authenticated sessions, wallets, cloud consoles, source-control access, and work still in motion.

OtterCookie matters because it moved the compromise from static theft toward live observation. A credential dump captures one moment. A watcher can wait for the work to happen.

In this episode:

OtterCookie’s role in the broader fake-interview pipeline
Why screenshots and keyboard capture mean something different on real workstations
Why clean sandboxes can miss the operational value of the implant
How wallet targeting changes the personal stakes for Web3 developers
Why “use a VM” is right, but incomplete
Why the developer became the perimeter

This episode avoids live indicators, exploit walkthroughs, victim records, and reusable operational detail. The goal is to explain the campaign safely: what changed, why it mattered, and what developers and defenders should understand.

The real workstation was the target.

The Fake Interview is a narrative technical podcast from Red Asgard about DPRK-linked fake interview campaigns targeting developers.

Episode 05 focuses on how infrastructure can be misclassified during an active investigation. The server discussed here was initially understood through its FTP exfiltration role. Later evidence tied the same host to additional campaign-linked services, including OtterCookie-related collection behavior.

A live adversary server. Two password changes. Eleven hours.

Episode 04 follows the forensic window where researchers preserved a contested Windows machine used in a Lazarus-attributed fake-interview campaign, uncovering the operator workbench behind the lures: campaign archives, fake-company material, targeting pipelines, wallet artifacts, browser traces, and signs of AI-assisted workflow.

Episode 3 focuses on the operator side of the campaign:

- why the collection pipeline did not distinguish between targets and operators;

- how operator workstations appeared in material collected by the campaign;

- how those workstations exposed social-engineering workflow, persona infrastructure, testing behavior, provisioning activity, and command structure;

- why OtterCookie should be understood as a post-access occupation tool;

- what defenders can learn from the factory model without needing access to sensitive data.

A fake coding interview. A malicious repository. A real developer workstation.

The Fake Interview is a Red Asgard narrative investigation into a DPRK-linked, Lazarus-attributed campaign targeting developers, Web3 engineers, and freelance technologists through job offers, coding tests, and trust.

Start with Episode 1: Real Blood on the Wire.

Episode 2 of The Fake Interview follows the first repository: a fake software project delivered through a job interview that behaved like real work until the moment it called home.

We examine how a malicious coding test abused normal developer behavior: opening a project, trusting a workspace, installing dependencies, running local code, and debugging what looked like a broken app.

This episode covers:

- DPRK-linked fake interview activity

- malicious GitHub / contractor repositories

- VSCode and Cursor workspace trust abuse

- run-on-folder-open execution

- Function.constructor abuse in JavaScript

- Vercel-hosted stage-one infrastructure

- payload delivery and command-and-control routing

- why developer machines are high-value targets

Companion notes:

https://podcast.redasgard.com/pages/companion-technical-notes-episode-02-the-repository-that-called-home