My name is Wendel Guglielmetti Henrique, and I'm a senior securityconsultant at Trustwave's SpiderLabs. I have over 12 years experience inInformation 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 largeconferences 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 firsttime I've ever posted on a blog.
In this post, I'll be discussing my personal experience with client-sideattacks, phishing attacks, and socialengineering, focusing mostly on the payloads. This will be a shortbrief about the most relevant points, which has allowed me to build a first-classpayload resulting in a 100% success rate during engagements.
I will also be including a few suggestions for penetration testers whoneed to drop executable files on disk. One of the things I hear quite often ispeople asking for help because they are being caught by anti-virus or endpointsecurity software.
The name of the blog post is a tribute for allmy co-workers at Trustwave that are Brazilians as well; we are a small team inBrazil 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 athitting the main points, but if I miss something or you have questions, feelfree to let me know.
While doing client-side attacks or using social engineering to convinceusers to execute a piece of malware, I noticed that my results were not as goodas I had initially hoped. During myearly 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 gettingstatistics about which employees open malicious links, submit theircredentials, shell access to their workstations, etc. This kind of informationis nice because it not only shows the robustness of e-mail and web filters, butit also helps organizations understand how educated their users are about thesekind of attacks.
Additionally, credentials are very useful; as we know password recyclingis one of the most old and still present issues related with informationsecurity. 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 thetarget organization does not have any remote administration interface availableon the Internet and does not offer web-access e-mail? It has not happened to meyet, but there could be cases where users do not give out their credentials andconsequently I would not have a good compromise to write up in my report.
At this point, you may be wondering about theshells, right? Yes, sometimes we get shell access and this is the best result, completepwnage.
In practice however, I have seen many payloads fail due to differentdefensive controls. Most of ourcustomers take security very serious and implement different security measuresto prevent or mitigate compromise. Just to expound on the customer-side successesI have seen:
- 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.
- Many advanced payloads do not work very well running in x86-64 (Windows).
- 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 problemsand I agree, but we need to be aware that they are there and think carefullyabout 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 fakewebsite, make sure to add the proper evasion techniques and test itextensively before delivery as not to get caught during the deliveryphase. You can use the same secure solutions to learn how they work andcreate a bypass for them. Additionally, keep in mind the statistics that Imentioned at the beginning may be very helpful to let you identify if you wereblocked 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 payloadand modules to work on 32bit and 64bit Windows and Applications. I tested it extensively and I would like tothanks all my co-workers from Trustwave and SpiderLabs that offered theirmachines 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 allowinternal machines to resolve external names via internal DNS name-servers(often DNS integrated with Active Directory). The
automaticallydetects the current DNS server(s) and uses DNS tunneling to evade firewalls. Thepayloads are configured to throttle connection speed and include evasions tomake the detection process more difficult for an administrator. I also registera 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 firsttwo sub-payloads collect a lot of information from the compromised system, attemptto escalate privileges, dump password hashes, take screenshots at random timesand send all this information over the current tunnel and exit. The thirdsub-payload does same but sends all information in a single e-mail with thecontents attached (compressed) to an email account that I control.
The final stage is clean-up, where I make sure to remove evidence aboutcollected information and payload.
To wrap up, I would like to thank my co-workers at SpiderLabs that gaveme ideas and helped with the infrastructure. Kudos for Garret Picchioni, BarrettWeisshaar, 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. Ifyou are doing all the other stages like a professional but use an averagepayload you won't get the great results you expect.
Customers: If you are not including client-side attacks and socialengineering in your penetration testing, you are not testing a very significantattack vector that real hackers will not hesitate to exploit.