SpiderLabs Anterior

Behind the Phish: Romance Perhaps?

When I look at the masses of spam we receive on a daily basis, I often wonder who is behind it all. What systems do they have in place, and who are the people behind such madness?  We have often discussed some of the big spamming botnets, like Cutwail, or Grum on this very blog.  But at the same time as the big boys carry out their business, there is also a lot of smaller scale spamming and scamming going on.

Today I was examining a phishing message, and I realized it may offer a clue as to how it was sent and by who. 

 

Pretty standard phish. The link led to a fake CommonWealth Bank phishing page illegitimately hosted on some little hotel’s web site.

Analysis of Malicious Document Files Spammed by Cutwail

In our Global Security Report, we highlighted a zero day vulnerability in the Windows Common Controls affecting Microsoft Office (CVE-2012-0158). This was reportedly being used for targeted attacked against NGOs and human rights activist.

Over the past week, the Cutwail botnet has been sending out spam containing malicious documents of the aforementioned vulnerability, CVE-2012-0158.  The use of a loaded RTF attachment  is a departure from normal for Cutwail, usually it distributes executable attachments or links to exploit kits.

The spam claims to be from Citibank or  Bank of America. The spam may use the “Merchant Statement” as a subject line and has an accompanying .DOC file attached.

Spam Campaign Samples

Baiting Attack Exercise – The Old School Way Still Works

In the past few months, we have had quite a few social engineering and client-side penetration tests, and, as you have probably noticed from my previous posts, these are the types of tests I enjoy doing, a lot.

Let me start this blog post briefly describing our usual approach and results for one of the baiting attack exercises we have performed. In this particular case, we have used traditional and old school techniques that still work.

Baiting attacks could be very similar to phishing attacks, however, instead of using email as the delivery method of the attack we use different ways of physical media which relies on the curiosity or sometimes even greed of the victims. 

More on the TrustKeeper Phish

Yesterday we alerted people to a widespread phishing campaign misusing Trustwave’s brand. Here we go into some more detail about the campaign.

First up, I’d like to repeat, these messages did not originate from Trustwave, and at no time was there any breach of Trustwave's networks or data. Here is an image of the offending email, which purports to be a notification from a TrustKeeper vulnerability scan:

Trustwave TrustKeeper PCI Scan Notification - Phishing ALERT

Over the last few hours, Trustwave has received multiple reports of individuals receiving fake emails pretending to be from Trustwave.

These emails did not originate from Trustwave. Recipients should immediately delete the emails and not follow any links presented in them.

These emails indicate they are being sent as part of a “TrustKeeper PCI Scan Notification” and are alerting the recipient to login to a portal to respond to an issue related to a vulnerability scan of their network.

Early analysis has shown these emails are being sent from many variations of fake Trustwave email addresses and redirecting users to multiple non-Trustwave URLs. Visiting these URLs might introduce malware onto your systems.

Below is a screenshot of a fake email:

Photobucket: An Identity Thief's Playground

Photobucket is a popular social media site that acts as gallery and cloud storage for user photos. Users can upload photos and arrange them into individual galleries or simply leave everything unsorted in one large library.

Adding support for smartphones makes it even more useful. Android and iPhone users can both download apps to automatically sync their cell phone photos to Photobucket. And why not? It’s super convenient – otherwise you’d have to manually transfer your photos from your phone to cloud storage one by one.

The security problem is that many users either (a) forget that the Photobucket app syncs all their photos to the site or (b) have no idea how to adjust privacy settings. Are you starting to see the problem here?

If you’re like most smartphone owners, you use your phone as an extension of your brain. When was The Matrix released? Look it up on IMDB! What’s the song that’s playing on the radio right now? Have Shazam tell you! You opened a new account at your credit union: how will you be able to memorize your new account number? Take a photo of the account document and keep it in your image Gallery! But if you’re syncing your photos to Photobucket with the default privacy settings, you’ve just shared that private document with the whole world!

This doesn’t sound too bad; after all, what are the odds an identity thief will find your user profile on Photobucket and sort through all your photos until they find a picture of your account information? Well, Photobucket actually makes this really easy for our hypothetical thief. To illustrate, you could check out photobucket.com/recent (please note that adult-themed pictures occasionally end up there). 

That’s right – Photobucket displays recently uploaded files from its users in (more or less) real-time. All our hypothetical thief has to do is stay at that page and scroll until he finds something useful. “But,” a skeptic might say, “people don’t put that sort of thing on Photobucket for the world to see!” A couple of hours of scrolling turned up evidence to the contrary. Obviously the interesting bits are obfuscated, but it was in plaintext for the world to read. Please keep in mind that absolutely no special software, skills, or techniques were involved in gathering the following images. 

Fraud, Passwords, and Pwnage on the Interwebz

