Companion Technical Notes - Episode 3: The Factory

The Fake Interview Episode 3 moves from the victims to the machinery behind the campaign.

Episode 1 established the central fact: the backend data was real. The campaign had exposed 857 compromised workstations across 90 countries, with 241,764 credential records. Episode 3 starts after that answer. It asks a different question:

What happens when the collection pipeline records the people running it?

This companion page supports the episode without turning the audio into a walkthrough.

No victim records, credentials, live infrastructure, raw access paths, hardcoded secrets, full operator identifiers, private endpoint mechanics, or reproducible access steps are published here.

Listen

Spotify:
https://open.spotify.com/episode/4fCxS9Q4n82tf8fRgsMRCZ?si=MSmeQ0azRqWX6Ebst1GKnQ

RSS feed:
https://podcast.redasgard.com/@FakeInterview/feed.xml

Related written investigation

This episode draws from Red Asgard’s broader Hunting Lazarus investigation, especially the material following the initial victim-data discovery.

Public background:

Hunting Lazarus Part III: The Infrastructure That Was Too Perfect - infrastructure patterning, OtterCookie, standardized C2 surfaces, and the earlier uncertainty around whether the infrastructure was operational or staged.
Hunting Lazarus Part IV: Real Blood on the Wire - the victim-data discovery that established the campaign was operationally real.

Some findings discussed in this episode are based on later investigative material that may require redaction, notification, law-enforcement coordination, or publication review before being released in full.

What Episode 3 covers

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.

The episode is not a malware teardown and not a guide to accessing adversary infrastructure. It is a public-safe narrative reconstruction of how an industrialized credential-theft operation recorded parts of itself.

Why the episode is called “The Factory”

A factory repeats a process.

This campaign had inputs:

developer profiles;
fake recruiter and business identities;
fake companies;
outreach scripts;
malicious repositories;
hosting accounts;
command-and-control services.

It had stages:

select or identify a target;
approach the target through a professional channel;
move the target into a technical interview frame;
deliver code that must run locally;
collect what the workstation holds;
sort, retrieve, and act on the result.

It had outputs:

credentials;
browser sessions;
source-code access;
wallet material;
local files;
cloud and developer-platform exposure;
organizational blast radius beyond the individual developer.

Episode 3 focuses on the additional output that changed this phase of the investigation: records from machines connected to the operation itself.

The factory did not only process targets. It processed parts of its own floor.

The self-infection pattern

The episode describes a self-infection pattern: machines associated with the operation appeared in the same broader collection environment as machines belonging to targets.

Public-safe interpretation:

The collection system behaved indiscriminately.
It collected from machines that ran or touched the toolchain.
Some of those machines were not external victims.
They exposed workflow, not just credentials.

The operational lesson is simple:

A collection pipeline that reads everything can also read the people who built, tested, or operated it.

This is not presented as a single isolated mistake. It is a design consequence. The toolchain did what it was built to do: collect.

What the operator-side records revealed

The episode summarizes several categories of operator-side exposure without publishing private identifiers or reproducible access details.

1. Social-engineering workflow

Operator-side records showed the campaign as work:

outreach templates;
lure scripts;
fake professional profiles;
persona materials;
account credentials for fake companies;
targeting queues;
communications between people performing different roles.

That matters because fake interviews do not scale on malware alone. They require logistics: accounts, scripts, identities, scheduling, payments, and people maintaining the illusion long enough for the technical task to arrive.

2. Persona infrastructure

The campaign used professional identities as infrastructure.

A target does not receive a message from “the C2.” A target receives a message from a person who appears to have a role, a photo, a company, and a reason to be making contact.

The operator-side material showed that those identities were assembled, maintained, and reused.

3. Testing and staging behavior

Some records showed the overlap between campaign operation and testing. That is important because testing environments can become part of production evidence when operators reuse machines, accounts, or tooling.

The episode does not publish access mechanics or exact paths. The public point is enough:

The same collection logic that worked against targets also captured operator-side activity when operators ran or touched the toolchain too closely.

4. Provisioning and supply-chain exposure

Operator-side machines can reveal more than individual victim harm. They can expose how the campaign stays online:

hosting relationships;
account procurement;
domain and service management;
internal dashboards;
infrastructure maintenance behavior.

A victim machine can show who was hurt. An operator machine can show how harm was organized.

OtterCookie’s role in this episode

OtterCookie is not treated as the central mystery of Episode 3. It is treated as an instrument of workstation occupation.

At a high level, OtterCookie included capabilities consistent with staying close to a compromised workstation:

system-wide keylogging;
repeated screenshot capture;
multi-monitor awareness;
persistence mechanisms;
virtual-machine awareness;
broader cryptocurrency wallet-extension targeting than earlier tooling.

The important defender point is not that OtterCookie was exotic. The important point is that it was shaped around the kind of machine the campaign wanted: a real developer workstation with browsers, terminals, local projects, cloud sessions, wallets, and saved credentials.

Episode shorthand:

BeaverTail looked like access malware. OtterCookie looked like occupation malware.

Attribution note

The series uses disciplined attribution language.

Preferred phrasing:

DPRK-linked;
Lazarus-attributed;
consistent with Contagious Interview tradecraft;
visible hands on keyboards;
distributed operators, contractors, or facilitators;
technical evidence does not necessarily expose every command layer.

Why this matters:

A campaign can be consistent with Lazarus-attributed tooling and targeting while visible operators, contractors, infrastructure maintainers, or facilitators appear in other countries. Public reporting should not flatten that into an unsupported claim about every person involved.

The audio therefore distinguishes between:

