Unexpected challenges: Allow SSH service on Linux decoys to accept any user and password

Unexpected challenges: Allow SSH service on Linux decoys to accept any user and password

When customers started using Cymmetria’s MazeRunner on an Internet-facing interface, we were a bit surprised. Perhaps we shouldn’t have been; after all, honeypots have been used that way since their inception. But modern cyber deception is about controlling the attacker’s path once they are already inside your network, and detecting them—fast.

Thus, some of our original design decisions made MazeRunner of limited use when facing random Internet scans. For example, we use real operating systems and services—not low-interaction honeypots or scripts. We want to avoid fingerprintability, as well as to provide an attacker with a real-feeling playground; therefore, everything an attacker encounters in our deception network is in fact real. One side-effect of this decision is that for a Linux operating system, root is actually root, and will not be available for login. Since most Internet scans over SSH try to access root, we set out to fix this, and to create a feature that would allow any login attempt with any user/password combination to succeed, and would also collect relevant attacker TTPs and related IoCs.

While the problem is straight-forward, the solution is nothing of the sort, and was a very interesting challenge to undertake.

In order to enable this new capability, we focused on three points:

  1. Creating a new user upon login request
  2. Accepting (and preferably logging) any password
  3. Handling privileged users

Let’s take a closer look at each of these three focus points, below.


  1.  Creating a new user upon login request

SSHD is the software responsible for managing and authenticating SSH connections to Linux machines. When a user attempts to connect to a Linux server, SSHD uses Name Service Switch (NSS) facility to resolve the given username and fetch the user’s information. Traditionally, Unix systems relied on local files such as /etc/passwd, /etc/groups, and /etc/hosts as their name resolution sources. As other name services became popular (such as LDAP for users and groups, and DNS for hosts), Sun Microsystems developed NSS, which was later ported to many popular Unix systems such as Linux, for their Solaris operating system. NSS allows the system administrator to manipulate the system’s name resolution process by adding and setting the order of modules (shared object files).

In order to achieve our goal (to create a new user in response to a login attempt), we added a new username resolution module to our decoys. When the user attempts to log in to our decoy, the new module will be called before the “regular” resolution process, allowing us to create a new user entry with the corresponding username.

Linux SSH interaction
Linux SSH interaction example


  1. Accepting (and preferably logging) any password

In order to maintain the appearance that the attacker’s operation is succeeding, we want to accept any password they might use. Moreover, storing the used password will allow us to see which stolen credentials were used and from where they were stolen.

Linux supports Pluggable Authentication Modules (PAM), allowing developers to write custom authentication schemes. In the default configuration, the username and password are acquired by pam_unix and verified according to the /etc/shadow file. One example of a custom authentication scheme is LDAP. The libpam-ldap package provides a pam_ldap module, which can be incorporated in the authentication process.

To intercept the authentication process, we defined a new PAM module that simply logs the username and the password used by the authenticating user and approves the credentials, before the pam_unix module is invoked.

  1. Handling privileged users

By introducing the capabilities discussed in focus points (1) and (2) to MazeRunner, we essentially gave the attacker the ability to use any set of credentials to access these particular decoy machines via their SSH service, especially using a privileged user such as root. Since logging in as root would allow the attacker to access our code and logs without needing to escalate their privileges, we needed to put in place the ability to deny authentication requests for privileged users or “cheat” by creating a session with standard permissions.

We decided to “cheat” by creating a session with standard permissions. We achieved this by redirecting attackers who try to open a session using privileged usernames (in step 1), to sessions that use non-privileged usernames.

While any advanced, human attacker would likely detect this new capability we’ve added, most random Internet attacks are carried out by non-human, automatic tools. These automatic tools will likely use any successful authentication to run their payload, without recognizing that deception is in play, and thereby reveal themselves.


We welcome your feedback, questions, and comments. Please feel free to reach out to us.

Not yet a customer? Ask us for a demo today.



Lev is a Senior Security Researcher at Cymmetria. He is currently completing his Masters degree in computer science and has published several works related to the field of cryptography and side-channel attacks. His works have been featured in publications such as Communications of the ACM, and he frequently speaks at international conferences and events such as RSA Conference Cryptographers’ Track (CT-RSA).

Twitter: @levp92


Share this:


Scroll to Top