Certified SOC Analyst (312-39) (312-39) — Questions 226–300

Multi-stage correlation rules combine several weak or partial indicators before raising an alert, so isolated low-fidelity events no longer generate tickets. This raises the confidence threshold each alert must clear, directly improving the Signal-to-Noise ratio and reducing the alert fatigue described in the stem.

ArcSight correlation rules can only aggregate on fields present in the normalised event schema. If SessionID is absent from the parsed CEF output, the connector or FlexConnector map must first be amended to extract it, satisfying the stem's prerequisite before any rule referencing that field can function.

Correlation rule thresholds define how many matching events within a specified time window trigger an alert. Setting the count to five and the window to 60 seconds produces exactly the required high-severity alert condition, filtering out lower-frequency noise.

Global service events captures activity from services such as IAM and CloudFront that are not region-specific, ensuring the audit trail covers account-wide actions rather than only regional API calls, which is essential for a robust security audit.

Deleting volume shadow copies is a hallmark pre-encryption action used by ransomware such as Ryuk and Conti, so treating it as a high-severity incident and isolating the host prevents further spread while preserving the ability to investigate. Isolation before escalation is standard containment practice because the threat is still active and the user is online.

Normalisation parses each vendor's proprietary log schema into a shared field structure, such as common timestamps, source IPs and event types. This lets the SIEM correlate events across heterogeneous sources, which raw vendor-specific formats cannot support directly.

The rotate directive specifies how many times logs are rotated before being removed. Setting rotate 7 means that after 7 rotations, the oldest log is deleted. If logrotate runs daily, this retains 7 days of logs. Combined with compress, it meets the requirement. This is the correct directive to control retention count.

Web shell interaction typically appears as repeated POST requests to a single script with command-like parameters and consistent response lengths that differ from normal traffic. Analyzing access logs for these patterns, odd user agents, and requests to recently modified scripts can reveal the initial upload and subsequent command execution, directly supporting identification of the web shell's activity timeline.

PEview parses the Portable Executable structure, displaying the import table, embedded strings and section headers directly from disk. It performs no execution, satisfying the static-analysis constraint, unlike dynamic tools such as sandboxes or debuggers that require running the sample.

Shimcache records execution paths, and a path referencing a volume that no longer exists indicates the binary ran from transient storage such as a USB device or mounted virtual disk. That evidence points to removable media or virtual volumes rather than fixed local disks.

The more command with input redirection from the file and stream name (filename:streamname) reads and displays the contents of the specified alternate data stream. This is a native Windows method to access ADS content without specialized tools, allowing the analyst to examine hidden data that may contain malware or exfiltrated information.

A VM snapshot captures the disk and memory state before execution, so all file system and Registry changes are isolated to the guest. After observing behavior with tools like Procmon and Regshot, the analyst reverts to the snapshot, restoring a clean baseline. This provides both real-time visibility and reliable rollback without contaminating the host.

Sysmon Event ID 3 logs network connections, including the source and destination IP addresses, ports, and the process ID and image path of the process that initiated the connection. This directly provides the correlation between outbound connections and processes, making it ideal for investigating potential data exfiltration.

DNS logs show whether the phishing domain was resolved by internal hosts and can reveal command-and-control beaconing to related infrastructure. This helps confirm execution and identify additional compromised systems. Correlating DNS activity with the initial email alerts provides evidence of post-click behavior and helps scope the incident beyond the original recipients.

Regular beaconing to a known malicious IP over an encrypted channel with small, consistent packets is a classic indicator of Command and Control. The infected host is checking in with its C2 server to receive instructions or maintain presence. This phase occurs after exploitation and installation, and before actions on objectives, making C2 the most direct match for this traffic pattern.

Password spraying from a compromised internal host produces exactly this pattern: many distinct usernames, a single source, and failures distributed across workstations. Because the server lacks a legitimate authentication role, its authentication traffic is anomalous. This strongly suggests the host is being used as a pivot point for credential attacks, requiring immediate containment and investigation.

Attackers routinely disable or alter CloudTrail trails and logging configurations to erase evidence of their activity. Monitoring for such modifications detects defence-evasion attempts early, satisfying the SOC requirement to identify common cloud account compromise indicators before forensic data is lost.

The Terminal Server Client Servers registry key stores the hostnames or IP addresses of systems to which the user has previously connected using the Remote Desktop Connection client. Each subkey represents a target, often with a MRU value. This is a reliable client-side artifact for identifying outbound RDP connections, including those to external IPs, during a proactive hunt.

Correlation rules evaluate events within a defined aggregation window; if that window is too short or misaligned, matching events never co-occur in the same evaluation cycle, so the rule cannot fire even though the filter logic itself is correct.

