Thread by @Alex_T_Weinert

Ok, so here's my take and recommendations from Identity Security lens on the #log4j2 vuln impact for #zerotrust and #AzureAD. TLDR: It's time for "EXTREME ZT: LPA ALL THE THINGS!" <thread>

The simple fact is that for whatever reason, we're getting an amazing look at what happens when responsible disclosure doesn't go to plan and the attackers and the defenders get vuln info at the same time. As a defender, you are certainly in a deep assessment/patching phase...

But you have a super complex environment evolved over years. All of your endpoints, all of the apps you depend on, all of your IoT devices, OT devices, etc. are potentially vulnerable and being probed for impact... and even you aren't sure where log4j2 has been used.

While we all work on formal guidance (soon) I want to say: NOW is definitely the time to get aggressive on your #ZeroTrust deployments. Guidance at aka.ms/zerotrust and if you are down the path, great.

And the core guidance at aka.ms/securitysteps is still valuable. But I want to get a little more specific.

Figure what's happening is that everything in your environment is getting blasted with permutations of the strings that trigger this vuln in hopes of getting them to hit logging and trigger the issue. Lots of experiments.

For SaaS apps, you are relying on vendors to detect and mitigate these attacks, patch as fast as they can, etc. But this burden falls to you for your LOB apps, things you've bought & deployed, things that run in your own cloud or that you manage in hosting providers like Azure.

And you are in a drag race. You need to block as much exposure as possible while the experiments are running - reduce the probability that an attacker finds a way to trigger the vuln in your infra.

And you can't know if things are pre-auth or post-auth. But a lot of logging gets done post-auth, so there's meaty protection available by blocking anomalous authentication.

So if I were you, using Azure AD Conditional Access, I would get really aggressive for all apps you haven't verified as issue free. You can use app tagging to help reduce business impact. This blog has deets. techcommunity.microsoft.com/t5/azure-activ…

1. Keep the volume attacks out by requiring MFA for access. Get it done. This, by itself, keeps the majority of the randos out. docs.microsoft.com/en-us/azure/ac…

2. If you use Identity Protection, use it to block risky logins to your not-yet-audited apps. This will block TOR and anonymizing VPNs, from which most of the probing is happening, but also any other weird behavior indicating "not actually your user." docs.microsoft.com/en-us/azure/ac…

3. Require Azure AD Joined or better, InTune managed devices to access these resources. This will help ensure traffic is only coming from trusted devices and reduce malware risk. docs.microsoft.com/en-us/azure/ac…

4. Use IP location features to restrict access to reasonable locations or trusted networks where it makes sense. docs.microsoft.com/en-us/azure/ac…

5. Attackers are really into the whole using the app to attack the app thing, so apply these rules to applications/service principals too. docs.microsoft.com/en-us/azure/ac…

5. And while none of us are thrilled about working the weekend keep an eye on the identity anomalies for your users and apps! docs.microsoft.com/en-us/azure/ac…

6. While ADFS doesn't use Log4j, other federation providers do, so I'd also recommend taking a look for minted or anomalous tokens. Likewise, Log4j is likely running on client endpoints, so keep an eye out for token theft. Help for both here: techcommunity.microsoft.com/t5/azure-activ…

Good luck everyone :) We'll be providing more than ad-hoc tweet threads soon!

Bonus: docs.microsoft.com/en-us/azure/ac…

(If you have trust relationships with such providers)

OK, getting a question on this so if it isn't clear: people are poking around. Mostly unauthed, but hackers will use the accounts they have - mostly non-MFA accounts from TOR or other random locations on new-to-your-environment machines - to probe post-auth exploits.

This thread is about cutting off access to explore post-auth vulns in your systems.

Because log4j moves us from "A hacker stole a user's password and read their paystub" to "a hacker stole a password and took control of the payroll server" * every LOB app in your environment. It's the same old guidance, the criticality in respect to this code injection is ++

And finally: msrc-blog.microsoft.com/2021/12/11/mic…