Hunting Lazarus, Part 5: Eleven Hours on His Disk

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

This is Part 5 of the "Hunting Lazarus" series. Parts 1–4 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. This installment covers the forensic examination of a MonoVM VPS running Windows Server 2025, machine name WIN-RCH83RTDA5G, acquired via provider rescue mode. The operator left more behind than he knew.

What an active operation leaves behind

At 05:20 UTC on February 19, we booted WIN-RCH83RTDA5G into rescue mode and changed the Windows Administrator password.

At 06:13:44 UTC, the operator logged back in.

Security ID:    SYSTEM
Account Name:   WIN-RCH83RTDA5G$

Logon Type:     10
Source Address: 37.19.200.137
Source Port:    64821

Date:           2026-02-19
Time:           06:13:44 UTC
Event ID:       4624

Logon Type 10 – interactive RDP. Successful authentication. Source resolves to DataCamp/CDNEXT-DAL, a commercial VPN and proxy network operating out of London. The machine accepted the connection, created a session, assigned a logon ID. Nothing in that record indicates that the Administrator password had been rotated fifty-three minutes earlier by a rescue mode session that Windows never saw.

We attribute that session to the operator because of what surrounds it – the same commercial VPN infrastructure visible across prior sessions in this investigation, campaign-consistent tooling, artifacts consistent with ongoing Lazarus Group operational activity. The attribution is a conclusion. The log field records only that authentication succeeded.

That is the last confirmed logon attributable to the operator on this machine.

We were already on his disk.

At 05:20 UTC, we had entered WIN-RCH83RTDA5G through its hosting provider's rescue mode: MonoVM booted a live rescue environment and mounted the tenant's NTFS partition with root access and no Windows authentication in the path. We read his event logs. We changed the Windows Administrator password. We exited.

He returned at 06:13:44 UTC and logged in successfully. He had no indication the environment had been touched.

We need to be precise about what else is in that log. There is a second EventID 4624, Logon Type 10, in the same Security.evtx – timestamped in the 06:18–06:30 UTC window, sourced from a Mullvad VPN exit node in Gothenburg. That session was ours: an RDP attempt using the credentials we had just set in rescue mode, which authenticated successfully but could not establish a graphical desktop session and was abandoned. In the raw Security.evtx, both entries are structurally identical – same event ID, same logon type, both show successful authentication. One was the operator. One was us. We note this in the cold open because a reader who later examines the raw log will find both events, and they deserve an explanation rather than a gap.

We returned at 17:11 UTC. Second rescue mode. rsync started at 17:13. Eleven hours had passed since the operator's last confirmed session.

The event logs were intact. He had not cleaned them.

What follows is what we found on his disk – and a precise account of what we did to access it.

The VPS That Kept Its Logs

The machine has a name: WIN-RCH83RTDA5G. It is running Windows Server 2025 on a MonoVM VPS, reachable at 23.227.199.7. MonoVM is a hosting provider headquartered in Armenia with infrastructure distributed across Europe and North America. This particular node sits in a datacenter the company lists as US-based. It is not a remarkable piece of infrastructure. It was never meant to be.

What made it worth looking at was everything that had come before it – three prior nodes, two countries, fourteen months of campaign activity we had documented across the first four installments of this series. This machine was a continuation of something. We had watched Lazarus rotate infrastructure the way a careful driver checks mirrors: habitually, without drama. When this VPS came up in our telemetry, it fit the pattern so cleanly it barely registered as a discovery.

That changed when we realized the logs were intact.

Most of the infrastructure we had examined in this investigation had been wiped or abandoned by the time we reached it. Operators are not sloppy about cleanup, as a rule. Logs get rotated, drives get zeroed, VPSes get terminated and repurposed. What you are usually left with is inference – network captures, passive DNS, artifacts in adjacent systems. You reconstruct what happened from the edges rather than the center.

This machine was different. The Windows event logs were present and unmodified. The Security log contained entries going back weeks. The System log was intact. Prefetch was enabled. The registry hives had not been scrubbed. Whether the operator ran out of time, or miscalculated the exposure window, or simply had not yet gotten around to it, we could not say. What we could say was that the machine, as of the moment we reached it, was a nearly complete record of its own use.

The preservation run was not the first thing we did on this system.

At 05:20 UTC on February 19 – eleven hours before rsync – we entered WIN-RCH83RTDA5G through the first rescue mode session. We read event logs. We changed the Windows Administrator password. We exited. MonoVM rebooted the machine back to Windows.

