We are excited to announce the release of v12.5 of CORE Impact; it has been the result of a lot of time talking to customers and translating what they need to be successful into action items for pretty much all groups in the company. Impact v12.5 contains many great new features and enhancements, which you can read about here or see videos of here. However in this blog we wanted to take a moment to introduce one significant feature, the Identity Manager. Back in 2001 when Iván Arce and Max Caceres presented on the idea of Automated Penetration Testing and released a white paper on the topic we had decided to build the first automated penetration testing framework to help advance the state-of-the-art in penetration testing. When we developed Impact we were focused on network remote code execution, with the goal of deploying our patented Syscall Agent on a compromised system we could see across the network/internet. Over time, and as the world changed, we released the ability to send attacks by email, targeting users inside a network, and then Web, WiFi, Network Devices and Mobile. As the world continues to evolve, so to do the attacks and the capabilities of Impact. With modern operating systems and (most) commercial applications offering an auto update, the time needed to apply a patch is shortening. Depending on the frequency of your testing this can have an impact on the amount of risk you are able to find in a given environment. However, what tends to remain constant in those systems are the authentication mechanisms used to grant legitimate access. Because of this factor we have created the Identity Manager within Impact v12.5.

What is an Identity? An Identity is any set of information that can be used to authenticate to a machine, this can be the username and password (that most people think of) or a SSH key, a cookie etc. This information can be found via Remote and Local Information Gathering on a target systems – any Identities found on those systems could be tried against other systems in the same environment to see if they are valid. They can also be guessed or brute forced during your testing.

As with most capabilities provided by Impact, there is more than one way to carry out this type of testing and you can choose the method that better fits your style or scenario. You can perform Identity testing via the Rapid Penetration Test (RPT) or using individual Identity Verifier modules. And can also interact with the discovered identities through the Impact GUI, to perform further tests on specific ones. We would go into more depth around how to utilize the individual Identity Verifier modules in a follow on blog post, as they are so powerful they deserve their own post.

The Network Information Gathering wizard is configured to attempt to pull Identity information from machines with the appropriate exposed services automatically. Typically, it will pull what we term partial identities, which is part of the information needed to form a complete identity. Think of a machine where SMB is accessible, depending on the configuration of the machine it may be possible to dump the user list from that machine (another example would be finger). We have a list of possible user accounts but we don’t have the associated passwords for those accounts.

 The Network RPT helps determine the appropriate passwords (and can find other Identities) via the Network Attack and Penetration wizard. The wizard will ask which type of testing it should perform (code execution and/or authentication weaknesses) and if both are selected what order these test should be carried out in. There are five different types of testing available in the RPT, we intend to explain the default testing type (Know and Default Identities), but to explain that it is necessary to first explain what default Identities and Known Identities are:

  • Default Identity – This is a service specific default (think postgres / postgres) Identity
  • Known Identity – These are Identities that have been discovered during the course of the testing.

Default Identities are those that are specific to a protocol; as a result we had to create Identities lists for every protocol we support testing. Researching to do this was an intense process. We first polled our technical community for the identities lists they used when facing different services. We also polled Google to find other sources of identities lists for the protocols we are testing. Each source was given a different weighting, as the order in which Identities are attempted is very important to us. We have also been quite fortunate that there were a number of large password leaks recently, that allowed us to reverse the encrypted passwords and determine the most popular identities in use, which we have also used in our identities sorting. We have two levels of testing when trying Default Identities (we also have dictionary-level attacks as you would expect), Quick and Deep. The amount of Identities attempted in a Quick test vs. a Deep test varies from protocol to protocol, as for some protocols an authentication attempt takes longer than others. Our consideration was the amount of time a Quick test would take vs. a Deep test. Of course for some protocols there are no default accounts that are configured when the application is installed. In these cases we used the most common username and password accounts identified in our research. As we mentioned there are 5 different types of Identity testing available within the RPT; you can read a summary of them here but if you are interested we would love a chance to demo this new capability to you!

Option Description
Default Identities Impact ships with lists of default and common Identities for each protocol it can test. This option will use those default lists to attempt to learn if any of the available services can be access with a default or common credential.
Known Identities As we have seen in this document we are able to discover Identities for systems during Information Gathering and Post Exploitation, as well as import Identities. This option will attempt to validate those identities. NOTE: If any of those Identities are missing a password (i.e. a partial identity) then it will be combined with passwords from a built in dictionary of common passwords.
Known and Default Identities (Default Selection in Wizard) A combination of the above two options, Impact will test both the default and common Identities for each service as well as the Identities that are known within this workspace.
Dictionary Attack Dictionaries of common usernames and passwords for each protocol are used to attempt to find valid Identities for each protocol. This method has the potential to be quite time intensive if the user extends this testing to include their own dictionary.
Custom The user can define a customer configuration for the identity testing that will be carried out.

Impact v12.5 has been exciting to work on, from the initial customer calls to ensure we were building the right thing, through the design to ensure the testing would be as efficient as possible with minimal disruptions, through to the buzz we received at some pre-release events. Alberto Soliño – Technical Product Manager Alex Horan – Product Manager