Authors: Yun Zheng Hu

Introduction

Today Fox-IT is publicly releasing its full Cobalt Strike Beacon Corpus, containing 56,843 raw beacons and their parsed configurations, from 190,182 sightings collected from 30,604 unique IP addresses running a Team Server (the Cobalt Strike command-and-control server that beacons connect back to) between 4 July 2018 and 29 September 2026, over eight years of beacon data. The corpus is available on Hugging Face: https://huggingface.co/datasets/fox-srt/cobaltstrike-beacon-corpus

Back in March 2022 we published Mining Data from Cobalt Strike Beacons. That post covered 128,340 beacon sightings collected from July 2018 to February 2022, and it introduced our Python project dissect.cobaltstrike for parsing them.

Since then, public scanning for Team Servers has become routine, and Cobalt Strike has shipped versions 4.6 through 4.13. Researchers have regularly asked us for an updated dataset. And here it is, a large, consistent, long-running dataset for the infosec community to build on. The corpus includes the raw beacon payloads, not just our parsed output, so anyone can reproduce our results or improve on them.

We also see publishing this corpus as an act of preservation. C2 infrastructure is short-lived, as the median Team Server is reachable for just 14 days, and the beacons it serves vanish with it. Eight years of collection captures things that can no longer be observed today, like the waves of cracked 4.0 builds or the adoption of leaked versions. By publishing the raw beacons alongside the parsed data, we keep that record available for anyone to study, long after the servers themselves are gone.

What’s in the corpus

The corpus is published on Hugging Face as two Parquet files:

All beacons were downloaded directly from internet-facing Team Servers, mostly on TCP ports 80 and 443 (HTTP and HTTPS) and UDP port 53 (DNS), with a small number on other ports. We deliberately didn’t include samples from other sources such as VirusTotal, so the corpus reflects the Cobalt Strike landscape as it was visible on the internet.

How we collected it

The collection method matches our 2022 post. We fingerprint likely Team Servers on the internet, then request a beacon payload from each one using a URI that passes Cobalt Strike’s checksum8 check. Every beacon that comes back is parsed with dissect.cobaltstrike, which decodes the configuration block. The result is stored as a sighting.

• Discovery: candidate hosts from our own internet-wide scanning. As in 2022, we’re keeping our fingerprints private so they stay effective; writing your own is left as an exercise for the reader.
• Download: x86 beacons over HTTP(S) and DNS.
• DNS: for DNS listeners we’re not publishing that fingerprint either, but it’s not rocket science. The beacon is fetched as a series of TXT record lookups sent over UDP port 53 directly to the Team Server’s DNS listener.
• Parse: Use dissect.cobaltstrike to parse the beacon and export the configuration
• Enrich: TLS certificate data captured at collection time (where available) and GeoIP/ASN via historical GeoIP databases.

Note that there might be some small gaps in the collection due to automation issues that we did not catch in time.

Getting started

Most research only needs the beacons.parquet dataset. The payloads.parquet dataset containing raw beacon payloads is only required if you want to re-parse the beacons or look into the ones that failed parsing.

I’m a big fan of DuckDB (and SQLite), and over time I’ve become fond of SQL for querying data as well. DuckDB is very fast, and AI assistants are very good at writing SQL queries. These days, that beats hand-writing pandas code and the matching matplotlib charts. That’s why I recommend exploring the data with DuckDB, for example in a Jupyter notebook.

An example of using DuckDB to query the dataset on Hugging Face directly:

SELECT watermark,
       count(*)                          AS sightings,
       count(DISTINCT collected_from_ip) AS servers,
       min(collected_on)                 AS first_seen,
       max(collected_on)                 AS last_seen
FROM 'hf://datasets/fox-srt/cobaltstrike-beacon-corpus/data/beacons.parquet'
GROUP BY watermark
ORDER BY sightings DESC
LIMIT 20;

Take a look at our Jupyter notebook in the Hugging Face repository as a starting point. It contains every query and chart from the sections below, so you can rerun them or adapt them to your own research questions.

A first look at the data

Here are a few quick results to show what the corpus can answer. They’re a starting point, not a full analysis. As with our 2022 post, we invite researchers to explore the data; see also “Research ideas” below.

Old versions never die

Each Cobalt Strike release takes over from the last, but old versions linger. Cobalt Strike 4.0 dominated most of 2020, 4.1–4.2 drove the early 2021 peak of about 3,000 beacons a month, 4.3–4.4 led from mid-2021 through 2022, and 4.5–4.8 took over in 2023. Since 2024, 4.9 and 4.5–4.8 have shared the lead, while 4.10+ remains a small share. Volume has since dropped to around 200 beacons a month, partly because fewer servers stage their beacon, which brings us to the next graph.

No beacon for you

