forensik komputer

bila anda adalah pengguna windows yang sering disibukkan oleh virus, sebaiknya anda menambah wawasan dan pengetahuan terhadap respon apa yang harus dilakukan terhadap Pc yang terinveksi virus dan dampak kerusakannya.
http://windowsir.blogspot.com clic disini

Links and Stuff

VMWare Tip
Jimmy Weg shared a tip over on the Win4n6 group that may be useful to others.  Jimmy pointed out that on a sidebar on pg. 102 of Windows Registry Forensics, I mention trying several times to interrupt the VMWare boot process so that I can access the BIOS.  Jimmy suggests making this a bit easier by adding bios.bootDelay="4000" to the settings.ini file in order to create a 4 second delay.

MarkG added a suggestion for using the VMWare host menu to select Power on to BIOS rather than simply booting the VM.

Thanks to both Jimmy and Mark...these tips may be very helpful to someone performing research, or attempting to use the techniques described near pg. 102 in WRF.

Sniper Forensics
Chris has posted another installment of his Sniper Forensics series over on the SpiderLabs Anterior blog.  This one is called Part IV: Finding Evil.

Chris and I worked together on the IBM team a while ago.  Chris moved on to TrustWave, and before I left IBM, the team submitted a letter to Visa and dropped off of the PCI QIRA list.  So, while I worked PCI response engagements for about 3 yrs (which included the associated certification and annual re-certification), I haven't worked these engagements in a while, and Chris and his team continue to work them on a pretty regular basis.  As such, there's a good deal that Chris and his team sees on a regular basis that I no longer see.

In this installment of the Sniper Forensics series, Chris discussed looking at systems which were part of a payment processing system; however, it appears that while the systems processed card holder data (CHD), they were apparently known (or thought) to NOT have been breached when Chris was called in to "investigate".  As Chris said in his post, we all tend to get analysis engagements like this..."I think this system may have malware or may have been breached, but I'm not sure".  In many cases, there are no definitive facts to point at, like a pop-up on the Desktop, AV detecting something, etc., and as such, it behooves us to have a thorough, documented process for addressing these types of engagements.

In short, the process used in this engagement appeared to be to acquire the necessary data (memory, volatile data, images, logs) based on scoping, and then perform analysis based on this data.  Rightly so, Chris draws on his past experience, as well as the customer specifications ("2.  What are you hoping that I don't find?") to determine what to look for in memory (as well as on the disk), which appears to have consisted of four specific types or artifacts of processes, and the checks are based on known items that the team had seen on previous engagements (process name variations, etc.).

Chris also described examining his timeline, going back 6 months to look at file "birth" dates ("B" in the "MACB" timeline listing) on files.  In his post, Chris didn't mention where the 6 month time frame originated, but he does say that the installation date for the system was in 2009.

One thing I wasn't clear on is this statement...

Searching the timeline also helped me to identify potential dump files.  I know most modern RAM dumpers obfuscate the output files by either using some basic encryption or even just encoding (like with an XOR).  It doesn't have to be fancy – just put the stolen data in some format that a regex won't identify.

I think it would be interesting to know (if it's not TrustWave company proprietary IP...) how someone would go about searching their timeline for files that Chris describes in that statement.  I think it's great that company's such as TrustWave are sharing information in the manner that they are, and my hope would be that, in cases such as this, that sharing would go just a bit further.

Some thoughts...
Reading through the post, it's clear that the scope was rather limited...and to be honest, this is often the case, as the customer will many times limit the scope.  This seems to have been the case here, as one of the scoping questions appears to have been, "2.  What are you hoping that I don't find?"  However, limiting the analysis in this manner can potentially be very dangerous, as the analyst may miss things that are different from those specifications.