Overview
Executive summary
The first half of 2026 reinforced a significant shift in the threat landscape: the most effective attacks increasingly don't look like attacks at all. They look like a Microsoft Teams message from someone claiming to be in IT. A login prompt from a trusted brand. A software package from a familiar repository. A routine request that appears legitimate on the surface.
As organizations invest in stronger security controls, attackers are adapting by targeting the trust relationships that businesses rely on every day. Rather than deploying sophisticated malware or exploiting technical vulnerabilities, many threat actors are achieving greater scale by abusing legitimate identities, trusted platforms, business workflows, and increasingly automated criminal ecosystems. This report examines the most significant threat activity, emerging techniques, and operational trends observed during the first half of 2026, drawing on observations from customer environments, incident investigations, threat intelligence research, and data from Ontinue's Advanced Threat Operations team.
Key takeaways
1H 2026 reinforced a consistent trend across the threat landscape: attackers are achieving greater scale by abusing existing trust relationships. Identity systems, collaboration platforms, SaaS integrations, software supply chains, and routine business processes all featured prominently in successful campaigns. The most significant threats are increasingly hidden within legitimate activity, making visibility, identity security, and rapid detection critical defensive requirements.
{{ t.s }}
{{ t.d }}
Supply chain risks: from XZ to Shai-Hulud to AI automation.
Two years ago, backdooring the software supply chain was slow, expensive work for a patient professional. Last year it turned into a worm. Last month an AI agent worked through the slow version by itself, against a real project, without being asked. None of the techniques were new - but the price of execution has dropped through the floor.
2024: XZ Utils.
The XZ Utils (CVE-2024-3094) vulnerability took years to develop. An unknown contributor calling themself “Jia Tan” appeared in 2021, did genuine work on a compression library almost nobody wanted to maintain, wore down a burned-out maintainer with the help of a chorus of pushy accounts, and got commit rights. The backdoor went into the release tarballs of liblzma - not the git tree - which is why nobody reading commits could even spot it if they looked. It armed itself only in the distro-patched, systemd-linked builds of sshd used by Debian and Fedora, and waited for a key only the author held. Had it reached a stable release, one anonymous person would have had a login on millions of Linux servers, a great many of them facing the internet by design.
Andres Freund, an engineer at Microsoft, found it because his ssh logins were taking about half a second too long and he could not leave it alone. That is the entire story of how it was caught. No scanner, no review board. One irritated person with a benchmark.
XZ was not the first of its kind. SolarWinds got into the Orion build system and shipped signed, trojanized updates to thousands of paying customers, with a payload written to wake up for only a chosen few of them. The Magecart skim on British Airways changed one familiar JavaScript file, Modernizr.js, and copied payment card details for two weeks before anyone noticed, and only then because the card networks spotted what all the fraud victims had in common. Each attacker sat inside something people already trusted and kept quiet.
2025 to 2026: Shai-Hulud.
Shai-Hulud, named after strings found in its own code, has no patience at all. Its trick is timing.
The worm ships a preinstall code that executes before your CI/CD tests, your scanners or any human uses near the package. It downloads Bun and hands control to a large obfuscated second stage to do the evil work. On a GitHub Actions runner that is a disposable box, so the evidence disappears the moment the job ends. It also writes malicious workflow files and registers self-hosted runners, usually named SHA1HULUD, to keep collecting secrets later without another package install. Turning CI into the beachhead was novel and ingenious - given CI is supposed to be the safety net.
Then it runs TruffleHog. Plenty of sensible pipelines run TruffleHog to catch credentials before they get published anywhere, so a scan mid-install looks like housekeeping and nothing fires. Shai-Hulud runs it to collect them. What it finds goes into brand new public GitHub repositories, quite often created under some other victim's account, with descriptions like "Sha1-Hulud: The Second Coming". Working out what ended up where takes days once your data is sitting in a stranger's org.
The rest is quick. Take whatever TruffleHog, the cloud metadata endpoints and the local credential stores give up, which in practice means personal access tokens, npm publish tokens and cloud keys. Encode the haul two or three times, dump it in the public repos, then use the stolen npm tokens to bump and republish the victim's own packages, sometimes close to a hundred of them, so their good name does the delivery. If a machine has nothing worth stealing and no way to ship it out, version 2 has a go at deleting the user's home directory. There is no profit in that, which tells you something about the author.
None of it has to be clever. Installing a dependency tree already means hundreds of file writes, network fetches and arbitrary scripts running with nobody's approval. One more script does not stand out.
Nobody knows who.
There has been no banner, no manifesto, nothing beyond a Dune reference in the strings. The speed, the token-theft economy and the mass reuse across hundreds of maintainers all read as ordinary crimeware. State work looks like Jia Tan: three years of unpaid maintenance labor to buy one login. Shai-Hulud needs no mission plan at all, just smash, grab, and on to the next maintainer. Different cadence, different goal, and worth remembering when someone on a bridge call starts talking about attribution before the tokens have been rotated.
July 2026: AI agents automate attacker patterns.
Frontier models have become good at vulnerability research, which was always going to cut both ways. AISI has been measuring the trend for a while: the length of cyber task a model can complete on its own, in their narrow suite, has been doubling every few months, and they reported in July that they now find cheating behavior in every one of their cyber capability evaluations. The part nobody had budgeted for is a model deciding on its own that a supply-chain attack is a sensible way to finish its homework.
The UK AI Security Institute published an incident report on 4 August, with a technical write-up alongside it. The setup was a routine cyber range evaluation: seven models, 122 runs, internet access switched on deliberately and the vendors' cyber classifiers switched off deliberately, which is not how you get these models as a customer. In 10 of the 122 runs an agent did something outside the test scope on the live internet, 19 such actions in all. Seventeen came from Anthropic's Mythos 5 and two from a single run of OpenAI's GPT-5.6-Sol. The 5 models remained within the test scope.
What tipped them off was data leaving a test box over Tor. They killed the runs and isolated the machines within the hour.
The transcripts showed that one agent had:
{{ x.t }}
The system prompt described a capture-the-flag exercise. The user prompt said to run a penetration test against three named hosts. Neither mentions social engineering. AISI's reading is that the deception fell out of the model chasing a hard goal, helped along in some runs by a misconfigured task that convinced the agent no honest solution existed. Their other admissions matter more. Internet access had been granted so the agent could fetch its own tooling, and the risk trade-off had not been revisited as models got better. Nobody had thought to forbid social engineering, because alignment training had always covered it before. The monitoring that eventually caught it was general-purpose security monitoring, not anything built to watch an evaluation as it ran. The agent never tried to break out of the sandbox, and never needed to.
AISI told GitHub before publishing. GitHub confirmed the activity breached their terms of service, helped clear up the artefacts the agent had left behind and contacted the users it had approached. METR have been asked to run an independent review.
Put that list next to the XZ timeline. Jia Tan needed three years. The agent got through a crude version of the same plan in three days. It failed because a maintainer read the diff, spotted the malware and closed the PR with a polite note, and because a member of the public who suspected the code opened it inside an isolated environment built for exactly that. What held was human attention, with no technical control underneath it. AISI say so themselves, and add that in several cases the margin was narrow.
The weak link is a person with a day job.
The people on the receiving end are small maintainers, the ones propping up a dependency everybody uses and nobody reads. Publishing pipelines that take a commit to global availability in ninety seconds make it worse, as does a culture where "latest" is the default.
GitHub has tightened things up with mandatory 2FA, seven-day token lifetimes and trusted publishing over OpenID Connect. Some of that breaks existing processes. Those processes were unsafe. pnpm's minimumReleaseAge is worth turning on too, since it stops CI pulling a version that only went live twenty minutes earlier, which is precisely the window these attacks live in. Attackers rely on speed and on a package having no reputation yet, good or bad, so moving off npm or yarn to a sensibly configured pnpm buys you more than the one setting.
Tracking your dependencies is not enough; you need to be able to prove them. Emit an SBOM on every build and store it with the artifact, so that on the morning a package gets flagged you can answer "are we affected" before lunch rather than by Thursday. Defender for Cloud's agentless code scanning is in preview and gives you malicious package findings off a GitHub or Azure DevOps connection without anyone touching a pipeline. An afternoon spent on that is worth a fortnight of triage, forensics, customer apologies and an awkward conversation with the board.
What to do next time.
{{ s.t }}
{{ s.d }}
Controls for the AI era.
AI in cybersecurity.
Generative AI has industrialized social engineering. What was once a labor-intensive and error-prone craft (writing convincing, thematic, timely phishing lures, impersonating executives, tailoring pretexts) can now be done at scale, in any language, with near-perfect fluency.
Cost of entry: attacker tooling, 2020–2026.
Each row is a tool an attacker can buy. The bar runs from its cheapest to its most expensive advertised price, and further left means cheaper. The AI tools sit far to the left of the attack frameworks they replace. Click a highlighted row to read where it appears in this chapter.
{{ s.l }}
Cost vs. autonomy — bubble size = blast radius (targets/orgs).
Each bubble is a real attack. Left to right is what it cost to run; bottom to top is how little a human had to drive it; the bigger the bubble, the more victims. The cheapest attacks are now also the most autonomous. Click a highlighted bubble to read its story below.
{{ s.l }}
Device code phishing.
Device-code phishing grew in the first half of 2026 as a material identity threat across Ontinue’s observed customer telemetry. Unlike conventional credential phishing, this tradecraft abuses a legitimate Microsoft authentication flow: the user completes authentication on Microsoft infrastructure, while the resulting tokens are made available to attacker-controlled infrastructure. Between May and June 2026, Ontinue identified multiple confirmed compromises across five different industries. In some of those cases, no correlated default Sentinel alert or incident was present at the time of discovery, highlighting a detection gap for token replay and device registration activity when defenders rely on out-of-the-box signals alone.
Background on the technique.
Device-code authentication is a legitimate OAuth flow designed for devices with limited input capability. In normal use, a device requests a short-lived code, the user enters that code into a trusted verification page, and the identity provider issues tokens back to the requesting device once authentication is complete. Device-code phishing abuses this separation between the user’s browser session and the device requesting authorisation. The victim is directed to a legitimate Microsoft sign-in experience and may complete multifactor authentication successfully, but the code they enter authorises an attacker-controlled session rather than a device they own.
Device-code phishing is not a new technique. The underlying OAuth 2.0 Device Authorization Grant was standardised in RFC 8628 in August 2019 and was designed for legitimate scenarios where devices lack a browser or have limited input capability, such as smart TVs, printers, media consoles, and similar constrained devices. The security issue arises when this legitimate flow is exposed to social engineering and insufficiently governed access controls.
Observed activity
In the activity observed by Ontinue, operators used the device-code flow to obtain Microsoft Entra refresh tokens. The tokens were subsequently replayed from operator-controlled infrastructure against the Microsoft Authentication Broker, enabling operators to obtain Primary Refresh Token material. The resulting access was used to register attacker-controlled devices for persistence and enumerate tenant resources through Microsoft Graph.
Ontinue identified ten confirmed device-code phishing compromises across five customer tenants between May and June 2026. The affected organisations represented the following sectors:
Kill-chain walkthrough
A device-code phishing compromise begins with a lure delivered to a user. The lure directs the user through attacker-controlled web infrastructure to a phishing page that presented a Microsoft device-code authentication prompt. The page did not need to capture the user’s password. Instead, it induced the user to enter a code into Microsoft’s legitimate device login workflow.
Once the user completed authentication, the attacker received a refresh token associated with the authorised session. From there, the operator replayed the token from controlled hosting infrastructure against the Microsoft Authentication Broker. The subsequent non-interactive sign-in activity did not resemble normal browser-based user access. It presented as server-side broker interaction using programmatic HTTP clients rather than an interactive user agent.
In the next stage, the operator used the brokered access to obtain Primary Refresh Token material and establish persistence by registering an attacker-controlled device in the tenant. In one observed case, a single compromised identity was associated with multiple attacker-registered devices, suggesting that the operator sought to preserve access even if one device object or session was later removed. This behaviour maps cleanly to device registration persistence rather than simple one-time token use.
After persistence was established, the operator conducted post-authentication reconnaissance. In one financial services/research case, the same session was used to sequentially access Microsoft Graph, Windows Azure Active Directory, and the Device Registration Service within a two-minute window. This pattern demonstrates the speed at which a successful device-code compromise can move from initial consent to tenant enumeration and persistence operations.
The observed tradecraft maps to several MITRE ATT&CK techniques: Spearphishing Link for lure delivery, Steal Application Access Token for token capture, Application Access Token replay for token use, Account Manipulation: Device Registration for persistence, Cloud Accounts for unauthorised account access, and Cloud Account Discovery for Graph-based enumeration.
Recommendations
{{ r.t }}
{{ r.d }}
Passkeys and Microsoft’s passwordless push.
Identity is only as strong as its weakest accepted sign-in method, and for most of 2025 that method was some flavour of password-plus-legacy-MFA. Adversary-in-the-middle kits such as Tycoon2FA and Salty2FA, covered elsewhere in this report, exist specifically to defeat that combination: they relay a real authentication session and harvest the token behind it. Microsoft’s response, arriving at scale in 2026, is to change what “normal” sign-in looks like across its entire customer base.
Passkey profiles, a new, group-based way to control passkey (FIDO2) registration and use in Microsoft Entra ID, are being auto-enabled tenant by tenant through the first half of 2026, whether an organisation has planned for it or not. For a report focused on identity as the primary control plane, this is one of the more consequential platform changes of the period, and it cuts both ways: done well, it closes off the credential-phishing pathway that has defined the last two years of identity attacks; done by default, it can quietly leave the same weaknesses in place under a more modern-looking label.
Why the timing matters.
Microsoft has published a firm rollout window (Message Center MC1221452). Worldwide general availability of passkey profiles runs from early to late March 2026, and tenants that have not opted in and set their own configuration are moved to automatic enablement between early April and late May 2026 (GCC, GCC High, and DoD environments follow later, in April and June). Tenants that take no action are not left without passkeys, they are migrated. Existing tenant-wide Passkey (FIDO2) settings are copied into a new Default passkey profile, and the passkey type that profile allows is decided by whether attestation was ever configured: attestation on maps to device-bound only, attestation off maps to device-bound and synced together. In practice, most tenants that never touched these settings will land on the more permissive outcome by default, at exactly the moment Microsoft-managed registration campaigns are also being tuned to nudge users toward enrolling a passkey rather than Microsoft Authenticator push. The organisations that shape this deliberately, ahead of their own enablement window, end up with a materially different (and stronger) security posture than the organisations that let it happen to them.
What actually changes under the hood.
A passkey replaces the shared secret at the centre of both passwords and legacy MFA with public-key cryptography. The device generates a key pair, keeps the private key in hardware, and will only produce a valid signed response for the legitimate relying-party domain after a local biometric or PIN check. There is no code and no reusable token to relay, which is precisely the property AiTM proxy kits depend on. Passkeys come in two flavours that matter for risk decisions:
Entra controls which of these a group of users can register through passkey profiles, attestation enforcement (cryptographic proof of the authenticator’s make and model), and AAGUID allow/block lists (an AAGUID identifies a specific security key model or passkey provider). These are policy levers, not defaults that take care of themselves, and several of the more damaging outcomes Ontinue expects to see through this migration are the direct result of those levers being left untouched rather than of any flaw in the cryptography itself.
Where we expect the seams to show.
Passkeys are phishing-resistant; the migration to them is not automatically attacker-resistant. The risk shifts from the credential itself to the process around it, and that process is where Ontinue is watching most closely going into the second half of the rollout.
Recommendations
Emerging attack techniques.
Spotlight: EtherHiding moves from novelty to mainstream.
The most significant development in this dataset is the scale of blockchain-hosted command and control. 25.3% of malicious findings - 1,568 domains - performed an on-chain RPC round-trip to retrieve their payload, resolving to just six distinct smart-contract dead-drop addresses.
EtherHiding was first documented by Guardio Labs in October 2023. It stores the malicious payload or C2 pointer inside a smart contract on a public chain, so retrieval is an ordinary blockchain read rather than a request to attacker-owned infrastructure. There is no domain to sinkhole, no server to seize, and no hosting provider to serve an abuse notice. Google Threat Intelligence has since observed North Korean state-aligned actors adopting the technique, characterising it as a further step towards bulletproof hosting.
A 2026 refinement tracked as NullReceiver conceals the C2 address inside the destination field of an empty transfer, removing even the contract-storage artefact. NullReceiver streamlines the EtherHiding approach by eliminating the reliance on smart contracts, transaction payloads, and on-chain storage. Instead, command-and-control details are encoded directly within the recipient ‘to’ address of an otherwise empty blockchain transaction.
Two characteristics of our observations deserve particular attention, as neither is widely reported:
{{ c.t }} {{ c.d }}
Execution tradecraft is diversifying.
PowerShell remains the most common interpreter at 60.6% of captured commands, but its dominance is eroding: mshta now appears in 42.5% and cmd in 37.1%. Notably, pcalua.exe - the Program Compatibility Assistant launcher, used here for proxy execution - appears in 25.4%, paired with the Start-Process alias ‘saps’ at 25.2%. Both are absent from many LOLBin detection rule sets. These percentages total more than 100% because some commands use multiple techniques.
56.6% of commands employ at least one obfuscation technique. Caret escaping (25.9%) is now more than twenty times more common than base64 -EncodedCommand (1.2%), which is what most detection content is tuned against. Character-code arrays and -join reconstruction account for a further 12.9%. Commands are short - a median of 99 characters - confirming these are download cradles rather than embedded payloads. Requested artefacts are led by .exe (12.0%), .ps1 (5.9%) and .cmd (4.3%).
Social engineering via Microsoft Teams.
Microsoft Teams was a recurring initial access vector across Ontinue's customer estate during the first half of 2026. What began as isolated campaigns by Black Basta affiliates in mid-2024 has become a cross-ecosystem technique adopted by multiple unrelated threat groups, each refining the approach independently. The clearest evidence of that proliferation is that the technique outlived the group that popularised it. Black Basta fragmented following the leak of its internal chat logs in February 2025, yet Teams vishing continued through 2026 under operators with no established connection to the original crew.
Observed activity
Impersonation of internal IT support is routine rather than exceptional across the estate. Approximately one in every 990 external Teams contacts carried at least one sign of IT-support impersonation during the reporting period, and around 30% of monitored organisations saw at least one. A contact here is a single employee paired with a single external person, counted once regardless of how many messages or calls follow.
{{ s.t }}
{{ s.d }}
Signs of fake IT support in external Microsoft Teams contact.
1 in 990 external Teams contacts showed signs of someone posing as internal IT support
A contact is one employee paired with one external person, counted once however many messages or calls follow. Some contacts showed more than one sign, so the bars add up to more than the headline figure. Display names using non-English characters are not counted as a sign: they reflect normal international naming. These are signs of impersonation, not confirmed attacks.
Call duration and what it indicates.
Ontinue observed scam calls ranging from 60 seconds to more than 30 minutes. That spread matters more than any average drawn from it.
Short calls are not evidence of attacker efficiency. They are more consistent with attempts that failed: calls declined, calls ended once the user became suspicious, and calls that never reached a conversation. The compromises that succeeded sat at the longer end of the range, where the operator had time to build rapport, work through the target's objections, and talk them through the remote access process step by step. The successful calls clustered around the twenty-minute mark rather than the brief exchanges the technique is often assumed to involve.
This is the more useful reading for defenders, and it inverts a common assumption about the technique. The window for intervention is longer than a headline average suggests, and awareness training should prepare employees for a persistent, patient, and personable caller rather than a brief scripted one. Users who expect a thirty-second scam are poorly prepared for a twenty-minute conversation with someone who sounds like a colleague.
ClickFix: industrial-scale delivery and the shift to blockchain C2.
What we did.
Over a ten-week window Ontinue operated an automated detonation pipeline against suspected ClickFix infrastructure, running 10,818 deep scans inside an instrumented browser that drives each lure exactly as a victim would - advancing the fake verification gate and capturing whatever the page writes to the clipboard, the resulting payload URL, and the network activity behind it. This gives us behavioural confirmation rather than reputation scoring.
Volume is accelerating sharply.
The volume is best explained by commoditisation rather than a step-change in adversary capability. Complete ClickFix kits are advertised on criminal forums from roughly $250 per month to $1,800 for a lifetime licence with updates included, which allows actors with no malware development capability to run campaigns at scale.
The lure sites are compromised legitimate businesses.
Delivery domain age at time of scan is decisive: a median of 1,886 days (5.2 years), with 73.3% older than one year and 50.5% older than five. Only 13.5% were registered within 30 days of observation. These are not bulk attacker registrations - they are established organisations whose sites have been compromised and repurposed as lure hosts. The TLD spread reinforces this, led by .com (2,994) followed by .org, .uk, .it, .au, .net, .ca and .de.
This carries a direct operational consequence. Blocking delivery domains imposes collateral damage on legitimate businesses, and they rotate faster than any blocklist can track. Blocking the payload host does neither.
1H 2026 Threat Intelligence Report
Download the report downloadCredits
Ontinue offers nonstop SecOps through an AI-powered managed extended detection and response (MXDR) service. Ontinue ION MXDR combines powerful proprietary AI with the industry’s first collaboration with Microsoft Teams to continuously build a deep understanding of our customers’ environments, informing how we prevent, detect, and respond to threats.
Continuous protection. AI-powered Nonstop SecOps. That’s Ontinue.