Key findings
Attackers targeted more than 2,250 Microsoft 365 tenants in October 2026 using compromised third-party application credentials and AI-assisted tools. The incident highlights a security risk for organisations that allow external software to access their cloud systems.
More than 2,250 tenants were targeted. Attackers attempted authentication using compromised application identities.
327 accounts were targeted across eight organisations. An earlier password-spraying phase generated more than 151,000 failed sign-in attempts.
Some attacks reached privileged access in under three hours. Automated activity helped attackers progress through certain cloud environments.
The campaign was reported in October 2026. It involved compromised ConnectWise Cloud Backup application credentials and the ARTEX AI-assisted framework.
Why Microsoft 365 application credential security matters
Many Nigerian businesses use Microsoft 365 for email, documents, meetings and internal communication. These services often connect to backup tools, reporting applications and other business software.
Each connection needs permission to access information or perform a task. Some applications work automatically, without asking an employee to sign in every time.
This is useful for business operations. A backup application, for example, may need regular access to files and other cloud resources. An integration may need to exchange information between systems throughout the working day.
However, the credentials used by these applications can become a security risk if they are stolen.
An attacker who obtains valid application credentials may be able to access resources through permissions that the organisation has already approved.
This can happen without stealing an employee's password or triggering the normal sign-in process.
The October 2026 campaign provides an example of how this weakness can be exploited at scale.
How the Microsoft 365 supply-chain attack worked
The reported campaign involved credentials associated with ConnectWise Cloud Backup applications. Attackers attempted to use compromised application identities to access Microsoft 365 customer environments.
The activity was assessed as associated with Storm-0940, a threat group described in the investigation as China-state-aligned.
The attackers also used ARTEX, an open-source AI-assisted penetration-testing framework, to automate parts of their activity.
The important point for businesses is how the attackers attempted to use existing trust relationships.
When an organisation authorises an external application, it may grant that application access to specific cloud resources. If the application's credentials are later compromised, an attacker may attempt to use the same access.
This creates a supply-chain risk. A security incident involving an external provider can affect organisations that depend on its applications.
However, attempted authentication does not prove that every targeted tenant was compromised. The published evidence does not establish that all targeted organisations experienced successful access or data theft.
Reported campaign figures
| Measure | Reported figure | Meaning |
|---|---|---|
| Microsoft 365 tenants targeted | More than 2,250 | Tenants subjected to attempted access |
| Accounts targeted in an earlier phase | 327 | Accounts included in password-spraying activity |
| Organisations in that phase | 8 | Organisations associated with the targeted accounts |
| Failed sign-in attempts | More than 151,000 | Unsuccessful authentication attempts |
| Time to privileged access | Under 3 hours | Duration reported for some attack sequences |
| Reporting year | 2026 | Year of the published investigation |
These figures describe different stages of the campaign. Failed sign-ins are not successful breaches, and the number of targeted tenants is not a confirmed count of compromised organisations.
How Microsoft Entra ID controls application access
Microsoft Entra ID manages identities and access for Microsoft cloud services. It supports both employee accounts and application identities.
Applications can connect to Microsoft 365 using OAuth authentication. Instead of storing an employee's password, an application may authenticate using its own credentials.
These credentials can include client secrets or certificates. When authentication succeeds, the application may receive an access token that allows it to use approved resources.
An application registration identifies the software requesting access. A service principal represents that application within an organisation's tenant.
Administrators can grant permissions that define what an application is allowed to do.
Some applications need limited access to particular information. Others may receive broad permissions because they perform backup, administration or integration tasks.
The greater the permissions, the greater the potential impact if the credentials are compromised.
Why employee MFA may not stop application credential theft
Multifactor authentication helps protect employee accounts by requiring additional verification during sign-in.
However, some applications use service-to-service authentication. They can request access without an employee completing an interactive sign-in.
If attackers obtain valid application credentials, employee MFA may not prevent them from attempting authentication through that application identity.
This does not mean MFA is ineffective. It remains an important control for employee accounts. Businesses also need separate controls for application identities.
What this means for Dynamics 365 Business Central
Many Nigerian companies use Dynamics 365 Business Central to manage accounts, stock, purchasing and sales.
Business Central can connect with external systems through APIs and Microsoft Entra application identities. These integrations may support reporting, data exchange and automated business processes.
For example, a Lagos distributor may connect Business Central to a warehouse application. A manufacturer may use an integration to exchange purchasing or stock information with another system.
These are examples of how business applications can communicate. They are not examples of confirmed compromises.
If an authorised integration uses application credentials and those credentials are stolen, an attacker may attempt to use the application's existing permissions.
The potential impact depends on the permissions granted inside Business Central and the connected identity platform.
The reported October 2026 campaign does not establish that Dynamics 365 Business Central was directly attacked or compromised.
Its relevance to Business Central is the underlying application identity risk, rather than evidence of a specific Business Central vulnerability.
Business Central integrations that deserve review
IT administrators should identify applications that connect to Business Central through APIs or service-to-service authentication.
Review the Microsoft Entra application registrations associated with these integrations. Check which applications are authorised inside Business Central and which permission sets they have been assigned.
Applications that no longer serve a business purpose should have their access reviewed and removed where appropriate.
Administrators should also examine how credentials are stored, renewed and monitored.
For finance and operations teams, this matters because integrations can access information used for purchasing, stock management, sales and accounting.
How attackers can maintain access
Compromising an application identity may be only the beginning of an attack.
Attackers may attempt to add new credentials to an application registration or change permissions to increase their access.
For example, adding another client secret or certificate may provide a way to authenticate again after the original credential has been replaced.
Changes to permission grants or administrator roles can also increase the resources available to a compromised identity.
Security teams should therefore investigate unexpected changes to application registrations, service principals and access permissions.
Rotating a stolen credential is important, but it may not be sufficient if an attacker has already added another credential or obtained additional privileges.
What AI changed in the attack
The attackers reportedly used ARTEX to automate parts of the campaign.
Some attack sequences reached privileged cloud access in less than three hours. This demonstrates the speed at which suspicious activity can develop in certain circumstances.
AI-assisted tools may help attackers organise authentication attempts, interpret results and continue through subsequent actions.
However, the published evidence does not establish that AI independently performed every stage of the attack.
It also does not provide a controlled comparison showing how much faster ARTEX was than conventional tools.
For businesses, the practical lesson is that security monitoring and incident response need to account for automated activity.
Waiting for a routine manual review may leave suspicious application changes undetected for too long.
What this means for you
Nigerian businesses using Microsoft 365, Business Central or other connected cloud applications should review how third-party software receives and maintains access.
At giosoft, we work with Microsoft cloud and business applications, including Microsoft 365, Dynamics 365 Business Central and Azure. We recommend treating application identities as part of normal access management, rather than reviewing only employee accounts.
Review application registrations
Start with Microsoft Entra application registrations and enterprise applications.
Identify the owner of each application and confirm that its permissions match its current business purpose.
Pay particular attention to integrations with broad permissions or administrator roles.
Check service principal sign-ins
Review service principal sign-in activity for unusual authentication patterns.
Investigate unfamiliar locations, unexpected access attempts and activity involving applications that should rarely change.
Sign-in records should be reviewed alongside audit events and relevant resource activity before drawing conclusions about compromise.
Monitor credential changes
Check for newly created client secrets, certificates and permission grants.
Confirm that changes were approved and performed by authorised administrators.
If a credential is suspected to be compromised, preserve relevant logs and follow a controlled process for replacing it.
Review Business Central application permissions
For Business Central integrations, check the applications authorised to access the environment and the permission sets assigned to them.
Remove unnecessary access and review integrations that have not been used recently.
Finance and operations managers should work with IT teams to confirm which integrations are still needed for daily processes.
Prepare for supplier security incidents
Keep a record of external applications and service providers that connect to business systems.
Assign responsibility for reviewing security notices and responding when a supplier reports compromised credentials.
Follow the affected provider's instructions before restoring access.
Security checklist for Microsoft cloud administrators
Inventory third-party applications connected to Microsoft 365 and Business Central.
Review Microsoft Entra application registrations and service principals.
Identify applications with broad permissions or privileged roles.
Inspect recently added credentials and permission grants.
Monitor service principal sign-ins and relevant audit events.
Remove unused integrations and unnecessary access.
Rotate compromised credentials and investigate persistence attempts.
Document procedures for responding to supplier security incidents.
The October 2026 campaign shows how stolen application credentials can expose trusted cloud connections. The reported targeting of more than 2,250 Microsoft 365 tenants is a reason to review application access, not evidence that every tenant was breached.
For Nigerian businesses, a practical starting point is to identify the external applications connected to Microsoft 365 and Business Central, confirm who owns them and check whether their permissions are still necessary.
