Go To an Online Directory and Submit Your Links

Do you have a web site that you wish to accomplish some promoting for on-line and however you do not know where to launch? If that may be your problem, you can now discontinue worrying and considered it half solved for now. You may be curious regarding what the answer to your problems is and that may be because you are now able to submit your product through directory link submit service.

This is a type of things where you'll have to pay a ertain fee to a web directory service that will inturn submit link for you so that people may have a way to go to your site. It could appear rather tricky but rest assured that its not. The process of doing that is very simple and the prices are very easy on the pocket. This is the perfect thing for those people who are not so keen on spending a lot of money for SEo and in spite of that desire to do it anyway. Again, it is very easy to obtain more traffic for your web site; you simply look for a web directory, submit your website and the rest is history. Well, not really but at least you have some for of on line marketing. Oh, there is also the matter of payment when you submit link to this web directory. IT was mentioned before that the fees are very reasonably priced.

There are a couple of choices that you will have to pick from if you submit link to web directories and the choice that you make will affect the purchase price that you will pay. See, if you simply submit your website and that's all you want, the cost you have to pay is lower. But if you choose to have your ink featured, well now, you might have to pay a higher price. Higher does not mean that you'll have to spend so much more just a little bit more than normal. Now, if you truly desire to make some impact on the internet site traffic that you are to get do not wait any longer and sign up with a web directory that offers reasonable prices.

Directory Link Submit - Web directory containing custom optimized categories. Try the Submit Link now!

Links

WRF Book Reviews
Thanks to everyone who's purchased a copy of Windows Registry Forensics, and in particular to those who've taken the opportunity to post their thoughts, or more formally write a review.  Paul Sanderson (@sandersonforens on Twitter), from across the pond, posted a review of the book to his blog recently.  Paul has the Kindle version of the book, as that's all that's available over there at the moment.

Speaking of the book, it seems to be doing well, if the Amazon ranking is any indicator.  There are a couple pretty helpful things to point out about this book that might be helpful in understanding why it might be useful for you.

First, this is the first book of it's kind.  Ever.

Seriously...there are no books out there that come at the topic from the perspective of a forensic analyst.  There are a number of books that include discussion of some Registry keys that are of use to an analyst, but none that discusses the Registry at the depth and breadth of WRF.  My primary motivation for writing the book was to fill that gap, because I really feel that the Registry is a critical and too-often-overlooked source of forensic artifacts on a system.

Second, the book makes use of primarily free and open-source tools.  This can be very important to smaller organizations, such as LE, professors and students at local community colleges, and even just to those learning or looking to develop new skills, as it puts the described capability within reach.  I know that not everyone can (or wants to) learn Perl, but the tools are there...and to make it even easier, many of the tools I've written have been provided as standalone EXEs (compiled with Perl2Exe).

SPoE
I was bopping around the TwitterVerse recently and ran across a link to Mike Murr's blog, and from there found a two year old post on the Single Piece of Evidence (SPoE) myth.  Mike's always been good for some well-thought-out opinions and comments, and this one is no different.  What he mentions with regards to anti-forensics techniques is similar to the reactions surrounding the release of XP and then Windows 7..."OMG!  What is this going to do to my investigations!"  The fact is that, while each brings it's own nuances and inherent anti-forensics, each also brings with it a whole bunch of new artifacts.  As Mike points out, when a user interacts with a Windows system, there are a lot of artifacts...and the same is true, albeit to a somewhat lesser degree, for malware, as well.

Hacking
If you've been watching the news lately, you're probably aware that no one seems to be immune to being compromised.  Even small boroughs in PA are susceptible.  While the linked article doesn't have a great deal of supporting information (no mention of the use of online banking, did the bank see a legit login from a different IP address, what the independent consultant determined, etc.).  In the past, a lot of these types of issues have been attributed to the Zeus bot, and in some cases, there haven't been any indications of Zeus on what were thought to be the affected systems.

Mayor Mowen was just being a mayor when he said, "You guard against it by increasing your firewall, which is what we are in the process of doing."

