Where Is the Digital Forensics Threat Report

Monday, August 22, 2011 Posted by Corey Harrell
Every year brings a new round of reports outlining the current trends. Information security threats, data breaches, and even cyber crime are covered in the reports. The one commonality across every report is they are lacking the digital forensic perspective. The reports address the question of what are the current threats potentially affecting your information and systems. However, the DFIR point of view asks the follow-up questions: how would you investigate a current threat that materialized on your systems and what would the potential artifacts look like? If a DF Threat Report existed then I think those two questions would be answered.

What The DF Threat Report Could Contain?

I’d like to see the report use case examples to illustrate a specific threat on a system. I find it easier to understand an investigative method and potential artifacts by following along an examination from start to finish. A simple way to demonstrate the threats would be to just replicate it on a test system. The use of test systems would enable the threat to be discussed in detail without revealing any specific case details. The current trend reports would just be guides highlighting what threats to focus on.

To see what I’m talking about I’ll walk through the process of how threats can be identifed for the DF Threat Report. The threats can then be simulated against test systems in order to answer the questions I'm bringing up. In the past two weeks I read the Sophos Security Threat Report Mid-Year 2011 and Securelist Exploit Kits Attack Vector – Mid-year Update reports. I’m using both reports since they are fresh in my mind but the areas I’m highlighting as lacking are common to most threat reports I’ve read (I’m not trying to single out these two organizations).

Example DF Threat Report Topics

The Sophos Security Threat Report Mid-year 2011 talked about the different ways malware is distributed. The threats covered included web threats, social networking, and email SPAM / spearphishing. The Securelist Exploit Kits Attack Vector Mid-year Update discussed the popular exploit kits in use and what vulnerabilities are targeted by the two new kits in the list (Blackhole and Incognito). There are threats in both reports that merit further discussion and would fit nicely in a DF Threat Report.

Sophos stated they “saw an average of 19,000 new malicious URLs every day” with more than 80% of the URLs belonging to legitimate companies whose websites were hacked. The report provided some statics on the URLs before moving on to the next threat. The DF Threat report could take two different angles in explaining the web threat; the server or client angle. If the phone rang at your company and the person on the other end said your website was serving up malware then how would you investigate that? What are the potential artifacts to indicate if malware is actually present? How would you determine the attack vector used to compromise the website? Now for the client angle, a customer comes up to you saying there is a rogue program holding their computer hostage. What approach would you use to identify the initial infection vector? What are the potential artifacts on the system to indicate the malware came from a compromised website as opposed to an email? These are valid follow-up questions that should be included in the web threat’s explanation.

The next threat in the Sophos report was Blackhat search engine optimization (SEO). SEO is a marketing technique to draw visitors to companies’ websites but the same technique can be used to lure people to malicious websites. “Attackers use SEO poisoning techniques to rank their sites highly in search engine results and to redirect users to malicious sites”. As expected the report doesn’t identify what the potential artifacts are on a system to indicate SEO poisoning. I could guess what the system would look like based on my write-up on the potential artifacts from Google image search poisoning. However, answering the question by examining a test system is a better option than making an assumption.

Another threat in the Sophos report was the ongoing attacks occurring in Facebook, Twitter, and Linkdin. “Scams on Facebook include cross-site scripting, clickjacking, survey scams and identity theft”. On Twitter attackers are using shortened URLs to redirect people to malicious websites. LinkedIn malicious invitation reminders contain links to redirect people to malicious websites. Again, the investigative method and artifacts on a system were missing. The same question applies to this threat as well. What are the potential artifacts on a system to indicate Blackhat SEO?

Rounding out the Sophos threats I’m discussing is SPAM /spearphishing. A few of the high profile breaches this year were covered and a few of them involved spearphishing attacks. Unfortunately, there was no mention explaining the artifacts tying malware to a specific email containing an exploit. Nor was there a mention of how your investigation method should differ if there is even a possibility spearphishing was involved.

The Securelist Exploit Kits Attack Vector Mid-year Update report identified the top exploit kits used in the first half of the year. One interesting aspect in the report was the comparison between the vulnerabilities targeted by the Blackhole and Incognito exploit kits. The comparison showed the kits pretty much target the same vulnerabilities. The DF Threat Report may not be able to cover all the vulnerabilities in the list but it could dissect one or two of them to identify the potential artifacts left on a system from exploitation.

Conclusion

The process I walked through to identify content for the DF Threat Report used reports related to security threats. However, a DF Threat report could cover various topics ranging from security to cybercrime. The report’s sole purpose would be to make people more aware about how to investigate a threat that materialized on your systems and what might the potential artifacts look like? In my short time researching and documenting attack vector artifacts I’ve found the information valuable when examining a system. I’m more aware about what certain attacks look like on a system and this helps me determine the attack vector used (and not used). I think the DF Threat Report could have a similar effect on the people who read it.