At 06:13:44 UTC, the operator returned and authenticated via RDP. EventID 4624, Logon Type 10, source address 37.19.200.137, a DataCamp/CDNEXT-DAL VPN exit node. Successful authentication. A session was created. Nothing in the Windows event log reflects what rescue mode had done to the Administrator password during a window Windows had no visibility into.

Between 06:18 and 06:30 UTC, we made our own RDP attempt from a Mullvad VPN exit node in Gothenburg, using the Administrator password we had set during the first session. The connection authenticated. No graphical session was established. We abandoned the attempt. That event appears in the same Security.evtx as the operator's 06:13 entry – EventID 4624, Logon Type 10, structurally identical.

At 17:11 UTC, we triggered the second rescue mode session. At 17:13 UTC, rsync began – a file-level copy of the mounted NTFS partition to our collection server. Sixty-nine gigabytes. Hashes matched. That is the point at which formal preservation started. Not before.

There is no preserved image of the disk prior to the 05:20 UTC session. There is no pristine pre-touch baseline.

The 06:13 UTC logon was not the first thing we noticed, but it became the first thing we could not stop thinking about.

Rescue Mode

WIN-RCH83RTDA5G was a live VPS on MonoVM's infrastructure at 23.227.199.7, running Windows Server 2025. Through wave 91–93 activity on February 17–18, we had VNC desktop screenshots timestamped at approximately 07:01 UTC on the 18th – an active, functioning Windows environment. The machine remained operational into February 19. The operator was using it.

Rescue mode is a provider feature. MonoVM – like most VPS hosting providers – offers a recovery mechanism that allows an account holder to boot a clean operating system on their server in place of the installed tenant OS. We authenticated using credentials recovered during prior investigation waves.

When rescue mode is active, the tenant OS does not run. In this case that meant a live rescue environment booted on the underlying hardware with the Windows partition mounted as an attached volume — Windows itself was not involved, and neither was any credential it managed. We authenticated to MonoVM's management dashboard as the account holder, using the operator's own hosting credentials. The access required no exploit. It required his password.

The first rescue mode session ran at approximately 05:20 UTC on February 19. We read event logs from the mounted NTFS partition. We changed the Windows Administrator password. We exited rescue mode, and MonoVM rebooted the VPS back to Windows.

At 06:13:44 UTC – fifty-three minutes after we exited – the operator logged back in via RDP. EventID 4624, Logon Type 10, source address 37.19.200.137, a DataCamp/CDNEXT-DAL VPN exit node. Successful authentication. A session was created. Nothing in the Windows event log reflects what rescue mode had done to the Administrator password during a window Windows had no visibility into.

The operator's event logs showed nothing unusual in that window. There was nothing for them to show — the machine had been offline from Windows' perspective, rebooted by the hosting provider, and brought back up without any record of what had run in the interval. When he authenticated at 06:13:44, he was logging into an environment he believed was unchanged. He had no basis to think otherwise.

Between 06:18 and 06:30 UTC, we made our own RDP attempt from a Mullvad VPN exit node in Gothenburg – using the Administrator password we had just set. The connection authenticated. No graphical session was established. We abandoned the attempt. Both entries are in Security.evtx: one at 06:13:44 from 37.19.200.137, one starting at 06:18 from the Mullvad exit. Both are EventID 4624, Logon Type 10. One was him. One was us.

We do not know what the operator did between 06:13 UTC and whenever he finished. We have no second rescue mode session running in that window to observe.

The second rescue mode session began at 17:11 UTC. At 17:13 UTC, rsync started – a file-level copy of the mounted NTFS partition to our collection server. Sixty-nine gigabytes across 124 directories. The transfer completed clean; hashes matched against the source.

Rsync is a file-level copy. It transferred allocated files, directory structure, and filesystem metadata as they existed at 17:13 UTC. It does not capture unallocated space, file slack, or MFT entries without active file handles.

The disk rsync captured was not an untouched disk. By 17:13 UTC, it had been accessed twice in rescue mode, the Administrator password change was resident in the registry hives, and the operator had authenticated a session at 06:13 whose duration and contents are unknown. There is no preserved image of the disk prior to the 05:20 UTC session. There is no pristine pre-touch baseline.

From the mounted partition – in that state, at that time – the Windows installation was fully accessible: event logs recording authentication and process activity covering the preceding period, browser artifacts, filesystem metadata, documents, downloaded archives. The operating system was not running to mediate any of it. Whatever the operator had accumulated and had not removed was there.

