Search This Blog

Thursday, June 6, 2013

(I) Calling for a "Malware Reporting Standard"

So what is a "Malware Reporting Standard"?  In short, a consistent way to report data and information about malware, usable by everyone, for use by any tool.  The bits of malware information that all of us Information Technology and Infosec professionals need to enter or import into our myriad of security solutions or scripts that we may use.

Why is this an issue?  Have you ever read virus descriptions from Sophos, Seculist/Kasperski, McAfee and others and tried to glean some data to enter into a security tool or search script?  Have you read the Mandiant APT1 report with the IOCs (MD5s) listed in the Appendix document, the Kasperski Red October report with the MD5s listed, or even the Kasperski WinNTI report which lacked any Indicators Of Compromise (IOC)?

So what do we need?  What we need is for all the vendors and malware researchers to provide and report data about malware in a concise format that makes it easy to identify and consume the valuable details littered throughout the above mentioned reports and virus descriptions.

For many security solutions, the following information is needed to create an analysis we use to detect any anomalies;

  • Filename
  • Path found
  • File extension
  • MD5/SHA1
  • Any Digital Signature info
  • Dates
  • Registry entries for Windozs systems 
A security professional does not necessarily need all the details to perform or setup an analysis.  The path or location the file was found and the extension of the file is fantastic information to setup an analysis for anything odd.  Look for anything in location \XYZ with the extension of .ABC that was found in the last 24 hours for example, and give me the SHA1 or MD5 of the file and maybe compare it to a file with the MD5 or SHA1 of the known bad IOCs (if necessary).  This is a better method as now automated scans can look for a few files and compare it to an IOC list (if necessary) versus checking every file on the system against the IOC MD5 list, which is growing daily and will soon, if not already be out of control and unusable.

I am well aware that there is unique malware tracked by Anti-Virus companies (no alert  triggered to the user)  that are purposefully kept secret.  Whatever reason they are not alerted to the end-user, legal, law enforcement and specific requests by customers not wanting any details of an identified malware released while investigations are ongoing.  We do not get to see these details that can help protect us, we are denied!  There is no reason AV companies cannot add certain minimum bits and still keep details secret.  AV companies can just add the following as a minimum to a monthly or quarterly report/list for the secret Shhh dont alert malware items;

  • Location/path malware was found
  • File extension of the malware
  • Anything else in the Malware Reporting Standard
As a part of implementing a “Malware Management Framework” (we recommend everyone start adopting), the review of malware reports, virus descriptions and any malware analysis details is a fundamental part of the “Malware ManagementFramework” process.  Look for the items mentioned above within the last 24 hours using a tool like IBM Endpoint Manager (formerly BigFix) or Tanium would allow you to detect even the “Shhh dont alert malware items” as suspicious or unknown files and to investigate.  If you used the "MalwareManagement Framework" approach, malware that dropped additional .OCX files in System32 would be obvious as there are only 5 or 6 .OCX files normally in C:\Windows\System32 as was seen in Gauss.  All you would need to know is to setup your analysis tools and/or scripts to look for this condition in the last 24 hours and alert you for example.

Far too often IOC's provided by many of the sources mentioned above, only provide information based on what is fed into their respective tool(s).  Mandiant's APT1 report with MD5 hashes to be fed into MIR, just as the JIB reports that Homeland Security/FBI/InfraGard provide.  I cant use this data in my malware detection tools.  Any and all malware researchers and vendors need to provide the industry more information!  I dont feel it is necessary to scan every file on a system to match how many MD5s?  It is not practical with 110 million pieces of new malware detected in 2012 and growing!  This is no longer a practical approach.  60 million already by May 2013, more than all of 2011!

The "Collective Intelligent Framework" (CIF) project is a step in the right direction, but we need to take the feeds and schema used by CIF, OpenIOC and others and standardize it.  A researcher or AV company can collect all or even parts of the bits of malware, but it must report it in a standardized manner.  Also provide the data in two formats, not just the XML to be consumed or imported by a tool, but also in CSV format like CIF supports.  Maybe each vendor can provide the same info in readable reports like we see with AV descriptions as well for easy consumption.  For AV companies, please add the data in your descriptions that match the "Malware Reporting Standard" in a consistent and obvious way to make it easy for us to consume and use. 

Aren’t we just letting the malefactr's, ne`er-do-wellers and malwarians know where and what we are looking for?  Absolutely!  If we can squeeze them into a smaller and smaller target, we win, they lose.  Malware authors will have to spend more time on their warez to avoid detection. This is a good thing if we can change their behavior and reduce hiding spots.

Something needs to change, something MUST change if we are to get ahead of malware and improve our investigation, detection and response capabilities.  Support the CIF schema as the start of a Malware Reporting Standard!

Read the CIF feed config and schema here:

We will support reporting any malware bits in the format discussed, so should you!