• Introducing Exphash: Identifying Malicious DLLs With Export Hashing

    Export Hashing (”exphash”), inspired by Mandiant’s imphash, is a SHA-256 hash of ordinal-ordered export names in PEs. Tracking DLLs which are used in search-order hijacking can sometimes be tricky. They may have a partial Export Address Table compromising of a dozen functions that exist in the legitimate equivalent, or simply the target function they wish to invoke. Greg Lesnewich published a partial version of a Export Hash using YARA, which took into account the whole table.

  • Inside Windows Defender System Guard Runtime Monitor

    What is System Guard Runtime Monitor? (SGRM)

    System Guard Runtime Monitor (SGRM) is a component of Windows Defender (WD), that was introduced in the Windows 10 1709 update and has been present since as a key component to ensure system integrity.

  • Stealthy Process Communication Between Threads on Windows 10

    Stealthy Process Communication Between Threads on Windows 10

  • Weaponizing Windows Sandbox To Bypass Defender

    Weaponizing Windows Sandbox

    Introduction

    I've not posted on here since May, as I've been busy with (well, life in general) projects and whatnot. This short blog post may be useful for a Red Team by living-of-the-land for the execution of payloads on a machine where Windows Sandbox can be enabled; Windows Sandbox is designed to work this way - no exploitation of anything is covered in this post. With this technique in terms of executing within a VM, we don't need to load an external ISO onto the machine, as all of this is handled by the sandbox. From my visibility, .wsb was not inspected or blacklisted on any major EDR or AV.

  • Fuzzing YARA for fun and no profit

    I've always been interested in fuzzing YARA to see if anything interesting would be produced. Whilst I didn’t manage to crash YARA when following the methodology that this post outlines whilst targeting the PE module – it'd be great to hear recommendations on how the process I followed upon could be improved on that I’ve made in my YARA fuzzing venture. We'll be using the excellent american fuzzy lop (a.k.a. "AFL") as the choice of fuzzer. If we were to find a parsing bug in YARA, it could possibly lead to code execution if a victim (in this case) runs our specially crafted executable through it. Fuzzing is a common method for finding vulnerabilities in software, in particular memory management vulnerabilities. It involves executing the target binary with various input values generated by the fuzzer, to test the program - the goal is to get it to crash.

  • Tampering with Zoom's Anti-Tampering Library

    Introduction

    This quick blog post highlights some of the flaws found in the Zoom application when attempting to do integrity checking, these checks verify that the DLLs inside the folder are signed by Zoom and also that no 3rd party DLLs are loaded at runtime. We can trivially disable this DLL, by replacing it with our own or simply unloading it from the process.

  • Writing a simple deobfuscator for a simple C# malware variant

    Introduction

    When a threat actor wishes to circumvent analysis from a reverse engineering standpoint, a common technique utilised by the attackers is to obfuscate their malicious code. This can be done in several ways and may include control flow obfuscation (making the flow of the program confusing, random jumps..), string obfuscation (not having text in plain sight, may be encrypted, encoded..), junk code (pointless code which does nothing, merely a way to confuse analysts), object renaming (renaming objects within the code from their original, e.g. MainService may become OQuXiqmXq throughout the code). To get around this, you can create your own tooling to deobfuscate binaries and strip them of these circumventions automatically. This is easier to achieve when managed code is involved as they're typically much more comfortable to manipulate, for .NET we've got dnlib, and for Java, we have ASM.

  • Comprehensive walkthrough of the LTDH19 RE challenges

    Introduction

    This year for ENUSEC's LTDH ("Le Tour Du Hack") I was tasked with writing the reverse engineering challenges needed for the CTF aspect of the event. Last year I also wrote the reverse engineering challenges which were used, so built on the feedback that I received. However, this year I attempted to make the challenges a bit easier to capture the interest of contestants that were new to the field. If you've got any questions feel free to pop me a message on Twitter @LloydLabs or e-mail [email protected].

  • A quick look at Windows API obfuscation via hashing

    Windows API resolution via hashing

    Although this method of API obfuscation is relatively old, my friend who was wanting to increase his skills in the Windows sphere confronted me about a way a few malware families seem to resolve APIs. It's pretty simple, however he could not find any documentation with a solid programming example on the matter at the time, so I thought I'd quickly write something up regarding it. I was going to write my own loader for this example (loading the desired module via LdrLoadDll within kernel32.dll, walking the InMemoryOrderModuleList to find the desired loaded module, finding the exported function we're after within the EAT..) - however I thought this might of have been a bit overkill for such a simple concept, I want to cover writing your own PE loader in the future though as it's an interesting subject.

  • Walkthrough of my Regime entry-level CTF challenge

    Regime walkthrough

  • [Part 1] - Analysing the new Linux/AES.DDoS IoT malware

    As the title suggests this is a bot which is spread by brute forcing SSH daemons and exploiting IoT devices using an array of exploits — this malware is mainly distributed by a Chinese actor who is familiar with C++ and C constructs, however the knowledge of C++ by this threat actor only extends to using the std::string class in C++. This bot was being distributed a few years ago just for x86_64 targets, this has changed along with some key fundementals of the bot. It's started to target embedded systems, which is why I thought I would cover it again. Linux/AES.DDoS is programmed in C++, we can see this due to the fact that all of the symbols are exported and C++ constructs are used.