Honeypot Brute Force Analysis (Exposing Anonymous Login Attacks)

Summary and Key Findings

As part of a personal security project, I set up a honeypot VM and exposed it to the internet to observe potential attack vectors targeting vulnerable systems. During the monitoring period, I detected a large number of brute-force login attempts, followed by a series of seemingly successful logins using a method that bypasses traditional authentication mechanisms—the anonymous logon technique. While these “successful” logins appeared legitimate, they were ultimately an attempt to exploit a common vulnerability in systems with weak authentication settings but were miscategorised as actual successful logins.

Through detailed investigation, I uncovered the abuse of the NT Authority Anonymous Logon method, misconfigured access controls, and the exploitation of SMB vulnerabilities. This report will outline the findings of this attack, provide an in-depth look at the attack method, and explore how attackers attempted to leverage anonymous logon to bypass security defences. Additionally, I will perform OSINT on the attacker’s IP address, discuss the implications of these findings, and offer recommendations for mitigating similar attacks, along with key indicators of compromise (IOCs).

Honeypot Setup

To simulate an attack scenario, I configured a virtual machine (VM) named “CORP-NET-EAST-1” as a honeypot within an Azure environment. The VM was deliberately exposed to the internet with minimal security measures, allowing me to observe unauthorised login attempts. This setup mirrors the conditions of a system that could be targeted by attackers looking for exposed or poorly configured machines.

Configuration of the Honeypot:

• Operating System: Windows 10 Pro

• Exposed Ports: RDP (3389), SMB (445), and WinRM (5985)

• NTLM Settings: NTLMv1 authentication allowed

• NSG Creation: Creation of a Network Security Group & Inbound Rules

• Logging: Enabled security event logging, particularly focusing on Event IDs 4624 & 4625

• Analysis: Creation of DCR to forward logs to Sentinel via AMA

Figure 1: Network Security Group Inbound Rule

Firewall

In order to fully simulate an environment vulnerable to external threats, I disabled the Windows firewall on the honeypot VM. By doing so, I ensured that no internal firewall rules were blocking the incoming attack attempts. The goal was to create an unfiltered entry point into the system, providing a more realistic attack surface for external actors.

Figure 2: Disabling Firewall on VM

Observing Failed Brute Force Attempts

Upon enabling logging and monitoring on the honeypot system, I quickly observed a surge in failed login attempts within just 30 minutes. These attempts primarily targeted common usernames such as “Administrator” and “Guest,” alongside thousands of other variations. Over the next 24 hours, the VM recorded more than 81,000 unsuccessful brute-force attempts. However, what stood out the most was the presence of three successful logins—immediately raising suspicion, shown in Figure 4.

To better understand the geographical origins of these attempts, I created a workbook heatmap within Microsoft Sentinel, visualising the distribution of attack sources shown in Figure 3.

Figure 3: Honeypot brute force attempts attack map

Figure 4: Total amount of Brute Force failed & successful logins

The next screenshot highlights the top failed login attempts by IP address, revealing two standout sources that repeatedly attempted to authenticate using the “Administrator” username. These IPs generated a significantly higher volume of brute-force attempts compared to others, suggesting automated attack activity.

Figure 5: Highest amount of Brute Force failed logins from single IP address

Successful Logins (But Not Really)

In addition to the brute force attempts, I also observed successful login events (Event ID 4624). However, further analysis revealed that these “successful logins” were actually a result of anonymous logon attacks. These logins did not require valid credentials and were performed using the NT AUTHORITY\ANONYMOUS LOGON account.

An Anonymous Logon is a method where an attacker can bypass authentication mechanisms entirely and gain unauthorised access to the system without entering a password. This is facilitated by the NTLM protocol (specifically NTLMv1 in this case) and is often exploited when RestrictAnonymous settings are misconfigured.

Below is a screenshot highlighting key details of one of the unauthorised logins:

Figure 6: Highest amount of Brute Force failed logins from single IP address

Key Observations

• NT AUTHORITY\ANONYMOUS LOGON appears in the logs, indicating an unauthenticated session.
• Logon Type 3 means a network connection (typically SMB or RPC).
• No associated process was recorded, indicating it was likely a service-based authentication.
• The attacker was able to connect to the system without needing to authenticate.
• No processes were initiated by the “successful” login, pointing to an automated or scripted attack using network-based protocols.
• The logs showed the ANONYMOUS LOGON account name with the account type being “User”, which is a clear sign that the login attempt was not legitimate.
• TargetUserSid S-1-5-7, this is a built-in anonymous login SID.