Recording affected systems and users establishes incident scope, letting responders prioritise containment and identify lateral movement. Without this, the ticket cannot drive triage or notification, making it critical alongside the initial detection time and symptoms.

Elasticsearch stores @timestamp in UTC internally, so the correct approach is to parse each source's original time zone in Logstash and normalize it to UTC. The date filter with the appropriate timezone setting ensures the @timestamp field reflects the actual event time regardless of the source's local time zone, producing consistent indexing and accurate searches.

Raising thresholds means low-severity events no longer trigger alerts, directly cutting the volume of notifications analysts must triage. This satisfies the stem's goal of reducing alert volume without disabling detection entirely, though it risks missing genuine activity below the new threshold.

Event ID 4688 in the Security log records process creation. When process creation auditing is enabled, it includes the full command line of the new process, provided the 'Include command line in process creation events' policy is turned on. For PowerShell, this event captures the exact command line used, which is critical for understanding the script or commands executed. This makes it the correct source for retrieving the command line.

The Microsoft 365 compliance center (now Microsoft Purview compliance portal) provides an audit log search that queries the unified audit log, which includes mailbox audit events such as MailItemsAccessed, SendAs, and SendOnBehalf. This is the correct tool to investigate mailbox access and operations across Exchange Online, SharePoint, and other services.

INetSim simulates common internet services, including DNS, on a local host. It answers the malware's DNS queries with the analysis machine's address, redirecting traffic there for observation. This satisfies the requirement to intercept resolution without touching real DNS infrastructure.

The failed-then-successful login sequence from an unfamiliar IP is the defining signature of a brute-force or credential-stuffing attack achieving entry, which is precisely what an unauthorised access attempt IoC captures. It satisfies the stem's constraint of identifying the specific IoC category for this authentication pattern, rather than a broader indicator such as anomalous traffic.

According to NIST SP 800-61, the incident response lifecycle consists of four phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. After detecting and analyzing an incident, the next phase is to contain the threat, eradicate the cause, and recover systems. This sequence ensures that the incident is properly managed and systems are restored securely.

Event correlation aggregates and links discrete log entries from multiple sources into a single related incident, revealing patterns that isolated events hide. This satisfies the SIEM requirement to identify security threats by connecting causally or temporally related activity rather than alerting on each event alone.

Detection and Analysis covers identifying an incident's type and scope, satisfying the stem's requirement. This phase uses indicators, log correlation and triage to determine what occurred and how far it spread, before containment. It maps directly to NIST SP 800-61's detection and analysis stage, where incident validation and scoping occur.

AWS CloudTrail records API activity in the account, including IAM policy attachment events such as AttachRolePolicy. The event history contains the identity of the caller (user or role), the source IP address, the timestamp, and the request parameters. Querying CloudTrail for the AttachRolePolicy event on the Lambda execution role will reveal exactly who made the change and from where, directly answering the analyst's need.

Source IP, destination host and involved user account supply the correlation triad needed to scope a high-severity alert: attacker origin, targeted asset and compromised identity. This satisfies the stem's initial-triage constraint by enabling rapid containment decisions and pivoting to related telemetry in Microsoft Entra ID sign-in logs before deeper forensic analysis.

Logon Type 2 represents an interactive logon, where a user physically types credentials at the console of a workstation or server. Brute-force attacks against workstations typically involve repeated interactive logon attempts, generating Event ID 4625 with Logon Type 2. Filtering for this type helps isolate attempts to guess local or domain credentials directly at the machine, distinguishing them from network-based or service logons.

Identifying what went well captures successful actions and effective responses during an incident, forming part of the Lessons Learned review. It satisfies the process requirement by documenting strengths so they can be repeated in future incident handling.

Event ID 4698 is logged by Windows when a scheduled task is registered, recording the task name, creator and creation time. Filtering these events to the last 24 hours directly satisfies the stem's requirement to identify tasks created recently, unlike task XML files or registry keys that show current state only.

PowerShell Script Block Logging writes Event ID 4104, capturing the full script block content executed, including de-obfuscated commands. This provides the deepest visibility into fileless PowerShell activity, unlike command-line auditing which may truncate or miss dynamically constructed code.

Falcon's Process Tree view reconstructs the full ancestry of a detection, showing each parent-child relationship from the initiating executable down to the suspicious file. This exposes the parent process needed to judge whether the detection is malicious.

Decoding the command reveals its true intent, while parent process and network connection analysis show whether the execution aligns with known automation or indicates malicious download and execution. This evidence-based approach validates the alert without disrupting the developer. It also preserves the ability to escalate with confidence if the activity proves malicious, balancing security with business continuity.

