Netragard Hacking Your Bank

We were recently hired to perform an interesting Advanced Stealth Penetration test for a mid-sized bank. The goal of the penetration test was to penetrate into the bank’s IT Infrastructure and see how far we could get without detection. This is a bit different than most penetration tests as we weren’t tasked with identifying risks as much as we were with demonstrating vulnerability.

The first step of any penetration test is reconnaissance. Reconnaissance is the military term for the passive collection of intelligence about an enemy prior to attacking that enemy. It is technically impossible to effectively attack an enemy without first obtaining actionable intelligence about the enemy. Failure to collect good intelligence can result in significant casualties, unnecessary collateral damage and a completely failed attack. In penetration testing, damages are realized by downed systems and a loss of revenue.

Because this engagement required stealth, we focused on the social attack vectors and Social Reconnaissance. We first targeted FaceBook with our “FaceBook from the hackers perspective“ methodology. That enabled us to map relationships between employees, vendors, friends, family etc. It also enabled us to identify key people in Accounts Receivable / Accounts Payable (“AR/AP”).

In addition to FaceBook, we focused on websites like Monster, Dice, Hot Jobs, LinkedIn, etc. We identified a few interesting IT related job openings that disclosed interesting and useful technical information about the bank. That information included but was not limited to what Intrusion Detection technologies had been deployed, what their primary Operating Systems were for Desktops and Servers, and that they were a Cisco shop.

Naturally, we thought that it was also a good idea to apply for the job to see what else we could learn. To do that, we created a fake resume that was designed to be the “perfect fit” for a “Sr. IT Security Position” (one of the opportunities available). Within one day of submission of our fake resume, we had a telephone screening call scheduled.

We started the screening call with the standard meet and greet, and an explanation of why we were interested in the opportunity. Once we felt that the conversation was flowing smoothly, we began to dig in a bit and start asking various technology questions. In doing so, we learned what Anti-Virus technologies were in use and we also learned what the policies were for controlling outbound network traffic.

That’s all that we needed…

Upon completion of our screening call, we had sufficient information to attempt stealth penetration with a high probability of success. The beauty is that we collected all of this information without sending a single packet to our customer’s network. In summary we learned:

• That the bank uses Windows XP for most Desktops
• Who some of the bank’s vendors were (IT Services)
• The names and email addresses of people in AR/AP
• What Anti-Virus technology the bank uses
• Information about the banks traffic control policies

Based on the intelligence that we collected we decided that the ideal scenario for stealth penetration would be to embed an exploit into a PDF document and to send that PDF document to the bank’s AR/AP department from the banks trusted IT Services provider. This attack was designed to exploit the trust that our customer had with their existing IT Services provider.

When we created the PDF, we used the new reverse https payload that was recently released by the Metasploit Project. (Previously we were using similar but more complex techniques for encapsulating our reverse connections in HTTPS). We like reverse HTTPS connections for two reasons:

• First, Intrusion Detection Technologies cannot monitor encrypted network traffic. Using an encrypted reverse connection ensures that we are protected from the prying eyes of Intrusion Detection Systems and less likely to trip alarms.
• Second, most companies allow outbound HTTPS (port 443) because its required to view many websites. The reverse HTTPS payload that we used mimics normal web browsing behavior and so is much less likely to set off any Intrusion Detection events.

Before we sent the PDF to the our customer we checked it against the same Antivirus Technology that they were using to ensure that it was not detected as malware or a virus. To evade the scanners we had to “pack” our pseudo-malware in such a way that it would not be detected by the scanners. Once that was done and tested, we were ready to launch our attack.

When we sent the PDF to our customer, it didn’t take long for the victim in AP/AR to open it, after all it appeared to be a trusted invoice. Once it was opened, the victim’s computer was compromised. That resulted in it establishing a reverse connection to our lab which we then tunneled into to take control of the victims computer (all via HTTPS).

Once we had control, our first order of operation was to maintain access. To do this we installed our own backdoor technology onto the victims computer. Our technology also used outbound HTTPS connections, but for authenticated command retrieval. So if our control connection to the victims computer was lost, we could just tell our backdoor to re-establish the connection.

The next order of operation was to deploy our suite of tools on the compromised system and to begin scoping out the internal network. We used selective ARP poisoning as a first method for performing internal reconnaissance. That proved to be very useful as we were able to quickly identify VNC connections and capture VNC authentication packets. As it turns out, the VNC connections that we captured were being made to the Active Directory (“AD”) server.

