hasherezade / pe-sieve Goto Github PK

Hi Hasherezade,

I've tried to process the JSON output in your newest release in LOKI and noticed that back slashes are not escaped.

Paths should be expanded to their full format before the comparison - otherwise they are mistakenly reported as different. Example of the invalid report:

"mapping_scan" : {
"module" : "6cc90000",
"status" : 1,
"mapped_file" : "C:\Program Files\Microsoft Office\Office15\URLREDIR.DLL",
"module_file" : "C:\PROGRA~1\MIF5BA~1\Office15\URLREDIR.DLL"
}

Currently the parameters have to start from the Windows-style switch, i.e.
/shellc
It makes difficult to use it when started from MinGW shell.
It should be possible to use the same parameters with two versions: with Windows-like switch, as well as with Linux-like switch, i.e.
-shellc
/shellc
both should be treated as the same parameter.

Test cases

Case 1:
c999ab160f652e1c6980c50507e1aacb9058d3aa359c92dd74bf3fc5ae5fd47b - KeygenMe v7 by MaxXor
Case 2:
5e1967db286d886b87d1ec655559b9af694fc6e002fea3a6c7fd3c6b0b49ea6e - Floki Bot

How it is

The hooks are tagged in the following way:

ec7c;CreateWindowExW->402551;5
1e981;CharUpperW->4017be;5

We can see the offset where the hook is installed, and the name of the hooked function. Hook target is represented by its VA. However, finding what is the module where the hook leads to, requires manual analysis.

How it should be

The target module should be mentioned in the report, i.e.:

ec7c;CreateWindowExW->402551[400000+2551:KeygenMev7.exe];5
1e981;CharUpperW->4017be[400000+17be:KeygenMev7.exe];5

or, in case if the hook leads to unnamed implant, it should be marked as unnamed:

ec7c;CreateWindowExW->402551[400000+2551:(unnamed)];5
1e981;CharUpperW->4017be[400000+17be:(unnamed)];5

Problem

In case if the first record in the Import Table is filled with a shim, this import is not recognized by PE-sieve. So, PE-sieve marks the Import Table as incorrect, and try to find a new one, setting the offset after the shim as the beginning of the Import Table.

Expected behavior

PE-sieve should not be overwriting Import Table's offset in such cases.

after scanning a lot of processes it finds both of these dll's as suspicious and hooked into a lot of processes, guessing this is probably a false positive but just asking to make sure :)

An extra null pointer check is not needed in the destructor for the class “ProcessScanReport”.

Test case

eed6d6301fe7ee79ce88ac7a65f42532fc7caa24e59333e3e662b804da5f322f - Qakbot

Problem

PE-sieve crashes at the phase of saving the payloads (example from 1.6.1)

Scan status before the crash suggests that it happened during payload reconstruction:

This issue was identified when a process load an image at "C:\Program Files (x86)\Razer\Synapse3\Service\..\UserProcess\Razer Synapse Service Process.exe"

PE Sieve identified that this did not match the mapped image, "C:\Program Files (x86)\Razer\Synapse3\UserProcess\Razer Synapse Service Process.exe"

Consider using PathCchCanonicalize before comparing the mapped image path to the image intended to be mapped to avoid this issue.

Since v0.2.1 PE-sieve no longer works on XP.
The reason is, the function GetProcessDEPPolicy is not available on XP, and should be retrieved dynamically. Since the unsupported function is in the Import Table of the application, it won't run on XP:

So far PE-sieve can reconstruct corrupt import table basing on its artefacts. However, in some cases we may need full rebuilding of import table.
PE-sieve should be able to make a fully new import table basing on the found IAT, and attach it at the end of the PE file by extending the last section.

@hasherezade
in path_converter.cpp (line 97), in the std::string convert_to_win32_path(std::string path) function an assignment is done in place of a compare operator:

