Easy as Pi
One Raspberry Pi, two red teamers and a simple mission: hack grandma
When reading this post, keep in mind I am working against my own home network. These types of activities should be limited to networks you own or have permission to poke at, whether at home or remote. This post is written in good fun but keep in mind, I had the permission of those in my home to do the security testing outlined here - as you always should - before attempting a similar exercise.
After building a Raspberry Pi “attack box”, of course I want to kick the wheels and take it for a spin before I get called into my next red team operation.
But what to do?
I could do the normal thing and ping our CEO Spencer Thompson and do a basic web penetration test against our site. But our site is pretty limited and doesn’t offer a lot of “meat” to go after. Plus, I’ve done about a million of these so I want to try something new.
Part of being a red teamer means being creative. Thinking outside of the box. Ideas, ideas, ideas…
I’ve got it! With the world shut down and everyone working from home, what if I plug my Raspberry Pi into my home network and see if I can gain a foothold onto one of my in-law’s devices! They’ve been staying with us to help take care of James, my 8-month old son. Challenge accepted.
Rules of engagement
April 14 (6:45pm)
Every good red team operation starts here: defining the rules of engagement.
For my Work From Home (WFH) security test, I’ll aim for the following:
Assumed network breach scenario. I’ll connect my Raspberry Pi to my home’s guest WiFi network and use that as my starting point.
I will use my Raspberry Pi attack box to drive the operation. It will be my attacker machine.
All IP addresses in the network are in scope and fair game. It’s a small home network, so I’ll need everything I can get my hands on.
If I land on a device, I’m to gain proof-of-entry only and will not take additional steps. This is to maintain the ecosystem in my home.
An actual guest of mine could take these steps or a contractor or burglar could plug a device into my router, television or other Internet-capable devices to mimic this type of initial foothold. All very reasonable, realistic scenarios.
For reference, I’m “live-blogging” the steps here as I go, so I have no idea how this post will turn out.. so here goes!
Planning
April 14 (7:10pm)
With the rules of the game set, it’s time to think through what I’m going to do. Let’s sketch out a general plan:
Scanning: try to figure out who is on the network and where they are.
Prodding: send some more aggressive packets to some of the interesting IP addresses I find.
Attacking: see if I can take advantage of any found information in order to gain an initial foothold on any other devices.
Advanced: if I’m struggling, see if I can send a phishing email to someone in the house and get a link-click to open up access. Or maybe I can attempt some man-in-the-middle attacks if I’ve gained enough information.
I’ll be controlling two computers through this exercise: my MacOS (to write this post) and my Manjaro Raspberry Pi (to do the assessment).
Plus, James will be assisting. Two red teamers on this operation, now dubbed GRANDMA.
Scanning
April 15 (7:56am)
Time to get started. I have a day job so this task may take several days.
Remember how I like to have a toolbox/ directory on my attack box, where I have local installations of tools I commonly reach for? That’s where I’ll be working from when not driving the commands from Operator.
Popping open Operator, let’s start with the built-in ARP scan against my local agent (on the Pi), to see what’s online right now:
A handful of devices online. I recognize my Mac and I can what may be my AppleTV (entertamentroom, by the way, did I name this thing?) and what appears to be my router (rt-ac3100-3888).
Running commands out of Operator gives you a distinct advantage: parsing. All output is automatically parsed for Indicators of Compromise (IoC), such as host names, file paths, SSH commands - or in the above example - IP addresses. And this info is saved to the agent, so I don’t need to take notes by hand as I go.
The IP addresses are helpful to record. Not sure offhand if they’re dynamic (changing) or static on my network, so I may have to re-run this later to double-check.
After each IP address, I can see the MAC address of each device. Another thing to tuck away for now.
Because 192.168.1.1 looks like a router, let’s see if I can get on the web interface:
No dice. But this makes sense. I’m on the guest WiFi network, no access to the network interface/GUI.
Well, no one but me is connected to the network, according to my first scan, so I’ll pause here at come back.
Alex, Lewis and I were talking the other day about having the ability to complete long-running “missions” where Operator can keep tabs on things like the results of an ARP scan and automatically continue to the next step once a change is detected.
April 15 (9:05am)
James alerted me to coffee being made in the kitchen, so I know now it’s a matter of time before new devices start coming online. Let’s check:
Targets acquired. Welcome to the party 192.168.1.112, 192.168.1.133, 192.168.1.134 and 192.168.1.80.
Not that I anticipate someone attempting to ARP poison me at home but I am fudging MAC addresses because they’re “unique” identifiers, in a sense.
Let’s write a new TTP for local network sniffing and point it at these new devices. This will help determine what type of device each is. I’ll toss the flags -Pn and -sV on the NMAP scan, to bypass any ping deflection protection the router may be imposing on my requests and to determine the service versions of any discovered ports.
Service versions are useful because they can be cross-referenced with known CVE’s for quick exploit discovery.
OK now I’m getting somewhere. The mobile devices, presumably the watch and iPad, aren’t giving me any feedback on the scan. I’m feeling lazy today, so I’ll sideline these for now, maybe come back if I’m struggling later. Let’s focus on the (by logical deduction) laptops and go deeper on a few interesting open ports.
Prodding
April 15 (9:12am)
Opening a normal terminal (remember, Operator isn’t a throwing framework and the reverse shell currently can’t handle interactive prompts) I’ll try to straight up SSH into the devices with port 22 wide open.
In all 3 cases, an initial root password attempt is a no-go. Two of the computers are set to allow two connection attempts then close the connection, the last one (192.168.1.80) allows three. Maybe I can brute force credentials? Back to Operator.
Note that I’m calling a built-in NMAP (LUA) script to attempt common SSH password combinations.
Shoot, my wife just grabbed James for his physical therapy session. I’m down a red teamer. That’s OK, this scan may take a few minutes, so I’ll refill on coffee and regroup when my teammate is back.
Attacking
April 15 (12:19pm)
Scan results and James are both back. However, all three scan results turned up empty. Hmm.
I’ve probably accumulated enough data to move into the attacking phase of this operation. The big things I’m tracking are:
An open HTTP port (80) on what I’d anticipate is a laptop. Based on the name of the computer, I would have thought it was Windows but there’s an open SSH port on it so your guess is as good as mine.
An open SSH port (22) on the 3 computers, which could allow me direct access to the shell
Despite my previous brute-force SSH attempts failing before, I just used NMAPs default password lists. I wonder what would happen if I use some of my own?
I’m a big fan of leveraging Markov chains generated from HashCat when creating a password list because I can feed in specific words of meaning (to my target) and get all the logical variations a user may be using.
Today, I’m going to use an open-source variation of this type of attack called Cupp. This Python-based tool asks me personal questions about my target, which uses that information to generate unique password lists. Things like pet names growing up, birth days, spousal information and the like.
Because I’m targeting my in-laws, I’m going to plug in the personal information about them I know, along with my wife and myself.
Awesome, 23,944 potential passwords generated.
That’s a lot of passwords, so let’s try the first IP on my list: 192.168.1.80. Why this one? It was the only host that allowed 3 SSH connection attempts manually, which means it’s likely running default SSH protections and a brute-force attack will have more success.
Bingo!
OK, but from past experience, brute force password guessing runs high on the false positive scale… so will this actually work?
Popping a manual shell, because remember Operator doesn’t (yet) support interactive password prompts within its reverse-shell capability, I give it a shot and immediately attempt to drop to root, re-using the password:
No false positives here - got you!
I have now successfully hacked my mother-in-law from my Raspberry Pi attack box. Turning on the webcam, I introduce myself.
April 15 (2:15pm)
With a squeal from James, Nicole is upstairs in a flash. She must have been notified. My operation has been compromised. Surrounded by terminals, with her mother’s details still on screen from my Cupp password dumping, it doesn’t take her long.
As a red teamer, this is where things get tricky.
I could put on my purple team hat and discuss the value of a security assessment at home and how, if we do it together, we could create a safer home for James. But I’ve been down this road before so it’s time to wrap up the operation.
Could I try other things? Probably. My list would likely be:
Attempt my SSH brute-force attacks on the other 2 computers in my home with open SSH ports.
Poke at the open HTTP port which is running on one of the computers.
See if I can hop from the guest network to the main WiFi SSID, in order to poison every computer’s ARP table and conduct man-in-the-middle attacks. This would ensure all traffic goes through my computer en route to the router, sort of like a proxy. There are some cool tricks in this type of attack, which will even allow me to see exactly what the computer user sees, graphically.
Send a phishing email to my in-laws and see if they bite, allowing me to gain a foothold on a computer. I’d need to bypass whatever email spam/filtering/protections the computer is running though, which can be a pain.
Drop an infected rubber ducky somewhere in the house and hope someone plugs it in. I’d probably have to attach an alluring label to it, like “cute pics of James.” What grandma could resist?
To recap, the tools I used in this operation were as follows:
Raspberry Pi, running Manjaro
Prelude Operator as the driving command-and-control center
cupp.py to generate a password list
The built-in SSH utility
A web browser
Operation GRANDMA is now complete. I was able to successfully leverage my Raspberry Pi attack box to conduct a realistic WFH security assessment, even gaining remote code execution.
I’ll call this a success (and hope my in-laws come back).
TUHN
Bullshit you your MIL's device had a running SSH server and she had configured it with her own password.