::%16777216 — so what exactly are you?

::%16777216 — so what exactly are you?

It is known that during attacks, adversaries can use tunneling. For example, to punch a reverse tunnel from a compromised Windows host deep inside an organization’s network, so that it can be used to easily connect interactively via RDP to that same host.

Methods for detecting such activity are also known. For example, you should definitely pay attention to the presence of IP addresses 127.0.0.1 or ::1 in logs as the source — it is from such addresses within the compromised system that connections to target services may be established.

😳 For many years, specialists investigating breaches noted and described in reports that when ngrok was used for the tunnel in such attacks, upon connecting via RDP, a strange value was recorded in the logs instead of the source IP address — ::%16777216.

On the one hand, this is an excellent artifact that is easy to search for: it is unlikely to occur in normal activity, and therefore its presence serves as a good and fairly accurate indicator of an attack.

But, on the other hand, there was no clear explanation anywhere of what this “magic number” is, why exactly it appears in logs, and whether it is always a sign of ngrok specifically being used.

😎 We decided to figure it out, and we managed to get answers:

🔴 ::%16777216 appears in logs in event 1149 (and also 4778 and 4779) instead of the IP address ::1 as a result of a bug in Windows.

🔴 The bug is not related to the presence of any vulnerability, but is caused by inconsistent interpretation of data in memory by different RDP protocol modules

🔴 The bug occurs not only with the address ::1, but also in any other case when a connection to RDP is made using the IPv6 protocol (for example, instead of the address fe80::6e1d:980d:9401:719b you will see the string 0:0:fe80::6e1d:980d%2607874452 in the logs)

🔴 The problem was most often associated with the ngrok utility, because during tunneling it creates a connection on the host using IPv6 by default, unlike many other utilities that use IPv4.

🔴 The address in the logs is not “corrupted” irreversibly; it can be restored:

1. Take the value from the log: 0:0:fe80::6e1d:980d%2607874452

2. Convert the part after % to HEX: 2607874452 dec = 9b710194 hex

3. Remove two zeros on the left, append the resulting digits on the right taking into account reverse byte order: fe80::6e1d:980d:9401:719b

The bug existed at least starting from Windows Server 2012 R2 in all versions of Windows. In early summer 2025, we sent information about this to Microsoft, and the results of recent tests show that in current versions (with the May 2026 updates) the bug has been fixed (we did not receive a response confirming the fix).

And the author discussed the nuances of the research, interesting details of IP address representation, and approaches to conducting the experiments that helped find the explanation in a talk at the ËPRSTCON conference held in May — look for the talk recording, presentation, and transcript on the conference website.

So what should be done now? 😨

1️⃣ In older versions of Windows that no longer receive updates, continue to pay attention to ::%16777216 in logs.

2️⃣ In current versions of Windows, where updates may have been installed, additionally check for the presence of ::1 where such an address should not normally be.

3️⃣ Keep in mind that there are many different utilities for creating tunnels, and such an indicator does not in any way confirm the use of ngrok specifically.

0️⃣ Optionally — improve your log parsing so that it restores the normal IP address: this will help take the address into account in correlation rules and get more relevant results during retrospective event search or threat hunting.

P.S.: and don’t forget to pay attention to the appearance of 127.0.0.1 in inappropriate places.

P.P.S.: and not only 127.0.0.1, but any address from the 127.0.0.0/8 network: all these addresses correspond to the localhost interface according to RFC5735, and this works in all popular OSes. It is unlikely that an adversary would easily manage to use an address like 127.0.13.37 as a source, but specifying such addresses as a destination for connecting to processes on the local host is quite possible.

#tip #win
@ptescalator