ARISTODE

Steps Taken:

• Reviewed entrypoint start (0x401380) and noted immediate stack setup plus helper invocations; recognized RC4/XOR helpers (fill_buffer, rc4_init_state, xor_dword_table) driving string decryption.
  • Traced module discovery via find_module_entry/get_module_base_address; confirmed ntdll.dll name emerges after RC4 at start:0x40146f using key from xor_dword_table.
  • Observed manual export resolution through resolve_export_by_name (0x402450) and unicode compare helpers, with first API decrypted as NtQueryVirtualMemory (start:0x4014a1 ➜ start:0x40156e).
  • Confirmed NtQueryVirtualMemory invoked at start:0x4015bf (call [ebp-0x20]) against code address 0x4015be; results stored in local MEMORY_BASIC_INFORMATION, flag 0x40 used to gate execution (anti-hook check).
  • Logged secondary RC4 cycle at start:0x4015e0 resolving another export pointer saved to [ebp-0x60], later referenced while staging payload protection changes.
• Inspected decrypt_payload_stage (0x401C10) and noted embedded

ARISTODE

{
  "sample_path": "/Users/yohuang/Downloads/malwares/NtHook.exe",
  "analyzed_at": "2025-11-04T07:31:58.539184Z",
  "verdict": "suspicious",
  "confidence": 0.59,
  "summary": "Verdict SUSPICIOUS from 35 evidence items (pattern=0, high=0, medium=21, low=14; max_conf=0.60, avg_conf=0.50; coverage=0%).",
  "reasoning_summary": {
    "purpose": "A Windows driver of unknown purpose, possibly intended to interact with specific user-mode processes.",
    "malware_class": null,
    "narrative": "This sample is a Windows driver, identified by its `DriverEntry` export and imports from `ntoskrnl.exe` [baseline_static_metadata-imports]. Its purpose is unclear, but it contains strings referencing several user-mode executables, including 'safemon.dll' and 'CORAL.EXE', suggesting it may be designed to monitor or interact with these specific processes. However, the analysis found no concrete evidence of malicious behavior. Automated checks for common rootkit techniques, such as registering process creation callbacks via `P

ARISTODE

• Investigation Log

• Connected to IDA session, captured module hashes, enumerated exports (DllEntryPoint, Crash) to frame analysis scope.
• Decompiled Crash → LaunchConfiguredIec104Sessions:0x100014e0, observed config parsing call and thread fan-out via CreateThread (0x10001547), then traced worker entry StartAddress to identify IEC‑104 workflow.
• Analyzed ParseIec104ConfigFile:0x10001610; confirmed _wfopen (0x10001674) and _fgets usage, mapped keywords target_ip, target_port, sequence, stop_comm_service, command_type, operation, shift, range, uselog at refs 0x100017B0–0x10002004 to per-session structure fields.
• Inspected RunIec104SessionWorker:0x10002FE0; documented service-kill logic (OpenProcess 0x1000303D / TerminateProcess 0x10003046), IEC-104 connect (Iec104Connect 0x10003079), handshake (SendStartupSequence 0x1000309D), sequence dispatch (range 0x1000315D, shift 0x100031AE) and command emission (IssueSingleCommand calls at 0x1000331A/0x1000335E/0x100034E6/0x10003507).
• Reverse engineere

ARISTODE

• Step 1: Reviewed DriverEntry (0x140001000) to record the device pair \Device\KApcHelper1 / \DosDevices\KApcHelperLink1, blanket dispatch table, and registration of ProcessCreateNotifyHandler plus a dummy thread notify hook.
• Step 2: Traced the init path into ResolveKernelApis (0x140001244) and LocateThreadFlagSetterPattern (0x1400014B0) to understand which kernel services and hidden thread helpers the driver depends on.
• Step 3: Decompiled DeviceControlDispatcher (0x140001B70) to map IOCTLs, uncover the handshake scheme, and note how every command is obfuscated by the HandshakeSeed.
• Step 4: Followed the command flow into HandleHandshakeSeed (0x140001124) to confirm token generation/validation and the use of HandshakeValidated as a global gate.

ARISTODE

In-memory loader decrypts and manually maps an embedded payload before handing execution to its DllMain.

Investigation Log

• Step 1: Confirmed IDA attachment to pikabot.exe and enumerated entry points (start at 0x49f3a2, TLS callback at 0x519630) to understand initial execution vectors.
• Step 2: Reviewed CRT startup at 0x49f22b and wWinMain_ManualLoaderEntry (0x519b8f) to see the real work funneled into ManualMapEmbeddedDll.
• Step 3: Checked TlsCallback_ProcessDetach (0x519630) and its thunk TlsCallback_CleanupThunk →

ARISTODE

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <jpeglib.h>
#include <setjmp.h>

// Structure to hold decoder state
struct decoder_state {
    struct jpeg_decompress_struct* info;
    struct jpeg_error_mgr* err;

ARISTODE

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>

// Define __user macro (in userspace, this doesn't have a special meaning)
#define __user

// Dummy functions to simulate kernel functions
static void might_fault(void) {

ARISTODE

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

// Dummy structures to represent kernel structures
struct device {
    // Simplified device structure
    int dummy;
};

ARISTODE

; ModuleID = 'alias.bc'
source_filename = "llvm-link"
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

%struct._IO_FILE = type { i32, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, i8*, %struct._IO_marker*, %struct._IO_FILE*, i32, i32, i64, i16, i8, [1 x i8], i8*, i64, %struct._IO_codecvt*, %struct._IO_wide_data*, %struct._IO_FILE*, i8*, i64, i32, [20 x i8] }
%struct._IO_marker = type opaque
%struct._IO_codecvt = type opaque
%struct._IO_wide_data = type opaque
%struct.KlvTag_t = type { i8, i32, i8*, %struct.KlvTag_t* }

ARISTODE

Call Path: napi_gro_receive->dev_gro_receive->napi_gro_complete->netif_receive_skb_internal->__netif_receive_skb->__netif_receive_skb_core->skb_vlan_untag->pskb_may_pull.2063->__pskb_pull_tail->pskb_expand_head->__kmalloc_reserve
  - kernel func (napi_gro_receive) | allocator (__kmalloc_reserve) | driver call site (ixgbe_rx_skb) - %17 = call i32 @napi_gro_receive(%struct.napi_struct* %15, %struct.sk_buff* %16) #11, !dbg !281511

Call Path: netif_receive_skb->netif_receive_skb_internal->__netif_receive_skb->__netif_receive_skb_core->skb_vlan_untag->pskb_may_pull.2063->__pskb_pull_tail->pskb_expand_head->__kmalloc_reserve
  - kernel func (netif_receive_skb) | allocator (__kmalloc_reserve) | driver call site (ixgbe_rx_skb) - %12 = call i32 @netif_receive_skb(%struct.sk_buff* %11) #11, !dbg !281507

Call Path: netif_set_xps_queue->kzalloc.1679
  - kernel func (netif_set_xps_queue) | allocator (kzalloc.1679) | driver call site (ixgbe_configure_tx_ring) - %170 = call i32 @netif_set_xps_queue(%struct.net_device* %16