Real World CANVAS

One of the things I really like about CANVAS is its adaptability. Often when we do a penetration test or application assessment for a customer we'll come up with an attack that isn't a straight forward “run this module, receive root” type of attack. That's where CANVAS' adaptability comes into play for us.

During the heady days of summer 2013 my trusty colleague @markwuergler and I were dispatched to the west coast on an extended consulting engagement. We undertook a Phishing attack from the position of an attacker with access to the internal network (come see more details about this at my PyCon lightning talk). We cloned their internal web based email login page but modified it such that when users posted their credentials it was logged by us, the users were then redirected to the legitimate page and presented with a password error. The logging gave us a key set of information: their internal IP, username and password.

Mark cooked up some magic with Python WMI where we reflected the credentials back at the originating IP, created a new share, uploaded a custom HTTP SSL Trojan to the host and executed it. This didn't give us a 100% success rate as not all users had sufficient permissions to use our upload and execute method but we still came up with a high percentage of compromised hosts.

Since we were going to have CANVAS code running on the remote hosts, we tweaked CANVAS's startup.py script which is run on every new node that connects to CANVAS. For this particular engagement all we did was check our privileges and take a screenshot of the compromised host for reporting purposes. However CANVAS allows us to make automated decisions about our privileges, choose to escalate if needed and then dump password hashes or start monitoring the host's network traffic. In our situation, because the folks checking their mail could be doing so from computers where downtime or lost data would be catastrophic, we had to limit ourselves to something safe. So extensive post exploitation actions including memory corruption based privilege escalation were out.

A lot of work went into this particular attack and CANVAS saved us a lot of trouble. Once we came up with the plan only about 1 day of prep was needed, if we had to implement all that CANVAS helped us automate it would've taken weeks.

This raises the question, if an attacker is in a position to carry out these types of shenanigans on your internal network how do you defend against it? Mark and I had already modified the Trojan to bypass detection by the anti-virus installed on the network, so AV would be of minimal help. One of the limitations of this attack was that we had to touch disk to infect the hosts. A defender can take advantage of this using another Immunity free product, El Jefe, which watches process execution across an entire enterprise. With a little bit of Python elbow grease you can code up an alert which would let you know when a new binary is executed on more than a set number of internal hosts within a certain time period.

As I've participated in consulting with Immunity over the past 5 years one of the questions I've learned to ask myself when writing reports is, what will the client do with this vulnerability information? This attack wasn't that surprising, an attacker with access to an enormous internal network has the ability to run some frightening attacks. What the client does with this is not apply a patch or modify an ACL but it is to start looking at data they hadn't considered before and then figuring out what else that data can tell them about how their enterprise REALLY works. Pen-testing is fundamentally about telling your client something they didn't already know and in this instance I think we did exactly that.