Risky IP feature of AAD Connect Health came to public preview in early May. With AAD Connect Health you can monitor sign-ins and send data to the cloud where it will be analyzed. Together with ADFS Extranet Lockout it helps to monitor and detect password brute force and spray attacks.
AAD Connect Health can be used for:
Installation guidance found from here
What’s Risky IPs in ADFS (docs.microsoft.com)
Additionally, it is possible for a single IP address to attempt multiple logins against multiple users. In these cases, the number of attempts per user may be under the threshold for account lockout protection in AD FS. Azure AD Connect Health now provides the “Risky IP report” that detects this condition and notifies administrators when this occurs. The following are the key benefits for this report:
- Detection of IP addresses that exceed a threshold of failed password-based logins
- Supports failed logins due to bad password or due to extranet lockout state
- Email notification to alert administrators as soon as this occurs with customizable email settings
- Customizable threshold settings that match with the security policy of an organization
- Downloadable reports for offline analysis and integration with other systems via automation
Risky IPs in Action
As a pre-requirement I have configured on-premises Active Directory Domain account lockout policy and password policy to following values:
- Account Lockout duration & Reset Account lockout counter after: 15min
- Account Lockout threshold: 10
Extranet account lockout policy with following values:
- ExtranetLockoutThreshold: 5
- ExtranetObservationWindow: 30min
$Timespan = New-TimeSpan -Minutes 30
Set-AdfsProperties -EnableExtranetLockout $True -ExtranetLockoutThreshold 5 -ExtranetObservationWindow $Timespan
After pre-reguirements configuration it’s time to perform attack simulation against my ADFS instance. Trying to logon multiple times with my test account.
Because of ”Extranet Account Lockout” policy my test account stays active and is not locked out at on-premises AD. This policy defines that authentication requests are not sent after 5 attempts to the domain controller.
After short period of time I navigated to Azure AD portal and AAD Connect Health blade where my Risky IP’s were visible
I tried to find same IP from Azure Traffic Analytics as malicious traffic but was unable to do so. Either my queries were build wrongly or this kind of traffic is not visible from Network Analytics. If latter is the case it would be nice to see Risky IP traffic as malicious traffic in Traffic Analytics. Of course then assumption is that VMs needs to be located at Azure datacenters as I have in my environment.
What I found was all traffic I generated to random ports during test sessions.
After I frustrated myself with Traffic Analytics I tried to find my Risky IP from NSG Flow logs from storage accounts and it was successful. This data was then imported to human readable format to JSON editor.
Now the Risky IP has been identified, what’s next
- It can be blocked at firewall
- If we take another angle and look this from identity point of view, Trusted locations can be defined to Azure AD which helps to define Conditional Access policies when protecting identities