In March 2024, attackers used a compromised GitHub identity and a lookalike Python package host to direct developers toward a malicious Colorama clone. The evidence describes an attack on developer dependencies and accounts—not a compromise of the official Colorama project—and the payload was designed to steal credentials and session data.
How the attack worked
The campaign combined two kinds of trust abuse: a hijacked GitHub account and a typosquatted download host. The fake host, files.pypihosted.org, differed from the legitimate Python package artifact host, files.pythonhosted.org, by a small but significant part of its name. A familiar package name or filename therefore did not establish that the downloaded code was official.
- Build apparent credibility. Attackers created repositories and used a compromised, reputable GitHub identity to star them and make a malicious commit. A Top.gg contributor’s account was compromised on March 4, 2024.
- Redirect a dependency. The commit added instructions in the
top-gg/python-sdkrepository to download Colorama from the lookalike host. - Disguise the package. The counterfeit code was made to resemble the real package. Checkmarx reported that large blocks of whitespace pushed malicious code out of view during a casual review.
- Run additional code. Importing the package launched further Python code, retrieved additional components and established persistence through the Windows Registry.
- Collect and send data. The malware targeted credentials, tokens and local files, then sent collected information to attacker-controlled infrastructure.
Checkmarx also reported that yocolor version 0.4.6 was published on PyPI on March 5, 2024, as a delivery mechanism in the campaign. That detail does not mean every installation of yocolor, or every Colorama installation, was affected.
When the incident unfolded
| Date | Reported event |
|---|---|
| November 2022 | Checkmarx’s campaign timeline lists earlier malicious PyPI packages associated with the activity. |
| February 1, 2024 | The attacker registered pypihosted.org, enabling the lookalike download host. |
| March 4, 2024 | A Top.gg contributor’s GitHub account was compromised and used to commit malicious code. |
| March 5, 2024 | yocolor version 0.4.6 was published on PyPI as a campaign delivery mechanism. |
| March 25, 2024 | Checkmarx published its technical report; SecurityWeek reported on the incident the same day. |
What the malware targeted
Checkmarx described a multi-stage infostealer rather than a simple package prank. Its reported targets included browser data, cryptocurrency wallets, Discord and other session tokens, Telegram and Instagram data, and local files. The documented Windows Registry persistence means removing the package alone may not remove every component or undo stolen-session exposure.
Recommended Free Tools
#1 Best Overall
Python developer Mohammed Dief described noticing repeated Colorama-related command-line errors before realizing his machine had been compromised. His account is an individual report, not a measure of how many developers were infected.
What is known about the impact
Checkmarx reported multiple infected developers and said the Top.gg community had more than 170,000 members. That figure describes community size; it is not a count of confirmed infections or victims. SecurityWeek reported that Colorama had more than 150 million monthly downloads, a measure of the package’s scale rather than the number of affected downloads.
The reported attack used a malicious clone and a compromised contributor identity. The available incident account does not establish that Colorama’s official maintainers or the official Colorama project were compromised. Nor do the reported community and download figures establish how many people installed the malicious code.
Quick Recap
How to check whether a dependency or mirror is suspicious
- Compare hostnames character by character. Check every package URL against the expected official host; do not rely on a familiar package name, filename or HTTPS lock icon.
- Review dependency instructions. Inspect
requirements.txt, lockfiles, setup scripts, CI configuration and shell history for direct URLs, unexpected package indexes or references to unfamiliar mirrors. - Verify what was installed. Compare the package version, source URL and hash against trusted project records or an internally approved artifact. A version number alone does not prove provenance.
- Examine code and behavior. Look for unusual import-time network activity, subprocess launches, persistence changes, obfuscated code or large blank regions that can conceal content. Treat these as investigation leads, not proof by themselves.
- Assess identity signals cautiously. A verified-looking GitHub identity, established account history, repository stars or a familiar project association can be useful context, but none proves a particular commit is safe.
What to do if you installed the fake package
- Isolate the suspected device. Disconnect it from networks where practical to limit further communication, and preserve relevant logs and files if an incident investigation may be needed.
- Use a clean device to revoke access. Revoke GitHub sessions and tokens, along with relevant cloud and application sessions. Stolen session cookies can allow access without the attacker knowing the account password.
- Rotate exposed secrets. From a clean device, change passwords and replace API keys or other credentials that may have been present on the machine. Prioritize accounts and keys used on the affected host.
- Inspect and remediate the endpoint. Check for Windows Registry persistence and suspicious processes or files; scan the device with trusted endpoint-security tools. Review browser, cryptocurrency-wallet and messaging sessions for unauthorized access.
- Rebuild from trusted sources. Remove the suspect dependency path, restore the project from a known-good source, and reinstall dependencies only from verified artifacts. Do not return the device to normal use until remediation is complete.
- Check connected build systems. If the affected machine had access to CI, cloud accounts or deployment credentials, investigate those systems and rotate any secrets it could reach.
How teams can reduce the risk
- Enforce dependency and mirror policy. Restrict installs to approved package indexes and repositories; flag or block unapproved direct URLs.
- Pin dependencies and verify hashes where practical. Version pins reduce unintended changes, while hashes help verify that an artifact matches an expected file. Neither makes an untrusted source safe by itself.
- Use provenance and composition controls. Package provenance checks, artifact signing and software-composition analysis can help establish where dependencies came from and identify risky components.
- Monitor install- and import-time behavior. Detection that observes network access, process launches and persistence changes can catch behaviors that static dependency review may miss.
- Protect developer identities and sessions. Use phishing-resistant multifactor authentication, short session lifetimes where available, and regular token review. Treat session cookies as credentials and investigate unexpected repository changes.
- Cover both laptops and CI. Apply dependency policy and monitoring to developer workstations as well as build systems; a clean CI pipeline does not rule out compromise of a developer’s machine or account.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →
