You have MFA enabled on every system you manage. You do not reuse passwords. Your systems are patched, your credentials are strong, and you follow security best practices.
Despite these precautions, an attacker who has already compromised one of your systems may be able to leverage your normal administrative workflow to gain access to another.
This paper documents a lateral movement technique we are calling config file poisoning. Under the right conditions, this can allow an attacker to abuse the victim's existing trust relationships, authentication mechanisms, and administrative privileges without requiring credential theft or session hijacking.
The premise is simple: if an attacker has access to a victim machine and knows the victim regularly connects to a second system, the attacker cannot currently access, they can modify a client-side configuration file on the victim's machine to execute commands on the second system the next time the victim connects. This all happens silently, automatically, and with no indication any command was run.
SSH (Secure Shell) is a protocol used to securely administer remote systems over encrypted connections. It is one of the most widely deployed administrative protocols in Linux and Unix environments and is increasingly common in Windows infrastructure. In addition to interactive shell access, SSH supports file transfer, tunneling, and port forwarding.
SSH provides several configuration mechanisms that allow administrators and users to customize connection behavior. For this research, we focus on the RemoteCommand option and its role in enabling configuration file poisoning.
SSH supports both system-wide and user-specific configuration files. System-wide settings are typically defined in /etc/ssh/ssh_config, while users may optionally create ~/.ssh/config to override connection behavior. These files control authentication methods, connection parameters, command execution behavior, and numerous other client-side options. In the following screen shot we can see some of the available options. Pay attention to the Red Box, PermitLocalCommand, we will come back to this as it is intertwined with the root cause of this attack.
The heart of this attack lies in an option called RemoteCommand, which as the manual page states as: ‘Specifies a command to execute on the remote machine after successfully connecting to the server`.
Assume an attacker has obtained remote code execution on Host-1. The victim regularly uses Host-1 to establish SSH connections to Host-2, but the attacker does not possess valid credentials for Host-2. By modifying the victim's SSH client configuration file, the attacker can cause arbitrary commands to execute on Host-2 during the victim's next legitimate SSH session.
The following screenshot shows the syntax of the malicious config file. This example states that for any remote host and any user, run the following command. The command creates a text file called `infection` in the users home directory with the text `This seems dangerous`. The exec $SHELL -l spawns a shell for the victim after executing the commands, making it appear as a normal SSH session to the victim.
Now with the config file in place, we can SSH into Host-2 and upon logging in we see the file, indicating RCE. Note the victim authenticates normally — key-based, password, MFA, doesn't matter, since the payload fires after authentication succeeds.
The impact increases significantly when the victim possesses elevated privileges on the destination system. In the following example, the victim account has NOPASSWD sudo permissions on Host-2.
Same structure of attack as before, we show a command that needs elevated privileges for, reading /etc/shadow.
With the config placed on host1, we SSH into host2 and there is no indication they just ran an elevated command. As we expect, in the following screenshot we can see the command successfully copied etc/shadow and made it readable to the user.
Finally, I changed the sudoers to PASSWD:ALL. We see the password is asked for on the second line. An astute observer may see it, but it could also be overlooked by a tired sysadmin.
Remember the Red Box, PermitLocalCommand? This implies there is a LocalCommand too. There is, and as you can guess, it’s an option to run a command on the local host. For our purposes this isn’t as interesting because we assume the attacker already has this ability. I only bring it up in the attack section to mention it could serve as a persistence mechanism for the attacker on Host-1, running the malicious command anytime the victim uses SSH.
Although the technique executes silently from the victim's perspective, it generates the typical forensic artifacts that defenders can use for detection and investigation.
We can see audit.d captures the command as we would expect with the hexencoded command in a2.
Use xxd to convert the hex back to ascii and see the original RemoteCommand we placed in the config file.
Sysmon for linux detected this example with event id 1, 11. The following with just the relevant parts of the log.
<Event><System><Provider Name="Linux-Sysmon" Name="OriginalFileName">-</Data><Data Name="CommandLine">bash -c echo 'This looks dangerous' > /infection.txt; exec $SHELL -l</Data><Data Name="ParentImage">/usr/sbin/sshd</Data><Data Name="ParentCommandLine">/usr/sbin/sshd</Data><Data Name="ParentUser">root</Data></EventData></Event>
The primary challenge in mitigating this technique is that it does not rely on a software vulnerability. RemoteCommand is functioning exactly as designed. The attack arises from the interaction between legitimate client-side automation features and user-controlled configuration files.
A natural mitigation would be the introduction of a PermitRemoteCommand directive analogous to PermitLocalCommand. However, SSH's configuration precedence model complicates this approach.
Looking at the man page for `ssh_config` we can see the description for the LocalCommand.
That final line is the important one, it states, ‘This directive is ignored unless PermitLocalCommand has been enabled’ confirms what we saw in the config file.
This means that it is off by default and attackers can’t use it, unless an admin sets it to ‘yes’?
No, Looking at the next screenshot of the ssh_config manual pages, we can see SSH works by setting the values in the config file by ‘the first obtained value’. The order it gets these values is:
1) Command line
2) User config
3) System-wide config
So even if the PermitLocalCommand value is defaulted to no or set to no by an admin in the system-wide config, the attacker can include `PermitLocalCommand yes` in the user supplied config, which is the first read, and what will be used, ignoring the system value. If maintainers added the PermitRemoteCommand in the same way it would also be overwritten by the user/attacker.
Lots of fixes could be implemented. One potential simple design change would be to increase user visibility when a RemoteCommand directive is executed. For example, SSH clients could display a warning or require user confirmation before executing commands sourced from configuration files. Similar approaches have been adopted elsewhere in the industry to increase awareness of potentially dangerous actions.
The issue is this isn’t a bug, it’s a feature of the service that has the potential to be abused.
Given the current state, this attack is insidious for the following reasons:
Good news is a couple small fixes to visibility could kill the attack.