Sophos IoCs: a CSV archive of published campaign indicators

A data drop rather than a tool

The repository description is one sentence: Sophos-originated indicators of compromise from published reports. That framing sets expectations correctly, because there is no package to install, no configuration to set and no API to call. The top level of the repository is a long list of CSV files, and the README is largely a piece of ASCII art rather than documentation. What the project is, then, is a way to make the indicators inside published Sophos research available in a form that a script can read. The audience is a detection engineer or a threat intelligence analyst who wants to look for infrastructure from a campaign that was already written up, and who would otherwise have to open a report, read the table, and retype the values. The value is in the extraction rather than in the analysis, and that distinction shapes everything about how you should use it. The analysis, the confidence ratings, the false positive notes and the reasoning stay in the reports, and this repository keeps only the machine readable residue. A team that wants both still has to read the published report, and a team that wants only the indicators gets them in a form that is quick to search and awkward to trust.

How the file names encode campaigns, dates and vulnerabilities

With no schema document, the file names are the index, and they are surprisingly informative. The naming patterns fall into a few families. Some files carry a date and a campaign, for example entries prefixed with 2023 and 2024 and 2025 that name ColdFusion ransomware, Akira followup, the ScreenConnect payloads and the Lumma Stealer, and one file dated 2608 that appears to be a case study set. Some carry a CVE identifier instead of a date, which is the clearest case because a vulnerability number is a stable key, and the listing includes Citrix CVE-2023-3519 attacks, CVE-2022-3236 indicators, CVE-2022-26134 attacks, the 2023 CVE-2023-40044 wsftp ransomware, CVE-2018-0798 RTFs and the Pacific Rim series built around CVE-2020-15069. Some carry a technique, such as the Follina CVE-2022-30190 hashes, DLL sideloading with PlugX and a USB worm, 3proxy and MoDi backdoors, and a file named after reflective injection. And a few are explicitly follow-ups, which is a useful signal that the collection is updated after the first report rather than frozen at publication. A handful of names carry a platform, which is how the mobile threat material is separated out.

Campaign families, series naming and the mobile material

One family of names deserves a closer look because it shows how a long running operation is tracked. The listing contains a series of Pacific Rim files, each naming a different component of the same activity: Asnarok, Covert Channels, the Cyberoam account indicators, Defending Forward, Personal Panda and Under The Radar. That pattern, several files sharing a prefix and differing by a codename, is how a vendor publishes successive reports about one intrusion set, and it means the collection is closer to a case file than to a flat list. It also means a search that matches on one codename can miss the related files, so the right way to use this repository is to look for the family, not just the exact file. The second pattern worth noticing is how the collection spans consumer and mobile threats, with entries for Android spyware, a fake antivirus, a fake app, Android package chat abuse, HiddAd, a cryptorom fake apps set, a ColdFusion and Citrix set, and quishing and image spam for email and web phishing, alongside traditional endpoint campaigns. The two ends of that range, a commodity fake app and a named intrusion set, are served by the same mechanism, which is the point of an archive like this.

CSV without a schema, and what that costs you

The format choice is where the practical cost sits. Every file is a CSV, which is the right choice for diffing, for loading into a spreadsheet, and for grepping from a shell, but a CSV is only a container and not a contract. There is no schema documentation in the README, and the top level listing shows no schema file, and no statement that every file shares the same columns, so the column layout of a given file is something you have to establish yourself by opening it. The listing shows how varied the sources are, with files named after ransomware families, after vulnerabilities, after marketing artefacts, after a security vendor's own report titles and after tools such as 3proxy, and the people who produced them used whatever columns the analysis produced, so an indicator might be a hash, a domain, an IP address, a URL, a file path, a mutex, a registry key or a user agent. If your pipeline expects a fixed table, you are writing the normalisation step yourself, and the metadata that tells you which is which is not in the repository either. The repository's language tag is YARA, so the project is tagged as publishing detection rules alongside the data, and the top level listing includes entries whose names end without a .csv extension, which is consistent with rule files sitting next to the CSV data. That is a useful distinction to keep in mind, because a YARA rule and a row in a CSV need different ingestion paths.

Searching the archive against the published report

The alternative to this collection is the source it came from: the published Sophos report itself, and the vendor's own feeds and portals. The difference in approach is about context, not about volume. A report tells you which indicators the analysts trusted, why, with what confidence and against what false positive caveats, and it tells you the story that makes the indicators meaningful. A CSV gives you the values and nothing else. For a one-off investigation, reading the report is usually faster, because you need the context anyway before you decide whether a hit matters. For a bulk task, such as running a retrospective sweep across every campaign in the archive, or feeding the values into a pipeline that checks many of your hosts at once, the collection is what you want, and the context becomes a later step per hit. The honest way to combine them is to treat the archive as a candidate generator and the report as the authority, which is also why the file names are so useful: the name tells you which report to go and read once a value has matched something.

A living archive with no releases and no stated licence

Two facts should shape any decision to depend on this repository. The first is that there are no GitHub releases, so there is no version to pin and no changelog to read, and the last push was on 2026-09-30, which tells you the archive is still being added to. In practice you consume it by cloning or fetching the files you need at the moment you need them, and you should record which file you used, because a CSV that is replaced in a later push will not tell you which indicators were correct at the time. The second is the licence, which is listed as unknown, with a custom licence that GitHub could not classify. That is a genuine constraint for anyone who wants to republish the indicators, feed them into a commercial service, or ship them inside a product, because the repository itself is the compiled output of published research and the terms of that research sit in the reports rather than in this repository. Neither fact makes the collection less useful, but both mean it should be treated as a reference to copy from and attribute, not as a dependency to vendor. The practical summary is simple: take the values, cite the report, and check the terms yourself.

Editorial conclusion

Adopt the Sophos IoCs collection if your detection work includes retrospective searching over campaigns Sophos has already written up, and if you can parse heterogeneous CSV files yourself. It does not fit a pipeline that needs a stable schema, a documented field format or a machine readable licence, because the repository is a flat folder of files with inconsistent naming and no releases to pin. Before you build on it, open a representative CSV from each source you plan to use and record its column layout yourself, and check the licence position before redistributing any of the indicators, since the repository's licence is listed as unknown.

Frequently asked questions

Official sources

1. Issues
2. README
3. sophoslabs/IoCs on GitHub