A couple of weeks back, a security researcher alerted his LinkedIn contacts about possibly ongoing targeted attacks stemming from the Iranian subnet 194[.]147[.]140[.]x. He advised cybersecurity specialists to watch out for subnets that may be threatful and consider blocking them. This post encouraged us to look into the subnets and details our findings using IP Netblocks WHOIS Database.

Analysis and Findings

As the first step, we downloaded the daily IP netblocks WHOIS data feeds for three days (i.e., 10—12 January 2021) leading up to the time the post was shared. The goal? To see if IP addresses included in the netblock were being tagged as malicious on open-source blocklist AbuseIPDB, which could be indicative of an ongoing campaign.

The IP netblocks WHOIS data feed for 10 January showed that the IP netblock 194[.]147[.]140[.]0—194[.]147[.]140[.]255 has been modified on January 8 2021. The screenshot below contains an overview of the change:

Note that this highlight contains the domain name kbcequitas[.]hu, which current owner is KBC Securities Hungary, a part of the KBC Equitas Hungary group. The organization is a known local Hungarian stockbroker, investment, and banking company. This post will later provide an interpretation of the organization’s presence in this netblock change.

The feed for 11 January, meanwhile, did not have entries pertaining to the IP netblock in question. But that for 12 January showed various changes made within the netblock as shown by the following screenshots:

• Change to part of the entire netblock under investigation 194[.]147[.]140[.]0–194[.]147[.]140[.]127 made on October 13, 2020.

  

• Change to another part of the netblock: 194[.]147[.]140[.]128–194[.]147[.]140[.]255,, which had taken place on January 8, 2021.

  

• Change to 194[.]147[.]140[.]0/24, which also took place months before on October 13, 2020.

  

While these modifications may not necessarily have anything to do with attacks or malicious activity (especially since some changes happened several months before), it is advisable to double check and dig deeper for utmost security.

AbuseIPDB Search Results

Keying in the IP addresses on AbuseIPDB allowed us to determine that the following were tagged as malicious for the reasons indicated:

• 194[.]147[.]140[.]2: Reported 82 times for port scanning, brute-forcing, and hacking.
• 194[.]147[.]140[.]3: Reported 87 times for port scanning and hacking.
• 194[.]147[.]140[.]4: Reported 172 times for distributed denial-of-service (DDoS) attacks, host exploitation, port scanning, hacking, spoofing, brute-forcing, SQL injection attacks, web app exploitation, and File Transfer Protocol (FTP) brute-forcing.
• 194[.]147[.]140[.]5: Reported 274 times for DDoS attacks, host exploitation, port scanning, brute-forcing, and hacking.
• 194[.]147[.]140[.]6: Reported 96 times for port scanning, brute-forcing, and hacking.
• 194[.]147[.]140[.]7: Reported 156 times for DDoS attacks, host exploitation, port scanning, hacking, SQL injection attacks, brute-forcing, and web app exploitation.
• 194[.]147[.]140[.]8: Reported 144 times for DDoS attacks, host exploitation, hacking, brute-forcing, port scanning, email spamming, FTP brute-forcing, SQL injection attacks, and web app exploitation.
• 194[.]147[.]140[.]9: Reported one time for port scanning.
• 194[.]147[.]140[.]12: Reported 17 times for port scanning, hacking, and brute-forcing.
• 194[.]147[.]140[.]13: Reported 18 times for port scanning, hacking, and brute-forcing.
• 194[.]147[.]140[.]14: Reported 17 times for port scanning and brute-forcing.
• 194[.]147[.]140[.]15: Reported 15 times for port scanning and brute-forcing.
• 194[.]147[.]140[.]16: Reported 16 times for port scanning and brute-forcing.
• 194[.]147[.]140[.]17: Reported 118 times for port scanning, hacking, host exploitation, hacking, DDoS attacks, phishing, web app exploitation, bot communication, and brute-forcing.
• 194[.]147[.]140[.]18: Reported 100 times for port scanning, hacking, host exploitation, web app exploitation, bot communication, and brute-forcing.
• 194[.]147[.]140[.]19: Reported 98 times for port scanning, hacking, host exploitation, web app exploitation, bot communication, and brute-forcing.
• 194[.]147[.]140[.]20: Reported 732 times for port scanning, hacking, host exploitation, brute-forcing, DDoS attacks, phishing, and web app exploitation.
• 194[.]147[.]140[.]21: Reported 664 times for port scanning, brute-forcing, hacking, host exploitation, and bot communication.
• 194[.]147[.]140[.]22: Reported 792 times for port scanning, brute-forcing, web app exploitation, hacking, and host exploitation.
• 194[.]147[.]140[.]23: Reported 732 times for port scanning, hacking, brute-forcing, and host exploitation.
• 194[.]147[.]140[.]24: Reported 720 times for port scanning, brute-forcing, hacking, web app exploitation, and host exploitation.

Organizations that are hesitant to block an entire IP netblock can settle for blocking the small subset indicated in IP Netblocks WHOIS Database (i.e., 194[.]147[.]140[.]0/24) or the specific IP addresses that have been confirmed malicious listed above. Priority should be accorded to those reported hundreds of times, namely, 194[.]147[.]140[.]5, 194[.]147[.]140[.]20, 194[.]147[.]140[.]21, 194[.]147[.]140[.]22, 194[.]147[.]140[.]23, and 194[.]147[.]140[.]24.

In light of these IPs identified as malicious and our earlier findings regarding kbcequitas[.]hu, the netblock seems now to be owned by a benign Hungarian company, according to the currently valid IP WHOIS data at the time of writing. It is probable that the netblock was revoked from the previous owner (originally behind the Iranian subnet) and has been reallocated to a new owner (KBC Securities Hungary) who may even not be aware of the dark history of their new netblock.

So security-wise while it is important to be careful with such a netblock, the new owner should also take care of initiating the blacklist removal, and possibly avoid using the particular IPs that were recently found malicious for some time.

If correct, this interpretation tends to illustrate a consequence of the saturation of the IPv4 space. Organizations getting hold of an IPv4 netblock should therefore be absolutely certain that it does not have a bad reputation due to previous owners’ activities.

Want to know more about the artifacts identified in this post for your own research? Or are you thinking of collaborating with our threat researchers? Contact us for partnership opportunities.