On internal penetration tests, it is common to get a foothold using man-in-the-middle techniques such as Link-Local Multicast Name Resolution (LLMNR) or WPAD. On a recent engagement, we encountered an added challenge because NetBios over TCP was disabled and WPAD was configured correctly. At this point, it is typical to begin hunting for systems with default credentials, such as Tomcat or JBoss. When looking at systems running on port 8080, we encountered a technology we had not come across before: CA Process automation. It wasn’t something we knew we could use, but we figured it was worth checking out. It turns out, we were right.
The login prompt which greets you when you connect to http://<IP>:8080/itpam/Web.jsp
Default Credentials
After doing some quick searches, we discovered that the default credentials for the admin account are pamadmin/pamadmin. We give these a try and bingo, we are in.
We spent some time looking through the various features of the application. First, we noticed that there were credentials stored by the application for Windows user and Microsoft SQL Server accounts. Unfortunately, these were stored in a masked form (starred out), and were also starred out in the page source. We learned the names of some SQL servers, but none of these had easily-guessable (sa/blank) passwords.
After this, we started losing interest and refocused attention on finding other low-hanging fruit. After some time, we came back to CA Process Automation to see if there was any other functionality which we could use to our advantage.
Command Execution – Designer for the Win
After poking around further, we found the “Designer” tab. This is used by administrators to create workflows, or decision-driven processes, in order to facilitate the duties of a systems administrator. One useful functionality is the ability to execute scripts, such as PowerShell, at steps within the process. At this point, we realized we had discovered gold.
We begin by creating a new process. Next, we add a “Run Script” object by dragging it onto the new process.
Our new process with the “Run Script” object placed at the beginning of the workflow.
Now modify the “Run Script” object so we can configure what command to run. Set the “script extensions” parameter to “ps1” so that we can run PowerShell, the hacker’s best friend. Now, place the contents of your script into the “Inline Script”. Finally, save the process and execute it.
The script is configured to execute a PowerShell command (i.e. rip back a shell).
If all goes well, at this point we should be looking at a Cobalt Strike Beacon or Meterpreter prompt.
After running the process, we see a new connection to the command and control server.
Our beacon is running under the context of SYSTEM, meaning that CA Process Automation will execute commands for us as SYSTEM. What do we do now? Mimikatz, of course! Now that we have domain credentials, we can begin the next phase of the engagement as an authenticated user.