re-behavior

Malicious Behavior Analysis

When to use / when not to use

• Use: to determine what a sample "is doing" — post-execution process/file/registry/network behavior; identify persistence and injection; ATT&CK tactic mapping
• Use: the evidence collection stage of dynamic analysis (complementary to [[re-tracing]])
• Do not use: the sample has not yet been run in a sandbox (first [[re-sandbox]] — dynamic execution is a mandatory prerequisite, see the highest principle in [[re-analyze/platform-tips]])
• Do not use: only static conclusions are needed (go to the [[re-triage]] / [[re-binary-core]] domain); only memory contents are needed (go to [[re-memdump]])

Tool preparation

This skill analyzes sandbox run artifacts — the run environment is first established by [[re-sandbox]] (default sandbox highest principle, see [[re-analyze/platform-tips]]).

Sandbox artifacts (run environment prerequisite)

• Established by [[re-sandbox]]: VM snapshot / container / firejail + network isolation (INetSim / fake DNS / network disconnected)
• Artifacts include: behavior logs, process snapshots, INetSim network records, memory dumps ([[re-memdump]])
• Verification: the sample in the sandbox has finished running per the [[re-sandbox]] steps and produced logs

procmon / Process Monitor (mainstay for Windows behavior recording)

• Windows: Microsoft Sysinternals —— choco install sysinternals, or download Procmon64.exe from the Microsoft website
• Linux/macOS: not applicable (use sysdig / bpftrace; for function-level recording see [[re-tracing]])
• Verification: run Procmon64.exe as administrator; a capture window appears and events can be recorded
• Additional: Process Explorer (same suite) to view the process tree and handles

sysdig (Linux system behavior tracing)

• Linux: apt install sysdig / dnf install sysdig / pacman -S sysdig
• macOS/Windows: not supported (Linux-only); the Linux version can be used inside WSL (requires root)
• Verification: sysdig --version；sysdig -c topprocs_cpu can output
• Common: sysdig proc.name=target -w out.scap record, then sysdig -r out.scap replay

bpftrace (Linux kernel-level tracing, low overhead)

• Linux: apt install bpftrace / dnf install bpftrace / pacman -S bpftrace
• Requires kernel BTF/tracing support; macOS/Windows not supported
• Verification: bpftrace --version；sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { print(comm) }' can print
• Purpose: high-frequency events such as file writes, process starts, network connections, lighter-weight than user-space monitoring

MITRE ATT&CK Navigator

• No installation needed: open in browser https://attack.mitre.org/matrices/enterprise/ or Navigator (https://mitre-attack.github.io/attack-navigator/）
• Local deployment (optional): git clone https://github.com/mitre-attack/attack-navigator, open the static page directly
• Verification: the page can be searched by tactic/technique

Windows/Linux built-in commands (persistence/network checks, zero installation)

• Windows: reg query、sc query、schtasks /query /fo csv、netstat -ano、Get-CimInstance Win32_StartupCommand
• Linux: ps -ef --forest、ss -tnp、cat /etc/crontab、systemctl list-unit-files --state=enabled
• Verification: each command can output normally

Operating steps

Execute in order, record the results of each step and save the evidence (path + sha256).

1. Process tree and injection identification：

   • Windows (run the sample while procmon is recording in the sandbox): filter Process Name = sample, use Process Explorer's Tree view to see the process tree — child processes, newly started processes after dropping to disk (dropper → payload two stages)
   • Injection characteristic sequence (procmon / sysdig filtering API):
     • DLL injection: OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread (target process is written to + new thread)
     • Process hollowing: CreateProcess(SUSPENDED) → NtUnmapViewOfSection → WriteProcessMemory → SetThreadContext → ResumeThread
     • APC injection: OpenThread → QueueUserAPC → ResumeThread
   • Linux: sysdig proc.name=target Look at the execve/clone sequence;ps -ef --forest look at the process tree
   • Record conclusions: injection target, injection technique, injected process PID

