In modern cyber crime ecosystems, initial access (TA0001) is a red hot market. Automated tools are used to create phishing pages and harvest unsuspecting users’ credentials at scale. These credentials are often used for schemes such as business email compromise (BEC) campaigns, or sold on illicit marketplaces.

Throughout 2024 and 2025, a common credential harvesting technique targeting Microsoft 365 / Azure credentials has utilised Axios. Axios is a JavaScript HTTP client that can make HTTP requests from a web browser or Node.js environment. Axios itself is a legitimate development tool, however in this context it is misused to create fraudulent (yet authentic looking) login.microsoftonline.com pages and authenticate with credentials provided by a victim of phishing (T1566). This blog from Field Effect goes into more detail about how this kind of Axios-based credential harvester works.

Credentials compromised in this manner are commonly used for business email compromise (BEC) schemes. This image from Microsoft Threat Intelligence’s blog illustrates the attack chain for an adversary-in-the-middle (AiTM) phishing attack to BEC.

This attack chain is related to the following MITRE ATT&CK techniques:

• Compromise Accounts (T1586)
• Valid Accounts (T1078)
• Phishing (T1566)

Detection opportunities

M365 login successes and failures are typically logged, which creates an excellent opportunity for defensive cyber security practitioners to become alerted to malicious activity targeting their organisation. In one scenario, a credential harvester using axios/1.7.9 as a user agent was observed. From a security monitoring perspective, this left a blatant, glaring artefact in the logging.

A detection rule like this practically writes itself, with surprisingly low rate of false positives and reasonably high confidence after baselining. The obvious drawback of high detection precision is that it only targets this unique type of credential harvesting technique. Regardless, it’s a quick and easy one to have in the arsenal and considering it’s been observed to be effecting numerous organisations throughout Australia and beyond, I’d argue it’s worth having.

See the two Sigma rules below.

Successful authentication from an Axios user agent

The implication of this rule is that credentials have been phished, harvested and successfully validated by a potential adversary. This warrants immediate attention.

title: Authentication from user agent associated with credential harvesting
id: 3a8cbbe3-e8ab-4de1-9a22-222b932557e1
description:
  - Identifies a successful authentication from the user agent 'axios'. Axios is a JavaScript HTTP client that can make HTTP requests from a web browser or Node.js environment. It is commonly abused for credential harvesting tools. This detection likely means a credential harvesting tool has tested the validity of phished credentials and succeeded. A valid session may have been logged and stolen by a credential harvesting tool.
references:
  - https://rigelnoble.com/blogs/cybersecurity/axios-credential-harvesters-detection-and-response/
tags:
  - attack.initial_access
  - attack.resource_development
  - attack.t1586
  - attack.t1566
  - attack.t1078
author: Rigel Noble
date: 2025/07/21
logsource:
  product: azure
  category: signinlogs
detection:
  selection:
    UserAgent|contains:
      - axios
    Operation|equals:
      - UserLoggedIn
  condition: selection
level: critical
falsepositives:
  - Legitimate web applications utilising the Axios user agent.

Failed authentication from Axios user agent

This rule implies that a user has clicked a phishing link and input their credentials, but the login has failed.

The login could have failed for various reasons (such as incorrect credentials), or it could’ve been blocked due to conditional access policies. While not as serious as a successful authentication, this still warrants attention.

title: Failed authentication from user agent associated with credential harvesting
id: d5b3ab18-4e82-4c54-8f1b-679f06d99ea6
description:
  - Identifies a failed authentication from the user agent 'axios'. Axios is a JavaScript HTTP client that can make HTTP requests from a web browser or Node.js environment. It is commonly abused for credential harvesting tools. This likely indicates a credential harvester has phished credentials from a user but has failed to sign on successfully.
references:
  - https://rigelnoble.com/blogs/cybersecurity/axios-credential-harvesters-detection-and-response/
tags:
  - attack.initial_access
  - attack.resource_development
  - attack.t1586
  - attack.t1566
  - attack.t1078
author: Rigel Noble
date: 2025/07/21
logsource:
  product: azure
  category: signinlogs
detection:
  selection:
    UserAgent|contains:
      - axios
    Operation|equals:
      - UserLoginFailed
  condition: selection
level: high

Data normalisation considerations

It’s important to note the fields for the logon outcomes may vary depending on the SIEM platform and any data normalisation that occurs for logs. azure and o365 can be distinct log sources, yet the axios user agent being used for authentication can be logged in both. If you want to maximise detection surface, you should account for variations in the key/field and relevant values, as it was observed they were slightly different between azure and o365 logs.

False positives and tuning

After these rules were deployed to a large number of unique environments, a few false positives related to legitimate applications utilising the axios user agent were discovered.

These false positives related to:

• The M365 SharePoint service principle, indicated by a user name of app@sharepoint. More info available on this Reddit post.
• A common enterprise knowledge management and collaboration software.
• A third-party ActiveDirectory plugin used to collect and sync host data.
• A custom application used by an approved third-party telecommunications contractor that collects data for billing purposes.
• An AI assistant, meeting and transcription application.

Application display names

Each false positive was assessed to be benign when considering the app_display_name and user name fields. Interestingly, where true positives were found to be malicious, there was no app_display_name field present at all. Yet, all false positives had this field available. Further research and testing could look at this field for clues around how malicious implementations of Axios credential harvesters seem to lack an application display name.

In theory, to reduce false positives you could adjust the rule to have a condition where app_display_name does not exist. However, I’d wager the benefit of having greater visibility into potentially malicious credential harvesting activity outweighs the risk of creating a blind spot by only alerting where there is not an application display name. This is particularly true in single-tenancy environments, where it is relatively easy to identify benign matches during a baselining period and to conduct ongoing tuning.

Response outcomes

In my opinion, a detection rule worthy of high or critical severity should have actionable response outcomes. For these two rules, response would be typical for any suspected phishing incident.

Immediate containment and eradication actions could include:

• Disabling the user’s account.
• Revoking active sessions for the user.
• Forcing a password reset for the user.

It would also be wise to:

• Investigate the users inbox for suspicious activity, such as:
  • Emails that have been recently received, sent or deleted.
  • Newly created forwarding rules.
• Review logging from other M365 apps for suspicious activity, such as Sharepoint/ Teams.

Lastly, consider if there are any lessons to be learned, or other relevant security controls that could have either prevented or mitigated the risk. In some organisations, well-defined conditional access policies (CAPs) were observed to block sign-ons from Axios-based credential harvesters. This was true even in cases where a user had been successfully phished and their account had sign on attempts with valid credentials. Without CAPs, the sign ons may have succeeded.

Conclusion

Credential harvesting is low effort and low skill for attackers, but high risk and high impact for organisations. Implementing simple yet high precision detection rules gives defenders a rare chance to get the jump on malicious activity related to initial access before it gets too far out of hand.