Successful Sign-In Using FastHTTP User Agent [RULE-1147]

Rationale

FastHTTP is a Go-based HTTP client library designed for high throughput and performance. It is not used by any mainstream web browser or standard Microsoft client application. When FastHTTP appears in sign-in logs, it is almost always associated with automated credential stuffing or brute-force campaigns.

Attackers frequently use tools built on FastHTTP to test large volumes of stolen credentials against Microsoft 365 tenants. If even one login attempt succeeds, the attacker gains immediate access to the compromised account, including email, files, and any connected services. This technique maps to MITRE ATT&CK T1078 (Valid Accounts), where adversaries use legitimate credentials to gain initial access.

Because this rule only triggers on successful sign-ins (ResultType 0), every alert represents an actual account compromise where the attacker has bypassed authentication. Rapid response is critical to prevent the attacker from establishing persistence, exfiltrating data, or moving laterally within the environment.

Follow-up

Follow these steps to adequately address this detection:

1. Verify whether the sign-in was performed by a legitimate user or application: Check with the account owner whether they used any automated tooling or development framework that could explain the FastHTTP user agent. Review the sign-in location and IP address for anomalies.

   • If no: The sign-in is unauthorized and the account is compromised:

     1. Immediately disable the account in Microsoft Entra ID to prevent further access.
     2. Revoke all active sessions for the user via the Entra admin center.
     3. Reset the user's password and require re-registration of MFA methods, as the attacker may have registered their own authentication methods.
     4. Review the account's recent activity in the Unified Audit Log (https://security.microsoft.com/auditlogsearch) for signs of data exfiltration, mail forwarding rules, OAuth app consents, or privilege escalation.
     5. Check for newly registered authentication methods or applications added by the attacker.
     6. Consider engaging Attic's IR team for a thorough investigation if there are signs of further compromise. An IR Credit Pack is required for this service.

   • If yes: The sign-in was caused by a legitimate automated tool:

     1. Verify that the tool is authorized by your organization's security policy and document the exception.
     2. If acceptable: close the incident and consider adding the application or IP to an exclusion list to reduce future noise.

More information

• Microsoft Learn: Sign-in logs in Microsoft Entra ID
• Microsoft Learn: Investigate risky sign-ins
• MITRE ATT&CK T1078 - Valid Accounts