2. Persistence checklist(scheduled tasks/WMI are often overlooked, see pitfall 3):

   • Windows:

     reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
     reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run"
     sc query state= all
     schtasks /query /fo csv
     

     WMI persistence (most hidden): Get-CimInstance -Namespace root\subscription -ClassName __EventConsumer(ActiveScriptEventConsumer / CommandLineEventConsumer are common malicious points)
   • Linux: cat /etc/crontab、ls /etc/cron.d /etc/cron.daily、systemctl list-unit-files --state=enabled、/etc/rc.local、/etc/profile.d/*、~/.bashrc
   • Record each item: location, command/path, whether it is related to the sample

3. File and registry operations：

   • Windows: procmon filter Operation = CreateFile / WriteFile / RegSetValue / RegCreateKey, Process = sample; focus on %APPDATA%, %TEMP%, %ProgramData%, Startup folder
   • Linux: sysdig -c spy_file proc.name=target(file read/write); for function-level calls supplement with strace from [[re-tracing]]
   • Every recorded item counts as a potential IOC (configuration drop path, downloaded files) — for use by [[re-ioc]]

4. Network connections and C2 characteristics：

   • Windows: netstat -ano cross-check with procmon network events; sandbox DNS already points to INetSim ([[re-sandbox]] step 2) — DNS queries in the INetSim log are direct evidence of the C2 domain
   • Linux: ss -tnp、sysdig fd.type=ipv4 proc.name=target
   • C2 characteristic checklist: non-standard ports (>1024 or 443/53 masquerading), periodic heartbeats (fixed-interval short connections), DNS tunneling (long random subdomains), abnormal User-Agent, HTTPS to unknown IP with certificate mismatch
   • C2 discovered → hand traffic details to [[re-protocol]] ([[re-netcap]] / [[re-proto-rev]] / [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]])

5. ATT&CK tactic mapping：

   • Classify the behaviors from steps 1-4 by ATT&CK tactic: initial access, execution, persistence (T1547 / T1053 / T1543), defense evasion (T1055 injection), command and control (T1071 / T1568)…
   • For each behavior write one line: "behavior → tactic:technique (ATT&CK ID) → evidence path", compile into a mapping table for the report (for use by the [[re-ioc]] report structure)

Behavior monitoring toolchain (Windows)

The four-piece set for behavior collection on the Windows side: ProcMon (whole-system file/registry/network/process), API Monitor (API-level hook), ETW (kernel-side events), Process Explorer (real-time process view). The first two are user-mode collection; ETW is on the kernel side; this section is from the collection side perspective, complementing the bypass side of [[re-evasion]]. Unless noted otherwise, all are Windows-only tools; for Linux/macOS equivalents go to [[re-tracing]] (strace/ltrace/dtruss) and the sysdig/bpftrace in this file's "Tool preparation".

ProcMon: filter → annotate → CSV export

• Filtering (Filter dialog, Ctrl+L): rule = column + relation + value, multiple conditions stack; columns can be Process Name / Operation / Path / Result / PID etc.; relations support e.g. is / is not / contains / does not contain / begins with / ends with / less than / more than / excludes (numeric columns use magnitude comparison); right-click an event to quickly generate a rule (Add to Include filter / Add process and children to Include filter)
• Filtering is non-destructive: non-matching events are still stored, just not displayed; only when Drop Filtered Events is checked are they actually discarded (used for ultra-high-frequency capture to control size, unrecoverable — do not check it when a complete evidence chain is needed)
• Annotation: The Include rule highlights events of interest in yellow; Highlight (Ctrl+H) customizes highlight colors; Exclude grays out and filters out—layered reading of "highlight = focus, grayed out = noise"
• CSV export: File → Save (Ctrl+S), in the dialog choose CSV as the format and Events displayed using current filter as the range (filter first, then export, to control volume); for batch conversion use the command line Procmon64.exe /OpenLog trace.pml /SaveAs out.csv; native PML preserves all fields and thread stacks, allowing review on another machine
• Timeline correlation: sort by Time of Day, align Process Create / CreateFile / WriteFile / RegSetValue / TCP-UDP Send-Receive into the evidence chain "process → file → registry → network" (corresponding to operation steps 1-4); use the Process Tree tool (Ctrl+T) to see process parent-child relationships and injection paths
• The Stack tab of event properties gives the thread call stack (a symbol server can be configured); verify the injection/persistence API sequence (empirical evidence for step 1 and pitfalls 5-7)

API Monitor: API-level hook chain

• Purpose: hook in-process API calls via import table hooks, record parameters (strings already decoded) and return values call by call, and display nesting levels in a call tree—the Windows-side counterpart of [[re-tracing]]'s strace/ltrace
• Usage: run as administrator → select the target process → check API categories (File / Network / Registry / Process / Thread) → attach; expand the call tree to key APIs (CreateProcess / WriteProcessMemory / RegSetValue / NtWriteFile) to see actual parameter values
• Bitness limitation (common pitfall): the 32-bit version can only monitor 32-bit processes, and the 64-bit version can only monitor 64-bit processes—choose apimonitor-x86.exe / apimonitor-x64.exe according to the sample's bitness
• Installation: official channel rohitab.com (free software, v2 alpha, unzip and run); the site is occasionally unreachable, so verify the checksum after obtaining the archive
• Verification: after attaching to the target process, it can list the call tree and record parameters and return values

ETW: kernel-side event collection (logman / wevtutil)

• Purpose: Windows' built-in event framework; session creation and event parsing use built-in system commands (logman / wevtutil / tracerpt), zero installation; kernel-side collection is unaffected by user-mode hooks—injection that goes straight through syscalls (pitfall 8) can only be covered by kernel-side events

• Create a session (requires administrator):

  logman create trace bhev -p Microsoft-Windows-Kernel-Process 0x10 -o bhev.etl -ets
  logman stop bhev -ets
  logman delete bhev -ets
  

  -p specify a provider (name or GUID), optionally with keywords and level (e.g. -p Microsoft-Windows-Sysmon 0xFF 5); kernel providers must be given explicit keywords—Kernel-Process's 0x10 is the process keyword, and 0x20/0x40 are the thread/image keywords; otherwise it may silently collect zero events;logman query -ets view active sessions;logman query providers enumerate registered providers (pipe findstr to filter targets)

• Common providers: Microsoft-Windows-Kernel-Process (process creation/exit), Microsoft-Windows-PowerShell (script blocks), Microsoft-Windows-Sysmon (reuse its events directly when Sysmon is installed)

• Event parsing: convert .etl to CSV with tracerpt bhev.etl -o out.csv -of csv; for event logs use wevtutil:

  wevtutil qe Security /q:"*[System[(EventID=4688)]]" /c:10 /rd:true /f:text
  wevtutil el
  wevtutil epl Security C:\secevt.evtx
  

  /q is the XPath filter,/c is the maximum count,/rd:true puts the newest first,/f:xml|text is the output format

• Complementary to re-evasion: this section is the collection side; for the bypass side (ETW disabling and detection), see [[re-evasion]]

Process Explorer: real-time process view

• Process tree: View → Show Process Tree (Ctrl+T)—parent-child relationships and exited processes are retained in gray; complements ProcMon's Process Tree tool (PE for real time, ProcMon for reviewing recordings)
• Lower Pane: Handles (Ctrl+H) shows handles opened by the process (files/registry/network objects), DLLs (Ctrl+D) shows loaded modules and mappings — check whether an injected DLL has landed and which process is holding a deleted file; Hide Lower Pane (Ctrl+L) collapses it
• Find Handle or DLL (Ctrl+F): reverse-lookup the holding process by file/path/key — find who is reading or writing a given path
• Signature verification: after enabling Options → Verify Image Signatures, a Verified Signer column appears in the process list; the Verify button on the Image page of process properties checks a single process — quickly distinguish legitimate system modules from suspicious injected modules (missing/invalid signature is an alert, in conjunction with step 1)

Cross-OS Constraints

• The above tools (ProcMon / API Monitor / Process Explorer / logman-wevtutil) are all built into Windows or Windows-only; on Linux/macOS the equivalent goes through [[re-tracing]] (strace/ltrace/dtruss) and the sysdig / bpftrace from "Tool Preparation"
• Exception noted: ProcMon has an official Microsoft Linux reimplementation (ProcMon-for-Linux, GitHub microsoft repo, preview, syscall-level, eBPF-based), experimental; formal analysis still relies mainly on sysdig/bpftrace

Cross-Domain Joint

• [[re-malware]]: workflow step 3 — behavioral analysis is the core part of determining whether a sample is malicious
• [[re-sandbox]]: all execution and re-execution of this skill must be inside a sandbox (mandatory prerequisite)
• [[re-protocol]]: step 4 discovers C2 → move to traffic capture / protocol reconstruction
• [[re-anti-analysis]]: abnormal behavior (delays/interaction checks, exiting after detecting the sandbox) → move to the anti-analysis countermeasures domain
• [[re-tracing]]: on Linux use the strace family to supplement sysdig/bpftrace with function-level call records
• [[re-evasion]]: the ETW collection side (the "Behavior Monitoring Toolchain" section) is complementary to the bypass side — an interrupted event stream means disabled evidence
• [[re-ioc]]: the behavioral evidence produced in steps 3/4 is the raw material for IOC extraction and reporting

Common Pitfalls and Traps

• Behavior bypassed by sandbox detection: Symptom — the sample only performs harmless behavior in the sandbox or does nothing at all, and only activates on a real machine; Cause — sandbox detection (VM characteristics, interaction checks, delayed triggering, see [[re-sandbox]] pitfall 4 and the [[re-anti-analysis]] domain); Countermeasure — extend the observation window (hours to days), fake interaction (input/mouse events), pair with [[re-sandbox]]'s INetSim for full network, and if necessary use [[re-anti-analysis]] to statically recover the trigger conditions
• Looking only at the process tree misses injection: Symptom — the process tree contains only the sample itself, but the malicious behavior occurs in another process; Cause — an injection-type sample appears harmless in its own process, with the malicious logic executing in the host process; Countermeasure — must check the injection characteristic sequence (the API sequence in step 1); behavioral evidence is based on the memory and modules of the injected target process
• Persistence hidden in scheduled tasks/WMI is often overlooked: Symptom — the sample comes back to life after a reboot, but cannot be found in Run keys/services; Cause — attackers prefer scheduled tasks (schtasks) and WMI event subscriptions for persistence, which routine checks do not cover; Countermeasure — the persistence checklist must include schtasks /query and the WMI __EventConsumer query (step 2), checking the creation time and command content item by item
• Hidden scheduled tasks cannot be found by routine queries: Symptom —schtasks /query Neither the Task Scheduler GUI shows the task, and after a reboot the sample still revives; cause — the attacker deletes the task's security descriptor (SD) registry value or tampers with the Index metadata, hiding the task from regular queries; countermeasure — directly check C:\Windows\System32\Tasks\*.xml and the registry HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache, missing SD triggers an alert
• Injection detection looks at system-side signals, not just API sequences: symptom — the process tree shows nothing abnormal, the API sequence is not captured, yet injection has already occurred; cause — injection targets are mostly trusted system processes, and API monitoring is bypassed or cannot cover them; countermeasure — combine Sysmon events: 8 (CreateRemoteThread), 10 (ProcessAccess with PROCESS_VM_WRITE/PROCESS_VM_OPERATION/PROCESS_CREATE_THREAD), 7 (ImageLoaded from abnormal paths), 25 (ProcessTampering, memory image inconsistent with disk = hollowing); for hollowed samples use PE-sieve/Hollows Hunter to scan (in-memory PE header does not match disk)
• Persistence locations beyond Run keys/services: symptom — the Run keys and service list are clean, yet the sample still executes after logon/boot; cause — the attacker uses locations such as Winlogon Userinit, AppInit_DLLs, IFEO, COM hijacking, service failure recovery "Run a Program", etc. (Autoruns scans 18+ categories of ASEP); countermeasure — complete the persistence checklist with the above locations (step 2), and verify path, signature, and creation time item by item
• KernelCallbackTable injection (callback table redirection): symptom — the process tree is normal, none of the conventional injection API sequence (OpenProcess→VirtualAllocEx→WriteProcessMemory→CreateRemoteThread) can be caught, yet injection has already occurred; cause — the attacker clones the PEB's KernelCallbackTable and redirects a callback (e.g. __fnCOPYDATA) to the payload, triggers it with a window message (WM_COPYDATA), and the execution hides behind a legitimate process identity (ATT&CK T1574.013, used by Lazarus/FinFisher, with ready-made Sigma detection rules); countermeasure — in addition to the API sequence, check the callback table pointer targets and callback function addresses (dt _PEB KernelCallbackTable), Sysmon 10 write events to the target process, combined with the T1574.013 Sigma rule and memory scanning
• Direct/indirect system call injection (direct syscall): symptom — invisible to user-mode hook monitoring such as procmon/API Monitor; kernel ETW events such as Sysmon 10/25 can still be captured, yet injection has already occurred; cause — DirectSyscalls/IndirectSyscalls issue system calls directly without going through ntdll user-mode exports (or use legitimate modules as a trampoline), bypassing security products' user-mode hooks; countermeasure — downgrade monitoring to the kernel side (ETW, Sysmon 25 process tampering, kernel driver-level events), do not rely only on user-mode API events
• Linux-side injection monitoring blind spots: symptom — Linux sample ps -ef --forest process tree is normal, sysdig shows no abnormal execve, yet malicious code is already running in the target process; cause — Linux injection does not touch disk:process_vm_writev tracelessly writes to the target's memory, the attacker reads /proc/<pid>/syscall to get the target RSP and then constructs a ROP on the stack to call dlopen(DD object-oriented injection PoC published in 2024),LD_PRELOAD was already injected before monitoring started; countermeasure — audit /etc/ld.so.preload(auditd rules watch its writes), audit records process_vm_writev/process_vm_readv/ptrace calls, and compare the consistency between disk files and /proc/<pid>/maps mapping sources