Tag Archives: OpenIOC

FireEye Endpoint Security (HX) – Supplementary Tools

Today I am going to write a few notes about tools that should be part of your toolkit in case you use FireEye Endpoint Security product a.k.a. as HX. If you don’t use FireEye HX, this post likely has no interest for you.

I tend to use HX when performing large scale Enterprise Forensics and Incident Response. I also tend to see HX or other EDR solutions on organizations with mature security operations that use such technology to increase endpoint visibility and improve their capabilities to detect and respond to threats on the endpoints. HX is very powerful,  feature rich but like many EDR products it tends to be designed for more seasoned incident responders with specialized skill set. HX can be used in the realm of protection, detection, and response. Today’s notes are primarily focused on two things: Increase awareness about tools that will help augment HX capability to detect attacks; Increase awareness about tools that will help the analyst ability to work with the results. Goal is to improve threat detection and ability to analyze the results therefore increase the effectiveness of your product and maximize the outcome of your investigations.

FireEye makes available a website named fireeye.market where one can download apps that extend the functionality of existing products. If you are a FireEye customer you likely have seen this before. For this post I’m looking at the Endpoint Security apps that might extend the functionality of the HX or enhance the analyst ability to perform the work faster/better.  On the FireEye Market website there are a few things that are freeware and can be downloaded without subscription. Others may require a subscription. One of the main freeware tools is the IOC Editor. Let’s briefly go over some of the things that will be useful.

Indicators of Compromise (IOC) Editor is a free tool for Windows that provides an interface for managing data and manipulating the logical structures of IOCs. IOCs are XML documents that help incident responders capture diverse information about threats, including attributes of malicious files, characteristics of registry changes, artifacts in memory, etc.  There are two versions of IOC editor in the website. We want the IOC 1.1 editor version 3.2. The installation file Mandiant IOCe.msi can be downloaded from here  https://fireeye.market/apps/211404 . The archive is IOCe-3.2.0-Signed.msi.zip (3EE56F400B4D8F7E53858359EDA9487C). This version brings updated IOC terms that allow us to create IOCs for HX real-time alerting and for searching the contents of the HX event buffer (ring buffer). Note that Redline does not support IOC 1.1. If you are a developer or interested in the details IOC 1.1 specification you can look here https://github.com/mandiant/OpenIOC_1.1. This schema is what Mandiant services uses internally to extend functionality of IOC Editor and support new and extended terms. The IOC editor contains two main set of terms: On one hand you have the terms that can be used to search for historical artefacts (Sweep) and on the other hand you have the terms that can be used to search event buffer (Real-Time) or generate real time alerts. All terms are created with a set of conditions and logic needed to describe and codify the forensic artefacts.

OpenIOC2HXIOC

When you use IOC editor to create, edit, maintain your Real-Time IOCs you need to upload them to HX either for testing or to be on released on production. One way to accomplish this is to use the Python script that takes IOCs as input and uploads them into HX to be used on Real Time alerting. This script can be downloaded from https://fireeye.market/apps/213060. You will need Python and a HX user account with API rights because the script takes advantage of the HX API to perform the work.

HXTOOL

HXTool, originally created by Henrik Olsson in 2016, is a web-based, opensource, standalone tool written in python. that can be used with HX. HXTool provides additional features not directly available in the product GUI by leveraging FireEye Endpoint Security’s rich API. Since the code now is open source, this tool is an excellent example of how you can develop applications utilizing the Endpoint Security REST API. It is available in FireEye’s public GitHub at https://github.com/fireeye/HXTool.

After installation, open a webbrowser and point it to localhost on port 8080. In the HXTool create a new profile with the IP address and port of the HX controller. Then connect with a user that has API Admin rights and was previously created in the HX management interface. There are many features in HX tool but the ability to use Script Builder to create audit scripts allows you fully leverage the potential of HX. After you create a script you run Sweeps using the bulk-acquisition method. The Sweeps can be used to perform enterprise forensics at scale or to look for real time data stored in the ring buffer of the endpoints. Nonetheless, you can use HXTool to perform stack analysis, enterprise searches based on OpenIOC 1.1, create, and maintain the Real-Time indicators, etc.

