CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Hacking a Reporter: Sleepless Nights Outside a Brooklyn Brownstone (Part 3 of 3)

This post is the conclusion of a three-part series (read the first here and the second here) that goes into more depth about our experience hacking journalist Adam Penenberg, which resulted in an article on PandoDaily in October. Parts one and two detail the malware aspects of our hack with contributions from Josh Grunzweig, Matt Jakubowski and Daniel Chechik. I, Garret Picchioni (voted to be the bald hacker with a heart tattoo in the original article artwork), will discuss the details of the onsite and wireless portions of the attack in this final post.

I, along with Matthew Jakubowski (Jaku), specialize in Network Penetration Testing for SpiderLabs. When asked whether we'd be interested in taking part in this project, it was a no-brainer and we immediately jumped at the chance.

Wireless Attacks:

This was one of the more challenging aspects of the project, and very different from a traditional penetration test. When we're performing wireless penetration tests for companies, we're given a list of network names (SSIDs) beforehand so that we don't waste time trying to identify them or accidentally compromise someone else's network. In this case it was different with some slightly higher stakes: it would require us to identify Adam's home wireless network name without compromising someone else's by mistake.

Once arriving onsite in Adam's neighborhood and doing a quick Wi-Fi scan we discovered it was going to be a lot more difficult than originally anticipated. As it turns out, there are a lot of people that live in Brooklyn Heights, and as a result a lot of unique wireless networks. Our initial scans of the area revealed that there were over 1,200 wireless networks discoverable from Adam's block with our wireless equipment. Without obvious wireless network names such as "Adam Penenberg's House" we had to resort to some conventional and unconventional methods to identify his network.