I bring this up, because there's traffic on Twitter recently with respect to the RSA conference, and the definition of "cyberwar", or more specifically, just "war".  I'd suggest that any action that forces your adversary to turn away for his main objective (attacking, etc.) and focus resource elsewhere, even if this tactic is used purely for an attrition effect, should be considered part of "war", declared or otherwise.

Analysis
F-Secure recently posted this analysis of an MBR infector.  The analysis includes a good number of hex views and listings of code in assembly language and lots of detail.  It would be a good idea to read through this carefully and take note of what's said.  For example, this baddy infects the MBR, and appears to make a copy (like Mebroot, here, and here) of the original MBR, placing it in sector 5.

The analysis includes the following:
Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.


I'm not entirely sure that this is a good line of reasoning in and of itself, in part because the bad guys have done a good job at shutting WFP off for a minute, and installing their malware.  WFP is not a polling service, so when it wakes back up, it has no way of knowing that a protected file was modified or replaced. However, it appears from the write-up that the malware infects userinit.exe at startup, possibly prior to WFP starting up, which may be the entire reason for infecting the MBR first.


I'm curious as to which version of Windows this malware was executed on, as the version of userinit.exe on my XP system, as well as a Windows XP VM I have, is 26Kb in size, slightly larger than what's shown in the write-up.  However, the write-up does provide a couple of good tips that an analyst can use to detect the presence of this malware.


If you're a responder or forensic analyst, and this one is tough for you to read and follow, keep something in mind that Cory posted to Twitter today (17 Feb), which included (in part), "...you shouldn't rely on malware fetishists for incident response advice."  Excellent point.

FakeAV
Another interesting analysis popped up...thanks to Ken for posting his analysis of a FakeAV bit of malware.  In his write-up, Ken does a pretty thorough job of documenting what he did, how he did it, and what he found.  For example, one of the Registry key that were modified is:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations

According to Ken, the "LowRiskFileTypes" value was added with the data ".exe".  This is interesting, but how does it apply to the malware infection.  MS KB article 883260 provides some hints to this.  This same KB article provides a hint about why the following key might also be updated:

HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments

In Ken's write-up, this key had the "SaveZoneInformation" value added, with "1" as the data.  Remember how back with Windows XP SP2, files downloaded via Outlook or IE had a "zoneid" Alternate Data Stream (ADS) attached to the file (this is described on pg. 314 of WFA 2/e)?  When analyzing a system with ADS on it, it's usually pretty easy to see them at a glance, as some of the commercial forensic analysis applications list them in red.  However, this setting appears to tell the system to not create the ADS.

Finally, Ken mentions that there was a change to the following key:

HKCU\Software\Microsoft\Internet Explorer\Download

In this case, the CheckExeSignatures value was changed from 'yes' to 'no'.  TechNet has some information about the value (maybe...the path is a little different,using "Main" in the key path, rather than "Download") and what effect it may have on the system. Other malware seems to modify the same set of keys, as seen here, and with this FakeAV write-up from Sophos.

There are a couple of interesting take-aways from this write-up, I think.  First of all, it's great that Ken took the time not only to run this analysis, but to share it with others.  I think one of the biggest mistakes analysts make when it comes to sharing and collaboration is assuming that everyone else has already seen everything.  I tried to shoot this one down at the WACCI conference last year, where I actually met Ken.  I don't see many FakeAV issues at all, to be honest.

Another take-away is that publicly available information provided by the vendor is utilized to take some steps towards not only allowing the malware to run, but also towards anti-forensics.  Think about it...by telling the system to not create the ADS for downloaded files, that removes one of the indicators that analysts could use to identify the malware's propagation mechanism.

Finally, this clearly demonstrates that there are steps analysts can use to detect malware on a system beyond running an AV scanner.  For example, there are number of Registry keys that Ken identified, as well as what's listed in other write-ups, that could be used to detect the potential presence of malware, even if the malware itself is not detected by AV.  The rather odd value in the user's Run key is something of a give-away, but RegRipper already has a plugin that dumps the contents of that key.  Now we have other keys that can be used with RegRipper or a forensic scanner to comb through the appropriate hives and check for the possible existence of malware.

