FaresMorcy
  • Whoami
  • Footprinting Labs
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Shells & Payloads
    • The Live Engagement
  • Password Attacks
    • Lab - Easy
    • Lab - Medium
    • Lab - Hard
  • Active Directory Enumeration & Attacks
    • Active Directory Enumeration & Attacks
    • AD Enumeration & Attacks - Skills Assessment Part I
    • AD Enumeration & Attacks - Skills Assessment Part II
  • SOC Hackthebox Notes & Labs
    • Security Monitoring & SIEM Fundamentals Module
    • Windows Event Logs & Finding Evil Module
    • Introduction to Threat Hunting & Hunting With Elastic Module
    • Understanding Log Sources & Investigating with Splunk Module
      • Introduction To Splunk & SPL
      • Using Splunk Applications
      • Intrusion Detection With Splunk (Real-world Scenario)
      • Detecting Attacker Behavior With Splunk Based On TTPs
      • Detecting Attacker Behavior With Splunk Based On Analytics
      • Skills Assessment
    • Windows Attacks & Defense
      • Kerberoasting
      • AS-REProasting
      • GPP Passwords
      • GPO Permissions/GPO Files
      • Credentials in Shares
      • Credentials in Object Properties
      • DCSync
      • Golden Ticket
      • Kerberos Constrained Delegation
      • Print Spooler & NTLM Relaying
      • Coercing Attacks & Unconstrained Delegation
      • Object ACLs
      • PKI - ESC1
      • Skills Assessment
    • Intro to Network Traffic Analysis Module
    • YARA & Sigma for SOC Analysts Module
      • Developing YARA Rules
      • Hunting Evil with YARA (Windows Edition)
      • Hunting Evil with YARA (Linux Edition)
      • Sigma and Sigma Rules
      • Developing Sigma Rules
      • Hunting Evil with Sigma (Chainsaw Edition)
      • Hunting Evil with Sigma (Splunk Edition)
      • Skills Assessment
  • TryHackme SOC 1
    • TShark
      • TShark: The Basics
      • TShark: CLI Wireshark Features
      • TShark Challenge I: Teamwork
      • TShark Challenge II: Directory
    • Tempest
    • Boogeyman 1
    • Boogeyman 2
    • Boogeyman 3
  • TryHackme SOC 2
    • Advanced Splunk
      • Splunk: Exploring SPL
      • Splunk: Setting up a SOC Lab
      • Splunk: Dashboards and Reports
      • Splunk: Data Manipulation
      • Fixit
    • Advanced ELK
      • Slingshot
    • Threat Hunting
      • Threat Hunting: Foothold
      • Threat Hunting: Pivoting
      • Threat Hunting: Endgame
  • TryHackme Rooms
    • Investigating Windows
    • Splunk 2
    • Windows Network Analysis
  • Powershell Scripting Fundamentals
  • SANS SEC504 & Labs
    • Book one
      • Live Examination
      • Network Investigations
      • Memory Investigations
      • Malware Investigations
      • Accelerating IR with Generative AI
      • Bootcamp: Linux Olympics
      • Bootcamp: Powershell Olympics
    • Book Two
      • Hacker Tools and Techniques Introduction
      • Target Discovery and Enumeration
      • Discovery and Scanning with Nmap
      • Cloud Spotlight: Cloud Scanning
      • SMB Security
      • Defense Spotlight: Hayabusa and Sigma Rules
    • Book Three
      • Password Attacks
      • Cloud Spotlight: Microsoft 365 Password Attacks
      • Understanding Password Hashes
      • Password Cracking
      • Cloud Spotlight: Insecure Storage
      • Multipurpose Netcat
    • Book Four
      • Metasploit Framework
      • Drive-By Attacks
      • Command Injection
      • Cross-Site Scripting
      • SQL Injection
      • Cloud Spotlight: SSRF and IMDS
    • Book Five
      • Endpoint Security Bypass
      • Pivoting and Lateral Movement
      • Hijacking Attacks
      • Establishing Persistence
      • Defense Spotlight: RITA
      • Cloud Spotlight: Cloud Post-Exploitation
  • SANS SEC511 & Labs
    • Resources
      • Primers
      • References
      • Tools
        • Network
        • Elastic Stack
      • Printable Versions
    • Book One
      • Part One
      • Part Two
      • Part Three
    • Book Two
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Three
      • Part One
      • Part Two
      • Part Three
      • Part Four
    • Book Four
      • Part One
      • Part Two
      • Part Three Lab
      • Part Four Lab
    • Book Five
      • Part One Lab
      • Part Two Lab
      • Part Three Lab
  • CyberDefenders
    • XXE Infiltration Lab
    • T1594 Lab
    • RetailBreach Lab
    • DanaBot Lab
    • OpenWire Lab
    • BlueSky Ransomware Lab
    • Openfire Lab
    • Boss Of The SOC v1 Lab
    • GoldenSpray Lab
    • REvil Lab
    • ShadowRoast Lab
    • SolarDisruption Lab
    • Kerberoasted Lab
    • T1197 Lab
    • Amadey Lab
    • Malware Traffic Analysis 1 Lab
    • Insider Lab
    • Volatility Traces Lab
    • FalconEye Lab
    • GitTheGate Lab
    • Trident Lab
    • NerisBot Lab
  • Practical Windows Forensics
    • Data Collection
    • Examination
    • Disk Analysis Introduction
    • User Behavior
    • Overview of disk structures, partitions and file systems
    • Finding Evidence of Deleted Files with USN Journal Analysis
    • Analyzing Evidence of Program Execution
    • Finding Evidence of Persistence Mechanisms
    • Uncover Malicious Activity with Windows Event Log Analysis
    • Windows Memory Forensic Analysis
  • Hackthebox Rooms
    • Campfire-1
    • Compromised
    • Brutus
    • Trent
    • CrownJewel-1
  • WEInnovate Training
    • Weinnovate - Active Directory Task One
    • Build ELK Lab
      • Configure Elasticsearch and Kibana setup in ubuntu
      • Configure Fluent-Bit to send logs to ELK
      • Set up Winlogbeat & Filebeat for log collection
      • Send Logs from Winlogbeat through Logstash to ELK
      • Enable Windows Audit Policy & Winlogbeat
      • Elasticsearch API and Ingestion Pipeline
    • SOAR
      • Send Alerts To Email & Telegram Bot
      • Integrate Tines with ELK
    • SOC Practical Assessment
    • Lumma C2
    • Network Analysis
  • Build ELK Lab
    • Configure Elasticsearch and Kibana setup in ubuntu
    • Configure Fluent-Bit to send logs to ELK
    • Set up Winlogbeat & Filebeat for log collection
    • Send Logs from Winlogbeat through Logstash to ELK
    • Enable Windows Audit Policy & Winlogbeat
    • Elasticsearch API and Ingestion Pipeline
  • Build Home Lab - SOC Automation
    • Install & configure Sysmon for deep Windows event logging
    • Set up Wazuh & TheHive for threat detection & case management
    • Execute Mimikatz & create detection rules in Wazuh
    • Automate everything with Shuffle
    • Response to SSH Attack Using Shuffle, Wazuh, and TheHive
  • Home Lab (Attack & Defense Scenarios)
    • Pass-the-Hash Attack & Defense
    • Scheduled Task Attack & Defense
    • Kerberoasting Attack & Defense
    • Kerberos Constrained Delegation
    • Password Spraying Attack & Defense
    • Golden Ticket Attack & Defense
    • AS-REProasting Attack & Defense
    • DCSync Attack & Defense
  • Home Lab (FIN7 (Carbanak Group) – Point of Sale (POS) Attack on Hospitality Chains)
  • Home Lab (Lumma Stealer)
