Skip to content

Latest commit

 

History

History
243 lines (197 loc) · 10.6 KB

0015-create-file-elf.md

File metadata and controls

243 lines (197 loc) · 10.6 KB

0015: Create the ELF sub-field of the File fieldset

  • Stage: 2 (candidate)
  • Date: 2021-05-04

Create the Executable Linkable Format (ELF) sub-field, of the file top-level fieldset. This document metadata can be used for malware research, as well as coding and other application development efforts.

Fields

Stage 0

This RFC is to create the ELF sub-field within the file. fieldset. This will include 25 sub-fields.

Name Type Description
elf.creation_date date Extracted when possible from the file's metadata. Indicates when it was built or compiled. It can also be faked by malware creators.
elf.exports flattened List of exported element names and types.
elf.exports.name keyword Name of exported symbol
elf.exports.type keyword Type of exported symbol
elf.segments nested ELF object segment list.
elf.segments.type keyword ELF object segment type.
elf.segments.sections keyword ELF object segment sections.
elf.header group Header information of the ELF file.
elf.header.class keyword Header class of the ELF file.
elf.header.data keyword Data table of the ELF header.
elf.header.machine keyword Machine architecture of the ELF header.
elf.header.os_abi keyword Application Binary Interface (ABI) of the Linux OS.
elf.header.type keyword Header type of the ELF file.
elf.header.version keyword Version of the ELF header.
elf.header.abi_version keyword Version of the ELF Application Binary Interface (ABI).
elf.header.entrypoint long Header entrypoint of the ELF file.
elf.header.object_version keyword "0x1" for original ELF files.
elf.imports flattened List of imported element names and types.
elf.imports.name keyword Name of imported symbol
elf.imports.type keyword Type of imported symbol
elf.packers keyword Packers used for the ELF file.
elf.sections nested Section information of the ELF file.
elf.sections.flags keyword ELF Section List flags.
elf.sections.name keyword ELF Section List name.
elf.sections.physical_offset keyword ELF Section List offset.
elf.sections.type keyword ELF Section List type.
elf.sections.physical_size long ELF Section List physical size.
elf.sections.virtual_address long ELF Section List virtual address.
elf.sections.virtual_size long ELF Section List virtual size.
elf.sections.entropy float Shannon entropy calculation from the section.
elf.sections.chi2 float Chi-square probability distribution of the section.
elf.shared_libraries keyword List of shared libraries used by this ELF object
elf.telfhash keyword telfhash hash for ELF files.
elf.architecture keyword Machine architecture of the ELF file.
elf.byte_order keyword Byte sequence of ELF file.
elf.cpu_type keyword CPU type of the ELF file.

Stage 1

New elf.yml candidate

Usage

In performing file analysis, specifically for malware research, understanding file similarities can be used to chain together malware samples and families to identify campaigns and possibly attribution. Additionally, understanding how malware components are re-used is useful in understanding malware telemetry, especially in understanding the impact being made through the introduction of defensive countermeasures.

As an example, if XDR vendors deploys a new malware model to defeat a specific type of ransomware and we start observing a change and/or relationship to the headers, import tables, libraries, etc of that malware family, we can make assumptions that the changes to the malware model are making an impact against the malware family.

As another example, tracking file metadata for specific families is useful in predicting new campaigns if we see similar file metadata being used for new samples. Example, the Maze ransomware family shutting down and re-purposing as Egregor (this is for Windows malware, but the concept is the same).

Source data

Stage 1

This type of data can be provided by logs from VirusTotal, Reversing Labs, Lockheed Martin's LAIKABOSS, Emerson's File Scanning Framework, Target's Strelka, or other file/malware analysis platforms.

Stage 2

Real world examples

"file": {
  "elf": {
    "packers": [
      "upx"
    ],
    "header": {
      "object_version": "0x1",
      "data": "2's complement, little endian",
      "os_abi": "UNIX - Linux",
      "machine": "Advanced Micro Devices X86-64",
      "entrypoint": 4846016,
      "abi_version": 0,
      "type": "EXEC (Executable file)",
      "version": "1 (current)",
      "class": "ELF64"
    },
    "segments": [
      {
        "type": "LOAD",
        "sections": []
      },
      {
        "type": "LOAD",
        "sections": []
      }
    ]
  }
}
"file": {
  "elf": {
    "header": {
      "object_version": "0x1",
      "data": "2's complement, little endian",
      "machine": "Intel 80386",
      "os_abi": "UNIX - System V",
      "entrypoint": 0,
      "abi_version": 0,
      "type": "DYN (Shared object file)",
      "class": "ELF32",
      "version": "1 (current)"
    },
    "segments": [
      {
        "type": "PHDR",
        "sections": []
      },
      {
        "type": "LOAD",
        "sections": []
      },
      {
        "type": "LOAD",
        "sections": []
      },
      {
        "type": "DYNAMIC",
        "sections": []
      },
      {
        "type": "GNU_EH_FRAME",
        "sections": []
      },
      {
        "type": "GNU_STACK",
        "sections": []
      },
      {
        "type": "GNU_RELRO",
        "sections": []
      }
    ]
  }
}

Scope of impact

Stage 2

There should be no breaking changes, depreciation strategies, or significant refactoring as this is creating a sub-field for the existing file. fieldset.

Concerns

ELF Imports

Type flattened won't allow explicit field mappings to be defined, so I don't think it's necessary to explicitly list them here. However, is there intent to still describe for data sources on how to "shape" the data for these flattened fields? There are no type: flattened fields today in ECS, so how to best capture provide that type of guidance will need to be hashed out.

People

The following are the people that consulted on the contents of this RFC.

  • @peasead | author
  • @devonakerr | sponsor
  • @dcode, @peasead | subject matter expert

References

RFC Pull Requests