Sectional MD5 - One of the ways for detecting the malware:

 In windows malware analysis, as a malware analyst we usually employs several ways to perform our analysis. The key is to understand what the malware is doing and we need to classify according to the behavior or artifacts which matches with the existing malware family or attackers toolset. In malicious file detection, the companies comes up with writing detection logic for addressing malware campaigns and if new malware set comes in the wild, the detection logic matches then the new files might be detected. Malware authors keep pushing new techniques for evasion and tries to propagate further. In this article, we are not going to see any evasion techniques but we going to see one of the old detection method, we can say the generic signature used by many AV engines to detect the malware, the method is referred as Sectional MD5.

Basically, MD5 is popular hashing algorithm which is to check integrity of the message or a file. For example, if two parties one is sending a message and another one is receiving, that message can be converted in to hash. Consider this, if the server stores a file and client is downloading the file. Server already shared the hash of the file, in our case MD5 hashing algorithm. After client downloads the file, they can calculate the hash of the file, and check whether both the files are same. Hashing algorithms are irreversible. One can generate the hash for a message or a file, but can't reverse it back to the original. Totally for integrity check only. SHA1, SHA256 are popular like MD5 hash. For a note, remember MD5 is prone to collision, we can talk about collision in some other posts.

Every PE files has sections and using any PE tools like PE bear, filealyzer, PEStudio we can determine the hash of the sections present in the files. When a malware researcher given the task to create generic signature, the researcher can compare the samples and found that one section which has malicious code and also it has the same hash in the all the given samples. Now the researcher can write the logic, if any of the section found with this particular MD5, it can be detected as malware. This technique is called as sectional MD5. So a common question is if one single byte changes in that section then the whole sectional MD5 will be collapsed and new hash will be generated. Easily the malware escapes the detection. Most of the times, the sections will not have same hash in the malware samples but still have the same behaviour and codes. It is something like single byte change or assembly logic change. In this scenario, how we can play? 

While debugging, we could spot the malicious call and the same call with same bytes found in the other files. Collect the bytes and locate the bytes in the file at disk; calculate the hash for those bytes which can be supplied as sectional MD5. In previous case, we mentioned about hash of the whole section. And in this case, sectional MD5 got created for the suspicious or malicious call subroutine found in the file. 

We got so many advance techniques for detection writing in practice, but sectional MD5 is known lesser now and even many don't know whether their engine has such capabilities. In the future posts, we will cover similar detection writing techniques and malware analysis related techniques. 

Kindly Note: This post is not generated by AI, and it is written by human; so please share it maximum and help us to write further. Your support needed. Our focus is to create high quality article in malware analysis field without using any AI. 

Post by

newWorld

RomCom’s Deliciously Simple Anti-Sandbox Trick

Not every evasion technique needs to be fancy. Some are so simple they’re almost… elegant. That’s the case with the Russian RomCom group, who’ve been running with a registry check that feels almost too obvious to work — and yet it does.

Before the Payload, a Quick Reality Check

RomCom’s initial downloader doesn’t rush to pull down second-stage malware. Instead, it pauses to ask: “Am I really on a victim’s machine, or am I trapped inside some analyst’s sandbox?”

The way it answers this question is by poking at a very ordinary spot in the Windows Registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs

