Secure Scroll

Quick recap: In Part 1 we built a working phishing simulator using GoPhish and hMailServer — free tools, everything running on your own machine. In Part 2 we automate the hard parts. Target research, email writing, and stack deployment — all in a few commands.

I work in detection engineering, so while this article covers the full setup, Section 6 is where my real interest is. If you are on the blue team side, skip ahead — I will not be offended.

0. Before You Start — Prerequisites

Before anything else, make sure you have these installed on your Windows machine. Everything in this article depends on them.

Installing Python — one important step:

When the Python installer opens, check the box that says “Add Python to PATH” before clicking Install. If you miss this, the pip command will not work and you will get an error.

After installing, open PowerShell and verify:

python --version
pip --version

1. Why Automation Matters Here

When I was setting up Part 1, the most time-consuming part was writing the email templates. Three templates took about 45 minutes — getting the tone right, making sure the urgency felt real without being obvious.

Attackers solved this problem a long time ago. They do not sit and write emails one by one. They pull public data about targets, feed it into a language model, and generate hundreds of personalized emails in minutes.

That is what we are building here. Not to attack anyone — but to understand exactly what your organization is up against, and to run better simulations with less manual effort.

Everything in this article runs on a standard laptop. No GPU. No cloud. Phi-3 is the model we are using and it runs fine on 8GB RAM.

2. Automated OSINT with TheHarvester

pip install theHarvester

theHarvester -d acmecorp.com -b google,linkedin,bing -l 50

The output gives you names and emails you can drop straight into your target list. Only run this against domains you own or have written permission to test.

3. Setting Up Phi-3 with Ollama

Ollama is a runtime for local language models. Think of it the same way you think of Docker — it manages the model for you so you do not have to deal with any setup complexity. Phi-3 is the model we are loading into it. I picked Phi-3 specifically because it does not need a GPU. Most AI tools you read about online assume you have an NVIDIA card. Phi-3 runs on CPU, which means it works on a regular office laptop. After installing Ollama from the prerequisites section, open PowerShell and pull Phi-3:

ollama pull phi3

About 2.3GB download. Once it finishes, test it:

ollama run phi3 "Write a short professional email asking someone to verify their account."

If you get a response back, you are ready. Now we connect it to your target data.

4. The Python Script That Ties It Together

This script reads your target list, sends each person’s details to Phi-3, and writes out a personalized phishing email for each one. The whole thing runs in under a minute for a list of 20 people.

Install the Ollama Python library:

pip install ollama

import csv
import ollama
INPUT_FILE = "targets/sample_target_list.csv"
OUTPUT_FILE = "targets/generated_emails.txt"
PROMPT_TEMPLATE = """
Write a professional phishing simulation email for security awareness training.
The recipient's name is {first_name} {last_name} and their job title is {position}.
The email should appear to come from the IT Helpdesk asking them to verify their account.
Keep it under 150 words. Sound natural, not robotic.
"""
def generate_email(first_name, last_name, position):
    prompt = PROMPT_TEMPLATE.format(
        first_name=first_name,
        last_name=last_name,
        position=position
    )
    response = ollama.chat(
        model="phi3",
        messages=[{"role": "user", "content": prompt}]
    )
    return response["message"]["content"]
with open(INPUT_FILE, newline="") as csvfile:
    reader = csv.DictReader(csvfile)
    with open(OUTPUT_FILE, "w") as outfile:
        for row in reader:
            print(f"Generating email for {row['First Name']} {row['Last Name']}...")
            email = generate_email(row["First Name"], row["Last Name"], row["Position"])
            outfile.write(f"--- {row['First Name']} {row['Last Name']} ---\n")
            outfile.write(email + "\n\n")
print(f"Done. Emails saved to {OUTPUT_FILE}")

Run it:

python generate_lures.py

Open targets/generated_emails.txt. You will see a different email for each person on your list, written around their specific job title. Copy them into GoPhish as templates and your campaign is ready to launch.

5. Docker Setup — The Whole Stack in One Command

If you do not want to install GoPhish and Ollama separately on every machine you use, Docker handles it. One file, one command, everything runs.

