3.3. JSON reports

PE-sieve creates 2 JSON reports:

• Scan report (scan_report.json)
  • Provides details what scans have been performed on the process, which detected anomalies of certain types.
• Dump report (dump_report.json)
  • Provides details on in which form the artifacts has been dumped.

Scan report

The scan report is divided on segments. First comes the general summary from all scans. Example:

{
 "pid" : 684, // PID of the process that was scanned
 "is_64_bit" : 1, // Flag indicating if the process was 64 bit: 1 if true, 0 if false
 "is_managed" : 0, // Flag indicating if the process was managed (.NET) : 1 if true (.NET process) , 0 if false (native process)
 "main_image_path" : "", // The path of the main image (from PEB). If empty, it often indicates process Doppelgänging.
 "scanned" : 
 {
  "total" : 48,  // total count of scanned modules
  "skipped" : 0, // count of modules excluded from the scan, for example:
                 // excluded on demand by the parameter: /mignore <module>
  "modified" : // list of all the modules in which any of the suspicious indicators were detected
  {
   "total" : 2, // total count of modules detected as suspicious
   "patched" : 0, // count of modules detected as patched (possible inline hooks or other code modifications)
   "iat_hooked" : 0, // count of modules where IAT hooks were detected
   "replaced" : 1, // count of hollowed/replaced modules
   "hdr_modified" : 0, //count of modules with PE headers modified (but without modifications typical for replaced modules)
   "implanted_pe" : 0, // count of manually mapped PEs (not associated with any PE file on the disk)
   "implanted_shc" : 0, // count of sections with code mapped outside of any PE (shellcodes, JITs)
   "unreachable_file" : 0, // count of modules that were associated with a PE file on the disk, but
                           // this file was deleted or inaccessible
   "other" : 1 // any additional indicators - such as
               // inconsistency between the path of mapped module and corresponding path set in the PEB
  },
  "errors" : 0 // count of inconclusive scans, interrupted by some errors
 },
[...]

After the general summary, we have a list of reports for particular scans that gave the suspicious indicators. Example:

 "scans" : [ // list of the reports from particular scans
  {
   "mapping_scan" : {
    "module" : "7ff6bc950000",
    "module_file" : "C:\\Windows\\notepad.exe",
    "mapped_file" : "",
    "status" : 1
   }
  },
  {
   "headers_scan" : {
    "module" : "7ff6bc950000",
    "module_file" : "C:\\Windows\\notepad.exe",
    "status" : 1,
    "is_pe_replaced" : 1,
    "dos_hdr_modified" : 1,
    "file_hdr_modified" : 1,
    "nt_hdr_modified" : 1,
    "ep_modified" : 1,
    "sec_hdr_modified" : 1
   }
  }
 ]

Mapping scan

Scan checking consistency between the path that was mapped, and the path set in PEB. In a normal situation they both should point to the same file.

   "mapping_scan" : { // report from the mapping scan
    "module" : "7ff6bc950000", // the base address at which the module was mapped in the memory
    "module_file" : "C:\\Windows\\notepad.exe", // The path set in the PEB
    "mapped_file" : "", // The path from which the module was mapped. If empty, it often indicates process Doppelgänging.
    "status" : 1 // status 1 - means positive result (suspicious)
   }

Headers scan

Scan checking consistency between the PE header mapped in memory, and header from a corresponding file on the disk.

   "headers_scan" : { // report from the headers scan
    "module" : "7ff6bc950000", // the base address at which the module was mapped in the memory
    "module_file" : "C:\\Windows\\notepad.exe", // The path corresponding to the module (for informational purposes)
    "status" : 1, // status 1 - means positive result (suspicious)
    "is_pe_replaced" : 1, // Flag indicating if the PE was detected as replaced - completely different than corresponding file on the disk
    "dos_hdr_modified" : 1, // Flag indicating if the differences were detected in DOS headers of both PEs:  
                            // 1 if true (different) , 0 if false (same)
    "file_hdr_modified" : 1, // Flag indicating if the differences were detected in File headers of both PEs 
    "nt_hdr_modified" : 1, // Flag indicating if the differences were detected in NT headers of both PEs 
    "ep_modified" : 1, // Flag indicating if the Entry Point differs in both PEs
    "sec_hdr_modified" : 1 // Flag indicating if the differences were detected in Section Headers of both PEs
   }

Sometimes the modifications in the headers are subtle, and they do not indicate a replacement of the full PE. That's why the flag is_pe_replaced helps to easily filter out when the PE was really replaced/hollowed.

Code scan

Scan checking consistency between the code section(s) of the PE mapped in memory, and corresponding sections from a file on the disk.

   "code_scan" : { // report from the code scan
    "module" : "75660000", // the base address at which the module was mapped in the memory
    "module_file" : "C:\\Windows\\SysWoW64\\user32.dll",  // The path corresponding to the module (for informational purposes)
    "status" : 1,  // status 1 - means positive result (suspicious)
    "patches" : 2, // how many patches are detected
    "scanned_sections" : 1 // how many sections in the PE were detected as code sections, and scanned for patches
   }

If this scan detected some patches, the full list of them will be dumped as a file with .tag extension. This file can be loaded to other analysis tools, and used for investigating of hooks and patches.

IAT scan

Scan checking consistency between the addresses filled with IATs and the addresses of the imported functions. It detect IAT hooks, and a well as imports shimming.

//TODO

Working set scan

Scan checking workingset against manually mapped (potentially implanted) PE files and related artifacts, as well as for sections with code mapped outside of any PE (shellcodes, JITs).

//TODO

Dump report

While the scan report gives details about the results of the scans, dump report describes the material that was dumped.

Example:

{
 "pid" : 684, // PID of the process that was scanned
 "output_dir" : "process_684", // The directory where the output from the process was saved
 "dumped" :  // summary of the dumped modules
 {
  "total" : 2, // total count of the modules supposed to be dumped
  "dumped" : 2 // count of the module that were dumped successfully
 },
 "dumps" : [ // reports about each dumped module
  {
   "module" : "7ff6bc950000", // the base address at which the module was mapped in the memory
   "module_size" : "e4000", // the size of the module
   "dump_file" : "7ff6bc950000.notepad.exe", // the file under which the dumped module was saved
   "dump_mode" : "UNMAPPED", // Mode in which the module was dumped.
                             // Possible modes can be listed by a parameter: /dmode ?
   "is_shellcode" : 0, // Flag indicating if the dumped component was a shellcode : 
                       // 1 if true (shellcode) , 0 if false (PE)
   "status" : 1 //  Flag indicating if the module  was dumped successfully
  },
[...]
 ]
}

If some additional material was dumped, the dump report may contain more fields. For example:

 "dumps" : [
  {
   "module" : "75660000",
   "module_size" : "153000",
   "dump_file" : "75660000.user32.dll",
   "tags_file" : "75660000.user32.dll.tag", // the tag file where the details about patches have been saved
   "dump_mode" : "UNMAPPED",
   "is_shellcode" : 0,
   "status" : 1
  }