IR
Last, but certainly not least, Chris posted today regarding IR activities; in particular, using a batch file to dump Registry hives from a live system for analysis.  Chris actually posted the batch file he used...take a look.  This one shows that Chris's command line kung fu is very good!

New Tools and Links

ProDiscover
Chris Brown has updated ProDiscover to version 6.8. This may not interest a lot of folks but if you haven't kept up with PD, you should consider taking a look.

If you go to the Resource Center, you'll find a couple of things. First off, there's a whitepaper that demonstrates how to use ProDiscover to access Volume Shadow Copies on live remote systems. There's also a webinar available that demonstrates this. Further down the page, ProDiscover Basic Edition (BE) v 6.8 is available for download...BE now incorporates the Registry, EventLog and Internet History viewers.

Chris also shared with me that PD v6.8 (not BE, of course) includes the following:

Added full support for Microsoft Bitlocker protected disks on Vista and Windows7. This means that users can add any bitlocker protected disk/image to a project and perform all investigative functions provided that they have the bitlocker recovery key.

The image compare feature in the last update is very cool for getting the diff's on volume shadow copies.

Added support for Linux Ext4 file system.

Added a Thumbs.db viewer.

These are just some of the capabilities he mentioned, and there are more updates to come in the future. Chris is really working hard to make ProDiscover a valuable resource.

MS Tool
Troy Larson reached to me the other day to let me know that MS had released the beta of their Attack Surface Analyzer tool. I did some looking around with respect to this tool, and while there are lot of 'retweets', there isn't much out there showing its use.

Okay, so here's what the tool does...you install the tool and run a baseline of the system. After you do something...install or update an app, for example...you rerun the tool. In both cases, .cab files are created, and you can then run a diff between the two of them. I see two immediate uses for something like this...first, analysts and forensic researchers can add this to their bag of tricks and see what happens on a system when an app is installed or updated, or when updates are installed. The second, which I don't really see happening, is that organizations can install this on their critical systems (after testing, of course) and create baselines of systems, which can be compared to another snapshot after an incident.

I'll admit, I haven't worked with this tool yet, so I don't know if it creates the .cab files in a specific location or the user can specify the location, or even what's covered in the snapshot, but something like this might end up being very useful. Troy says that this tool has "great potential for artifact hunters", and I agree.

CyberSpeak is back!
After a bit of an absence, Ovie is back with the CyberSpeak podcast, posting an interview with Mark Wade of the Harris Corporation. The two of them talked about an article that Mark had written for DFINews...the interview was apparently based on pt. 1 of the article, now there's a pt. 2. Mark's got some great information based on his research into the application prefetch files generated by Windows systems.

During the interview, Mark mentioned being able to use time-based analysis of the application prefetch files to learn something about the user and their actions. Two thoughts on this...unless the programs that were run are in a specific user's profile directory (and in some cases, even if they are...), you're going to have to do more analysis to tie the prefetch files to when a user was logged in...application prefetch files are indirect artifacts generated by the OS, and are not directly tied to a specific user.

The second thought is...timeline analysis! All you would need to do to perform the analysis Mark referred to is generate a nano-timeline using only the metadata from the application prefetch files themselves. Of course, you could build on that, using the file system metadata for those files, and the contents of the UserAssist subkeys (and possibly the RecentDocs key) to build a more complete picture of the user's activities.

Gettin' Local
A recent article in the Washington Post stated that Virginia has seen a rise in CP cases. I caught this on the radio, and decided to see if I could find the article. The article states that the increase is a result of the growth of the Internet and P2P sharing networks. I'm sure that along with this has been an increase in the "I didn't do it" claims, more commonly referred to as the "Trojan Defense".

There's a great deal of analysis that can be done quickly and thoroughly to obviate the "Trojan Defense", before it's ever actually raised. Analysts can look to Windows Forensic Analysis, Windows Registry Forensics, and the upcoming Digital Forensics with Open Source Tools for solutions on how to address this situation. One example is to create a timeline...one that shows the user logging into the system, launching the P2P application, and then from there add any available logs of file down- or up-loads, launching an image viewing application (and associated MRU list...), etc.

Another issue that needs to be addressed involves determining what artifacts "look like" when a user connects a smart phone to a laptop in order to copy or move image or video files (or uploads them directly from the phone), and then share them via a P2P network.

