Watch where you point that cred! Part 1

TL;DR

• Poorly protected authentication requests from privileged automated tasks (e.g. vulnerability scanners, health checks) could be intercepted by rogue authentication servers planted in the internal network.
• Weak authentication methods, overly broad privileges and scopes, as well as poor network protections can leave these requests vulnerable to capture.
• Mitigations:
  • Use the principle of least privilege (avoid Domain Admin for routine tasks).
  • Implement strong password policies and consider agents or certificates for authentication.
  • Employ NAC, SMB signing, and proper asset management.
  • Deploy honeypots to detect intruders and provide an early warning for breaches.

Introduction

Unauthorised network access remains a significant threat, especially for organisations lacking robust network security controls. If an attacker infiltrates a building and connects their device to the office Ethernet, they may gain connectivity to hosts in the internal network, enabling enumeration and potential exploitation.

Common defences against this include intrusion detection / prevention systems (IDS / IPS), network segmentation, and Network Access Control (NAC). For instance, port-based authentication (802.1X), or MAC filtering can restrict network access to approved corporate devices only. However, attackers can circumvent these measures by compromising or spoofing legitimate devices, allowing them to appear as trusted sources while launching attacks on internal systems.

Honeypots offer an additional layer of defence by luring attackers into revealing themselves. This not only delays malicious activity but also provides an early warning to the security team to respond faster and contain the breach. Examples of honeypots include:

• Placing a decoy file in the domain controller’s file share to detect someone looking for hardcoded credentials in scripts (e.g., run_cmd.ps1) and alerting when the file has been opened or downloaded, or if the canary account has been used to log in somewhere. (Windows File Access Monitoring, Canarytokens).
• Creating a canary Kerberoastable service account with a high-value name (e.g. svc_backup), and flagging any ticket requests for this account as suspicious. (Creating a Kerberoast Service Account Honeypot – Active Directory Security).
• Deploying a physical or virtual honeypot server that is running commonly targeted services (g., SMB, SSH, FTP, SQL etc.) and logging any connection attempts. (How to Build a Honeypot to Increase Network Security).

Threat actors have also been known to use honeypots, such as setting up free Wi-Fi networks to sniff traffic. Fake command-and-control (C2) servers have also been discovered that observe and mislead security researchers, while also polluting threat intelligence feeds (Malicious Honeypots Polluting Internet Scanner Results | CyberMaxx).

At the coalface. Accidental honeypot

A client asked me to demonstrate what an attacker could do if they managed to compromise a corporate laptop, and to show how their security tooling could potentially be avoided. While I am not a red teamer with a cache of fancy payload obfuscation skills, I do know how to proxy traffic.

OpenSSH is installed by default on Windows. As it had not been uninstalled on the corporate laptop, I created an SSH reverse proxy to tunnel my command-and-control (C2) traffic through the laptop and into the internal network, bypassing endpoint detection. For more info on this technique, check out our blog post: Living off the land with native SSH and split tunnelling.

I wanted to use a tool on my testing laptop that wasn’t on the C2 server. So, I spun up a local OpenSSH server on my testing laptop and established the proxy tunnel locally, with both laptops connected to the internal network over Ethernet.

However, I noticed something strange in my OpenSSH logs: another internal host was attempting to log into my SSH server with a Firewall Administrator service account!

SSH honeypot

Given this behaviour, I suspected an automated health check or task was blindly scanning for SSH services across the internal network. OpenSSH logs don’t record the password, so the next day, I set up an SSH honeypot using the Cowrie tool (GitHub – Cowrie SSH/Telnet Honeypot) to act as a rogue authentication server and capture the login attempt. Sure enough, the next day, the same host tried to log in, and I captured valid credentials! This led to full compromise of the client’s firewalls and switches.

Since there was no NAC in place, any unauthorised person in the office could have plugged in a rogue server, and simply waited for automated login attempts to roll in.

Below is an example to show how the SSH credentials are logged in Cowrie:

This got me thinking: couldn’t credentialed vulnerability scanners be exploited in a similar way?

Credentialed vulnerability scanning

Vulnerability scanners offer an automated way to detect weaknesses across a network.

Password-based scanners can log into the hosts with admin credentials to audit installed software and system settings for comprehensive results. Highly privileged accounts like Domain Admin accounts are often used as a quick and easy solution, rather than setting up lower privileged or per-host admin credentials for potentially thousands of devices.

