SNOsoft Research Team: 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:
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.
- 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.
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.
This, http://snosoft.blogspot.com/2010/04/hacking-your-bank.html, is a very detailed account of how a bank was hacked. This methodolgy could be used on almost any large organization.
Last week, 
Posts
Stumble It!
