By David Pearson
This is an introduction to a series of blog posts I’ll be writing, detailing remote access capabilities on the network. Today, I’ll be explaining what this means, the motivation for this series, key takeaways, and pointing out what I’m not aiming to do. I hope you’ll follow along as new posts are created, and I hope to receive many questions about my findings–after all, without asking questions, proactive threat hunting simply wouldn’t exist!
What is a Remote Access Capability
In the context of this series, a remote access capability is a product or tool that allows somebody who is not physically present at a device to view, control, or otherwise interact with the device. This clarification is important, as there are plenty of ways to interact with a system in non-visual ways (whether that’s SSH, FTP, or calling up someone sitting in front of the device and asking them to do your bidding). By defining the context to visual interaction, we focus on capabilities that generally exist for the purposes of IT support or collaborative work.
Remote access capabilities are a double-edged sword. They provide benefits such as cost savings, the ability to virtually bring disparate groups together, and work flexibility to the organization, while at the same time they provide a woefully under-examined and mostly opaque access vector for both malicious insiders and external adversaries alike. More still, some of these solutions are actually marketed with the purpose of circumventing organizational controls that organizations have worked hard to implement.
As somebody who is tasked with helping to root out security issues in the network–be it policy violation, unpatched users, a malicious insider, a successful external threat, or any other number of scenarios–shouldn’t we yearn for more clarity about tools that allow our network perimeter to be bypassed in such a simple manner?
This series will focus on just that. I’ll do so by taking a step-by-step analysis through several of the most popular remote access capabilities that are likely already on your network, providing in-depth knowledge of each tool’s footprint on the network. In the process, I’ll share several tips about how the capability can be discovered using the Awake platform, effectively providing fuzzy queries to enhance your workflow.
But what is the point of this in-depth analysis? Can’t we discover this behavior by looking for DNS requests for common sites of the tool–or by tagging all of the IP addresses related to the tool’s infrastructure–and then looking for the volume of traffic in either direction? Doing so will likely provide you a first-order level of visibility into many of these tools, sure. However, do you know all of the IP addresses (or domain names) associated with any of these tools? Even if you did, what if it changes? Do you also know that the tool’s behavior likely requires its own infrastructure? What if it’s repackaged to be used by a malicious actor? Even if you know how much traffic is going in either direction, do you know what is occurring in that traffic? Do you know the true endpoint, or the true originator? These are the questions that I plan to answer for you.
In the end, these tools are commonly used for a reason. Many of them are excellent methods to bring together disparate groups who may be precluded from sharing the same space, and many save administrators’ time in walking to and from an end user’s desk potentially multiple times to solve a trivial issue. The point of this series isn’t to say one solution is better than the others, or to point out vulnerabilities in their implementations. This is simply focused on delivering a framework to help you understand these protocols and then enable you make sense of traffic like this when you run into it in your own environment.
Follow along as I dive into the first remote access capability analyzed—LogMeIn.