Bangeter 04-malware_identification_v50.pdf

• Mostly the same attack has been used befor.
• Most malware families have been analyzed befor -> addition information
• Through identifying malware we emidiatly get access to all work done previously
• analysis of new malware can take days to months.

An indicator of compromise (IOC) is an a priori known characteristic artefact of attacks, malware samples / families.

IOCs can be used for detection and identification purposes.

Host based IOCs

• Hashes of malware executables, modules, dropped files etc...
• Filenames of dropped files or email attachements (infection vector)
• Registry entries (e.g. used for persistence)
• Mutexes (program object that is created so that multiple program thread can take turns sharing the same resource, such as access to a file.)
• Process names
• Anti-virus or Yara signatures
• Strings

Network based IOCs

• IPs addresses or domain of CC
• CC protocol characteristics
• WHIOIS information

Yara is a language to check for IOCs

• open language anyone can write rules
• allows shareing of rules

In contrast to AV engine rules, Yara rules can be written and shared by anybody, which allows security teams to act independently of vendors.

Yara rules ca be used in different places of an organiyation's detection / security technologies:

• Memory forensic investigation
• Sandboxes
• Endpoint / AV
• Gateway detection

Malware analysis can be very time consuming and expensive. Shortage of skilled analysts and an abundant number of malware samples does not scale well

Solution: Analysis automation

AV vendors and threat intelligence companies automatically process and analyze feeds of 100'000s of malware samples per day to generate, better av signatures IOCs or threat intelligence.

Malware sandboxes automate malware (binaries, documents, URLs) analysis, and typically allow to quickly:

• Determin whether a sampe is malicious
• Determine IOCs
• Determine the malware family (in some cases), e.g. based on correlation of IOCs or using Yara rules

Malsware sandboxes are dynamic analysis systems:

• Samples submitted to a sandox are executed for a couple of minutes
• Then an analysis report is presented to the user.
• Analysis reports can often be read by less skillec analysts for triage purposes

• Detection of the instruments being used
  • Detection of debuggers, or prevent attaching debuggers
• Detecting virtual machines
  • Malware sleeps for a couple of minutes to defeat sandboxes
  • Malware tries to figure out whether it is on a real machine or running in a Sandbox:
    • No user interaction
    • Small memory of analysis machine
    • Only one CPU
    • etc...
• Once an analysis environmment is detected, malware will exit, or show non-malicious behavior

In general it is impossible to recontruct the original PE file from memory since some modifications cannot be undone:

• IAT
• Relocations
• Some pages may be missing from memory

Don't expect the recovered PE files to be runnable

Recovered PE files are sufficent for analysis with IDA Pro or to upload to Virustotal.

Malware sometimes modifies /destructs the PE header in memory to make reconstruction hard/impossible

PE files in memory contains more information than PE files on disk:

• DLLs used by PE file
• Dynamic data such as heap and stack

Packing is an ovfuscation technique used by malware, with two goals:

• Evading AV signatures
• Prevent or slow down static analysis

To unpack malware it is often sufficient to dump memory of the unpacked process, recieving memory injections.

PE rebuild

• prcdump
• dlldump

Raw:

• vaddump
• memdump
• malfind ... ./dumps-malfind

General limitation: Memory that is paged out cannot be dumped, which can result in corruption when dumping PE files

we can upload dll and executables that we extracted with dlldump and procdump to malfind for automatic analysis.

The dumped strings may contain:

• CC commands
• CC URLs
• Filesystem paths
• Malware names
• Names of AVs to kill
• Malware log messages
• ...

In some cases, the strings may be sufficient to identify a sample, or at least to develop a first understanding of a samples capabilities.

Simply run strings on dumped (and unpacked) process memory, DLLs ,etc..

Under linux two invocations of strings needs to be made for ASCII and unicode strings

strings -el memory.bin

stings memory.bin