Hunting Lazarus Part VI: The Factory That Ate Its Workers ? Red Asgard Blog

The full investigation is consolidated in the Inside the Machine research article.

This is Part VI of the "Hunting Lazarus" series. The earlier installments documented the Contagious Interview campaign run by Lazarus Group – the DPRK-linked APT – which targets cryptocurrency and Web3 developers with fake job interviews, fabricated company identities, and malicious code repositories. Part V ended on the forensic acquisition of a single operator VPS. This installment moves outward from that machine to the broader victim database, the operators who appeared inside it, and the design failure that put them there.

How a global credential-theft pipeline consumed the operators who ran it.

The victim database held more than fourteen thousand check-in records – approximately twenty-five hundred unique machines – across thirty-six countries.

Five of them were not victims.

They were operator workstations.

The same exfiltration pipeline that harvested developer credentials, wallet material, browser sessions, source-repository tokens, and files from its intended targets had ingested the campaign's own staff. The supervisor's machine. A persona operator's machine. A test workstation. A provisioning workstation. A second operator machine whose infection persisted long enough to appear across multiple internal classifications.

The pipeline did not ask whether the machine it was reading belonged to a target or to the person running the targeting system. It read the machine and moved the data.

That design consequence changed this phase of the investigation. Until then, the campaign had looked like a large credential-theft operation aimed at developers, Web3 workers, and financial-sector employees. After the self-infections, it became something else: a collection system that documented not only the people it compromised, but also the people who operated it.

During the same period, search queries began appearing on an exposed code-search panel inside the operation's own infrastructure:

/password/
/SSH/
/token/

A fourth search term was a company name. It is not reproduced here.

The first three terms were generic security keywords. The fourth was not.

Investigators were reading those searches as they arrived. The code-search interface was indexed against the operator's own project directories. The C2 behind it was still live. The infrastructure had not been abandoned. Someone was searching through it while the investigation was reading it.

Then a port on the exposed surface went dark.

The operator had noticed something.

Both sides were now working the same infrastructure.

The Factory

A developer who applied for a job that did not exist. A Web3 engineer who agreed to a call with a company that had no real product. A computer science graduate student who received an interview invitation and a coding test.

Each record in the database represented a specific person whose professional identity, credentials, and in some cases financial assets were taken without their knowledge. This article describes them in aggregate because individual notification is ongoing, and further specificity would compound the harm.

The records were organized into multiple internal teams. The classification system was built into the C2's routing layer: each infected machine reported not only its contents, but also a designation that placed it into a targeting category. The category names were not visible in the public-facing panel. The structure was.

That structure mattered. It showed that the campaign was not merely accumulating victims. It was sorting them. Different portions of the victim pool were being handled as separate lanes inside a larger operation.

The largest concentrations fell into three sectors: software developers, Web3 and cryptocurrency professionals, and employees of financial institutions. The sector breakdown was not incidental. These were the workers most likely to hold the credentials the campaign wanted: GitHub tokens, package-registry access, cloud keys, wallet material, browser sessions, and internal application credentials.

The campaign operated through fake company personas. The personas had LinkedIn pages, email domains, Calendly links. They looked institutional. They sounded professional. They all did the same thing: make a developer run code.

The infrastructure supporting the campaign used a dead-drop communication layer. Extensive Pastebin dead-drop infrastructure appeared in the panel's records as fallback channels. Each account was a redundant mailbox where malware could check for updated instructions without connecting directly to the main C2. Provisioning at that scale is not improvisation. It is preparation for disruption.

The infection chain followed the same logic. A JavaScript first stage ran through the fake coding-test workflow. An exfiltration stage harvested files, credentials, and wallet data. A persistence and communications component kept the machine connected and checked for updated instructions. The details varied by build and campaign wave, but the operating principle did not: run code on the developer's machine, collect what the machine holds, transmit it through the same pipeline.

Inside the recovered Python payload source, there was one line that did not belong to the execution path:

#hel p me

It appeared in two distinct Python builds recovered from different parts of the corpus: one from the FTP exfiltration server, another from later payload material and victim-machine copies. The builds differed by four lines. A subprocess call had been reformatted in the later build, with output suppression added. The comment survived unchanged.

Same function: execute_payload_with_uac().

Same position: after the successful return path.

Same effect: none.

It was dead code. It did not change execution. It did not beacon. It did not signal at runtime. It was visible only to someone reading the recovered source after deobfuscation.

The investigation cannot determine who wrote it, when it was inserted, or what it meant. It does not prove coercion. It does not prove authorship. It proves something narrower and stranger: across two separate Python builds, someone left the same malformed plea in the same unreachable place.

Earlier drafts described this as a JavaScript Watchdog comment. That was wrong. No JavaScript source recovered in this corpus contains it. The confirmed artifact is Python.