To determine whether these “successful” logins actually granted system access, I performed my own SMB authentication test against the honeypot using an anonymous logon attempt. Despite Windows event logs marking the login as successful (Event ID 4624), further analysis of the SMB session traffic in Wireshark revealed that no actual access was granted. Specifically, the SMB2 SESSION_SETUP Response returned a STATUS_ACCESS_DENIED (0xC0000022), confirming that while the log event suggested a successful login, the session was ultimately rejected by the system. Here’s what I did:

Figure 7: SMB authentication test against my honeypot

A System Error 5 (Access Denied) message occurred when I attempted to establish an SMB connection using an anonymous login, indicating that the honeypot successfully rejected my unauthenticated access request. However, despite this denial, Event Viewer—just as it had for the attacker—incorrectly logged the attempt as a successful login.

Figure 8: SMB connection event viewer information

Honeypot Security Controls

To understand why SMB access was blocked despite the misleading event logs, I investigated the security controls in place on the honeypot.

I ran the following powershell command to understand if anonymous access was restricted on the honeypot.

Figure 9: Restricted anonymous access configuration on honeypot

❌ RestrictAnonymous = 0

• This is a major misconfiguration, meaning that attackers may be able to query user accounts, shares, and even attempt NTLM relay attacks.

✅ RestrictAnonymousSAM = 1

• This setting prevents anonymous users from querying the security account manager (SAM) database which stores user accounts and password hashes.

Knowing that RestrictAnonymous was turned off, I then wanted to understand the SMB permissions on the honeypot, I ran the following Powershell command to get the SMB Server configuration details:

Figure 10: SMB configuration settings on honeypot

Setting	Value	Meaning
EnableSMB1Protocol	False	SMBv1 is disabled, null session attacks often rely on SMB1
RequireSecuritySignature	False	Set to false meaning that NTLM relay attacks are possible
RejectUnencryptedAccess	True	SMB requires encryption, blocking null and anonymoys connections

Based on the SMB settings configured on the honeypot, anonymous (null session) logons are effectively blocked.

✅ SMBv1 is Disabled (EnableSMB1Protocol = False)

• SMBv1 is an outdated and insecure protocol that historically allowed unauthenticated null sessions.
• Many legacy null session attacks (e.g., net use, net view) relied on SMBv1 being enabled.
• Since SMBv1 is disabled, these older attack methods cannot be used to gain anonymous access.

✅ SMB Requires Encryption (RejectUnencryptedAccess = True)

• The honeypot can reject unencrypted SMB connections, which null sessions typically rely on.
• Without encryption, anonymous logins are blocked by default, preventing attackers from leveraging unauthenticated access.
• This setting is critical because even if other security measures were misconfigured, encryption enforcement would still prevent null session attacks.

❌ SMB Signing is Not Required (RequireSecuritySignature = False)

• SMB signing prevents NTLM relay attacks by ensuring that SMB messages are cryptographically signed.
• Since signing is not required, this, however means an attacker could potentially attempt a NTLM relay attack.

Knowing why the anonymous login method didn’t work, I confirmed this by running Wireshark to capture and analyse the SMB authentication sequence to confirm these security controls.

Figure 11: Wireshark packet capture of NTLM authentication sequence

Through this SMB packet capture, I identified the following NTLM handshake steps:

Breakdown of the NTLM Authentication Process

1️⃣ Client Sends NTLMSSP_NEGOTIATE (0x00000001)

The client initiates the authentication request, proposing NTLM as the authentication method. We can see that inside this request, the client is telling the honeypot which NTLM version it supports, what security features it wants to use and the domain and workstation information

Figure 12: Wireshark packet capture of initiating client auth request

2️⃣ Server Responds with NTLMSSP_CHALLENGE (0x00000002)

The server challenges the client to prove its identity. This is a standard NTLM handshake process, occurring before authentication success or failure is determined. Here we can see the random challenge named the Server Challenge that the client must encrypt to prove its identity.

Figure 13: Wireshark packet capture of NTLM challenge

3️⃣ Client Sends NTLMSSP_AUTH (0x00000003)

In a typical login process, the client would respond to the challenge with credentials. I can see NTLM authenticated using ANONYMOUS ZERO NTHASH, meaning the client did not provide a valid username/password. Instead, it used the NT AUTHORITY\ANONYMOUS LOGON account. The honeypot still processed the NTLM authentication sequence but without actual credentials typical of anonymous logon attempts.

