Skip to main content

The Watchtower: Anatomy of an Alert

Shubham
Shubham
Cybersecurity Enthusiast

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.