Powered by GitBook
On this page
  1. Home Lab (Attack & Defense Scenarios)

Password Spraying Attack & Defense

PreviousKerberos Constrained DelegationNextGolden Ticket Attack & Defense

Last updated 1 month ago

Setting Up the Environment

To apply this scenario in your home lab, you need the following:

✅ Windows Server (Domain Controller - DC)

✅ Windows Client (Domain-Joined Machine)

✅ Ubuntu Machine (Elasticsearch & Kibana)

✅ Ubuntu Machine (TheHive)

​Before initiating the attack, we must install Winlogbeat on the Windows server to collect logs and send them to Elasticsearch.​

Please review this for the installation:

​Below is the winlogbeat.yaml configuration file:​

Password spraying is a type of brute-force attack where an attacker tries a single, common password against multiple user accounts before moving on to another password and repeating the process. This technique is used to avoid account lockout policies that trigger after a certain number of failed login attempts.

Before initiating a Password Spraying attack simulation, it is essential to enable auditing for both successful and failed login attempts.

To conduct this attack and analyze the resulting logs, we will install and utilize the DomainPasswordSpray.ps1 tool.

Invoke-WebRequest -Uri https://raw.githubusercontent.com/dafthack/DomainPasswordSpray/refs/heads/master/DomainPasswordSpray.ps1 -OutFile DomainPasswordSpray.ps1 
Import-Module .\DomainPasswordSpray.ps1

​After installing the tool, let's proceed to execute the attack against the domain Main.local.​

Invoke-DomainPasswordSpray -Password Admin123! -UserList .\users.txt -Domain Main.local  -Force

Before analyzing the logs in ELK, let's first review the events that occurred from PowerShell.

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625} -MaxEvents 20
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625} -MaxEvents 10 | ForEach-Object { "Target User: $($_.Properties[5].Value)" }

Now, let's access the ELK logs and filter for event code 4625.​

​Let's add additional columns, such as 'hostname' and 'username', to enhance our data set.​

We need to establish a threshold rule that triggers an alert when the count of unique usernames surpasses a specified limit within a defined timeframe, with grouping based on the hostname field.

Next, we need to scroll down to proceed with creating the rule.

This rule triggers an alert when five authentication failure events occur for different usernames on the same hostname in five minutes.