The event logs were intact. He had not cleaned them.

EvilGru52

On the Windows desktop, alongside the usual clutter of a working system, there was an archive: UploadData(JHC).rar. The name suggested staging – data collected, compressed, prepared for transfer.

Inside the archive was a single top-level directory.

It was named EvilGru52.

The operator had named it himself. This was not a system-generated label, not a default folder name, not inherited from a tool. Someone had typed those characters, pressed enter, and began filling the directory with victim data. The naming was deliberate. It was, in the clearest possible sense, a signature.

The archive itself weighed 245 megabytes.

The alias cross-referenced with a second artifact from the Chrome Default profile: the primary account email address linked to the browser was [email protected] – primary by volume, with 1,669 inbox messages against 647 for the next account as of the acquisition date. The root string – gru – appears in both. EvilGru52. drgru854. Two separate places, two separate artifacts, the same fragment of identity running through each of them. The name Gru is a reference to the cartoon supervillain from Despicable Me – the bald, Eastern European-accented schemer who builds an underground empire while maintaining a facade of ordinary life. Someone found that funny, or apt, or both, and styled himself Evil Gru.

We are not inferring the alias. We are not reconstructing it from fragments or inferring it from behavioral patterns. It is written in a directory name by the person who created the directory. The email address that shares its root sits in the browser profile of the same machine. The connection is direct.

There is a particular quality to the moment in an investigation when a subject stops being a pattern of behavior and becomes a person with a name. For months, this operator existed as a cluster of indicators – infrastructure, tooling, timing, targets. The machine had been active. The machine had been used. Someone had been on the other end of it.

EvilGru52 is what that person called himself when he believed the audience was zero. When the machine was running, when the sessions were live, when he was moving through victim networks and staging exfiltrated data into a folder he had personally labeled – he was EvilGru52. That was the name he chose for himself inside the work.

Now we know it too.

The Network Behind EvilGru52

EvilGru52 was not the only name on the disk. It was the alias someone used for the work. The accounts are a different layer – the infrastructure of identity that the alias ran on.

Two Gmail accounts were active in Chrome's Default browser profile on the VPS when we imaged it: [email protected], with 1,669 inbox messages at the time of capture, and [email protected], with 647. Both were open concurrently on the machine used to manage the campaign. The root string in the primary address – drgru – maps directly to the alias.

Five additional Gmail addresses appeared in Chrome autofill data from Profile 6, the browser profile used for wallet-drain operations: [email protected] (used to authenticate to Gate.com during active drain sessions in February 2026), [email protected], [email protected], [email protected], and [email protected]. Whether these represent the same individual under different pseudonyms or other members of the team operating the drain profile is not confirmed. The "fiaz" and "khan" naming convention across three of them is consistent with a Pakistani-facing persona pattern. They were used for exchange registration, not for LinkedIn outreach.

Two Telegram sessions were present on the VPS, recoverable from the tdata directory. The first account: @Bdkma717, registered under the name "michael_jemes" with a US VoIP number in the +1 360 area code (Western Washington), used operationally under the name "Luke." The second: @bagtm828, registered as "Kevin," bio identifying the holder as "Business Manager at Tunebook.io," second US VoIP number in the +1 269 area code (Battle Creek, Michigan). @bagtm828 self-confirmed location as Kyiv, Ukraine in a message from November 4, 2025. Both accounts received login verification codes during the investigation window – they were still active as of February 19.

A third identity connects both accounts: @goldenman66eth, Telegram ID 7081551406. This account self-identifies as "Gru" and uses the alias "JHC" as a secondary identifier – the same JHC that appears in UploadData(JHC).rar on the operator's desktop. @goldenman66eth functioned as a supervisor in the channel structure: the account distributed stolen payment card data, Payoneer credentials, and ETH wallet addresses for payment routing.

The Nostr identity on the disk resolves to the same source. The file hey.txt – the same file that contained crypto seeds and FTP credentials – carries a record labeled "Anigma nostr nsec:" followed by the private signing key for a Nostr identity using the alias Anigma. Nostr defines identity by keypair rather than username: holding the private key is holding the identity. Whoever wrote that file held the Anigma keypair.

EvilGru52 for the work. drgru854 for the inbox. Anigma for the decentralized network. Gru and JHC for the channel. Each naming calibrated for a different surface, each of them now in our notes.

The Office

The first thing you notice, working through the disk image, is how organized it is.