Make sure Docker Desktop is installed from the prerequisites section and it is running before you continue. Save this as docker-compose.yml in your project root:

version: "3.8"
services:
  gophish:
    image: gophish/gophish
    container_name: gophish
    ports:
      - "3333:3333"
      - "80:80"
    volumes:
      - ./part1/config/gophish_config.json:/opt/gophish/config.json
    restart: unless-stopped
  ollama:
    image: ollama/ollama
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped
volumes:
  ollama_data:

Start everything:

docker-compose up -d

Pull Phi-3 into the running container:

docker exec -it ollama ollama pull phi3

GoPhish is now at https://localhost:3333. Ollama is running at http://localhost:11434. Everything is local, nothing goes to the cloud.

6. How to Detect This on the Defensive Side

Building this taught me something useful — AI-generated phishing is much harder to catch with traditional filters because it does not repeat itself. This is the section I actually enjoyed writing. Building this taught me something useful — AI-generated phishing is much harder to catch with traditional filters because it does not repeat itself. Every email is slightly different, so keyword matching and signature-based detection largely miss it.

Here is what actually works:

Sigma rules to catch the activity:

# Rule 1 - High volume of unique outbound emails
title: Possible AI Phishing - High Volume Unique Emails
detection:
  selection:
    EventID: 4625
    Source: SMTP
  condition: selection | count() > 50 within 1h
# Legitimate senders rarely send 50+ unique emails in one hour
# Rule 2 - OSINT tool running on a corporate machine
title: OSINT Tool Execution - TheHarvester
detection:
  selection:
    EventID: 1
    CommandLine|contains:
      - 'theHarvester'
      - 'harvester.py'
  condition: selection
# TheHarvester on a corporate endpoint is a red flag
# Rule 3 - Ollama API traffic on the network
title: Local LLM API - Ollama Port Activity
detection:
  selection:
    EventID: 3
    DestinationPort: 11434
  condition: selection
# Port 11434 is Ollama's default port — unusual in corporate environments

7. Closing Thought

What took me 45 minutes to do manually in Part 1 now takes about 2 minutes with this setup. That is the reality of where phishing is heading — not because attackers are smarter, but because the tools got easier.

The same tools work for defenders though. You can now run monthly simulations with rotating AI-generated templates, test different departments with different lures, and do it all without a vendor platform or a budget approval.

The best phishing awareness programs are the ones that feel real. This setup gets you there.

GitHub: All files from both parts — https://github.com/chandpeshwar/phishsim-from-scratch

Sources:

• GoPhish — https://getgophish.com
• Ollama — https://ollama.com
• Microsoft Phi-3 — https://azure.microsoft.com/en-us/products/phi-3
• TheHarvester — https://github.com/laramies/theHarvester
• Docker Desktop — https://www.docker.com/products/docker-desktop
• MITRE ATT&CK T1566 (Phishing) — https://attack.mitre.org/techniques/T1566

Disclaimer: This article is intended for educational and defensive security purposes only. All tools, techniques, and scripts covered here are for authorized security testing within your own organization. Never run phishing simulations or OSINT tools against systems, domains, or individuals without explicit written permission. The author takes no responsibility for any misuse of the information provided.

Ten years ago, phishing was a fake login page and a gamble that someone would fall for it. Today, attackers do not need you to fall for anything — they sit silently between you and the real login page, wait for you to complete MFA yourself, and steal your session the moment you are done. This article breaks down how phishing got here and what defenders can do about it.

Where It All Started — The HTML Clone Era

The original phishing kit was exactly what it sounds like. An attacker would:

1. Download the HTML of a real login page — Gmail, PayPal, a bank
2. Modify the form to send credentials to their own server
3. Host it on a cheap or compromised domain
4. Send mass emails pointing victims to it

That was it. The whole thing could be set up in an afternoon. Kits were sold on forums for a few dollars — a zip file with HTML, CSS, and a PHP script to capture passwords.

The problem for attackers: These kits only stole passwords. Once organizations started rolling out MFA, a stolen password alone stopped being enough. They had to adapt.

