All Entries Tagged With: "pro"
Using Core Impact Pro Modules
Core IMPACT Pro has the ability to do a full on Network Vulnerability Test, or you can do just Information Gathering using the Network RPT tabs. There’s little attention paid to the modules that make up the suite of tools – and there is so much fun to be had in there. Maybe there is a time when you want to write your own exploits and execute them in Core; or you want to do specific types of discovery and attack – well, Core IMPACT Pro gives you that ability, with tremendous flexibility. I’m going to walk you through a couple of scenarios using the “modules” view, just to show how simple yet excruciatingly effective that portion can be.
Firstly, create a new workspace and click on the “Modules View” tab at the bottom, left of the Modules workspace. You will see a list of folders.
Take time to look around; look in all the folders at all the available tools, and note the modules structure. You’ll be pleasantly surprised at what is available there. If you wanted to perform a specific targeted attack, or information gathering using a single method, you can have some serious fun here.
I’m going to start with an ICMP sweep to identify all “live” hosts on a subnet.
– double click on the “Information Gathering” folder in the modules workspace. The folder will expand.
– double click on the “Network Discovery” folder – that folder expands also!
– double click “Network Discovery – ICMP”. Input the subnet details you want to scan as shown in the image below, and hit “OK”.
Core Impact will perform an ICMP sweep to find hosts, and will attempt to resolve the hostnames. One thing to notice – this is lightening fast!
Once the sweep is done, Core Impact displays the discovered hosts. That’s great, but I want more information so I’m going to attempt to identify the operating systems of the discovered hosts. For a mostly Windows based network (assumption), I prefer using SMB information gathering.
In the modules workspace:
– double click the OS Detection folder
– drag “OS Detect by SMB” and drop it onto your network block (where it says “Network: 192.168.100.0.)
The module will then attempt to find the OS of all the hosts listed in that subnet. In my example there is a mix of operating systems. There were a few that didn’t come up in the SMB scan so there’s more information to be had. Isn’t there always?
In the OS Detection folder there is Nmap OS Stack Fingerprinting. Using Nmap OS Stack Fingerprinting the same way I used the SMB module (drag and drop) I can see some Cisco routers – I’m even given the IOS rev – useful information indeed – plus I see some Macs. I’m going to take a look at a Mac.
When I TCP port scan the Mac I see the Windows File Sharing services running. I’m going to try enumerating users on this machine by dragging the SMB information-gathering module and dropping it onto the host. The SAMR Dumper module gives me some useful information.
Module "DCE-RPC SAMR Dumper" (v1.18) started execution on Wed Jun 24 16:46:45 2009
Retrieving endpoint list from 192.168.100.2
Found domain(s):
. STEVE-SHEAD-C
. Builtin
Found user: nobody
Found user: root
Found user: daemon
Found user: unknown
Found user: lp
Found user: uucp
Found user: postfix
Found user: www
Found user: mysql
Found user: sshd
Found user: qtss
Found user: imap
Found user: mailman
Found user: appserver
Found user: clamav
Found user: amavisd
Found user: jabber
Found user: xgridcontroller
Found user: xgridagent
Found user: appowner
Found user: securityagent
Found user: sshead
The anonymous user has NULL SMB password.
Received 23 entries.
-- Module finished execution after 2 secs.
These usernames can be used in a password attack on this machine if you are so inclined – but I’m not interested in that right now.
I’m going to scan the IP 192.168.0.254 machine since it looks like a Windows 2000 machine (don’t worry – it’s a security test machine). After checking the open ports listed on this machine I’m pretty sure it’s vulnerable to an older remote RPC exploit (ms06-040 worked on this in the old days) to gain access.
– double click the “Exploits” folder in the Modules view
– double click the “Remote” folder and drag the “MSRPC SRVSVC NetrpPath Canonicalize (MS06-040) exploit” onto the host.
If the exploit succeeds, you will see the agent installed just below the host. Depending on whether you chose a “bind” shell or a “reverse” shell will dictate how you want to interact. I love reverse shells personally.
We can connect to the agent and continue the attack. By right clicking on the agent we can invoke an encrypted remote command prompt. The “ipconfig” command reveals that this machine is dual homed – that means there’s more fun to be had.
I’d like to explore the newly found network using Core IMPACT – why not right? This is one of the many fancy features of Core IMPACT. I can now set the installed agent as a “Source” (right click on the agent and select “Set as Source) and pivot any attack from this agent to the new network. This feature can be extended and remote networks can be explored using “agent chaining” – but that’s another story.
I will start the information gathering cycle again on the newly discovered network and perhaps exploit a Windows XP machine on the remote network.
Ok – let’s stop there for now. You can see that I could have branched off in a number of different directions, attacks, scans and much more, just from messing around in the modules area. Sometimes it pays to get granular and use individual scans and attacks. Sometimes it pays to have the flexibility to craft your own exploits and be able to incorporate them into your Core IMPACT environment. The moral here is don’t just play with the automated stuff – though that is a ton of fun – you’re missing so much more by leaving out the modules – and the modules can lead you in some pretty interesting directions, that you wouldn’t otherwise see if everything was automated.
How to perform a client-side attack without attempting an exploit
This method was taken out in the Core IMPACT Pro 8 release, but it can still be done. I’ve taken the ‘generic’ knowledge base article from the Core Security customer support portal for the 7.5 product, and edited it to show how it works. Core tell me that they are looking to put the ability to perform a client side attack without attempting an exploit back into the mix in the next rev.
Here’s a couple of points to note though – the chances are the AV on the local machine is going to pick up the ‘click’ as a virus called “Bloodhound.Exploit.196″ – your crew will see a lot of anti virus activity if the exploit works. Also, if you have an internal proxy with AV built in, clicking the link will be immediately redirected, and won’t make it through to the exploit web server. Who has an internal proxy though? Right? We do!
An interesting idea that I’ve heard would be to have a message appear on clicking the link in the exploited email that says “You shouldn’t have clicked that! – Contact IT immediately” or whatever your company dictates is appropriate – I’m liking that idea. Any who – here’s the write up.
How to perform a client-side attack without attempting an exploit, and acquire an understanding of users (via their respective email addresses) who are susceptible to a client-side attack.
After acquiring a list of email addresses via the Client-side Information Gathering wizard, perform the following steps:
1. Launch the Client-side Attack & Penetration wizard, specify an email address in the FROM field, choose one or more target email addresses for the TO field, and click Next.
2. For the Attack Type, choose the Web Browser attack and click Next.
3. For the Exploit, click the Change button and select the IE VML Buffer Overflow exploit. For the E-Mail template, click the Change button and choose a message template. Modify the SUBJECT and click Next.
4. Specify an IP address for the SMTP server to which the messages are to be delivered, select the Connect From connection method and click Next.
5. Once the Client Side Attack & Penetration wizard appears in the Executed Modules window (give it a minute or two if you have a huge list of email addresses), right-click the Agent Connector Manager Module that is running beneath it and select Stop.
What will occur is that the Agent Connector module will stop, which prevents the attempt of the exploit, as well as the Client-side Attack & Penetration wizard itself, and the IE VML Buffer Overflow exploit and child module. The only module that should remain running will be the Web Server module.
Note the purpose of the Web Server module is to record any connectivity to it, received the result of a user having clicked the link offered within the email. And if you examine the Module Log window in relation to the Web Server module, if there is any connectivity, it will be reflected here.
After a period of time has passed, if the User Report is generated (found under the Client Side Report Generation wizard), it will reflect the number of email addresses harvested, the number of email addresses tested (AKA attacked) and the number of email addresses of users who clicked the link offered, as well as pertinent information including their email address and IP address, etc.
Detecting Conficker using Core IMPACT Pro
- thanks to Alex Horan from Core Security for help with this post:
We all know that IMPACT Pro can be used to identify machines that are vulnerable to MS08-067 by safely exploiting the vulnerability (and in the process by passing any network and local IPS and other protections in place). But if the machine is already compromised by Conficker then we know that it will no longer be exploitable because the Conficker worm applies an in memory patch to prevent MS08-067 from being exploited on that box (in the “it’s my box now and no one else can play with it’ school of thought.
Felix Leder and Tillmann Werner of the Honeynet Project released a paper (https://www.honeynet.org/files/KYE-Conficker.pdf) that talks about Conficker and in one section has details on how to detect if Conficker has infected a machine. The developers at Core Security Technologies has used that work to create a module that runs inside of Impact and identifies remotely if the machine has had the Conficker in memory patch applied (and therefore has been compromised by Conficker).
How does it work?
Quite simply as it happens, I simply open up a new workspace (or save a little time and use a workspace that already has information about the machines I am interested in checking for the presence of Conficker.
I then go to the Misc folder in what is called the Modules View (effectively a view that allows me granular control over what specific modules or actions I want to perform) and open up the ‘Conficker Detection’ module. Like most modules in IMPACT Pro I could drag and drop this onto a machine or group of machines, but I am going to show how to use the Entity Selection dialog box to specify the targets.
When the module is open I select the ellipsis button next to the TARGET parameter.
In the Entities Selection dialog I have grouped systems by OS and am going to have the module check my entire set of Windows machine for me.
The module runs against each targeted machine, for each machine it connects to exposed dcerpc endpoints and fingerprints them to determine if the machine has been compromised by Conficker. When it is done it will report back to me which machines we identified as being infected by Conficker (and any that it was unable to get any endpoint information from).
If it has I get to see this information in the following places:
• The Module Output
• The Module Log
• The Host Report
• The Vulnerability Report
For me, I simply created a macro that does the following:
• Asks me for an IP address (or Addresses)
• Performs Information Gathering against those machines
• Runs the Conficker Detector against those machines
• Runs the Vulnerability Report
I just start the macro and walk away, when I come back there is the Vulnerability report showing me all the machines that have been identified as having been compromised by Conficker.