$ git clone https://github.com/fireeye/HXTool
Cloning into 'HXTool'...
remote: Enumerating objects: 6401, done.
remote: Counting objects: 100% (90/90), done.
remote: Compressing objects: 100% (70/70), done.
remote: Total 6401 (delta 39), reused 55 (delta 20), pack-reused 6311
Receiving objects: 100% (6401/6401), 14.64 MiB | 5.08 MiB/s, done.
Resolving deltas: 100% (4337/4337), done.  
$cd HXTool/   $ pip install -r requirements.txt --user
(..)
Installing collected packages: itsdangerous, MarkupSafe, Jinja2, click, Werkzeug, flask, pycryptodome, tinydb, six, python-dateutil, numpy, pytz, pandas Successfully installed Jinja2-2.11.2 MarkupSafe-1.1.1 Werkzeug-1.0.1 click-7.1.2 flask-1.1.2 itsdangerous-1.1.0 numpy-1.16.6 pandas-0.24.2 pycryptodome-3.9.7 python-dateutil-2.8.1 pytz-2020.1 six-1.15.0 tinydb-3.15.2    
$ python3 hxtool.py
(..)
[2020-06-02 01:39:41,497] {hxtool} {MainThread} INFO - Application starting
[2020-06-02 01:39:41,501] {hxtool} {MainThread} INFO - Application is running. Please point your browser to https://0.0.0.0:8080. Press Ctrl+C/Ctrl+Break to exit.  
* Serving Flask app "hxtool" (lazy loading)  
* Environment: production   
WARNING: This is a development server. Do not use it in a production deployment.    Use a production WSGI server instead.  
* Debug mode: off

Supplementary  IOCs

In the FireEye market website, there are a set of FireEye released Real-Time IOCs designed to supplement FireEye Endpoint Security’s production indicators. They were created for environment-specific detection and testing, like tests based on MITRE’s ATT&CK framework. Most of these IOCs will require substantial tuning to use in a production environment. They need to be customized for your environment and should not be uploaded in bulk. This set contains more than 400 IOCs and can be obtained from https://fireeye.market/apps/234563

FireEye Red Team IOCs.  Last December as result of an incident, FireEye released a set of IOCs to detect FireEye Red Team tools. These IOCs empower the community to detect these tools and are available in different formats including OpenIOC, Yara, Snort, and ClamAV. There are more than 80 IOCs in OpenIOC format and can be downloaded from https://github.com/fireeye/red_team_tool_countermeasures

The first set of IOCs are very broad and need to be customized for a particular environment but they offer a starting point for security teams to test and get familiar with the process. The lifecycle of designing, building, deploying, and adopting IOCs is part of the Security monitoring and/or Incident Response capability where well trained and well equipped personnel alongside with consistent and well defined process come into play. If you want to be able to run sophisticated threat hunting missions you first should be able to understand the threat, understand the indicators that help you identify the threat in your network and then you can create and maintain IOCs that may represent that threat. The second set of IOCs are overall very good but some of them need tunning specially the LOLBINs and the suspicious DLL executions.

GOAUDITPARSER

So, by now, with the things that were covered, you have a set of IOCs that you uploaded to HX using the OpenIOC2HXIOC script and you used the HXTool to Sweep your environment to look for threats or you used them to generate Real-Time alerts. But how to analyze the results? Traditionally you likely used the HX GUI or downloaded the data and used Redline. However, we can now use some other technique.  Daniel Pany just recently open sourced GoAuditParser. A versatile and customizable tool to help analysts work with FireEye Endpoint Security product (HX) to extract, parse and timeline XML audit data. People have used Redline to parse and create a timeline of the data acquired with HX but using this tool an analyst may be able to improve his ability to perform analysis on the data at scale obtained via HX. The compiled builds of the tool can be downloaded from https://github.com/fireeye/goauditparser/releases/tag/v1.0.0. Danny has published extensive documentation on how to use the tool on GitHub.

GAP_4_1_4

That’s it for today. If you use HX you can now improve your investigation methods using the mentioned tools. Consider and think about the following 3 steps:

  • Based on leads or alerts you collect Live Response data
    • Use HXTool Script Builder to create a script to acquire Live Response Data
    • Use HXTool to run a Bulk Acquisition to run the acquisitions of Live Response data
    • Download the Live Response Acquisition using HXTool
  • Analyze results & develop timeline
    • Use GoAuditParser to extract, parse and timeline the results.
    • Perform the forensic investigation by interpreting the results
    • Use your favorite tool to create a timeline (likely Excel)
  • Design, build, deploy and adopt Real-Time IOCs and Sweep IOCs
    • Use IOC editor to build IOCs that represent your findings
    • Use IOC editor to create IOCs for both Sweeps and Real-Time
    • Deploy Real-Time IOCs using OpenIOC2HXIOC
    • Create Sweeps with HXTool using Script Builder, Job Filters in conjunction with IOCs to filter results and BulkAcquistions.
  • Repeat

Hopefully this short summary increases the awareness on how to use HX more efficiently. It also serves to capture a perspective on how to use HX because you can use such tools to handle real security incidents and intrusions at enterprise level.

