Overview
Vulnerability scanners are a cornerstone of modern security programs, helping teams identify weaknesses before attackers do. But when these tools are configured with privileged credentials, they can themselves become high-value targets.
In one case, while running continuous testing through our Chariot platform for a Fortune 500 financial services company, we compromised a server and instrumented the SSH process to dump credentials. Shortly after, we observed that a vulnerability scanner account with high privileges was authenticating to the system, handing us credentials directly, all while a widely deployed Linux EDR product on the server failed to trigger a single alert.
This example underscores a larger theme: many scanners rely on stored passwords to authenticate over SSH or legacy protocols like NTLMv1, and if those credentials are exposed, attackers can weaponize them for deeper compromise. In this post, we examine real-world risks created by scanner access, from password exposure to potential pivots into CI/CD infrastructure. We also share research showing that Linux EDR solutions often fall short, leaving blind spots where attackers can modify services, intercept credentials, or escalate privileges without raising alarms.
The takeaway is clear: organizations must treat scanner credentials as sensitive assets, enforce strong access controls, and validate that their Linux EDR solutions provide meaningful coverage, not just regulatory compliance.
Credential Abuse Through Scanner Access
Our most recent engagement involved a purple team exercise conducted in conjunction with the continuous testing performed by our Chariot platform. On this project, we leveraged another vulnerability to gain root privileges on an internal Linux server within the customer environment. After gaining access to the system, we began performing post-exploitation and reviewed the authentication logs on the system. We observed that a privileged service account associated with the customer’s Nessus vulnerability scanner was regularly authenticating to the server using password-based authentication over SSH.
You may think this is quite strange and be wondering, why would a vulnerability scanner be authenticating to a server if it’s meant to be testing for vulnerabilities? This is often referred to as “authenticated scanning” and allows the vulnerability scanner to perform more accurate and in-depth testing for vulnerabilities on a server or within an environment. Often, this account needs to be provisioned with root or administrative privileges across the environment in order to perform authenticated scanning effectively.
Normally, from an unauthenticated perspective, a scanner would attempt to discover vulnerabilities by probing services, but it’s often difficult to detect certain vulnerabilities automatically via unauthenticated scanning due to the risk of crashing the system or there simply not being any great indicators to key off of that are related to the vulnerability. Authenticated scanning helps to reduce the number of false positives and increase the number of vulnerabilities that can be identified by vulnerability scanners.
Risks Associated with Password-Based Authentication
A natural question is: what is wrong with configuring password-based authentication for vulnerability scanners?
The core issue is that the password for the privileged service account used in authenticated scanning must be transmitted to the server during login. If an attacker has already compromised the target system, they can manipulate the authentication mechanism—for example, instrumenting the SSH daemon to intercept credentials. Once obtained, the attacker can reuse the stolen password to move laterally and compromise other systems across the environment.
This risk does not exist with more robust mechanisms such as private-key authentication. Private-key–based methods rely on a challenge–response process, which ensures the private key itself is never exposed to the target server. As a result, credential material theft in transit is effectively mitigated.
Why Organizations Still Use Password-Based Authentication
If private-key authentication is more secure, why do organizations continue to deploy password-based methods in scanning contexts? Several practical reasons explain this:
- Lack of Centralized Key Management: Without a certificate authority or a centralized key distribution system, provisioning and managing SSH keys across a large environment can be difficult.
- Operational Resistance: Keys already provisioned for deployment tools (e.g., Ansible or other configuration managers) may be tightly controlled, leading to resistance against reusing them for vulnerability scanning.
- Directory Services Integration: Many Linux systems are domain-joined or leverage centralized authentication directories. In such environments, enabling password-based login for a service account often feels like the most straightforward and “normal” configuration.
While these reasons are understandable, the tradeoff is a significantly larger attack surface if credentials are intercepted. Organizations should carefully weigh this risk and strongly consider private-key–based authentication for critical scanning tasks.
Legacy Authentication Protocols Risks (e.g. NTLMv1)
Another critical risk arises from the use of legacy authentication protocols or non-standard protocol implementations. These can introduce weaknesses not present in modern or officially supported implementations.
A common misconfiguration is enabling NTLMv1 for authenticated scanning of legacy systems. While this may preserve backward compatibility, it carries serious consequences: if the scanning service account authenticates to a compromised or attacker-controlled system, the attacker can capture the NTLM hash of the account. This credential material can then be reused for lateral movement or privilege escalation.
Even in environments that use newer mechanisms like NTLMv2, risks remain when custom implementations of SMB or NTLM are deployed. For example, if a vendor’s implementation fails to correctly set channel binding tokens or signing requirements in authentication requests, then NTLMv2 authentications could be subject to relay attacks. In practice, this means that authentication intended for one host could be replayed to another service, such as LDAP, ultimately compromising the service account. By contrast, Microsoft’s native SMB/NTLM implementations include protections that prevent such relays by default.
Why This Matters
- Backward compatibility vs. security tradeoffs: Supporting older systems often means reverting to insecure protocols.
- Custom implementations increase risk: Diverging from reference protocol stacks can create exploitable gaps.
- Relay and hash-theft attacks: Even without cleartext passwords, captured authentication material can often be replayed in ways that yield account compromise.
Organizations should strongly prefer disabling NTLMv1 and validating that only hardened, up-to-date protocol implementations are used for authenticated scanning.
Not Just Vulnerability Scanners
This issue is not unique to vulnerability scanners. Over the past seven years at Praetorian, I’ve observed the same authentication weaknesses across a wide variety of projects. Other systems, such as asset inventory platforms, IT automation frameworks, and management tools, frequently rely on authenticated connections using insecure protocols or password-based authentication mechanisms.
Techniques for Obtaining Credentials from Scanners
In this section, we are going to touch briefly on different techniques that can be used for obtaining credentials from a vulnerability scanner if it is authenticating to a Linux server that you have compromised within an environment over SSH using password-based authentication.
SSH Service Environment Variable Modification
A straightforward method for harvesting credentials on Linux is to hook the pam_authenticate function within the SSH daemon. By intercepting the point where credentials are passed to PAM, an attacker can capture usernames and passwords during login. This technique is particularly effective given that most Linux distributions configure SSH to use PAM for authentication by default.
One way to achieve this is by setting the LD_PRELOAD environment variable, which hijacks the symbol resolution process used by the dynamic linker. While modifying global linker configuration files (e.g., /etc/ld.so.preload) can achieve the same outcome, those changes are more likely to trigger file integrity monitoring alerts.
A stealthier alternative is to leverage the way systemd services, such as sshd, are often configured with environment variable files (for example, /etc/default/ssh or service-specific drop-in files). By modifying these service environment files, an attacker can inject LD_PRELOAD specifically into the SSH daemon without affecting the entire system (see Figure 1). This narrows the scope of modification, avoids high-signal indicators like global configuration tampering, and still enables credential interception every time a user logs in through SSH.
Figure 1: An example OpenSSH systemd service configuration file showing the service is configured to read environment variables from the /etc/default/ssh file.
Tracing on the SSHD Service Process (e.g. STrace)
Another classic technique for credential interception is to leverage Linux debugging and tracing tools, such as strace, to monitor inter-process communication (IPC) within OpenSSH. For context, OpenSSH spawns multiple processes to handle different tasks—such as network communication, session management, and authentication. It relies on IPC between a broker process and a monitor process (running with elevated privileges) to perform sensitive operations like password-based authentication via PAM.
By attaching a tracer such as strace to these processes, an attacker can capture the data being passed over these IPC channels. Because password credentials are transmitted in cleartext between processes, they can be extracted without needing to modify core system files or binaries. Tim Jensen’s write-up on SSH Password Theft provides a deeper dive into this technique.
If a tracing utility like STrace is not available on the server, we have other options for collecting these controls by simply invoking the ptrace system call directly to perform this instrumentation ourselves. Fortunately, someone else has already done this work for us, with Matt Keeley of ProDefense writing a tool called Hawk which he describes in his article Hawk’s Prey: Snatching SSH Credentials.
That said, attackers must use this approach cautiously. Continuous tracing of SSH processes on production servers can introduce noticeable performance degradation or even system instability. Despite this drawback, it remains a powerful and relatively low-footprint method of harvesting SSH credentials in real time.
Malicious Pluggable Authentication Module (PAM) Authentication
Another effective way to capture credentials is to add a malicious PAM module into the authentication stack. PAM is the central authentication framework used by most Linux distributions, meaning any new module integrated into the stack will be executed whenever users authenticate—whether via SSH, sudo, or other PAM-enabled services.
Unlike modifying or replacing existing modules, this technique involves simply adding a new, attacker-controlled PAM module to /etc/pam.d/ and updating the relevant configuration files to load it. Once loaded, the malicious module can intercept usernames and passwords before passing control to the legitimate modules, ensuring authentication still succeeds while silently logging the captured credentials.
This method has several advantages:
- Transparency: Authentication continues to function normally, so users and administrators rarely notice anything unusual.
- Flexibility: A new module can be introduced with minimal disruption, making it harder to distinguish from legitimate PAM configurations.
- Stealth: Because no core system libraries or binaries are modified, many common detection mechanisms (e.g., file integrity monitoring on /lib or /usr/lib) are bypassed.
In our lab testing, this approach proved both reliable and stealthy. More concerningly, none of the Linux EDR products we evaluated flagged the addition of a new PAM module or the credential interception it performed.
Honeypots and Firewall Traffic Redirection
Scanners often log in repeatedly from a fixed set of source addresses, which makes them a good target for redirection. One option is to configure a fake SSH service listening on a nonstandard port such as 2222/TCP and then use iptables rules to redirect incoming connections originally destined for 22/TCP into the honeypot service on 2222/TCP. From the scanner’s perspective, it continues to connect normally, while the honeypot captures authentication attempts.
This setup is simple to implement in practice. A lightweight Go program, such as an example sshoneypot.go, can be used to stand up the honeypot and handle incoming sessions. Combined with the firewall redirection, this provides a straightforward method for intercepting scanner traffic without modifying the legitimate SSH daemon or any local configuration files.
Observations on Linux Endpoint Protection Solutions
In our testing of Linux endpoint detection and response (EDR) products, we’ve consistently observed that they are significantly less mature and more compliance-oriented than their Windows counterparts. While all major EDR vendors advertise support for Linux and macOS, the detection capabilities of their Linux agents in particular often fall short of expectations.
For example, across multiple widely deployed EDR products, none of the credential dumping techniques we described earlier generated alerts during our experiments. Detection rates were effectively zero. This strongly suggests that many Linux EDR solutions are optimized to check compliance boxes (e.g., “Linux support available”) rather than to deliver feature parity with their Windows agents, which tend to be far more mature and capable of detecting common attacker tactics, techniques, and procedures (TTPs).
During red team engagements, this discrepancy shapes our operational choices. Many organizations with mature security programs have robust detections around Active Directory and their internal Windows environments. While we still employ those techniques, we often find it easier to persist, evade detection, and move laterally within Linux infrastructure, particularly CI/CD pipelines and supporting systems. In practice, Linux remains a softer target, even for organizations that are otherwise highly mature in their defensive posture.
Conclusions
Vulnerability scanners and related tools are invaluable for identifying weaknesses before attackers do—but they also introduce risks that defenders cannot afford to ignore. When these scanners rely on password-based authentication or legacy protocols like NTLMv1, they create an attractive attack surface. Once an adversary compromises a single host, the scanner itself can become a conduit for credential theft, privilege escalation, and lateral movement across the environment.
Our testing shows that these risks are amplified by the relative immaturity of Linux endpoint protection solutions. Even widely deployed EDR products failed to detect straightforward credential interception techniques like LD_PRELOAD injection or process tracing on SSH. For mature organizations with strong Windows detections, Linux infrastructure and CI/CD pipelines often remain the softer target.
The takeaway is clear:
- Treat scanner and automation credentials as sensitive assets.
- Prefer key-based authentication or stronger mechanisms over passwords.
- Disable legacy protocols and validate that only modern, hardened implementations are in use.
- Continuously validate Linux EDR capabilities, ensuring they provide real coverage rather than simply meeting compliance checkboxes.
At Praetorian, we regularly uncover these gaps during real-world engagements and through continuous testing on our Chariot platform. By simulating how attackers actually operate, we help organizations see where credential misuse, weak authentication models, and blind spots in Linux detection combine to create pathways for compromise. Addressing these risks now ensures that the very tools meant to secure your environment don’t become the entry point for its downfall.