This past weekend I was lucky enough to attend Microsoft’s BlueHat Conference in Redmond WA and Security B-Sides Seattle.  The combination of some of those talks succeeded in keeping some persistent issues alive in the hopes of finding a solution.  We live in a world dominated by the Internet and rapidly changing technology.  Most people regularly use at least some form of social media online whether it’s Facebook, Twitter, Reddit, etc., and it’s accessed and updated from a home computer, tablet device, or smartphone.  And while the Information Security world is far more cognizant of what transpires online your average user really isn’t.  And it’s sad to think they either don’t care, or have a “it will never happen to me” attitude.  I’m not sure how much of my online life is made up of paranoia, anti-social behavior, or just that I feel what I do is none of anyone’s business but my own.  I don’t have a real Facebook account, I have a “sock puppet” account. I have a twitter account, but if you look at it, it’s all angry rants.  I try to minimize my web footprint as much as possible, but I love my email accounts.  Yes, that’s right -plural.  All are different user names, with different email services.  Each is associated with various logins to different services on the Internet.   So what about the average user? 

An Analysis of a Fake Vodafone Bill PDF File

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 Vodafone-OnlineRechnung@vodafone.com. 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

Detected as malicious by PDFScore. 

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.

Phishing Evolves: Rogue IVRs

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.

Client-side Payload - The Brazilian Way.

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.

[DETAILS]

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:

• Tracking statistics about victims opening my e-mails (not 100% precise), through clicking my evil links, etc.

• Collecting credentials with fake web-site logins.

• Periodically getting command line access to targets (via reverse shells).

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:

1. A set of prevention technologies: anti-virus, endpoint security with personal firewall, e-mail gateways / anti-spam systems, web gateway filtering inspecting non-encrypted and SSL connections, IPS, etc.
   
   
2. Many advanced payloads do not work very well running in x86-64 (Windows).
   
   
3. Very restrictive inbound and outbound firewall rules, basically denying everything and only allowing the essential traffic. Additionally, authentication is required for outgoing connections.

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:

• Create a custom payload or add my own evasion techniques, this way almost any signature detection system can be bypassed.

• I do the same with the communication protocol since you don't want to be detected and blocked because you’re mimicking the behavior of a well-known hacking tool. For example, the Metasploit meterpreter reverse_http(s) payload contains the string "Meterpreter" on the User-Agent variable.

• Use a SSL encrypted connection; another interesting approach is to buy a SSL certificate from a trustworthy CA (Certificate Authority) to use on the communication protocol. There are many tools that do not generate dynamic SSL certificates and consequently can be easily detected.

• If you are going to drop any executable on disk you may want to consider a code signing certificate, I have seen a few security solutions that give better reputation to executables because of a Code Signing certificate. These certificates are not that expensive and I have seen individuals in "underground" forums with fake companies that have acquired them. In addition, a decent packer will do the trick to bypass almost all anti-virus (the infamous FUD - Fully UnDetectable).

• Reuse common services and ports that obviously are used by your target - more details below.

If you are going to use a phishing e-mail or fake website, make sure to add the proper evasion techniques and test it extensively before delivery as not to get caught during the delivery phase. You can use the same secure solutions to learn how they work and create a bypass for them. Additionally, keep in mind the statistics that I mentioned at the beginning may be very helpful to let you identify if you were blocked by an e-mail or web filtering solution.

For the second problem, I decided to follow this path:

• This problem doesn’t appear very relevant at first; however, I'm impressed by the number of computers running Windows 64bit over the last year and I believe it will continue to grow. When you think of the hundreds of potential victims, it may not be that relevant if you just need to compromise one of them. However, when you have a very small list of victims this may be the difference between success and failure. I have noticed that many advanced payloads that interact with specific applications to escape firewall rules do not work properly with Windows 64bit and 64bit applications.

Based on this, I took special care to make the payload and modules to work on 32bit and 64bit Windows and Applications.  I tested it extensively and I would like to thanks all my co-workers from Trustwave and SpiderLabs that offered their machines as sacrificial lambs to test on.

For the third problem, I decided to follow this path:

• The payload contains three sub-payloads that are all enabled by default, but if I have size limitations I will disable one or two to fit size restrictions.

Most of the companies that I have worked with allow internal machines to resolve external names via internal DNS name-servers (often DNS integrated with Active Directory). The first sub-payload automatically detects the current DNS server(s) and uses DNS tunneling to evade firewalls. The payloads are configured to throttle connection speed and include evasions to make the detection process more difficult for an administrator. I also register a domain that does not look suspicious.

• I’ve also noticed that many companies allow employees to access the web (HTTP/HTTPS) via a proxy server with authentication (in general integrated with Active Directory). The second sub-payload automatically detects the proxy address and uses HTTPS as the communication channel. The key here is that I reuse the current user credentials to authenticate with the proxy, so I can get to the Internet with all the access that the compromised user has. In addition, I have implemented some other features to make this more difficult to detect.

• Most of my attacks are delivered via e-mail, so I was thinking, why not use this channel as the communication channel?! The third and newest sub-payload talks to the user’s e-mail client and automatically reuses the SMTP server and current e-mail credentials to send communication back. The cool thing is that this payload does not raise any security alarms from the current e-mail client (Outlook) and it automatically detects the sent message and deletes it from sent items.

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

[CONCLUSION]

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.