References:

Endpoint Security Server User Guide Release 5.0.2
Endpoint Security Server System Administration Guide Release 5.0.2
IOC Editor 2.2.0.0 User Guide


Tagged , , , , ,

Finding Evil on my Wife’s Laptop – Part II

[The first part of this article described the steps needed to do a live memory acquisition of a potentially compromised system using a free tool called Redline – version 1.11.1 -. In this case the system was my wife’s computer which had been complaining about the slowness of her system for quite some time. With the memory image done, I could start a full investigation with Redline and look for known threats hits against IOCs. ~Luis]

Back in February 2013, Mandiant released a unique report called APT1, Exposing One of China’s Cyber Espionage Units. This report is a must read for everyone in the security industry. It  exposed detailed evidence about a cyber espionage campaign that has been claimed to be carried out by the Chinese government.  The report is full of details, very well written and contains massive tactical intelligence. In two weeks following its release it generated a lot of comments and research. One important aspect of this report was that Mandiant released a separate appendix which contains huge number of indicators such as domain names, IP addresses, SSL certificates and MD5 hashes. The appendix can be downloaded here. The appendix C – The Malware Arsenal contains full details about the discovered malware capabilities including description, registry keys, mutex names, C&C addresses and others in a very structural fashion.  The appendix G – IOCs contains the indicators of compromise in OpenIOC format that can be imported into Redline to find Evil.

digitalartifacts

Basically, what I did was to import those digital artifacts in OpenIOC format into Redline and then analyze the memory image to find matches.
First, I opened the Redline tool and selected to open a recent analysis session – which was done in part I -.  Then clicked on the top left M button and selected Session information.

redline-recentanalysis

The Analysis Session Information box appeared. In the Memory Image Location,  I browsed into the collected data folder and selected the memory image. The file should be in the folder where the data was collected and it starts with the name w32memory-aquisition.xxx. This will allows us to acquire memory address space of processes and drivers. With this feature we can dump malicious processes or driver from memory into a file. Then we could eventually disassemble it to further determine its capabilities.  Clicked ok to finish.

redline-analysisinfo

Next, I  went to Mandiant Redline Options trough the M button. Here I  selected the Whitelist Management and imported a MD5 Whitelist provided by Mandiant. This extra list is a set of hashes from common (known good) executable files to filter out some of the memory analysis entries. Includes known good DLL’s and executable hashes from Microsoft Windows Server Update Service and National Software Reference Library and can be downloaded here. Then clicked Add to Whitelist to append this hashes to the existing ones. Next clicked Hide Whitelisted Items by Default and clicked ok. This allows me to hide a great number of known good information because the tool does not display any file with an MD5 hash value in the whitelist.

redline-options

After that, in the Start your Investigation page – this is the home page of your analysis and contain different steps suggested by the tool to assist you in the investigation – I selected I am Reviewing a Full Live Response or Memory Image and clicked in Investigate. This took me to the navigation page where I could apply a set of filters to do a in depth analysis of the system. The tool automatically groups data by types, such as processes or users, and creates views to help you spot potential areas of compromise. First thing that called my attention was in the Processes filter where the svchost.exe was redlined with a malware risk index (MRI) score of 85. The MRI score allows me to prioritize the investigation. Higher the score more likely this process is involved in a potential compromisse.

redline-processes

I double clicked in the process and it took me to the detailed information page. Then I select the MRI Report tab at the bottom of the window. Here I could see the reasons that  contributed to the high MRI score, a pie graph and various tables of risk factors  . One relevant aspect was that it contained a big number of  injected memory sections.

redline-processfulldetail

Next, without losing anymore time I went to the IOC reports section and clicked on Create a new IOC report.  The Start you Analysis section appeared. Here I  selected the folder in which the IOC files were  located which was the folder where I extracted the APT1 appendix report. A huge list of indicators were loaded. I could review them, enable and disable each IOC by checking it. The warnings indicates that Redline will evaluate the IOC, but it may falsely indicate there were no hits (a false negative) due to a lack of collected data or unknown terms.

redline-iocreportcreation

Then the data was evaluated and executed in the background. It took around 30m to finish. When the analysis was done I could browse the IOC report. In the report I could see details about the IOC, such as definition and author. Hits associated with each file that corresponds to an IOC. Detailed information about each hit and the number of indicators that generated hits. In this case the IOC characteristics of the GREENCAT and WEBC2-GREENCAT malware family matched the characteristics observed in the system!

redline-iocresults1

