Advanced IP Scanner: the preferred scanner in the A(P)T toolbox

1. Introduction

Hunt & Hackett has been working on a wide variety of targeted ransomware cases. During these targeted ransomware cases, ‘Advanced IP Scanner’ (AIS)¹ was regularly used as reconnaissance tool for Active Scanning (T1595) and Network Service Scanning (T1046). This has not only been observed by Hunt & Hackett, but also by other incident response parties.

Groups that have (had) used Advanced IP Scanner include:

• Conti²
• Darkside/UNC2465³
• Egregor⁴
• Hades/ Evilcorp⁵
• REvil⁶
• Ryuk/ UNC1878⁷
• UNC2447⁷
• UNC Iranian actor⁸
• Dharma⁹

This small write-up focuses on some of the forensic traces left by AIS that Hunt & Hackett observed during Incident Response cases. The artefacts might be useful during an investigation, and can shine some (minor) light on threat actors’ activities. Furthermore, this blogpost provides some pointers related to detecting Advanced IP Scanner.

2. Advanced IP Scanner

Advanced IP Scanner (AIS) is freely available online¹ and can be executed as an installer and as a portable version. Both have been used by threat actors. After the installation / execution of AIS, the end user is presented with an overview as shown in Figure 1.

Figure 1 - GUI of Advanced IP Scanner.

AIS is a simple and user-friendly IP scanner, which provides the end user with a concise overview of the systems found in the network. From a high-level perspective, AIS provides the user with the following functionality:

1. IP scanning: scan the given range for systems that are alive, or dead;
2. Tools: provide functionality to ping an IP, perform a Tracert, or connect with Telnet / SSH;
3. Remote connections: connect to the corresponding IP address via HTTP, HTTPS, FTP, RDP, or RADMIN (only works if RADMIN is installed).
4. (Re)boot/ Wake-On-Lan: the user can boot / reboot a system if the user is authorized to do so, or can send Wake-On-Lan (WOL) packages to a system. If enabled, this provides the user with functionality to remotely boot a system.

The fact that there is a portable version of Advanced IP Scanner, that it has a GUI and that the tool supports a variety of ways to interact with identified systems probably contributes to it popularity.

3. Forensic traces

AIS leaves traces on a host system when it is executed. This section describes the traces that are created during usage of the AIS tool and more specifically, the Windows registry keys that are being created. Do note that for both the portable version as well as the installer version, the same traces are created in the Windows registry.

3.1 AIS registry keys

After the installation of AIS, keys and subkeys are created in the HKEY_USERS hive of the user under which account AIS was installed. Data is more specifically stored at the following location:

Computer\HKEY_USERS\<SID>\SOFTWARE\famatech\advanced_ip_scanner

The mentioned registry keys are created, by both the installer version of AIS and the portable version, after the first usage of the application and subsequently some (sub)keys are updated after using AIS. While looking at it graphically, multiple keys and subkeys are created as shown in Figure 2. The most relevant traces from a forensic perspective are either stored under the ‘advanced_ip_scanner’, or the ‘State’ key.

Figure 2 – Overview of keys created with regards to AIS.

3.2 The ‘advanced_ip_scanner’ keys and subkeys

If we look at the subkeys of the advanced_ip_scanner key, we are presented with the keys as shown in Table 2. This table shows the name and type of the subkeys, together with the value (data) of the subkey, a comment with what the subkey represents and what the function is within AIS. Especially the locale subkey might be of relevance, since this could potentially reveal something about the background of the threat actor, as well as the locale_timestamp key since this gives an indication of when the application has been used for the first time.

Table 2: Overview of the AIS registry key ‘advanced_ip_scanner’ under HKEY_USERS hive.

3.3 The ‘advanced_ip_scanner\State’ keys and subkeys

A variety of subkeys are listed under the key advanced_ip_scanner/State, as shown in Table 3. This table shows the name of subkeys together with the type of subkeys, the value (data) of the subkey, a comment with what the subkey represents and what the function is within AIS. All the keys, except for LastRangeUsed are created upon the first time the application is started. The key LastRangeUsed is created upon the first time a scan is performed with AIS.

The three registry keys IpRangesMruList, LastRangeUsed and SearchMruList under the key advanced_ip_scanner\State are especially interesting, as they could be of relevance during an IR assignment.

