Anatomy of a Sophisticated Multi-Infrastructure Password Spray Campaign
Overview
Between October 17th and 21st 2024, the detection team at Petra observed a password spray campaign targeting three of our Microsoft tenants. The threat actor employed multiple evasion tactics: maintaining a low-and-slow tempo, rotating IPs and user agents, and using 14 diversionary accounts to obscure their focus on two primary targets. The campaign began with Russian infrastructure before pivoting to Vietnamese networks, demonstrating both operational sophistication and persistence.
Campaign Statistics
Total Duration: 4 days
Total Failed Attempts: 25
Unique Accounts Targeted: 16
Unique Tenants Targeted: 3
Infrastructure Sets: ASN 35048 (RU) and ASN 150820 (VN)
Primary Target (User c): 8 attempts across both infrastructure sets
Secondary Target (User a): 2 attempts across both infrastructure sets
Log Analysis
Here’s an anonymized timeline of all the failed login attempts that were observed.
Campaign Infrastructure Evolution
Initial Phase - Russian Infrastructure (ASN 35048)
The threat actor initially operated from Russian infrastructure (ASN 35048) between October 17-20, generating 14 failed login attempts. During this phase, they alternated between two user agent signatures: Windows 10 with Firefox 105.0.0 accessing Azure Portal, and Windows 10 with an undetermined browser and application.
Infrastructure Pivot - Vietnamese Infrastructure (ASN 150820)
The campaign then pivoted to Vietnamese infrastructure (ASN 150820) on October 21, 2024, where they attempted 11 failed logins. The tooling changed but remained consistent throughout this phase, primarily using iOS and an unknown browser to access Microsoft Authentication Broker.
Persistent Targeting of Users c and a
The strongest evidence for all this activity belonging to a single campaign comes from the attacker's persistent targeting of specific accounts across both infrastructure sets.
User c - Primary Target
User a - Secondary Target
Sophisticated Evasion Techniques
The campaign only consisted of 25 attempts across 16 accounts over 4 days, with the most targeted account (user c) receiving only 7 attempts spread across both infrastructure sets - effectively bypassing traditional brute force detection thresholds. The attacker never reused the same CIDR block, pivoted from Russian to Vietnamese infrastructure, and changed their user agent signature from Windows 10 to iOS in further efforts to evade any signature-based detections. The attacker also continued to focus on accounts a and c across both infrastructure sets while using other accounts as noise to obscure the primary targets.
Detecting this Campaign with Behavioral Signals
While traditional brute force detection focused on IP-based rate limiting would miss this campaign, Petra's ASN-based behavioral analysis enabled real-time detection of this sophisticated attack. By tracking the patterns of failed login attempts over time, we identified both ASN 35048 and ASN 150820 as exhibiting suspicious patterns of failed authentications across multiple accounts and organizational boundaries.
Once these ASNs were identified as suspicious, any successful authentication attempts from these networks could be automatically flagged as high-risk compromises requiring immediate investigation.
This detection methodology has proven particularly effective for catching low-and-slow campaigns that deliberately operate below traditional threshold-based alerting, while also providing a defensive advantage that persists even when attackers switch infrastructure or modify their tooling.
Hunting for This Threat in Your Environment
KQL
If KQL is your preferred method to analyze logs, a quick check for any logins from Vietnam or Russia would help identify whether this threat campaign is ongoing within your environment. NOTE: this would generate a lot of false positives if users are either visiting these countries for business or frequently utilizing consumer VPN clients.
SigninLogs
| where TimeGenerated > ago(30d)
| where LocationDetails.countryOrRegion in~ ("RU", "VN")
| project TimeGenerated, UserPrincipalName, Status.errorCode, Status.failureReason, AppDisplayName, ResourceDisplayName, LocationDetails.countryOrRegion, IPAddress
| sort by TimeGenerated desc
Powershell
ADSignInLogsGraph‐Analyzer by Invictus-IR is an excellent tool for pulling and analyzing logs via Powershell. If you have a P1/P2 license and an API key for IPInfo, you can look at the output file Hunt.xlsx generated by this script and search for any occurrences of the ASNs 35048 and 150820.
Protecting your Environment
If you would like to prevent any login events from these IPs within your Azure tenant, you can take the steps detailed below to add conditional access policies that blocklist these IPs.
Step 1: Create Named Location with IPs
In the Azure portal:
Navigate to Azure Active Directory > Security > Conditional Access > Named locations.
Click New location.
Name the location (e.g., "Blocked IPs - Threat Actor").
Under IP ranges, upload a .csv file with the following IP addresses:
45.134.252.249, 46.8.56.158, 188.130.221.209, 194.35.113.174, 188.130.137.145, 45.151.145.79, 45.142.252.226, 188.130.188.246, 188.130.189.155, 95.182.124.245, 213.226.101.221, 45.86.0.254, 185.181.247.90, 45.81.137.89, 160.22.174.97, 157.15.38.166, 160.22.175.118, 160.30.190.54, 160.187.120.48, 157.15.38.88, 157.15.38.99, 160.187.121.59, 160.187.120.105, 160.22.174.188, 160.187.120.52
Save the named location.
Step 2: Create Conditional Access Policy
Navigate to Azure Active Directory > Security > Conditional Access > Policies.
Click + New policy.
Name the policy (e.g., "Block Threat Actor IPs").
Under Assignments:
Users or workload identities: Select All users or specific groups/users you want to protect.
Cloud apps or actions: Select All cloud apps (recommended) or specific apps.
Conditions:
Select Locations.
Include the newly created named location ("Blocked IPs - Threat Actor").
Under Access controls:
Choose Block access.
Enable the policy.