This is not the workspace of someone improvising. There are folders. There are templates. There are named personas with consistent digital footprints across multiple platforms. If you walked into a physical office and found a whiteboard covered in outreach scripts and a filing cabinet full of fake LinkedIn profiles, you would assume you had found a boiler room operation. That is approximately what we found – except it ran on a Windows VPS, and instead of selling timeshares, it was selling fake job opportunities that ended with a Node.js payload draining cryptocurrency wallets.

Four companies anchored the operation. TwentyFour7 – also styled as "Twenty Four 7" in some materials – and Tunebook.io handled recruitment-facing outreach. VaultSwap and MindGeek provided the crypto and tech veneer that made the fake DEX platform pitches plausible. None of these entities exist in any meaningful legal or commercial sense. They exist as named surfaces: landing pages, email domains, LinkedIn company pages – enough to make a cold message feel institutional rather than personal.

Behind each company were the personas. Eleven of them, each with a name, a LinkedIn profile, a Calendly booking link, and a fabricated CV. Joel, Alfredo, Arnas, Kathleen, Heather, Alexia, Sam, Bruna, Rosangela, Vilson, Oriona. They held titles that map neatly onto the roles a legitimate startup would have – Project Strategists, COOs, CMOs, Business Managers, CEOs, Technical Recruiters. The titles are not random. They are calibrated to answer the question a cautious developer will ask when a stranger reaches out on LinkedIn: who are you, and why are you contacting me?

The answer, built into the persona architecture, is: I am a professional, I represent a real organization, and I am reaching out because we have a specific need.

The sales machinery that converts that answer into a malware delivery sits in four template files recovered from the disk.

invite.txt contains the cold outreach templates – LinkedIn messages customized by developer role. There are variants for QA engineers, DevOps engineers, and generalist developers. Details.txt carries the pitch decks in text form: the fake DEX platform, its features, its market position, why a technical co-founder or senior developer would want to join. Schedule.txt provides the interview scheduling flow, complete with Calendly links tied to the personas. And Money.txt frames the financials – project budgets in the range of $700,000 to $800,000. Not salaries. Budgets. The distinction is deliberate — a budget signals committed backing and a defined technical scope, not an open-ended job offer.

The pipeline ends with the repositories. Five GitLab projects and one on GitHub – gitlab.com/tune247/ultrana-1-24-592-devel, gitlab.com/jason198511/evm-1-8-128-release, gitlab.com/jasonharry1988052/evm-ultrana-demo, gitlab.com/nextzen247/ultrana-1-23-579-release, github.com/0xJHdev/ultrana-staking-platform – styled as crypto project demos, the kind of codebase a candidate would be asked to run locally as part of a technical interview. These are not codebases candidates are meant to audit. They are codebases candidates are meant to execute. The delivery chain – fake LinkedIn contact, fake company, fake interview, malicious demo repository – is the defining signature of the Contagious Interview campaign, a Lazarus Group operation targeting crypto and Web3 developers that has been documented since 2023. Consistent with BeaverTail delivery patterns documented in prior Lazarus research – BeaverTail being the npm-based malware family attributed to Lazarus, designed specifically to harvest credentials and drain cryptocurrency wallets from developer machines – these repositories are not submissions to be reviewed but payloads to be triggered.

What sealed it was the PowerShell history. Buried in ConsoleHost_history.txt was a sequence:

git clone https://gitlab.com/jason198511/evm-1-8-128-release
npm i
npm start

The operator had cloned one of his own fake demo repositories and run it on his own VPS. Whether this was a test, a mistake, or a rehearsal before deployment, the effect is the same – it closes the loop. The lure, the pitch, the interview, the demo, the payload: we can trace the entire chain from a single machine, because the person running the machine ran it on himself.

This is not improvisation. It is industrialized. The scripts are templates because the targets are interchangeable. The personas are interchangeable because the companies are fictional. The repositories are products in the same way that phishing kits are products – tested, versioned, ready to ship. The operator was running a company. It just did not exist.

Sixteen Thousand Targets

The four fake companies and eleven personas in The Office existed to approach specific people. The target file on the disk makes the scale visible.

The file is named Target. It was present in two locations on the forensic image: in C:\Users\Administrator\Documents\ and in the Recycle Bin as part of a deleted archive from February 11. Both copies are byte-identical. The operator deleted a copy and kept a copy. The working copy remained.

