4 posts tagged with "siem"

1. System Overview​

A SIEM (Security Information and Event Management) is the central nervous system of the SOC. Without a SIEM, an analyst has to manually check the logs of every single device (Firewall, Server, Laptop). With a SIEM, all those logs are sent to one place, translated into one language, and checked automatically for threats.

• Host-Centric Logs: Events from within a single device (e.g., User Login, File Access).
• Network-Centric Logs: Events about traffic between devices (e.g., VPN connections, Firewall Allows/Denies).

2. The Data Pipeline (Architecture)​

The SIEM works in stages. Understanding this pipeline is key to debugging why an alert didn't fire.

1. Ingestion (Collection):
   • Getting logs off the device and into the SIEM.
   • Methods: Agents (Forwarders), Syslog (for network gear), or Manual Uploads.
   • Key Location (Linux): /var/log/httpd (Apache Web Logs).
2. Normalization:
   • Every device speaks a different language. A Windows log says "Event ID 4624" (Login). A Linux log says "Accepted password for...".
   • Normalization translates both to a standard field: Action: User_Login.
3. Correlation (The Brain):
   • The SIEM links events together.
   • Example: "VPN Login from Russia" + "File Download" = Suspicious.
4. Visualization:
   • Dashboards showing trends (e.g., "Top 10 Failed Logins").

3. Correlation Rules (The Logic)​

A SIEM doesn't "know" what a hack looks like. You have to teach it using Rules.

• The Logic: IF [Condition A] AND [Condition B] THEN [Trigger Alert].
• Common Rule Types:
  • Brute Force: IF Action=Login_Failed happens > 5 times in 1 minute -> Alert.
  • Log Deletion (Covering Tracks): IF EventID=104 (Log Cleared) -> Alert (Critical).
  • Process Execution: IF ProcessName contains whoami OR miner -> Alert.

4. Lab Analysis: Crypto-Mining Incident​

In the lab scenario, you investigated a slow computer.

• The Trigger: An alert fired for "Suspicious Process."
• The Evidence:
  • Process Name: cudominer.exe (Mining software).
  • Rule Match: The SIEM rule looked for the string miner.
  • User: Chris.
  • Hostname: HR_02.
• Verdict: True Positive. The user (or malware) was running unauthorized mining software.

5. Operational Reality vs. Theory​

• Format Issues: In the real world, logs break constantly. If an update changes a log format, the SIEM stops understanding it (Normalization failure).
• Tuning: The hardest part of the job.
  • Example: You create a rule for "Log Deletion."
  • Reality: The IT Admin has a script that clears logs every Sunday for maintenance.
  • Fix: You must Tune the rule to say "IF Log Deletion AND User is NOT 'IT_Admin_Account'".
• Blind Spots: If you don't install an agent on a server, the SIEM is blind to it.

1. System Overview​

Triage is just the filtering mechanism. Reporting is the output mechanism. After validating an alert (Triage), the information must be structured and moved upstream. This phase bridges the gap between "I found something" and "We fixed it."

• L1 Role: Validate, document, and route.
• L2 Role: Receive valid threats, perform deep forensics, and execute remediation (containment/cleaning).
• Communication: The critical link to external stakeholders (IT, HR, Management).

2. The Reporting Lifecycle​

The goal is to create "Actionable Intelligence." A report is useless if the next person has to redo your investigation.

Step A: The "5 Ws" Framework (Standardization)​

Every report must follow a strict schema to ensure no critical data is lost during handoff.

1. Who: The entity involved.
   • User: m.clark
   • Privilege: NT AUTHORITY\SYSTEM (Highest risk).
2. What: The specific action.
   • Action: Executed revshell.exe via cmd.exe.
3. When: The exact timestamp (SIEM time, not current time).
   • Critical: Helps correlate with other logs (e.g., firewall traffic at the exact same second).
4. Where: The location.
   • Host: DMZ-MSEXCHANGE-2013 (High value target).
   • Path: C:\Users\Public\ (Common malware drop zone).
5. Why: The Verdict justification.
   • Reasoning: "Parent process is IIS Worker (w3wp.exe) spawning a shell. This indicates a web shell exploitation."

Step B: The Decision Matrix (Escalate vs. Close)​

Not every validated alert goes to L2. You must filter based on the "Alert Funnel."

