Windows-RDP-brute-force-attack-simulation-and-defensive-hardening

This project demonstrates a Windows RDP brute-force attack simulation and defensive hardening in a controlled lab using Kali Linux (attacker VM on Hyper-V) and a Windows 10 “server” (target). The lab workflow includes:

• Build the attacker environment: install Kali Linux in Hyper-V by downloading the ISO, creating a VM, installing, and rebooting into Kali.

• Prepare the target for defense: enable Windows Firewall and create an inbound rule to allow RDP on a custom TCP port 45931.

• Hardening change: update Local Security Policy to restrict NTLM by setting “Restrict NTLM: Incoming NTLM traffic” to Deny all accounts.

• Deploy IPBan: verify PowerShell version (5.1+), install IPBan, then configure allowlisting and reduce the default “failed logins before ban” threshold from 5 to 2–3.

• Attack validation: confirm connectivity and services, run Nmap to assess RDP exposure, then perform a Hydra dictionary attack using user.txt and pass.txt.

• Outcome: IPBan detects repeated failures and bans the attacker IP, with evidence in IPBan logs.

---

🛡️ RDP Brute-Force Attack & Defense Lab (Kali + Windows + IPBan)

A hands-on cyber security lab that simulates a brute-force/dictionary attack against Windows Remote Desktop Protocol (RDP) and validates defensive controls using IPBan to detect repeated failures and automatically block offending IPs.

⚠️ Ethical Use Only
This project is for authorized lab environments and defensive learning. Do not run attacks against systems you do not own or explicitly have permission to test.

---

🎯 Objectives

• Build an attacker VM (Kali Linux) on Hyper-V
• Validate RDP exposure and connectivity via scanning
• Execute a controlled Hydra dictionary attack against RDP authentication
• Deploy and tune IPBan on Windows to automatically detect and ban brute-force attempts
• Capture evidence of detection and mitigation from logs

---

🧱 Lab Topology

• Target (Windows 10 server): 192.168.0.1
• Attacker (Kali Linux): 192.168.0.3

🧱 Security Architecture Overview (Mermaid)

flowchart LR

A (Kali Linux\nAttacker) -->|Scan & Login Attempts| B(Windows 10\nRDP Service)

B -->|Failed Logins| C[IPBan]

C -->|Auto Block| D[Windows Firewall]

D -->|Traffic Blocked| A

---

(A) Install Kali Linux on Hyper-V (Attacker VM)

To install Kali Linux on Hyper-V (Draft), you can follow these steps:

1. Download the Kali Linux ISO: You can download the latest Kali Linux ISO image from the official Kali Linux website: https://www.kali.org/downloads/

   

2. Create a new virtual machine in Hyper-V:

• Open Hyper-V Manager.
• Click on "Action" in the menu bar and select "New" -> "Virtual Machine".
• Follow the wizard to create a new virtual machine. Make sure to allocate enough resources (CPU, RAM, disk space) for the virtual machine.

3. Install Kali Linux on the virtual machine:

• Start the virtual machine.

Follow the on-screen instructions to install Kali Linux. You can install it alongside Windows, erase the disk, and install Kali Linux.

4. Complete the installation:

• Once the installation is complete, reboot the virtual machine.

• Log in to Kali Linux using the credentials you set up during the installation process.

• Kali Linux installation Complete

• That's it! You should now have Kali Linux running on Hyper-V. Remember to keep your Kali Linux system updated with the latest security patches and updates.

---

(B) Develop an attack and defence activity.

Configure Windows RDP Access & Firewall (Target)

• Ensure Windows Firewall is ON

• Create an Inbound Rule to allow RDP on the configured port

Protocol: TCP

Port: 45931 (as per lab configuration)

• Click on inbound rules, right click for a new rule, click on port and configure as shown in the screenshot above (TCP, Port 45931).

• Screenshots RDP is allowed on port 45931 in the Windows firewall settings.

• Ensure Windows firewall is turned on after the above configuration.

---

(C) Apply Hardening Control (Target)

Update Local Security Policy:

• Network security: Restrict NTLM: Incoming NTLM traffic → Deny all accounts

This reduces reliance on older authentication mechanisms and aligns with stronger hardening posture.

---

(D) Install and Configure IPBan (Target)

Run PowerShell as Administrator

Confirm PowerShell version:

• $PSVersionTable

Install IPBan

• Copy and paste this link into a webshttps://github.com/jjxtra/IPBan, on the github.com website copied clipboard this command