if (stripped_path[1] = ':') {

Hello, maybe I'm doing something wrong, but I'm sure pe-sieve can detect that standard injection by this tool - https://github.com/rvrsh3ll/MSBuildAPICaller

Here s screenshot:

• Some of the malware packers/protectors erase PE headers of the payload to evade automated unpackers. The header can be erased in fragments or fully. Examples:
  • Princess Locker: https://www.virustotal.com/#/file/b07c1eb438ea06719492576d60b562c7184a231ba0cc3dbee8a211a03b29b548
  • Korplug: https://blog.malwarebytes.com/threat-analysis/2016/08/unpacking-the-spyware-disguised-as-antivirus/
  • Smoke Loader: https://blog.malwarebytes.com/threat-analysis/2016/08/smoke-loader-downloader-with-a-smokescreen-still-alive/
• PE-sieve's scanner should be able to recognize that the particular memory area contains a PE file, even if the header was removed
• PE-sieve (or libPeConv ?) should be able to reconstruct a valid header before the PE is dumped

Test case

85a6aa581ffa0514149f3267c41681d27600adbe6ca7b35ee328ec3b3d9f749c - a KrugBot sample

Problem

The packer loads a shellcode containing a PE in the memory. PE-sieve run with the option /shellc detects the loaded shellcode. However, it misses to detect and extract the PE file that is embedded there. A view from Process Hacker:

PE-sieve run without any parameters does not detect the payload at all.

Two types of implants are currently detected: PE files and shellcodes (if the scan was deployed in the shellcode detection mode - option: /shellc).
Shellcode should be reported only when there is a detached memory area containing code. However, currently, the code section within a manually loaded PE file is reported twice: as a part of the implanted PE file, and second time as a standalone shellcode.

This bug occurs when the sections of the manually loaded PE file are not in a single allocation area, and are processed as different units.
Test case:

• TrickBot: https://www.virustotal.com/en/file/75c0e4fd24de70c53f8c7eceaa77484cfb788bb6bbb5a1e0b5b604a3e67a7d76/analysis/

Test case

c80ac369737d8215d45de0602b5de844d20795269a5751af00c29d8795edafa2 - Notepad.exe packed with AsPack 2.12 (from "Unpacking with Anthracene 02 - AsPack 2.12")

Problem

All sections of the file are set as NOT executable in the header:

the protection is changed dynamically to executable.
Mistakenly, PE-sieve do not scan them, because it treats them as non-executable.

Hello,
SHA256:
dff7820b2b0b877c46a0cbc6be22b45b11511af7d50e36c7d83fa27f3db277b0
This is a HawkEye sample.
PESIEVE VERSION: 0.2.1 x86 running on Windows 7 32-bit.

It creates a suspended RegAsm.exe and injects into it. Just before ResumeThread is called on the child process, I dumped its contents using both MegaDumper (for .NET executables) and PESIEVE

The PE dumped by PESIEVE doesn't seem to work.
The PE dumped by MegaDumper (ofi.exe) works fine.

As we discussed this is related to the section alignment field of the PE structure as you have discovered. in the PE by PESIEVE it is 0x1000 (wrong value) while the correct value is 0x2000

The following zip file contains

1. Original HawkEye sample
2. PESIEVE dump of RegAsm.exe
3. MegaDumper dump of RegAsm.exe
4. Error message screenshot after running the dump by PESIEVE
5. Screenshot of the command line output by PESIEVE

https://ufile.io/l2jbzynr
password: hawkeye

Hi,
SHA256: fcfb911e57e71174a31eae79433f12c73f72b7e6d088f2f35125cfdf10d2e1af
This sample of Trickbot spawns after approximately 60-90 minutes an instance of svchost.exe with the module importdll32.dll - which is responsible for stealing browsing data. Tested on Windows 7 32-bit
When using pesieve to dump it, imports were not rebuild correctly.

To verify this - i decrypted the original importdll32 on the disk with trickbot_config_decoder
The decrypted module has the correct imports.

This zip file contains: the original trickbot sample, the decrypted importdll32, dumps of both pesieve and process dump and the pesieve log when trying to dump importdll32 from svchost.exe
password is: trickbot
https://ufile.io/yqr7u

Full area of IAT (as defined in Data Directory) is excluded from the code scan. It is scanned by another type of scan, detecting IAT hooks. This is in general a good behavior, but it creates a blind spot for the patches that are installed in the padding at the end of the IAT.

Example:

Test case:

• https://www.hybrid-analysis.com/sample/8b86662ab617d11079f16d95d4d584e8acb4a374b87edf341195ab9e043ed1d2?environmentId=100 (Andromeda)

• The Data Directory of the infected application (svchost.exe):
  
  IAT is located in the .text section, from RVA 0x1000 to 0x11A8.

• It has been hooked by Andromeda and the patch starts from RVA 0x11A4.
  Infected code:
  
  versus the original code:
  

• Due to the fact that IAT is omitted, the hook is not detected properly. Only the bytes that are outside the IAT has been detected as patched:
  

Below: the patched svchost vs the original one:

So, the patch starts in the last DWORD of the IAT (which was filled with padding).

Awesome project!! Thanks!! Would like to make a feature request for python bindings please!

I encountered this behavior using Loki in order to scan several machines. At first I was wondering if it was a false positive, but I set up a testing Windows 10 and the behavior didn't show up.

I get a process replaced for almost every process. For exemple with firefox :

20180910T09:43:16Z [hostname] LOKI: Warning: MODULE: ProcessScan MESSAGE: PE-Sieve reported replaced process PID: 9432 NAME: firefox.exe OWNER: [username] CMD: "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -contentproc --channel="8792.69.1317586373\549569501" -childID 10 -isForBrowser -prefsHandle 4372 -prefsLen 11889 -schedulerPrefs 0001,2 -parentBuildID 20180830143136 -greomni "C:\Program Files (x86)\Mozilla Firefox\omni.ja" -appomni "C:\Program Files (x86)\Mozilla Firefox\browser\omni.ja" -appdir "C:\Program Files (x86)\Mozilla Firefox\browser" - 8792 "\\.\pipe\gecko-crash-server-pipe.8792" 960 tab PATH: C:\Program Files (x86)\Mozilla Firefox\firefox.exe REPLACED: 1

I get this message for all kinds of processes.
I was wondering if it could be some kind of false positive. Also, I was curious about the method you use to check for process hollowing. I checked your code, but it is a still a little bit complex for me. Could you summarize or guide me to some documentation on the subject ? 😄

Hello,
I analyzed a .NET malware. It creates a suspended process, injects a .NET PE into it and resumes execution.
SHA256:
e31fef0296b867dbce44c50bf2517d7d28df97698c85c0d2f51043eea7846924

When dumping with MegaDumper, a tool for dumping .NET executables, the dumped injected PE from child process seems to work fine.

When using PE-SIEVE (Version 0.2.3.1-i (x86))
I get the following error and the entry point is the wrong one - 'Wrong RVA supplied! RVA is out of image scope!'. Of course, I can't execute the dumped PE.

using PE-Bear, here is the difference in the entry point:
https://ibb.co/rdKhJQP

I think it's related to the entry point calculation in .NET executables. I looked at MegaDumper's code, and found that indeed the entry point is calculated in a different way:
https://github.com/CodeCracker-Tools/MegaDumper/blob/291f45bb6dd5401c5d9443cfbff0f2e60c7089f0/MegaDumper/MainForm.cs
The entry point should point to a jmp to the _CorExe routine.

Apart from that, i also noticed a 1-byte difference in the .text section (compare files and see)

In the following .zip file, you will find

1. The sample
2. The dumped PE by PE-SIEVE
3. PE-SIEVE log (using /imp 1)
4. The dumped PE by MegaDumper
   Password: tesla
   Link: https://ufile.io/e3pw2gt6

Module Overloading is a new PE injection method that is currently not detected.

• currently the memory page scanner can find only PE files that are aligned to the beginning of a memory page
• some malware load their payloads in an unaligned way (example: https://blog.malwarebytes.com/cybercrime/2017/01/zbot-with-legitimate-applications-on-board/)
• the scanner should be able to detect such cases and properly dump those payloads

Test case

• crinkler_demo.zip - c44a57b69ed73cd585032d60be395f3389133f68852b18ad7e3007682e60be87 - Flare-On 2019, task: Demo

This task is packed by Crinkler packer: http://crinkler.net/
The PE has atypical alignment: no sections.
PE-sieve should detect and dump it like any other packed app.

The title says all

https://github.com/hasherezade/pe-sieve/blob/master/scanners/scanner.cpp#L68

I used the software with all the processes in my machine and got a lot of warnings, so either it's severely compromised by undetected malware or there are many false positives.

Example:

{
"pid" : 612,
"main_image_path" : "C:\Windows\System32\svchost.exe",
"scanned" :
{
"total" : 25,
"skipped" : 0,
"modified" :
{
"total" : 6,
"hooked" : 6,
"replaced" : 0,
"detached" : 0,
"implanted" : 0,
"other" : 0
},
"errors" : 0
},
"scans" : [
{
"code_scan" : {
"module" : "7ffd51060000",
"status" : 1,
"patches" : 59
}
},
{
"code_scan" : {
"module" : "7ffd4d4b0000",
"status" : 1,
"patches" : 11
}
},
{
"code_scan" : {
"module" : "7ffd50320000",
"status" : 1,
"patches" : 4
}
},
{
"code_scan" : {
"module" : "7ffd4e4d0000",
"status" : 1,
"patches" : 58
}
},
{
"code_scan" : {
"module" : "7ffd50250000",
"status" : 1,
"patches" : 9
}
},
{
"code_scan" : {
"module" : "7ffd4d3e0000",
"status" : 1,
"patches" : 3
}
}
]
}

Although... 1 file got detected, so maybe nothing or double false positive? https://www.virustotal.com/#/file-analysis/MGRiNGZlOWU0ZWVjNjM5MjliZDVhY2Q3OGRiMjY2ZjE6MTU0Nzg3MDQ5OQ==

Attaching 1 of the many many processes with warnings.

process_612.zip

Fragment of the invalid report:

{
"mapping_scan" : {
"module" : "400000",
"status" : 1,
"mapped_file" : "E:\\vboxsrv\\vm_shared\\KeygenMe V7.exe",
"module_file" : "E:\\KeygenMe V7.exe"
}
},

• The executable KeygenMe V7.exe was deployed from a VM shared folder. This folder was mapped in the following way:
  E -> \Device\VBoxMiniRdr\;E:\vboxsrv\vm_shared
  The original retrieved path:
  \Device\VBoxMiniRdr\vboxsrv\vm_shared\KeygenMe V7.exe
  was resolved with the first mapping only.
• Instead of this, it should be resolved recursively, till the moment when there is no suitable mapping. Example:
  \Device\VBoxMiniRdr\ vboxsrv\vm_shared\KeygenMe V7.exe ->
  E:\vboxsrv\vm_shared \KeygenMe V7.exe ->
  E: \KeygenMe V7.exe

Hi @hasherezade,

Great tool!
I'd like to integrate PE-Sieve in my LOKI scanner.
https://github.com/Neo23x0/Loki

I have already tested an integration (PE-Sieve started as sub process, processing the output) and failed due to the PAUSE that is integrated after the output summary.

I would like to use your releases and don't want to fork the repo.

Could you make the pause optional or remove it completely in your compiled releases?

#2

This feature was requested by a user working in incident response. In some places of the world people still use Windows XP, so the PE-sieve should be able to scan their systems for anomalies as a part of collecting the material from the incident.

Test case

088597a57480fb76054cae34b94820f35b46a03129e536e495c97aff9112ebc8 - Kovter sample

Affected version

The bug was observed in the past, but was patched. It does not occur in v0.2.3 (the last release), but it was re-introduced by the latest changes.

Problem

The implanted PE is properly detected, but the reconstruction of the PE is unsuccessful.
Example of the report fragment:

 "scans" : [
  {
   "workingset_scan" : {
    "module" : "1320000",
    "status" : 1,
    "has_pe" : 1,
    "has_shellcode" : 0,
    "is_listed_module" : 0,
    "protection" : 64,
    "pe_artefacts" : {
     "pe_base_offset" : "0",
     "nt_file_hdr" : "104",
     "sections_hdrs" : "1f8",
     "sections_count" : 7,
     "is_dll" : 0,
     "is_64_bit" : 0
    }
   }
  }

Expected payload:
539c20437c8266352fef989b834d1e1ba2061364a07f63817fbea62714b8a96a

Test case

e757457b62788c658d38e4d77a0c8cfd5272c5690389e6f51bf4349795311c63

Problem

PE Image Base was found after section headers:

Dumped memory region: 55a075c86f2529613dd7df289d2fb6e828fa2e50b6f0be6d483d29f5393d5c90

Comment

A possible reason was that the memory area contained some bogus artefacts, that misguided the scan. This kind of situation should be prevented by additional checks.

• Sample: 9fb885662b6c0e96a13789f9bdacb36b
• Scanning without any option works fine, but while this sample is scanned with option /imp, the application crashes:
  

Test case

• Banker Mekotio: full package: 1131624ba8d17448c628bc89a8e650c7, the malicious DLL: 106e9deece0f1298bb2559fe29f38ef7f2f67c7974478c845435b4d4ca4f7980

How it is:

Currently, any modifications in sections are treated as patches. Hovewer, sometimes the modified section is not patched, but fully unpacked from the memory. Example:
Before:

After:

Currently, the content of such section is compared with an empty region. It generates a lot of noise, i.e.:

How it should be

Sections that are fully unpacked in the memory should not be treated the same as patched. No tags should be generated for them, and they should be marked as unpacked.

The pointer to the function at GuardCFCheckFunctionPointer is overwritten. PE-sieve detects this as a patch, creating unnecessary noise.
This type of patches should be filtered out by default.

Test case:

• Normaliz.dll
  (i.e. in the process: explorer.exe)
• on Windows 8.1 64bit

Details:

The pointer to the function is located in the scanned section (.text):

Detected patch:

We miss you on youtube... please come back.

PE-sieve version: v0.2.6
Hash: ca8194e9a1232e508619269bdf9a9c71c4b76e7852d86ed18f02088229b0f7c7

Seems like PE-sieve can't read the remote PE at a specific offset - looks like an invalid address?

FYI, this is the new Bazar malware (loader module specifically):
https://www.bleepingcomputer.com/news/security/bazarbackdoor-trickbot-gang-s-new-stealthy-network-hacking-malware/

Test case

0a4962325cf05ea602081647da910866d0d747abbb5d3340dfa721cdd93e9ba5 - Emotet

Problem

Emotet has 2 payloads. One of them is reconstructed correctly, while another is not.

Both payloads are detected:

Header from the payload that is not reconstructed is corrupt (we can see i.e. invalid Machine Id):

Test case

633521d921ddad8671293319f0fd9daab9a0a606887ada3ab3709027cbb1e591 - Ursnif

Problem

During the workingset scan PE-sieve crashes:

This bug is present in version 0.1.6, but not in 0.1.5.

Implement scanning IAT on demand (enabled by a parameter) against classic IAT hooking.

Test case:

Classic IAT hooking (implemented using IAT Patcher): cm_hooked.zip
The replacement function was defined in the following way:

The scan output should look like:

1000100c;User32.MessageBoxW->NagMeNot.dll.MBox;10000000+100c;0

Hi,
The new trickbot variant
(SHA256: 374ef83de2b254c4970b830bb93a1dd79955945d24b824a0b35636e14355fe05)
spawns 4 instances of svchost.exe

the 2nd instance contains the new password grabbing module (pwgrab32)
I run: pesieve-32.exe /pid PID_OF_SVCHOST /imp
version is 0.1.6 (x86) and I run it on windows 7 32-bit.
It indeed dumped the dll located at 0x10000000 but it was missing its imports. I tried with the various dump modes but none of them helped to solve the issue.

I tried to do the same operation with Process-Dump (https://github.com/glmcdona/Process-Dump) and it worked just fine - imports were successfully reconstructed.

In the zip file below you can find the new trickbot variant, along with the relevant dumps of both pesieve and process-dump. password is: trickbot

https://ufile.io/x7oyw

When silent mode is enabled in the DLL form of PE-Sieve, scanning certain processes still results in output (shown below).

When using the dll in other projects, it may be desirable to completely suppress output and provide error information through the API.

Add a parameter allowing to make a minidump of the process detected as suspicious.

Hi,
I am currently experimenting with pe-sieve for detection of various DLL injection methods. but I have found it is able to detect only the reflective DLL injection. What about the other mode of DLL injection - such as using -a) CreateRemoteThread, b) NtCreateThreadEx etc. How pe-sieve can be used to detect those things.

thanks,
Sima

Test case

4c85fce4f7630dda213bafc2f842dd131dfc5f087be7c6a75f4ad2ca378904d0

Problem

Crash happens during scanning the main module:

Comment

The layout of sections in this sample is atypical - it can possibly be the reason of invalid parsing:

Allow to exclude known hooks from the detection. Hooks should be defined in an external configuration file, easily readable and editable for humans.

Test case

633521d921ddad8671293319f0fd9daab9a0a606887ada3ab3709027cbb1e591

Problem

The payload has a partially corrupt header (starting from file header):

PE-sieve was able to find some artefacts:

However, if failed to reconstruct the PE.

Hello! I designed a logo for PE-SIEVE. I hope you like it.
I'm waiting your feedbacks for sending original/editable/.png version of logo design or for improve it.
I can change colors or add something you wanted on design! Have a good day!

If the DEP is disabled for the process, shellcode can be also executed from a non-executable page.

PE-sieve should be able to detect what DEP policy applies on the particular process, and if needed, scan non-executable pages.