GREENCAT family was one of the malware profiled in the APT1 campaign and is described in the  appendix C – The Malware Arsenal . Basically is a backdoor that communicates with a C&C server and includes a variety of features such as gathering info about the system or creating a shell. When clicking in the details section I could see full hit details such as the file and PE info. In the PE Info I could get further details on PE Sections, Exported and Imported functions and strings.

redline-iocresults2

As you could see is extremely easy and accessible to everyone to do a memory analysis on a potential compromised system and use IOCs to find known Evil.  The tools are getting better, more sophisticated and automated. With this type of tools I even get the feeling that I could do memory forensics and hunting malware!

Additionally, In the resources section of the OpenIOC site you can find IOCs for malware including Zeus, Stuxnet, Duqu and others. You could then import them into Redline and scan your systems. You never know if someone might have implanted a Stuxnet variant on your home systems to compromise your wife’s nuclear centrifuge ; ).

As possible next steps, I  might get a copy of the malware sample by dumping it from memory or get the binary itself. Then take it to my malware analysis lab and determine its capabilities. Using behavioral and code analysis techniques combined with the assistance of tools available on REMnux you analyse it in a controlled environment. From an incident response perspective, I will now proceed with the containment phase. I will notify my wife about what happened and I will take her system offline in order to stop the damage and prevent the attacker from getting further. I will then go through the eradication, recovery and lessons learned phase.

 

References:
Redline User Guide

Tagged , , , , ,

Indicators of Compromise (IOC’s)

indicators20 days have passed since my last post about how to do a live memory acquisition of a windows system for malware hunting and forensics purposes. In that article, I  explained the details on how to create a collector, collect the data, and import the data into Mandiant Redline. The second part will be about the investigation and how to look for threats using indicators of compromise (IOC). However, before part II , I would like to give a brief introduction to IOCs.

For those who never heard about indicators of compromise they are pieces of information that can be used to search and identify compromised systems . These pieces of information have been around since ages but the security industry is now using them in a more structural and consistent fashion . All types of companies are moving from the traditional way of handling security incidents. Wait for an alert to come in and then respond to it. The novel approach is to take proactive steps by hunting evil in order to defend their networks. In this new strategy the IOCs have a key role. When someone compromises a systems they leave evidence behind.  That evidence, artifact or remnant piece of information left by an intrusion can be used to identify the threat or the malicious actor. Examples of IOCs are IP addresses, domain names, URLs, email addresses, file hashes, HTTP user agents, registry keys, a service configuration change, a file is deleted, etc. With this information one could sweep the network/endpoints and look for indicators that the system might have been compromised. For more background about it you can read Lenny Zeltzer summary. Will Gragido from RSA explained it well in is 3 parts blog here, here and here. Mandiant also has this and this nice articles about it.

Now, different frameworks and taxonomy exist in the security industry in order to deal with IOCs. These frameworks are important in order to share information in a consistent, scalable, automated and repeatable way across different organizations. One initiative is the OpenIOC sponsored by Mandiant. OpenIOC uses an extensible XML schema that allows to describe the technical characteristics of an intrusion or malicious actor.  Another initiative is from the IETF Working Group who defined two standards. One for describing the observables of security incidents which is  The Incident Object Description Exchange Format (IODDEF) described in RFC 5070. The other is the Real-time Inter-network Defense (RID) described in RFC 6545 and is used to transport and exchange the IODEF  information. Other initiative is from MITRE that developed CyboX, STIX, and TAXII , all free for the community and with high granularity. In order to read more about these initiatives Chris Harrington from EMC Critical Incident Response Center has a nice presentation about it. Other resource is a very interesting study made last October by ENISA named Detect, SHARE, Protect – Solutions for Improving Threat Data Exchange among CERTs.

That being said, we can now start using these IOCs to defend our networks. One way is by gathering information from the investigations made by security researches or vendors with actionable intelligence. For example back in September 2013 the campaign “ICEFOG : A tale of cloak and three daggers” was released by Kaspersky. This report contains great technical details and significant amount of actionable information. Another example was the  NetTraveler campaign which has been disclosed in June 2013. This report describes a piece of malware was used to successfully compromise more than 350 high-profile victims across 40 countries. The report is well written and contained great technical details. On chapter 5 it presents a huge list of IOCs to help detect and eradicate this threat. Following that, Will Gibb from Mandiant converted the information from the NetTraveler report into the OpenIOC format.  With this IOCs one could import it into  Redline. Of course this was an effort made by a vendor to incentive the usage of his format but others could use any other standard or framework to collect this observable’s and turn them into actionable information.

On my next post I will show how to import IOCs in OpenIOC format into Redline and find Evil on my wife’s laptop!

Tagged , , , , ,