The First Upgrade — Fake MFA Pages

The first response to MFA was simple — just add another fake page. After the victim entered their password, they were shown a fake MFA prompt asking for their one-time code. The attacker would grab that code, log into the real service with the stolen password and code — all within the 30-second window before it expired.

It worked, but it was clunky. Someone had to be watching, manually copying codes, racing the clock. It did not scale.

The next problem: Attackers needed something that could do this automatically, for thousands of victims at the same time, without anyone sitting at a keyboard watching.

 The Game Changer — Reverse Proxy Phishing (AiTM)

This is where things got genuinely dangerous. Instead of showing a fake page, the attacker’s server became a silent relay — sitting between the victim and the real website, passing everything through.

Here is how it works:

Normal login:
  You → Microsoft login page → Authenticated ✓
AiTM phishing:
  You → Attacker's proxy → Microsoft login page → Authenticated ✓
                ↓
         Attacker silently copies your session token

The Phishing Kit Ecosystem Today

What started as a clever technical trick became an entire criminal industry. Here is where things stand:

This is not a shadowy underground anymore. Tycoon 2FA charged $120 for 10 days and $350 for a month — with a web dashboard, pre-built Microsoft 365 and Gmail templates, campaign tracking, and support. It ran like a SaaS business. A criminal one, but a business.

The OAuth Device-Code Attack — The Newest Trick

Just as defenders started catching up to AiTM proxies, a new approach emerged that does not even need a fake login page.

How it works:

OAuth device-code flow was designed for devices without keyboards — smart TVs, printers — where typing a password is not practical. The device shows you a short code, you go to a real URL on your phone or laptop, enter the code, and the TV gets signed in.

Attackers turned this against users:

1. Attacker generates a real device-code request to Microsoft
2. Sends the victim an email: “Please verify your device at microsoft.com/devicelogin — code: ABC123”
3. Victim goes to the real Microsoft page, enters the real code
4. Microsoft authenticates the attacker’s device

The victim did everything correctly. They went to a real Microsoft URL. They entered a real code. And they just handed the attacker persistent access to their account — no session token to expire, no time pressure.

Detection — The Signals AiTM Leaves Behind

AiTM is difficult to catch at the email layer. The real detection opportunity is in what happens right after authentication.

.

Rule 1 — Impossible Travel Detection

Real users do not log in from two countries within minutes. If a session shows up in two places that fast, the token has been stolen. Fires when the same account authenticates from one country and then the active session appears from a different country within 10 minutes.

title: AiTM - Impossible Travel Session Reuse
logsource:
  product: azure
  service: signin_logs
detection:
  selection:
    ResultType: 0
    TokenIssuerType: AzureAD
  condition: same UserPrincipalName with different CountryOrRegion within 10m
level: critical
tags:
  - attack.credential_access
  - attack.t1539

Rule 2 — New MFA Method Registered After Login

After stealing a session, attackers register their own MFA device immediately — so they keep access even if the victim resets their password. Fires when a new authentication method is added to an account within 1 hour of a fresh sign-in. Users almost never register new MFA devices the moment they log in.

title: AiTM - MFA Method Added After Login
logsource:
  product: azure
  service: audit_logs
detection:
  selection:
    OperationName: "Update user"
    TargetResources|contains: "StrongAuthenticationMethod"
  condition: selection within 1h of successful sign-in by same user
level: high
tags:
  - attack.persistence
  - attack.t1098.005

Rule 3 — Suspicious Inbox Rule After Authentication

Creating inbox rules right after logging in is one of the most consistent attacker behaviors — hiding replies, forwarding emails out, deleting security alerts before the victim sees them. Fires when an inbox rule that forwards, deletes, or moves emails is created shortly after a login event.

title: AiTM - Suspicious Inbox Rule Post Authentication
logsource:
  product: microsoft365
  service: exchange
detection:
  selection:
    Operation: "New-InboxRule"
    Parameters|contains:
      - 'ForwardTo'
      - 'DeleteMessage'
      - 'MoveToFolder'
  condition: selection within 30m of successful sign-in by same user
