Designing and Validating MITRE ATT&CK–Aligned SOC Alert Rules for End-to-End TTP Detection

---

Student Name: Tan Amos

Student Code: s22

Class Code: CCK3_250714

Institute: Centre for Cybersecurity

Trainer: Samson

---

1. Introduction

Project Breach Trace is the second part of a breach simulation series, under the Security Operations Centre (SOC) track. This report documents a complete offensive-to-defensive workflow in a controlled lab, where simulated attacker TTPs are executed and then detected through SOC-style monitoring and alerting.

In a VMware Workstation virtual LAN, attacks were launched from a Kali Linux VM against a Windows Server 2019 Domain Controller and a Linux web server, with pfSense (Snort-enabled) providing network visibility and Elastic Security/Kibana serving as the central SIEM for analysis.

The work focuses on turning observable adversary behaviour into actionable detections by creating and validating alert rules aligned to each scenario, including SSH brute force, SMB brute force, SMB enumeration, SMB-based file exfiltration, hash dumping and Pass-the-Hash to obtain a DC shell, and an ICMP flood DoS. Results matched expectations end-to-end: 6 custom rules created → 6 attacks executed → 6 types of alerts triggered.

---

2. Lab Environment and Topology

2.1 Topology

All attacks originated from the Kali Linux attacker VM (172.16.50.52) within a VMware Workstation virtual LAN lab. Security telemetry was ingested into the ELK server (172.16.50.2) and investigated using Elastic Security/Kibana, with pfSense/Snort contributing network IDS events for the DoS scenario.

2.2 Systems and IP Addresses

• pfSense (Netgate) firewall/router + Snort IDS: 172.16.50.1

• ELK Linux server (Elastic Stack / Kibana): 172.16.50.2

• Domain Controller (Windows Server 2019): 172.16.50.254

• Linux Web Server: 172.16.100.20

• Kali Linux (attacker): 172.16.50.52

2.3 Data Sources, Indices, and Data View

• Primary security events index pattern: logs-* (used for attacks #1–#5)

• Firewall/IDS (pfSense/Snort) index pattern: logs-pfelk-* (used for DoS attack #6)

• Note: The active Elastic Security data view determines which indices appear on Elastic Security pages and which indices detection rules can query.

---

3. Log Prerequisites and Ingestion Setup

This section summarizes the minimum logging and ingestion prerequisites I enabled so that Elastic Security received the right level of detail (event codes, fields, and context) to support the alert rules built for each attack scenario.

3.1 Windows Domain Controller logging prerequisites (DC: 172.16.50.254)

A) Advanced Audit Policy Configuration (via Group Policy)

To ensure authentication, SMB, and object-access activity produced consistent Security Event Logs for detection, I enabled Advanced Audit Policy subcategories on the Domain Controller via Group Policy.

Steps:

• Open Group Policy Management on the DC.

• Create or edit a GPO linked to the domain/OU containing the DC.

• Navigate to:

  Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies

• Enable the required audit subcategories (Success/Failure as appropriate).

• Run gpupdate /force and confirm events appear in Event Viewer → Windows Logs → Security.

Audit subcategories enabled:

• Logon/Logoff

  • Audit Logon (Success/Failure)

  • Audit Account Lockout (Failure)

  • Audit Special Logon (Success)

• Account Logon

  • Audit Credential Validation (Success/Failure)

• Object Access (for SMB/share activity)

  • Audit File Share (Success/Failure)

  • Audit Detailed File Share (Success/Failure)

• Detailed Tracking

  • Audit Process Creation (Success)

Rationale:

• Brute force and Pass-the-Hash patterns rely on authentication events.

• SMB enumeration/exfiltration relies on share/file-share access auditing.

• Process creation improves investigation context (what executed, when, and by whom).

B) Sysmon installed and configured

Sysmon was installed to add higher-fidelity endpoint telemetry (process, network, and related activity) beyond default Windows logs.

Steps:

• Download Sysmon from Microsoft Sysinternals on the Domain Controller and extract it (example folder: C:\Tools\Sysmon).