The file contains 16,952 LinkedIn profile URLs. One per line. No email addresses, no names, no personal details of any kind – only the profile slug on linkedin.com/in/ sufficient to reconstruct the full public profile. The operator was using LinkedIn as the identification and outreach layer.

The file is structured in sections. The first segment contains approximately 44 profiles prefixed with a red-stop emoji – an active outreach queue, the profiles currently in motion. The remainder of the file is the pipeline: profiles compiled and staged for future approach.

The industry profile is consistent throughout. The URL slugs across the full 16,952 entries resolve overwhelmingly to blockchain and Web3 professionals: Solidity engineers, smart contract developers, DeFi protocol contributors, fullstack developers active in the Web3 ecosystem. The geographic spread is global – Southeast Asia, South Asia, Eastern Europe, Western Europe, the Middle East, North America. The fake DEX platform pitch in Details.txt offers a technical co-founder role and an $800,000 project budget. That pitch was written to land precisely with this population.

The 44 priority entries are the people who, as of the time of the disk image, were already in contact with one of the eleven personas.

The remaining 16,908 entries are who was next.

Six Seeds, Six Victims

Chrome Profile 6 was the operations browser. The Gmail account tied to it – [email protected] – was not a persona for job applications or repository commits. It was a workspace, and among the extensions installed in it was Rabby Wallet.

Rabby is a wallet manager built for practitioners: it handles multi-chain portfolios cleanly, imports seed phrases without friction, and gives full control of every derived address the moment you hand it a recovery phrase. That last feature is the relevant one here.

Six seed phrases were imported into Rabby Wallet on that machine. Not in a continuous daily run – in two deliberate sessions. Two imports on February 14. Then a four-day gap, no activity. Then four more on February 18. KeyringIDs 3 and 4 on the first date, KeyringIDs 5, 6, 7, and 8 on the second. The Rabby Wallet leveldb records the timestamps. The pattern they describe is not a compulsive accumulation but staged work: a batch, a pause, a second batch. Someone loaded two victims, stopped, and returned four days later to load four more.

A seed phrase is not a password that can be changed. It is the root credential from which every wallet address the phrase ever generated can be derived — and whoever holds it holds all of them, irrevocably, across every chain, without any action or knowledge required from the original owner. Six of them were sitting in the operator's browser profile.

The pipeline that fed this window starts several sections back – the fake developer identities, the GitLab repositories seeded with code that looked useful, the sustained effort to appear legitimate to people doing legitimate work. All of that existed to create a moment: someone trusts the repository, runs the code, and the code reaches back. The seed phrases in Rabby Wallet are what that moment produced. Six of them, collected across two sessions separated by four days.

The staging interpretation is not a reach. The two-session structure matches the kind of operational discipline visible elsewhere on this machine – deliberate sequencing, not urgency. February 14 was a first pass. February 18 was the completion of whatever count the operator was working toward. Six victims, reached in two movements.

The February 18 cutoff is notable. On the same date, MetaMask and Zerion were uninstalled from the browser, and Phantom was onboarded for Solana. The machine's profile was shifting. Four days after the last seed batch, it went quiet. The record of the imports stayed. It does not tell us whether assets moved, by how much, or by which routes – but it tells us the mechanism was engaged, and how many times.

Six times. Two sessions. Four days apart.

The Bridge He Used to Disappear Money

Among the artifacts recovered from the disk, Stargate Finance appeared. A URL, a session trace, enough to register its presence in the operator's workflow.

Stargate is a cross-chain bridge built on the LayerZero messaging protocol. The mechanism is specific: submit a transaction on one chain, and a corresponding asset is released on a destination chain of the operator's choosing. ETH on Ethereum becomes USDC on Arbitrum. From there the same mechanism moves it again – to Solana, to BNB Chain, to any supported network. Each hop lands on a separate blockchain.

This is the forensic limit. The origin chain shows a deposit into the bridge contract. Whatever follows — which destination chain, which asset, which receiving address — is selected by the sender and requires independently monitoring the other end to trace. We did not have that monitoring in place. Stargate was present in the disk artifacts. What it is capable of is documented. The reason an operator with six freshly imported seed phrases would have it open is not obscure.

The C2 Infrastructure Expands

Three new FTP servers appeared in FileZilla's recentservers.xml that had no prior history in our documentation of this operator or this infrastructure cluster.

195.201.104.53
144.172.89.198
216.126.227.239