That was the factory.

What the investigation found next was what happened when the factory turned inward.

The Workers

The exfiltration pipeline was built around a simple design principle: collect everything from every machine the toolchain touched.

There was no evaluation layer. No identity check. No rule that said: stop if this machine belongs to an operator. No filter that distinguished production victims from testing workstations. When operators tested builds locally, ran tooling from machines they used for other work, or connected from systems previously used in development, the pipeline processed those machines the same way it processed the laptops of developers who had run a fake interview repository.

The operators' credentials, filesystem paths, browser sessions, wallet material, dashboard access, and infrastructure accounts moved through the same channel as the data taken from the campaign's intended targets.

Five machines appeared in the victim directories that were not victims.

They were operator workstations.

The supervisor's machine

The first one ran the campaign.

It contained outreach templates, lure scripts, persona material, and structured targeting data. It held artifacts tied to fake professional identities used to approach developers on platforms where unsolicited technical work is normal enough to lower suspicion. It also contained communications showing tasking relationships between a supervisor and subordinates.

This was not merely a compromised workstation. It was the machine that described how the campaign found people.

The supervisor's machine had been catalogued by the collection system he helped operate. The workstation that held the target list appeared in the same infrastructure as the machines of the people on that list.

The long-running operator infection

Sixty-eight days.

That is how long a single operator infection persisted before the campaign's own collection system stopped reporting it as new. The machine appeared across multiple internal classifications – the widest cross-team footprint of any self-infected operator system observed in this phase.

It contained campaign material, access credentials, and routing resources used by the operation. Its network indicators pointed to a consumer connection in the Russian Far East rather than to a hardened operator enclave.

Sixty-eight days is the important fact.

An operator's workstation remained inside the same collection pipeline as the victims, across multiple internal lanes, for more than two months. If the campaign had a process for identifying operator self-infection, it failed. If it had a process for cleaning it, the investigation did not observe it. The system kept collecting.

The persona operator

More than thirty fabricated LinkedIn profile photographs.

Associated identity material. Some images appeared AI-generated. Others appeared taken from other sources and attached to professional identities that did not correspond to living people. These were the faces behind the interview invitations: project strategists, business development contacts, recruiters, and supposed founders whose accounts existed to make the approach look normal.

The same machine held credentials for an internal operator dashboard. That matters because it connects the persona factory to the management layer. The fabricated identity was not just a profile. It was part of an operational workflow.

The self-infection exposed what the victim database alone could not show: how many personas were maintained, how those personas were distributed across platforms, and how the operator authenticated to the campaign's own management infrastructure.

The test workstation

Not a residential machine. A server.

Hosted in a datacenter and present in a classification the investigation assessed as operator-controlled testing rather than a victim pool. Its presence showed that self-infection was not limited to careless operators running malware from personal laptops. The testing environment itself fed the same exfiltration path. The operator ran the toolchain in a context he believed was separated from victim collection. The pipeline made no such distinction.

There was no clean wall between test and production. At least from the perspective of the exfiltration system, both were just machines that had run the code.

The provisioning workstation

Hosting accounts. Cloud-provider access. Domain-registration resources. Development-platform credentials. Account material used to bring servers online and keep them operating.

The fifth machine exposed the campaign's supply chain.

This was not merely one person's compromised workstation. It was the administrative surface behind the campaign's infrastructure. The machine showed which providers were being used, which accounts controlled provisioning, and which credentials authenticated to those services. The workstation that helped administer the campaign's infrastructure had itself been administered by the campaign's collection system.

What Self-Infection Proved

The self-infection pattern was not a vulnerability the investigation created. It was a design consequence.

The collection tooling was built to collect without evaluating. Applied to victim machines, that design maximized theft. Applied to operator machines, it created exposure. The pipeline did not stop at an organizational boundary because the software had no concept of one.

What it collected from intended targets was harmful: credentials, wallets, browser sessions, source-code access, personal files.

What it collected from operators was different. It exposed the campaign itself.

The operators' machines held targeting lists, lure scripts, persona infrastructure, dashboard credentials, provisioning accounts, payment flows, and internal communications. The victim database showed scale. The operator machines showed organization.

The technical artifacts had implied a staffed operation. The self-infections documented one.

The Command Chain

The supervisor's machine contained a communications export with more than thirty chats. The visible hierarchy was not inferred from timing patterns or infrastructure reuse. It was present in the communications.

A supervisor issued instructions. A mid-level operator relayed them. Subordinates executed. One operator managed fake-profile procurement. Others handled outreach, persona maintenance, account purchases, and operational expenses.

Payment moved through the same channels as tasking. Stolen payment-card data was used for account purchases. Payment-service accounts were shared for operational costs. Cryptocurrency wallets were designated for proceeds.