attribution of the campaign and tradecraft;
the visible operator layer;
infrastructure operators or tool builders;
unresolved questions that belong to law enforcement, partner notification, or future reporting.

Defensive guidance for developers

Treat unknown interview repositories as hostile until proven otherwise.

Before running code from a recruiter, freelance client, interview panel, or unfamiliar company:

use a disposable virtual machine or isolated laptop;
do not use your daily browser profile;
do not mount SSH keys;
do not expose cloud credentials;
do not expose package publishing tokens;
do not expose wallet extensions;
do not unlock a password manager inside the review environment;
inspect package scripts before installing dependencies;
inspect editor configuration, especially VSCode or Cursor workspace files;
inspect devcontainer, shell, and setup scripts;
require the interviewer to demo their own project on their own machine first;
treat voice-only calls, camera failures, urgency, and platform switching as risk signals.

The safest assumption is simple:

Dependency installation is code execution. Workspace trust is code execution. A coding test can be an execution environment.

Defensive guidance for teams

Organizations should not leave safe interview-code review to individual improvisation.

Recommended controls:

provide isolated review environments for external code;
make disposable review environments the default for hiring, contracting, and third-party code evaluation;
restrict secrets from review environments by default;
use short-lived scoped credentials;
limit developer tokens and package-publishing permissions;
monitor child processes from editors, package managers, build tools, Node, Python, and shell scripts;
alert on newly cloned repositories making unexpected outbound network connections;
monitor for credential-store access from unusual development contexts;
monitor for unexpected persistence created during project setup;
keep separate browser profiles for external-code review;
maintain a response checklist for suspected coding-test compromise.

The goal is not to make every engineer paranoid. The goal is to move the trust boundary before unfamiliar code reaches a privileged workstation.

Incident response checklist

If you suspect you ran a malicious interview repository or coding test:

Disconnect the machine from the network.
Do not rotate credentials from the suspected machine.
Use a clean device to revoke and rotate credentials.
Prioritize SSH keys, GitHub tokens, package registry tokens, cloud keys, wallet material, password-manager sessions, browser sessions, and CI/CD secrets.
Preserve the machine if possible; do not wipe before collecting evidence.
Export relevant logs from endpoint security, EDR, network telemetry, package manager history, shell history, and editor workspace history.
Review browser profiles for saved credentials and active sessions.
Review package scripts, workspace configuration, and any downloaded payloads.
Check for persistence created during or shortly after repository execution.
Notify affected organizations if work credentials, client repositories, cloud access, or payment systems may have been exposed.

Credential rotation without removing persistence is not enough. If remote access, scheduled execution, startup items, or malicious editor tasks remain, the attacker may regain access after credentials are changed.

What we are not disclosing

This companion page intentionally omits:

victim names;
victim companies;
unnotified affected organizations;
operator full names and private identifiers;
credentials, tokens, wallet secrets, hashes, or hardcoded values;
live infrastructure addresses not already published in vetted reports;
access paths into adversary systems;
exact endpoint mechanics;
raw request paths that enable data retrieval;
reproduction steps for accessing stolen data;
law-enforcement-sensitive details;
partner-only indicators that could harm notification or remediation.

The story does not need to teach abuse to be true.

Public-safe detection ideas

These are high-level hunting directions, not complete detection rules.

Workstation behavior

Look for:

unexpected Node, Python, or shell processes launched from interview repositories;
package installation spawning network tools, archive tools, credential access, or persistence mechanisms;
new scheduled tasks, launch agents, login items, or startup entries created after opening an unfamiliar project;
screenshot or keyboard-monitoring libraries appearing in code that should not need them;
unusual access to browser profile directories;
unexpected reads of wallet-extension storage;
outbound connections soon after npm install, npm start, pnpm install, yarn, pip install, or editor workspace trust events.

Identity and recruitment layer

Look for:

recruiter personas reusing language across platforms;
newly created or low-history company domains;
private repositories created shortly before an interview;
refusal to demonstrate the project on the interviewer’s machine;
platform switching during recruitment;
voice-only or text-only calls explained by technical issues;
pressure to run code live while screen-sharing.

Infrastructure layer

Look for patterns, not only indicators:

repeated service layouts across unrelated-looking servers;
unusual clustering of developer-targeting infrastructure;
co-residence of multiple malware-family services on shared hosts;
hosting, domain, and account procurement patterns around fake companies.

Published IOCs should live in vetted advisories or written reports, not in this podcast companion unless they have been reviewed for victim-safety and operational-risk concerns.

Episode continuity

Episode 1: Real Blood on the Wire
The victim data was real. The honeypot theory died. The developer workstation became the blast-radius story.

Episode 2: The Repository That Called Home
The fake company and malicious repository showed how professional trust became code execution.

Episode 3: The Factory
The campaign’s own collection system recorded operator-side machines, exposing the workflow behind the fake interviews.

Episode 4: Eleven Hours
The next episode focuses on the forensic view of a single operator environment and what remained on disk.

Headphones note

For the best experience, listen with headphones. This episode uses subtle stereo placement on a few short lines.

The effect is intentionally limited. It is not binaural audio, not 8D audio, and not a gimmick. It marks the inversion at the center of the episode: the records were not only victims.

Suggested short episode description

Episode 3 moves inside the campaign. After Episode 1 established that the victim data was real, this episode asks what happened when the collection pipeline recorded machines connected to the people running the operation. The result was not just another malware finding. It was a view of the factory: fake personas, targeting workflow, operator workstations, command structure, and the mistake of building a collection system that did not know who it was collecting from.