Before getting to what those entries mean, it is worth explaining what recentservers.xml is. FileZilla writes this file automatically when a user configures or initiates a connection to an FTP server through the GUI. The file records host, port, protocol parameters, and credentials – stored in plaintext XML, which is its own forensic gift. What it captures is intent and infrastructure knowledge: these are servers the operator configured connections to. The file confirms he had the credentials and the intent to reach them. It does not confirm every listed connection produced a successful data transfer; a connection attempt that stalled at the authentication layer would still be represented here. The significance of the artifact is not in proving active sessions. It is in surfacing infrastructure he was using or had prepared to use.

That matters for what follows.

The file held six FTP entries in total. Three of the hosts were familiar – flagged during earlier phases of this investigation, documented and cross-referenced. Seeing them again confirmed continuity: this machine shared infrastructure with a pattern of activity we had been tracking. Operators reuse what they trust.

The three new entries were not previously attributed to this operator or this cluster. The credentials attached to them follow the same team-numbering pattern as the known servers – 10team, 2team, 3team – which is consistent with a coordinated exfiltration infrastructure rather than ad hoc staging. The password on 144.172.89.198 matches a credential documented on a previously known server in this cluster — 167.88.165.222 — confirming infrastructure reuse at the credential level.

A note on what FTP-based exfiltration looks like operationally: it is not sophisticated. It was not designed for covert use. But it is reliable, widely supported, and trivially scriptable. For moving structured data at volume – credential dumps, browser artifacts, session cookies, wallet files – FTP works. You write a few lines, point them at a server, and the files move. The operator was not reinventing his infrastructure. He was using what functions.

The implications of six FTP connections are straightforward. WIN-RCH83RTDA5G was not a standalone workstation. It was a node – connected outward to infrastructure we only partially understand, some of it documented, three endpoints of it newly surfaced. The map just got wider.

One Hundred and Twenty-Four

The three FTP servers in FileZilla are the outbound path. C:\10team\ is what they were receiving.

The directory structure on the VPS organizes exfiltrated data by team and victim machine. C:\10team\ contained 124 subdirectories at the time of imaging. C:\1team\ contained 34. C:\2team\ contained one. Each subdirectory is named with a team identifier and a machine hostname – a convention that maps incoming data to an originating team and a specific compromised workstation. The team numbering is consistent with the FTP credential structure: 1team, 2team, 3team, 10team. The directories on the VPS and the accounts on the FTP servers are two sides of the same architecture.

The C:\Users\Administrator\Documents\ folder held the aggregate of what had been processed: 618 stolen documents in a doc\ subdirectory, 124 stolen spreadsheets in xls\. A separate archive in Downloads – 905_DESKTOP-RJGBUN6.rar, 1.7 gigabytes – contained the compressed filesystem of a compromised Windows workstation. The total rsync of the full disk ran to 69 gigabytes.

The team prefixes matter for what they indicate. The FileZilla credentials reference four team labels – 1team, 2team, 3team, 10team. Three of those four have corresponding directories on this volume; 3team had credentials in the FileZilla config but no directory on the disk. The 159 victim subdirectories that are present span three teams. That is still not a solo operator's machine. It was a collection and coordination layer for an operation with more than one team working it, and the infrastructure extended to a fourth team this volume does not contain.

Six seed phrases were loaded into Rabby Wallet on this machine during February. Six victims accessed through the cryptocurrency-drain layer this particular operator ran. One hundred and fifty-nine victim directories are a longer history – data collected before and alongside what appeared in this machine's own browser profiles.

The 16,952 profiles in Target are the plan. The 159 subdirectories across the team folders are part of the record of what had already run.

The AI Tools

Two AI tools were on the disk. They are not the same tool, and they should not be treated as such.

The first is LM Studio. LM Studio is a desktop application that lets you download and run large language models locally, on the machine itself – no API calls, no tokens routed through a cloud provider, no logs held by someone else. The evidence for its presence is a Windows shortcut: .lmstudio.lnk, dated December 27. A shortcut in the user environment indicates the application was installed and configured for quick access. What we cannot determine from a shortcut alone is whether LM Studio was actively running sessions at the time of the disk image, or how frequently it was used. The shortcut establishes that it was set up for use. That is the claim we will stand behind.

For an operator managing eleven fabricated personas, volume was the operational constraint. The shortcut at .lmstudio.lnk was dated December 27. LM Studio runs models on the local machine, without external API calls. Whether that was the reason for the installation, the disk does not say. That it was set up, and that its design fits the problem on the machine, we can say plainly.