The record established what the infrastructure had only suggested: the campaign was not run by a lone operator with a few scripts. It was a staffed operation with roles, delegation, accountability relationships, and a payment architecture.

The geography complicated attribution.

Session data and operator artifacts placed visible hands on keyboards across Eastern Europe, Russia, the South Caucasus, and European hosting environments. The technical record recovered in this investigation did not place any operator in North Korea.

That does not clear the campaign of Lazarus attribution. It narrows what the evidence actually shows.

The tooling, tradecraft, targeting, and campaign pattern remain consistent with DPRK-linked Contagious Interview operations. The visible operators, however, were geographically distributed and not located in North Korea in the recovered records. Whether those operators knew who controlled the campaign above them, whether they were contractors, affiliates, coerced participants, criminal collaborators, or something else, is not resolved by the technical record.

The distinction matters. Attribution is not a single field in a database. It is a layered claim: infrastructure, tooling, tasking, tradecraft, operator identity, command authority, and beneficiary. This investigation can document some of those layers with high confidence. It cannot honestly collapse all of them into one sentence.

The Target List

The supervisor's machine held the same prospecting database described in Part 5.

The profiles were not random. They described software developers, blockchain engineers, and Web3 professionals, organized by geography and targeting status. The file was the campaign's prospecting database: the population the operation intended to work through before those people appeared in the victim database.

That matters because it separates this campaign from opportunistic malware distribution.

The fake interview was not just a lure sent into the world to see who clicked. The target list showed selection. Developers were identified, sorted, approached, and moved through a social-engineering pipeline. At least one prospective target had been evaluated by on-chain holdings before contact. The approach followed the money, but it reached through professional identity.

The campaign did not need to compromise a cryptocurrency company directly if it could compromise the developers, contractors, and freelancers whose machines held the keys.

That is the core lesson of Contagious Interview. The perimeter was not the company firewall. It was the developer's laptop.

The Tool Builder

A sixth identity emerged through a different path.

Not through self-infection. Not through the communications chain. Through build artifacts.

A phishing relay management panel carried a software-company name in its HTML footer. The panel was part of the operation's credential-interception infrastructure. The footer was not hidden, stripped, or obfuscated. It sat inside the deployed interface like a developer credit left behind in a normal web application.

Server logs connected that company to a specific developer environment. Filesystem paths in deployment errors pointed to macOS development directories. An earlier build of the same application showed a related project path. Across the footer, logs, and recovered build history, the investigation associated the tool with a developer tied to a software development firm in the operator's region.

The distinction matters.

The operators ran the campaign. They sent the interview invitations, maintained fake personas, handled victim data, and managed the infrastructure. The tool builder appears to have built one of the platforms they used.

Whether he knew how the platform was being used, whether he was a willing participant, whether he was a contractor building what he was asked to build, or whether his relationship to the Lazarus-affiliated infrastructure was intermediated through parties not visible in the record, are questions the technical evidence raises but does not answer.

The evidence supports a narrower statement: the tool was built in a real development environment, carried a company mark, and was deployed into infrastructure used by the campaign.

The fourth search term in the cold open was tied to that company. During the same period investigators were reading the infrastructure, an operator was searching for the company's traces in his own project directories.

Whether that search was damage assessment, compartmentalization review, or something else, the record does not establish. The search happened. It was observed. The company name in the footer was the same string the operator searched while investigators watched.

The Reach

The self-infections explained the campaign from the inside.

The victim records showed what the campaign reached from the outside.

Most recovered credentials represented individual access: a developer's GitHub token, a registry credential, a cloud login, a browser session, a wallet file. One finding showed a different kind of blast radius.

Among the credentials recovered from the exfiltration infrastructure was repository access associated with a sovereign financial institution. The access reached private source-code repositories related to national payment infrastructure.

The institution was not necessarily selected as a target. The developer was.

That is the point.

A fake interview compromise does not need to know which institutions depend on a developer's machine. The malware collects what the machine holds. If the machine holds personal credentials, those are collected. If it holds wallet material, that is collected. If it holds source-code access to institutional infrastructure, that moves through the same pipeline.

The system that could not distinguish operator from victim also could not distinguish individual credential from institutional exposure.

The repository credential is not published here. The institution is not named here. The developer is not named here. The finding was separated into notification and law-enforcement channels because public disclosure must not become a second compromise.

The public lesson is narrower and still severe: developer-targeted malware can become infrastructure exposure without the attacker ever targeting the institution directly.

The Machine Was Still Alive

Part 5 ended with a timestamp: EvilGru52 logged off at 06:13:44 UTC. Eleven hours later, WIN-RCH83RTDA5G's disk was ours.

That was one machine. The investigation was reading more than one.

The broader operator-side environment was not abandoned. It was live, connected, and actively used during the period investigators were examining the disk. Victim data was staged there. Infrastructure relationships passed through it. Connections tied it to the broader exfiltration system.

