Hacking a Reporter: UK Edition

Over the summer, a U.K. journalist asked the Trustwave SpiderLabs team to target her with an online attack. You might remember that we did the same in 2013 by setting our sites on a U.S.-based reporter.

This scenario, however, would differ from the first. The reporter, Sophie, was our only target. Co-workers, company or family were off limits. Sophie wrote about the experience from her perspective here. Below, we'll tell the story from the perspective of Trustwave SpiderLabs, playing the role of "theoretical" attacker.

Online, some readers criticized Sophie for being too naïve when it came to the attack. There could be some truth to that, but we would say that with great pretext a well-executed attack rarely fails, no matter the target (and zero-days are rarely required). We're not saying this out of pride or to take it easy on Sophie. It's just our experience. :)

To hedge against the risk of failure, we proposed a two-to-three stage attack. We described the first stage as a demonstration of passive information gathering and later stages only as "more active".

At a high level, we approached the project as follows:

Stages of activity

1. Passive information gathering/reconnaissance
2. Active fingerprinting
3. Active attack

First, we performed reconnaissance on Sophie and identified her potential cellphone model, her corporate e-mail address, some of her social network profiles and much more. This was a good starting point, but to increase the chance of success its helps greatly to know what operating system the target uses and fingerprint her system(s) as much as possible.

Fingerprinting: First Attempt

In our first attempt to fingerprint her, we created a Gmail account using a fake, Latin name (we'll explain why later). From that account, we sent a few e-mails to Sophie asking whether we could meet her. We included a hidden image in an attempt to fingerprint her system when it loaded the image.

The e-mail was purposefully vague about the details of any in-person meet because people tend to be curious, and we expected Sophie to reply asking for more details and consequently open additional attack vectors.

We never received a response or a proper fingerprint because Gmail prevented it as Google image's proxy downloaded the images.

Fingerprinting: Second Attempt

As part of our second fingerprinting attempt, we registered a domain that resembled the Linkedin domain—"linkedhn.com." We sent an e-mail to Sophie that mimicked the one sent by Linkedin when a user invites you to connect. We sent the e-mail masquerading as a supposed colleague of Sophie's. If she chose to confirm the connection, the message would lead Sophie to the login page for our cloned Linkedin website.

Sophie opened our counterfeit invite but did not log in. We were, however, able to fingerprint the target system using the BeEF framework. We enumerated her plugins, OS version, location, and much more. In short, we identified that Windows 7 with Java 1.7 update 51 and Microsoft Office 2010 were in use. We then quickly lost our browser hook and no further attacks were launched. Although seemingly small, this first victory was important. Blind attacks—when not launched against massive groups of potential targets—are unlikely to succeed against a single individual. Below you see some of the system information we were able to gather.

After allowing some time to elapse, we revived our fake gmail account that used a Latin name. We used it to introduce ourselves and lend more credibility to our subsequent pretext.

We created a new account called "UK.Leaks.Team@gmail.com" and sent the following, fictitious e-mail to our target three days before Brazil's presidential election.

Sophie,

We are part of a Worldwide activist group and write to you again as one of our local collaborators tried to contact you a few weeks ago using the alias Ricardo Almeida to protect his identify, but unfortunately you haven't replied. We want to talk to you because we have obtained confidential files from the UK government and are currently working with newspapers from different countries.

At the time of writing we already have agreements with national newspapers from the USA, Germany, Italy, France, Brazil, Argentina and South Africa. The document in reference must be released on October 3^rd, 2014; two days before the Brazilian Election Day.

…

We would like to invite The [REDACTED] to be a primary channel for public disclosure of this document and attach a partial extract for your initial review. If you agree to publish an article in accordance with our coordinated global release date of October 3^rd, we will send the full document and related files for your review.

Please be aware we are a not-for-profit group and our identities must remain private to protect individuals involved.

Viewing Instructions



The attached file is compressed and encrypted with a strong password "![REDACTED]Curtis7482" (without quotes), in order to reduce the file size and increase the security of our communication. If you are using Windows you may need to copy the attached .rar file outside Outlook to be able to open it since the file is encrypted, as follows:

1. You will need a tool to extract .rar files, for example Winrar, 7Z, etc. The steps below are based on Winrar.
2. Copy the attached file to your "Documents" folder.
3. On the "Documents" folder, right click on "UK Leaks Proof – [REDACTED].rar", choose "extract here" and insert the password.
4. A new file will be created called "UK Leak #12 - BR Voting System.pdf", which can be double clicked to open.

We hope you find the extract enlightening and are waiting for your answer.

Sincerely.

UK Leaks Team
The contents of this message are confidential and may be privileged. Copying or disclosing is prohibited.

Guess what? She opened the e-mail and followed the instructions. Originally she hesitated, but it seems her appetite for a scoop overwhelmed her reluctance. Put yourself in her place. She is a journalist for a big newspaper, and she's contacted by a supposed anonymous leaker with ground-breaking news about electoral fraud. What would you do? You probably wouldn't let security best practice get in the way of a potential exclusive! Maybe you'd think twice, but you might also put faith in your antivirus program and have a look at the attachment.

Here's the e-mail displayed on her computer: :)

Her use of the Webmail interface caught our attention. Later, we discovered that she seemed to be using a different computer as the fingerprint in this case differed from the original.

We used an old trick to impersonate the binary and make it look like a valid PDF file. Because Gmail prohibits sending a direct executable, usually we hide it inside a .zip file. Gmail also blocked the .zip file and so in the end we were forced to use something less common. We chose to use a .rar file and adapt the pretext to it. We hypothesized that since Sophie was a technology journalist, she might already have Winrar installed. Below is how the fake PDF file appeared to Sophie on her computer once she followed the instructions:

It looks like a genuine attachment, right? A clue that reveals something might be amiss is its description as "application" in the "type" column. Many people might ignore it, but it's worth checking that description to avoid such social engineering hacks.

Another feature we added was that every time the fake PDF was opened, it paused for a few seconds and displayed a pop-up message stating "Access was denied." We hoped this might lead to her double-clicking the file again or trying to open it using another computer. It worked! As a result we got 6 different connections and shells from her laptop.

We packed the executable with a private packer that at the time had a very low rate of detection. The payload is a variation of the 3 in 1 described in this blog post.

At one point she replied to our e-mail agreeing to the release date and saying she planned to open the file immediately. As you'll see below, warnings from security software on her system raised her suspicions. But in spite of her reservations: the pressure of the release date, the potential for a scoop that could affect her career in a positive way, and her confidence in her security software led to the compromise of her system.

After her original reply, it took her another 25 minutes to execute the file. We think this might have been a symptom of her trepidation. We delayed our response to let the pressure and phony urgency work its magic. Once she sent her second response expressing her concerns that it was a scam, it was too late—she was already compromised. But, had this particular attack failed, her asking us for proof gave us a second chance to try another attack vector had we needed it. :)