• Place your Sysmon configuration XML in the same folder (example: C:\Tools\Sysmon\sysmonconfig.xml).

• Open PowerShell as Administrator.

• Change directory into the Sysmon folder:

  • cd C:\Tools\Sysmon

• Install Sysmon and load the configuration (accept the EULA):

  • Sysmon64.exe -accepteula -i C:\Tools\Sysmon\sysmonconfig.xml

• Confirm Sysmon is installed and running:

  • Open Services (services.msc) → verify Sysmon64 is Running

  • OR run: sc query Sysmon64

• If you need to update the configuration later, apply it without reinstalling:

  • Sysmon64.exe -c C:\Tools\Sysmon\sysmonconfig.xml

• Confirm events are being written:

  • Open Event Viewer and navigate to the Sysmon Operational log (Applications and Services Logs → Microsoft → Windows → Sysmon → Operational).

  • Verify that recent Sysmon events are appearing (you should see new entries shortly after normal activity).

---

3.2 Shipping Windows logs into ELK (logs-*)

Windows events from the DC were forwarded to the ELK server (172.16.50.2) so that Elastic Security could query them in logs-* for attacks #1 - #5.

What was shipped:

• Windows Security Event Log (authentication + SMB/share auditing)

• Sysmon Operational log (enhanced endpoint telemetry)

Ingestion method (Winlogbeat):

• Install Winlogbeat on the DC (common path: C:\Program Files\Winlogbeat\).

• Open winlogbeat.yml as Administrator and configure these Windows event channels:

  • Security

  • Microsoft-Windows-Sysmon/Operational

• Configure the output so logs are sent to your ELK pipeline on 172.16.50.2 (direct to Elasticsearch or via Logstash — whichever your lab uses).

• Enable Sysmon parsing/normalization so Sysmon events map into useful structured fields in Elastic (module/pipeline depending on your setup).

• Run validation tests from an elevated PowerShell:

  • winlogbeat test config

  • winlogbeat test output

• Install Winlogbeat as a service (if not already installed) and start it:

  • Typical flow: winlogbeat.exe install-service

  • Then: Start-Service winlogbeat

• Confirm Winlogbeat is running and sending events:

  • Check Services for winlogbeat = Running

  • In Kibana Discover, filter for host.ip: 172.16.50.254 and confirm Security + Sysmon events are arriving under logs-*.

3.3 Linux web server logging prerequisites (172.16.100.20)

To support SSH brute force detection and investigation, Linux authentication logs were collected and shipped to ELK.

Steps:

• Confirm SSH authentication is logging locally on the Linux web server:

  • Debian/Ubuntu: /var/log/auth.log

  • RHEL/CentOS: /var/log/secure

• Install your log shipper (Elastic Agent or Filebeat) on the Linux web server.

• Enable collection for authentication/system logs:

  • If using Filebeat: enable the system module (auth).

• Ensure the shipper is reading the correct auth log path for your distro (auth.log vs secure).

• Configure output to forward events to ELK (172.16.50.2) using your lab’s pipeline (Elasticsearch/Logstash).

• Start the shipper and confirm it stays running:

  • Check service status and logs to ensure there are no connection/parsing errors.

• Generate a clear test event:

  • Perform 1–2 failed SSH logins so you can easily validate ingestion and field parsing.

3.4 pfSense + Snort (DoS telemetry source via logs-pfelk-*)

The ICMP flood DoS scenario was detected using Snort on pfSense (172.16.50.1). These IDS alerts were forwarded into ELK and stored under logs-pfelk-*, which was used only for the DoS detection rule.

Steps:

• Install Snort on pfSense:

  • pfSense UI → System → Package Manager → Available Packages

  • Search Snort → Install

• Enable Snort on the correct interface:

  • Services → Snort → Interfaces

  • Add/select the interface that carries your lab traffic (LAN/internal)

  • Enable Snort on that interface