This rule means:

  • At each execution (every 1 minute), the rule analyzes data collected over the last 5 minutes (the look-back time).

  • For example, if the rule runs at 5:21 PM, it will check data from 5:16 PM to 5:21 PM. Then, at 5:22 PM, it will check data from 5:17 PM to 5:22 PM, and so forth.

For password spray detection, the rule interval should be set to match or be shorter than the look-back time for continuous monitoring, ensuring no attacks are missed. However, if system resources are limited, increasing the interval to 5-10 minutes with a look-back time of 10-30 minutes balances performance and detection timeliness. For practice, let's configure the rule to run every minute with a loopback time of five minutes.

Next, let's rerun the attack and check if an alert was triggered.

Let's proceed with reviewing the alerts.

These rules are not the final production-ready versions. When deploying them in real-world environments, they need to be continuously tuned to minimize false positives as much as possible.

To automatically forward this alert to Tines, a Gold license is required. However, since we do not have one, we cannot utilize Tines' webhook URL for this purpose. Instead, we will send an HTTP request to retrieve alerts from the ELK stack and schedule this request to run every 10 minutes to check for new alerts.

Before proceeding, we need to create an API key with the necessary privileges to retrieve alerts.

{
  "superuser": {
    "cluster": [
      "all"
    ],
    "indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "all"
        ],
        "allow_restricted_indices": true
      },
      {
        "names": [
          "*"
        ],
        "privileges": [
          "monitor",
          "read",
          "view_index_metadata",
          "read_cross_cluster"
        ],
        "allow_restricted_indices": true
      }
    ],
    "applications": [
      {
        "application": "kibana-.kibana",
        "privileges": [
          "feature_alerting.all",
          "all"
        ],
        "resources": [
          "*"
        ]
      }
    ],
    "run_as": [
      "*"
    ],
    "metadata": {},
    "transient_metadata": {
      "enabled": true
    },
    "remote_indices": [
      {
        "names": [
          "*"
        ],
        "privileges": [
          "all"
        ],
        "allow_restricted_indices": false,
        "clusters": [
          "*"
        ]
      },
      {
        "names": [
          "*"
        ],
        "privileges": [
          "monitor",
          "read",
          "view_index_metadata",
          "read_cross_cluster"
        ],
        "allow_restricted_indices": true,
        "clusters": [
          "*"
        ]
      }
    ],
    "remote_cluster": [
      {
        "privileges": [
          "monitor_enrich",
          "monitor_stats"
        ],
        "clusters": [
          "*"
        ]
      }
    ]
  }
}

We can retrieve the alerts triggered in ELK by accessing the following URL:

https://192.168.204.146:9200/.kibana_alerting_cases/_search?_source=alert&filter_path=hits.hits._source.alert

First, we will send a GET request to this URL using the previously generated API key.

curl -k -X GET "https://192.168.204.146:9200/.kibana_alerting_cases/_search?_source=alert&filter_path=hits.hits._source.alert" 
-H "Authorization: ApiKey Vi1BWmFaVUJQUXNLZV9FNWFsVnk6eUtOUDhNZlpRNC0xNzBQbWpBSDRkUQ==" | jq

Let's begin our workflow on Tines by sending an HTTP request to retrieve alerts from this endpoint. However, before proceeding, we need to use Ngrok to expose the ELK stack publicly, allowing Tines to send HTTP requests to it.

ngrok http https://your-ip:9200/

We are now able to retrieve the alerts. Let's proceed.

Now, let's run the HTTP request.

Let's schedule this request to run every 10 minutes to check for new alerts.

We have received the alerts and can forward them to any desired destination. Now, let's utilize this alert to send a notification to our Telegram bot and create a case in TheHive.

Let's rerun the workflow to verify if any output is received in our Telegram bot.

We also want to create a case in TheHive using the alert information.

We need to use Ngrok here as well because TheHive is hosted on our local machine. This allows us to expose TheHive's URL publicly, enabling Tines to send HTTP requests for case creation.

The following elements must be added to ensure the case is successfully created in TheHive.

{
  "title": "<<get_alerts.body.hits.hits[0]._source.alert.name>>",
  "description": "<<get_alerts.body.hits.hits[0]._source.alert.params.description>>",
  "severity": 2,
  "type": "<<get_alerts.body.hits.hits[0]._source.alert.params.ruleSource.type>>",
  "source": "ELK",
  "sourceRef": "<<get_alerts.body.hits.hits[0]._source.alert.params.ruleId>>",
  "date ": "<<get_alerts.body.hits.hits[0]._source.alert.createdAt>>"
}

Now, let's rerun the workflow to verify whether the case is created successfully.

You may include a summary and MITRE tags to enhance the case's informativeness.

To set up a Telegram bot, please refer to the following guide: .

WWe also require the API key to create a case on TheHive. To obtain it, please visit the following URL: .

Telegram Bot Setup
https://faresbltagy.gitbook.io/footprintinglabs/build-home-lab-soc-automation/automate-everything-with-shuffle
https://faresbltagy.gitbook.io/footprintinglabs/weinnovate-training/build-elk-lab/set-up-winlogbeat-and-filebeat-for-log-collection