I've been running a honeynet for about 4 years now and in the past 6 months I've seen a dramatic shift in attacks. There are probably many people that would argue this, but the age of automatically spreading malware seems to be past. Before someone jumps down my throat let me explain. There will always be the vulnerability that is wormable, but with some of the protective measures being implemented by default now, a lot of this is mitigated. When was the last big global worm? There will always be the exploits that the kidiots download and run but seeing the same thing over and over again gets old fast when it's not a real situation.
For a time, I was fighting off FXP groups(which was very amusing actually), people loading up rootkits etc etc..but that seems to have dropped off. I think we're experiencing and have experienced a dramatic shift away from the automated kits that so plagued us for the past few years. The focus has become the user, and their gullability. There are some great honeynet tools out there now to go out and search websites but needless to say, my honeynet has gone dormant for the time being.
That said I've been considering modifying my honeynet to facilitate forensics and incident response, and not just for my own use. I haven't quite fleshed this idea out, but I'm wondering if it would even be considered useful by others.
We have hacking labs online for the public, why not forensics and incident response labs?
Imagine a network that was randomly infected with malware and compromises, and you had access to it, not only to check it out but actually test your response procedures and skills. Essentially what I'm saying is take The Hackers Challenge and make it a live situation. As I said I haven't fully fleshed this idea out, but would it be useful and interesting or just a waste of time?
Thoughts?
Friday, March 30, 2007
Monday, March 26, 2007
Vista Complete Backups part 2
I spent a little more time with Windows backups today working on the shadow copy type of backup that's available. I started by looking at the Backup Rules registry key in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\ScheduleParams\Rules
to decode the values in to something that actually makes sense. First a little explanation of the Key. Automatic backups can only be scheduled in Vista Ultimate and Business/Enterprise editions. So, if you're looking for this on a system that isn't one of these, good luck.
Under Rules you'll see a numerical value that corresponds to your drive letter. 1 is C, 2 is D and so on. These keys exist ONLY if you've selected them in your backup configuration. Let's look under key 1 shall we?
Here's what my system looks like. As you can see I am looking at my C drive backup configuration for automatic backups.
As I was looking at this I thought, what the heck is that hex value? It says flags, but what flags are they? Explanation forthcoming....
As you may have noticed, I like to use pictures to explain things (art is the international language right?)
Here's what I've gathered so far and I think it's fairly complete:
Each type of data in these backups is a power of 2 as shown here and please excuse my paint-fu or lack of.
As you can see I added in the numerical value of each data type that Windows Backup tries to use by default. Don't ask me why 16 is not there - if someone knows, please indulge me.
The backup flags begin counting at decimal value 1073741824 (0x40000000)
Add the data types in the image above to this number and you'll be able to decode any value you see.
Here's a quick cheat sheet:
Pictures only - 0x40000004 1073741828 - value of 4
Music - 0x40000001 1073741825 - value of 1
Videos - 0x40000002 1073741826 - value of 2
Documents - 0x40000008 1073741832 - value of 8
Email - 0x40000040 1073741888 - value of 64
TVshows - 0x40000080 1073741952 - value of 128
Compressed - 0x40000020 1073741856 - value of 32
Additional - 0x40000100 1073742080 - value of 256
All types selected - 0x400001ef 1073742319 - value of 495
It should be a matter of simple addition to decode the backup flags value now.
to decode the values in to something that actually makes sense. First a little explanation of the Key. Automatic backups can only be scheduled in Vista Ultimate and Business/Enterprise editions. So, if you're looking for this on a system that isn't one of these, good luck.
Under Rules you'll see a numerical value that corresponds to your drive letter. 1 is C, 2 is D and so on. These keys exist ONLY if you've selected them in your backup configuration. Let's look under key 1 shall we?
Here's what my system looks like. As you can see I am looking at my C drive backup configuration for automatic backups.
As I was looking at this I thought, what the heck is that hex value? It says flags, but what flags are they? Explanation forthcoming....
As you may have noticed, I like to use pictures to explain things (art is the international language right?)
Here's what I've gathered so far and I think it's fairly complete:
Each type of data in these backups is a power of 2 as shown here and please excuse my paint-fu or lack of.
As you can see I added in the numerical value of each data type that Windows Backup tries to use by default. Don't ask me why 16 is not there - if someone knows, please indulge me.
The backup flags begin counting at decimal value 1073741824 (0x40000000)
Add the data types in the image above to this number and you'll be able to decode any value you see.
Here's a quick cheat sheet:
Pictures only - 0x40000004 1073741828 - value of 4
Music - 0x40000001 1073741825 - value of 1
Videos - 0x40000002 1073741826 - value of 2
Documents - 0x40000008 1073741832 - value of 8
Email - 0x40000040 1073741888 - value of 64
TVshows - 0x40000080 1073741952 - value of 128
Compressed - 0x40000020 1073741856 - value of 32
Additional - 0x40000100 1073742080 - value of 256
All types selected - 0x400001ef 1073742319 - value of 495
It should be a matter of simple addition to decode the backup flags value now.
Pen testing and incidents
I was reading the latest information security mag and came across the face off column that Marcus Ranum and Bruce Schneier have. For those that haven't read this column before, the name of it "face off" tells you what it's all about.
It wasn't so much what they were debating that got me thinking, but rather it caused me to reflect back on a comment I once heard. I was sitting in a Hacking By Numbers session put on by SensePost. If you haven't had the opportunity to check them out, it's definitely worth it and the tools are great too. Anyways, it was during this session that we got in to a discussion about speed vs stealth of attacks on networks and systems. The old school of thought was that it was best to be stealthy while attacking networks. Making heavy use of IDS evasion techniques, clearing logs etc was the order of the day. After talking to these guys a little, then comparing what was said to the attacks I've seen and dealt with, the exact opposite is true. Speed seems to be the best option for many attackers, who cares if you splatter logs, the chances of being prosecuted for infiltrating a network is slim at best. If there was one thing worth remembering from the HBN session, it was something the instructor said...
"Stealth doesn't matter that much, I can set off your alarms 100 times or more as long as I accomplish my objective. I can screw up as many times as it takes to achieve my goal. You guys or your system administrators can only mess up once."
When I talk to sysadmins about incident preparation and detection I usually bring this up because the point is, we are up against a determined enemy and when it comes to protecting our networks and systems we need to be just as vigilant about protection as they are about accomplishing their objective.
It wasn't so much what they were debating that got me thinking, but rather it caused me to reflect back on a comment I once heard. I was sitting in a Hacking By Numbers session put on by SensePost. If you haven't had the opportunity to check them out, it's definitely worth it and the tools are great too. Anyways, it was during this session that we got in to a discussion about speed vs stealth of attacks on networks and systems. The old school of thought was that it was best to be stealthy while attacking networks. Making heavy use of IDS evasion techniques, clearing logs etc was the order of the day. After talking to these guys a little, then comparing what was said to the attacks I've seen and dealt with, the exact opposite is true. Speed seems to be the best option for many attackers, who cares if you splatter logs, the chances of being prosecuted for infiltrating a network is slim at best. If there was one thing worth remembering from the HBN session, it was something the instructor said...
"Stealth doesn't matter that much, I can set off your alarms 100 times or more as long as I accomplish my objective. I can screw up as many times as it takes to achieve my goal. You guys or your system administrators can only mess up once."
When I talk to sysadmins about incident preparation and detection I usually bring this up because the point is, we are up against a determined enemy and when it comes to protecting our networks and systems we need to be just as vigilant about protection as they are about accomplishing their objective.
Sunday, March 25, 2007
Damaged CD media
Last year I signed up for the DC3 forensics challenge while at the Blackhat conference. I never really got around to participating in the challenge due to time constraints though. I still have the packet sitting in my office and one day decided to play with the CD challenge. In this challenge I was presented with a CD that has some data on it, and it's been cut in to two unevenly sized pieces. The task is to retrieve the data. The data rings on the cd were small, roughly 50MB by the looks of it. Of course at this point, the 2006 challenge is over with and AccessData won the challenge but I never saw the reports posted anywhere. So, on to some CD fun!
I found the CD to be one of the more interesting challenges so I did some experimenting. In the name of experimentation some of the things I tried were:
Take a CD, write 50MB of data to it, cut it with an exacto knife, then trying to piece it back together using electrical tape. This actually worked...once. However it never worked in subsequent trials so this method was abandoned.
Take a CD, write 50MB of data to it, cut it with an exacto knife, then try to glue it to another CD. This failed miserably. The glue seeped in to the wrong places and the disc wouldn't budge in the reader.
Finally, I took a CD, wrote 50MB to it, and cut it with an exacto knife, then cut it again, and again and again and again, until I got something that resembled a credit card cd. This worked, over and over and over again. It worked in all 5 trials and was labeled the winner as you can see below what one disk looks like on the front and back.
As you might notice this particular test copy was broken - it's been in my bag for 6 months.
So, what's the trick here? Remember that CD's must maintain balance to spin properly inside of your reader. By cutting the disk to a smaller size, some extra weight was removed and the CD is no longer lopsided, so it balances easier and it now fits within the inner ring of the reader drive much like the credit card cd's do.
One other thing to remember, while experimenting with this some fun with a paper cutter was had. There's nothing like applying obscene amounts of cutting force to optical media!
The 2007 DC3 challenge has been posted on the DC3 site. Registration isn't open yet, but the topics look really interesting this year. Pay attention to the first three and you might notice that I've been talking a little about each one ;)
* BitLocker Breaker
* TPM Trickery
* Damaged Media Recovery
* Real vs. Fake Image Analysis
* SAM Attack
* Sizzling Thumb Drive
* Steganography Tracks
* Password Cracking
* Hack That
* and more...
I found the CD to be one of the more interesting challenges so I did some experimenting. In the name of experimentation some of the things I tried were:
Take a CD, write 50MB of data to it, cut it with an exacto knife, then trying to piece it back together using electrical tape. This actually worked...once. However it never worked in subsequent trials so this method was abandoned.
Take a CD, write 50MB of data to it, cut it with an exacto knife, then try to glue it to another CD. This failed miserably. The glue seeped in to the wrong places and the disc wouldn't budge in the reader.
Finally, I took a CD, wrote 50MB to it, and cut it with an exacto knife, then cut it again, and again and again and again, until I got something that resembled a credit card cd. This worked, over and over and over again. It worked in all 5 trials and was labeled the winner as you can see below what one disk looks like on the front and back.
As you might notice this particular test copy was broken - it's been in my bag for 6 months.
So, what's the trick here? Remember that CD's must maintain balance to spin properly inside of your reader. By cutting the disk to a smaller size, some extra weight was removed and the CD is no longer lopsided, so it balances easier and it now fits within the inner ring of the reader drive much like the credit card cd's do.
One other thing to remember, while experimenting with this some fun with a paper cutter was had. There's nothing like applying obscene amounts of cutting force to optical media!
The 2007 DC3 challenge has been posted on the DC3 site. Registration isn't open yet, but the topics look really interesting this year. Pay attention to the first three and you might notice that I've been talking a little about each one ;)
* BitLocker Breaker
* TPM Trickery
* Damaged Media Recovery
* Real vs. Fake Image Analysis
* SAM Attack
* Sizzling Thumb Drive
* Steganography Tracks
* Password Cracking
* Hack That
* and more...
A little rant
I've been waiting and waiting for a forensics equipment company to release evidence bags for digital evidence but I've yet to see it. I've searched, asked on mailing lists and still there isn't a single company that provides evidence bags for digital evidence. Seriously, digital evidence is mainstream now, and we should demand that suppliers provide us with evidence bags that allow us to provide an adquate description of the device contained within. In addition, when I bought my yearly supply last year not a single evidence bag was anti-static. I ended up buying anti-static bags from Uline and I stuff the evidence inside of them, seal the bag, then seal that bag inside of a generic evidence bag. So, vendors, if you ever read this blog or hear about it..provide us with proper equipment! The closest I've seen is from a company called SecurityBag
Other types of evidence have specific containers. Arson evidence is stored in metal cans, DNA swabs exist with caps to seal them, yet we can't properly identify our evidence on our bags.
This brings up another question I came up with recently, and maybe someone else has tried this already, but I wonder is the glue that holds together "tamper proof" bags succeptible to tampering? I think I'll have to sacrifice a few bags to testing.
Other types of evidence have specific containers. Arson evidence is stored in metal cans, DNA swabs exist with caps to seal them, yet we can't properly identify our evidence on our bags.
This brings up another question I came up with recently, and maybe someone else has tried this already, but I wonder is the glue that holds together "tamper proof" bags succeptible to tampering? I think I'll have to sacrifice a few bags to testing.
Peer Review
One of the foundations of science is that scholarly work or ideas should go through a peer review process so the work can be validated and accepted or refuted and thrown out as an invalid theory. When it comes to digital forensic "science" I have to admit, I don't see much of this. Sure, we have a few scientific journals like Digital Investigation and organizations are popping up all over the place but I have yet to see any peer review being done of the core forensics processes. Take something as simple as disk imaging and ask two examiners how they acquire an image. I can almost guarantee you'll get two different answers. Does our field have any real requirement for image acquisition other than the hashes must match? Of course we must take precautions not to modify the contents of the evidence, but what if a suspect disk crashes while you're imaging it? Is that something we have any control over? Shouldn't you have been able to predict this event? We have tools like SMART to help predict disk failure, but how many of us collect this information before acquisition? Most of the time we can't even collect this information because our write blockers prevent the commands from reaching our disks!
How about how someone processes an image? What information is processed? How do you collect the information?
Forensics teams are popping up all over the place these days or the requirements are being built in to job descriptions of security folks, but how many of these groups actually get their processes peer reviewed? The answer is very very few. I know a few people that actually offer to peer review processes for others - for a price of course but this service isn't advertised.
This all points to one of the problems with our field. We don't yet have the scientific infrastructure in place to support promoting ourselves as scientists and our field as a science. One facet of the problem is that in many cases, digital forensics isn't considered a science, it's a business process and we all know that business processes are considered privileged information by the business community. Let me put it another way, companies don't disclose intrusion information because they fear public embarrassment or a drop in stock price. They also don't allow their people to disclose their forensics processes because they fear that something might be proven wrong or inadequate in the process.
Unfortunately, these processes can be dragged in to a court room at some point and be extremely damaging when the opposition rips apart what passes for an operational forensics process but not a legal one.
What I'm proposing is we develop a standard for the major activities carried out by a digital forensics examiner/team and a formal peer review for forensic processes. Maybe I've been going to the wrong conferences but to date, I've never seen anyone submit a formal process for public peer review (sorry but I don't consider $300 journals as a public forum -it's quite biased economically)
To put my money where my mouth is so to speak I'll soon be posting an acquisition procedure I wrote using Helix for review and validation as well as subsequent use/modification by anyone that is interested.
How about how someone processes an image? What information is processed? How do you collect the information?
Forensics teams are popping up all over the place these days or the requirements are being built in to job descriptions of security folks, but how many of these groups actually get their processes peer reviewed? The answer is very very few. I know a few people that actually offer to peer review processes for others - for a price of course but this service isn't advertised.
This all points to one of the problems with our field. We don't yet have the scientific infrastructure in place to support promoting ourselves as scientists and our field as a science. One facet of the problem is that in many cases, digital forensics isn't considered a science, it's a business process and we all know that business processes are considered privileged information by the business community. Let me put it another way, companies don't disclose intrusion information because they fear public embarrassment or a drop in stock price. They also don't allow their people to disclose their forensics processes because they fear that something might be proven wrong or inadequate in the process.
Unfortunately, these processes can be dragged in to a court room at some point and be extremely damaging when the opposition rips apart what passes for an operational forensics process but not a legal one.
What I'm proposing is we develop a standard for the major activities carried out by a digital forensics examiner/team and a formal peer review for forensic processes. Maybe I've been going to the wrong conferences but to date, I've never seen anyone submit a formal process for public peer review (sorry but I don't consider $300 journals as a public forum -it's quite biased economically)
To put my money where my mouth is so to speak I'll soon be posting an acquisition procedure I wrote using Helix for review and validation as well as subsequent use/modification by anyone that is interested.
Friday, March 23, 2007
Vista Complete System Backup
Lately, I've been kicking around a few Vista Enterprise systems for testing and am working analyzing some of the "new features" of Vista. One such "new feature" is the Backup and Restore Center.
Microsoft decided to change the backup program a bit in this latest OS release. They finally moved away from the old interface they stole from Seagate and Veritas.
As you can see below, we now get the flashy GUI that tells us some interesting information. We can see when I made a complete disk image and when I tried out the shadow copy backup.
After making these backups I thought, hey wait..this has got to exist in the Registry. Like everything else in Windows there is indeed a Registry entry for the new Windows backup system.
You can check it out on your own systems here:
HKLM\software\Microsoft\Windows\CurrentVersion\WindowsBackup
Underneath there I found a few subkeys, one of which is SystemImageBackup.
In here I found a series of values which I exported:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\SystemImageBackup]
"LastBackupResultHr"=dword:00000000
"LastBackupResultHrDetailed"=dword:00000000
"LastBackupTime"=hex(b):704ac9ebcc6dc701
"LastBackupLocation"="\\\\?\\Volume{2f147a6d-d29b-11db-8792-00188b27e7f8}"
"LastBackupDrive"="E:"
"LastSuccessfulBackupTime"=hex(b):704ac9ebcc6dc701
"LastSuccessfulBackupLocation"="\\\\?\\Volume{2f147a6d-d29b-11db-8792-00188b27e7f8}"
"LastSuccessfulBackupDrive"="E:"
Interesting eh? We can see a few values that should be easily recognizable and one that at first threw me off a bit. The LastBackupTime and LastSuccessfulBackupTime values are a little large for 32bit hex values aren't they? I had to do a little searching on this one because it's listed as a REG_QWORD rather than REG_DWORD. Well, QWORD is a 64 bit value in little endian. As evidenced by Dcode You can correlate the time stamps between the image above and the decoded hex datetime stamp
Now, if you look back to the first image you'll see that the image was created on my E: drive. Obviously the registry values I'm showing keeps track of the Volume Information GUID as well as the logical drive letter. Now you have a volume GUID to match up when you start looking for missing disks from a system you are investigating.
After looking at this I decided to try to write a perl script using the Parse-Win32Registry module but have had some difficulty getting it to work. I keep getting this error while trying to use dumpreg.bat. If anyone knows of a fix to this or what the cause is, let me know please.
C:\Perl\site\bin>dumpreg.bat -r f:\vistareg\SOFTWARE Microsoft\Windows\CurrentVe
rsion
Invalid key node type at offset 0x38c8
38c8 a8 ff ff ff 6e 6b 20 10 3b 06 6d b8 fc 67 c7 01 ....nk .;.m..g..
38d8 00 00 00 00 20 00 00 00 b5 0c 00 00 00 00 00 00 .... ...........
38e8 b0 47 74 00 ff ff ff ff 00 00 00 00 ff ff ff ff .Gt.............
38f8 c0 ba 00 00 ff ff ff ff 8c 00 a0 00 00 00 00 00 ................
3908 00 00 00 00 00 00 00 00 6d 00 5c 00 07 00 00 00 ........m.\.....
at dumpreg.bat line 41
There are several other subkeys I'm looking at under this Key, including the ones created for automatic backup schedules.
Microsoft decided to change the backup program a bit in this latest OS release. They finally moved away from the old interface they stole from Seagate and Veritas.
As you can see below, we now get the flashy GUI that tells us some interesting information. We can see when I made a complete disk image and when I tried out the shadow copy backup.
After making these backups I thought, hey wait..this has got to exist in the Registry. Like everything else in Windows there is indeed a Registry entry for the new Windows backup system.
You can check it out on your own systems here:
HKLM\software\Microsoft\Windows\CurrentVersion\WindowsBackup
Underneath there I found a few subkeys, one of which is SystemImageBackup.
In here I found a series of values which I exported:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsBackup\SystemImageBackup]
"LastBackupResultHr"=dword:00000000
"LastBackupResultHrDetailed"=dword:00000000
"LastBackupTime"=hex(b):704ac9ebcc6dc701
"LastBackupLocation"="\\\\?\\Volume{2f147a6d-d29b-11db-8792-00188b27e7f8}"
"LastBackupDrive"="E:"
"LastSuccessfulBackupTime"=hex(b):704ac9ebcc6dc701
"LastSuccessfulBackupLocation"="\\\\?\\Volume{2f147a6d-d29b-11db-8792-00188b27e7f8}"
"LastSuccessfulBackupDrive"="E:"
Interesting eh? We can see a few values that should be easily recognizable and one that at first threw me off a bit. The LastBackupTime and LastSuccessfulBackupTime values are a little large for 32bit hex values aren't they? I had to do a little searching on this one because it's listed as a REG_QWORD rather than REG_DWORD. Well, QWORD is a 64 bit value in little endian. As evidenced by Dcode You can correlate the time stamps between the image above and the decoded hex datetime stamp
Now, if you look back to the first image you'll see that the image was created on my E: drive. Obviously the registry values I'm showing keeps track of the Volume Information GUID as well as the logical drive letter. Now you have a volume GUID to match up when you start looking for missing disks from a system you are investigating.
After looking at this I decided to try to write a perl script using the Parse-Win32Registry module but have had some difficulty getting it to work. I keep getting this error while trying to use dumpreg.bat. If anyone knows of a fix to this or what the cause is, let me know please.
C:\Perl\site\bin>dumpreg.bat -r f:\vistareg\SOFTWARE Microsoft\Windows\CurrentVe
rsion
Invalid key node type at offset 0x38c8
38c8 a8 ff ff ff 6e 6b 20 10 3b 06 6d b8 fc 67 c7 01 ....nk .;.m..g..
38d8 00 00 00 00 20 00 00 00 b5 0c 00 00 00 00 00 00 .... ...........
38e8 b0 47 74 00 ff ff ff ff 00 00 00 00 ff ff ff ff .Gt.............
38f8 c0 ba 00 00 ff ff ff ff 8c 00 a0 00 00 00 00 00 ................
3908 00 00 00 00 00 00 00 00 6d 00 5c 00 07 00 00 00 ........m.\.....
at dumpreg.bat line 41
There are several other subkeys I'm looking at under this Key, including the ones created for automatic backup schedules.
Subscribe to:
Posts (Atom)
