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.
The first episode of The Fake Interview begins with the moment the honeypot theory died. After earlier reporting raised the possibility that the infrastructure might be staged for researchers, the backend answered with something harder to dismiss: real developer machines, real credential records, real local development environments, and victims across dozens of countries. This episode follows how a fake job interview became an execution environment. A message. A call. A repository. A project that needed to run locally. From there, the campaign turned ordinary developer workflows into a credential-theft pipeline. In this episode: why localhost ports like 3000 and 5173 mattered how fake interviews target the normal habits of software work why developer laptops create organizational blast radius why the exposed records killed the honeypot theory what researchers owe victims once real credentials appear why the audio version avoids reusable access details This episode does not include victim records, credentials, campaign extraction steps, hardcoded secrets, or instructions for accessing adversary infrastructure. Companion notes and defensive guidance are available from Red Asgard.
Episode 02 – The Repository That Called Home The malware didn’t begin with code. It began with credibility. In this episode of The Fake Interview, valh4x goes back to the beginning of the Contagious Interview attack path: the fake company, the recruiter profile, the broken video call, the believable technical task, and the moment a normal-looking repository becomes an execution environment. The episode follows a known pattern of DPRK-linked fake-interview activity often tracked under the Contagious Interview umbrella. The goal is not to relitigate attribution in every paragraph, but to show how the technique works when the job market itself becomes the delivery mechanism. A company does not need to be real to be useful to an operator. It only needs to be plausible long enough for the victim to accept the next step: clone the repository, install the dependencies, run the app, share the screen. To a developer, that sounds like work. To the operator, it is the moment the victim moves from conversation to execution. Episode 02 explains how malicious repositories abuse normal developer workflows, why opening code is not always passive, why the real target is often the developer’s working environment, and how a repository that “calls home” stops being a one-off scam and becomes part of a campaign. The episode then follows the campaign’s infrastructure evolution: public dead drops, takedown pressure, and the shift to Polygon smart contracts as a blockchain-based payload delivery layer. From the victim’s point of view, they were running a crypto project. From the malware’s point of view, the blockchain was a mailbox. This episode is written for developers, security teams, founders, project managers, and anyone who has ever treated a coding test as just another step in the interview process. No live endpoints, reusable exploit steps, victim records, credentials, or operational access details are published in the audio. Key themes: fake companies and recruiter credibility LinkedIn as abused trust infrastructure coding interviews as execution environments malicious repositories and developer workflow abuse staged payload delivery dead-drop infrastructure Polygon smart contracts as malware delivery infrastructure developer workstation blast radius practical isolation guidance for interview code Hosted by valh4x. Stay skeptical, and don’t run strangers’ code on your real machine.
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 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 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.
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 pipelineWhy screenshots and keyboard capture mean something different on real workstationsWhy clean sandboxes can miss the operational value of the implantHow wallet targeting changes the personal stakes for Web3 developersWhy “use a VM” is right, but incompleteWhy the developer became the perimeterThis 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.
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.