We think she may be thinking to herself, "Did I just do something I shouldn't have?!"

As we showed you earlier, Sophie was using the Gmail web interface with Chrome. She also had OpenOffice, which is less common. The computer was not running with elevated privileges, but as you know, there are ways to escalate privileges even on a fully patched computer (but that's a topic for another blog post).

Once we established command and control on her system, there isn't anything we couldn't have done. We did consider one of the most interesting avenues to be piggy-backing onto the corporate VPN connection, stealing credentials, and then exploring the file-shares and other resources used by Sophie and potentially her colleagues. The sky was the limit.

What can we take away from this?

Organizations should consider the following:

1. Raise awareness and educate employees on the potential perils of social engineering attacks.
2. Review gaps in perimeter anti-malware defenses (particularly e-mail and web gateways). If security gateway technology is already in place, be sure it's configured to be effective and that it's tested.
3. Regular patching and updating of systems and software is not just for servers. Patching end-user systems and software should be a structured, on-going activity.
4. Understand that the compromise of a user laptop can lead to pivoted attacks against the internal corporate network, even if the compromised user is working from home. For example, attackers could pivot through any corporate VPN connections that are, or will be, established by that remote user.

As a footnote to this post it's worth mentioning that often we get asked, "what's the point of social engineering, you're always going to get in". To be fair, that is a pretty accurate statement. The value of social engineering engagements comes partly from testing resilience, but more so more from raising employee awareness of what is possible when they are targeted.