The Recent Documents as it appears from its name Petrac records the number and types of files opened by the user. If the downloader finds that it has less than a certain number (in 2024 it was 100, and from a month it was downloaded to 69), then it will be understood that this is not a normal user device (because it doesn't open files!), but a sandbox, and it is locked without completing the download of the rest of the malware.

Why It Works

• It’s dirt simple. No advanced code injection, no kernel gymnastics. Just reading a registry value.

• It blends in. A single registry check doesn’t set off many alarms.

• It nails the target. Most sandboxes don’t bother faking user behavior at the level of “open 100 random files.”

And that’s the beauty of it.

The Takeaway

RomCom is a reminder that adversaries don’t always need to reinvent the wheel. Sometimes, the most effective anti-analysis check is hiding in plain sight, built around the fact that humans use their machines very differently than sandboxes do.

For defenders and sandbox builders: if your environment doesn’t look “lived in,” you’re going to miss tricks like this.

Reference articles:

https://www.welivesecurity.com/en/eset-research/update-winrar-tools-now-romcom-and-others-exploiting-zero-day-vulnerability/

https://unit42.paloaltonetworks.com/snipbot-romcom-malware-variant/

Post by

newWorld

Analysis of AsyncRAT Campaign

AsyncRAT (Asynchronous Remote Access Trojan) is a type of malicious software designed to give attackers remote control over an infected computer. Unlike other types of malware that require constant communication with the attacker’s system, AsyncRAT operates asynchronously, meaning it can send and receive data without needing a continuous connection. 

What AsyncRAT actually do: 

● Remote Control: It allows cybercriminals to control the infected system, enabling them to execute commands, access files, and even take screenshots. 

● Data Theft: AsyncRAT can steal sensitive information, such as login credentials, personal files, or confidential data. 

● Keylogging: The malware may include keylogging features to capture the victim's keystrokes, potentially revealing passwords and other private details. 

● Persistence: Even after restarting the system, AsyncRAT can remain active, giving attackers ongoing access to the machine. 

● Stealth: The Trojan is often designed to be hidden from security software and system monitoring tools, making it difficult to detect. 

Infection Chain: 

The infection process begins with a PowerShell script, which is initially delivered in a base64-encoded format. This encoding is used to evade detection by security tools and filters. Once the script is decoded and executed, it performs a series of actions: 

Stage 1: PowerShell (.PS1) Script 

Stage 2: Batch (.bat) File 

Stage 3: MSIL (.Net) Framework

Initial Vector PowerShell (.PS1) Script: 

PowerShell is often used in attacks because it is a powerful scripting language built into Windows, allowing attackers to execute commands without needing additional malware. Its ability to run base64-encoded scripts helps bypass detection and evade traditional security measures. 

The PowerShell script is delivered in a base64-encoded format to bypass detection systems. Upon execution, the script decodes itself back into its original form, which contains instructions to drop additional files onto the system. 

Hard-Coded PowerShell Script: 

Hard-Coded Batch Script:

Dropped DOS batch File: 

Once decoded, the PowerShell script proceeds to drop a batch script (.bat file) onto the infected system. The batch file contains specific commands that are designed to be executed automatically upon execution. 

The batch script is triggered by the PowerShell script and runs without user interaction. This batch script is responsible for executing further actions, such as making changes to system settings or preparing the system for the next stage of the attack. 

Payload .NET Executable: 

One of the primary functions of the batch script is to download a malicious payload from a remote server or location. This can be an executable file that will compromise the system. The payload may be malware, ransomware, or another type of malicious software, depending on the attacker's objective. 

"LoadOP" refers to a type of malware or trojan designed to load additional malicious payloads onto an infected system. It acts as a loader or dropper, enabling the delivery and execution of further malware after compromising the target system. Cybercriminals often use such tools to bypass security defenses by

first deploying a small, less detectable payload (like LoadOP), which then downloads or loads more damaging malicious software. 

Embedded Windows API Strings: 

LoadLibraryA is a Windows function that loads a DLL into a process's memory, allowing the application to access the functions within that DLL. 

On the other hand, "LoadAPI" is a broader term referring to the technique of dynamically loading external APIs or code. While not a specific Windows function, it is used in both legitimate software and malicious activities. Malicious software often exploits functions like LoadLibraryA to inject harmful code or load malicious DLLs into legitimate processes, which is why these terms are frequently discussed in malware analysis.

Indicator of Compromise (IOCs): 

Indicators of Compromise (IOCs) are forensic data points used to identify potential security breaches or malicious activity, such as IP addresses, file hashes, or suspicious URLs. They help detect, investigate, and respond to cyber threats.

MITRE Attack Framework: 

ID	Tactic	Technique
TA0001	Initial Access	Spam Email Phishing Attachment (.ps1)
TA0002	Execution	Windows Scripting (.bat)  Native APIs
TA0003	Persistence	DLL Side Loading  Logon Initialization Scripts  Windows Services (.net)
TA0004	Privilege Escalation	Process Injection  DLL Side Loading
TA0005	Defense Evasion	Disable or Modify Tools  Virtualization/Sandbox Evasion  Process Injection  DLL Side Loading
TA0007	Discovery	Security Software Discovery  System Information Discovery  Application Window Discovery  Virtualization/Sandbox Evasion
TA0009	Collection	Archive Collected Data
TA00010	C&C Server	Encrypted Channel  Non-Standard Port Ingress Tool Transfer  Non-Application Layer Protocol

Post by

newWorld

Hal9th - Windows defender : Anti-emulation check?

 Recently I found a LinkedIn post about mentioning of 'Hal9th' as the computer name and 'John Doe' as the username in windows defender anti-malware sandbox. If the malware goes into the windows defender sandbox or emulator, the environment gives the feeling there is an user and a machine. In the normal scenario, malware does exhibit the behaviour. In terms of anti analysis or sandbox aware techniques, the malware can employs the technique to detect this condition of "if computer name==Hal9th or user name==John Doe" then it exit the process; which in turns no behaviours captured. 

Referene: https://www.linkedin.com/posts/sheik-mohamed-4b49b231_if-a-malware-checks-for-the-machine-name-activity-7353790068542631949-9HZ8

And I really liked the reference to '2001- A space odyssey' which is a brilliant movie and if we rank the movie on science or space exploration, this one will be ahead of interstellar. 

Typically, a malware authors know the AV environment as like a malware researcher. So that they able to play the game as far as they can.

Post by

newWorld

BitLocker’s Hidden Flaw – Protect Your Laptop Now!

 Your laptop’s data is like a treasure chest, and Microsoft’s BitLocker is the lock keeping it safe. BitLocker scrambles your files so thieves can’t read them, even if they steal your device. It’s meant to be super secure, especially with a chip called the TPM that acts like a secret vault for the key. But a new trick called “Bitpixie” shows this lock isn’t as strong as we thought, according to a fascinating article from Compass Security. Here’s what you need to know!

The Bitpixie flaw (aka CVE-2023-21563) is like a skeleton key for BitLocker. During startup, Windows accidentally leaves the master key in the laptop’s memory. An attacker with a few minutes of access can grab it and unlock your data—no password needed! They do this by rebooting your laptop with a network cable plugged in, tricking it into using an older, less secure startup mode. Using a custom Linux or mini-Windows system, they snag the key in about five minutes. Scary, right?

This flaw has been around since 2005 but was only found in 2022. Microsoft’s working on a fix, but it won’t be fully rolled out until 2026. If your laptop uses BitLocker without a startup PIN or password (common in Windows 11), it’s at risk.

How to Stay Safe:

Add a PIN or password to BitLocker in Windows settings. It’s like a second lock!

Disable “PXE booting” in your laptop’s BIOS to block the attack.

Never leave your laptop unattended in public.

This Bitpixie trick is a wake-up call: even strong locks can have weaknesses. Check out Compass Security’s article for more details, and lock down your laptop today! Reference: https://blog.compass-security.com/2025/05/bypassing-bitlocker-encryption-bitpixie-poc-and-winpe-edition/

Post by

newWorld

How Malware Uses GetThreadContext() to Detect Debuggers – And How to Bypass It?

 

Introduction

In the world of malware reverse engineering, understanding how malware detects debuggers is crucial. One of the most common techniques is using GetThreadContext() to check hardware breakpoints stored in debug registers (DR0–DR3).

Malware authors use this method to terminate execution, alter behavior, or even delete itself if a debugger is detected. In this blog post, we'll break down how malware leverages this API and explore techniques to bypass it.

Understanding the API GetThreadContext()

🔹 What is really the GetThreadContext()?

GetThreadContext() is a Windows API function that retrieves the execution state of a thread, including register values and debug information.

BOOL GetThreadContext(

    HANDLE hThread,   // Handle to the thread

    LPCONTEXT lpContext // Pointer to CONTEXT structure

);

Here we need to understand the two things:

• hThread: A handle to the target thread.

• lpContext: A pointer to a CONTEXT structure that receives register values, including debug registers (DR0–DR3).

Debug Registers (DR0–DR3)

• These registers store hardware breakpoints.

• When a breakpoint is set, an exception is raised when the address is accessed.

• Malware checks these registers; if non-zero values are found, a debugger is present.

How Malware Uses GetThreadContext() to Detect Debuggers

CONTEXT ctx;

    ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;  // Retrieve debug registers only

    HANDLE hThread = GetCurrentThread(); // Get handle to the current thread

    if (GetThreadContext(hThread, &ctx)) {

        if (ctx.Dr0 || ctx.Dr1 || ctx.Dr2 || ctx.Dr3) { // Check for hardware breakpoints

            printf("Debugger detected via hardware breakpoints!\n");

            return 1; // Exit or change behavior

        } else {

            printf("No debugger detected.\n");

        }

In this code, you might get doubts since there is no check for values in the registers. Suppose if there is no breakpoints been set then it will be zero and if there is a non zero will be there then the detection of hardware breakpoints will be triggered. 

Understanding the Logic

• Bitwise OR (||):
  • The || operator in C is a logical OR. It evaluates expressions from left to right and returns true (non-zero) if any of the expressions are true.
  • In the context of integers, any non-zero value is considered true, and zero is considered false.
• Debug Register Values:
  • The debug registers (DR0, DR1, DR2, DR3) hold memory addresses and control bits related to hardware breakpoints.
  • If a hardware breakpoint is set, the corresponding debug register will contain a non-zero value.
• The Check:
  • Therefore, if (ctx.Dr0 || ctx.Dr1 || ctx.Dr2 || ctx.Dr3) essentially asks: "Is DR0 non-zero OR is DR1 non-zero OR is DR2 non-zero OR is DR3 non-zero?"
  • If any of the debug registers have a value other than zero, the entire if condition evaluates to true, and the code inside the if block is executed.

In simpler terms:

• If all DR0, DR1, DR2, and DR3 are zero, the if condition is false.
• If even one of those registers has a value, the if condition is true.

• Hardware breakpoints require the debug registers to store specific values. A zero value in a debug register generally means no hardware breakpoint is set for that register.
• By using the logical OR operator, the code elegantly checks if any of the debug registers contains a value that indicates a hardware breakpoint.

Therefore, although it does not use a "==0" comparison, the logical OR of the registers themselves, is enough to test for any non zero value.

How to Bypass This Anti-Debugging Check

Reverse engineers and malware analysts use various methods to evade this detection.

🔹 (A) Manually Clear Hardware Breakpoints

🔹 (B) Hook GetThreadContext() to Return Fake Data

🔹 (C) Use a Stealth Debugger (HyperDbg)

        - Instead of user-mode debuggers (which expose breakpoints), use a hypervisor-based debugger like HyperDbg, which operates at the virtualization level.

✅ Advantage: Malware running inside a VM cannot detect hardware breakpoints.

Other Debugging Evasion Techniques Malware Uses

Apart from GetThreadContext(), malware often employs:

• CheckRemoteDebuggerPresent() – Checks if a debugger is attached.

• NtQueryInformationProcess(ProcessDebugPort) – Determines if a process is being debugged.

• NtSetInformationThread(ThreadHideFromDebugger) – Hides threads from debuggers

Final Thoughts

The GetThreadContext() technique is a powerful anti-debugging method used by malware, but as analysts, we have multiple ways to bypass or neutralize it.

✅ To Defeat Debugger Detection:

• Clear hardware breakpoints using SetThreadContext().

• Hook GetThreadContext() to modify return values.

• Use a stealth debugger like HyperDbg.

Would you like a real-world example of a packed malware sample using this technique? Drop a comment below! 🚀

post by

newWorld

Understanding GetThreadContext(): Peeking Inside a Thread's Soul

 In the world of Windows programming, threads are the workhorses that allow applications to perform multiple tasks concurrently. But what if you need to examine the inner workings of a thread? That's where the GetThreadContext() function comes into play.

What is GetThreadContext()?

GetThreadContext() is a powerful Windows API function that retrieves the context of a specified thread. In simpler terms, it allows you to get a snapshot of a thread's state, including its registers, stack pointer, and program counter. This information is crucial for debugging, profiling, and even implementing certain security measures.

How Does it Work?

The function takes two main parameters:

1. HANDLE hThread: A handle to the thread whose context you want to retrieve.
2. LPCONTEXT lpContext: A pointer to a CONTEXT structure that will receive the thread's context.

The CONTEXT structure is a large and complex structure that contains all the information about a thread's state. You can specify which parts of the context you want to retrieve by setting the ContextFlags member of the CONTEXT structure. For example, you can retrieve only the debug registers, floating-point registers, or all registers.

Use Cases:

• Debugging: Debuggers heavily rely on GetThreadContext() to inspect the state of threads and identify errors. They can examine register values, stack traces, and other information to understand what a thread is doing.
• Profiling: Profilers use GetThreadContext() to collect performance data about threads. They can track how often threads are running, what instructions they are executing, and how much time they are spending in different parts of the code.
• Anti-Debugging: Some security software uses GetThreadContext() to detect debugging attempts. By checking for specific values in the debug registers, they can identify if a debugger is attached to the process.
• Hardware Breakpoints: As we discussed before, GetThreadContext() in conjunction with the CONTEXT_DEBUG_REGISTERS flag, is how you can read the values of DR0-DR3.
• Custom Thread Management: In advanced scenarios, you might use GetThreadContext() to implement custom thread management logic, such as saving and restoring thread states.

Sample Program in C:

#include <windows.h>
#include <stdio.h>

int main() {
    CONTEXT ctx;
    ctx.ContextFlags = CONTEXT_ALL; // Retrieve all registers

    HANDLE hThread = GetCurrentThread();

    if (GetThreadContext(hThread, &ctx)) {
        printf("EIP: 0x%X\n", ctx.Eip); // Example: Print the instruction pointer
        // ... access other registers from the ctx structure ...
    } else {
        printf("Failed to get thread context.\n");
    }

    return 0;
}

Important Considerations:

• Permissions: GetThreadContext() requires THREAD_GET_CONTEXT access to the target thread.
• Security: Be cautious when using GetThreadContext() in production code. It can expose sensitive information about your application's internal state.
• 64-bit vs. 32-bit: The CONTEXT structure differs between 32-bit and 64-bit systems. Make sure you are using the correct structure for your target architecture.
• Context Flags: using the proper context flags is essential for performance, and to avoid errors. Do not retrieve data you do not need.

Conclusion:

GetThreadContext() is a powerful tool for inspecting the state of threads in Windows. Whether you are debugging, profiling, or implementing advanced security measures, understanding how to use this function is essential for any Windows programmer. I hope this blog post has given you a helpful overview.

Post by

newWorld

Dissecting a Stealthy Malware: A Step-by-Step Reverse Engineering Guide

 Introduction

In today’s cybersecurity landscape, malware authors continue to refine their evasion techniques, making detection and analysis more challenging. In this post, we will take a real-world malware sample, analyze its behavior, and reverse-engineer its functionality. Whether you are a beginner in malware analysis or a seasoned professional, this guide will provide actionable insights to enhance your reverse engineering skills.

Step 1: Identifying the Malware Sample

Before diving into deep analysis, we need to collect information about the malware.

1.1 Collecting the Sample

• Source of the Sample: Malware can be found in phishing emails, malicious attachments, drive-by downloads, or suspicious executables flagged by endpoint security solutions.
• Hashing & Storage: Before analysis, calculate MD5, SHA1, and SHA256 hashes for identification and comparison. Use a dedicated malware repository like MalwareBazaar or VirusShare.

1.2 Preliminary Static Analysis

• Using VirusTotal: Upload the sample to VirusTotal to check existing detections and related metadata.
• File Type & Structure: Use the file command or PEStudio to determine if it’s a PE file, script, or packed binary.
• Analyzing PE Headers: Look at compilation timestamps, import tables, and suspicious section names using tools like CFF Explorer.

Step 2: Static Analysis Without Execution

Static analysis helps in extracting useful insights without running the malware.

2.1 Checking Strings

• Use strings (Linux) or BinText (Windows) to identify hardcoded URLs, commands, or suspicious file paths.
• Watch for obfuscation techniques like XOR encoding or base64-encoded payloads.

2.2 Inspecting Imports & Exports

• Tools like PEView and PEStudio help determine API calls related to process injection, network connections, or persistence mechanisms.
• Look for functions like CreateRemoteThread, WriteProcessMemory, or LoadLibrary that indicate possible code injection.

2.3 Identifying Packing & Obfuscation

• Run Detect It Easy (DIE) or PEiD to check for UPX or custom packers.
• If packed, use UPX -d to unpack standard UPX-packed files.

Step 3: Dynamic Analysis (Executing in a Safe Environment)

To observe runtime behavior, we execute the sample in a controlled environment.

3.1 Setting Up a Safe Environment

• Use FlareVM, REMnux, or Cuckoo Sandbox to analyze malware in an isolated VM.
• Disable internet access to prevent real-world impact but use tools like INetSim to fake network services.

3.2 Behavioral Monitoring

• Use Procmon to track file modifications and registry changes.
• Wireshark captures network traffic to identify command-and-control (C2) communications.
• Regshot compares registry states before and after execution to spot persistence mechanisms.

3.3 Identifying Persistence Mechanisms

• Look for malware creating autorun registry entries (HKLM\Software\Microsoft\Windows\CurrentVersion\Run).
• Check for scheduled tasks (schtasks /query) or service installations.

Step 4: Code Disassembly & Debugging

Code disassembly and debugging are essential techniques in reverse engineering and software analysis, used to understand the inner workings of a program, identify vulnerabilities, or analyze malware. Disassembly involves converting machine code into a human-readable assembly language using tools like IDA Pro, Ghidra, or Radare2, allowing analysts to examine program logic and behavior. Debugging, on the other hand, involves executing the program step-by-step using debuggers like GDB, WinDbg, or LLDB to inspect registers, memory, and function calls in real time. These techniques help security researchers, malware analysts, and software developers detect and fix issues, bypass protections, or gain insights into proprietary or malicious code. For deeper insights, we analyze the malware’s code. Breakpoints are handy to spot the perfect code area which the researcher really looking: https://www.edison-newworld.com/2024/05/setting-up-breakpoints-in-virtualalloc.html

4.1 Disassembly with Ghidra or IDA Pro

• Identify key functions, loops, and suspicious API calls.
• Use function cross-referencing to understand execution flow.

4.2 Debugging with x64dbg or OllyDbg

• Set breakpoints to inspect decryption routines and C2 communications.
• Look for anti-debugging techniques like IsDebuggerPresent or CheckRemoteDebuggerPresent.

4.3 Extracting Decrypted Payloads

• Identify encrypted sections and use memory dumping tools like Scylla to dump unpacked code.
• Analyze dumped binaries separately to uncover secondary payloads.

Step 5: Extracting IOCs (Indicators of Compromise)

After thorough analysis, extract key artifacts:

5.1 File Hashes & Artifacts

• Collect MD5, SHA256, and file paths for tracking across security platforms.
• Identify and extract dropped files from the system.

5.2 Network Indicators

• Capture C2 domains, IP addresses, and DNS queries.
• Use tools like Fakenet-NG to simulate network responses and observe malware behavior.

5.3 YARA Rules for Detection

• Write detection rules using YARA to classify similar malware samples.
• Example rule:

rule ExampleMalware {

    strings:

        $a = "malicious_string" nocase

    condition:

        $a

}

Real-World Case Study: Dissecting a VB6 RAT

Background

A recent malware sample written in VB6 was identified, using msvbvm60.dll for execution. Upon analysis, we found:

• API calls related to keylogging (GetAsyncKeyState).
• Registry-based persistence in HKCU\Software\Microsoft\Windows\CurrentVersion\Run.
• XOR-encrypted network communication to an external C2 server.

Conclusion

Reverse engineering malware is a critical skill for cybersecurity professionals. By following these structured steps, you can gain a deeper understanding of how modern threats operate and develop stronger detection and mitigation strategies.

Next Steps

🚀 Want to practice? Download sample malware from MalwareBazaar or VirusShare (safely in a VM).
💬 Have insights or questions? Drop them in the comments below!