It would take an effort to get an annual/semi-annual DF Threat report released. People would be needed to organize its creation, research/test/document threats, edit the report, and to release the report. I wouldn’t only be an occasional author to research/test/document threats but I’d be a reader eager to see the DF Threat Report with each new year. Maybe this is just wishful thinking on my part that one day when reading a report outlining the year’s trends there will actually be useful DFIR information that could be used when investigating a system.
Labels:
  1. Corey,

    In your mind, who would compile such a report?

    As you've demonstrated in your blog, it's not hard to set up a system, run an exploit against it and then post the results of a forensic examination. However, the question would be, who (which company) is doing enough to identify trends in their examinations, and would be willing to share that information?

    When I was on the IBM ISS team, we couldn't get most analysts to post their reports to a share on a server, let alone share their findings.

    It may be cynical of me, but I don't think folks out there are going to do something like this, as in a lot of ways, I think that they believe that it would expose them to too much risk.

  2. To compile the report wouldn't necessary require an organization. I was thinking along the lines to use the trend reports being put out by the various security companies such as Sophos, Symantec, Mandiant, etc.. Their reports already identify trends so all that would be needed is for the trend to be replicated on a test system for documentation. For example, with the Facebook attacks one would just need to find an active attack and then infect a test system to document the artifacts. This wouldn't release any actual case data since it is a testing environment. The person could share their perspective on how they would approach the investigation.

    I don't think an organization who is identifying trends would necessary be required to compile the report since trends reports from other sources would be used. It could be done by one person with others to help write the content.

    I agree with you that most folks won't discuss a case in such detail. This is why I thought using test systems and trends identified by other security organizations could help avoid that. The one thing I found out is it takes a lot of time and testing to document the artifacts from an exploit or simulated attack. I'm not sure how many people would be willing to give up so much time to writeup an article.

  3. I'm sure that with the right infrastructure, something like this could be made easier to complete. For example, look at the process of what is done to identify exploit artifacts:

    - Snapshot the file system and Registry

    - Run exploit

    - Create a second snapshot; 'diff' to identify what should be searched for in a timeline

    I'm thinking that this could be automated to a degree, in much the same way malware analysis is sandboxed.

  4. Mandiant has their M-Trends and "State of the Hack" that provide current DFIR trends, including case studies. Also, the Verizon DBIR report has high-level stats on the breaches they investigate. What are you looking for in a DF "threat report" beyond what they do?

  5. Alex,

    I think what Corey is looking for is not the trends in the exploits being used, but what the most-popularly-employed exploits "look like" on a system, with respect to exploit artifacts.

    One example might be that one of the reports you mentioned would suggest that SQL Injection is widely used, but that doesn't really help analysts that aren't familiar with SQL Injection attacks. Following with what Corey is asking about, a DF "threat report" (perhaps "artifact report" is a better term) would illustrate what the artifacts of a SQL Injection attack look like.

    HTH

  6. I read both reports produced by Mandiant and Verizon. However, a DF Threat report would provide more information that would be useful in examinaing a system.

    I'd like to see a reference to an investigation methodology to use. Take the example of a compromised web server distributing malware. The report should mention some of the initial steps to perform when examining this kind of security incident. If the Sophos numbers are correct 19,000 malicious URLs is alot. I wonder how many people are aware of the investigation method to locate and resolve the issue.

    The second thing I'd like to see in the report are the potential artifacts indicating the threat/breach type. Knowing the potential artifacts can help you better understand the activity on the system. Take the VBIR report and their mention of the attack paths on pg 36 in the 2011 Data Breach report. The attack paths laid out include remote access services, backdoor, web application, or file sharing. If I'm doing an examination and determine the timeframe I'm interested is X. Then I proceed to examine the activity that occured around X. How do I know which attack path was used? If I was aware about the potential artifacts such as certain programs executing, files being created in certain directories, certain event logs, etc then it would be easier for me to identify the attack path. It would also be easier for me to rule out certain attack paths.

    I guess I'm looking more for a report targeted at the digital forensic practioner. To make us more aware of how the threats/breaches/cyber crime trends look like from the data we are seeing during an examination.

  7. Harlan,

    That's an interesting idea to automate it. I basically use the same process to locate exploit artifacts as I do to locate remnants of certain attacks. Do you think it could be done on a smaller scale if you don't have the infrastructure?

  8. Do you think it could be done on a smaller scale if you don't have the infrastructure?

    You've already done it, apparently.

    Here's what I would do...with an image, the in-take process would be to run mmls/fls (as approp.), then mount the volume and extract relevant data. Pretty easy...at least, as I'm building my forensic scanner, it seems pretty easy to me...

Post a Comment