The Manchester Airports Group (MAG) breach caused a fair amount of noise in the UK. MAG confirmed that data relating to around 8.7 million people had been affected, including information associated with airport parking, lounges, Fast Track bookings and Wi-Fi registrations.
FulcrumSec claimed the route in was three iterable admin keys embedded in the frontend JavaScript of the Manchester, Stansted and East Midlands airport websites.
This specific incident first came to light publicly in late August 2026. However, MAG wasn't the first FulcrumSec incident I'd looked into. A few of their previous breaches had already cropped up on my radar and I'd always found their approach interesting because it was a little different to many of the incidents we normally hear about.
So this new MAG incident became the trigger for me to go back through more of their previous work, and the more I looked, the more commonality there seemed to be. That left me with a bunch of questions, so I reached out to FulcrumSec directly... who kindly responded!
The remainder of this post is a combination of me summarising past FulcrumSec breaches enriched with insight directly from FulcrumSec on their activities. It's put together with the intent of better informing defenders about real adversarial tradecraft in order to enable better defences.
It's not possible to independently verify every claim they make about their intrusions, or everything they told me privately, but I've viewed a lot of data lifted by FulcrumSec and everything I've been able to verify so far has appeared authentic. Scott Helme also independently verified the keys-in-JavaScript claims from the MAG incident and found it to be a legitimate claim. There is always two sides to a story and, whilst I don't condone it their activities, I believe we can take a good level of confidence in the authenticity of everything discussed in this post.
They don't really pick victims first
One of the first things I wanted to understand was how FulcrumSec selects its victims. Looking at the public cases, there isn't an obvious sector focus. Airports, pharmaceuticals, education, healthcare, SaaS companies and professional services have all appeared.
My assumption was that they wait for some form of initial key or token from an initial access broker and then take and work with that (much in the same way we see infostealer data used and traded in order to facilitate initial access).
What I hadn't quite expected was that FulcrumSec are not just the operator carrying out the attack, it turns out they gain their own initial access by running large-scale internet scanning infrastructure looking for exposed credentials and vulnerable systems, and then work out which organisations those exposures belong to.
At its peak, they say they had around 250 servers scanning client-side JavaScript across the corporate internet, with separate fleets looking for React hosts during React2Shell and other vulnerabilities.
That scanning produces thousands of leaked or extracted credentials, which they then enumerate in bulk to establish what they authenticate to and how much access they provide. If the organisation is sufficiently interesting and the access appears likely to lead to a wider compromise, they continue.
MAG is a good example of that model. FulcrumSec says the airport websites exposed iterable administrator credentials directly in frontend JavaScript. Arup allegedly exposed a GitHub PAT in browser-side JavaScript, and Novo Nordisk also exposed credentials in public JavaScript (in this case on development and sandbox systems).
So the victim selection appears to happen after the technical opportunity has presented itself, rather than the other way around. Clearly checking and eliminating your exposure is the single best way to not appear on their victim list.
They tell me that client side JavaScript is still the biggest source of useful credentials, but it sounds like they are constantly evolving their toolset and other sources will likely become more prevalent in time. So clearly focusing on the principles rather than the specifics of what is shared here is important for future resilience.
The first credential is often just the starting point
The next thing that became obvious going through their incidents was how often one credential simply led to another.
Arup is probably the cleanest example to share this happening:
FulcrumSec says a GitHub PAT exposed in JavaScript gave them access to roughly 10,000 private repositories. They then claim those repositories contained Azure Storage credentials, AWS keys, Azure AD client secrets, database credentials and OAuth credentials, which in turn gave them access to further cloud and database infrastructure.
Novo Nordisk followed a similar pattern. FulcrumSec say an exposed GitHub PAT provided access to more than 1,000 private repositories, which then revealed credentials for additional SaaS and cloud services.
Global Schools Group provides another variation, with FulcrumSec claiming AWS credentials were included in Angular frontend configuration, followed by access to CodeCommit repositories and 168 Secrets Manager entries.
This is a common theme in FulcrumSec's writeups - the first piece of access exposes somewhere else worth searching, which might then lead to future pivots.
FulcrumSec told me that credential enumeration is done at scale, with large numbers of leaked credentials tested to determine what they expose and which organisations they belong to.
That makes the movement between systems less like traditional lateral movement you might see when an adversary moves from endpoint to endpoint and more like following a series of pivots.
They tell me that they have scripts for every stage of their attacks, all held together by orchestration scripts, which makes sense at the scale they appear to be operating. Just plugging a token or credentials into the pipeline gives them a huge amount of intel about what access it might provide. So no doubt this plays a key role in deciding which credentials to pursue further.
They intentionally stay off the endpoint
This question I was probably most interested in the answer to related to endpoint activity - across the FulcrumSec incidents I'd looked at there was comparatively little traditional endpoint activity. There wasn't much discussion of credential dumping, Cobalt Strike, PsExec, EDR bypass or Windows lateral movement; the type of thing we commonly see in incident reports. Instead, the activity was mostly GitHub, AWS, Azure, SaaS platforms, APIs, databases and cloud storage.
I asked FulcrumSec whether that was intentional.
They said it was initially a deliberate decision because they didn't want the additional work involved in endpoint detection and evasion. They then realised that endpoint compromise was often unnecessary anyway.
To quote them:
“Why bother with endpoints at all if a company's best data is in the cloud?”
They pointed out that companies frequently back up huge amounts of information into cloud storage, including mail, database backups and source code. In some cases, compromising an AWS or GCP environment gives them access to several different classes of company data without needing to compromise each underlying service individually.
That explains quite a lot of the tradecraft in their public write-ups.
LexisNexis is a useful example. FulcrumSec says React2Shell gave them execution inside an AWS ECS workload and temporary AWS role credentials. Those credentials reportedly had broad access to both Secrets Manager and large amounts of storage, meaning they didn't need much additional lateral movement before they could start exfiltrating data at scale.
Hatica shows another route. FulcrumSec says a GitHub token exposed 75 private repositories which ultimately led to a legacy database containing thousands of Slack bot tokens belonging to customers.
The endpoint simply wasn't necessary in either case.
What gives them away?
Staying in cloud and SaaS doesn't, or rather shouldn't, make an adversary invisible. But something that stands out across several FulcrumSec write-ups is the volume of access they obtain. Cloning thousands of repositories or downloading terabytes of cloud data should make a lot of noise.
Whilst FulcrumSec says Arup eventually detected some of its GitHub and Azure Storage activity, and Novo Nordisk reportedly identified different parts of its access at different times. It sounds like this is not typically the case.
I suspect the logs exist in many environments, it's just really whether anyone has enough context to recognise the activity in the logs as abnormal, or whether the logs are actually being proactively monitored.
A service identity suddenly accessing resources it has never touched before, from infrastructure it has never appeared from, at substantially greater volume than normal is potentially useful behaviour for a defender to detect. But that requires some understanding of what normal looks like for that identity - and this understanding is not something generic security solutions are set up to detect. These type of detections require context and an understanding of system or process being defended which no security tooling will ever have by default.
FulcrumSec tell me
"Companies are sadly terrible at cloud detection".
They tell me that they can typically walk away with huge quantities of data without being detected, and can count on one hand the number of times that they have been caught prior to exfiltrating enough data to be extremely impactful.
They tell me that:
“Even orgs that seem to have decent visibility into their AWS environment, for example, will leave their Azure Storage completely unwatched. Or their Databricks unity catalog, or their Snowflake DBs, or GCP bukets...”
In our conversations FulcrumSec made the point that companies should watch for mass enumeration of cloud credentials, sharing a level of disbelief that this doesn't get their access killed more often.
They also shared a hat tip to Sysdig and an article that they had posted on how to block them, which is no doubt worth a read if you're interested in defending against this adversary.
I think my key takeaway here was that we've reached a level of maturity when it comes to securing the endpoint, that level of maturity probably hasn't translated to SaaS and other similar hosted platforms, despite them often being repositories for highly sensitive data.
There are more breaches
There are currently 23 distinct incident write-ups on FulcrumSec's site, but I was curious to know if there were more, or whether they'd just selected the more interesting ones to write up.
According to FulcrumSec the public site contains organisations where they failed to reach an agreement, and that “far more companies pay than do not.” Although they didn't provide exact number.
They also said they don't pursue extortion where the data isn't sufficiently damaging or where they don't believe the organisation could afford their price.
There's no way to independently verify other victims, particularly because the organisations that pay are exactly the ones that don't get published publicly. But it does mean the public list should probably not be treated as a complete view of their activity. Although the techniques remain common across the board.
Why do they spend so much time in the data?
Another thing I'd noticed in their write-ups is how much effort FulcrumSec appears to put into analysing the data they steal.
They don't simply publish a directory listing and a torrent. Their posts contain statistics, relationships, internal communications and observations pulled from inside the datasets, essentially a writeup of each incident.
Whilst I could see a financial element to their activities, it felt to me like a lot of their drive seemed to be the thrill of the hack.
When I asked about this, they said they are primarily financially motivated, but also that they enjoy doing this and enjoy analysing the data they obtain.
They also frame their recent “Hardcoded Horrorshow” work as demonstrating basic security failures at large companies rather than relying on zero-days against well-defended organisations. That's obviously their own justification for what they're doing, but it does explain some of the tone and level of detail in their write-ups.
Do they ever go back?
Finally, I wondered whether they ever checked whether companies had actually fixed the problems they found. FulcrumSec are definitely more verbose than most at sharing the initial access vectors, so I was curious to know whether they wait for that to be closed off before they publish their writeup.
FulcrumSec said that where they make what they describe as responsible disclosures, they do check that credentials have been rotated, vulnerabilities patched or the original issue otherwise resolved.
Companies that pay are subsequently considered off limits, although they say their automated scanning has occasionally rediscovered exposures at those organisations and they have notified them.
For organisations that don't pay, they say they don't go back and compromise them again: "We don't like to dwell on the past, and we'd rather not be vindictive about it -- they [the victim] faced the consequences already"
That's their stated policy rather than something we can independently verify, but it was an interesting answer.
What I took from it
MAG was what put FulcrumSec in front of a much wider UK audience, but it looks like a single example of a model they've been using for some time.
The interesting bit for me wasn't the specific credential that MAG exposed, but rather how they have industrialised finding those mistakes and then following the access wherever it leads.
The first credential might expose customer data directly. It might expose 10,000 GitHub repositories. It might land them inside AWS. It might simply reveal another credential.
From there they keep following those pivots, often without needing to touch an endpoint at all. Ultimately this was the thing that I found interesting about FulcrumSec's activity - the cloud and SaaS pivots rather than working their way through different endpoints. In their own words:
“Why bother with endpoints at all if a company's best data is in the cloud?”
As Lab539 is a company that crafts tailored defences for organisations, it's somewhat natural that one of my takeaways is that too many organisations still really don't understand the threats that face them and rely too heavily on generic security tooling, without enough understanding of what is normal in their own environment.
A lot of FulcrumSec's activity is technically legitimate: valid tokens, API keys and cloud identities being used for the things they were designed to do. There is often no malware, payload, or endpoint activity to detect.
Obviously auditing for over-permissioned cloud identities and exposed API keys is an essential defensive control. But I believe another extremely important factor here is applying context to an environment. A PAT cloning repositories is normal; cloning thousands from unfamiliar infrastructure probably isn't. An application reading a secret is normal; enumerating dozens of unrelated secrets probably isn't. Scripts are noisy when operating at scale and defences need to be better at identifying and operating on that noise.
This kind of detection has to be tailored to the environment. Generic tooling can provide the telemetry and does provide the functionality to implement exactly these type of detection. But it requires someone has to tell it what “normal” (or "abnormal") looks like, it needs some tailoring to the business operations, otherwise nothing will be detected.