We were able to crack the VNC password by using a VNC Cracking Tool. Once that happened we were able to access, the AD server and extract the servers SAM file. We then successfully cracked all of the passwords in that file, including the historical user passwords. Once the passwords were cracked, we found that the same credentials were used across multiple systems. As such, we were not only able to access desktops and servers, but also able to access Cisco devices, etc.

In summary, we were able to penetrate into our customers IT Infrastructure and effectively take control of the entire infrastructure without being detected. We accomplished that by avoiding conventional methods for penetration and by using our own unorthodox yet obviously effective penetration methodologies.

This particular engagement was interesting as our customers goal was not to identify all points of risk, but instead was to identify how deeply we could penetrate. Since the engagement, we’ve worked with that customer to help them create barriers for isolation in the event of penetration. Since those barriers have been implemented, we haven’t been able to penetrate as deeply.

As usual, if you have any questions or comments, please leave them on our blog. If there’s anything you’d like us to write about, please email me the suggestion. If I’ve made a grammatical mistake in here… I’m a hacker not an English major.

Outbound Traffic Risk and Controlls

Recently one of our customers asked me to provide them with information about the risks of unrestricted or lightly restricted outbound network traffic. As such, I decided to write this blog entry and share it with everyone. While some of the risks behind loose outbound network controls are obvious, others aren’t so obvious. I hope that this blog entry will help to shed some light on the not so obvious risks…

In all networks, there are two general types of network traffic, inbound and outbound. Inbound network traffic is the type of traffic that is generated when an Internet based user makes a network connection to a device that exists in your business infrastructure. Examples of such connections are browsing to your website, establishing a VPN connection, checking email, etc. Outbound network traffic is the type of traffic that is generated when a LAN based user (or a VPN connected user in some cases) makes a network connection to a device somewhere on the Internet.

Just about everyone is familiar with the risks that are associated with the inbound type. Those risks include things like Vulnerable Web Applications, unpatched services running on Internet facing production systems, etc. In fact, most people associate the idea of security with the inbound connection type more so than the outbound type. As a result, they end up leaving the most vulnerable part of their business open to attack.

The truth is that the size of the attack surface for the outbound connection type is considerably larger than that of the inbound connection type. The attack surface is best defined as the sum of all potential risk points for a particular group of targets. In the case of the outbound connection type, the potential risk points include every variant of software installed on every device capable of making outbound connections (and helper applications too). This includes technologies like Adobe Acrobat, Mozilla Firefox, Internet Explorer, Flash, QuickTime, Microsoft Office, Safari, FTP Programs, Security Scanners, Antivirus Technologies, Smartphones, etc.

One example of an attack would be something like this. An employee receives an email containing an interesting blog entry from Netragard, LLC. That email contains a link that points to a malicious payload designed to compromise the employees computer. When the link is clicked, a request is made to download the payload, which results in the employees computer being compromised. Upon compromise the employees computer establishes an outbound *HTTPS connection to the attacker, and the attacker tunnels back in over that connection to take control of the employees computer. In most cases, the employee has no idea that they’ve been compromised, nor does their employer.

*Because the connection is an HTTPS connection IDS/IPS technologies won’t flag it as suspicious nor is it possible to sniff the connection since its encrypted with SSL. (SNOsoft's Jayson Street)

The compromise doesn’t stop at the employees computer. The instant that the employees computer is compromised then the network that the computer is connected to is also compromised. At that point the attacker can use ARP Poisoning to perform Man in the Middle attacks (or other more direct attacks), or just to capture user credentials. Either way distributed metastasis is almost inevitable if the attacker has any semblance of skill. (Thank god Netragard didn’t really embed a malicious link in this blog entry right?).

The good news is that suffering a compromise doesn’t need to be costly or technically damaging. If the proper policies, procedures and controls are in place then a compromise can be relatively harmless from a cost in damages perspective. Outbound connection controls are an example of controls that everyone should have in place.

If outbound connections are restricted to specific protocols and can only be established by authenticated users then attacks like the one described above will be largely ineffective. The outbound controls might not always prevent the users computer from being compromised, but they will usually prevent the users computer from establishing a connection back to the attacker (which will ideally prevent the attacker from taking control of the computer). In such a case, the computer will need to be reinstalled but at least the rest of the network will still be intact.