Hacking a Reporter: Writing Malware For Fun and Profit (Part 1 of 3)
Matthew Jakubowski (@jaku) contributed to the writing of this blog post.
Pando Daily editor Adam Penenberg recently published a story about my coworkers and I hacking his life entitled "I challenged hackers to investigate me and what they found out is chilling". If you haven't already, I strongly recommend that you read it.
Pando Daily also published a follow-up blog post, "A reporter asked us to hack him, and here's how we did it", explaining our perspective on the project this week.
We thought that some of our friends and readership might appreciate even more technical details about the infiltration. So we've decided to publish a three-part series of posts on the topic.
Parts one and two will detail the malware and phishing aspects of our hack with contributions from myself, Matt Jakubowski and Daniel Chechik. Next week, our colleague Garret Picchioni will publish more technical details about the onsite and wireless portions of the attack.
My daily job as a security researcher on the Malware Analysis Team in SpiderLabs typically consists of reverse-engineering malware (usually something encountered during a forensics investigation). When I was asked to take part in this project, it seemed a natural fit that I would help out by writing custom malware in order to gain access to Adam's machine. Rarely do I get the chance to don my metaphorical "black hat" and actually create a malicious file. Doing so often allows me to see the situation from both sides, which in turn allows me to do a better job when it comes to reversing malware. In short, I was pretty excited.
tl;dr We got to hack a reporter, write some custom malware, and had a ton of fun doing it.
Phase 1: Reconnaissance / Prep Work
Before we actually conducted any digital attacks against Adam, we gathered as much information as we could. We found quite a bit—pictures of his apartment, credit reports, names, birthdates, emails, phone numbers, etc. The list goes on, but there was a problem. Even with all of this research, we were unable to uncover what operating system (OS) he and his wife were using (Windows, OSX, Linux, etc.). When designing malware for a specific target, the payload you write is platform-dependent. As a solution, I decided we needed an exploit that was platform-independent and could fingerprint the OS and download/execute the specific malware based on that OS. For this step, I enlisted the help of my coworker Daniel Chechik (@danielchechik). Daniel specializes in web-based exploitation and was able to call upon his expertise to assist the team. I relayed my requirements and the dilemma I was facing. A couple of days later he came back with a great solution.
Daniel created a malicious Java applet to detect both the version of Java running on the target machine and its operating system. Using this information the applet would attempt to exploit a known Java exploit (CVE-2013-2423 or CVE-2012-0503 for our technical readers) and download/execute a specific payload depending on the OS. I modified the applet slightly to download/execute the specific payload even if the exploits didn't work. It was a last-ditch effort just in case the user happened to be running an updated version of Java. It ended up looking something like this:
Figure 1: Java Malware Execution Flow
Our solution allowed us to infect Adam's and/or his wife's machine whether they were running a Mac or a Windows OS and provided a number of exploits to be used based on what version of Java was installed.
Now you might be asking yourself, "Wait a minute, what if Java wasn't installed?". "What happened if they opened up this file on their smart phones?". "What about anti-virus!?". These are all legitimate questions. In terms of anti-virus, the file Daniel created, along with the OSX/Windows malware I wrote, had a very low anti-virus detection rate. Even if anti-virus was running on Adam's machine, it was unlikely that it would catch this file. Regarding the victim machine's Java version and accessing the file on a mobile device, keep in mind that this was only one tactic out of the nine we planned. We didn't expect this to be a perfect solution. We put our eggs in a number of different baskets and hoped that one of our ploys would succeed. That's the beauty of being the attacker. We didn't need every single one of our schemes to work—just one of them. Unfortunately, the target of an attack would need to defend against every single one of our attempts.
With our creation of a malicious file capable of attacking multiple platforms, it was time for me to get my hands dirty writing the Windows and OSX malware. This was the first time I've written OSX malware, which made it a really fun learning experience. My original plan was simple—If I get this malware loaded on Adam's machine, I want to be able to do two things:
- Ensure that the malware is persistent and will continue running until I manually uninstall it.
- Download/Execute other malware or commands, giving us (SpiderLabs) the ability to fully control the machine.
Figure 2. Snippet of Code From OSX Malware
This is essentially what I did. Writing the Windows malware was fairly simple because I've written similar programs for other engagements/events. In truth, writing the OSX malware turned out to be quite simple as well. It was much easier to code than I originally thought and took me roughly a day or two to complete (mainly due to the testing I was performing to make sure it worked). While the platforms for each binary were different, they both took roughly the same path of execution, as you can see below:
- Copy self to a hidden path on the file system
- Ensure persistence via common techniques
- Make request to remote web server every ten minutes in order to see if a command is available. If so, execute command.
With the malware ready to go, it was time to go after Adam and his wife.
Phase 2: The Attack
Adam already went into a lot of great detail in his article, so I'll do my best not to overlap too much. Essentially, we decided to target both Adam and his wife via some spear-phishing email. We knew that Adam's wife owned a Pilates studio, and I thought that we could try to pretend to be someone looking for a job. I registered a legitimate looking email for a Pilates instructor and sent out an email attaching Daniel's malicious Java applet.
A couple of days later, we got a hit! We quickly jumped on the chance and within ten minutes we had full access to Adams' wife's computer. It appeared that she had opened the Java file resulting in the installation of the OSX malware on her machine. For about ten to fifteen minutes we basked in the glory of gaining access. We were on cloud nine.
And then, silence.
Our connection was lost, never to return. We sat in silence, pondering what could have happened. Perhaps she was simply done with working for the day and had turned off her computer. We waited for another 36 hours for our connection to return. During this time, Jaku and Garret (who were on-site in NYC) continued our pursuits through other avenues of attack.
Meanwhile, I started to have serious doubts about my malware. I worried that maybe we had lost our only opportunity because of a stupid mistake I had made. Sure enough, after reviewing my code I found that a mistake on my part was to blame. Without getting too technical, an error in my logic prevented the malware from running after Adam's wife closed her laptop (putting it to sleep instead of rebooting it). About 25 minutes after coming to this realization, I had version 2.0 of my OSX malware ready to go. The problem was, I needed to get her to open it again…
Phase 2.5: The Attack – Take Two
Even though I had a new version of the OSX malware ready, we had serious doubts that we could dupe Adam's wife into opening another Java file. Because we didn't have any contact with Adam, we didn't know whether she had grown suspicious. We thought maybe his wife would tell him about this weird email she received and how an attached file didn't open at which point Adam would tell her to restore her machine to a backup and never open another file. In short, our hopes of regaining access dwindled.
We decided to step-up our game by using a different delivery mechanism. This time around, Jaku gave me some assistance. We packed a malicious OSX application inside of a ZIP file. If and when the file was opened, the application would not only execute my newly improved malware but open up a legitimate movie file as well. This made sense in the context of our ploy. We also changed the default icon to make it look like a normal movie file. We figured if Adam's wife opened up the file this time around, she would see a video actually open up and believe the file was working as expected.
Figure 4. The Phishing Email (Taken from the original PandoDaily article)
The next day, low and behold, we had a new connection! It appeared that Adam's wife had opened up this second email as well. Once again, we had access for roughly twenty minutes.
And then, once again, things went dark.
We held our breath, hoping against hope that she had simply closed her laptop again. We designed the new version of the malware to resume operations when she opened up her laptop again. We waited. We ate dinner. We waited some more.
Stay tuned for the next installment in our series where I'll explain phase three of our malware attack and how we were able to access financial records, W-2 information and more from Adam's wife's infected laptop.