• Configure baseline Snort settings so alerts are generated and logged:

  • Ensure alert logging is enabled for the interface

  • Set protected networks appropriately (HOME_NET should cover your lab subnets, e.g., 172.16.50.0/24 and 172.16.100.0/24)

• Enable ICMP flood-related rules/signatures:

  • In Snort rule management/categories, enable the rules that generate ICMP flood alerts

• Verify Snort is generating alerts:

  • Trigger a short ICMP burst first (safe test)

  • Confirm an alert appears in the Snort alerts view

• Forward pfSense/Snort logs to ELK (pfELK pipeline):

  • pfSense → Status → System Logs → Settings

  • Configure Remote Logging Options to send logs to 172.16.50.2

  • Ensure Snort alert logs are included in what gets forwarded (based on your pfSense/Snort logging settings)

• Confirm logs land in Kibana under logs-pfelk-*:

  • Kibana Discover → select data view including logs-pfelk-*

  • Filter for pfSense/Snort events and confirm ICMP alerts appear with timestamps matching your tests

---

4. Detection Content Overview

4.1 Rules created

I created one detection rule per attack scenario, resulting in 6 custom rules: 5 Threshold rules (SSH brute force, SMB brute force, SMB enumeration, SMB exfiltration, ICMP flood/DoS via Snort events) and 1 Event Correlation rule using EQL (Pass-the-Hash leading to a successful shell on the Domain Controller).

Threshold rules were used where attacker behaviour produces a burst or high count of similar events in a short window (for example, repeated authentication failures or repeated IDS alerts), making them well-suited for brute force and flood-style patterns.

The Pass-the-Hash scenario was implemented as an EQL Event Correlation rule because it is best validated as a sequence of related events occurring within a defined timeframe, rather than a single-count threshold.

4.2 Dashboards used

To track security activity and confirm the rules were functioning as intended, I used Elastic Security’s built-in dashboards:

• Overview dashboard — provides a high-level snapshot of current alerts and events during the testing window.

• Detection rule monitoring dashboard — provides visibility into detection rule execution, including whether rules are running successfully and their overall health/performance.

4.3 Creating Detection Rules in Kibana

All alert rules in this project were created from the Elastic Security interface using the following navigation path:

• Left menu → Security → Rules → Detection rules (SIEM) → Create new rule

From the “Create new rule” workflow, I selected the appropriate rule type (Threshold for burst/count-based attacks and Event Correlation (EQL) for the Pass-the-Hash sequence), set the data source (for example, logs-* or logs-pfelk-*), and configured the query, threshold/correlation logic, schedule, and alert metadata before enabling the rule.

---

5. Attack-by-Attack Validation

This section validates each attack scenario by showing (1) the attacker activity, (2) the detection rule created for that activity, and (3) the alert generated in Elastic Security.

Note: All attacks were executed by running the Project Breach Point (Part 1) script with added functionality implemented for Breach Trace; this report focuses on detection outcomes, so refer to the accompanying .sh file for the full commands and execution details.

For consistency, each subsection follows the same evidence flow: Terminal output → Rule configuration + logic → Alert triggered (Alerts page).

---

5.1 Attack 1 — SSH brute force on Linux Web Server

MITRE ATT&CK: Brute Force: Password Guessing (T1110.001)

From Kali (172.16.50.52), I used Hydra to execute an SSH brute force attempt against the Linux web server (172.16.100.20) to generate repeated authentication failures within a short time window.

Rule built (Threshold; index: logs-*****):

KQL: host.os.type: linux AND event.category: authentication AND event.action: ssh_login AND event.outcome: failure

Group by: source.ip, host.name

Detection logic:

Alert when a single source IP generates ≥ 10 failed SSH logins against the same host within a ~2-minute rolling window (example: runs every 1 min, additional look-back 1 min).

Rationale:

• Linux + authentication + ssh_login narrows the rule to SSH login attempts only (not other log types), using ECS categorization and the more specific event.action field.

• event.outcome: failure isolates the brute-force signal (repeated failures).

• Group by source.ip + host.name keeps the alert actionable (who attacked what) and matches how Elastic models SSH brute force (same source → same target).

