We haven’t come across many malicious PDF files recently in our spam traps, so when we found this message, ostensibly from Vodafone Deutschland, we naturally took a closer look.
In this example, the cyber crooks are targeting Vodafone Deutschland customers by spamming a fake billing statement. The message claims to be from [email protected] The spam may look harmless at first, especially given the links in the message point to the real Vodafone.de website. But the attached PDF file is indeed dangerous.
I tested the attached PDF file against PDFScore (a tool developed by our colleague Rodrigo Montoro a.k.a Sp0oKeR) and it showed a number of suspect elements inside the file. You may check out Rodrigo's presentation about "Scoring PDF Structure To Detect Malicious Files" at SOURCE 2012 in Seattle: http://www.youtube.com/watch?v=qNlZiB2wnEM
The malicious PDF file was crafted to exploit the Libtiff vulnerability (CVE-2010-0188) in Adobe Reader 9.3 and earlier. The exploit crashes Adobe Reader and executes the attacker’s malicious code.
As someone who’s worked in the financial industry for years, I’m fascinated by methods used by phishers to encourage people to part with their money. Most of us can easily recognize and avoid the more obvious and clumsy phishing attacks (419 scams, emails in broken English claiming to be from “PayPaI,” etc.), but how equipped are we do deal with the threat of rogue IVR systems?
IVR (Interactive Voice Response) is a technology that lets humans communicate with computers over a phone line, using voice recognition or touch-tones from a phone’s keypad. We’ve all had experience with IVR systems: the automated attendants and phone menus we love to hate are implementations of IVR technology.
Your financial institution’s promise to never ask for your personal information in an email doesn’t really stop determined phishers; it just forces them to be more creative. That’s where rogue IVR systems come in. Phishers can trick their victims into entering their personal information by emulating the legitimate IVRs of real financial institutions.
Building your own IVR is actually quite simple. Take Asterisk, for instance. Get the hardware, get the software, install and configure Asterisk on your Linux machine, and you’ve got yourself an IVR, ready to go. Get a cheap 800 number and you’re two-thirds of the way to ruining someone’s day.
The general attack model goes something like this. Using their own IVR systems, attackers send victims emails or SMS text messages nearly identical to real financial institution alerts regarding fraud detection or similar. The fake message is careful to substitute the phone number of the financial institution with the attacker’s number, however. The victim calls the provided number and enters their personal information when prompted by the fake IVR.
The lazy phisher won’t care how the real financial institution’s IVR works; he’ll just prompt the victim to enter their information but reject their credentials every time. This may net him several passwords and PINs, but it will raise red flags with victims when they realize their credentials aren’t working when they should.
A somewhat more ambitious phisher will call the financial institution’s real number and record the prompts and responses given by the IVR’s automated system. He then uses this recorded audio to add an element of professional believability to the attack.
Now let’s take a look at the most transparent (and most impressive) implementation of a rogue IVR. At DEF CON 20, this attack was demonstrated to a room full of hackers at the Social Engineering CTF. The first part of the attack is the same as above: get the victim to call your IVR by dialing your number instead of their financial institution's number. But when the call comes in, make your IVR divert the call to – wait for it – their actual financial institution! The victim will hear legitimate prompts coming from the legitimate IVR and enter his personal information – while your IVR captures that information as it plays man-in-the-middle. Unless the victim sees his financial institution’s phone number later and realizes he dialed something different, he will have no idea he’s been had.
The moral of this story? The only way to consistently defeat phishers and their rogue IVRs is to never dial a phone number provided in an email or SMS, even if it looks legit. Instead, save your financial institution’s phone number to your contacts list and dial it from there.
My name is Wendel Guglielmetti Henrique, and I'm a senior security consultant at Trustwave's SpiderLabs. I have over 12 years experience in Information Technology, with the last 7 years dedicated to penetration testing.
My recent presentations include RSA Conference 2012 (USA), ToorCon 13 (USA), Defcon 19 (USA), Black Hat Arsenal 2010 (USA), OWASP AppSec Research 2010 (Sweden), Black Hat Europe 2010 (Spain), as well as other large conferences around the world. I also co-authored a patent-pending penetration testing technology.
This is my first post at SpiderLabs blog; to be honest, it's the first time I’ve ever posted on a blog.
In this post, I’ll be discussing my personal experience with client-side attacks, phishing attacks, and social engineering, focusing mostly on the payloads. This will be a short brief about the most relevant points, which has allowed me to build a first-class payload resulting in a 100% success rate during engagements.
I will also be including a few suggestions for penetration testers who need to drop executable files on disk. One of the things I hear quite often is people asking for help because they are being caught by anti-virus or endpoint security software.
The name of the blog post is a tribute for all my co-workers at Trustwave that are Brazilians as well; we are a small team in Brazil but work very hard.
First of all, as much as I would like to describe each point in extreme detail, it would not be a blog post, but probably a small book. I will do my best at hitting the main points, but if I miss something or you have questions, feel free to let me know.
While doing client-side attacks or using social engineering to convince users to execute a piece of malware, I noticed that my results were not as good as I had initially hoped. During my early testing stages, I was able achieve at minimum the following tasks:
All things considered, this is not bad at all; customers like getting statistics about which employees open malicious links, submit their credentials, shell access to their workstations, etc. This kind of information is nice because it not only shows the robustness of e-mail and web filters, but it also helps organizations understand how educated their users are about these kind of attacks.
Additionally, credentials are very useful; as we know password recycling is one of the most old and still present issues related with information security. Most of the time I'm able to reuse captured credentials to log-in to VPNs, SSH servers, Citrix applications and access e-mail accounts.
This is great from the penetration testing perspective, but what if the target organization does not have any remote administration interface available on the Internet and does not offer web-access e-mail? It has not happened to me yet, but there could be cases where users do not give out their credentials and consequently I would not have a good compromise to write up in my report.At this point, you may be wondering about the shells, right? Yes, sometimes we get shell access and this is the best result, complete pwnage.
In practice however, I have seen many payloads fail due to different defensive controls. Most of our customers take security very serious and implement different security measures to prevent or mitigate compromise. Just to expound on the customer-side successes I have seen:
You may argue that solutions for attackers exist to get around these problems and I agree, but we need to be aware that they are there and think carefully about them when designing a payload that will be successful.
For the first problem, I decided to follow this path:
For the second problem, I decided to follow this path:
For the third problem, I decided to follow this path:
Since it's a penetration test exercise and not real hacking the first two sub-payloads collect a lot of information from the compromised system, attempt to escalate privileges, dump password hashes, take screenshots at random times and send all this information over the current tunnel and exit. The third sub-payload does same but sends all information in a single e-mail with the contents attached (compressed) to an email account that I control.
The final stage is clean-up, where I make sure to remove evidence about collected information and payload.
To wrap up, I would like to thank my co-workers at SpiderLabs that gave me ideas and helped with the infrastructure. Kudos for Garret Picchioni, Barrett Weisshaar, Ryan Jones (US or “2” if you prefer :), Luiz Eduardo, Nathan Drier, Matthew Jakubowski, Alex Gatti and Jonathan Claudius
Pen-Testers: your payload is a very important part of your attack. If you are doing all the other stages like a professional but use an average payload you won't get the great results you expect.
Customers: If you are not including client-side attacks and social engineering in your penetration testing, you are not testing a very significant attack vector that real hackers will not hesitate to exploit.
Over the past few weeks we have seen a resurgence of malicious spam with links leading off to the Blackhole exploit kit. Last week about 2% of spam hitting our traps fell into this category, which is pretty significant given that many people still consider ‘spam’ annoying but harmless. The spam typically originates from the ubiquitous Cutwail spambot variants, but other botnets are also involved. The campaigns vary widely from day to day according to the attackers’ whims. The message templates are based on mimicking high-profile brands, for example:
Today, I’ll focus on a Verizon campaign. Below is a sample message, which as is typical, displays some aspect of an account bill or statement. Merely hovering over the link shows that the URL (underlined in red) is not associated with Verizon in any way:
Of course, the goal of an exploit kit is to exploit. So how successful is this campaign? As it happens, a colleague of mine happened to ‘find’ his way into the admin panel of this particular Blackhole server and take a screenshot, which reveals some interesting information indeed:
I love looking at admin panels! At a glance you can see what is driving the bad guys. If you somehow can’t read Russian, I have annotated the four columns representing Hits, Hosts, Downloads (successful exploits), and Download Rate (percentage of successful exploits). You can see the highlighted domain from the original spam message had a 10% success rate, 17 installs out of 167 unique host visits. Overall success rates for the kit were 13.06% for this particular day, and 7.77% overall. Is it just me, or does anyone else think that a 10% success rate is higher than it should be?
The bottom section displays the array of exploits used. Notably, over 75% of successful installs were accomplished using some type of PDF exploit, with over 50% resulting from an exploit targeting the Adobe Reader PDF LibTiff vulnerability (CVE-2010-0188). The “PDF ALL” refers to a bundle of known PDF exploits including GetIcon (CVE-2009-0927), CollectEmailinfo (CVE-2007-5659), printf (CVE-2008-2992), and newPlayer (CVE-2009-4324).
Some of the other exploits used in this kit are the trusty MDAC (CVE-2006-0003), Java AtomicReferenceArray (CVE-2012-0507), Microsoft Help Center URL Validation (CVE-2010-1885), and a Flash exploit, which is most likely SWF File Remote Memory Corruption (CVE-2011-0611), given past Blackhole analysis.
On the installs by country, while the United States had the lowest install rate (6.16%), it had the highest total number of installs by far (616), reflecting its higher number of hits. This is not really surprising given that the spam campaigns, and the brands used, seem specifically targeted at US users. The operator of this kit is most likely affiliated with a pay-per-install program, and these programs typically pay more for US-based computers. Another interesting stat was the 13 successful installs in Russia, representing a high 35% exploit rate. Hmmm, I wonder whether some of these are the kit operator’s test machines?
So what can we learn from this little analysis?
Trustwave Secure Web Gateway and MailMarshal Secure Email Gateway provide protection against Blackhole and other exploit kits, and these spam campaigns, respectively.
Thanks to fellow SpiderLabs colleague Daniel Chechik for his input and for wandering into this particular Blackhole kit.
In the next series of blogs we will describe in detail an attack from one of the most sophisticated cybercrime groups. We will investigate every layer of the cyber-attack from infecting innocent users with bots to collecting their money into the cyber-gang hands. In this blog we will provide an overview of the attack and describe the spreading technique of the bot.
Prior to advent of information technology, criminals typically stole by way of breaking and entering, such as by targeting banks to steal money from a teller or, if they were smart or lucky enough, the safe. As the years passed and technology advanced, another layer of complexity has been added to criminal activity: “cybercrime.” In the last few years, online banking has become the next vector of attack for cybercriminals. These hackers realized early on that breaking into a user’s PC is much easier than breaking into a bank or even a bank’s website. More importantly, they realized that getting caught for online crime was highly unlikely.
Last year, Trustwave SpiderLabs, discovered a sophisticated cybercrime operation that targeted online banking users in the U.K. We found a Command and Control (C&C) server located in Moldova that controls more than 30,000 machines which were infected with the Zeus banking Trojan. This malware, known to have been around for several years, steals personal information, receives commands from its server and performs unauthorized bank transactions via its plug-ins. This attack has stolen more than £1 million. The same cybercrime group launched a similar online banking attack more than a year ago. Unlike most cybercrime attacks that operate with a single hacker or a small team, this attack operation was launched on a much larger scale. The manager of this operation has several affiliates, each launching bots of his own. Trustwave SpiderLabs has been and continues to work closely with law enforcement agencies to investigate this attack.
However, before investigating the actual work pattern of the cybercrime gang, let’s review a simple diagram of the attack, and then take a closer look at a few attack vectors that spread the bot.
Cybercriminals spread Phishing emails and posts on social networking websites, manipulating users into clicking on a malicious URL. In this specific attack, the URL has led to a fake Facebook login page, asking the user to download an update for Adobe Flash player.
Once the user clicks on the link, a bot is downloaded to the user’s PC.
In addition to the fake Flash Player update, the page also uses a drive-by to maximize the chance of successful exploitation of the user’s PC. The technique uses an iFrame object that redirects the browser to a malicious exploit kit.
The browser is redirected to a server hosting the Blackhole exploit kit. If the exploitation is successful, the same malware payload (the phony Flash update) is installed.
In the next blog in this series, we will analyze the known Blackhole Exploit Kit that has been used to exploit users’ machines
Recently, while scrounging around our spam traps, I spotted this ordinary piece of malicious spam. It uses a very simple social engineering trick, speculating about Obama’s sexual orientation and a link to a supposed picture to prove it.
There was nothing special about this spam but the link with a double extension file named “you.jpg.exe” was something worth investigating. So out of curiosity, I downloaded the file and checked out what it does.
First thing I did was to find out what the file really was. Of course, it was not an image file of Obama but rather a self-extracting RAR file.
Opening the file through a RAR extracting tool revealed the files inside it.
I extracted “you.jpg.exe” and inspected each of the files inside it but found they were actually encoded. So I run “you.jpg.exe” in our test machine and observed. When run, the image below popped up. Hmmm, definitely not Obama.
In the background, the following files were installed in the Windows System32 folder:
Also an autorun registry was created:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run bpk = <%windir%\System32\bpk.exe>
Googling for the dropped files gave me a hint that what was installed was a keylogger and in particular a commercial version from Blazing Tools called Perfect Keylogger (PK). This keylogger program can be legitimately purchased and used, ostensibly for monitoring your kids’ or employees’ browsing habits, etc. As you can imagine, PK can also be used for badness.
I almost ended the analysis here. But a moment later, more interesting stuff appeared. The keylogger connected to a remote FTP server, and this allowed me to intercept the attacker’s FTP credentials.
Using the intercepted credentials, I logged in to the FTP server and found many folders containing monitoring logs and screenshots of victim’s desktop. That number of logs shows just how effective the spammer’s social engineering trick was.
Here is the WHOIS info of the FTP server:
Not wanting to stop here, I did a little more investigation on the PK installation files in my hope to uncover who was behind the campaign.
According to PK’s Online Help webpage, the program uses a hotkey to unhide the admin window or the system tray icon. The default hotkey combination is CTRL+ALT+L, but this didn’t work. So brute forcing different hotkey combinations enabled me to retrieve the correct hotkey. But to my dismay, this window popped up:
Before getting dirty by reverse engineering the keylogger and trying to crack the password, I scrounged around the net for more clues. I found a personal blog by Chris Pogue who happens to be a colleague here at Trustwave SpiderLabs who previously encountered this keylogger. In his blog, he noted that the password and other configurations were stored in an encoded file named PK.BIN, and the monitored data is stored in an encoded file named BPK.DAT. He also noted that the files can be decoded with a simple XOR using the key 0xAA.
I supposed that the PK version that Chris analysed was an older version, hence the XOR key 0xAA didn’t decode our configuration file. Well, for the dump file BPK.DAT, the XOR key partially worked, but to make it more readable I XORed it using two bytes 0xAA, 0x00:
But I was more interested in the file PK.BIN, because it stores the configuration details of the keylogger including perhaps the details of the attacker. But the file needed some extra work because of the fact that it can’t be decoded by simply XORing it with 0xAA. So my best guess was that it used a different XOR key.
This is what the file looks like in text mode, hhmmm look at that repetitive pattern!
In HEX mode, I took that repetitive string and made it our XOR key:
With the help of some python script, it helped me decode the file:
if len(sys.argv) > 1: pkhandle = open(sys.argv,'rb') pkbuffer = pkhandle.read() pkhandle.close() key=[0x0D,0x0A,0x08,0x05,0x01,0x02,0x06,0x03,0x03,0x0E,0x01,0x08,0x03,0x0C,0x09,0x07,0x05,0x0D,0x0C,0x0B,0x03] dec = '' ctr = 0 for i in range(11,len(pkbuffer)): a= ord(pkbuffer[i]) b =key[ctr%len(key)] x = a^b dec = dec+(chr(x)) ctr+=1 dechandle = open('pk.dec','wb') dechandle.write(dec) dechandle.close()
And voila! (note: I needed to blur some details to protect the victim’s data in the FTP server)
The decoded PK.BIN shows enough details to get inside the PK admin panel, including the keylogger's admin password, FTP server/credentials, PK license name and license key. I typed in the admin password and it was successful, giving me more understanding about what the attacker is capturing and more of his keylogger configuration.
In the configuration file, it revealed the name Charles Onuigbo as the PK license name.
Now, I don’t conclude that Charles Onuigbo is the attacker or indeed if he is a legitimate person. The only thing interesting about the name is that it appears to be fairly common in Nigeria, the home of email scams!
I have reported the FTP site to its ISP through abuse email, and am looking forward to this site being taken down ASAP.
UPDATE: I have received an email from the company who hosted the FTP server in question and they wrote :
"Hello- I'm unsure if my co-workers wrote you back regarding this. We have stopped access to the account being used for this on the server in question... "
I have checked the FTP server and can confirm that the malicious FTP account has been disabled. Thank you Alex Kwiecinski of Liquid Web Inc. and your team for taking immediate action.
Recently, we came across a phishing attack targeting Australian Apple Store customers. The phishing scam claims to offer a $AU100 Apple Store credit when buying a $9 Australian Dollar Apple discount card. Does it sound legit or too good to be true?
There are obvious signs that tell you right away that this is a phishing scam. First, the English is not quite right. Second, in order to buy the discount card, the user needs to open an attached HTML form and fill it out with sensitive personal information and credit card details. That's not all, the form also asks for your credit card limit and Visa/MasterCard SecureCode password, really??
We examined the HTML phishing form and investigated the website where the data was sent when clicking the submit button. The webserver (specifically hosting a blog which probably was hacked) has directory listing enabled. We found 2 new files related to the phishing scam, the phisher's PHP script file and a .Txt file that contains the phished data.
Based on the language used in the log, there is a hint that a Romanian phisher is possibly behind this campaign. Unfortunately, there were also a handful of victims' data found in the log.
For the record, Apple is not in the habit of attaching HTML forms to emails and then asking you to enter sensitive data. But despite all the suspicious signs found in this email, many on-line users were still lured.
Again we say, be particularly leery of any HTML email attachment requiring you to enter sensitive information.
Note: We have informed the owner of the hacked website about this. One of the comments in the blog raised his concern. Tut tut indeed!
The blog owner seems to be aware and posted this: