Microsoft and Todyl are reporting a cloud intrusion campaign in which stolen application credentials become access to other credentials, business files and downstream customer tenants. For small businesses, managed service providers and government contractors, the immediate question is not simply whether a secret appeared in a repository. It is what that application could reach before its access was contained.

Microsoft's November 5 research describes attackers using the ARTEX agentic offensive framework to find exposed secrets and conduct follow-on operations. In one observed case, an agent moved from searching GitHub to exfiltrating Azure Key Vault data in five minutes. That is a case observation, not a universal time-to-compromise estimate.

What is new, and what began earlier

The reporting is new; the underlying activity did not start this week. Microsoft says secret scanning was observed beginning in August 2026 and successful service-principal sign-ins in a follow-on attack as early as October 28. Todyl first observed related access on November 1, published its investigation November 3 and updated it November 6 with corroboration from Microsoft's research.

The two investigators describe application identities accessing Azure and Microsoft 365 resources, collecting credentials and reaching other applications or customer tenants. Microsoft reports file downloads and mailbox-item access as well as cloud discovery and secret theft. Todyl's November 3 snapshot counted access reaching 27 organizations; that is a historical, visibility-limited investigator count, not a current campaign-wide total.

Todyl's earlier assessment treated an agentic explanation cautiously; its November 6 update endorses the credential-crawler assessment following Microsoft's findings. Neither report establishes a country attribution for this incident. Todyl explicitly distinguishes it from the October ConnectWise Cloud Backup incident attributed to Storm-0940. Shared tooling is not proof that these are the same operator or compromise.

Why application access changes the response

A service principal is an application's identity. Its permissions can authorize access without an employee approving an MFA prompt. An organization can therefore have strong user authentication and still leave powerful application credentials exposed. Microsoft also describes cases where a compromised vendor-owned multitenant application credential enabled access to downstream tenants.

The practical risk extends beyond the first key. Accessible vaults, configuration files and documents can contain storage keys, connection strings, deployment credentials or credentials for unrelated systems. For a contractor, that warrants reviewing where project information and customer access sit within the application's effective permissions. Neither source establishes that every exposed application or customer tenant suffered data theft.

Actions for administrators and their service providers

  1. Preserve and scope the evidence. Review Entra service-principal and non-interactive sign-in logs, including failures followed by successes. Hunt back at least to October 28 and further where retention permits. Correlate Azure Activity, Key Vault and Storage diagnostics, Microsoft 365 audit records and Azure DevOps auditing. A token request is not itself proof that vault contents were read; use resource-side evidence to determine actual access.
  2. Contain the identity, not just the repository leak. Remove compromised application secrets, certificates and federated credentials, including unauthorized additions, and disable the service principal if necessary. Plan for application interruption with its owner. Deleting exposed code does not invalidate a credential, and Microsoft warns that already-issued tokens remain valid until expiry.
  3. Recover downstream credentials and sessions. Rotate secrets in any vault the affected application could read and credentials in accessed documents. For affected users, address Entra sessions, Azure DevOps personal access tokens and SSH keys. Investigate permissions, service connections and pipelines rather than assuming one new client secret completes recovery.
  4. Validate the actual control boundary. Microsoft recommends an exact-address block for 199.19.77[.]84 in workload-identity Conditional Access and a user-scoped policy for replayed sessions. Workload-identity policies require Workload ID Premium and cover single-tenant applications registered in the tenant; do not assume they protect every managed identity or third-party multitenant integration. A firewall block is not equivalent to blocking cloud identity sign-ins.
  5. Check the customer and recovery paths. MSPs should review Partner Center, granular delegated administrative privileges and customer tenants, and notify affected customers under their agreements. Verify that backup authority, Azure DevOps service connections and recovery credentials are outside the compromised application's reach. Review AI-service keys, usage and billing where those resources were accessible.

Indicators help, but do not define the incident

The sources differ on blocking scope: Microsoft's guidance specifies the exact operator address, while Todyl's November 6 update recommends a broader range. Do not silently treat those recommendations as identical or block an entire hosting ASN. Microsoft also cautions that 199.19.77[.]18 is a Tor exit node that may carry unrelated activity. Shared hosting, legitimate command-line clients and user-agent strings are not sufficient evidence of attribution or compromise.

Behavioral correlation matters more than a single blocklist hit: one source authenticating to several application identities, rapid requests across cloud services, unusual document downloads and new credential use following collection deserve investigation. Use source-provided hunting material with its context; absence of a listed address does not establish that an environment is clean.

Bulwark assessment

The important development is the compression of an already-dangerous access chain, not an exemption from normal incident response because AI is involved. Prioritize the applications with the broadest authority and customer reach. Record an owner, the permissions involved, the evidence retained and the downstream credentials recovered. Longer term, remove secrets from code, adopt managed identities or carefully scoped federation where appropriate, and protect the systems that issue trusted tokens. Replacing a stored secret does not remove excessive permissions or insecure federation trust.

Primary source: Microsoft Threat Intelligence and Microsoft Security Research: Threat actors use agentic AI tooling to find and abuse exposed secrets, November 5, 2026.

Primary source: Todyl: Stolen App Credentials, Real Access, published November 3 and updated November 6, 2026.