• Schedule + look-back: Elastic recommends ≥ 1 minute additional look-back to avoid missed alerts if executions drift.

Tuning: Elastic’s prebuilt SSH brute-force rules use high burst thresholds (e.g., 25 failures in 15s or 60 failures in 30s) for noisy environments; in an internal lab, 10 failures in ~2 minutes is a practical baseline that still catches Hydra while reducing “one-off typo” noise.

Validation:

The alert fired during the attack window; source.ip = 172.16.50.52 and destination.ip/host = 172.16.100.20.

---

5.2 Attack 2 — SMB brute force on Domain Controller

MITRE ATT&CK: Brute Force: Password Guessing (T1110.001)

From Kali (172.16.50.52), I used Hydra to perform repeated SMB/NTLM login attempts against the Domain Controller (172.16.50.254) to generate a burst of failed network authentication events.

Rule built (Threshold; index: logs-*****):

KQL: host.os.type: windows AND event.code: 4625 AND winlog.event_data.LogonType: 3

Group by: source.ip, user.name, host.name

Detection logic:

Alert when a single source IP generates ≥ 10 failed network logons (LogonType 3) for the same user + host within a ~2-minute rolling window (example: runs every 1 min, additional look-back 1 min). Elastic recommends ≥ 1 minute additional look-back to reduce missed alerts if rule execution drifts.

Rationale:

• event.code: 4625 targets Windows “account failed to log on” events, which are the primary signal for repeated failed logins during brute force activity.

• winlog.event_data.LogonType: 3 narrows to Network logons (type 3), which is the expected logon type for SMB-style authentication attempts arriving over the network.

• host.os.type: windows keeps the detection focused on Windows authentication telemetry (reducing unrelated non-Windows noise).

• Group by source.ip + user.name + host.name makes the alert precise and actionable by tying the spike to who is being targeted, where, and from which attacker IP (e.g., Kali → DC).

Tuning: Elastic’s prebuilt Windows “multiple logon failure” content looks for high-volume bursts of failed Network logons and uses a very high threshold (example: ≥ 100 failures per 60 seconds) in its reference rule query—appropriate for noisy environments. For an internal lab/DC where you want earlier detection (and have less background noise), 10 failures in ~2 minutes is a reasonable baseline that still reliably catches Hydra without alerting on one-off mistakes.

Validation:

The alert fired during the attack window; source.ip = 172.16.50.52 and destination host = 172.16.50.254 (DC).

---

5.3 Attack 3 — SMB enumeration on Domain Controller

MITRE ATT&CK: Network Share Discovery (T1135)

From Kali (172.16.50.52), I enumerated SMB shares on the Domain Controller (172.16.50.254) using smbclient to identify accessible shares and validate that share-discovery behaviour is visible to Elastic Security.

Rule built (Threshold; index: logs-*****):

KQL: host.os.type: windows AND event.code: 5140 AND winlog.event_data.ShareName: \\*\\IPC$

Group by: source.ip, user.name, host.name

Detection logic:

Alert when a single source IP generates ≥ 3 IPC$ share access events (5140) for the same user + host within a ~5-minute rolling window (example: runs every 1 min, additional look-back 4 min).

Rationale:

• host.os.type: windows scopes the rule to Windows share-access telemetry only, reducing irrelevant matches.

• event.code: 5140 specifically captures “a network share object was accessed,” which is the core event for tracking SMB share access on the DC.

• ShareName: \\*\\IPC$ focuses on the IPC$ administrative share, which exists to support named-pipe communication; share discovery commonly touches IPC$ as part of remote share enumeration workflows.

• Group by source.ip + user.name + host.name keeps the alert actionable by linking the burst to who performed the enumeration, from where, and which host was targeted.

Tuning: Microsoft notes Event 5140 is generated once per session when the first access attempt is made to a share. Because enumeration tools may create multiple short-lived connections/sessions, a lower threshold over a longer window (e.g., 3 in 5 minutes) is a practical baseline for spotting repeated IPC$ access without flagging a single normal connection.

