Extremely loved this box for its path to root. Those who are unaware/ scared / have not learned that part, its highly recommended (at by me) to do it first locally and then on actual machine.
My Hints:
User:
You may stuck in rabbit hole. I did. Be careful. Nothing much is required. Read all pages carefully, Google accordingly. You will find it easily.
Understand the difference between (Reverse) Shell and RCE
Root:
You will easily find an exe. Google it.
Do it manually on you machine first. Once you are confident, do it on actual machine.
Yes there are tools to convert script to (windows) executable
This was a fun, easy box with an opportunity to learn a few things from. There are a couple of rabbit holes that may catch you, I spent way too much time on one of them.
User:
There are certain pages that you should always check first because they provide information or a way in, this box was no different.
Google is your friend (If you’re searching verbatim what you found on the box, Google might show you something a little different)
Find out what you can do with the foothold in, then make it better with a common tool
Root:
This is where it can get extremely frustrating. I knew what needed to be done quickly, but I didn’t know how to do it. I’ve done this kind of “workaround” before, but never with windows.
ENUMERATE!!! There are two places to find the vulnerability (one will show you it’s on the system the other will show you if it’s running).
Google is still your friend
You can use the original way in (user step 3) with this exploit to get admin (no metasploit needed).
does anyone have an issue running an exploit where the issue is:
ImportError: No module named colorama ?
I’ve reinstalled this module over and over but the exploit still can’t seem to find the module.
Did you install it for the right Python version?
I had it once that I installed a module for python using pip(2), but never noticed that the script was running with python3
does anyone have an issue running an exploit where the issue is:
ImportError: No module named colorama ?
I’ve reinstalled this module over and over but the exploit still can’t seem to find the module.
This might be an issue between python2 and python3. If you’ve installed the module into python2 and are running the exploit with 3, it might never be able to find it (and no amount of pip install colorama will solve it.
If you are on Kali there have been issues in the past where some modules end up causing nightmares.
If all else fails you can remove it from the exploit - its only really there to make the output look pretty and lots of people get misled into thinking its a shell rather than an RCE because of this.
Can anyone help me with the last step of root? I’ve got everything set- my reverse shell just keeps dying right when it connects back. So far it is the only payload I’ve gotten working… windows/meterpreter/reverse_tcp
It worked in a Win10 VM.
priv esc - port forwarding is a waste of time IMHO. Build the exploit on a windows machine with the py tool is the way to go. I did both plus You will need to know how to craft an executable from a script, at least on the OSCP. Trying to run the privesc through a tunnel might expose your IP address. Just move the .ex* the same way you did to upgrade your shell initial user shelluse the telepa**& . After you craft your py into an ex* on a windows machine. You will have to listen at your port from the “venom shell” you created. Google a tutorial if you don’t know how to do it. Let me know if this is too much of a spoiler.
Can anyone help me with the last step of root? I’ve got everything set- my reverse shell just keeps dying right when it connects back. So far it is the only payload I’ve gotten working… windows/meterpreter/reverse_tcp
It worked in a Win10 VM.
Try to exploit it with a non-meterpreter shell payload, and see what is going on.
“AV evasion is an ever evolving progression”
Can anyone help me with the last step of root? I’ve got everything set- my reverse shell just keeps dying right when it connects back. So far it is the only payload I’ve gotten working… windows/meterpreter/reverse_tcp
It worked in a Win10 VM.
Try to exploit it with a non-meterpreter shell payload, it should be fine.