HackTheBox Meetup 0x2A: Talking NTLM Relay Attacks
Spent an evening at HackTheBox Meetup 0x2A and it was exactly the kind of night that reminds me why local security communities are worth showing up for. Good people, a relaxed setting, and a topic that everyone in the room had either exploited, defended against, or both. The meetup number being 0x2A (42 in decimal) was a nice touch for a hacker crowd too.
The Meetup Scene
If you’ve never been to a HackTheBox community meetup, the format is simple and that’s the point. People who are into offensive security, CTFs, and breaking things show up, someone leads a discussion or a talk, and the rest of the night is hallway conversations, war stories, and trading techniques over drinks. No corporate booths, no badges to scan, just people who genuinely like this stuff getting together.
The crowd was a mix of students, working pentesters, and a few blue-teamers who came to understand what they’re up against. That mix is what makes these nights valuable. You get the offensive perspective and the defensive one in the same conversation, and the questions people ask from each side sharpen everyone’s understanding.
The Topic: NTLM Relay Attacks
The main thing we dug into this time was NTLM relay attacks, building off the relay material a few of us had been working through. It’s one of those topics that sounds intimidating from the outside but clicks fast once someone walks you through the actual flow. We spent a good while going back and forth on the mechanics, the conditions that make it work, and how to shut it down.
Here’s the gist of what we covered.
What NTLM Relay Actually Is
NTLM authentication is a challenge-response protocol. When a client wants to authenticate to a server, the server sends a challenge, the client encrypts it with a hash derived from the user’s password, and sends it back. The server validates it. The key weakness is that nothing in the basic flow cryptographically ties that authentication to the specific server it was meant for.
That’s the whole opening. In a relay attack you sit in the middle. When a victim tries to authenticate to you (or you coerce them into it), you don’t try to crack anything. You take their authentication and immediately forward it to a different target server, authenticating as the victim. The target sees a valid authentication and lets you in. You never needed the password at all.
It’s the difference between trying to pick a lock and just walking the key over to a different door while the owner isn’t looking.
Getting the Authentication to You
Relaying is useless if nobody authenticates to you, so the first half of any relay attack is coercion. A few of the classic ways to make a victim authenticate to your machine:
- LLMNR/NBT-NS poisoning : when a host fails a DNS lookup it broadcasts to the subnet, and you answer, becoming the destination it tries to authenticate to.
- mitm6 : you abuse IPv6 by becoming the network’s DNS server via rogue DHCPv6, then redirect victims toward you.
- Coercion bugs : techniques that force a machine, even a domain controller, to authenticate to an arbitrary host on demand.
Once the victim is talking to you, the relay does the rest.
Why SMB Signing Matters So Much
The single most important condition we kept coming back to is SMB signing. If the target server requires SMB signing, the relayed session gets rejected because the attacker can’t properly sign the messages on the victim’s behalf. If signing is not required, the relay sails straight through.
This is why one of the first things you do on an engagement is scan the network for hosts that don’t enforce signing. Those are your relay targets. It’s also why, from the defensive side, enforcing signing everywhere is the highest-impact fix.
Relaying to Something Useful
Where you relay the authentication to is what turns a neat trick into a real compromise. Relaying to SMB on another machine where the victim is a local admin gives you code execution. Relaying to LDAP opens up options like modifying directory objects. And relaying coerced authentication to certificate services has been one of the more devastating chains in recent years, because it can hand you credentials for high-value accounts.
The recurring lesson was that the relay itself is simple. The art is in chaining it: who can you coerce, where can you relay them, and what does that identity let you do once you’re there.
Shutting It Down
We closed the discussion on the defensive side, which I always think is the part that makes you actually understand an attack. The big ones:
- Enforce SMB signing everywhere, the closest thing to a hard stop for SMB relay.
- Disable LLMNR and NBT-NS so the easy coercion paths dry up.
- Disable NTLM where you can and move to Kerberos, removing the vulnerable protocol entirely.
- Lock down the IPv6 and DNS angles that tools like mitm6 abuse.
- Channel binding and extended protection for services like LDAP and web endpoints, so a relayed session can’t be reused against them.
Why These Nights Are Worth It
What I like about working through a topic like this in a room full of people is that you hear all the little details that don’t make it into a writeup. Someone mentions a gotcha they hit on a real engagement, someone else explains why a defense they deployed didn’t work the way they expected, and suddenly the topic is three-dimensional instead of a flat set of steps.
You also leave with a list of things to go try. I came away wanting to rebuild the whole coercion-to-relay chain in a lab just to feel each moving part for myself, which is exactly the energy a good meetup should send you home with.
Big thanks to everyone who showed up and to whoever keeps these running. On to the next one.
HackTheBox Meetup 0x2A was a community evening focused on NTLM relay attacks. If there’s a HackTheBox meetup near you, go.
