Hacking a Reporter: Writing Malware For Fun and Profit (Part 2 of 3)

Matthew Jakubowski (@jaku) contributed to the writing of this blog post.

This post is part two of a three-part series (read the first part here). Parts one and two detail the malware aspects of our hack with contributions from myself, Matt Jakubowski and Daniel Chechik. In part three, our colleague Garret Picchioni will publish more technical details about the onsite and wireless portions of the attack.

To summarize part one: we wrote some platform-independent malware and, after a couple of hiccups, installed it on Adam's wife's machine and were waiting for our connection to her machine to come back. Eventually, late that night, we once again received a connection to her machine, which is where our story continues.

Figure 1. An actual image of us writing the malware for this engagement (Not really. Image from the hit movie, Swordfish)

Phase 3: Further Compromise and the Spoils

The objectives for this engagement as a whole were not definite. We just knew we wanted to cause as much hypothetical damage as possible. In order to do so, we set our sights on acquiring access to as many of Adam's accounts as we could and obtaining as much sensitive information as we could get our hands on. Once we gained access to Adam's wife's machine, we began rummaging through the Documents, Downloads and Desktop folders. Unfortunately, throughout the project we only had access to Adam's wife's machine for very brief periods (approximately 10-20 minutes) before our connection was lost.

After checking the sizes of the folder, we realized that we couldn't download everything with such limited durations of access. Instead, we developed a list of file names from those folders so that in case the laptop went offline again, we could prioritize what files we wanted to grab when the laptop came back online.

The next time the laptop came online we made copies of multiple files from the Documents folder, mostly PDFs. While none of the files contained passwords, we did manage to find paycheck stubs, W-2 forms, credit card receipts, and other sensitive files. These files provided us a wealth of information about Adam and his family that would have allowed a criminal to steal their identities. Additionally, we could use information from some of these documents to help us if we wished to execute any sort of social engineering attacks.

Our periodic, brief connections with the computer seemed to stem from Adam's wife opening her laptop for only short periods of time. We later learned she had been on a trip and didn't have her charging cable. She was limiting her use of the laptop in order to conserve battery power and, unbeknownst to her, making our work more difficult.

Because of this obstacle, whenever the connection was live, we had to act quickly. Jaku developed an alerting system that sent him and Garret a text message whenever a connection from Adam's wife's laptop was received. Whenever we received an alert, we would drop what we were doing and log in to our laptops as quickly as we could to ensure we didn't waste a single minute of access. You can bet this always led to an interesting scene when at lunch fellow diners would hear a loud audio alert, and see two guys immediately pull out their laptops and start typing frantically. I'm sure another site to see was when Garret and Jaku sprang into action after receiving an alert while driving down Interstate 278 in NY at 11:30 p.m.

But at this point, we did not have full administrator or root access on the system. We were limited in what data we could access and what system changes we could make. For instance, while we could enable SSH on her laptop, we couldn't enable VNC Screen Sharing as it required additional permissions.

Even just the limited access we had in OS X, however, was powerful and allowed us to perform a number of actions without a password. Because of the brief periods of access we had, we automated a number of commands to run whenever the connection was re-established. One of the commands resulted in a dump of all wireless networks the laptop had connected to and saved. This helped confirm the wireless access point name used at Adam's home while we narrowed our list (more about the wireless aspects of our hack will be discussed in part three of this series).

Our current level of access also allowed us to download Adam's wife's Apple Keychain file. The OS X Keychain file stores all of your passwords for your programs, the websites you visit and the wireless networks you connect to so that you don't have to type them out every time. Make no mistake, a Keychain file is much more secure than a text file listing usernames and passwords sitting on your desktop. The file is encrypted using your OS X login, but we didn't actually have the password to the machine yet. Without the password, we were still able to read the stored account usernames but not their associated passwords. The list of accounts looked promising, which increased our desire to gain access to them. So we set out to start cracking the Keychain offline as soon as possible.

Just moments after we managed to download the Keychain file, Adam's wife closed her laptop once again.

We attempted to crack the Keychain file over the next couple of days without success. The fact that we couldn't crack it made us scratch our heads. It suggested that the password was rather complex. It turns out that the cracking program we used had a bug in it that prevented the cracking of Keychain passwords. The bug was patched just days after the engagement concluded.

As the days passed, we had fewer and fewer chances to access the laptop remotely. It would connect for only a few minutes and then disconnect again. We decided that the next time the laptop did connect we would copy the Firefox, Chrome and Safari profile folders/cookies and peruse them for passwords that might help in our cracking. We noticed that all three browsers were installed and grabbed the profiles for all three.

Inside the Firefox profile we found a number of saved passwords. Because they were saved in plain-text we were able to view them without much work. We tried those passwords against the Keychain file, but they didn't work. At this point we had to come up with another idea. Late one night over beers we developed a plan to snatch Adam's wife's password—create a fake login prompt. To avoid arousing any suspicion, it needed to imitate a prompt that an OS X user would commonly see.

By morning, Jaku had created the prompt you see below. I swear, that guy never sleeps. His application would prompt Adam's wife with the following:

Figure 2. Jaku's GUI Application used to collect the password

The "Name:" field would be pre-filled with the user's full name and all other functions would behave like a normal password prompt in OS X, except that it would log the username and password captured. It took a couple of tries, but eventually Adam's wife typed in her password.

We checked the newly captured password against the Keychain, and it worked! Now we also had full administrator access to the laptop.

We knew that some of the websites we planned to log into would throw up a red flag if we logged in from a different IP address. So we decided it best to log-in from Adam and his wife's home access point. With the account passwords in hand, we quickly drove to Adam's neighborhood.

Upon our arrival, we first checked the iCloud service to locate the household's Apple devices. We could tell that Adam and his wife were not home, so we could work undetected. We then went one-by-one down the list of credentials from the Keychain file and logged into each site. Sometimes the password listed didn't work. In those cases we would take another guess based on other passwords in the Keychain, and we were generally successful. We then moved onto a banking website.

The banking site proved challenging because if we tried to log-in from an unrecognized device, it would also require an authorization code sent by text message or phone call. We were able to use a previously captured cookie stored in Firefox to imitate Charlotte's browser and dupe the site into believing that it was Adam's wife that was logging in.

At this point, and without much time to spare, we decided to wrap-up after achieving access to a bevy of accounts and documents:

• W2 documents
• Adam's Twitter account
• iCloud account
• Amazon account
• Banking account
• Other miscellaneous accounts

And this wraps-up our explanation of the technical details of the malware aspects of our "hack a reporter" project. Overall, it was one of the most fun engagements I've been involved with in quite some time. Due to a few constraints (not getting arrested being the biggest one), we weren't able to go "full-criminal", but I think you'll agree that it was a fairly accurate representation of what could happen if an attacker decided to target an individual.

I'd like to extend a huge thanks to everyone who helped out on this engagement—Garret, Jaku, Daniel Chechik, Wendel Henrique, Jonathan Werrett, and Keith Lee. Wendel, Jonathan, and Keith are not directly mentioned in this article, but they all helped out in a big way.