Showing posts with label forensic. Show all posts
Showing posts with label forensic. Show all posts
Wednesday, December 15, 2010
Thursday, October 7, 2010
determining and Mounting LUKS based encrypted disk images
Article on how to determine whether a disk image is LUKS based and if it is how to deal with it. It also covers LVM as well.
It does NOT cover brute forcing the password.
Wednesday, September 29, 2010
eEye Digital Security zero day tracker
eEye Digital Security have a Zero-Day tracker page to catalogue the latest zero-day exploits and vulnerabilities.
Link to zero day tracker here
Link to zero day tracker here
Labels:
forensic,
incident response,
vulnerability
Thursday, September 23, 2010
Really Really persistent cookies
Extremely persistent browser cookies:
evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.
Specifically, when creating a new cookie, it uses the following storage mechanisms when available:
- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Storing cookies in RGB values of auto-generated, force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in Web History (seriously. see FAQ)
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage
- HTML5 Database Storage via SQLite
And the arms race continues....
Labels:
forensic,
incident response,
privacy
Sunday, July 19, 2009
NetWitness Investigator
NetWitness
Seen this product before but everytime i play with it seems to have more and more. Would be a useful product to use for near real time analysis of network traffic. Don't think it has an ability to read traffic from the wire direct, certainly not in the free version. Could use something like DaemonLogger to provide continuous 50Mb pcap files for analysis.
Has as a nice interface that seems relatively intuitive to use.
Apparently PhoenixDatacom are the UK suppliers of it, so at least its easy to get a look at.
Labels:
forensic,
netwitness,
network
Saturday, July 18, 2009
USB Device Forensics
Taken from Windows Incident Response by Keydet89
I posted to the Win4n6 Yahoo Group on USB removable storage devices and tracking connections, and got some really good confirmation from Rob Lee, so I thought I'd share it here, as well.
So, when I was writing WFA 2/e, I did some testing and found that when connecting a USB removable storage device to a system, beneath the unique instance ID key (under the DeviceClasses key), a Control subkey was created, and when the device was disconnected, the Control subkey was deleted. The creation/deletion of this subkey constitutes a modification to the unique instance ID key, updating the key's LastWrite time and allowing us to track the usage of the device.
However, there appear to have been changes to this functionality since then, and Rob's more expansive testing has confirmed my own. Essentially, if you sit down to a running system (XP SP2 or 3, Vista, Windows 7), and plug in a USB removable storage device (even one that's been previously connected to that system), you'll see the Control subkey created...but when you disconnect the device, the Control subkey will remain until the system is rebooted. Rob has confirmed that this LastWrite time survives logins, as well.
So, now the LastWrite time on the unique instance key refers to the time that the device was last connected to the system, which is an important distinction to make when performing analysis of the usage of these devices. This requires further testing for more complete confirmation, but this is how things appear at this time. Shout outs to Rob Lee for the testing on this!
So this should give us a bit more on when and should look to automate it if possible

So, when I was writing WFA 2/e, I did some testing and found that when connecting a USB removable storage device to a system, beneath the unique instance ID key (under the DeviceClasses key), a Control subkey was created, and when the device was disconnected, the Control subkey was deleted. The creation/deletion of this subkey constitutes a modification to the unique instance ID key, updating the key's LastWrite time and allowing us to track the usage of the device.
However, there appear to have been changes to this functionality since then, and Rob's more expansive testing has confirmed my own. Essentially, if you sit down to a running system (XP SP2 or 3, Vista, Windows 7), and plug in a USB removable storage device (even one that's been previously connected to that system), you'll see the Control subkey created...but when you disconnect the device, the Control subkey will remain until the system is rebooted. Rob has confirmed that this LastWrite time survives logins, as well.
So, now the LastWrite time on the unique instance key refers to the time that the device was last connected to the system, which is an important distinction to make when performing analysis of the usage of these devices. This requires further testing for more complete confirmation, but this is how things appear at this time. Shout outs to Rob Lee for the testing on this!
So this should give us a bit more on when and should look to automate it if possible
Labels:
forensic,
incident response,
usb