• LastRangeUsed: this key represents the last scan that is being performed and shows the range that has been scanned.
• IpRangesMruList: this key represents all ranges scanned by AIS, including the frequency. Every range scanned has a prefix of [digit]-[digit], followed by [start IP address]-[IP range]. The first digit of the prefix represents the number of times a range has been scanned, which will be increased after every subsequent scan. The range 192.168.227.1-254 in Table 3 has for example been scanned five times. It’s unknown what the second digit represents, since this digit remained ‘static’ throughout the different tests performed. The scanned IP-range is stored in memory while the application is still running. Upon closure of the application, the data is written from a buffer in memory to the registry. The order in which the scanned IP ranges are stored is unknown.
• SearchMruList: This key contains an overview of all IP-addresses searched for by the user. These are added upon closure of the AIS application. Besides the last searched IP address, also other historical searches are saved here. Do note that a similar prefix is added to IP address, just like for the key IpRangesMruList. However, it’s unknown what this prefix represents.

Table 3 - Overview of the AIS registry State key under HKEY_USERS hive.

4. Detection

Detection of the Advanced IP Scanner process is trivial. Here at Hunt & Hackett, we also try to come up with better, behavioral detection methods that do not rely on static signatures for individual applications.

4.1 Port scanning detection using Chronicle

Detection should not only focus on the characteristics of individual pieces of software, but also on behavior of applications. This means we also try to identify internal port scanning itself, and not merely the execution of Advanced IP Scanner. As part of our detection engineering efforts, we experiment with custom YARA-L¹⁰ rules for Chronicle¹¹ to detect internal port scans.

Experimenting with horizontal port scanning detection

Internal port scanning of entire ranges results in a large number of network connections from the scanning machine to other machines in a corporate network. We can use build-in functionality of Chronicle to experiment with YARA-L rules capable of detecting internal scanning behavior.

In large enough networks, we can attempt to detect hosts that have performed a large number of connection attempts to other internal machines, which is indicative of internal port scans.

The experimental YARA-L rule depicted in Figure 3 for example triggers when a machine has made more than 100 internal connections or connection attempts within 10 minutes. Real-world testing shows that this approach can detect (some) internal port scans, though heavy tuning is required to filter out benign machines / processes that perform internal network discovery for legitimate reasons.

Figure 3 - Experimental YARA-L rule for detecting internal port scans

Limitations of detection attempts

With some filtering effort, we can use Chronicle to detect internal port scans at customers, though this approach is impractical and requires heavy tuning. Additionally, our detection attempt is not foolproof and can be circumvented by a determined attacker.

Some methods of bypassing this detection attempt include:

• Slow scanning to circumvent any time-based detection thresholds.
• Scanning of small IP blocks at a time to bypass any count-based thresholds.

4.2 Port scanning detection using Canary tokens

In the previous section, we concluded that it is not feasible to detect all internal port scans using only network connections data and threshold-based detection rules. To enhance detection, we can place canary tokens at strategic places in an organization’s network. Whenever a canary token is scanned, the cyber defense center will receive an alert and an analyst can investigate why a canary token was triggered.

Whenever an alert is deemed malicious, this indicates an attacker is performing active reconnaissance in an organization’s network. Though, whenever a canary token is triggered, this does not automatically mean a network has been breached. Canary tokens can also be triggered by benign activities, including:

• Misspelled IP addresses or server names
• Applications that (for various reasons) contain network discovery functionality
• System administrators or other users performing network scans for legitimate reasons

5. Detection rules

This section contains an overview of different rules in both Carbon Black as well as Yara-L format.

Additionally, you can find an already existing Sigma rule in the Sigma rule repository https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/win_advanced_ip_scanner.yml. For completeness the Sigma rules is listed in this section as well.

5.1 Sigma

5.2 CarbonBlack

5.3 Chronicle

Sources

1. https://www.advanced-ip-scanner.com/
2. Based on H2-CERT findings during IR assignment
3. https://www.fireeye.com/blog/threat-research/2021/05/shining-a-light-on-darkside-ransomware-operations.html
4. https://www.ic3.gov/Media/News/2021/210108.pdf
5. https://www.bankinfosecurity.com/hades-ransomware-has-targeted-7-large-companies-a-16977
6. https://www.huntandhackett.com/blog/revil-the-usage-of-legitimate-remote-admin-tooling
7. https://www.logpoint.com/en/blog/detecting-fivehands-ransomware-at-different-stages-of-the-kill-chain/
8. https://us-cert.cisa.gov/ncas/alerts/aa20-259a
9. https://www.crowdstrike.com/blog/targeted-dharma-ransomware-intrusions-exhibit-consistent-techniques/
10. https://cloud.google.com/chronicle/docs/detection/yara-l-2-0-syntax
11. https://chronicle.security/