Recommendation needed for SMB relay / Pass the hash attacks

Hi Forum, can anyone recommend a machine that I can work on to practice SMB relay or pass the hash attacks?

ta

Pass the hash you could do on any machine where you get an NTLM password hash at some point. The pass the hash part is the easy bit really, its getting the password hash in the first place that is what you should be looking into and practising. Once you’ve got the hash, there’s plenty of tools out there that will let you just supply that instead of a password and then they do the PTH for you (Evil-WinRM, plenty of Impacket scripts like wmiexec, psexec, smbclient, etc).

So there isn’t really much to practice with that last part, as you’re just running a script and supplying a hash. But if you really want to see an example of that, you can see me doing it with wmiexec if you skip to 4:50 in this video (after getting the hash with a DC sync attack) :

For SMB relay: As far as I know this requires you to have two target systems. System A which initiates the SMB authentication and system B to which you will relay the credentials. If successful, you will be authenticated to system B.
Relaying the authentication back to the same system should not work (there may be edge cases that I don’t know about, so feel free to correct me).
Also, before using this technique it’s good to check if the systems have SMB signing enabled+required, since that would mitigate the attack.

I don’t know of any boxes that interact with other machines in this way and didn’t find anything when searching for “relay” on ippsec.rocks.

As @VbScrub mentioned, doing the actual PTH is pretty simple. Getting there is most of the battle. If you want to do it yourself, try the Forest machine. It teaches some good Windows concepts in addition to PTH.

Oh and as for SMB relay - I believe that term just means NTLM relaying but targeting SMB as the service you want to access.

If that’s the case then I can’t think of any recent machines where that was useful. On the Forest machine that was recently retired, some people said in their writeups that they used NTLM relaying to gain membership to a certain security group… but when I looked into it I was 99% certain that didn’t actually gain them anything, as we already had permission to just add ourselves to that group (which is what I did). I’m pretty sure people were only doing it because that’s what a blog post told you to do as part of a setup for the attack, but on the HTB machine the first user account we get access to already has permission to just add new members to the relevant groups so the setup the blog post talks about is completely unnecessary.

A lot of the time for NTLM relaying you’d need multiple machines anyway, and on HTB machines we’re only dealing with single machines. Basically you’re trying to get a user from one machine to authenticate to you and then you relay that on to another machine so that you can access that machine as the original user. There are definitely ways to do this against a single machine for some services (to elevate you from one local account on that machine to another local account like System), but MS stopped you being able to do it for SMB a long time ago. See this quote from: MS08-068 Microsoft Windows SMB Relay Code Execution

“On November 11th 2008 Microsoft released bulletin MS08-068. This bulletin includes a patch which prevents the relaying of challenge keys back to the host which issued them, preventing this exploit from working in the default configuration. It is still possible to set the SMBHOST parameter to a third-party host that the victim is authorized to access, but the “reflection” attack has been effectively broken.”

@zaicurity said:
For SMB relay: As far as I know this requires you to have two target systems. System A which initiates the SMB authentication and system B to which you will relay the credentials. If successful, you will be authenticated to system B.
Relaying the authentication back to the same system should not work (there may be edge cases that I don’t know about, so feel free to correct me).

Ah you posted this while I was typing my novel :slight_smile:

For SMB relaying I agree, it should no longer be possible to relay back to the same machine. But for other services I believe it is still possible as I’m pretty sure that’s how RottenPotato and JuicyPotato work. Their technique is described as:

  1. Trick the “NT AUTHORITY\SYSTEM” account into authenticating via NTLM to a TCP endpoint we control.
  2. Man-in-the-middle this authentication attempt (NTLM relay) to locally negotiate a security token for the “NT AUTHORITY\SYSTEM” account. This is done through a series of Windows API calls.
  3. Impersonate the token we have just negotiated. This can only be done if the attackers current account has the privilege to impersonate security tokens. This is usually true of most service accounts and not true of most user-level accounts.

I did just find this timeline: Ghost Potato | Shenanigans Labs
Which states that MS patched this vulnerability in 2018. But that’s the first I’ve heard of that and I’ve used JuicyPotato successfully on recent HTB machines which I’d assume would have had this patch.

Thats really useful thanks for providing this

No worries, hope it helped a little