AI Is Lowering the Cost of Cyberattacks

Microsoft recently observed a China-aligned threat actor move from initial targeting to privileged cloud access in less than three hours while using an agentic penetration-testing framework. Microsoft describes the broader development as cyberattacks accelerating toward machine speed, and the speed is notable, but it may not be the most important part of the story. Reconnaissance, credential abuse, exploitation, privilege escalation and persistence are familiar techniques. What artificial intelligence can change is the amount of human effort required to apply them repeatedly, adapt when an approach fails and continue investigating many targets at once. Microsoft Security

The threat actor, tracked by Microsoft as Storm-0940, used ARTEX, an open-source multi-agent penetration-testing framework, against hundreds of organizations. ARTEX can coordinate activity across different stages of an attack with relatively little human interaction and can work with different underlying AI models. The significance is not that human operators disappear, but that they can delegate more of the tactical work that would traditionally demand sustained attention. Microsoft Security

Even within an ARTEX-enabled campaign, however, not every large number demonstrates adaptive AI behaviour. Microsoft recorded more than 151,000 failed authentication attempts during one password-spraying operation, briefly reaching approximately 2,900 failures per minute. The activity targeted 327 accounts across eight organizations, with lockout responses accounting for nearly 98 per cent of the observed activity, yet no successful authentication, token issuance, Microsoft Graph call or directory change resulted from the spray. The volume demonstrates aggressive automation, but high-volume credential attacks existed long before agentic AI. The more important question is what an automated system can do when repeating the same action does not work. Microsoft Security

A separate campaign reported by Reuters provides a clearer example of that distinction. A hacker used autonomous AI agents to attempt intrusions against more than 1,200 websites across the United States, Canada, Australia and Japan, breaking into websites belonging to more than 100 companies. Snorre Fagerland of security firm NorForge, who tracked the activity, said successful intrusions took an average of roughly 23 hours of autonomous probing and cost about $50 in AI usage each. The campaign used Cairn, an open-source AI platform, to coordinate attacks with relatively little human supervision. Reuters

The most useful detail is how the agents behaved when easy openings were not available. Reuters reported that they could identify overlooked infrastructure, pursue subtler vulnerabilities and continue experimenting until they found a viable route to execute malicious commands. That behaviour marks a more meaningful distinction between scripted automation and agentic attack tooling. A script is highly effective when the sequence of actions is known in advance; an agentic system can increasingly interpret results, pursue another path and continue through unsuccessful approaches without requiring a person to make every tactical decision. Reuters

When attacker attention becomes cheaper

Skilled offensive labour has always imposed a practical constraint on cyberattack. An operator who spends a day investigating one environment cannot spend that same day manually examining twenty others, which means targets that fail to reveal an obvious weakness may eventually be abandoned because the expected return no longer justifies additional human effort.

Autonomous agents weaken that constraint. The Reuters campaign is instructive precisely because successful intrusions were not instantaneous; they took an average of around 23 hours of probing. The difference is that those hours did not require an equivalent amount of continuous human attention. Software could continue examining a target, testing alternatives and following unsuccessful paths while the operator supervised a much larger campaign. Reuters

This is where the economics become significant. Offensive work often consists not of immediately finding the correct vulnerability, but of repeatedly discovering that something does not work. A service is patched, a credential lacks sufficient privilege, an application is not exploitable in the expected way, or another system has to be investigated. If autonomous agents can absorb more of that unsuccessful investigative effort, the cost of pursuing each target falls even when the underlying techniques remain familiar.

The companies identified in reporting on the Reuters campaign included large businesses, so the case should not be presented as evidence that AI attackers are already shifting primarily toward smaller organizations. The broader implication is analytical rather than observed: if the marginal cost of sustained investigation continues to decline, targets that previously might not have justified prolonged manual attention could become more economical to pursue. A regional manufacturer, medical practice or mid-sized professional-services company does not need to become strategically important for that calculation to change; the cost of continuing the investigation simply has to become low enough.

The near-term threat may therefore be less about an adversary becoming dramatically more intelligent and more about an adversary being able to afford greater patience across a much larger target population. That distinction matters because organizations that have historically considered themselves too small or unremarkable to justify sustained attention may find that attacker economics are changing faster than their own risk assumptions.

Supply-chain access multiplies the leverage

Storm-0940 also demonstrates how much greater that leverage becomes when autonomous tooling is combined with trusted third-party access. Microsoft assesses that the actor was responsible for a ConnectWise supply-chain compromise involving a multi-tenant application. After acquiring control of identities belonging to ConnectWise cloud applications, the attackers used those trusted identities in attempts to authenticate to more than 2,250 downstream Microsoft 365 tenants. Microsoft Security

In some affected environments, the activity progressed beyond authentication into Microsoft Graph and directory operations. Microsoft observed reconnaissance, application credential modifications used to establish persistence, and changes involving identities, groups and privileged roles. Its detection data includes at least one instance in which attackers used a compromised ConnectWise application identity to assign that application the Global Administrator role. These changes could leave additional access paths active after the original compromised application was remediated, requiring defenders to investigate what happened after initial access rather than assuming that removing the original integration had resolved the incident. Microsoft Security

This combination of trusted access and automation creates a concentration risk that conventional vendor assessments do not always capture well. A compromised third-party application already possesses something an external attacker would ordinarily need to obtain: legitimate trust inside the customer environment. If the same application is authorized across hundreds or thousands of tenants, autonomous tooling can help investigate those downstream environments without forcing the attacker to choose as sharply between scale and depth.

Third-party risk assessments therefore need to examine more than whether a supplier appears secure. Certifications, vulnerability-management programs and incident-response capabilities remain relevant, but they do not answer what happens when those controls fail. Security and procurement teams should understand what an integration can access, which privileges it holds, whether those privileges remain justified over time and how quickly the connection can be removed when compromise is suspected.