Our collection relies on beacon staging, meaning a Team Server can serve its beacon as a downloadable payload to anyone who requests the right URI or DNS record. Operators can turn this off (the host_stage option in the Malleable C2 profile), and disabling it is common OPSEC advice. To measure how much this affects our beacon collection, we counted two numbers per month:

1. The unique Team Servers (ip:port) confirmed by our high-confidence HTTP fingerprint
2. The unique Team Servers (ip:port) that handed out a beacon over HTTP(S)

These are monthly totals, not a server-by-server match. On average, the Team Servers that handed out a beacon were only about 32% of those we fingerprinted, and that share has drifted down from around 40% in 2023 to 20–25% in 2026. In other words, because not every server hands out a beacon, the corpus shows only part of the Cobalt Strike landscape, and that part is getting smaller. Disabled beacon staging is the most likely reason, but not the only one. Servers can go offline between fingerprinting and download or block our scanners, and our fingerprint doesn’t catch every Team Server.

The dashed sections mark months when beacon collection wasn’t running, because of an automation error that went unnoticed for a while.

The short life of a Cobalt Strike Team Server

The median Team Server was reachable for 14 days. 35% were seen on a single day only, just 14% were still serving a beacon after three months, and only 2% after a year.

We identify a Team Server by its public key and C2 domains from the beacon configuration (or its IP address when the configuration contains no domains), so a server that moves to a new IP is still counted once. This allows us to measure how long a Team Server typically stays online. Identifying servers by public key alone or by ip:port gives almost the same result, a median lifetime of 14–15 days. These are first-to-last-sighting spans, so a server may have been online before our first and after our last sighting. Servers still active in the last 30 days are left out.

It’s always DNS

Most public scanning focuses only on HTTP(S) beacons, but we’ve also collected DNS beacons since 2020 (apart from the months when our automation broke). DNS beacons have declined much less steeply than HTTP(S) ones, perhaps because they get far less attention in public research and OPSEC advice, so fewer operators think to lock them down. After a peak in 2022, they have mostly hovered around 100 a month since 2024, with a median of 120 over the whole period.

Parse me if you can

The corpus also includes 128 unique beacons (0.23%) that we downloaded but couldn’t parse. Note that the corpus doesn’t contain HTML pages or other responses that were unlikely to be a beacon. We excluded those before publishing. At first glance, most are beacons with custom modifications that dissect.cobaltstrike can’t parse yet. And some payloads from the early years aren’t Cobalt Strike at all, but Metasploit Meterpreter payloads. We’ve deliberately left them in for researchers to analyse. You can find all unparsed beacons with: WHERE config_json IS NULL

The unparsed count used to be higher, but we managed to bring that down. We noticed some operators customised their beacon configs, for example by shuffling the order of the configuration settings or changing their type values, which broke our parser (and probably most others). The corpus helped us find these cases, so we made the config scanning of dissect.cobaltstrike independent of layout and added many other features and fixes along the way. See the dissect.cobaltstrike v1.3.0 release notes.

Research ideas

Some other research questions that could be answered using the corpus:

• Clustering: Group operators by config features (watermark, SPAWNTO/PROCINJ hash, C2 profile, certificate, sleep/jitter, specific beacon modifications)
• Classification: Separate red team from criminal infrastructure. Build and publish labelled subsets.
• Infrastructure: Top hosting providers that are hosting a Cobalt Strike Team Server.
• Certificates: Pivot on x509 reuse across servers and time or find how many are running the default Cobalt Strike keystore certificate.
• Benchmarks: Use the corpus as a shared test set for config extractors and ML models.
• Parser failures: 128 beacons can’t be parsed by dissect.cobaltstrike. Figure out why.

Over to you

Eight years of Cobalt Strike beacons are now one download away on Hugging Face. Run your own queries, pick up one of the research ideas above or come up with your own, dig into the beacons we couldn’t parse, and share what you find.

Before you start, read the Limitations section on the dataset card. The raw payloads are real Cobalt Strike beacons, so handle them like any other malware sample.

Introduction

When a company that manages data for millions of UK citizens falls victim to ransomware, the whole industry should pay attention to it. On 15 October 2025, the UK Information Commissioner’s Office (ICO) published a detailed 136 page report about the Capita breach. 

The aim of this blog is to extract actionable cybersecurity lessons from the ICO’s findings as well as open source reports surrounding the breach from a cyber threat intelligence (CTI) analyst’s perspective to help SOC and CERT teams, and CISOs understand what happened and how to avoid the mistakes made by others.

BLUF Incident Impact Summary:

• Capita was attacked by BlackBasta ransomware in March 2023
• Over six million individual’s records were exfiltrated from Capita’s systems
• A £14 million fine was issued to Capita by the ICO
• Capita said in May 2023, the incident cost up to £20 million to recover

Important context about Capita

