Microsoft Entra ID, formerly Azure AD, features federation enabling authentication delegation to external Identity Providers (IdP). The trust between Entra ID and the external IdP relies on a signed token 🔐

The external IdP signs the token with a private key, with the public key configured in Entra ID. But actually, Entra ID can be configured to accept two token-signing certificates and both are equally accepted as token signers! 💥 This second token-signing certificate may be overlooked by defenders and their security tools! 👀

In this post, I’ll show you where this certificate can be found and how attackers can add it (given the necessary privileges) and use it to forge malicious tokens. Finally, I will provide some recommendations for defense in light of this.

➡️ Find this article on Tenable’s TechBlog: Exploiting Entra ID for Stealthier Persistence and Privilege Escalation using the Federated Authentication’s Secondary Token-signing Certificate

Microsoft Entra ID (formerly known as Azure AD) allows delegation of authentication to another identity provider through the legitimate federation feature. However, attackers with elevated privileges can abuse this feature, leading to persistence and privilege escalation 💥.

But what are exactly these “elevated privileges” that are required to do so? 🤔 In this article, we are going to see that the famous “Global Administrator” role is not the only one allowing it! 😉 Follow along (or skip to the conclusion!) to learn which of your Entra administrators have this power, since these are the ones that you must protect first.

➡️ Find this article on Tenable’s TechBlog: Roles Allowing To Abuse Entra ID Federation for Persistence and Privilege Escalation

J’ai eu la chance de présenter à la conférence Identity Days 2023.

I had the chance to speak at the Pass the SALT 2023 conference.

On a Windows machine, we can find users’ certificates stored in files in C:\Users\<USER>\AppData\Roaming\Microsoft\SystemCertificates\My\Certificates (i.e. %APPDATA%\Microsoft\SystemCertificates\My\Certificates). These files have seemingly random names (i.e. “3B86DFC25CFB1B47EB4CBF53FD4028239D0C690E”) and no extension. What is their format? How to open them in code? With which Windows APIs? 🤔

Let me spoil you with the answers right away, including code samples, and I’ll describe after what I tried and what I learned 💡

➡️ Find this article on Tenable’s TechBlog: How to read Windows serialized certificates (with code sample)

I investigated a situation where an SMB client could not connect to an SMB server. The SMB server returned an “Access Denied” during the NTLM authentication, even though the credentials were correct, etc. The only unusual thing is that the SMB server was accessed through a NAT mapping! Which made me think that this setup was in fact similar to an NTLM relay (aka SMB relay) attack. 💡 And indeed, the server had the “Microsoft network server: Server SPN target name validation level” policy (i.e. SmbServerNameHardeningLevel registry key) enabled which blocked this scenario!

😉 This situation could also occur in your regular SMB environments, so follow along to see how to troubleshoot this, how it is configured, how it works and what we suggest to do in this case.

➡️ Find this article on Tenable’s TechBlog: SMB “Access is denied” caused by anti-NTLM relay protection

I had the chance to speak at the SharkFest’22 Europe conference.

Have you ever wondered how to decrypt Kerberos/NTLM “encrypted stub data” fields 🔐 in Wireshark when analyzing Kerberos, RPC, LDAP… traffic?
➡️ Read how to do it on Tenable’s TechBlog: Decrypt Kerberos/NTLM “encrypted stub data” in Wireshark

An Active-Directory domain controller running as a virtual machine hosted by a compatible hypervisor is able to detect when it has been restored from a snapshot, thanks to the Virtual Machine Generation ID feature. In this case, it goes into a safe passive mode before retrieving the latest changes from other domain controllers (to avoid USN rollback issues, RID reuse, etc.). The same can be observed on the DFS-R side.

💡 This is a practical safety feature in production environments, but it can create tricky issues in labs and even break them… Let’s see how to disable it (in labs only)!

Windows offers built-in audit policy settings to configure which events should be logged. But when testing those options, we noticed surprising behaviors that can lead to missed events. When you configure your Active Directory domain controllers to log security events to send to your SIEM and raise alerts, you absolutely do not want any regression which would ultimately blind your SOC! In this article we will share technical tips to prevent those unexpected issues.

➡️ Discover this article on Tenable’s TechBlog: Don’t make your SOC blind to Active Directory attacks: 5 surprising behaviors of Windows audit policy