{
	"id": "31198eff-936f-4f7a-86ed-43005d7c3387",
	"created_at": "2026-04-06T00:15:41.756923Z",
	"updated_at": "2026-04-10T03:20:38.509455Z",
	"deleted_at": null,
	"sha1_hash": "94c8ac3d6389f54db85951361a3345b44f3a0a74",
	"title": "Analysis of a Convoluted Attack Chain Involving Ngrok",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 360386,
	"plain_text": "Analysis of a Convoluted Attack Chain Involving Ngrok\r\nBy Abraham Camba, Khristoffer Jocson, Gilbert Sison, Jay Yaneza ( words)\r\nPublished: 2020-09-14 · Archived: 2026-04-05 20:36:18 UTC\r\nOne of the primary benefits of an Endpoint Detection and Responseproducts (EDR) security solution is that it\r\ngives blue teams (security personnel responsible for maintaining and analyzing an organization’s network\r\ndefenses) the visibility required to detect an attack in its early stages and visualize an incident as it is happening. \r\nWhile these kinds of security technology innovations benefit the cybersecurity industry as a whole, it is often\r\nmatched by a corresponding evolution in the tools and techniques that malicious actors use as a response.\r\nThe Trend Micro ™ Managed XDRproducts team recently handled an incident involving one of Trend Micro’s\r\ncustomers. The incident revealed how a malicious actor incorporated certain techniques into an attack, making it\r\nmore difficult for blue teams and security researchers alike to analyze the chain of events in a clean and easily\r\nunderstandable manner.\r\nInitial Investigation\r\nIn July 2020, we noticed the following suspicious event in our customer’s environment via the Trend Micro Apex\r\nOne ™ Endpoint Security Solution:\r\nProcess: c:\\windows\\system32\\reg.exe CommandLine: REG ADD\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run /v \u003cvalue\u003e /t REG_SZ /d \"\\\"c:\\Windows\\system32\\\r\n\u003crandom name\u003e\\\"\" /f\r\nA few points to note: first, the value name of the registry being created was patterned after a certain security\r\nvendor. Second, there was a mistake (or maybe intentional) in the spelling of the registry name (as seen in the\r\n\u003cvalue\u003e portion, which we did not include for privacy reasons). Finally, there is the randomly named executable\r\nin the system directory. When considering all of these together, the alert presented us with obvious red flags.\r\nThe executable file turned out to be a keylogger that sends the mouse and key clicks it sniffs to a Gmail account.\r\nWe found hardcoded information in the binary, providing evidence that it was created specifically for the targeted\r\norganization. Furthermore, we also learned from the binary that the attackers had existing knowledge about the\r\norganization.\r\nWe searched records and events using the keylogger’s file name and hash and found the following:\r\nFile Events\r\nBased on the created analysis chains, the keylogger is dropped by the ntoskrnl.exe process. This tells us that the\r\nfile was dropped either via network share or through the use of an exploit affecting the kernel.\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 1 of 7\n\nFigure 1. The keylogger is dropped by Ntoskrnl.exe\r\nEvents With Command-Line Parameters\r\nWhile it was not surprising to find reg.exe process events containing the identified random file name (given that it\r\ntriggered the investigation), the chain of processes that preceded reg.exe was more difficult to predict.\r\nFigure 2. The chain of events leading up to the reg.exe process\r\nInstead of the keylogger calling reg.exe to generate its persistence mechanism, another process — services.exe —\r\nseems to be the root of the chain. This means the attacker managed to create a service that would launch a series\r\nof cmd.exe processes to build the persistence mechanism using reg.exe.\r\nRegistry Data\r\nDuring our investigation, we found service registry entries containing the command line parameter passed to\r\nreg.exe:\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 2 of 7\n\nReg Key: hklm\\system\\currentcontrolset\\services\\\u003crandom\u003e\r\nReg Value: imagepath\r\nReg Data: %COMSPEC% /C echo REG ADD\r\nHKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run /v \u003cvalue\u003e /t REG_SZ /d\r\n\"\\\"c:\\Windows\\system32\\\u003crandom\u003e\\\"\" /f ^\u003e %SYSTEMDRIVE%\\WINDOWS\\Temp\\\u003crandom\u003e.txt \u003e\r\n\\WINDOWS\\Temp\\\u003crandom\u003e.bat \u0026 %COMSPEC% /C start %COMSPEC% /C\r\n\\WINDOWS\\Temp\\\u003crandom\u003e.bat\r\nThis registry entry explains the multiple cmd.exe processes in the chain leading to the reg.exe shown above. The\r\ncommand line of the first cmd.exe will contain the string after %COMSPEC%, while the second will contain the\r\nstring after the second %COMSPEC%, and so on, in sequential order.\r\nDigging Deeper\r\nThe act of creating a service to launch a command was uitlized for implementing the shell portion of a backdoor\r\nshell. Using the string %COMSPEC%, we searched and examined other service registry entries, eventually\r\ndiscovering multiple tools and commands that were executed using this method.\r\nWe observed commands that were derived from service registry entries like “query user”, “net user \u003cuser\r\naccount\u003e /domain”, “ping \u003cip address\u003e”, etc. on multiple machines. If a new backdoor shell was indeed\r\nimplemented, it meant that we still needed to find the component that communicates with the outside world, as\r\nwell as the part that creates the service entries.\r\nWe got our first break when we found the command “\u003crandom\u003e tcp --authtoken \u003ctoken\u003e -config \u003cconfig file\u003e\r\n\u003cip\u003e:445”. Based on the parameters alone, this particular tool looked like it had something to do with network\r\ncommunication, utilizing a common port (SMB/TCP 445) that is widely used within a corporate environment.\r\nAfter collecting the file, we determined that the tool is a copy of ngrok, a software program that allows an internal\r\nmachine to be visible to the outside world by routing the traffic through the ngrok website. The existence of the\r\ntool on two machines meant that those machines were externally visible. We have previously written how ngrok\r\ncan be usednews- cybercrime-and-digital-threats for malicious purposes.\r\nHow the service entries are created is still a mystery at this point. We searched instances of psexesvc.exe (the\r\nserver part of PsExec) and remotesvc.exe, but the result of indicator of compromise (IOC) sweeping was\r\ninconclusive. However, we did discover the string “admin/smb/psexec_command” in one of the service entries,\r\nwhich resembles the command execution of Metasploit. What we know is that Metasploit’s PsExec module does\r\nnot drop a binary on the target machine. Further research shows that some versions of Mimikatz and Impacket do\r\npossess such a feature.\r\nSimulating the Attack\r\nTo try to figure out the attack’s mechanics, we performed a simple simulation by installing ngrok on one of the\r\nmachines (Machine A) that was neither visible nor accessible externally.\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 3 of 7\n\nFigure 3. Installing ngrok on Machine A\r\nNgrok can expose to the internet any open IP port within the internal network that is accessible to Machine A\r\n(including itself). In our example, ngrok exposed another machine (Machine B) 192.168.19.129:445 through the\r\nngrok server. We were then able to access 192.168.19.129:445 via 2.tcp.ngrok.io:14139.\r\nBy using the service Smbexec module of the Impacket tool kit and the credentials of Machine B, we were able to\r\nsend simple ping commands to Machine B from an external machine.\r\nFigure 4. Using an external machine to send ping commands to Machine B\r\nThe resulting behavior was similar to what we observed in the customer’s environment, where randomly named\r\nservice entries were created and then deleted. The commands were executed without needing to drop a binary on\r\nthe target machine.\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 4 of 7\n\nFurthermore, since the commands were executed as a service, it runs with elevated privileges. Given that network\r\ntraffic was tunneled via the ngrok service, the command and control server was effectively hidden. As long as the\r\nattacker knows the ngrok-assigned public address, it can connect to the compromised endpoint from anywhere, at\r\nany time.\r\nFigure 5. Connecting to a compromised machine using the ngrok-assigned public address\r\nWhile we did not expect the simulation to recreate the actions of the attacker completely, it provided valuable\r\ncontext on how the attack possibly happened.\r\nIn the case of the simulation, it required ngrok installed on the internal machine, the ngrok server domain and port,\r\nand an administrator account. We believe that the attacker possessed all three, given that they were the ones who\r\ninstalled ngrok on the machine, and they seemed to have been present long enough to know certain details about\r\nthe environment. They were also able to compromise a high-privilege account. Based on this, the simulation we\r\nconducted fits the attack characteristics.\r\nFighting Back With EDR\r\nThe diagram in Figure 6 shows a typical backdoor shell root cause analysis chain.\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 5 of 7\n\nFigure 6. Root cause analysis chain of a typical backdoor shell\r\nShell.exe launches cmd.exe, which then launches the tool to execute the given command. It could also be shown\r\nlaunching tools it has installed — such as Toola.exe — in the diagram. This kind of diagram is straightforward,\r\nmaking it easy to identify suspicious objects and determine the basic flow of how things work in an attack.\r\nIn this incident, the root cause analysis begins with services.exe and ends with the executed tool or command.\r\nThere was no evidence that a multi-stage tool that drops other tools were ever used, and based on the access the\r\nattackers had in this model, it is highly probable they had no use for such a tool. The machines were so accessible\r\nthat the attackers could run any tool they needed without having to think of clever mechanisms to install the\r\nbinary (such as moving it laterally from one machine to another) — in other words, tools can be run virtually on\r\ndemand. Take, for instance, the installation of the keylogger; the attackers dropped the keylogger file via server\r\nmessage block (SMB) and issued a separate command to create its persistence mechanism. They did not use a\r\nkeylogger that creates its own persistence mechanism, likely because it is not difficult for them to create the\r\nregistry entry for persistence remotely.\r\nMeaningful root cause analysis chains are difficult to come by because everything starts with services.exe (or\r\nanother windows process in cases of file dropping, for instance) running one command/tool at a time. The\r\nresulting chain can look more like a “tree” with services.exe at the center, where each branch represents a\r\ncommand executed through services.exe.\r\nOur analysis shows that the technique used in the attack hinders the ability of security researchers to piece\r\ntogether the sequence of events via a short diagram. However, certain features of EDR are designed to handle\r\nincidents like this.\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 6 of 7\n\nMitigation Through Suspicious Events\r\nSuspicious events are effective triggers of an EDR solution, and the capability to mitigate through the same\r\nsolution is ideal for blue teams. In this incident, Trend Micro Managed XDR utilized the Apex One capabilities to\r\nboth investigate and mitigate the threat in the same software suite.\r\nInvestigation Through Logged Events\r\nConventional incident response methodology would often require running a tool to acquire evidence from a\r\nsuspect host. In this investigation, everything was done through the examination of EDR logged events. No\r\nmemory or disk image acquisition was done for the investigation, which means that the data collected by EDR\r\nwas enough to determine how similar attacks work. The chronological order of the commands were taken from the\r\ntime stamps of the events. Even without the self-explanatory diagram EDR creates, it is still possible to determine\r\nhow the attack took place.\r\nNew Alerts\r\nEDR allows for the painless creation of alerts to trigger an investigation. In this case, new alerts can be created\r\nwhenever services.exe launches cmd.exe and when %comspec% is written to an autostart registry entry, which can\r\nhelp future threat hunting capabilities for blue teams.\r\nTrend Micro Solutions\r\nThe Trend Micro XDRproducts solution protects connected emails, endpoints, servers, cloud workloads, and\r\nnetworks by using powerful AI and security analytics to correlate data and provide an optimized set of alerts via a\r\nsingle console. With this technology, organizations can quickly identify threats and remediate their impact in a\r\ntimely manner.\r\nTrend Micro Managed XDRproducts offers expert threat monitoring, correlation, and analysis from experienced\r\ncybersecurity industry veterans, providing 24/7 service that allows organizations to have one single source of\r\ndetection, analysis, and response. This service is enhanced by solutions that combine AI and  Trend Micro’s\r\nwealth of global threat intelligence. \r\nTags\r\nSource: https://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nhttps://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/20/i/analysis-of-a-convoluted-attack-chain-involving-ngrok.html"
	],
	"report_names": [
		"analysis-of-a-convoluted-attack-chain-involving-ngrok.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434541,
	"ts_updated_at": 1775791238,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/94c8ac3d6389f54db85951361a3345b44f3a0a74.pdf",
		"text": "https://archive.orkl.eu/94c8ac3d6389f54db85951361a3345b44f3a0a74.txt",
		"img": "https://archive.orkl.eu/94c8ac3d6389f54db85951361a3345b44f3a0a74.jpg"
	}
}