certutil -hashfile on Windows and sha256sum on Linux compute cryptographic hashes of a file without executing it. These are built-in, fast, and reliable for generating values that can be compared to threat intelligence. This satisfies the pre-execution, no-detection-risk requirement of the scenario directly.

Alert scheduling defines the exact time windows during which a correlation rule evaluates events, so restricting evaluation to business hours directly satisfies the stem's timing constraint. Suppression settings complement this by muting notifications outside those windows, preventing after-hours triggers without disabling the underlying detection logic entirely.

The User Principal Name uniquely identifies a user across Microsoft Entra ID, EDR and SIEM platforms, enabling correlation of activity tied to one identity. This satisfies cross-platform tracking because UPN remains consistent where hostnames or IP addresses differ per system.

This approach applies the diamond model by capturing all four vertices—adversary, infrastructure, capability, and victim—and translating them into a detection rule. Correlating DNS queries with subsequent connections increases fidelity, reduces false positives, and creates reusable detection logic. It also enriches the SIEM with context, enabling proactive hunting for related infrastructure and behaviors beyond the single domain.

Correlation rules match loosely defined patterns across heterogeneous log sources, so benign activity frequently triggers alerts. Tuning thresholds and exceptions becomes a continuous effort, and the resulting high false-positive rate is a defining challenge of SIEM correlation rule development.

Get-SmbSession queries the SMB server's active session table, listing connected clients, user names and originating IP addresses. This directly satisfies the stem's need to view active SMB sessions between the two workstations during lateral movement analysis.

Snapshotting the persistent disk captures the rogue VM's disk state before remediation, preserving volatile evidence for forensic analysis. This satisfies the forensic requirement, as deleting the VM first would destroy the data needed to investigate the compromise.

The Incident Response Plan defines severity classifications, escalation routes and contact trees, so it specifies who notifies whom and through which channel during a high-severity event. Communication paths are procedural, not technical, so no log or monitoring tool replaces it as the first reference.

A cloud-provider source IP is not inherently malicious, so reputation must be established before classifying. Querying threat intelligence feeds determines whether that address is flagged, supplying the evidence needed to decide if the brute force alert is genuine or benign.

Authentication logs reveal when and from where the stolen credentials were used, establishing the attacker's access timeline and affected systems. They help determine the scope of compromise and whether additional accounts or resources were accessed, making them critical for the incident report.

Scheduled Tasks survive reboots and run without user interaction, so attackers register a malicious task to relaunch their payload automatically. Checking the task library, its triggers and actions exposes this persistence mechanism, satisfying the stem's requirement for a commonly examined persistence artifact.

Regex extracts named capture groups from raw log lines, letting you map each field to SIEM taxonomy entries. It handles the unstructured, variable-format input the stem describes, unlike delimiter or fixed-position parsing that assume consistent structure.

Microsoft Defender for Servers provides endpoint detection and response, capturing process-level execution telemetry on the VM, including command lines and parent processes. This satisfies the stem's requirement to see process execution details on the suspected cryptomining virtual machine.

A log aggregator receives raw log streams from dispersed network nodes, then parses and normalises each into a common schema before forwarding to storage. This directly satisfies the stem's two requirements: centralised collection from varied sources and format standardisation prior to persistence.

Event correlation logic applies rules that match multiple related log entries across sources and time windows, then merges them into one incident, satisfying the stem's grouping requirement. Unlike simple aggregation, it evaluates conditional relationships between events, so causally linked alerts become a single actionable case rather than separate notifications.

The bytes_sent field records the byte count transmitted from the internal host to the destination address, directly quantifying outbound transfer volume per connection. Filtering on it isolates the largest flows to the external IP, satisfying the requirement to identify exfiltration volume rather than connection counts or packet totals.

Isolating the workstation via EDR is the most immediate containment action. It cuts off all network communication, including C2 traffic, while preserving the endpoint for forensic analysis. This prevents lateral movement and further data exfiltration without alerting the attacker by shutting down the system.

With the agent running and connectivity verified, the failure lies within ingestion. Checking SIEM ingestion error logs reveals agent authentication failures, such as expired certificates or incorrect shared secrets, which silently block log delivery from the Windows server.

MTTR measures the elapsed time from incident detection to resolution, directly quantifying how quickly the team restores normal service. It satisfies the stem's efficiency requirement by exposing response speed as a measurable, benchmarkable figure, complementing detection-focused metrics such as MTTD.

A successful authentication from an anomalous geography and time using a legitimate account is the textbook signature of Initial Access through valid accounts. The attacker has obtained credentials and is using them to enter the environment, which is the first foothold and matches the observed log evidence.