The Capita Group is a business process outsourcing (BPO) and professional services group employing approximately 34,500 people worldwide and with a reported annual revenue of £2,421.6 million. For readers outside of Great Britain, Capita is best known as the UK’s go-to managed service provider for large-scale, data-sensitive public sector operations.

Companies within the Capita Group act as data processors for a range of business services to both public and private sector organisations. Capita plc is the ultimate parent company of a large corporate group consisting of multiple legal entities.

Capita has long been one of the UK government’s biggest suppliers of outsourced services.

They manage (or have managed):

• The BBC TV Licensing system
• The UK Congestion Charge for Transport for London (TfL) 
• The National Pupil Database – via contracts with the Department for Education.
• Electronic tagging of offenders – under contracts with the Ministry of Justice.
• Council administration and call-centre services – many local authorities (e.g., Birmingham, Southampton, Sheffield) 
• Numerous Local Government and private sector pension schemes (including universities, utilities, and insurance companies).
• Ministry of Defence (MOD) – Training and support contracts for the British Army’s Recruitment Partnership Project (including vetting systems) and Royal Navy training programmes.

The ICO established that during the Incident, data was exfiltrated from two legal entities which were acting as data controllers, and from four legal entities which were acting as data processors:

• Capita plc - Capita plc’s focus includes Central Government, Local Public Service, Defence, Education, and Pensions. Capita was selected to administer the UK’s Civil Service Pension Scheme (CSPS) from September 2025, via a contract worth £239m over 10 years.
• Capita Resourcing Limited - is a subsidiary of Capita plc focused on resourcing/human-capital services, i.e., recruitment, contingent staffing, talent acquisition.
• Capita Business Services Limited - is another subsidiary that provides business-process and digital services (as a part of the Capita outsourcing ecosystem). The supplier record shows over £331.9m recorded government spending linked to this entity.
• Capita Pension Solutions Ltd (CPSL) - a regulated pensions business within the Capita Group. Its role: delivering pensions administration and consulting services for pension schemes, including defined benefit schemes.

Breach Timeline

In the ICO’s report, a timeline of events that led to data exfiltration and ransomware deployment was provided. The timeline diagram below helps illustrate what happened.

TheRecord also reported that Capita’s share price dropped more than 12% from a high of £38.64 ($47.97) on March 30, the day before the incident was first reported, to £33.72 ($42.58) on Wednesday morning.

On 3 April 2023, Capita released a public statement about the cyber incident. At the time, Capita said the “issue was limited to parts of the Capita network and there is no evidence of customer, supplier or colleague data having been compromised.” 

On 8 April 2023, Brett Callow spotted that Capita had been listed on BlackBasta’s Tor data leak site before it was quickly removed that same day.

Security researcher Kevin Beaumont who analysed the leaked data samples at the time identified copies of stolen passport scans, PII records, bank account details, internal floor plans of multiple buildings from various schools as well as Capita Nuclear, part of Capita Business Services.

It took Capita until 20 April 2023 to confirm that some of its systems were in fact breached and that data had been stolen.

Types of Stolen Data

In the ICO’s report, we learn that 6,024,221 data subjects for whom Capita was the data processor had personal data exfiltrated, as determined by Capita’s forensic provider.

Types of data stolen included sensitive such as Home Address, Email, Phone Number, National Insurance Numbers, Driver’s License Scans, Passport Scans, Bank Account Numbers & Sort Codes, Credit Card Numbers, Biometrics, Criminal Record Checks, and Employee Login details.

BlackBasta Operator TTPs

The tactics, techniques, and procedures (TTPs) of the BlackBasta operators provided in the breach timeline by the ICO are useful for understanding what technical steps were involved that led to the breach and ransomware attack. A summary of the aspects of the attack have been mapped to a diamond model diagram below.

Outside of the breach timeline, some additional technical details were shared:

• Following initial access, the Threat Actor accessed the ‘CAPITA\backupadmin’ service account approximately 4.5 hours later. Capita could not confirm how the Threat Actor was able to escalate their privileges; however, there were traces of Kerberos credential harvesting and reconnaissance activity found following the Incident.
• The Threat Actor was able to use the ‘CAPITA\backupadmin’ domain administrator account to pivot to administrator accounts in different Capita domains. In total no fewer than 8 domains were compromised, a very large quantity of data was exfiltrated and the Threat Actor attempted to deploy ransomware on at least 1057 hosts.
• Even though Capita quarantined the device through which the Threat Actor first gained access on 24 March 2023, by this time the Threat Actor had deployed software into the network which had enabled them to establish persistence and ultimately allowed them to continue moving laterally across the network into different Capita domains and to access/exfiltrate data, before deploying ransomware on 31 March 2023.