level: high
tags:
  - attack.collection
  - attack.t1114.003

Rule 4 — OAuth Consent from Unverified Publisher

Device-code phishing ends with the victim granting consent to an attacker-controlled OAuth app. Legitimate enterprise apps are almost always verified — an unverified one is a red flag. Fires when a user consents to an OAuth application from an unverified publisher.

title: AiTM - OAuth Consent by Unverified Publisher
logsource:
  product: azure
  service: audit_logs
detection:
  selection:
    OperationName: "Consent to application"
    TargetResources|contains: "IsVerified: false"
  condition: selection
level: high
tags:
  - attack.initial_access
  - attack.t1566

MITRE ATT&CK Mapping

What Actually Stops AiTM

Most MFA does not stop AiTM. Here is what does:

The uncomfortable truth: SMS codes, push notifications, and TOTP apps like Google Authenticator do nothing against AiTM. They protect the login moment. AiTM skips past the login moment entirely. FIDO2 is currently the only widely available MFA method that holds up — because the authentication is bound to the real domain and cannot be relayed through a proxy.

Final Thought

Phishing used to be about tricking people into handing over passwords. Now it is about letting people log in normally — and stealing the proof of that login.

Defenders who are still focused entirely on stopping credential theft are a step behind. The real question in 2026 is not whether your users have MFA. It is whether your MFA can survive a proxy sitting between your users and your identity provider — and whether anyone is watching what happens in the first few minutes after a successful login.

That is where attacks are landing now.

Blue Team Autopsies — Article 2

The attacker was in the network for 22 days.

What Was Actually Happening Inside the Network

I want to be specific about what happened here, because “the SIEM had the data” is one of those things people say without really unpacking what it means. So let me unpack it.

Day 1, 9:14 AM — someone logs into the VPN. Valid credentials. Right username, right password. Nothing looks wrong except the IP — Eastern Europe. This particular employee had never once logged in from outside the country. Four years of history, all domestic. That fact was sitting in the authentication logs and not a single rule was checking it. So the login went through, no alert, completely clean.

Next day they started looking around. Ran net user /domain. Ran net group "Domain Admins" /domain. Standard stuff — it’s what attackers do when they want to understand the layout, figure out who has the keys, plan their next move. Windows flagged every one of those commands. Event IDs 4661, 4662 — they exist specifically for this. All logged. Nobody watching.

Then came the slow part, Days 5 through 18. Files started moving to a staging folder. Not a big dump — that would’ve been obvious. Small amounts. 200MB one week, 350MB a few days later, a gap, then 180MB, then 420. Spread out deliberately, always under whatever threshold might have triggered something. The account had legitimate access to those files — finance records, legal docs, engineering stuff — so nothing looked wrong on the surface. There was no baseline for what “normal” looked like for that account, so there was nothing to compare it against.

Days 19 through 21, the files left. Three sessions, always late at night, always after 11. Uploading to attacker-controlled cloud storage. Here’s the thing though — the destination domain was already in the company’s threat intelligence feed. Flagged. The DNS logs had every single query to it. Both pieces of information were in the same SIEM. Nobody had written a rule that connected them.

Day 22, an analyst got a gut feeling about some outbound traffic. Not a rule. Not automation. A person, following their instinct. IR confirmed the breach within hours.

Twenty-two days.

Everything Was Logged. Nothing Was Covered.

I keep coming back to this table because I think it’s the most honest summary of what went wrong:

That last row. Forty-seven rules, all pointed at something the attacker never did.

Three Failures That Made This Possible

Failure 1 — The Team Was Still Fighting a 2019 Threat Model

All the detection work was built around catching malware — bad hashes, suspicious process names, known file signatures. Solid work. Genuinely. Just completely beside the point when the attacker walks in with a real password and uses tools that shipped with Windows. There was no weapon to detect. The metal detector was perfect. The attacker had a badge.

Failure 2 — Empty Queue Meant Clean Network. It Didn’t.