Splunk also highlights that Event IDs 5140/5145 can be used to hunt network share discovery and that repeated IPC$ access patterns can be a sign of share enumeration activity.

Validation:

The alert fired during the attack window; source.ip = 172.16.50.52 and destination host = 172.16.50.254 (DC).

---

5.4 Attack 4 — SMB exfiltration on Domain Controller

MITRE ATT&CK: Exfiltration Over Alternative Protocol (T1048)

From Kali (172.16.50.52), I used smbclient to copy files from the DC’s SMB share (172.16.50.254) to simulate data exfiltration over SMB.

Rule built (Threshold; index: logs-*****):

KQL: host.os.type: windows AND event.code: 5145 AND winlog.event_data.ShareName: \\*\\SMB_share

Group by: host.name, user.name, source.ip

Detection logic:

Alert when a single source IP generates ≥ 30 Event ID 5145 records for SMB_share for the same user + host within a ~5-minute rolling window (example: runs every 1 min, additional look-back 4 min).

Rationale:

• event.code: 5145 is generated by Audit Detailed File Share and records activity at the file/folder access level (i.e., it logs each time a file or folder is accessed through a share), making it suitable for spotting rapid/bulk access typical of copying/exfiltration.

• ShareName: \\*\\SMB_share scopes the detection to the specific share used in the lab exfiltration scenario, reducing noise from normal access to other shares.

• Group by source.ip + user.name + host.name keeps the alert actionable by tying the activity to the originating host (Kali), the account used, and the target system (DC).

• Thresholding is important because Event 5145 can be very noisy: multiple 5145 entries can be generated for a single “user action” (directory listing, file open, read, metadata checks). A count-based rule helps differentiate bulk activity from one-off access.

Tuning: Event 5145 is commonly used by SIEM content to detect high-frequency file copying on network shares. For example, Splunk’s detection logic for “High Frequency Copy Of Files In Network Share” is built on 5145 and evaluates activity in 5-minute buckets with thresholds that only trigger when counts are meaningfully above baseline (including conditions where averages exceed ~20). This supports using a “few dozen in ~5 minutes” range as a starting point, then adjusting based on normal share usage.

Validation:

The alert fired during the attack window; source.ip = 172.16.50.52 and destination host = 172.16.50.254 (DC).

---

5.5 Attack 5 — Hash dump + Pass-the-Hash to DC shell

5.5.1 Hash dump (Credential dumping from DC)

MITRE ATT&CK: OS Credential Dumping: NTDS (T1003.003)

From Kali (172.16.50.52), I used Impacket tooling to dump NTDS-related credential material from the Domain Controller (172.16.50.254) as a prerequisite for the Pass-the-Hash test.

5.5.2 Pass-the-Hash (EQL event correlation rule → shell obtained)

MITRE ATT&CK: Use Alternate Authentication Material: Pass the Hash (T1550.002)

Using the dumped hash material, I authenticated to the Domain Controller (172.16.50.254) without a cleartext password and obtained an interactive shell from Kali (172.16.50.52).

Rule built (Event Correlation / EQL; index: logs-*****):

EQL query:

sample by host.name [ any where event.code: "4776" and winlog.event_data.Status: "0x0" ] [ any where event.code: "4624" and winlog.event_data.LogonType: "3" and winlog.event_data.AuthenticationPackageName: "NTLM" and event.outcome : "success" ] [ any where event.code: "4688" and process.parent.name: "WmiPrvSE.exe" and process.name: "cmd.exe" ] [ any where event.code: "5145" and winlog.event_data.ShareName : "\\\\*\\ADMIN$" and winlog.event_data.RelativeTargetName : "__*" ]

Detection logic:

Alert when the DC shows a correlated set of events consistent with Pass-the-Hash used for remote execution: successful NTLM credential validation → successful NTLM network logon → WMI-spawned cmd.exe → access to an ADMIN$ file beginning with __ (typical of Impacket WMIExec-style command output redirection).

