In this section
Active Reconnaissance — Probing Without Being Caught
You've seen port scans in your firewall logs. You've investigated brute-force alerts and credential-spray detections. This section explains why those detections catch the amateur but miss the professional, and why the gap is not a technology problem. It is a threshold problem that the attacker understands better than you do.
Scenario
Your firewall logs show 3,000 connection attempts to port 443 across your external IP range from a single source over 90 minutes. That is a scan: obvious, noisy, and easily blocked. The same day, an attacker sends a single authentication request to your OWA endpoint with a valid username and invalid password. That is also active reconnaissance: testing whether the account exists by observing the error response. One triggered five alerts. The other triggered zero. The difference is not sophistication. It is the attacker's understanding of your detection thresholds.
Your thresholds were designed for the wrong attacker
Every security product ships with reconnaissance detection thresholds: account lockout after five failed attempts, brute-force alerting after ten failures in five minutes, port scan detection after a hundred SYN packets in ten seconds. These thresholds catch the script kiddie running Hydra at maximum speed.
The professional attacker knows your thresholds. One attempt per account per hour, from a rotating pool of residential proxy IPs, with randomized timing jitter. That is 24 passwords tested per account per day from IPs that change with every request. No individual account hits lockout. No individual IP triggers the rate limit. No individual event is anomalous. Residential proxy services (available for $5-10 per gigabyte) provide IP addresses from real ISP ranges that don't appear on commercial threat intelligence blocklists, making IP-based detection even harder.
But in aggregate, across your entire tenant, someone is testing 1,000 accounts at one password per hour. That is 1,000 failed authentications spread across 1,000 accounts and 1,000 IPs over 60 minutes. The aggregate pattern is a coordinated spray. Each individual event is indistinguishable from a user mistyping their password. Your SIEM has every event. Your rules don't correlate them into a pattern because they evaluate each event in isolation.
The attack is invisible to per-entity rules and visible only to cross-entity correlation over extended time windows. This distinction between per-entity detection and cross-entity correlation is the central detection engineering challenge for reconnaissance, and it recurs throughout Modules 5 through 8 for post-exploitation techniques.
The same 487 authentication failures appear as noise in the per-entity view (left) and as a coordinated spray in the cross-entity view (right). Most detection rules evaluate the left view.
Password spraying
Password spraying is the most common active cloud reconnaissance technique because it combines breached email lists from passive reconnaissance (Section 1.5), common password patterns, and legacy authentication endpoints into an attack that is operationally cheap and technically simple.
The attacker starts with valid email addresses from passive reconnaissance, selects one password to test (Spring2026!, Company123!, Welcome1!), and configures their spray tool to attempt one authentication per account per hour through residential proxies. After 24 hours, one password has been tested against every account. After a week, seven passwords. In a 500-account organization, at least one user typically has a password matching the top 20 patterns.
The authentication endpoint matters. Attackers target legacy endpoints (Exchange ActiveSync, IMAP, POP3, Exchange Web Services) that may not trigger Entra ID risk policies, may not be subject to smart lockout, and may not produce the same sign-in log entries as modern authentication. If your organization has not blocked legacy authentication, you have spray-vulnerable endpoints that bypass your primary detection.
When the spray succeeds, there is no failed-login alert because the login succeeded. The sign-in log shows a successful authentication from an unfamiliar device and location. The alert, if one fires, is "unfamiliar sign-in properties" at medium severity. Your detection requires two layers: cross-account correlation for the spray pattern itself (many accounts, one failure each, distributed IPs) and post-authentication anomaly detection for the successful credential (unfamiliar device combined with immediate discovery commands equals compromised account).
The per-entity view shows nothing anomalous. The cross-entity view shows a coordinated operation. Detection requires the second perspective. Module 4 covers spray detection rules in detail.
Network probing
Fast network scans are trivially detected. Slow scans are not. One port per target per minute, from rotating IPs, over three days. Your firewall logs every connection attempt. No volume threshold fires because no single source IP or destination port accumulates enough events within any detection window.
The slow scan works because internet-facing services receive legitimate connection attempts constantly. Web crawlers, academic research scanners, Shodan, Censys, and misconfigured clients all produce connection events that look identical to attacker reconnaissance. A single SYN packet to port 443 from an IP address you've never seen before is indistinguishable from a CDN health check, a search engine crawler, or an attacker probing your web server. The attacker hides in this noise by operating at the same pace and volume as legitimate traffic.
Over three days, the attacker identifies every open port on every external IP, captures service banners revealing software versions, identifies TLS certificates revealing internal hostnames (reinforcing the CT log findings from passive reconnaissance), and discovers forgotten services: the development server IT deployed two years ago with an expired certificate and an unpatched web framework. They also identify which services require authentication and which accept anonymous connections, narrowing the target list for the next phase.
Volume-based detection catches fast scans. Time-window correlation catches slow scans if the window is long enough, at least 72 hours. The trade-off is that longer windows produce more false positives from legitimate scanners. The detection approach is to baseline your normal external scanning traffic over a two-week period and alert on statistical deviations from that baseline rather than on absolute volume. A sudden increase in unique source IPs probing a specific port range over 48 hours is more meaningful than a raw count of connection attempts.
Cloud tenant enumeration
Microsoft's public APIs allow attackers to confirm your tenant exists, enumerate valid usernames, and discover your federation configuration without producing a single sign-in event.
The GetCredentialType endpoint (login.microsoftonline.com/common/GetCredentialType) accepts a username and returns structured information about the account: whether it exists, what authentication methods are configured (password, FIDO2, phone), and whether the tenant uses federation with an on-premises identity provider. The response differs measurably between valid and invalid usernames, allowing automated enumeration at scale. Tools like o365creeper, trevorspray, and MSOLSpray automate this process. The attacker feeds in potential usernames generated from LinkedIn names combined with the email format discovered during passive reconnaissance and receives a validated target list for the password spray.
Federation discovery is particularly valuable to attackers. If the GetCredentialType response indicates ADFS or PingFederate federation, the attacker knows that authentication flows through an on-premises server rather than Azure AD directly. This changes the attack approach: the federated identity provider may have different lockout policies, different logging configurations, and different MFA enforcement than the cloud tenant. Some federated configurations pass authentication through to the on-premises provider without applying Entra ID Conditional Access policies, creating a bypass path.
You cannot prevent enumeration at the API level. Microsoft's public authentication endpoints must accept arbitrary usernames to function. The defensive response is resilience, not prevention: assume the attacker already knows your tenant exists and which usernames are valid. Enforce phishing-resistant MFA so that enumeration findings are unexploitable. Block legacy authentication so the spray has no vulnerable endpoint. If you use federation, ensure your on-premises identity provider enforces the same MFA and lockout policies as your cloud tenant. Your defense is not preventing the reconnaissance. It is making the findings useless.
Credential stuffing
Unlike spraying (which guesses passwords), credential stuffing uses known passwords from breach databases or infostealer logs. If the password was reused, the authentication succeeds on the first attempt. There is no failed-login trail to detect.
The infostealer pipeline described in Section 1.5 feeds directly into credential stuffing operations. An employee's personal device is infected with Lumma or StealC. The stealer captures their M365 password and a valid session cookie. The attacker (or a broker who bought the stealer log) tests the credential against the organization's login endpoint. If the password still works, authentication succeeds immediately. If the session cookie is still valid, the attacker bypasses MFA entirely because the cookie represents an already-authenticated session.
The successful credential stuff produces one log entry: a successful sign-in from an unfamiliar device. Not a failed login. Not a spray pattern. A single successful authentication that looks exactly like a user logging in from a new phone.
Your detection is post-authentication behavioral analysis. The authentication event itself is indistinguishable from legitimate access. The signal comes from what happens after authentication. Does the account immediately run discovery commands? Does it access mailboxes or SharePoint sites it has never accessed before? Does it create inbox rules or OAuth consent grants within minutes of signing in? Does the user agent string or client application change between the authentication event and the subsequent activity? These behavioral indicators are the detection surface for credential stuffing, and they are covered in detail in Module 5.
The gap between credential stuffing and password spraying creates a detection asymmetry that matters for your architecture. Spraying produces failed-login telemetry that cross-entity correlation can detect before any account is compromised. Stuffing produces no pre-compromise telemetry at all. Your only detection opportunity is post-authentication behavior. Organizations that invest only in pre-authentication detection (lockout, spray detection, impossible travel) miss the entire credential stuffing attack surface.
Account lockout after five failures defends against brute force (many passwords against one account). It does not defend against spraying (one password against many accounts). A spray that tests one password per account per hour never triggers lockout on any individual account. The SOC reviews the lockout logs, sees no lockouts, and concludes no spray is occurring. The spray has been running for a week. Cross-entity correlation across all accounts over extended time windows is the only detection approach that works against professional-grade spraying.
Offensive Operations Principle
Active reconnaissance generates telemetry because it touches your infrastructure. The detection challenge is distinguishing attacker probing from legitimate traffic. Per-entity thresholds catch the amateur. Cross-entity correlation over extended time windows catches the professional. The gap between those two detection levels is where targeted attackers operate.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.