Introduction

Outbound SSH can be a serious blind spot. Attackers can use SSH tunnels to bypass firewalls, EDR, and even AppLocker — proxying malicious activity without running tools directly on the host. This enables lateral movement and internal compromise.

To mitigate this, I block outbound SSH connections and enforce application control on SSH binaries using Microsoft Intune, combining Windows Firewall and AppLocker for layered protection.

Why Outbound SSH is Dangerous

SSH is often seen as a secure protocol, but in the wrong hands, it becomes a powerful tool for attackers. Allowing outbound SSH from endpoints introduces several risks:

• Firewall Evasion Through Tunneling
  • Attackers can create SSH tunnels to forward other traffic (HTTP, RDP, SMB) through port 22. This bypasses outbound filtering and hides malicious activity inside encrypted SSH traffic.
• Data Exfiltration
  • SSH provides end-to-end encryption, making it easy for attackers to move sensitive data out of your network without triggering DLP or inspection tools.
• EDR Blind Spot
  • Modern Windows includes OpenSSH client binaries like ssh.exe. Attackers can use these built-in tools—no need for custom malware—making detection harder.
• Lateral Movement
  • SSH tunnels allow attackers to pivot inside the network, proxying internal services through a single encrypted channel.

AppLocker – Lock down ssh.exe to Local Administrators only

If AppLocker is already configured with default rules, the Windows folder is typically allowed for Everyone. To restrict ssh.exe to Local Administrators, you need two steps:

Step 1: Exclude ssh.exe from the default Windows allow rule

Modify the existing rule that allows %WINDIR%\* by adding an exception for ssh.exe. This prevents standard users from running it while keeping other Windows binaries accessible.

<FilePathRule Id="dc25c247-c39d-4fb3-9343-62ed59649dfa" Name="All files located in the Windows folder" Description="Allows members of the Everyone group to run applications that are located in the Windows folder." UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePathCondition Path="%WINDIR%\*" />
      </Conditions>
      <Exceptions>
        <FilePathCondition Path="%WINDIR%\System32\OpenSSH\ssh.exe" />
    </Exceptions>
</FilePathRule>

Step 2: Allow ssh.exe for Local Administrators

Create a dedicated rule granting access only to the Administrators group (SID S-1-5-32-544)

<FilePathRule Id="6e6e1abd-0b4e-4740-a825-a34118c17ded" Name="%WINDIR%\System32\OpenSSH\ssh.exe" Description="Allow SSH" UserOrGroupSid="S-1-5-32-544" Action="Allow">
  <Conditions>
    <FilePathCondition Path="%WINDIR%\System32\OpenSSH\ssh.exe" />
  </Conditions>
</FilePathRule>

Effect: What Happens After Enforcement

After deploying the AppLocker policy, the difference is clear. When a standard user tries to run ssh.exe, AppLocker blocks execution and displays a Group Policy message:

This confirms that non-admin users cannot use SSH for tunneling or remote access.

Next, open an elevated Command Prompt as a Local Administrator and run the same command:

Here, ssh.exe runs successfully and proves that the rule works as intended – admins retain access while regular users are restricted.

Windows Firewall – Block Outbound SSH (Port 22)

Blocking the SSH binary is only half the solution. Attackers can still use other tools or scripts to initiate SSH connections if port 22 is open. To close this gap, create an outbound firewall rule that denies TCP traffic on port 22.

In Microsoft Intune, create a new Windows Firewall Rules policy. Within that policy, create a new rule similar to below:

Configure the remote port range to 22 and set the protocol to 6 (TCP). This ensures the firewall rule specifically targets SSH traffic over TCP port 22

• Important Limitation: Blocking outbound traffic on port 22 only works if SSH uses its default port. If an attacker or legitimate process configures SSH to listen on a different port—say 2222 or 443—the firewall rule won’t apply, and the connection will succeed. This is why relying solely on port-based blocking is not enough. Combining it with AppLocker restrictions on SSH binaries provides a stronger defense against tunneling and unauthorized remote access.

Validation – Test Outbound SSH Blocking

To confirm that your Windows Firewall rule is working, use portquiz.net, a public service that listens on all TCP ports. This allows you to test outbound connectivity easily.

Run the following command in PowerShell:

Test-NetConnection portquiz.net -Port 22

ENJOY 🙂