Free Stuff
Ken Pryor has posted his second article about doing "Digital Forensics on a (less than) shoestring budget" to the SANS Forensic blog. Ken's first post addressed training options, and his second post presents some of the tools described in the upcoming Digital Forensics with Open Source Tools book.

What I like about these posts is that by going the free, open-source, and/or low cost route for tools, we start getting analysts to understand that analysis is not about tools, it's about the process. I think that this is critically important, and it doesn't take much to understand why...just look around at all of the predictions for 2011, and see what they're saying about cybercrime being and continuing to become more sophisticated.

Links and stuff

Windows Registry Forensics
The folks at Syngress tweeted recently that Windows Registry Forensics is due to be published this month! It's listed here on Amazon, along with editorial reviews from Troy Larson and Rob Lee. I, for one, cannot wait! Seriously.

A word about the book...if you're interested in an ebook/Kindle version, or if you have trouble getting the contents of the DVD with your ebook purchase, please contact the publisher first. Once the book has been sent in for printing, I (and authors in general) have very little to do with the book beyond marketing it in ways that the publisher doesn't.

Rules
Jesse Kornblum posted his Four Rules for Investigators recently. I would say that it was refreshing to see this, but I've gotta say, I've been saying most of the same things for some time...I think the big exception has been #2, and not because I disagree, but as a consultant, I generally assume that that's already been addressed and handled.

Jesse's other rules remind me a great deal of some of the concepts I and others have been discussing:

Rule 1 - Have a plan...that kind of sounds like "what are the goals of your investigation and how do you plan to address it with the data you have?"

Rule 2 - Have permission...definitely. Make sure the contract is signed before you forensicate.

Rule 3 - Write down what you do...Documentation! Now, I know some folks have said that they don't keep case notes, as those would be discoverable, and they don't want the defense counsel using their speculation and musings against them. Well, I'd suggest that that's not what case notes are about, or for. Case notes let you return to a case 6 months or a year later and see what you did, and even why. They also let someone else pick up where you left off, in case you get sick, or hit by a bus. What I really don't like seeing is the folks who say that they spent hours researching something that was part of a case, but they didn't document it, so they can't remember it...they then have to re-do all of that research the next time they encounter that issue. Also, consider this...one person on a team conducts research that takes 10 hrs to complete. If they don't document and share the results of the research, then the other 9 people on the team are going to spend a total of 90 hrs doing that research themselves...when the original research could have been shared via email, or in a 1/2 hr brown bag training session.

Rule 4 - Work on a copy...Always! Never work on the original data. I've had instances where immediately after I finished making copies of the images, the original media (shipped by the customer) died. Seriously. Now, imagine where I'd've been had I not followed procedure and made the copies...my boss would've said, "...that's okay, because you made copies...right?" I'm generally one of those folks who follows procedure because it's the right thing to do, and I tend not to make arbitrary judgments as to when I will or won't follow the procedure.

Jesse isn't the only one saying these things. Take a look at Sniper Forensics: Part 1 over at the SpiderLabs Anterior blog. Chris has gotten a lot of mileage out of the Sniper Forensics presentations, and what his talks amount to include putting structure around what you do, and the KISS principle. That's "keep it simple, stupid", NOT listening to Love Gun while you forensicate (although I have done that myself from time to time).

Is it StuxNet, or is it APT?
I found this DarkReading article about targeted attacks tweeted about over and over again. I do agree with the sentiment of the article, particularly as the days of joyriding on the Information Superhighway are over with, my friends. No one is really deploying SubSeven any longer, just to mess with someone and open and close their CD-Rom tray. There's an economic driver behind what's going on, and as such, steps are being taken to minimize the impact of unauthorized presence on compromised systems. One thing's for sure...it appears that these skilled, targeted attacks are going to continue to be something that we see in the news.

USB Issues and Timelines
Okay, this isn't about the USB issues you might be thinking of...instead, it's about a question I get now and again, which is, why do all of the subkeys beneath the USBStor key in the System hive all have the same LastWrite time? While I have noticed this, it hasn't been something that's pertinent to my exam, so I really haven't pursued it. I have seen where others have said that they've looked into it and found that the LastWrite time corresponded with an update.

