The Google Mirror: Browser Trust as the Attack Surface

The Google Mirror: Browser Trust as the Attack Surface

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.

OtterCookie: The Malware That Watched the Developer

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.

the FTP Server: How One Boring Label Hid a Second Layer of the Campaign

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.

Eleven Hours: Inside the Lazarus Operator’s Disk After the Fake Interview Campaign

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.

The Factory: How a Lazarus-Attributed Credential Pipeline Collected Its Own Operators

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.