Controlling Agents
Core Impact agents are the results of penetration tests. They work with Core Impact to execute modules (your chosen tasks) on target systems. Every module needs an agent in order for it to operate.
Note that although a module is automatically assigned an agent (the source agent) for execution, it might interact with other agents to accomplish its goal. Refer to the specific module's documentation for more information.
About Agents and WebApps Agents
An Agent (sometimes referred to as an OS Agent) represents an entity on a target system that serves as your conduit to that system. When you create a new workspace there is one agent present, localagent, that comes with the Console. This agent is always the starting point of a new Network or Client Side test since modules that perform initial operations are first executed from the Console. As hosts are compromised, Core Impact deploys agents on those targets. When this occurs, you can instruct any module to run from an agent other than localagent. (see Set as Source in the Interacting with Agents section).
When an Agent is being prepared to be deployed on a target system, a cookie is generated so that the agent can be identified by and connect to Core Impact. This cookie will allow any agent to connect back to Core Impact, even after the Core Impact workspace has been restarted (see Closing a Workspace for details on closing a workspace and leaving modules running).
If Core Impact successfully exploits a host but antivirus or intrusion detection systems (IDS) prevent the agent from being installed, the host will be tagged as 'vulnerable but not exploitable'. This classification will be shown in the host's Quick Info, the Attack and Penetration Summary, as well as in the Vulnerability Report.
IOS Agents are the result of Network Device testing. They represent the information of how to exploit a network device vulnerability. If an IOS agent exists in your Network view under a Network Device, then you have the ability to perform certain post-exploit activities on the device such as opening a command shell. See Post Exploitation Modules for Network Devices.
Android Agents are specifically designed to operate on Android devices.
WebApps Agents are the result of WebApps testing. They represent the information of how to exploit a web application vulnerability. If a WebApps agent exists in your Web View, then you have the ability to perform certain activities on the web application's server. In this regard, a WebApps agent is similar to an OS agent.
The different types of WebApps agents are described below:
- SQL Agent: Represents the knowledge of how to exploit a web application using SQL Injection.
- RFI Agent for PHP: Represents the knowledge of how to exploit a web application using PHP File Inclusion.
- XSS Agent: Represents the knowledge of how to exploit a web application using Cross Site Scripting.
- Web Browser Agent: Obtained when you gain control of a web browser through a XSS attack. Web Browser Agents are launched on XSS agents.
- OS Command Injection Agent: An OS command injection attack is possible when an attacker is able to execute system level commands through a vulnerable page in a web application. Applications are considered vulnerable to an OS command injection attack if they take user-supplied input and use it directly in a system level command.
- WebDav Agent: Represents the knowledge of how to exploit a poorly configured web server.
The below graphic illustrates how Agents and WebApps Agents are created and what steps can be taken from them. Note that from a WebApps Agent, one can optionally deploy an OS agent.
figure 53 - Agents Summary
See Interacting with WebApps Agents for information on how to use WebApps Agents.