Rather than speculating as to the cause, I thought what I'd do is recommend that folks who see this create a timeline. Use the file system metadata, LastWrite times from the keys in the System and Software hives, and Event Log data, to start. This should give you enough granularity to begin your investigation. I'd also think about adding Prefetch file metadata (if you have any Prefetch files...), as well as data from the Task Scheduler log (that is, if it says anything besides the Task Scheduler service starting...).

Links and Updates

It's been a while since I posted a list of links and resources from across the Internet. I thought that since things have been quiet toward the end of 2010, I'd post some of the things I'd run across and found interesting...so, here goes...

GSD
Looks like Claus is back with an interesting update to his site. Claus hasn't been updating his site as much as he had done in the past, but it is always good to see is posts. A lot of what Claus posts that is oriented toward forensics is from an admin's perspective, which is great for a guy like me...I'm not an admin (nor do I play one on TV), so I often find that it's good to get a reminder of the admin's perspective. Besides, Claus always seems to be able to find the really good stuff...

One of the interesting things I found in Claus's post was the mention of a new mounting tool, OSFMount, for mounting images. I find it useful to be able to do this, and have been using FTK Imager 3.0. Claus also mentions in his post that ImDisk was updated recently...like OSFMount, it comes with a 64-bit version, in addition to the 32-bit version.

So, what does this tell us about image mounting tools? There are several other free and for-pay tools, some of varying quality, and others with vastly greater capabilities. So why does it seem that there's an increase in the number of tools that you can use to mount images? After all, you can use LiveView to convert a raw dd image to a vmdk and open it in VMPlayer, or you can use vhdtool to convert a raw dd image to a vhd and open it in MS's Virtual PC, which is freely available.

eEvidence
I watched for a long time and didn't see any updates for a while...while I wasn't watching, Christine updated the e-Evidence.info site with a lot of great reading material back in November. This site has always been a great source for information.

VSS
Based on a link from the e-Evidence site, I did some reading about mounting images, and accessing and recovering data from Volume Shadow Copies. The first resource I looked at was from QCCIS.com; the whitepaper provides an explanation of what the Volume Shadow Service does, and provides a simple example (albeit without a great deal of exacting detail) of mounting and extracting data from shadow copies. This is a good way to get started, and I've started looking at ways to implement this...so far, I've used Windows 7 Professional 64-bit as a base system, mounted an image (with FTK Imager 3.0) that includes a Vista 32-bit volume, and not been able to access the shadow copies. I'll be trying some different things to see if I can mount images/volumes in order to access the Volume Shadow Copies.

Malicious Streams
This site isn't strictly Windows-oriented...in fact, it's decidedly focused on MacOSX. However, Malicious-streams.com contains information about PDF malware, a bit of code geared toward Windows systems, and some good overall reading. Also, the author is working on a version of autoruns for MacOSX and I hope that this gets released as a full version early this year, as it would be a great way to start things off in 2011.

Resources
Derek Newton's list of Forensic Tools
Open Source Digital Forensics Site
LNK Parser written in Python

Links, Thoughts...

What's good and what's been going on lately in the world of Windows IR/DF? I think maybe things are slowing down around the holidays, as it seems that many of us who are blogging are simply sharing the same links that everyone else is blogging...kind of circular, and when you poke your head up, you realize that you've been reading the same half dozen stories for the past week.

Maybe there really isn't a whole lot going on at the moment...maybe adding something a little bit different, perhaps a different angle, will change things up just a bit.

Books
Many of you know that I've had a couple of books published, and number 5...Windows Registry Forensics...will be out shortly. WFA 2/e has been pretty successful so far, and a number of folks have sort of off-handedly asked me about a third edition. To be honest, this is something that's up to the publisher...WFA 2/e may be successful enough for a third edition, or the publisher may decide that the title and subject have run their course....who knows?

