Password Spraying Attack & Defense

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>>"
}