The analysts cleared their queue every day. Dashboard was green. Internally that read as: we’re fine. But a detection rule only catches what you thought to write a rule for. If the attacker does something outside that set — different tool, different path, slower pace — the rule produces nothing. And silence looks identical whether your network is clean or whether someone’s been quietly inside it for three weeks.

I genuinely think this is the most dangerous assumption in security operations right now. Not the sophisticated attacks. The assumption that if nothing fired, nothing happened.

Alert queue empty → No rules matched → Threats outside rule coverage go unseen.

The queue being empty tells you what your rules found. It tells you nothing about what they missed.

Failure 3 — The Intelligence Was Paid For. Never Used.

The feed was ingested. The domain was in it. The DNS queries were in the logs. Two facts, same platform, zero connection between them. This happens more than anyone wants to admit — organisations buy threat intelligence, tick the box, and never actually operationalise it into live detection logic. It’s just data in a table at that point. It doesn’t protect anything.

What They Fixed After the Breach

But honestly the biggest change wasn’t technical.

They stopped telling leadership “we closed 340 alerts this week.” They started telling them “68% of our log sources have active detection coverage.” Those are completely different numbers and they tell completely different stories. The first one sounds busy. The second one tells you the actual shape of your blind spots.

When leadership saw that percentage for the first time, the conversation about resourcing changed immediately.

Three Questions to Ask Your Team This Week

1. Which log sources do we ingest that have zero detection rules using them?
Go find out. The answer will surprise you.

2. When did we last run an actual threat hunt — not alert triage, a real hypothesis driven into raw data?
If you can’t name a date, you haven’t run one.

3. For every threat intel feed we’re paying for — which SIEM rule operationalises it?
If you can’t point to the rule, the feed isn’t protecting you. It’s just costing you money.

The Line That Should Stay With You

22 days. Fully staffed SOC. SIEM running. Evidence logged from Day 1.

Nobody asked the right questions.

If you’re an analyst — your most valuable work isn’t the alerts you close. It’s the threat that never generated one that you go find anyway.

If you’re a threat hunter — the space between your rules isn’t empty just because no alert fired there. Go look.

If you’re a security manager — you’re probably measuring how busy your team is. Start measuring how much of your environment they can actually see.

This article is part of the Blue Team Autopsies series — stories about security that should have worked, and exactly why it didn’t.

Disclaimer: The scenario described in this article is fictional and constructed for educational purposes only. It is based on common real-world attack patterns and detection failures but does not represent any specific organization or confirmed incident. Technical details are illustrative. Nothing here constitutes legal, compliance, or security advice. Always test detection changes in your own environment before deploying to production.

ChatGPT is amazing at explaining code, but pasting your company’s security logs into a public AI is a massive security breach. Here is how SOC Analysts are using open-source, local AI to speed up investigations safely.

If you have been following our Watchtower Chronicles series, you know what life is like for a SOC Analyst, You can find the links for the watchtower Series at the end of this article. You are staring at a SIEM dashboard, and an alert pops up with a massive, confusing wall of text from a Windows Event Log.

As a beginner, your first instinct might be to copy that terrifying block of code, open ChatGPT, paste it in, and ask: “Is this malware?”

Stop right there. If you do that in a real corporate environment, you might get fired before lunch. Today, we are going to talk about the Privacy Dilemma of AI in cybersecurity, and how you can run powerful AI models directly on your own laptop to analyze logs with zero risk.

The Privacy Dilemma: Why Public AI is a Trap

Large Language Models (LLMs) like ChatGPT, Claude, and Gemini are incredible tools for translating complex logs into plain English.

But here is the catch: When you paste data into a public AI, you are sending it to a third-party server.

Remember the Windows Event ID 4688 (Process Creation) we enabled back in [Part 2 of the Watchtower Chronicles]? That log doesn’t just show that PowerShell ran. It might contain:

• Internal server names
• Employee usernames
• Proprietary script logic
• Sometimes, accidentally hardcoded passwords

If you paste that into a public AI, you have just committed a Data Exfiltration incident. You handed your company’s internal blueprints to an external vendor.

So, how do we get the superpower of AI without the security risk? We bring the brain to the data, instead of sending the data to the brain.

The Solution: Local LLMs with Ollama