The second tool is different in kind: PaddleHub, Baidu's NLP and computer vision pipeline framework. PaddleHub is not a chat interface. It is not a desktop application you open and interact with directly. It is a programmatic library – a collection of pretrained models you invoke by writing code, to run specific tasks: text classification, named entity recognition, OCR, document parsing. The evidence for its presence is also a shortcut: .paddlehub.lnk, dated January 8. Same evidentiary weight as the LM Studio shortcut – installation and setup confirmed; active use and specific application of the tool are not confirmed by the artifact.

What data would PaddleHub have been used against? The disk does not answer that question. What we can say is that the machine held harvested documents, and that PaddleHub's NLP pipeline architecture is well-suited to batch triage of that kind of material – extracting names, organizations, and structured content from unstructured text at a volume no manual process could match efficiently. That is an inference from the tool's design and what else was present on the machine, not a reconstruction from session logs or output artifacts.

The finding we will stand behind is narrower than the inference: a Lazarus-attributed operator, running an industrialized social engineering campaign, had local AI inference capability installed on the machine, with shortcuts indicating both tools were set up for use. The specific applications – what they processed, what they produced – remain opaque.

What is not opaque is the direction this points, and the distinction between the two tools matters for reading it clearly. LM Studio is a GUI application for interactive local LLM use. PaddleHub is a developer framework for running pretrained models programmatically against data. These are two different capability investments. Together they suggest an operator who was not simply adopting AI tools casually, but building out a local infrastructure for it – one tool for generation, one for data processing.

These campaigns have always been resource-intensive in human terms: building personas, maintaining them, sustaining extended pretexts over weeks or months. Local AI tooling changes that calculus. It lowers the cost of volume. Whatever these two tools were used for on this machine, their presence is a signal about where this kind of operation is heading.

trustwallet.txt

The file is called trustwallet.txt.

It lives in the Documents folder of a Windows VPS. The name is straightforward. It is not obfuscated, not archived, not encrypted. It is a plaintext file with a name that does exactly what it says – it stores trust wallet information. The kind of file someone makes when they want to remember something important and believe no one else will ever read it.

We read it.

What is inside is not a victim's data. It is the operator's. A TrustWallet seed phrase – twelve words, the complete cryptographic key to a wallet. Below that, an Aptos wallet address and its corresponding private key, written out in full. A Solana wallet address associated with Phantom. An Ethereum seed phrase, also twelve words. A Filecoin node private key. A Starknet seed phrase. A Nostr nsec key – the private signing identity for a decentralized social protocol. Below those, configuration entries for additional wallet setups under names we will not reproduce here.

The file is a complete self-portrait of a man's financial infrastructure across six distinct blockchain ecosystems, stored in plain ASCII, on a machine connected to the internet, on a VPS he used to run the operations that drained other people's wallets.

The analysis writes itself, and then it doesn't.

The obvious reading is OPSEC failure. But that framing is too small for what this actually shows. OPSEC failure implies a lapse – a moment of carelessness in an otherwise careful practice. What trustwallet.txt reveals is a threat model. He knew exactly what kind of machine this was. He knew it ran phishing infrastructure, that it held victim credentials, that it was used to drain wallets by tricking people into surrendering their seeds. And he stored his own seeds there anyway. Because in his threat model, the machine was accessible only to him.

He understood the threat of a compromised user session. He had not modeled the threat of a compromised hosting account — his own, held in his own name, authenticated with a password he had stored on the same machine. The miscalculation was not technical. It was about who the adversary was.

And the disk had everything.

Six ecosystems means six separate asset classes. TrustWallet and the Ethereum seed cover EVM-compatible holdings – whatever is stored across standard ERC-20 infrastructure. Solana is its own world, the Phantom ecosystem with its own token economy. Starknet operates on ZK-rollup architecture, a layer-2 environment with its own growing asset base. Filecoin is a storage-chain network with its own native token and node economics. Nostr is not a financial instrument in the traditional sense, but a private nsec key is a cryptographic identity – it is how a pseudonym signs its speech across a decentralized network. Whoever holds the key holds the name.

Earlier in this article, we described Profile 6 on the Chromium installation – a browser profile containing six victim seed phrases, stored in the user data directory, ready to be used.

Profile 6 contained six victims' keys.

Documents contained one operator's keys.

The format is identical. The file structure is the same. The only thing that changed is whose name is at the top.

The Last Commute

The 06:13:44 UTC session has been present in this article since the first paragraph. With everything the investigation established sitting behind it, it is time to lay the complete RDP record on the table.