sudo -i; bash <(wget -qO- https://raw.githubusercontent.com/DigitalRuby/IPBan/master/IPBanCore/Linux/Scripts/Install.sh) and paste into PowerShell and press enter to run the command.

• The screenshot above shows IPBan installation complete.

Open IPBan config:

• Configure whitelist/allowlist for trusted admin IPs

Tune brute-force threshold:

• Reduce failed logins before ban from 5 to 2–3 for quicker enforcement

(A whitelist - allow-list is a cybersecurity strategy that approves a list of email addresses, IP addresses, domain names or applications, while denying all others. IP whitelisting is when you grant network access only to specific IP addresses)

• it is recommended to actually change it to two (2) or three (3) as shown below.

---

(E) 🔍 Attack Simulation

The IPBan service will monitor log events on the server, detect suspicious activity, and dynamically block IP addresses that exceed the configured thresholds.

• The IPBan is running correctly (as seen in the screenshot above)

Activity

1. A Remote Desktop Protocol (DRP) login will be performed to verify the functionality of the IPBan.

• IP addresses for target machine (Windows 10 server) 192.168.0.1
• IP address for attack machine (Kali linux) 192.168.0.3
• Note (Established communications already exist between the attack machine (Kali Linux) and the target machine (Windows 10 server) form the previous exercise)

2. Confirm IP addressing

• Kali: ifconfig

• Windows: ipconfig

• Ifconfig command shows IP address for the kali linux

• Ipconfig command shows IP address for the Windows 10 machine

3. Scan for RDP exposure (Nmap)

• Run a port scan targeting RDP (default 3389) and validate service visibility per lab configuration.

(The results shown after the port scan in the screenshot above suggest that port 3389 rdp is filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed. )

• The Remote Desktop protocol configured to allow traffic has shown in the screenshot above

• (Since the Remote Desktop service has been enabled on the Windows Machine, it is possible to verify the service running on the device by performing a Nmap Port Scan. By default, the port that the Remote Desktop service runs on is port 3389. It can be observed that the Windows machine with IP Address 192.168.0.1 has Remote Desktop Service successfully. It is also able to extract the System Name of the Machine, it is DESKTOP-S5EA3ND.)

4. Brute-force / Dictionary attack (Hydra)

Prepare dictionaries:

• user.txt (candidate usernames)

• pass.txt (candidate passwords)

(In a process of performing a penetration test on the Remote Desktop service, after the Nmap scan, it is time to do a Bruteforce Attack. Hydra. Although called a Bruteforce, it is more like a dictionary attack. We need to make two dictionaries one with a list of probable usernames and another with a list of probable passwords.)

• The attack on the Windows machine is shown in the screenshot ABOVE

---

(F) 🛡️ Defense Validation (IPBan)

Expected behavior:

• IPBan monitors log events and detects repeated login failures

• Once the failure threshold is exceeded, IPBan bans the attacker IP

Evidence appears in:

• IPBan logs showing failed attempts and ban action

---

📌 Results / Outcome

✅ Successful simulation of brute-force attempts against RDP ✅ IPBan detected suspicious behavior and blocked the attacker IP after multiple failed logins ✅ Defensive tuning improved responsiveness by reducing ban threshold

---

🔹 Formal / Academic

IPBan is an open-source intrusion prevention and brute-force protection tool designed to automatically block malicious IP addresses after repeated failed authentication attempts. What IPBan Does

IPBan continuously monitors system and application logs (primarily on Windows, but also supported on Linux) to detect patterns that indicate brute-force or credential-stuffing attacks. When a configurable threshold of failed login attempts is reached, IPBan automatically bans the offending IP address by creating firewall rules.

Where IPBan Fits in a SOC / SIEM Architecture

IPBan operates at the endpoint and network enforcement layer of a SOC architecture, providing automated, near-real-time response to brute-force and credential-based attacks.

1. Position in the Security Stack

In a typical SOC/SIEM model, IPBan sits between log generation and network control, complementing SIEM rather than replacing it:

[Endpoints / Servers]

    ↓

[Event Logs (Auth Failures)]

    ↓

[IPBan – Local Detection & Response]

    ↓

[Firewall Enforcement (Block IP)]

    ↓

[SIEM / SOC Monitoring & Correlation]

• Endpoints generate authentication and security events (e.g., Windows Event Logs for RDP failures)

• IPBan consumes these logs locally

• Firewall rules are dynamically updated to block malicious IPs

• SIEM ingests logs and actions for visibility, correlation, and auditing

---

2. IPBan’s Role in the SOC

IPBan functions as a lightweight Intrusion Prevention System (IPS) with automated response capabilities:

SOC Function IPBan Contribution Detection Identifies repeated authentication failures Response Automatically blocks attacker IPs Containment Prevents further brute-force attempts Reduction of Noise Stops alert storms at the source Endpoint Hardening Adds protection close to the asset

IPBan is particularly effective against high-volume, low-sophistication attacks (e.g., internet-wide RDP scans).

3. Relationship to SIEM

IPBan does not replace a SIEM. Instead, it:

• Acts before alerts escalate to Tier-1 SOC analysts

• Reduces false positives and alert fatigue

• Provides enrichment data (ban events, attacker IPs)

• Supports automated response in environments without SOAR

In mature SOCs:

• IPBan events are forwarded to the SIEM

• Analysts review bans, trends, and repeat offenders

• SIEM correlates IPBan actions with other telemetry (EDR, IDS, cloud logs)

4. Comparison to Other SOC Components Tool Purpose SIEM Centralised logging, correlation, alerting SOAR Orchestrated, multi-system response EDR Endpoint behaviour detection IDS/IPS Network traffic inspection IPBan Endpoint-level brute-force prevention

IPBan is best described as local, automated containment.

5. Why SOC Teams Use IPBan

• Fast response without human intervention

• Low operational overhead

• Strong control for exposed services (RDP, SSH)

• Ideal for SMBs, hybrid environments, and edge systems