Status	Definition	Action
False Positive	Benign activity (e.g., Admin testing).	Close. Add note: "Authorized activity per Change Request #123."
True Positive (Low)	Minor policy violation (e.g., P2P software).	Close (usually). Send automated email to user/manager. (Check specific SOC policy).
True Positive (High)	Active threat (Phishing, Malware, Root access).	Escalate. Assign to L2 immediately.
Uncertain	You cannot confirm if it's safe or malicious.	Escalate/Request Info. Do not guess. Ask L2 for a second opinion.

Step C: Escalation Protocol​

When moving a ticket from L1 -> L2, follow this "Handshake":

1. Update Status: Move from "In Progress" to "Escalated" (or reassign owner to L2).
2. The Handoff:
   • Procedural: Assign ticket in the system.
   • Direct: Ping the L2 on shift (Slack/Teams). Crucial for Critical alerts.
3. No "Throwing over the fence": You remain responsible until the L2 acknowledges receipt.

3. Communication Procedures (Crisis Management)​

The system breaks down when people panic. Follow these rules when standard workflows fail.

• The "Silent" Attacker: If you suspect a user's communication channel (Slack/Email) is compromised, do not contact them there. Call them on a mobile phone.
• The Unresponsive L2: If a Critical alert sits for >30 mins with no L2 response:
  1. Call L2 directly.
  2. Escalate to L3.
  3. Escalate to SOC Manager. (Do not jump straight to Manager unless necessary).
• The "Missed" Attack: If you realize you closed a ticket yesterday that was actually malware:
  • Do not hide it.
  • Re-open immediately and inform L2. Time is the enemy; hiding mistakes helps the attacker.

4. Technical Indicators in Reporting​

When writing the "Why" section, focus on these proof points:

• Email Analysis:
  • SPF/DKIM Fail: The sender is not who they claim to be (Spoofing).
  • Urgency: "Action Required Immediately" (Social Engineering).
  • Attachment: .zip or .html attachments from unknown senders.
• Web Shells:
  • Process Tree: w3wp.exe (Web Server) -> cmd.exe or powershell.exe. Web servers should serve pages, not run commands.
• Reconnaissance:
  • Commands: whoami, net user, nltest. These are "enumerating" the network to find the next target.

5. Operational Reality​

• Documentation is Evidence: In a legal breach, your notes are evidence. "I think it's bad" is useless. "Hash X matches Trojan Y on VirusTotal" is evidence.
• The "Bus Factor": Write every report as if you will be hit by a bus tomorrow. Can the next person understand exactly what happened without asking you?

1. System Overview​

The SOC L1 analyst acts as the verification layer between automated detection systems and manual incident response.

• Data Source: Endpoints (laptops, servers), Firewalls, and Cloud services generate raw logs.
• Aggregation: A SIEM (Security Information and Event Management) tool collects these logs.
• Detection: The SIEM applies logic rules (correlations) to the logs.
• Output: When a rule condition is met, an Alert is generated.

The L1 role is to validate whether the Alert represents a real security threat or a system error (noise).

2. The Triage Lifecycle​

The workflow follows a standard logic gate to ensure alerts are handled efficiently.

Step A: Queue Management​

Alerts appear in a dashboard queue. They must be selected based on a specific hierarchy to minimize risk.

1. Severity: Prioritize Critical and High alerts first. These represent immediate threats (e.g., Ransomware, Data Exfiltration).
2. Time: If severity is equal, prioritize the oldest alert.
3. Assignment: The analyst must assign the alert to themselves. This locks the ticket and prevents duplication of effort.

Step B: Contextual Analysis​

An alert provides a timestamp and a trigger event. The analyst must query surrounding data to understand the Intent.

• User Context: Is the user's behavior anomalous?
  • Example: A Human Resources user running PowerShell scripts is suspicious. A Developer doing the same is likely normal.
• Host Context: What is the function of the machine?
  • Example: High traffic on a web server is normal; high traffic on a printer is suspicious.
• External Intelligence:
  • Check destination IPs against reputation databases (e.g., AbuseIPDB, Talos).
  • Check file hashes against VirusTotal.

Step C: The Decision (Logic Gate)​

Every alert must end in a binary decision.

1. False Positive (Benign) The system logic triggered correctly, but the activity is not malicious.

• Causes: Legitimate administrative work, software updates, or overly broad detection rules.
• Action: Close the alert. Note the business justification (e.g., "User authorized to install Spotify").

2. True Positive (Malicious) The activity is unauthorized and harmful.

• Causes: Malware execution, credential theft, unauthorized access.
• Action: Escalate to L2/Incident Response. The L1 typically prepares the evidence package but does not perform the containment (isolation/wiping) themselves.

3. Technical Indicators​

When analyzing raw logs during Triage, look for these specific anomalies:

