The Endpoint Security Broker

Enable on-demand access to RDP and SSH. Disable access protocols by default.

There’s lots of advice out there on how to improve security for remote sessions: restrict the users who can connect to devices, use jump boxes, ensure sessions are encrypted, shift the default port for the protocol… all good suggestions… but they fail to address the real issue with RDP, SSH, or any other remote access protocol.
If someone has gained entry to a single device on your network (for example, if the user clicked something they shouldn’t have in an email or visited the wrong website), then chances are, the malware in question will be scraping for password hashes and using RDP with pass-the-hash to navigate your network.
Dead men tell no tales – and disabled protocols provide no access. There is no machine as well protected as an offline one. The real answer is to disable RDP (and other access protocols like SSH on Linux, Unix and Mac) entirely. That way, even when attackers have credentials, you massively hamper their ability to move laterally and own your network.
Disabling RDP or SSH is, of course, impractical. No one does it because administrators need remote access to servers and even desktops to perform many routine tasks to troubleshoot incidents and issues. So,  while disabled SSH or RDP may be the most secure thing, it’s simply not done.

Enter Tachyon.

[vimeo_video id=”260984414″]
In Tachyon, you can nominate which users are permitted to access devices via access protocols like RDP and SSH. You can disable access protocols across the board – and in doing so massively reduce your attack vector for your network. When an authorized user wants to access a device, they just click on their RDP or SSH icon, as they always have. They are prompted for the hostname they want to connect to, and then they are prompted for credentials.
Access is instant and uses the standard access protocol for that device (SSH, RDP, VnC, whatever). The authorized user accesses the device via a protocol that was disabled when they typed in the hostname using credentials that (depending on how you configure Tachyon) were not valid when the connection was initiated.

What happens is this: When the user clicks on the icon (rather than just running putty.exe or mstsc):

1. The icon triggers a connection to the Tachyon Restful API, in the user context of whoever is logged in
2. A request is sent to run the Tachyon instruction which will enable access to a remote system
3. The Tachyon API confirms that this person is allowed to run that instruction – and if they are, it will:
   1. Enable the protocol in question on the target device
   2. Create or Enable a user for use with this connection
   3. Set a randomized password for this user
   4. Add this user to any local groups (Windows) or sudoers list (*nix) as preconfigured to ensure the user can run whatever they need to run/are permitted to run
4. The client application will be started (mstsc for example) – and will initiate the connection to the target host. Tachyon has added 200-300ms (yes, that’s milliseconds) in overhead to the connection request.
5. The user is prompted for their credentials (which Tachyon will have provided to the user for this one time only use).
6. The user connects to the machine with all of the rights assigned to the user (that user was disabled or didn’t exist when the process was initiated).

Once the user disconnects, logs out or kills the session:

7. The user account is disabled or deleted (depending on configuration)
8. The user account has its rights and group membership stripped from it
9. The protocol is disabled again.

That’s it. Even if the protocol in question has vulnerabilities – they can’t be exploited if the protocol is disabled/not running. Even if the attacker has a hash from a previous connection, it won’t be valid and the user either won’t exist or will have no rights (and the attacker likely won’t have a protocol to try the hash against!).
Tachyon changes the rules of the game, and the hackers will remain trapped inside the one device they accessed when the user did a silly thing. No lateral movement, no searching for juicy data to exfiltrate – they are locked in.
This is just one of the hundreds of potential use cases for Tachyon. Contact [email protected] today. We can show you how Tachyon can help you better protect, detect and real-time remediate incidents in your environment today.