WIN-RCH83RTDA5G's authentication log does not show a single opportunistic connection. It shows a pattern. ColoGuys Dallas – 67.43.49.10 – appears as a recurring source address across three consecutive days: February 17, 18, and 19. Two sessions on the 17th, one on the 18th, two more on the 19th. This was not a one-time operation. This was a commute.

On February 19, the log records the following.

At 02:53 UTC, EventID 1149 from the TerminalServices-RemoteConnectionManager log – not the Security log – records a pre-authentication negotiation from 62.33.223.164, which geolocates to RU-TRANS-TELECOM infrastructure in Vladivostok, Russia. There is no corresponding EventID 4624. No successful logon follows. EventID 1149 records a channel negotiation – a pre-authentication probe, not a confirmed session. A connection was initiated, a channel was negotiated, and then either authentication failed or the connection was abandoned before it completed. It is not a logon. It is not a VPN slip. It is not an identity. It is a Vladivostok-associated IP touching the authentication layer and going no further. The log shows nothing else, and we will say nothing else about it.

At 06:13:44 UTC, EventID 4624, Logon Type 10, records successful authentication from 37.19.200.137 – DataCamp/CDNEXT-DAL, London. That is the operator's confirmed last session. It has been documented in the cold open and in the Rescue Mode section. We restate it here because this is where the full record belongs.

Between 06:18 and 06:30 UTC, EventID 4624, Logon Type 10, records a second successful authentication – from a Mullvad VPN exit node in Gothenburg. That was ours. Both entries have been disclosed. The RDP log for February 19 contains two successful authentications. One was the operator. One was us. There is no third entry.

At 17:11 UTC, we triggered the second rescue mode session. At 17:13 UTC, rsync began.

Eleven hours separated the operator's last confirmed session from the start of preservation. The machine was running throughout. The event logs were intact. The filesystem was unmodified. trustwallet.txt was sitting in Documents exactly where he had left it. He had come in that morning, done whatever he came to do, and left. Nearly half a day passed. Then we were there.

Eleven hours is also an unbridgeable distance. Whatever he did after 06:13:44 UTC, he did it without those keys.

What Lazarus Built Here

WIN-RCH83RTDA5G was one node.

That is the fact that matters most, and the one easiest to lose sight of when you are deep inside a single machine's filesystem. Across this investigation, the infrastructure around this VPS resolved into a specific geometry: 11 fabricated professional personas, 4 fake companies built to sustain them, 6 malicious repositories seeded into the development ecosystem – 5 on GitLab, 1 on GitHub – 16,952 LinkedIn profiles staged as the next-wave target list, 6 victim cryptocurrency wallets drained across two sessions in February, 159 victim directories across three team-numbered collections on-disk (124 in 10team, 34 in 1team, 1 in 2team), 3 previously undocumented C2 FTP servers whose addresses have since been shared with the relevant parties.

Parts I through IV traced how Lazarus Group constructs a working environment – the persona architecture, the recruitment lures, the repository poisoning, the slow accumulation of access. WIN-RCH83RTDA5G is where some of that work landed. Local AI inference capability was installed on the machine. Telegram Desktop artifacts were present with a last-modified timestamp of February 11. Whether those Telegram sessions remained valid at the time of analysis was not confirmed and cannot be stated as fact.

Two threads remain open. The Telegram artifacts may carry session data; they may not. The three newly identified FTP servers are now in other hands. Both threads extend beyond this article.

The series continues because the infrastructure continues. Campaigns like this one do not conclude when a single VPS is imaged. They continue at the pace of their operators – methodical, patient, already several steps ahead of whatever timestamp we open on next.

But here is what this node told us that the prior three did not: the operator left his own keys on the machine he used to steal yours. That is not a detail in the box score. That is the shape of the whole operation compressed into a single plaintext file – the infrastructure, the arrogance, the miscalculation. EvilGru52 logged off at 06:13:44. Eleven hours later, the disk was ours.

This investigation is based on forensic artifacts recovered from an operator VPS acquired via MonoVM's rescue mode feature, which replaced the tenant Windows installation with a live rescue environment, mounting the NTFS partition as an attached volume accessible over SSH with root privileges and no Windows authentication in the path. Victim identities are withheld. Persona names appearing in this article – including EvilGru52 – are operator-chosen aliases recovered directly from forensic artifacts on the disk; they were not assigned or inferred by the investigators. Findings from this investigation were shared with law enforcement prior to publication.

Share this article

Help spread the word about security best practices.