Rationale (succinct):

• 4776 with Status 0x0 indicates successful NTLM credential validation on the DC, making it a strong “authentication succeeded” anchor for correlation.

• 4624 LogonType 3 + NTLM + success confirms a successful network logon using NTLM, which aligns with how PtH is commonly executed over the network (and matches ATT&CK detection guidance focusing on anomalous NTLM LogonType 3 activity).

• 4688 where WmiPrvSE.exe spawns cmd.exe is a high-signal indicator of WMI-based remote execution, a common pattern for Impacket’s WMIExec-like behavior.

• 5145 to \\*\\ADMIN$ with RelativeTargetName: "__*" captures the SMB artifact where command output is redirected to a temp file on ADMIN$ starting with __, which multiple defenders document as a hallmark of Impacket WMIExec activity.

• Why EQL sample by host.name****: EQL’s sample correlates events by a join key (here, the target host) even when timing/order isn’t perfectly consistent across log sources—useful for multi-log-source PtH traces.

Validation:

The correlation alert fired during the attack window on the DC (172.16.50.254), matching the PtH shell activity initiated from Kali (172.16.50.52).

---

5.6 Attack 6 — DoS on Linux Web Server

MITRE ATT&CK: Network Denial of Service: Direct Network Flood (T1498.001)

From Kali (172.16.50.52), I executed an ICMP flood against the Linux web server (172.16.100.20). This scenario was detected using pfSense/Snort telemetry forwarded into Elastic under logs-pfelk-*.

Rule built (Threshold; index: logs-pfelk-*****):

KQL:

network.transport: ICMP AND (destination.ip: 10.0.0.0 to 10.255.255.255 OR destination.ip: 172.16.0.0 to 172.31.255.255 OR destination.ip: 192.168.0.0 to 192.168.255.255)

(These destination ranges represent RFC1918 private networks.)

Group by: source.ip, destination.ip

Detection logic:

Alert when ICMP events from the same source.ip to the same destination.ip exceed ≥ 5 events within 1 minute (example: runs every 1 min, additional look-back 1 min). Elastic recommends ≥ 1 minute additional look-back to reduce missed alerts if rule execution drifts.

Rationale:

• network.transport: ICMP filters specifically for ICMP traffic, which is commonly used in direct network flooding (ping floods).

• Destination limited to RFC1918 ranges keeps the detection focused on internal/private lab targets and avoids unrelated public IP traffic.

• Grouping by source.ip and destination.ip makes the alert actionable (who is flooding which target) and prevents unrelated ICMP traffic from being aggregated together.

Tuning: Because these are pfSense/Snort-derived events (not raw packet captures), a lower threshold (e.g., 5 alerts/events in 1 minute) is usually enough to confirm sustained flooding while avoiding false positives from occasional ping/diagnostic activity. If your dataset logs every ICMP packet (rather than IDS alerts), increase the threshold substantially and tune based on your baseline.

Validation:

The alert fired during the attack window; source.ip = 172.16.50.52 and destination.ip/host = 172.16.100.20.

---

6. Discussion and Improvements

Overall, the detections worked as expected because each rule type matched the underlying “shape” of the attacker behaviour.

Threshold rules were effective for brute force, SMB activity, and ICMP flooding because these actions generate a high-volume burst of similar events (e.g., repeated authentication failures, repeated share access records, or repeated IDS/network events) within a short period.

In contrast, Pass-the-Hash is better represented as a multi-step chain (successful NTLM validation → network logon → follow-on execution and access), so the EQL event correlation rule provided stronger fidelity by correlating related events into a single detection instead of relying on counts alone.

Grouping fields such as source.ip, user.name, and host.name kept alerts specific and actionable by clearly identifying who attacked what.

For a real organization, the main tuning goal would be reducing false positives while keeping early detection. I would baseline “normal” authentication and share-access behaviour per subnet and host role, then apply different thresholds for internet-facing systems vs internal servers, and for privileged accounts vs standard users.

