3.5Log interpretation and malware analysis output

A SOC's daily work comes down to "reading logs and assembling events." But logs differ in granularity and vocabulary across OS, application, and command line; SIEM correlates them across sources, and SOAR automates routine responses. Further, an unidentified sample is safely executed in a sandbox (detonation chamber), and its behavior (hashes of dropped files, contacted URLs/IPs, registry changes) is extracted as IoCs. This section addresses the judgment of reconstructing "what happened" from a single log line or an analysis report and deciding the next move.

3.5.1Log sources and SIEM/SOAR

• OS/app/CLI logs—OS logs (Windows event logs, Linux /var/log) show logons and service state; application logs (e.g., a web server's access log) show app-specific events; CLI logs (shell history, sudo/audit logs) show the commands executed. For example, sshd[2011]: Failed password for invalid user admin from 203.0.113.5 signals an SSH brute-force. Granularity differs, so combine them to assemble the event.
• A SIEM collects, normalizes, and correlates many logs to raise alerts on attacks invisible in a single log (e.g., a chain of auth failures spanning multiple hosts). If time sync (NTP) breaks, correlation goes wrong, so timestamp consistency is a prerequisite.
• A SOAR receives detections from a SIEM and the like and automates/semi-automates response along a playbook (e.g., auto-blocking a suspicious IP, isolating an endpoint, opening a ticket). It accelerates repetitive first-line response and frees analysts to focus on cases needing judgment.

3.5.2Sandbox and analysis output

• A sandbox/detonation chamber is dynamic analysis that actually runs (detonates) a suspicious sample in an environment isolated from production and observes its behavior. Even where static analysis (examining structure without running) is stymied by obfuscation, it can reveal actual behavior. However, advanced malware performs sandbox evasion (detecting the virtual environment or delaying execution), so "no reaction" does not necessarily mean "safe."
• Analysis output—the report lists the hashes (MD5/SHA-256) of created/modified files, contacted URLs/domains/IPs, registry/filesystem changes, launched processes, network behavior, and more. As IoCs, these can be fed into a SIEM or EDR to confirm contamination of other hosts and to block. Hashes in particular are indicators that uniquely identify a sample.

A user reports "I opened the attachment but nothing happened," and you are examining that attachment. First, static analysis takes a hash and checks it against known verdicts, but there is no hit (possibly unknown/variant). Because it is obfuscated and its intent is unreadable from structure alone, you run it in an isolated sandbox (detonation chamber). The report shows this behavior: after execution it creates a misleadingly named file svchost32.exe (SHA-256 recorded), beacons to a URL hxxp://malicious-update[.]example/gate.php, and registers itself under HKCU\...\Run. Concluding "nothing happened in the user's environment, so it is harmless" is wrong here—advanced malware performs sandbox evasion, yet in a real user environment it may fire when conditions are met, so "no reaction" is not "safe." Rather, the behavior the sandbox revealed is its true nature. The next move is to extract the report's hashes, contacted URLs/IPs, and the Run-key registration name as IoCs, feed them into the SIEM, and use cross-source correlation to surface "on which other endpoints is there a file with the same hash or traffic to the same URL." For any endpoints that hit, run a SOAR playbook to auto-isolate, block the IP, and open a ticket, accelerating first-line response. Choosing the right log source matters too: web proxy/DNS logs show whether there was traffic to that beacon URL (an app/network fact), OS logs show the Run-key registration or service-creation traces, and CLI/audit logs show manual lateral-movement commands—a single log shows only a fragment, and only bundling them in a SIEM yields the "whole picture of the compromise." In short: use the sandbox to establish "what the sample does," turn its output into IoCs, and use SIEM/SOAR to confirm and stop "how far it spread"—this flow is the practical backbone linking dynamic analysis and log operations.

3.5.3Section summary

• OS logs show logon/persistence, app/CLI logs show app events/executed commands, a SIEM builds the whole picture via cross-correlation, and a SOAR automates response via playbooks—each source tells you different things
• A sandbox (detonation chamber) is dynamic analysis that runs a sample in isolation and observes behavior; "no reaction" is not "safe" (watch for sandbox evasion)
• Analysis-output hashes/URLs/IPs/registry changes are fed as IoCs into a SIEM/EDR to confirm contamination of other hosts and to block