Basics – process impersonation • Malware impersonates processes to run under their cover • Examples of the techniques: • Process Hollowing (RunPE) • Reflective DLL injection • Manual PE loading (various variants) • Process Doppelgänging • Combinations of multiple techniques (i.e. Transacted Hollowing)
Basics – new combinations of known techniques https://blog.malwarebytes.com/threat-analysis/2018/08/process- doppelganging-meets-process-hollowing_osiris/
Searching and preventing malicious implants • Malware authors/offensive researchers try to evade it by finding uncommon APIs that can be used to make injection. Some newer examples: • AtomBombing technique • Process Doppelgänging • What if some unknown API was used for injection?
Searching and preventing malicious implants • What if we want to scan a system post- factum? • How to detect and implant without knowing how it was injected?
Searching and preventing malicious implants • There are various applications that allow to detect some indicators, i.e. GMER (rootkits/hooking), RunPE detector • They don’t help collecting material for analysis • Some of them detect only the most popular variants of the implants – not robust enough to analyze new types of malware
Searching and preventing malicious implants • RunPE detector – detects typical RunPE – but not its modified versions https://www.youtube.com/watch?v=-8EJfvPo_yQ
Introducing PE-sieve • PE-sieve – works on a live system • Focus: speed and simplicity of use • Passive scan, not hooking any APIs • Can be used post-infection • Generates a material ready to be analyzed: not only detection, but precise details • Free & open source: https://github.com/hasherezade/pe-sieve https://github.com/hasherezade/hollows_hunter
What PE-sieve detects? • Inline hooks • Packed and self-modifying PE files • Replaced processes: i.e. Process Hollowing, Process Doppelganging • Manually loaded PE-files (Reflective DLL Injection and others) • Shellcodes
Inline hooking detection • Test case #1: a crackme with inline hooks • Report from PE-sieve The hooked/patched modue is automatically dumped Report about hooks
Simples ideas work... • It is very easy to detect code overwritten in memory by comparing it with the executable on disk • No impersonation technique is perfect: they all leave some suspicious artefacts
Detection: inline hooking, self-modifying code • Code scan • Load the PE from the disk that corresponds to the module withing the process • Detect all the sections containing code • Transform both sections into the same format (relocate to the same base, remove IAT, etc) • Compare
Detection: impersonated process • Headers scan • Load the PE from the disk that corresponds to the module withing the process • Are their headers matching? • When it works? • For all the techniques that rely on connecting the implanted PE to the PEB, in order to have imports automatically resolved
Detection: manually mapped PE / shellcode • Workingset scan • Search executable memory pages that are not a part of any module • Suspicious mapping type? Other indicators? • Are they part of a PE file? Detection of PE headers /artefacts
This is not a normally mapped PE... #1 https://github.co m/stephenfewer/ ReflectiveDLLInje ction [-] PE implanted into MEM_PRIVATE (vs typical: MEM_IMAGE) [-] RWX – very unusual protection
Detecting partially erased headers https://www.youtube.com/watch?v=dFJcGYUFB0s PE-sieve is still able to detect the remainings of the header and reconstruct the full PE
hshrzd
twada
ivargrimstad
pospome
uhooi
_tanako
lhespanha
adammc331
shimabox
yosuke_furukawa
taowata
ogiwarat
jrf
vanstee
addyosmani
maltzj
marktimemedia
rocio
bkeepers
marcelosomers
swwweet
sachag
destraynor
brad_frost
cromwellryan