Signals · Threat intelligence

They didn't break in. They logged in.

Infostealers and hijacked developer accounts show that attackers increasingly use valid sessions rather than exploits. Here is what UK and Dutch leaders should check now.

By Gouresh Kamble, Amon Dîn · 19 October 2026 · 5 min read

Most boards still picture a cyber attack as someone forcing a door. The past fortnight has been a reminder that, more often, the attacker simply has a key.

Between 8 and 12 October, the long-running GhostAction campaign compromised the GitHub accounts of about 1,900 developers and used them to target more than 30,000 repositories, according to GitGuardian. Every malicious change was committed under the victim's own identity. The Hacker News reports that the most likely source of that access was leaked access tokens from infostealer logs or credential dumps. The workflows were dressed up as a "security audit". Their actual job was to collect cloud keys, deployment credentials and AI service API keys.

At the same time, researchers have been tracking what infostealer malware now collects. Symantec reported on 15 October that the Aoki stealer has recently added credential and session files for AI coding assistants to the usual haul of browser passwords and password-manager data. Barracuda describes the same shift: stealers now take whole browser identities, including session cookies and tokens, and stolen sessions can blunt the protection multi-factor authentication provides.

Why this matters to UK and Dutch organisations

None of this needs a vulnerability in your systems. It needs one laptop, often a personal or contractor device, to run a fake download or a fake CAPTCHA. The stolen session then works from anywhere, and to your logs it looks like a normal, authenticated user.

The regulatory picture is moving in the same direction on both sides of the North Sea. In the Netherlands, the Cyberbeveiligingswet has been in force since 15 August, bringing NIS2 duties of care, incident reporting and management accountability to many more organisations. In the UK, the Cyber Security and Resilience Bill reaches Report stage in the House of Lords on 26 October. As Hill Dickinson summarises, it would bring managed service providers and data centres into scope and expect an initial incident notification within 24 hours.

Both regimes assume you can tell, quickly, when something has gone wrong. With an attacker who logs in rather than breaks in, that is precisely the hard part.

The question is no longer whether your passwords are strong. It is whether you would notice someone else using a valid session.

What good looks like

The UK NCSC's guidance on identifying suspicious credential usage starts in a sensible place: know what normal looks like for your important accounts, such as usual locations, working hours and devices, so that the abnormal stands out. From there, a few disciplines make the biggest difference.

Treat sessions and tokens as credentials. Resetting a password does not always end an active session. Your incident playbook should revoke sessions and refresh tokens, not just change passwords.

Shorten the life of secrets. Long-lived personal access tokens, API keys sitting in code repositories and old deployment credentials are exactly what GhostAction went looking for, including in deleted Git history. Rotate them, scope them narrowly and prefer short-lived credentials.

Bring AI tools into scope. AI coding assistants and agents now hold keys to source code, cloud accounts and data. Their tokens deserve the same inventory, rotation and monitoring as any administrator's.

Watch for your organisation in stolen data. Infostealer logs and credential dumps are traded openly in criminal markets. Monitoring for your domains and staff in that data often gives the earliest warning that a session is in someone else's hands.

Include suppliers and personal devices. Many infections start on devices you do not manage. Ask your managed service providers how they protect the sessions they use to reach your systems, and limit what an unmanaged device can access.

Five questions for your next leadership meeting

Could we revoke every active session for a compromised user within an hour, including on cloud, email and developer platforms?
Do we know how many long-lived tokens and API keys exist in our code repositories and pipelines, and who owns them?
Which AI tools have access to our code, cloud or data, and are their credentials inventoried and rotated?
Would we learn that a member of staff's credentials were in an infostealer log from our own monitoring, or from a third party?
If this happened on a Friday evening, could we meet a 24-hour reporting duty under the Cyberbeveiligingswet or the coming UK regime?

If any of those answers is "we're not sure", that is the signal worth acting on first.

Sources

← All Signals