Since we were attempting to be as secretive as possible (Adam didn't know we were there) we had rented a ZipCar, parked it about 50 yards from his house and worked from there. This helped us avoid drawing attention to ourselves and also allowed us to use some of our more high powered but increasingly shady looking wireless equipment. While scanning, we discovered that many networks contained the first and last names of the presumed owners. This gave us an easy way to determine a scope. We began background checking the names of each of these wireless networks to determine where they resided. With this information, I was able to build a grid of sorts using signal levels of the wireless networks and the approximate distances these networks were from Adam's house. I could then roughly (and I do mean roughly) approximate what a signal level coming from Adam's building might be. This limited the list of possibilities, but that was still a list of hundreds of networks.

Given the way wireless radio waves work, the reasons for the still high number of possibilities included the following:

  1. Adam has neighbors in his building and in buildings next door

  2. Radio waves were bouncing off his windows and allowing us to discover networks (and associated clients) coming from buildings across the street from him

  3. We were discovering networks from buildings directly behind his

Our next list of eliminations occurred a couple days later thanks to Charlotte's Pilates studio. By compromising its wireless network we discovered that an internet service provider (ISP) in the area issues wireless router/modem combinations to its customers and makes the default SSID a string of random characters. As a result of an earlier social engineering e-mail sent to Adam by our colleague Wendel Henrique, we knew his ISP at home was another competitor in the area, thus allowing us to eliminate another stack of wireless networks.

We now needed to determine the final list of possibilities, doing this required two techniques. Knowing that we were capturing wireless networks from buildings behind his, I walked that block on the side of the street furthest from Adam's house with my iPhone and a lower powered wireless antenna connected to my laptop. This gave me an approximate list of wireless networks exclusive to this block and allowed me to eliminate them from the list of networks on Adam's block.

We then started planting a first generation Eee PC behind a planter on Adam's doorstep late in the evenings, in an attempt to scan wireless networks potentially exclusive to his building (or very close.) However, we ran into stability problems with the Eee PC. First, its battery life was absolutely horrible, and second, its wireless drivers were flaky, giving us mixed results in Airodump. Fortunately, both Jaku and I decided to over compensate and bring almost every relevant piece of equipment we could think with us to New York. We preferred to have an item on hand and not need it rather than need a device we didn't have (the LaGuardia TSA agents had a lot of fun searching my 50 pound backpack). After an 18-hour day and hardly any sleep the night before, our newly promoted Analyst Rick Alfaro (who we brought along with us, because of the potential learning opportunities) reminded Jaku and I that we had a Raspberry Pi buried in the mountain of tech equipment in our hotel rooms.

With the Raspberry Pi, we were able to run an ARM-compiled version of Kali Linux on it, which included support for our favorite wireless cards and their respective drivers. With this, we set out to make a device that we could stuff inside a tiny felt bag that we could stuff behind Adam's planter. What we ended up with was a true work of art but not without its own troubles (building devices on no sleep will help with that.) We connected two wireless cards to the Raspberry Pi, one to scan wireless networks in his building and the other to capture WPA handshakes (the encrypted conversation where a device sends the wireless network password to the router for verification) from networks that could possibly be Adam's. We could have in theory performed both tasks from the same card. But given that we were channel-hopping while scanning, we didn't want to miss a WPA handshake or only capture a part of one. We also tethered my iPhone to the Pi so it could phone back home to our VPS to allow us to interact with the device without having to be on Adam's doorstep.

My iPhone also has an awesome jailbroken app installed on it for locating lost or stolen iPhones (seriously, it makes Apple's Find my iPhone look like amateur hour) in the event someone discovered the bag and stole our device. This whole contraption was then powered from an external battery that we estimated would provide an estimated 16 to 18 hours of usage.

8607_318ccfcf-78b0-4923-b089-b7fa7ba38669
First iteration of the wireless device

 

10641_92d3fcd0-5843-4d4c-8709-0503ef09b9c6
Wireless device inside bag being used against Adam's network with a high gain Yagi Antenna

We then bundled the contraption up inside the felt bag and placed it behind the planter, retrieving it just before sunrise. One of the biggest troubles we encountered was the tethering connection to my iPhone. It was extremely unreliable and would often drop, most of the time never returning. This left us blind at times and required that we physically hover over the device and tap into a Bluetooth serial connection with direct console access if we wanted to interact with it. One night while I hid in a corner just below Adam's stoop using the Bluetooth console, I experienced a mild state of panic as Adam returned home for the evening.

After letting the device sit overnight, we had our final list of approximately 20 wireless networks. One of the advantages of wireless traffic traveling over the air for anyone to intercept is the ability to see what devices are connected to or associated with what wireless networks. After doing some research online and reading Adam's articles, we knew that he used exclusively Apple devices. From the final list of 20, we found two wireless networks that had a considerable number of associated Apple devices. Although we can't reveal exactly why without giving disclosing information directly pertaining to Adam's home network, one of those networks had a high possibility of being his. This, by coincidence, was confirmed when Charlotte's laptop phoned home to us for the first time. Using OS X's command line we were able to determine what wireless network she was currently connected to, along with networks she'd connected to previously.

At this point, we rented ZipCar number two in an effort to conduct some basic attacks against Adam's wireless network. As a result of some highly suspicious neighbors (seriously, I'm surprised no one called the cops on us) we had to hide our equipment (and myself) in the trunk and only expose whatever antenna we were using at any given time. So for a good portion of the day, I worked from the trunk of a car (it was surprisingly comfortable) attacking Adam's wireless network and attempting to capture WPA handshakes. Normally, this is a set-it-and-forget-it sort of endeavor. We could have "turned on" the Raspberry Pi, left and returned hours later to the spoils. But, we found ourselves overheating the Raspberry Pi and drawing too much electrical current. Because this was browning-out the device, we had to apply some manual finesse.

9531_5ee6a05e-aa28-412d-b4ec-6599154cf5c1
Attacking Adam's wireless network

This unfortunately proved to be a waste of time, because none of Adam's devices were connected to his wireless network at the time we were working and none connected before the battery powering our Raspberry Pi died. So we returned later that evening and worked from the stoop across from his house. We noticed that devices had connected, and we attempted to capture a WPA handshake. Capturing a WPA handshake, of course, requires a device to be associated with the wireless network. If all devices were already connected, we were going to have trouble. So, we set out to perform a de-authentication attack on the associated devices. To do so, we sent specially crafted packets to only these devices informing them to disconnect from the wireless network. Once they attempted to reconnect to the network, we were able to capture the WPA handshake. We sent that handshake to SpiderLabs' password cracking server and proceeded to crack the password to his network in approximately 15 minutes. With the password, we had full access to his wireless network.

I also want to extend a huge thanks to everyone who helped on this engagement: Josh Grunzweig, Daniel Chechik, Wendel Henrique, Jonathan Werrett, and Keith Lee. Wendel, Jonathan, and Keith all were working on their own incredible attack vectors to target Adam, but they unfortunately weren't put into action.

Latest SpiderLabs Blogs

Fake Dialog Boxes to Make Malware More Convincing

Let’s explore how SpiderLabs created and incorporated user prompts, specifically Windows dialog boxes into its malware loader to make it more convincing to phishing targets during a Red Team...

Read More

The Secret Cipher: Modern Data Loss Prevention Solutions

This is Part 7 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here. Far too many organizations place Data Loss Prevention (DLP) and Data...

Read More

CVE-2024-3400: PAN-OS Command Injection Vulnerability in GlobalProtect Gateway

Overview A command injection vulnerability has been discovered in the GlobalProtect feature within Palo Alto Networks PAN-OS software for specific versions that have distinct feature configurations...

Read More