The access path is not described here.

That omission is deliberate. The public fact is that the operator environment was active and operationally connected. The mechanics of how that was confirmed are not necessary for public understanding and are not appropriate to reproduce.

The finding matters because it changes the interpretation of the earlier disk story. The investigation was not reading a single dead machine after the campaign had moved on. It was reading infrastructure that still belonged to a living operation.

And the operator was beginning to close doors.

The Intervention Question

The same operator-side visibility led to a separate finding: an exposed control plane that could interrupt active malware sessions.

The public version is simple.

Investigators identified a way to temporarily sever active sessions between infected machines and the operator's management layer. The intervention did not remediate the victims. It did not clean the machines. It did not remove persistence. It interrupted the operator's ability to maintain active real-time access while the intervention ran.

The implementation is not described here.

No event names. No endpoint paths. No timing loop. No sequence. No victim identifiers.

The reason to mention it in this article is not technical. It is ethical.

Once a defender discovers that active victims can be temporarily protected by disrupting a malicious control path, the investigation is no longer only about observation. It becomes a question of authority, proportionality, evidence preservation, victim protection, and the risk of unintended harm.

That question deserves its own article. Part VI records only why the question exists.

The Cash-Out Layer

The corpus also pointed beyond credential theft.

Recovered materials suggested a downstream financial layer involving wallet aggregation, relayed movement, exchange infrastructure, and delegated-account authorization workflows associated with EIP-7702-style account delegation.

This is not presented here as a protocol vulnerability.

EIP-7702 is a legitimate account-abstraction-related mechanism. The finding in this corpus is not that the protocol was broken. The finding is that delegated authorization workflows can become useful in a cash-out chain when attackers already control keys, sessions, approvals, infrastructure, or victim interaction paths.

The details require separate validation. Some artifacts belong in law-enforcement packages. Some involve exchange accounts, wallet addresses, API material, or live victims. Some claims are easy to overstate, especially any claim tying this corpus to unrelated public thefts.

For Part VI, the public point is limited: the campaign did not end at collection. It fed a financial layer. That layer needs to be described carefully, with evidence separated from inference.

What the Self-Infections Opened

The operator machines did not merely identify operators.

They opened the next layers of the investigation.

They showed that victim data was manually staged for review.

They showed that developer compromises could carry institutional access far beyond the individual who ran the coding test.

They showed that the campaign included active control infrastructure, not just credential collection.

They showed that the financial path extended beyond browser theft and wallet harvesting into aggregation and cash-out workflows.

Those findings are not fully described in this article because some involve unnotified victims, active credentials, access mechanics, or intervention methods that would be irresponsible to reproduce. They are separated into notification packages, law-enforcement material, counsel-reviewed records, and later public articles where the claims can be described without exposing people or live systems.

Part VI is narrower.

It documents the design failure that exposed the operation from inside.

The campaign built a pipeline that collected everything. It aimed that pipeline at developers. It also ran the pipeline across its own machines.

The result was not merely self-infection. It was self-documentation.

He Was Looking Back

The cold open's search queries now have their context.

The operator was searching his own project directories for credentials, access material, and the company name tied to a tool used inside the campaign. Those searches occurred during the same period investigators were reading the infrastructure.

The searches were not routine maintenance. They looked like exposure review.

The operator was trying to understand what had been seen, what had been taken, and what the other side might know.

The investigation cannot prove the operator understood the full scope of the exposure. The record suggests something narrower: he had noticed enough to begin searching.

After that period, the infrastructure began closing. Access points went dark. Credentials rotated. Services disappeared. The pattern was systematic. Infrastructure the investigation had observed, and access points the operator had reason to suspect were exposed, were being secured.

Password rotation is maintenance. Rotation timed to active contestation is response.

The sequence does not resolve into a clean story in which either side fully controlled the situation. It describes two parties operating around the same infrastructure with incomplete information about what the other side held.

The investigation had reached a point of mutual visibility.

That point did not last.

The operator withdrew. The infrastructure closed behind him.

The Record

The case remains active. Victim notification is ongoing. Law enforcement holds attribution and notification materials. No public enforcement action is described here.

This article does not publish victim names, active credentials, operator access mechanics, or intervention steps. That restraint is not cosmetic. It is what separates public reporting from operational exposure.

The investigation documented a factory.

The factory's own machinery documented its workers.

The same system built to consume developers consumed the people who ran it. The operators' machines held the target lists, the persona pipeline, the command chain, the provisioning accounts, and the traces of the tool builders whose work made parts of the operation possible.

None of these findings closed the case.

They established the record.

The investigation continues.

But it was no longer unilateral.

Share this article

Help spread the word about security best practices.

Hunting Lazarus Part VI: The Factory That Ate Its Workers