These scans are also often given carte balance to scan entire /16 subnets instead of specific known hosts.

In contrast, agent-based solutions install a local agent onto the host to perform continuous vulnerability management, which avoids credentials being sent over the network.

Linux scanning

SSH-based vulnerability scans can be abused by a rogue SSH server to capture credentials. When Nessus attempts to authenticate, the rogue server captures the provided username and password. Nessus does warn against connecting to unknown SSH hosts without verifying host keys, but I imagine most organisations skip this step.

Here’s how the scanner’s captured authentication request looked in Cowrie:

Windows scanning

Nessus Professional is often used to perform credentialed scans on Windows hosts, over SMB. Attackers could capitalise on this by setting up a rogue SMB server to:

1. Capture the NTLMv2 password hash from the SMB authentication request. If the account was set with a weak password, the hash could be cracked to obtain the plaintext password.
2. Relay the SMB authentication request to other hosts that lack SMB signing, impersonating the account and compromising those systems.

Testing this, I configured a Nessus Professional scan against a /24 subnet with a Domain Admin account.

You can create a rogue SMB server on Linux with tools like impacket-smbserver, Responder, or PCredz. In this example, I used impacket-smbserver and captured the domain admin password hash from the scan:

Genuine host rogue authentication server

If the internal network has already been hardened with measures like network segmentation, VPN gateways, and NAC, the threat from non-corporate devices accessing the network, like a planted Raspberry Pi in the office, will be significantly reduced. However, a realistic threat remains from genuine corporate devices that have been compromised by attackers.

Inveigh is a Windows-based rogue SMB server. I ran the same scan against the Inveigh SMB packet sniffer, with poisoning disabled, to capture the hash:

Running Inveigh directly on a corporate laptop is likely to be detected by EDR. This could be evaded by disabling the SMB service on the laptop and instead, forwarding incoming SMB traffic out to an attacker-controlled server to capture the request, over SSH – more details on this in Part 2.

Incoming SMB traffic to the workstation will now be redirected out to the C2 server, allowing for hash capture.

Summary

Attackers can passively capture privileged credentials used by automated tasks and vulnerability scanners in internal networks if they have been configured with an excessive scope or are insufficiently protected by network or host controls. This risk may be missed in penetration tests that are typically only conducted during normal working hours, particularly if the tasks are running on evenings and weekends.

Recommendations

Audit and secure automated tasks and scanning practices

• Identify and review scheduled tasks, monitoring tools, vulnerability scanners, and other automated processes that may be running in the network.
• Use secure authentication methods, such as certificate- or agent-based authentication, instead of username / password-based authentication.
• In environments using DHCP, avoid scanning entire subnets; instead use individual hostnames or IP addresses to minimise exposure to unauthenticated attackers and reduce the risk of credential interception. If you’re only option is to target subnets, use a ‘known_hosts’ list so that you only authenticate against genuine corporate devices.

Account management

• Use separate service accounts with the minimum necessary permissions for different tasks and tiers.
• Avoid running scheduled tasks or vulnerability scans with highly privileged accounts like Domain Admins.
• Use long, secure passwords for service accounts (e.g., 25+ characters, mixed character sets, and ideally randomly generated) to make any captured hashes difficult to crack.
• Add service accounts to the “Protected Users” group to reduce their exposure to credential theft attacks. Deny interactive and remote logon rights to service accounts.
• Monitor these accounts for any authentication requests not sourced from the appropriate host (e.g., if the Nessus service account is logging in from a workstation rather than its designated server).

Host management

• Implement an asset management programme to track genuine corporate devices and trigger alarms for unknown or newly connected hosts in the internal network.
• Monitor for strange endpoint activity, such as the SMB service being disabled, or firewall rules / port proxies being created.
• Enable SMB signing and LDAP channel binding across the internal network to prevent relay attacks.
• Block outbound traffic for SMB and SSH services to the public Internet.

Honeypots for detection

Consider deploying honeypots in the network to detect unauthorised activity, such as decoy servers, service accounts, and files.

Be cautious with your credentials

Never input real credentials into a server unless you are certain it’s a genuine corporate host, it could be a rogue server trying to capture your info!

Follow industry guidance

For safe Nessus credentialed scanning, refer to this guide from Tenable.