You don’t need a million-dollar supercomputer to run AI. Thanks to the open-source community, you can run incredibly smart models right on your daily work machine.

The easiest tool to do this is Ollama.

Ollama is a free, open-source tool that lets you download and run Large Language Models (like Meta’s Llama 3 or Google’s Gemma) locally. It runs completely offline. You can unplug your router, and the AI will still work.

Here is how to set up your own private “AI SOC Assistant” in three simple steps.

Step 1: Download and Install

Go to the official Ollama website and download the installer for Windows, Mac, or Linux. The installation takes less than a minute.

Step 2: Pull an AI Model

Open your command prompt (Terminal or PowerShell) and tell Ollama which “brain” you want to download. For cybersecurity log analysis, Meta’s Llama 3 (the 8B version) is incredibly fast and smart.

Type this command and hit enter: ollama run llama3

The tool will download the model (it’s a few gigabytes, so grab a coffee). Once it finishes, you will see a simple >>> prompt. You are now talking to an AI that lives entirely on your hard drive.

Step 3: Analyze the Log Safely

Let’s feed it a real SOC scenario. Remember the Brute Force Sigma Rule we wrote in [Part 3]? Imagine that rule triggers, and you find a weird PowerShell command in the logs.

Copy the log, go to your offline Ollama terminal, and ask it:

You: “You are an expert SOC Analyst. Explain what this command does in simple terms, and tell me if it is malicious: powershell.exe -nop -w hidden -EncodedCommand JABz...“

Local AI: *”This is a highly suspicious command.

1. -nop (NoProfile) stops PowerShell from loading user settings, often used to bypass local restrictions.
2. -w hidden hides the window from the user.
3. -EncodedCommand takes a Base64 encoded string to hide the actual script from simple antivirus scanners. Verdict: This is a classic evasion technique used by malware to hide its actions. You should isolate this machine immediately.”*

Tying it Back to the Watchtower

In [Part 5 of the Watchtower Chronicles], we talked about Alert Fatigue and using SOAR to automate the boring stuff.

Local AI is the next evolution of that concept. By running tools like Ollama, a Tier 1 Analyst doesn’t have to spend 20 minutes Googling obscure command-line flags. The local AI translates the technical gibberish into a clear threat narrative in seconds.

It dramatically speeds up your OODA Loop (Observe, Orient, Decide, Act), allowing you to triage alerts faster, accurately, and—most importantly—with absolute data privacy.

Conclusion

AI is going to change cybersecurity forever. But as defenders, our first job is protecting data. By mastering local open-source models, you give yourself a massive career advantage. You become an analyst who knows how to leverage the future without compromising the present.

Go download Ollama, feed it some fake logs, and see how it changes your workflow. Happy (and private) hunting!

Disclaimer

This article is for educational purposes. Running local LLMs requires a decent amount of RAM (typically 8GB to 16GB minimum for smooth operation). Always consult your company’s IT policies before installing new software on corporate devices, even offline tools.

Links to the Previous Watchtower Chronicles

https://secure-scroll.com/2026/01/22/the-watchtower-chronicles-part-1-decoding-the-soc-the-essential-vocabulary/

In Part 1, we learned the language of the SOC. Now, we must give our Watchtower the ability to see. Without data, an analyst is blind. Today, we learn the art of Visibility.

Welcome back to The Watchtower Chronicles.