• Parent-Child Process Drift:
  • Standard: explorer.exe opens chrome.exe.
  • Suspicious: winword.exe (Word) opens powershell.exe. This suggests a malicious macro.
• Beaconing:
  • Consistent, rhythmic network connections to an external IP at regular intervals (e.g., every 5 minutes). This indicates Command and Control (C2) communication.
• Double Extensions:
  • Files named document.pdf.exe or invoice.xlsx.scr. The system hides the final extension, tricking the user into executing a binary.

4. Operational Reality vs. Theory​

• Noise: In a production environment, SIEM rules drift. Valid software updates often trigger "System Modification" alerts. The majority of L1 work is filtering out this noise.
• Living off the Land: Attackers often use standard administrative tools (PowerShell, PsExec) to blend in. The SIEM cannot distinguish between an Admin using PowerShell and a Hacker using PowerShell. The analyst must verify the source and intent manually.

0x01: The Watchtower (SIEM Architecture)​

Switching to the Blue Team, I spent time analyzing the SIEM (Security Information and Event Management).

There is a common misconception that a SIEM dashboard is an external tool or a third-party website we simply "check." In reality, a SIEM is the heartbeat of an organization's internal infrastructure. It acts as a massive funnel for data, operating in three distinct phases:

1. Ingestion (The Collection): This is the raw feed. Every firewall, server, workstation, and even the ID card scanners at the front door send their logs to a central point. Without this centralization, you would have to manually log into 5,000 different computers to see what is happening.

2. Normalization (The Translation): Logs are messy. A Windows server might say EventID: 4625, while a Linux server says Failed password for root. The SIEM’s job is to translate these different languages into a standard format (e.g., Authentication_Failure). This structure turns chaos into queryable data.

3. Detection (The Logic): Once the data is structured, we apply logic rules. These aren't just simple keyword searches; they are correlations.
   Simple: "Alert if a user fails login 50 times."
   Complex: "Alert if a user logs in from New York, and then logs in from London 10 minutes later."

The Art of Triage​

When one of these alerts fires, the job isn't just to "close the ticket." It triggers an Incident Response (IR) cycle. We have to become investigators immediately:

• True vs. False Positive: Is this actually a hacker running nmap, or is it just a junior sysadmin who misconfigured a network scanner? Context is everything.
• Contextual Analysis: We look at the metadata. Who is the Process User? If it's SYSTEM, that's bad. Which Host is affected? If it's LPT-HR-009 (Human Resources), they probably shouldn't be running PowerShell scripts at 2:00 AM.
• Containment: If the threat is verified, we move to containment. We don't wait; we isolate the machine from the network to prevent lateral movement.

---

0x02: File Identity (Windows vs. Linux)​

One of the most interesting alerts I analyzed involved a deceptive file named cats2025.mp4.exe. This highlights a fundamental difference in how operating systems establish "identity."

The Windows Deception​

Windows relies heavily on file extensions to decide how to treat a file. It trusts the name, not the data.

• The Trick: Attackers exploit the default Windows setting: "Hide extensions for known file types."
• The Execution: An attacker names a virus cats2025.mp4.exe. Because Windows sees .exe as a "known" type, it hides it. The user only sees cats2025.mp4 and thinks it is a video.
• The Reality: The icon might look like a video player, but the Operating System sees an executable. One double-click, and the payload runs.

The Linux Architecture​

Linux (and by extension, ELF binaries) operates on a "trust but verify" model. It generally ignores extensions entirely.

• Magic Bytes: Instead of reading the name, Linux reads the file header—the specific hexadecimal signature at the very start of the file.
  • An ELF binary (Linux program) always starts with the bytes 0x7F 45 4C 46.
  • If you name a file image.jpg but it starts with those bytes, Linux knows it is not an image. It is a program.
• The Permission Gate: This is the most critical safety feature. Even if you download a Linux virus, it cannot run by default. A user must explicitly grant the "Executable Bit" (chmod +x) permission.

Because the "Double Extension" trick fails on Linux, malware authors use a different camouflage technique called Masquerading.

Instead of trying to look like a generic PDF, Linux malware tries to look like a boring system process. They name their malicious files kworker, systemd-daemon, or journal-service so that when an admin runs a process list (ps aux), the malware blends perfectly into the background noise of the operating system.

EOF​

The deeper you go, the more you realize that "hacking" is rarely about smashing keys in a terminal. It is about understanding the architecture. It is knowing how the OS trusts files, how databases store passwords, and how to filter through millions of logs to find the single line that reveals the anomaly.