The domain "corpcitrix.ad.capita.co.uk" appears to be an internal Active Directory domain name used by Capita to host its corporate Citrix environment. The "ad" label shows it’s an AD DNS namespace, "corpcitrix" indicates the environment is for Citrix-published desktops/apps or related infrastructure, and "capita.co.uk" is the organisation’s FQDN.

The command shown above is a PowerShell invocation (potentially via Cobalt Strike) to enumerate every system in the domain, resolve each machine’s IP address, and save the results to “SFS_pc.txt” file. Powerpick runs the code in an unmanaged PowerShell environment and can execute without being dependent on powershell.exe.

In short, this command shows a BlackBasta operator running net reconnaissance mapping hosts and IPs (likely to plan lateral movement, targeting, exfiltration or ransomware deployment).

Notable moments during the Incident

• Critical alerts were mishandled or deprioritised: The initial malicious file (‘jdmb.js’) triggered a P2 (High) alert at 08:00 on 22 March 2023, indicating compromise. The SOC did not act for nearly 58 hours, despite automatic escalation warnings for missed service-level agreements (SLAs). The ICO also noted that “at no point in the six months before or after the Incident did Capita meet their SLA for any alert level.”
• Excessive delay between detection and containment, plus a lack of automation: Isolation of the device from the rest of the Capita network still required human intervention, which took 58 hours to arrive. Capita’s SOC lacked the ability to isolate the device automatically. By then, the attacker had already gained domain admin access and moved laterally.
• Inadequate incident response procedures: Capita did not invoke its Major Incident Management process until 09:22 on 29 March 2023, which was seven days after compromise. By that point, data exfiltration was already underway and it was two days before ransomware was deployed on 31 March 2023.
• Understaffed and overburdened SOC team: Capita is understood to have had 1 SOC analyst per shift in place at the time of the Incident in March 2023. This combined with historic underperformance indicates systemic issues within the SOC, including inadequate staffing, insufficient training, and/or inefficient processes.

Lessons Learned from the BlackBasta Ransomware Attack on Capita

• Having tools isn’t enough, they must be configured, integrated, and monitored effectively
• Capita had Trellix EDR, a SIEM, and a SOC, but alerts were missed and containment delayed.
• Lessons: Security tools are only as effective as the people, processes, and automation supporting them. Critical security alerts must have clear, measurable response times with automatic escalation if breached. Security Leadership must define and enforce strong Service Level Agreements (SLAs) for incident response.
• Implement proper Active Directory (AD) tiering
• Lack of AD tiering allowed attackers to move laterally from low-privilege systems to domain controllers (specifically a backup service account with domain admin privileges).
• Lessons: Segregate admin privileges between tiers (workstations, servers, domain controllers) to contain breaches. Limit, rotate, and monitor privileged accounts using a PAM solution to enforce least privilege. Regularly review service accounts, ensure unique credentials, and monitor their activity for anomalies.
• Act on penetration test findings promptly
• Multiple pentests also warned of AD and privilege issues months before the breach, but fixes were delayed.
• Lesson: Treat pentest reports as actionable tasks with deadlines and executive oversight.
• Automate incident response where possible (SOAR)
• Lack of Security Orchestration, Automation and Response (SOAR) led to manual triage delays.
• Lesson: Use SOAR playbooks to automate containment, escalation, and alert enrichment for faster response.

Additional Resources

1. Qakbot - https://attack.mitre.org/software/S0650/
2. Cobalt Strike - https://attack.mitre.org/software/S0154/ 
3. Bloodhound - https://attack.mitre.org/software/S0521/ 
4. Rclone - https://attack.mitre.org/software/S1040/ 
5. SystemBC - https://malpedia.caad.fkie.fraunhofer.de/details/win.systembc   
6. BlackBasta Ransomware - https://malpedia.caad.fkie.fraunhofer.de/details/win.blackbasta 
7. Credentials from Web Browsers (specifically performed by Qakbot) - https://attack.mitre.org/techniques/T1555/003/
8. Steal or Forge Kerberos Tickets - https://attack.mitre.org/techniques/T1558/ 
9. Exfiltration Over C2 Channel (performed by SystemBC and Rclone) - https://attack.mitre.org/techniques/T1041/
10. BlackBasta Leaks: Lessons from the Ascension Health attack - https://blog.bushidotoken.net/2025/02/blackbasta-leaks-lessons-from-ascension.html 
11. The Continuity of Conti - https://blog.bushidotoken.net/2022/11/the-continuity-of-conti.html 
12. BlackBasta Group Profile (Ransomware Tool Matrix) - https://github.com/BushidoUK/Ransomware-Tool-Matrix/blob/main/GroupProfiles/BlackBasta.md 
13. BlackBasta Group Profile (Ransomware Vuln Matrix) - https://github.com/BushidoUK/Ransomware-Vulnerability-Matrix/blob/main/GroupProfiles/BlackBasta.md