A vendor application with narrowly scoped permissions and a tested revocation process presents a materially different exposure from one that has accumulated extensive Microsoft Graph permissions or privileged roles. Contracts also matter because customers need clear incident-notification obligations and defined responsibilities for credential rotation. Contractual protections cannot compensate for excessive technical privilege, but they can materially affect how quickly customers receive the information required to contain a compromise.

Reduce the window and the payoff

Organizations facing increasingly automated attack activity need to address two related problems: how long an attacker can continue operating and how much useful authority is available during that period. Faster incident response matters, but reducing the value of successful access can be equally important because a compromised identity with limited authority creates a very different incident from one that immediately inherits broad administrative access.

Containment should begin with decisions made before an incident occurs. Security leaders should establish which high-confidence scenarios permit immediate action, which can be automated safely and which genuinely require additional approval. If an active session is clearly compromised or a malicious service principal needs to be disabled, responders should not spend the first stage of an incident determining who has authority to act.

Traditional response metrics can conceal this delay. An organization may report an impressive mean time to detect while leaving an attacker operational for hours after the initial alert. A more revealing measure is the time between high-confidence detection and the point at which the compromised access path can no longer be used. For an identity incident, that might mean revoking sessions and rotating credentials; for an endpoint, it may mean isolation; and for an application identity, responders may need to remove unauthorized credentials, grants or role assignments while checking whether additional persistence was created elsewhere.

Microsoft's response guidance for the ConnectWise-related activity reflects this broader approach. It recommends examining service-principal sign-ins, credential additions, consent grants, privileged role assignments and subsequent Microsoft Graph activity. Microsoft also explicitly warns organizations not to allow evidence collection to delay urgent containment, which is an important operational distinction for incident-response teams accustomed to balancing forensic preservation against the need to stop ongoing access. Microsoft Security

Reducing the attacker's payoff requires equally close attention to non-human identities. Service principals, OAuth applications, API credentials, automation accounts and vendor integrations often operate with persistent permissions because software requires continuous access. Those identities should have identifiable owners, documented purposes and permissions that can be justified. Unused integrations should be removed, unexpected credential and privilege changes should be monitored, and standing access should be narrowed wherever broader rights are no longer necessary.

Organizations can apply additional contextual restrictions to some of their own workload identities. Microsoft Entra Conditional Access for workload identities can block certain service principals based on factors such as location or detected risk, but its scope is important. The policies apply to single-tenant service principals registered within the organization's own tenant; Microsoft applications, third-party SaaS services and multi-tenant applications are outside their coverage. Creating or modifying these policies also requires Microsoft Entra Workload Identities Premium licensing. Microsoft Learn

That limitation is particularly relevant because a trusted multi-tenant vendor application is precisely the type of scenario at the centre of the ConnectWise case. For those integrations, the practical controls lie elsewhere: carefully limiting permissions when consent is granted, governing enterprise applications throughout their lifecycle, monitoring app-only authentication and Graph activity, detecting unexpected credential or role changes, and maintaining a tested process for cutting the integration off quickly when compromise is suspected.

These controls cannot eliminate initial compromise, but they can reduce what the attacker inherits. Narrow application permissions constrain immediate reach, shorter-lived credentials reduce the useful lifetime of stolen authentication material, and segmentation prevents access to one system from automatically becoming access to another. Rapid containment then ensures that the time created by those preventive controls is not wasted.

Smaller organizations need a different response

The potential decline in attacker labour costs matters particularly for organizations without large security teams. If persistent investigation eventually becomes economical across a broader population of targets, recommendations built around dedicated SOCs, identity-engineering teams and sophisticated orchestration platforms will not be enough.

For smaller organizations, resilience is more likely to come from reducing complexity and relying on controls that function without constant specialist attention. Phishing-resistant authentication, centrally managed endpoints, automatic security updates, tightly controlled administrator privileges and regular review of SaaS integrations can remove substantial exposure without requiring a large internal security function.

Managed detection and response may also be more realistic than attempting to reproduce an enterprise SOC internally. The distinction is whether the provider can actually respond. A service that forwards an alert at 2 a.m. but waits for the customer to begin containment may provide monitoring without materially reducing the attacker's operating window. Organizations should understand which actions their provider can take under predefined conditions, how after-hours escalation works and where customer approval remains necessary.

Technology vendors also carry greater responsibility if automated attackers can economically pursue a broader range of customers. Secure defaults become more important when customers may not have dedicated IAM or cloud-security expertise. Integrations should not receive unnecessarily broad privileges by default, and meaningful security logging should not depend on customers discovering obscure configuration settings only after an incident has occurred.

AI changes the economics before it changes the techniques

The near-term impact of offensive AI is unlikely to be defined by an entirely new category of cyberattack. The techniques appearing in recent campaigns remain recognizable, while the more consequential shift is the declining cost of applying those techniques repeatedly, adaptively and across a much larger set of potential victims.

Organizations do not need to respond by automating every defensive decision. They need to reduce the value of successful access while removing avoidable delays once malicious activity becomes sufficiently clear. That requires stronger governance of non-human identities, greater scrutiny of third-party application privileges, clear containment authority and response metrics that reflect when an attacker actually loses the ability to continue operating.

Artificial intelligence does not need to make attackers dramatically smarter to change the threat landscape. If one operator can investigate more targets, follow more unsuccessful paths and sustain more effort at lower cost, the economics of targeting begin to change. The practical response is to build environments in which successful access gives the attacker less to work with, while ensuring that once compromise is understood, the organization can remove that access before cheap investigative effort becomes an expensive incident.