Offensive/Defensive Measures for Azure IPv6 support

Microsoft recently announced it would be officially supporting IPv6 for Azure AD services starting at the end of March 2023. Once this announcement was made this had got me thinking on the implications both from a penetration testing/red team perspective and the effect it will have with ongoing blue team operations.

The following announcement can be found here:

IPv6 Coming to Azure AD

So stepping back and looking at things from a penetration testing standpoint there are toolsets already available from an Azure AD perspective that you can utilize to perform attacks over IPv6.

For example, password spraying over IPv6 is possible with the combination of two tools:

GitHub - blacklanternsecurity/TREVORspray: TREVORspray is a modular password sprayer with threading,…

GitHub - blacklanternsecurity/TREVORproxy: A SOCKS proxy written in Python that randomizes your…

In order you use both the proxy tool and spraying tool you will need to run your proxy from a compute resource that has access to a /64 block of ip addresses. This makes Linode an excellent choice to run these type off attack operations from.

An Overview of IPv6 on Linode

So how do you start this type of attack during an authorized red team or penetration test engagement? There are a few issues to talk about first.

Maintaining OPSEC statement

When you spray over IPv6, any seasoned SOC team could see you coming as authentication requests are extremely rare over IPv6. It’s so rare if you audit the last 30 days of your sign in activity in Azure AD you may notice that all of your authentication traffic is probably going over IPv4.

Some cool things to note about spraying over IPv6 is that authentication requests may be classified as an unknown location. This is helpful to evade user and sign on risk detections if you happen to be testing a customer with Azure AD P2 licensing.

So how does all of this work between TrevorSpray/Proxy?

Command Line Spaying Tactics

On your linode box you will need to pull your IPv6 address:

ip addr show | grep inet6

So for example we can use trevorproxy with the subnet command and use the IPv6 subnet we are in:

sudo trevorproxy subnet -s dead:beef::0/64 -i eth0

Once we are ready to spray we need to create a SSH tunnel from the linode box to our local attack box:

ssh root@0.0.0.0 -L 1080:127.0.0.1:1080

Next you can attempt to spray over IPv6. Some command breakdowns to talk about.

-nl (No Looting)
-6 (prefer IPv6 over IPv4)
--proxy (use socks5 proxy)

Some of the reason why we want some of these options is to maintain OPSEC over the linode box. For example if you get a valid account/password pair you do not want it to immediately loot the account looking for MFA bypasses. This will expose your linode IPv4 address (Would look really bad on a red team).

So your spray command may look like the following:

trevorspray -u users.txt -p 'Winter2023!' -nl -6 --delay 5 --random-useragent --proxy socks5://127.0.0.1:1080

Defensive Perspectives

So from a pure defensive perspective you will see authentication attempts coming from multiple IPv6 addresses.

Figure 1 — Azure AD Sign In Logs

Next if we drill down into the location details you will see that we are coming up empty as to where this IPv6 location is actually from. I do have this classified as a hostile country but we will get to that later.

Figure 2 — No location details

When you log into Azure you will see a notification on taking appropriate action in your named location policies similar to the one below.

Figure 3 — Azure AD IPv6 Alert

System Administrators may wish to take additional action with some of their named location policies. In this example I updated my hostile countries list to include unknown counties or regions. Then in a conditional access statement I will block any hostile countries from authenticating into my environment. Enterprises will typically maintain a list of countries that they don’t want authenticating to their Azure environment. (Reminder: Blocking locations in Azure is not a security boundary. Attackers will just simply proxy into a device to get around conditional access blocks. This will however effectively block IPv6 if you have this location configured to be blocked inside of conditional access)

Figure 4 — Hostile Countries Location Settings

The other issue this will create is defenders will not have any telemetry on where IPv6 requests are geographically coming from. This creates issues in trying to determine if a request is actually legitimate. For example Apple devices have a feature called Private Relay for paying iCloud customers that you can easily switch on. This hides your actual ip address when using the safari internet browser.

Figure 5 — iCloud Private Relay Settings

What this does in the background is your IP is anonymized over IPv6. A simple search on google can reveal what IP address your safari browser is using.

Figure 6 — IPv6 Address Using iCloud Private Relay

As more services such as these become mainstream it may also create issues for blue team defenders protecting their azure environments when they are unable to determine a geolocation of a request.

Conclusion

Once IPv6 support is turned on for Azure Services it will be really important for enterprises to be ready for these scenarios to be introduced into your environment because I am suspecting they will happen. What can defenders do to protect Azure Assets?

• At the time of this writing IPv6 requests will come from unknown locations. Hopefully that will change. You can use services such as Maxmind to get location data telemetry for authentication requests.

GeoIP2 Databases Demo

• If you are an E5 customer make sure you have user/sign-in risk policies configured and enforced.

Figure 7 — User/Sign-In risk policies

• Alternatively you can control these types of actions through a conditional access template policy. They can be found under the Zero Trust section.

Figure 8 — Zero Trust Conditional Access policies

• Privileges RBAC roles in Azure should be cloud only accounts and should be backed with FIDO2 authentication keys
• All end users should have MFA protection with number matching or OTP codes with an authenticator app. Push notifications should not be in use. The following Microsoft Article explains how to turn on number matching in the Azure Portal.

Use number matching in multifactor authentication (MFA) notifications - Azure Active Directory …

• Require MFA for All Guest Access
• Restrict Service accounts from logging into cloud workloads if its not needed.
• Adopt Zero Trust Concepts in your Azure environment. Microsoft has some very amazing deployment plan guidance on how to get started.

Zero Trust deployment plan with Microsoft 365

• Consider requiring hybrid Azure AD joined devices or compliant devices in conditional access when authenticating to cloud workloads. More information can be found here:

Require compliant, hybrid joined devices, or MFA - Azure Active Directory - Microsoft Entra