Monday, April 26, 2010

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.

22 comments:

  1. Great work, can I ask how did you find out the pdf reader is not updated or patched for the vulnerability?

    ReplyDelete
  2. 3 Questions :

    1)"send that PDF document to the bank’s AR/AP department from the banks trusted IT Services provider."
    Did you fake mail ?? wasn't it stopped by their spam filters in place ?

    2)For AV evasion checking did u do virustotal ? OR check locally ?

    3)In your experience as a pentester how often
    has pdf-embedded-exploit (as a matter of fact any email vector) worked ? Any statistical data would be helpful :D

    Thanks

    ReplyDelete
  3. Metasploit? Polypack? Wait... *eyes narrow*...were you using script-kiddie automated tools that you famously rail about?

    :) Yes, I'm being a jerk with that silly question, and partly poking fun, so don't take that too seriously!

    Nice article! This is certainly a very real issue these days and will only get worse, but one problem I have is how you would truly protect against an attack like this? Once you're in control of a system, that's one thing, but all that stuff up to and including that part aren't terribly easy to mitigate. (This is why I think this avenue is only going to get worse for us, because it's not easy to fix.)

    - control information about bank infrastructure: I guess you could tell techs not to post technical details online in support forums and such...but you really can't stop that very well other than knowledge. And even then someone will do it and that's that; the info is out. Hopefully techs would just use aliases for this...

    - Facebook or social networking profiling: Should employees simply not advertise their job affiliation or not connect to suppliers on social networks? I feel that this is in the same boat as above, it'll happen even if we stomp our feet.

    - HR interview: Would HR do anything different to help protect against harvesting data this way? I doubt it. (They are also ripe for sending malicious resume files to!)


    I guess I like to assume an attacker will know (or be able to easily find out) what your infrastructure posture is, your OS, some of your generic technologies, and have access to a corporate directory at some point, with a way to contact them all (email/phone) if desired.

    - PDF payload and system ownage: Ok, AV vendor fail to start, and I don't think there is realistically anything that can be done about that unless you work at the vendor. You can wag your fist and threaten to change vendors, but you're just getting in a different boat; you're still in a boat in the same ocean. Could this have been mitigated with patches and running as reduced privilege users? You'd have to answer that. :) OS patches are a gimme, but software patches like Acrobat...new pain in the ass.

    - HTTPS tunnel out: While I do have sympathy for those who say you can inspect https traffic by issuing trusted certs and sitting in between the transactions, I don't think there is any really good way to then determine between good traffic and unwanted traffic short of having people check these things manually...and then you open the privacy issues up. Blacklisting through a web filter will work...if the vendor knows to reduce the reputation or flag endpoints for malicious issues. But if you're being targeted, then the attacker is just going to get a new Dreamhost box and hit you from someplace on one else has seen as bad. Either way, I think end-user egress control is difficult, or at least takes some good security staff working on the problem!

    The rest once you got control of a box is a different ballgame, and there are plenty of things to do for detection and segmentation and best practices (doh, vnc on a dc...). :)

    Again, thanks for posts like this. Hopefully it helps demonstrate to technical and non-technical folks alike that these possibilities exist and do happen! Getting buy-in on these things is still a huge problem.

    -LonerVamp

    ReplyDelete
  4. This is really quite cool :) A bit scary how you used the social networks to get important information easily but still, quite cool.

    ReplyDelete
  5. Nice one! This is hardly "unorthodox" though. Passive recon is traditional, followed by a canned PDF client-side exploit, which is SOP in 2010. Nonetheless, excellent write-up!

    ReplyDelete
  6. interesting article and very well written. Only mistake is a mystyping (Before we sent the PDF to the our customer) but then again english is not my first language :) There's a lot of food for thought, thanks.

    ReplyDelete
  7. My question is: What tool or tools did you use to perform ARP poisoning on the compromised host? Arpspoof? Did you use arpspoof with meterpreter's sniffing capabilities?

    Also, were you able to get SYSTEM level privileges on the compromised host?

    Thank you for your post, I greatly appreciate it.

    ReplyDelete
  8. Just goes to show just how much of a gold mine sites like Facebook and LinkedIn are, when it comes to social engineering as well as knowing who to target.

    And, as near as I can tell, there's not really any particularly good way for any medium-to-large size company to stop this kind of information leakage. Even if you did want to risk the wrath of your employees by enforcing strict policies about discussing their job, there's just too many non-compliant employees and too many external points of contact to really prevent it.

    Pretty depressing stuff for an info sec specialist.

    ReplyDelete
  9. Eh...

    They were using the same passwords on their Cisco/other kit as they used on their user accounts?

    That's such a big ... ... ... screw-up that it's hard to imagine.
    (Even worse than running the same AV SW on both servers and desktops.)

    How was it possible for your payload to install on the user's PC?
    Or did the user have admin access on it?

    ReplyDelete
  10. One word: scary! I would expect a bank to be better prepared! Of course, they did hire you to find and fix problems, but they *were* already in operation, right?

    ReplyDelete
  11. Ingenious, fascinating, well written and... well, scary. From the point of view of a bank 'end user', the sooner this sort of thing is openly discussed by the banks the better. I won't hold my breath though.

    ReplyDelete
  12. Very good story, enjoyable read. Highlights how much easier nowadays it is to get the client to do the hard work for us and move on from there.

    ReplyDelete
  13. Wow, thanks for the response and comments. I'm not going to be able to reply to all of these comments because I do have to work too. ;) I will try to address a few in the near future.

    ReplyDelete
  14. Also good write up on a "pen-test" although you left out some important information, namely. How did you determine the scope and boundaries of the assessment, How did you package the results to the client? Did they include risks or prioritization? How did the client respond? How were you asked to assist going forward? A pen-test is of absolutely no value if the appropriate root-causes and follow-up actions identified and reported.

    Thanks!

    ReplyDelete
  15. Very well written. Nice entry :)

    ReplyDelete
  16. Thank you for providing a very clear writeup of your work. Despite another commenter saying this is SOP, not many other people blog so straightforwardly as this. And thanks to your client for being understanding about your communications :) Everyone has to deal with this!

    ReplyDelete
  17. In response to: April 28, 2010 2:37 PM

    ----------------------

    I agree that there's nothing unorthodox about using metasploit and its respective PDF functionality. But if you're saying that our methodology is Standard then I challenge you to prove it.

    ReplyDelete
  18. In response to beloved LonerVamp

    ---------

    My issue with automated tools isn't really an issue with the tools as much as it is an issue with the people/vendors using them improperly.

    Everybody knows that the tools won't produce high quality output (when compared to the results produced by a true expert), but everybody also knows that they aren't designed to do that.

    Automated tools are designed to make testing efficient, to identify low hanging fruit, and to reduce cost. They are designed to assist security professionals with testing or to help IT people maintain their networks. Use them right, and they are awesome.

    What really gets under my skin is when a security vendor produces a report that is the direct product of an automated tool and tells the end customer that its the product of talent and expertise. That happens all too often.

    ReplyDelete
  19. Robert Bannerjee said...

    3 Questions :

    1)"send that PDF document to the bank’s AR/AP department from the banks trusted IT Services provider."

    Did you fake mail ?? wasn't it stopped by their spam filters in place ?

    Yes we faked the email.

    2)For AV evasion checking did u do virustotal ? OR check locally ?

    Checked locally using he same AV scanner (and yes they used the same one for the server too, but that's since changed for obvious reasons).

    3)In your experience as a pentester how often
    has pdf-embedded-exploit (as a matter of fact any email vector) worked ? Any statistical data would be helpful :D

    The short answer is that it depends. Every target is unique and every customer has a different network. We've used email based attacks in a variety of ways with great success (and some failure). In fact, we even exploited a vulnerable AV scanner at one point. ;)

    ReplyDelete
  20. Everybody knows that the tools won't produce high quality output but everybody also knows that they aren't designed to do that.
    Dallas web design company

    ReplyDelete