Report Format ll-ioc-json

The Lastline Analyst API allows extracting Indicators of Compromise (IOC) from analysis reports. These IOC reports are available in three formats:

• Structured Threat Information Expression (STIX),
• Open Indicators of Compromise (OpenIOC), and
• Lastline IOC (format described in more detail below).

The OpenIOC and STIX formats are described in more detail in their respective documentation pages at http://stixproject.github.io/releases/1.2/ for STIX and http://schemas.mandiant.com for OpenIOC v1.0 and v1.1 schemas.

IOC reports in Lastline IOC format are composed of two basic entities: Matches and Rules. A Match entity describes a single object (such as a file on the file system) with specific properties (such as the name of the file). A Rule combines multiple Match objects into complex expressions. Alternatively, a Rule can also combine one or more Rule objects. While some Match types describe objects that are available in STIX or OpenIOC, others do not have a direct mapping into the other IOC formats. The following table shows Lastline IOC Match types and their counterparts:

Lastline	OpenIOC	STIX
Mutex	ProcessItem/HandleList/Handle/Name	MutexObj
Registry	RegistryItem/KeyPath, RegistryItem/Value	WinRegistryKey
File	FileItem/FullPath	WinFile
Autostart	None	None

Report Structure

The Lastline IOC report contains a tree (dictionary) formatted using JSON or XML. This tree contains 2 main sections, containing a list of Match and Rule objects.

Matches

The Matches section contains a list of all basic entities that were extracted as Indicator of Compromise. That is, the analysis system found the behavior to be indicative/interesting in terms of the system modification.

Each entry is defined by a unique name attribute, as well as a type. Depending on the type, the entry has other, type-specific arguments (args) describing the entry in more detail.

Mutex

• type attribute value: mutex_match

• args:

  • mutexname: required string with global mutex name.

Registry

• type attribute value: reg_match

• args:

  • reg_key: required string with registry key path. Example: HKCU\Software\Microsoft\Windows.
  • reg_value_name: optional string with value name (note that this is not the data stored in the registry, but the name under which it is stored). Example: IsAutoLoadable.

File

• type attribute value: file_system_match

• args:

  • filename: required string with full path to file. Example: C:\mysample.txt
  • md5: optional string with md5 of file

Autostart

• type attribute value: autostart

• args:

  • class: one of logon, explorer, bho, services, codecs, hijack, appinitdll, office.
  • filename: required string with full path to file. Example: C:\mysample.txt
  • md5: optional string with md5 of file

Rules

The Rules section contains a list of boolean expressions combining individual Match or Rule entries into complex expressions. An expression contains one or more entries combined with boolean operators and or or.

A report may contain a special Rule named root to indicate one Rule entry that combines all other entries into one expression describing all objects described in this IOC report.

Examples

Example1

This example shows two Match entries, and each entry refers to a file on the file system using different parameters.

The objects are combined using the OR operator, meaning that the IOC should match if at least of the two files exists with the given properties:

{
    "matches": [
        {
            "name": "full_1",
            "type": "file_system_match",
            "args": {
                    "filename": "c:\\windows\\systemself.exe"
                }
        },
        {
            "name": "files_1",
            "type": "file_system_match",
            "args": {
                "md5": "6062fdc71440cb97db32c645627e181f",
                "filename": "c:\\windows\\systemself.exe"
            }
        }
    ],
    "rules": [
        {
            "name": "root",
            "match": "full_1 or files_1"
        }
    ]
}

Example2

This example shows two Microsoft Windows Registry elements. The first is described by its key, the other by its key and value name.

The objects are combined using the AND operator, meaning that the IOC should match if both registry entries exist with the given properties:

{
    "matches": [
        {
            "name": "full_1",
            "type": "reg_match",
            "args": {
                "reg_key": "HKLM\\test1"
            }
        },
        {
            "name": "full_2",
            "type": "reg_match",
            "args": {
                "reg_value_name": "ObjectId",
                "reg_key": "HKLM\\test2"
            }
        },
    ],
    "rules": [
        {
            "name": "all_indicators",
            "match": "full_1 and full_2"
        }
    ]
}