One of the most powerful features of CORE IMPACT Pro is the ability to run client side/phishing attacks very easily utilizing its Client Side Rapid Penetration Test (RPT) feature. However, there are likely situations when you want to dig deeper into the product’s functionality based on some specific aspects of the penetration testing engagement that you’re working on.
For instance, by taking advantage of our pivoting technology, you can perform more sophisticated client side attacks once you’ve already penetrated a system.
Let’s say that you’re targeting a network that encompasses a DMZ and an internal network, and somehow you’ve managed to compromise one server in the DMZ. Now, you want to go after the internal network, but it cannot be accessed from the DMZ (or the Internet).
A client side attack against the employees working on that internal network would be good choice (while you test several other things). Of course you can perform your attack from the IMPACT console, but wouldn’t it be better to perform it from the already compromised DMZ hosts?
There are clearly some advantages therein:
1) The targeted victims will see a link pointing to one of their company’s machines that greatly increases the likelihood of them taking the bait.
2) Increased potential to send emails on behalf of actual internal users since you’ve already compromised a company machine which is clearly another significant advantage from the social engineering perspective.
3) The security measures monitoring connections from the internal network to the DMZ would most likely be less sensitive than those employed for connections to the Internet. For example, any traffic going to the Internet would be subjected to stricter rules in terms of IDS or AV systems, or maybe even completely filtered.
In terms of a client side attack, there are three important concepts to have in mind:
1) Sending email: Where the target emails will be sent from.
2) Web Server: Once the email is read and the attachment/link clicked, where the subsequent content will be downloaded from (fake web pages, exploit payloads, etc).
3) Agent Connection: Once an exploit is successful, where the agent running on the target machine will connect back to IMPACT.
When you manually run the modules (instead of using RPT) IMPACT allows control of these three elements independently, meaning each one of the aforementioned actions can be running on different agents (on different compromised machines).
Going back to our initial example, we assumed that we have an agent installed in one compromised server at the target’s DMZ (let’s call it agent(0)).
One easy attack would be:
1) Send the emails from agent(0).
2) Start the Web Server in agent(0) so subsequent content would be downloaded from that machine.
3) Have the new agents installed by our attack to connect back to agent(0) using and HTTPS channel (all agent communication will be tunneled over an inconspicuous encrypted HTTP connection).
With this approach we would end up having new agents connected to our agent(0) and chained back to our console.
How do we do that?
Let’s pick the “One Link Multiple Client Side Exploit” that you can find in the Client Side Tab of Impact Pro (you could also cherry pick any particular exploit if you wanted. If we click the “Parameters” button we will see the options that will allow us to change the agent’s configurations. As mentioned before, we’re going to route the attack through the agent(0).
The following screenshots will show you where you should set the agent to the one installed in the DMZ (agent(0)):
1) For sending email :
2) For Web Server:
If you know the internal hostname of the DMZ host, change the URL BASE parameter ( just the hostname, without http://) and the link sent on the emails will point to that hostname (otherwise it will be the host’s IP addresses). This will make the link look more real.
3) For Agent Connection:
Once all those options are set, click the “Send Email” button and you’re good to go. This module will try to exploit every single client side exploit available in IMPACT Pro for every client connecting to the Web Server. If the attack succeeds, you will get new agents connected to the agent(0).
This is the simplest of examples, but in some scenarios you’re going to face situations where you need to perform every action from the different agents connected. (For instance, sending mails from local agent, having the Web Server in the DMZ agent, and having the agents connect to another agent that is running.)
From that point on you can set the new agents as source and then start playing inside the internal network compromised through two chained agents!
Alberto Solino, Director of Technical Program Management