Snyk discovered 12 malicious packages in the Python Package Index (PyPI) that stole Discord tokens, Roblox credentials, and payment card data. The attackers used Discord's content delivery network (CDN) to host and distribute their malware, wrapping it in PyInstaller executables to evade detection.
This was a calculated attack. The perpetrators created 12 variants, tested distribution channels, and exploited a chat platform's infrastructure against its users.
Attack Timeline
While specific dates for package publication or detection are not provided, Snyk's research team identified the malicious packages during routine monitoring. The packages were available on PyPI long enough to be indexed and potentially installed by developers seeking legitimate dependencies.
The attack chain unfolded as follows:
- Attacker publishes packages with names similar to legitimate libraries.
- Developer installs package via pip.
- Package downloads executable from Discord CDN during installation.
- PyInstaller-wrapped binary runs, harvesting credentials.
- Stolen data exfiltrates to attacker-controlled endpoints.
Failed Security Controls
Dependency Verification: None of the 12 packages should have reached a production environment. Your pip install command trusts PyPI by default. Without verifying package signatures or checksums, you risk accepting malicious content.
Network Egress Filtering: The malware downloaded executables from Discord's CDN and uploaded stolen credentials to external endpoints. Both actions should have triggered alerts.
Runtime Behavior Monitoring: A Python package that spawns executables during installation is suspicious. A package that accesses browser credential stores and Discord token files is hostile. These behaviors should have triggered automated responses.
Static Analysis at Intake: PyInstaller conceals Python code in a binary blob to evade analysis tools. Your dependency scanner must unpack these archives and inspect the contents. Many scanners do not.
Compliance Standards
NIST 800-53 Rev 5 outlines several relevant controls:
SR-3 (Supply Chain Controls and Processes): Implement controls to protect against supply chain risks. Installing unvetted packages from public registries is a supply chain risk. Use intake procedures like signature verification, hash checking, and behavioral analysis before production deployment.
SR-4 (Provenance): Track the origins of all components. Can you list every PyPI package in production and trace each one back to its publisher? If not, you're violating this control.
SI-7 (Software, Firmware, and Information Integrity): Use integrity verification mechanisms. Your build process should validate package hashes against known-good values. Lock files are useful only if you check them.
ISO/IEC 27001:2022 addresses this from a vendor management perspective:
Control 5.19 (Information Security in Supplier Relationships): Treat package registries as suppliers. Implement security requirements in your relationship with PyPI, such as private mirrors, vulnerability scanning, and approval workflows before new packages enter your environment.
Control 5.20 (Addressing Information Security within Supplier Agreements): Extend this to monitoring and incident response. When Snyk publishes a malicious package list, ensure you can check your dependencies against it promptly.
PCI DSS v4.0.1 specifies requirements for third-party code:
Requirement 6.3.2: Maintain an inventory of bespoke and custom software, and third-party software components. Every PyPI package you import is a third-party component. You need an SBOM (Software Bill of Materials) that updates automatically with every build.
Requirement 11.6.1: Detect unauthorized changes to HTTP headers and payment page content. These packages targeted payment information. If your application handles cardholder data and imports unvetted packages, you're creating a risk that violates this requirement's intent.
Actionable Steps
Implement Package Verification: Use tools like pip-audit to scan your requirements.txt against known vulnerability databases. Add hash checking to your requirements files: pip install --require-hashes. This extra step can prevent similar attacks.
Deploy a Private Package Mirror: Use tools like Artifactory or Nexus Repository to control what packages enter your environment. Block malicious packages at the mirror level before developers can install them.
Enable Network Monitoring for Package Installations: Your CI/CD pipeline should not download executables from Discord's CDN. Set up egress filtering rules to flag unexpected domains during build processes. Alert on any HTTP requests to file-sharing or chat platforms from build containers.
Scan for PyInstaller Artifacts: If a Python package includes .exe, .app, or other compiled binaries, investigate why. Legitimate packages may use native extensions, but they should be clearly documented. Undocumented executables are red flags.
Generate and Monitor SBOMs: Use tools like Syft or the OWASP CycloneDX specification to create machine-readable inventories of every component in your applications. When a malicious package is disclosed, know immediately if you're affected.
Establish Package Approval Workflows: Before adding a new PyPI package to your codebase, require a security team review. Check the package's publication history, maintainer reputation, and download statistics. New packages from unknown maintainers need extra scrutiny.
The attackers understood your dependency management workflow better than you did. They anticipated your pip install without verification, bypassed your content filters using Discord's CDN, and hid their code from your scanners with PyInstaller.
Close these gaps now. The next wave of attacks is already being developed.