Figure 14: Wireshark packet capture of NTLM auth message

4️⃣ Server Sends SMB2 SESSION_SETUP Response

If authentication succeeds, the response contains STATUS_SUCCESS (0x00000000). If authentication fails, the response contains STATUS_ACCESS_DENIED (0xC0000022).

In this case, the STATUS_ACCESS_DENIED response confirmed that the anonymous logon attempt was unsuccessful, due to access restrictions on the honeypot. This aligns with my findings above — while the Windows logs misclassified the login as “successful,” actual system access was denied.

Figure 15: Wireshark packet capture of smb session access denied

OSINT Analysis

Anonymous Logon Attempt OSINT

After conducting OSINT on the IP address 46{.}105{.}132{.}55, I discovered that it has previously been reported as a malicious IP address over 9000 times and is associated with a domain linked to a French cybersecurity company known for offering services like penetration testing and vulnerability assessments. While it’s common for such companies to conduct security tests, including simulated attacks, these activities are typically done within controlled environments and with explicit permission.

Figure 16: French IP OSINT on AbuseIPDB

The legality of this activity depends on whether the company had prior consent to probe my honeypot. Unauthorised scanning or probing of systems, even if it’s part of a cybersecurity test, can be deemed illegal under laws like the Computer Misuse Act in the UK or similar regulations in other countries. In this case, the activity could be considered unauthorised, as no prior consent was given to the company to target my honeypot system.

While the company may have been conducting a security assessment, the lack of authorisation means the activity could potentially violate cybersecurity laws. I have reported this activity to ActionFraud for further investigation.

Mitigations

Disable NTLMv1

NTLMv1 is an outdated and insecure authentication protocol that is vulnerable to various types of attacks, including pass-the-hash attacks. Disabling NTLMv1 forces systems to use more secure authentication protocols like NTLMv2 or Kerberos, thereby improving overall security by preventing attackers from exploiting weaknesses in NTLMv1.

Disable SMBv1

SMBv1 is an outdated protocol that doesn’t offer the modern security features we need today. It’s been a prime target for ransomware and other attacks, like the WannaCry outbreak.

Enable SMB Signing and Encryption

Turning on SMB signing is important because it ensures that any data exchanged over SMB is cryptographically signed. This prevents issues like man-in-the-middle and NTLM relay attacks. Additionally, enabling SMB encryption helps protect sensitive information from being tampered with during transmission.

Restrict Anonymous Logon Access

It’s essential to limit anonymous logon access since it stops unauthorised users from accessing shared resources without validating their identity. If anonymous access is misconfigured, it can unintentionally allow unauthorised access to a system without the need for credentials.

Limit SMB and RDP Exposure

Keeping SMB and RDP available only to trusted IP addresses or networks is a smart move. This limits their exposure and minimizes the risk of remote attacks. Allowing these services on the open internet can lead to brute-force attempts and unauthorised access, so it’s important to keep access tightly controlled.

Monitor and Detect Unusual Activity

Constantly monitoring for unusual activity can help catch potential attacks early on, before they escalate. Utilising tools like SIEM systems, IDS/IPS, and anomaly detection allows for quick response to suspicious behavior and take action against security threats.

Implement strong NSG or Firewalls

Using strong Network Security Groups (NSGs) or firewalls helps enforce network-level security by controlling inbound and outbound traffic. By configuring strict rules, you can block unwanted or malicious traffic and prevent unauthorised services from being exposed to external threats.

Disable or Secure RDP

If RDP isn’t necessary for remote access, it’s best to disable it completely. But if you do need it, making sure it’s secured with multi-factor authentication, VPNs, and other protective measures will help keep unauthorised outsiders away. This is vital since the RDP protocol is often targeted by attackers.

Conclusion

The successful logon activity strongly suggested an attempt to exploit misconfigured authentication settings, potentially to enumerate shares, access system information, or escalate privileges. While Windows event logs misclassified the login as successful, network traffic analysis proved that access was ultimately denied, highlighting the importance of correlating log data with packet captures and event logs when investigating potential security incidents.

IOCs

IOC Type	IOC
IPv4 Address	46{.}105{.}132{.}55
Domain	scan072{.}intrinsec{.}com
IPv4 Address	5{.}113{.}133{.}110
IPv4 Address	95{.}214{.}54{.}126