The Time We Hacked a Private Equity Firm…from Their Lobby
Let me start by saying this private equity firm paid us to hack them as part of a white hat penetration test. This test was part of the client’s Cybersecurity Risk Assessment within Agio’s larger SEC Governance Program. After we decided this is what they wanted to do, we had a scoping call to discuss strategy, resulting in several social engineering attacks in addition to the traditional network-based attacks. This client emphasized a valuable and sensitive database of theirs, specifically, which of course then became the target of our “capture the flag” exercise. The next step was to host the on-site kick-off meeting and then begin the technical evaluation of their environment, better known as a penetration test.
On the morning of the meeting, we arrived a few minutes early to the client site and the receptionist offered us a seat and coffee, as our client host was running 15 minutes late. I settled into the lobby, and quickly noticed a placard with the private equity firm’s Guest WiFi network and password clearly identified. Our Agio Pen-Tester pulled out his laptop and connected to the guest network, launched a basic network scanning tool, and within 30 seconds had a devilish smile on his face.
From the network scan, the Agio engineer didn’t find many devices on the guest network; in fact, only our devices and a printer. But, the printer was a high-end multifunction printer, susceptible to an exploitable buffer-overflow attack. It turns out the operating system hadn’t been updated in years (7 years to be exact), and was running an outdated version of Linux not actually required to support printing. In seconds, our engineer was on the command-line, and had recovered cached credentials on the printer from an admin account. And here’s where it gets really interesting…
Agio’s engineer discovered the printer was connected wirelessly to the guest network, but it was also connected to the production network via an ethernet cable. Thus, the printer was acting as a bridge. He then navigated onto the production network using the recovered cached admin credentials in an attempt to establish an additional foothold in the production network outside of the printer.
Bingo! Those cached credentials stolen from the printer actually worked as the local admin credentials on several machines. Several hops and jumps later, our engineer was actually able to login to the production database and “capture the flag” from this private equity client…all from a printer in the lobby.
It took approximately 8 minutes for all of this to go down, after which our contact greeted us and invited us back to the conference room to begin the kick-off meeting for the penetration test…that already happened.
While it is certainly not every day you can breach a client’s network in under 10 minutes, there are some issues in this scenario that we often see at other private equity and hedge funds.
* Before we move on, it’s important to note that in order to protect our client’s anonymity, we altered a few of the technical details in this story, although a vast majority of this not-so-tall-tale remains intact.
- Know what’s on your network.
I doubt the IT staff knew the printer was plugged into the production network or that it was also on the guest WiFi network. If the firm had a process by which they reviewed new network devices, then they would’ve caught this configuration mistake. Just imagine if a bad-actor had placed a malicious device on their network…
- Update all devices
With the printer’s software 7 years old, “over-the-counter” exploit tools can easily gain access to the printer, and in this case the production network, given it was mistakenly configured as a bridge device.
- Manage your passwords (and have a firmwide process in place)
The fact that the local printer admin account was the same as the local admin account on the servers and workstations is bad, but also not surprising, unfortunately. We often find this weak password practice at our hedge fund and private equity clients.
- Limit access to required services to port and protocol, not just IP address
Just because the printer was on the guest wireless network for the convenience of guest users doesn’t mean we ignore the “principle of least privilege.” This printer should’ve been protected by restricting access to just the ports and protocols needed for printing – not all services.
Connect with us.
Need a solution? Want to partner with us? Please complete the fields below to connect with a member of our team.