In our last article(https://secure-scroll.com/?p=160), we defined the vocabulary of the SOC. We talked about “Alerts,” “Incidents,” and “SIEMs.” But there is a fundamental truth in cybersecurity that overrides everything else:

“You cannot detect what you cannot see.”

If a hacker breaks into a server, but that server isn’t generating logs, the attack didn’t “happen”—at least, not to the SOC. To the Blue Team, it is invisible.

In this chapter, we are going to explore Visibility. We will look at the “Golden Sources” of data you need to collect, why “more data” isn’t always better, and how to turn on the single most important log in Windows.

The “Golden Triangle” of Data

You can’t log everything. It costs too much money and slows down the network. A smart SOC prioritizes the Golden Triangle of visibility.

1. Identity Logs (The “Who”)

Attacks almost always involve stealing credentials. If you know who is logging in, you can spot anomalies.

• What to watch: Failed logins, Logins at weird times (3 AM), or Logins from weird places (VPN from North Korea).
• Key Windows Events: 4624 (Success), 4625 (Failure).

2. Endpoint Logs (The “What”)

The endpoint (laptop/server) is the battlefield. This is where the malware runs. You need to know what programs are executing.

• What to watch: Process Creation (e.g., powershell.exe launching unknown_file.exe).
• Key Windows Event: 4688 (Process Creation).

3. Network Logs (The “Where”)

malware needs to “phone home” to the hacker to get instructions (C2 – Command and Control). Network logs show this conversation.

• What to watch: Connections to bad IP addresses, or huge data transfers (Data Exfiltration) leaving the network.
• Source: Firewalls (Palo Alto, Fortinet) or DNS Server logs

Here is the complete draft for Part 2 of your series.

This article shifts from “Definitions” to “Action.” It explains what data a SOC Analyst actually looks at and teaches the reader how to turn on the most important logging setting in Windows.

Quality vs. Quantity (Garbage In, Garbage Out)

A common mistake beginners make is thinking, “I’ll just log everything!”

This leads to Alert Fatigue. If you log every time a user opens a Word document, your analysts will drown in millions of useless events. The goal of a SOC Engineer is Tuning—filtering out the noise so the Analyst only sees the signal.

• Bad Log: “User Bob opened Chrome.” (Who cares?)
• Good Log: “User Bob opened Chrome and it immediately downloaded an .exe file.” (Suspicious.)

Tutorial: Turning on the Lights (Windows Command Line Logging)

Let’s make this practical. By default, Windows is actually very quiet. It will tell you “PowerShell started,” but it won’t tell you what PowerShell did.

• Default Log: PowerShell.exe started. (Useless).
• What we need: PowerShell.exe started -Command "Download-Malware.ps1"

To see the hacker’s commands, you must enable “Include Command Line in Process Creation Events.”

How to do it (On your own lab machine):

1. Open Group Policy Editor (gpedit.msc).
2. Navigate to: Computer Configuration -> Administrative Templates -> System -> Audit Process Creation.
3. Double click “Include command line in process creation events”.
4. Set it to Enabled.

Now, when you look at Event ID 4688 in your Event Viewer, you will see exactly what the hacker typed. This single setting has caught more bad guys than almost any other.

The Central Brain: The SIEM

So we have Identity logs, Endpoint logs, and Network logs. But we can’t log into 500 different servers to read them.

We need to send them all to one place. This is the SIEM (Security Information and Event Management).

• Collection: Agents (like Splunk Forwarder or Wazuh Agent) sit on the laptops and ship the logs to the SIEM.
• Correlation: The SIEM links them together.
  • Log 1 (Firewall): “Connection from Russia.”
  • Log 2 (Server): “Failed Login.”
  • SIEM Alert: “Brute Force Attack from Russia detected!”

Coming Up Next…

Now that we have the Vocabulary (Part 1) and the Data (Part 2), we are ready to teach the machine how to spot evil.

In Part 3: Signal in the Noise, we are going to write our very first Detection Rule. We will take that log we just enabled (Event 4688) and write logic to catch a real-world attack.

Get your logic gates ready

Disclaimer

This article is for educational purposes. Modifying Group Policy (GPO) and Audit settings can increase log volume significantly. Always test in a lab environment before applying changes to a production network.

Before you can walk the walk, you must talk the talk. Welcome to Part 1 of our SOC Monitoring series, where we decode the jargon, acronyms, and slang used by professional defenders.

Imagine walking into a hospital operating room. The doctors are shouting things like “BP is dropping!” or “Push 10cc of Epi!” If you don’t know what those words mean, you can’t help save the patient.

The Security Operations Center (SOC) is no different. It has its own language. When a crisis hits, clear communication is the difference between stopping a hack and losing data.

In this first installment of The Watchtower Chronicles, we are going to build your dictionary. But this isn’t a boring A-Z list. We are going to learn these terms by following the lifecycle of an attack.

Phase 1: The Signals (What are we looking at?)

In a SOC, data flows in constantly. You need to know the difference between a harmless noise and a gunshot.

1. Event

• Definition: Anything that happens on a system. It is neutral—neither good nor bad.
• Example: “User Bob logged in.” “File A was opened.”
• Analogy: Hearing a car drive past your house.

2. Alert

• Definition: An event (or series of events) that triggers a warning because it looks suspicious.
• Example: “User Bob logged in at 3 AM from Russia.”
• Analogy: Hearing a car screech its tires and stop in front of your house.

3. Incident

• Definition: A confirmed security breach or attack. An alert becomes an incident when a human verifies it is bad.
• Example: “We confirmed Bob’s account was hacked and is downloading database files.”
• Analogy: Seeing someone break your window and jump inside.

4. False Positive

• Definition: An alert that looked bad but turned out to be harmless. The bane of an Analyst’s existence.
• Example: An alert triggers for “Malware Download,” but it turns out the user was just downloading a new video game installer that looked weird.

Phase 2: The Evidence (What did we find?)

Once we have an Incident, we start looking for clues. These clues have specific names.

5. IOC (Indicator of Compromise)

• Definition: A piece of forensic evidence that proves a known attack happened. It is static and precise.
• Example: A specific bad IP address (192.168.1.50), a Virus Hash (MD5: e5d2...), or a malicious domain name (evil-site.com).
• Analogy: Finding a fingerprint or a specific drop of blood at a crime scene.

6. IOA (Indicator of Attack)

• Definition: Evidence that an attack is currently happening or about to happen. It focuses on the intent rather than the specific tool.
• Example: “A persistence registry key was created” or “Powershell is running a hidden command.”
• Analogy: Seeing the door handle jiggle.

7. TTPs (Tactics, Techniques, and Procedures)

• Definition: The behavioral patterns of the hacker. Not what tool they used (IOC), but how they work.
• Example: “This hacker group (APT28) always sends phishing emails on Fridays and uses a specific PowerShell script to steal passwords.”
• Analogy: Knowing that a specific burglar always enters through the chimney and steals only silverware.

Phase 3: The Tools (What are we using?)

You can’t do the job without the gear.

8. SIEM (Security Information and Event Management)

• Pronounced: “Sim”
• Definition: The “Brain” of the SOC. It collects logs from everywhere (firewalls, servers, laptops), correlates them, and generates alerts.
• Example Tools: Splunk, Microsoft Sentinel, Wazuh, Elastic.

9. EDR (Endpoint Detection and Response)

• Definition: Advanced antivirus on steroids. It records exactly what happens on a laptop (process creation, network connections) and allows you to remotely kill viruses.
• Example Tools: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne.

10. SOAR (Security Orchestration, Automation, and Response)

• Pronounced: “Soar”
• Definition: The robots. Software that automates boring tasks.
• Example: If a phishing email is detected, the SOAR tool automatically blocks the sender and deletes the email from all inboxes without a human lifting a finger.

Phase 4: The Scorecard (How well are we doing?)

Finally, managers need to measure success. These are the metrics we discussed earlier.

11. Dwell Time

• Definition: The time a hacker sits inside your network undetected.
• Goal: Reduce from Months $\rightarrow$ Hours.

12. MTTD (Mean Time to Detect)

• Definition: How fast does your alarm ring? The average time it takes to spot an active threat.

13. MTTR (Mean Time to Respond/Remediate)

• Definition: How fast do you put out the fire? The average time to kick the hacker out after finding them.

Conclusion

This vocabulary is your toolkit.

When you read a job description, an incident report, or the rest of this article series, these terms will appear constantly.

Now that we speak the language, we are ready to enter the control room.

In Part 2, we will look at “The Eyes of the Beast”—learning how to set up the Logs and Visibility needed to catch a hacker in the act.

Disclaimer

This article is for educational purposes only. Definitions in the cybersecurity industry can vary slightly between organizations and vendors. These definitions represent the generally accepted industry standard.