It is also logical to conclude that their activities generated system and network-based artifacts that outlined their activity, even if that activity mimicked normal and authorized operational activity. Understanding these system and network-based artifacts is an important step to preventing and detecting attempts to infiltrate a network.
Now, I added my own emphasis to the above quote, but Don makes an excellent point. When an intruder interacts with your infrastructure, there's going to be digital material exchanged between their system, and the nodes on your infrastructure with which they're interacting. Also, the intruder is going to leave digital detritus on your infrastructure...in some cases, it may be extremely transient or volatile, and in other cases it may look very similar to legitimate traffic or activity. However, Don's point is extremely well-taken...you need to understand these artifacts so that you can
IntoTheBoxes
Speaking of Don, he recently tweeted that he's interested in bringing the ITB back. When Don was producing this (two issues), it was a very good e-zine, as articles were contributed by folks from the DFIR field. It's one thing to have a list of links with no commentary or insight, but it's completely different...and I think, highly beneficial...to have something contributed by folks from the field who are not only doing the work, but doing some of the primary research, as well.
If you'd like to contribute to the ITB, take a look at the ITB WordPress site, maybe take a look at the previous editions, and contact Don at @cutaway on Twitter.
Artifacts and Presentations
While we're on the topic of artifacts...I've attended several conferences over the years that include presentation titles that refer to network or system artifacts for various incidents (intrusions, APT, etc.). As of yet, I have yet to see a single presentation that actually gives those artifacts. I attended a presentation not long ago, the title of which referred to intrusion artifacts found in the Windows Registry; however, the presentation including nothing more than a bunch of "look here..." references, with no real explanations as to why an analyst would look at those keys or values. Several of the referenced Registry keys or values were dependent upon the intruder having shell-based access to your systems, such as via RDP or VNC (yes, this does happen), but that isn't something that was really discussed during the presentation.
In general, the artifacts left during an intrusion are heavily dependent upon how the intrusion occurred. For example, I have seen incidents where an employee's home system was compromised, and their remote access (RDP) credentials "stolen" via a keylogger. The intruder logged in via RDP, activated a dormant domain admin account, and began hopping to systems across the enterprise. We were able to track the activity via Registry analysis...the Remote Desktop client on Windows XP maintains an MRU list of systems connected to in the Registry (on Windows 7, the MRU is in the Jump Lists).
Now, if the intruder is able to gain access to a system on your infrastructure (via an infected document in an email attachment, or a link to a malicious site in an email), and ultimately gain access to the system and run commands via the command line, most normal systems may have very limited capability (i.e., lack of sufficient Event Logging, etc.) for detecting this sort of activity. In these cases, you'd likely be looking for secondary or indirect artifacts (this term is discussed in chapter 1 of Windows Forensic Analysis 3/e).
GSR
As most folks on Twitter are aware, the TrustWave Global Security Report is out...and just looking at page 6, it's a very interesting read. Page 6 addresses the issue of detection, and states that 84% of the organizations included in the report relied (or depended) on external third party reporting in order to identify compromises to their infrastructure. That number is actually up slightly from the previous year...the report speculates that this maybe a resource issue...I would also consider that it may include a lack of understanding of threats.
Further, from reading through the information presented in the report, I can see a huge opportunity for IOCs. For example, simply looking at the packers used (pg 17), it should be easy to create a series of indicators that folks can look for with respect to these artifacts. The same is true with respect to the Aggregation section of the report (pg 9)...there is some pretty significant potential for IOCs in just that one paragraph.
Thoughts on Report Stats and Revelations
Following right along with the TrustWave GSR report, I ran across Wendy's blog post (via Twitter and LinkedIn) that shines some light on some of the realities behind these reports. When reading these reports, we need to keep in mind who the customers of the organization are...the TrustWave guys do a LOT of PCI forensic work, and some of that is done for smaller organizations. Wendy makes it clear in her post what some of the folks who get compromised are thinking and why they don't appear to have any idea of how to do security.
Another area that isn't covered as much in Wendy's post are the larger infrastructures that get compromised...those that may not have security that's much better than a mom-and-pop shop, simply because they are so big. In such organizations, change is most often glacial, and can be mired down by cultural and political issues within the infrastructure. A misconception about a lot of large organizations, including the federal government, is that they have the resources to throw at the information security problem...this simply isn't the case. Years ago, I supported a federal agency that had two DF analysts for the entire (global) organization.
Okay...but so what? Like Wendy said, don't let the statistics bother you, particularly if you're a security pro, because getting upset about it isn't going to change anything. As long as people are looking for the easiest way to achieve a "good enough" solution, there's going to be someone right there to take advantage of that, regardless of the technology used.
Case Studies
As I've worked to develop my writing style (for my books) over the years, one of the things that I've noticed is that folks in this community love case studies. I've also noticed that as much as folks ask for case studies, very few are willing to offer up case studies of their own. One of the forums recently had a discussion thread that involved posted case studies, and the forum admin started a different thread to gauge the interest in such things. Unfortunately, that thread didn't really go anywhere.
I'd like to encourage DFIR folks to consider either sharing case studies, or sharing and engaging in discussion regarding what they'd like to see. I know that some folks can't share their actual case findings (even if customer references are redacted or simply not mentioned) due to the nature of where they work...sadly, many can't even state where their primary source of evidence was found. However, for those who can't share those things, one of the things you may be able to share is requests such as, "...where would I look for...", or "...on Windows 7, what data sources would I look to in order to determine...".
Another example of sharing can be seen at Corey's blog...many of Corey's posts regarding exploit artifacts are very detailed, but are not specific to a case; rather, he's posted information about his research, which in turn is highly beneficial.
Tools
USB Write Protect is a nifty little GUI utility you can use to enable write protection on USB devices on your Windows systems. Even though this is software-based write-protection and should not replace a hardware write-blocker, having the ability to
Speaking of USB devices, check out Mark Woan's USBDeviceForensics utility. You can use this utility to import or point to the Software, System, and NTUSER.DAT Registry hives (found in mounted images, or extracted from an acquired image), collect a lot of the information available in Rob Lee's USB Analysis profiles, and even some additional information not specifically listed in the profiles.
David Hull posted recently regarding innovative approach to "finding evil"; using several tools and a bash script, he hashes what's found via AutoRuns and submits the hashes to VirusTotal. What I like about this is that David has clearly identified/defined the issue he was facing, and then developed an innovative solution to the issue. Many times I've talked to analysts who talk about "doing Registry analysis" without any clear understanding of what they're looking for, and not know if what they're looking for is even in the Registry. David has clearly decided that he wants to use automation to achieve a modicum of data reduction...of all of the data he has access to, his approach is, "just show me the bad stuff."
For anyone who's been watching, Corey's posted quite a bit on ripping VSCs, providing a lot of great information about not just what artifacts are available on a system, but what you can find in the VSCs on a Vista+ system, and how to get at those artifacts. Corey's taken a big step forward with this, tying free and open source tools together via batch files to make this data collection much more automated, and now Jason's thrown his hat in the ring by creating the VSC Toolset, a GUI interface for these tools. This is all very cool stuff and provides a capability that isn't necessarily available via some of the commercial products.
There was an excellent post from Christiaan Beek recently regarding using Volatility to analyze a hibernation file...check it out. Christiaan gives a step-by-step walk-through on how to analyze a hibernation file...something that should be strongly considered (and a skill that should be developed), particularly when the situation and goals of your exam warrant it.
This is a little off-topic, but if you're analyzing Android phones, you might want to check out Open Source Android Forensics. This is a bit more of an open source link than it is a Windows forensics link, but consider it in the context of DFwOST.
No comments:
Post a Comment