Capturing memory first preserves volatile data such as running processes, network connections and encryption keys that vanish on shutdown or reboot. Imaging the disk afterwards still captures persistent evidence, and the order avoids altering RAM contents through disk-write activity.

Detect It Easy inspects PE headers, section entropy and packer signatures to flag likely packing or obfuscation. High entropy and unusual section names are the indicators it surfaces, directly answering whether the suspicious file is packed.

WHOIS records expose the domain's creation date, which directly answers the registration-timing requirement in the stem. Unlike DNS, which returns current resolution data, or passive DNS, which logs historical resolutions, WHOIS holds registrar-level registration metadata including creation and expiry dates, letting you establish when the malicious domain first existed.

Kerberoasting requests service tickets for accounts with SPNs, often using weak RC4 encryption (0x17). Event ID 4769 logs Kerberos service ticket requests. A non-computer service account with RC4 encryption is suspicious because modern environments typically use AES. This combination strongly suggests an attacker is requesting a ticket to crack offline.

Cryptographic hashes act as tamper-evident seals: any modification to a log file changes its hash, so recomputing and comparing against a stored baseline reliably detects alteration. This provides stronger integrity assurance than access controls or plain checksums, which cannot resist deliberate tampering.

netstat -tulnp lists TCP and UDP listening sockets with numeric ports and, via the -p flag, the owning process ID and program name. This maps the rogue process to its associated network socket, identifying its listening or established connections.

Validating the offense against its contributing events establishes scope and truth before any containment or escalation. Confirming the source IP, targeted account, and whether the successful authentication came from a known host distinguishes a true positive from a false positive. This evidence-driven first step prevents premature escalation and ensures subsequent actions are justified by the actual event data.

The Security Content Engineer owns detection content, tuning correlation rules to reduce false positives and validating that the SIEM parses and alerts correctly. This role keeps rule logic and platform health aligned, distinct from analysts who triage alerts or architects who design the deployment.

A feedback loop allows analysts to report whether threat intelligence led to successful detections or response actions. This helps refine the intelligence process, improve the relevance of future feeds, and adjust detection rules. It ensures that threat intelligence remains aligned with operational needs and continuously improves the SOC's effectiveness in identifying and responding to threats.

The USBSTOR key in the SYSTEM hive records the device instance for every USB mass storage device that has ever been attached, including vendor and product identifiers. It persists after the device is disconnected, which is exactly what is needed to retrospectively confirm which removable drives touched this workstation and to pivot toward volume serial numbers in the setupapi logs.

The first step in incident response is to validate the alert to determine if it is a true positive. By correlating logs from multiple sources, the analyst can confirm whether the outbound traffic is malicious or benign. This ensures that subsequent actions are based on accurate information, avoiding unnecessary escalation or containment measures that could disrupt operations.

Patching the underlying vulnerability removes the initial infection vector, satisfying the eradication requirement to eliminate the root cause rather than merely containing symptoms. Without remediation, re-infection recurs from the same exploited flaw. This action belongs to eradication, not recovery, because it prevents the malware's reintroduction before systems return to production.

The CloudWatch Unified Agent collects metrics and logs in one package and can stream on-premises log files to CloudWatch Logs via its logs section. It satisfies the forwarding requirement, unlike the older CloudWatch Logs agent or SSM Agent.

Sysmon event ID 10 is ProcessAccess and logs when a process opens a handle to another process, including the source image, target image, granted access, and call trace. When configured to monitor LSASS, it can reveal unauthorized tools such as Mimikatz or comsvcs.dll MiniDump accessing lsass.exe. This directly answers whether LSASS memory was accessed in the last 24 hours.

A SIEM collector receives raw event data from sources such as syslog, agents, or APIs and forwards it to the central processing engine for parsing, correlation, and storage. It handles ingestion and transport, not analysis itself.

Packed files typically have high entropy because compression or encryption is used to obscure the original code. Tools like PEiD or Detect It Easy can calculate entropy; values above 7.0 often indicate packing. This is a reliable indicator because legitimate code usually has lower entropy due to structured instructions and data.

VirusTotal submits the hash to dozens of antivirus engines and reputation feeds simultaneously, returning aggregated detections without executing the file. This multi-engine correlation gives far stronger verdict confidence than any single-vendor scanner or sandbox lookup.

HKCU\Software\Classes\CLSID enables per-user COM hijacking: an attacker registers a malicious in-process COM server that loads whenever any application instantiates the hijacked CLSID, achieving persistence without admin rights. This satisfies the hunt's requirement to cover common registry persistence locations, since user-writable CLSID entries are a documented, frequently abused technique.