Skip to content

4.11. Detect shellcode by custom patterns (pattern)

hasherezade edited this page Feb 25, 2024 · 18 revisions

Option: /pattern

By default, PE-sieve comes with a set of hardcoded patterns that are used to detect if the scanned memory area contains shellcodes. We can enable using them in the scan by parameter /shellc (selecting /shellc P, or other dedicated options: more information in 4.1.-Detect-shellcodes-(shellc) ).

Since version 0.3.9 PE-sieve offers also detection by custom set of patterns, that can be defined by the user. The file with the patterns need to be supplied after the parameter /pattern. Format: pattern [patterns file]. Example:

pe-sieve.exe /pid 1243 /pattern my_patterns.txt

The pattern file can be used in addition to the hardcoded patterns, or as a standalone.

In the following case, both hardcoded paterns and custom patterns are used:

pe-sieve.exe /pid 1243 /pattern my_patterns.txt /shellc P

NOTE

  1. Patterns are searched in the regions that don't belong to any module (not inside the main EXE, loaded DLLs, etc.).
  2. By default, PE-sieve scans only executable areas. In order to scan non-executable regions, use option /data with appropriate argument

Patterns file format

The file has to follow the SIG format, used by SigFinder. It needs to contain one or more definitions of patterns. Each pattern is defined in the following way:

<Signature name>
<Number of elements in the signature: N (decimal)>
<N byte definitions>

The byte definitions are expected values of bytes, in hexadecimal format. Each unknown nibble can be masked by ?.

Examples of valid byte definitions:

23 56 12 68

  • matches: 23 56 12 68

55 0? 34 12

  • matches: 55 00 34 12, 55 01 34 12, ... 55 0F 34 12

40 ?? 4? 8? e?

  • matches i.e.: 40 89 43 85 e2, 40 AA 44 80 e6, etc.

Example of a valid signature:

Heavens_Gate1
12
6A 33 
E8 00 00 00 00
83 ?? ?? 05
CB

The output

The scan_report.json provides details on detected artifacts, including patterns. If the scan by any (hardcoded or custom) patterns was issued, the workingset_scan section will contain a sub-section patterns with a summary on patterns that matched. It can have the following fields:

  • total_matched (count of all patterns matched, including the hardcoded ones)
  • custom_matched (count of patterns matched from the set defined by the user in pattern file)

If any of the user-defined patterns were found, the containing memory area will be detected as suspicious, and dumped into a file, as it happens in case of any other shellcodes detected. Additionally, a .pattern.tag file will be generated, detailing where exactly each pattern can be found in the dump.

The .pattern.tag file follows the TAG format, and contains the following information:

[offset:hex];[Pattern name];[pattern length:hex]

If pattern.tag file was generated, the dump_report.json will contain information about it. The name of the file will be added in the pattern_tags_file field of the relevant module.

Example

File: 4466000.shc.pattern.tag. Content:

16b0;Heavens_Gate1;c
1728;Heavens_Gate1;c
17b1;Heavens_Gate1;c

From the above we can learn that the list of tags belongs to the dump 4466000.shc. The user defined pattern, Heavens_Gate1 was found 3 times, at offsets 16b0, 1728, 17b1 relative to the start of the memory region. The pattern is 12 (0xC) bytes long.