Secureworks Counter Threat Unit (CTU) researchers say they have observed the Smoke Loader botnet dropping a custom Wi-Fi scanning executable to infected systems. CTU researchers named this malware Whiffy Recon. It triangulates the infected systems’ positions using nearby Wi-Fi access points as a data point for Google’s geolocation API.
Whiffy Recon first checks for the WLANSVC service on the compromised system. This service indicates the presence of a wireless capability on a Windows system. However, the malware only checks for the service name and does not confirm that the service is operational. If the service name does not exist, then the scanner exits. Whiffy Recon persists on the system by creating the wlan.lnk shortcut in the user’s Startup folder. This link points to the original location of the downloaded Whiffy Recon malware.
Whiffy Recon’s main code runs as two loops (see Figure 1). One loop registers the bot with the C2 server, and the second performs Wi-Fi scanning.
The first loop checks for the presence of a file named %APPDATA%\wlan\str-12.bin. The malware recursively scans the %APPDATA%\Roaming\*.* directory until it locates the str-12.bin filename.
It is unclear why it searches the entire directory when it creates the file in a specific location.
If the file exists and contains valid parameters, Whiffy Recon proceeds to the second loop to perform Wi-Fi scanning. If the str-12.bin file does not exist on the system, Whiffy Recon registers the compromised system with the C2 server by sending a JSON payload in an HTTPS POST request (see Figure 2). The HTTP headers include an Authorization field containing a hard-coded UUID.
The body of the request contains three parameters: a randomly generated UUID for the botId that identifies the system, a type set to “COMPUTER”, and a version number of 1. The version number suggests plans for further development.
If the registration is successful, the C2 server responds with a JSON message indicating success (see Figure 3). The “secret” field contains a UUID that is used instead of the hard-coded Authorization UUID in future POST requests. The botId UUID and the secret UUID are stored in the str-12.bin file, which is dropped in the %APPDATA%\Roaming\wlan\ folder.
After identifying the botId and secret key, the malware’s second loop scans for Wi-Fi access points via the Windows WLAN API (see Figure 4). This loop runs every 60 seconds.
The scan results are mapped to a JSON structure (see Figure 5) that is sent to the Google Geolocation API via an HTTPS POST request. The Google Geolocation API is a legitimate service that triangulates a system’s location using collected Wi-Fi access points and mobile network data and returns coordinates. The Whiffy Recon code includes a hard-coded URL that the threat actors use to query the API.
These coordinates are then mapped to a more comprehensive JSON structure (see Figure 6) that contains detailed information about each wireless access point found in the area. This data identifies the encryption methods used by the access points.
This data is sent as a POST request to the C2 server using the secret Authorization UUID and the URI /bots//scanned (see Figure 7).
Because the Wi-Fi scanning occurs every 60 seconds and is enriched with geolocation data, it could allow the threat actors to track the compromised system. It is unclear how the threat actors use this data. Demonstrating access to geolocation information could be used to intimidate victims or pressure them to comply with demands.
To mitigate exposure to this malware, CTU researchers recommend that organisations use available controls to review and restrict access using the indicators listed in Table 1. Note that IP addresses can be reallocated. The IP address and URL may contain malicious content, so consider the risks before opening them in a browser.
If you wish to be removed from this list, please click here.