Skip to main content
73 Microsoft Repos Poisoned on GitHubIncident
3 min readFor Security Engineers

73 Microsoft Repos Poisoned on GitHub

Recently, Microsoft temporarily removed 73 of its open-source repositories from GitHub due to an information stealer injected through compromised CI/CD pipelines. Some repositories have been restored, while others remain offline during the ongoing investigation.

This incident highlights how attackers exploit trust relationships in software development and the control failures that allow them to succeed.

What Happened

Attackers compromised the 'durabletask' package, a Microsoft library, injecting code to steal credentials and environment variables. This malicious package spread through dependency chains into 73 Microsoft repositories. The attack, known as "Miasma," is part of a supply chain campaign by the cybercrime group TeamPCP.

Microsoft detected the breach, took affected repositories offline for review, and began restoring them after validation. The attack exploited gaps between repository access controls and build-time execution permissions.

Timeline

Initial Compromise: Attackers accessed the 'durabletask' package, adding credential-harvesting code while maintaining its functionality.

Propagation Phase: The compromised package was integrated into 73 repositories through normal updates, treated as a trusted dependency.

Detection: Anomalous behavior in repository activity was flagged by Microsoft's security monitoring, prompting an investigation.

Response: Affected repositories were removed from public access. After forensic review, some have been restored; others remain offline.

The attack demonstrates how quickly malicious code can spread through dependency networks once initial access is achieved.

Which Controls Failed or Were Missing

Dependency Verification: The package was accepted as legitimate without cryptographic verification of integrity.

Build Environment Isolation: Malicious code accessed credentials during the build process, indicating excessive permissions and lack of secrets isolation.

CI/CD Pipeline Authentication: Weak authentication or insufficient separation between code commit rights and build execution rights were exploited.

Automated Dependency Updates: Systems automatically updating dependencies enabled the rapid spread of malicious code without manual review or security scanning.

IDE and Tool Execution Controls: Insufficient sandboxing or user permission prompts allowed execution of malicious code during development.

What the Relevant Standards Require

NIST 800-53 Rev 5 SA-10 requires protecting the integrity of system changes and verifying software components before integration.

ISO/IEC 27001:2022 Annex A.8.31 mandates separation between development, test, and production environments to reduce risks.

OWASP ASVS v4.0.3 Requirement 14.2.1 requires components to come from trusted sources with integrity verification.

PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining security of custom code throughout the development lifecycle.

SOC 2 Type II CC6.8 requires restricting access to system components and data to authorized users.

These standards emphasize verification, isolation, and least-privilege access. The Miasma attack exploited gaps in these areas.

Lessons and Action Items for Your Team

Implement Dependency Pinning and Verification

  • Pin exact versions of dependencies in lock files.
  • Verify package checksums against known-good values before each build.
  • Use tools like Sigstore or in-toto for cryptographic verification.
  • Avoid auto-updating dependencies in production branches without review.

Isolate Build Credentials

  • Build systems should not access production credentials.
  • Use short-lived tokens that expire after each build.
  • Store secrets in vaults like HashiCorp Vault or AWS Secrets Manager.
  • Audit environment variables needed for builds.

Require Manual Review for Dependency Changes

  • Flag pull requests modifying dependency files in your CI/CD.
  • Have a second engineer review dependency version changes.
  • Run security scanning on dependency updates.
  • Block merges if new vulnerabilities are introduced.

Sandbox Your Development Tools

  • Configure IDEs to prompt before executing code from dependencies.
  • Disable automatic code execution in AI coding assistants.
  • Run builds in containerized environments with minimal network access.
  • Use separate development machines or VMs for untrusted code.

Monitor Repository and Build Activity

  • Alert on unexpected changes to dependency files.
  • Track write access to your CI/CD configuration.
  • Log all build-time network requests and flag unusual destinations.
  • Set up alerts for new packages added to your dependency tree.

Audit Your Trust Boundaries

  • Map where your build process trusts external input without verification.
  • Document systems that can push code versus those that can trigger builds.
  • Review permissions for publishing packages to internal repositories.
  • Test your response plan: how quickly could you identify and remove a compromised dependency?

The Miasma attack didn't require breaking encryption or exploiting memory bugs. It relied on your build system trusting a package it shouldn't have. Fix that trust model to close the door they walked through.

supply chain security

Topics:Incident

You Might Also Like