However, the question itself got me thinking along a different road...that is, what does it take to write a book? In exploring material for a third edition, I took an opportunity to ask some folks what they thought should be included in that edition, only to get some very interesting responses. Those responses then got me to thinking, "here's someone who does a lot of work...why doesn't he write a book?" I then thought, what is it that's holding folks back? There are a number of folks out there who likely have the necessary background to write a book...I mean, based on some of the books that have been written over the years, a solid background in ediscovery or digital forensic analysis should be enough to write a solid book, right?

If you're looking for a particular topic, my publisher has a page up called "Write for Syngress" for those who may be thinking about writing a book, or just tossing the idea around.

I think that a lot of folks look for someone to write a book for them, without ever thinking that maybe they could write that book themselves. Time is always a factor, but based on my experience, there are a number of decisions that need to be made, and sometimes thinking through those things can actually get you over that hump.

As such, what I'm going to be doing over time is writing a series of blog posts about writing books. I'm going to offer up my thoughts and experiences, and hope that someone out there decides to put pen to paper (figuratively, or literally) and step out and just do it. Yes, writing a book is time consuming and it can be arduous, but it can also be very rewarding.

Prefetch Files
Mark Wade recently had an article published in the DFI News regarding Prefetch file analysis. The article is a good resource for those not familiar with Prefetch files and how they might be used. I do, however, have a question about one statement made in the article:

For instance if the Standard Information Attribute (SIA) and File Name Attribute (FNA) timestamps are modified in the Master File Table (MFT) to impede analysis...

In light of what's available in Brian Carrier's File System Forensic Analysis book, I'm a bit unclear as to how FNA timestamps would be purposely modified. Does anyone have any input on that? Is anyone seeing FNA timestamps being purposely and maliciously modified in the same manner as SIA timestamps?

That question aside, I think that Mark makes a number of excellent points and observations in his article, particularly that data embedded within the Prefetch files can be used to determine a number of interesting artifacts, such as errant removable storage devices or paths, "abnormal" or deleted user accounts, etc.

Imaging Systems
Lance recently posted a "hard drive imaging process tree for basic training"; keeping in mind that it's for basic training, it's an excellent resource to look to and use.

There are a couple of things that you should consider adding if you're planning to use this decision tree for your own training purposes. For example, the first comment talks about adding chain of custody documentation...this is something that should definitely be done. Several other comments refer to collecting volatile memory...while Lance's responses are that this is covered in other modules, I tend to agree with Rob and Andrew...this is something that needs to be included at the basic level; we can no longer leave this to the advanced level.

The thing I am glad to see at the end of the entire process is "Verify Image". I can't say that it's happened too many times, but I do know of analysts who have gone on-site, acquired images, documented everything, and not verified their images. When they got back to the lab, they found that for some reason, they did not have valid images. This must be part of the process.

Great job, Lance, on producing an excellent resource! Thanks!

Oh, hey, almost forgot...thanks for updating the post to include volatile data collection!

Memory Analysis
Gl33da's got a new blog post up, this one on identifying memory images. If you do memory analysis, but don't actually perform the memory acquisition, this is an excellent post that's chock full of great information, in that she not only points out a method for determining the version of Windows of a memory image, but points out that it's already been incorporated into Volatility 1.4. Shoutz to gl33da for sharing!

If you are performing memory acquisition, are you using windd? Or are you using the MoonSols Windows Memory Toolkit Community Edition?

Addendum: Russ McRee pointed me to an article he wrote for InfoSecInstitute, titled "Security Incident Response Testing To Meet Audit Requirements". The article focuses primarily on the PCI DSS v2.0, specifically para. 12.9, which mandates the requirement for an IR capability, in addition to providing specifications. Overall, I think that the article is very good, and includes a good deal of the things I would do or recommend when writing or evaluating an IR plan.

The only real issue I have with Russ's article...and this comes from being QSA certified and on a QIRA team for far too long...is that the majority of organizations that I investigated had enough trouble just getting something down on paper, let alone a coherent IR plan. The likelihood of a comprehensive plan that was tested, and an IR team that is trained and drilled on a regular basis was slim to none. Now, this isn't all organizations obviously...this is simply based on my experience and the responses I performed.

I will say that Russ does have some very interesting information in the article that will no only benefit responders, but forensic analysts, as well as those who provided training to responders and analysts. Thanks, Russ, for pointing me to the article.