跳到正文
DEV Community· kozhevniko·· 1 天前精選AI 評分79

每分鐘 2,900 次登入嘗試：ConnectWise 攻擊對第三方應用程式信任的啟示

2,900 sign-in attempts a minute: what the ConnectWise campaign teaches about third-party application trust

AI 導讀

Microsoft 將針對 ConnectWise 客戶 Microsoft 365 環境的供應鏈攻擊歸因於 Storm-0940，事件涉及高權限第三方應用程式及後續目錄操作。

推薦理由

文章將 ConnectWise 事件中的密碼噴灑、應用程式憑證持久化與目錄權限風險，轉化為檢查第三方高權限應用程式的具體控制項。

正文 · 原文

2,900 sign-in attempts a minute: what the ConnectWise campaign teaches about third-party application trust

Microsoft attributed the supply-chain attack against ConnectWise customers' Microsoft 365 environments to a China-state aligned group it tracks as Storm-0940. The attribution is the headline; the mechanics change how a defender should treat every high-privilege third-party application in their tenant.

The sequence

Microsoft Security Research reported that as early as September 2026, Storm-0940 used an agentic AI penetration testing framework called ARTEX to automate attacks against hundreds of organisations across a wide range of industries, including aerospace and defence, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductors, software, technology, think tanks and non-profits.
Immediately before the ConnectWise compromise, the group ran a password-spraying campaign that ultimately failed. Across a four-day stretch ending 14 October, it targeted 327 Microsoft 365 and Exchange Online accounts at eight organisations, generating more than 151,000 failed logon attempts and peaking at roughly 2,900 failures per minute.
The next day, the group turned to ConnectWise, using AI agents and the same malicious infrastructure to compromise Microsoft 365 environments belonging to a series of ConnectWise Cloud Backup customers.

Why the failed spray still matters

A spray of 151,000 failures is evidence of an attempt, not of a breach. It is also a measurement of defender reaction time. At close to 2,900 attempts per minute, a control that detects and blocks spray after a threshold of a few hundred failures has already let the campaign run its course before anyone responds. The timeline suggests the group changed target rather than technique.
This is the rhythm that automated offensive tooling produces. Microsoft stated that ARTEX is a system of LLM-driven agents that run an autonomous penetration test from reconnaissance through data exfiltration with little human interaction, that it works with any AI model, and that multiple threat actors from various regions are using it.

What the agents reached

In some victim environments, Microsoft reported, the AI agents progressed beyond authentication into Microsoft Graph and directory operations. The listed activity includes reconnaissance, application credential modifications used to establish persistence, and changes involving identities, groups and privileged roles.
That list describes a pivot in which the third-party application is the entry point and the directory is what sits behind it. Microsoft observed multiple customer environments with evidence of follow-on activity, and noted that a compromised third-party application holding high privileges could provide access beyond its originally intended purpose.
Microsoft did not state how many customers were compromised, and it added that successful authentication does not necessarily mean the group accessed or stole data. Both qualifications matter. A directory change is a real event with real evidence, while a successful sign-in is only a precondition.

The control that the campaign exploited

Anyone who has reviewed OAuth grants will recognise the pattern. An application is consented once, usually for a legitimate integration, and thereafter authenticates as itself rather than as a user. MFA designed for human sign-ins does not constrain it. Conditional access scoped to users may not reach it. Reviewing consent is a separate exercise from reviewing the application vendor's own security posture, and the ConnectWise case is a reminder that a backup product can hold tenant-wide reach.
Concrete checks that follow from the reported activity:

  1. Enumerate every application with directory-level permission in each tenant, then ask which of them genuinely need write access to identities, groups or roles.
  2. Review recent credential additions on existing applications. The reported technique modifies application credentials to establish persistence, and a new secret on an old application is easy to miss in a user-focused audit.
  3. Compare group and role membership against a known baseline, so that changes involving privileged roles surface as diffs rather than discoveries.
  4. Check whether sign-in risk policies apply to service principals and workload identities, not only to interactive users.

Where recovery stands

ConnectWise temporarily shut down services on the Saturday following the attacks and said it began restoring services in phases the following Wednesday. It advised customers to keep connections disabled and stated that recovery would take several days. Microsoft's executive vice president described the campaign as one of many in a wave of AI-driven cyberattacks since early October.
For an affected customer, the practical order is separate from the vendor's restore schedule. Rotate credentials that were reachable from the tenant while connections stayed disabled, review directory changes made during the window, then re-enable integrations one at a time with the permission scope re-checked.

What remains unresolved

The reporting does not state the initial access vector into ConnectWise's own environment, does not quantify how many downstream tenants experienced confirmed data access as opposed to directory modification, and does not publish indicators for the malicious infrastructure. Microsoft's account also does not describe whether the password spray against the eight organisations and the subsequent ConnectWise campaign used identical infrastructure, only that the same infrastructure is described for the latter. Those gaps leave detection work to your own telemetry: application credential changes, new consent grants, and role assignments outside a change window.

References

來源：DEV Community · dev.to

#教學/實踐#Agent#Microsoft