HTB Oopsie reverse shell error

WARNING: Failed to daemonise. This is quite common and not fatal. Successfully opened reverse shell to 10.10.15.176:1234 ERROR: Shell process terminated

I’ve read through the forum and found that the failure to daemonise isn’t major (ie common and not fatal), and it wouldn’t be a ufw issue since I’m getting the shell, but why is my shell terminating as soon as its spawned?

to add a bit more info to this, when i turn the 127.0.0.1 proxy back off I’m getting the shell that immediately closes. Leaving the proxy on gives me the Connection Refused (111) error

@unhappyraccoon try to login into HTB site from a another dev(if you are running in a VM try open the site on Host)…because once you turn proxy on, your connection is terminated in HTB(i think so at least) and the target machine closes too as soon as you turn proxy off(since you are disconnected from HTB the only thing that keeps it awake is the proxy requests(i think that’s what causes the issue) if you try to upload and find the php-reverse-shell manually in the browser blah.blah.bla.blah/uploads/blablablabla i guess you wont be able to, you ll propably get the 404 error rather than 403 on browser. So as i foretold try opening HTB in another dev…

Xx5had0wWol.phxX
im running directly on the host, but i dont know about the proxy causing a dc from the machine, the oopsie pdf tells us to turn the proxy on for burpsuite. i may have missed an instruction saying to turn it back off after the cookie and admin code is found or something though. i just installed parrot on another laptop, so im working to rule out if its an issue within kali, and to see if i did follow the instructions correctly.
i wasnt getting the 404 though, i did get the reverse shell open, but it was closing immediately and i couldnt find a way to keep it open.

Try creating a simple command cradle to execute system commands and receive the output with some kind of listener. Once you have established reliable control you can progress to a a more persistent reverse shell and tty

schoobydrew
simple command cradle… like a python scrpt with it’s own listener so that it’s running from a program and can’t close out immediately? sorry, but i’ve kind of been out of the game for a while.

it has nothing to do with kali or any Os you are using since you have the correct tools to get the job done…proxy doesn’t dc you from the machine…it will dc you from the HTB website-account(https://app.hackthebox.com/))…after you are being dc from HTB, target machine its trying to despawn(that’s where i thought your issue might be.)…i dont know if you understood that on my first post, just open HTB (https://app.hackthebox.com/) on a different device so you wont log out from HTB and maintain connection to your HTB account…if that wasn not the case…keeping the proxy up will make the listener to crash if the designated port we want to listen is already being held from burp(in case you ve inserted the same port on the reverse shell with that of the burpsuite is listening)if still that was not the case too…dont forget before uploading to change and match the reverse php ip(ifconfig @terminal and observe closely this is where your mistake is…its a connection error…look at the interfaces)(target is inside a private network that you have access in it) you propably have an Ip mismatched…

i will attempt to log in on one machine and pwn the HTB machine on another, at least I can hold my connection that way, but I don’t think that would’ve been the issue since I never logged out of HTB during that first attempt. the first time I tried it, I had my openvpn on the entire time(which I believe is a necessity to be on the same network as the HTB machine), but had changed between proxy and non-proxy connections because I couldn’t do web searches in the general clearnet with the proxy on; nothing was loading. I’m not sure which port burp was running on, I hadn’t even considered that but I’ll check that next time, my listener was on 1234 lije the walkthrough suggested though, so that shouldn’t have been the issue. my ifconfig from tun0 did match my uploaded php script, but if those were mismatched i wouldn’t have gotten the reverse shell to open to begin with.
my issue was that the reverse shell connected then closed immediately.
I’m going to try and complete oopsie again tonight, but i will pay careful attention to my ports and keep a second machine logged into my HTB account to prevent a dc error

Didn’t work for me as a resolution. I relogged in, reset the machine, went through the steps, still get Failed to daemonise.

Here are some general troubleshooting steps you can try:

Make sure that your listener is configured correctly. The listener is the program on your attacker machine that waits for incoming connections from the target machine. Make sure that it is listening on the correct IP address and port, and that any firewalls or network devices between the attacker and target machines are configured to allow traffic on that port.

Double-check your payload. Depending on the vulnerability you’re exploiting, you may need to use a specific payload or shellcode to establish a reverse shell. Make sure that your payload is configured correctly and that it is compatible with the target system.

Try a different shell type. If you’re encountering errors with a specific shell type, try using a different shell, such as a Python or Perl reverse shell. Some shells may not work on certain target systems or with certain payloads.

Check for error messages on the target system. If you’re seeing error messages when attempting to establish a reverse shell, check the target system’s logs or console output to see if there are any clues about what might be causing the error.

Try different exploit payloads. If you’re encountering errors with a specific exploit payload, try using a different payload to exploit the vulnerability. Sometimes, different payloads may work better on different target systems.

It’s also important to note that attempting to exploit systems without permission is illegal and can result in serious consequences. Always make sure that you have permission from the target system owner before attempting any kind of penetration testing or exploitation.

Regards,
Rachel Gomez