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 Research2010 (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 firstt ime 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 pawnage.

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 Un-Detectable).

• 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 timesand 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.