I would also add rule exceptions/allowlists for known admin jump hosts, vulnerability scanners, or scheduled management tools that legitimately generate SMB or authentication noise.

Finally, I would standardize schedules to balance timeliness with reliability and keep a consistent additional look-back to reduce missed detections during rule execution drift, while using severity/risk scoring to prioritize high-confidence alerts (for example, correlation-based PtH detections).

What I would add next:

• Add richer telemetry (e.g., expanded Sysmon coverage and/or network flow/packet visibility) to improve context and reduce ambiguity.

• Create “high-confidence” and “low-confidence” versions of some rules (e.g., brute force) with different severities and thresholds.

• Extend correlation for lateral movement (e.g., combine NTLM logon + remote execution + SMB admin share artifacts into a single investigation view).

• Improve dashboards with drilldowns by attacker IP, targeted hosts, and top usernames, and add a quick “attack timeline” panel per scenario.

• Define response playbooks (triage steps, verification queries, containment actions) linked to each alert for faster analyst workflow.

---

7. Conclusion

This project validated SOC-style detections across six simulated attacks in a controlled lab environment, with every scenario producing the expected alert in Elastic Security.

Threshold rules proved most effective for bursty, high-volume patterns such as SSH/SMB brute force, SMB share activity, and ICMP flood behaviour, where repeated events over a short window are the core signal. For lateral movement using Pass-the-Hash, an EQL event correlation rule provided the highest value by linking multiple related Windows events into a single high-fidelity detection.

Overall, the results demonstrate reliable end-to-end visibility—from attacker execution to SIEM alerting—using both host-based and network/IDS telemetry.

---

8. References

MITRE ATT&CK

MITRE ATT&CK. (n.d.). Brute Force: Password Guessing (T1110.001). https://attack.mitre.org/techniques/T1110/001/

MITRE ATT&CK. (n.d.). Network Share Discovery (T1135). https://attack.mitre.org/techniques/T1135/

MITRE ATT&CK. (n.d.). Exfiltration Over Alternative Protocol (T1048). https://attack.mitre.org/techniques/T1048/

MITRE ATT&CK. (n.d.). OS Credential Dumping: NTDS (T1003.003). https://attack.mitre.org/techniques/T1003/003/

MITRE ATT&CK. (n.d.). Use Alternate Authentication Material: Pass the Hash (T1550.002). https://attack.mitre.org/techniques/T1550/002/

MITRE ATT&CK. (n.d.). Network Denial of Service: Direct Network Flood (T1498.001). https://attack.mitre.org/techniques/T1498/001/

Elastic Security / Kibana (Detections, Alerts, Dashboards, Data Views)

Elastic. (n.d.). Create a detection rule (Threshold rules, Event Correlation/EQL rules). https://www.elastic.co/docs/solutions/security/detect-and-alert/create-detection-rule

Elastic. (n.d.). About detection rules (rule types overview). https://www.elastic.co/docs/solutions/security/detect-and-alert/about-detection-rules

Elastic. (n.d.). Manage detection alerts (Alerts page workflow). https://www.elastic.co/docs/solutions/security/detect-and-alert/manage-detection-alerts

Elastic. (n.d.). Overview dashboard (alerts/events snapshot). https://www.elastic.co/docs/solutions/security/dashboards/overview-dashboard

Elastic. (n.d.). Detection rule monitoring dashboard (rule execution health/performance). https://www.elastic.co/docs/solutions/security/dashboards/detection-rule-monitoring-dashboard

Elastic. (n.d.). Data views and Elastic Security (active data view controls what appears in Security pages). https://www.elastic.co/docs/solutions/security/get-started/data-views-elastic-security

Elastic. (n.d.). Data views (Kibana data view fundamentals). https://www.elastic.co/docs/explore-analyze/find-and-organize/data-views

Windows Logging Prerequisites (Audit Policy + Sysmon)

Microsoft. (2025). Advanced Audit Policy Configuration settings (Windows Server). https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration

Microsoft Sysinternals. (2024). Sysmon (System Monitor). https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon