Mert SARICA
Table of Contents
Introduction
On October 25, 2023, at 11:46, I learned that my Turkish e-Government Gateway account had been temporarily disabled for one hour due to multiple unsuccessful login attempts with the wrong password through the e-Government application and warnings sent to my email address.
Although the likelihood of a threat actor guessing my long and complex password was low, and I also use a two-step authentication method on the e-Government Gateway, as a security researcher, I decided to investigate how my account was temporarily disabled.
Having started my professional career in 2005 as an Ethical Hacker and Penetration Tester, conducting security tests for web applications for years, I began examining the e-Government Gateway login page as if I were a threat actor attempting to hack my account.
For a threat actor to access my account, they needed to have my TCKN (Turkish ID) information. Given that, as seen in my article “Was Turkey’s e-Government Hacked?“, many of our details circulate in the underground, obtained from various sources over the years, I didn’t need to dwell on where and how they found my TCKN information.
Could a threat actor with my TCKN information eventually determine my password through brute force attack and reach the two-step authentication stage? Did e-Government Gateway not have a series of security measures to prevent this attack technique, such as CAPTCHA or IP address blocking? To find answers to these questions, I attempted to log into my e-Government account with incorrect passwords. After two unsuccessful attempts, a CAPTCHA control appeared, as expected in a secure web application, and my account was not disabled. So, how did the attacker manage to temporarily disable my account?
CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a type of security measure known as challenge-response authentication. CAPTCHA helps protect you from spam and password decryption by asking you to complete a simple test that proves you are human and not a computer trying to break into a password protected account. (Source: Google)
In an attempt to find an answer to this question, when I started making unsuccessful login attempts to my e-Government account from different IP addresses using a VPN, I observed that my account was temporarily disabled for one hour on the 5th attempt. This once again demonstrated a security control that should exist in a secure web application. It effectively prevents the detection of the password through a brute force attack, which might target the account through possibly hundreds or thousands of bots.
Who is the Target?
In recent months, due to my articles on WhatsApp Scammers and Cryptocurrency Scammers, I’ve been able to thwart the plans of scammers. In this cyber attack, I set out to determine whether the threat actors had specifically targeted my account or if they had coincidentally come across my account in a password spraying attack targeting broad accounts.
In a password spray attack, the bad guys try the most common passwords across many different accounts and services to gain access to any password protected assets they can find. Usually these span many different organizations and identity providers. For example, an attacker will use a commonly available toolkit like Mailsniper to enumerate all of the users in several organizations and then try “P@$$w0rd” and “Password1” against all of those accounts. (Source: Microsoft)
Image: Arkose Labs
To find an answer to this question, I conducted a Google search to see if there were other individuals like me whose e-Government accounts had been temporarily disabled. Through my search, I discovered that a significant number of people have been subjected to such attacks since 2020.
When I investigated the source of the IP addresses in these screenshots, I found that some of them were originating from a network called Tor, which is frequently used by cybercriminals for anonymous communication.
171.25.193.78 – Tor Exit Node
185.220.100.252 – Tor Exit Node
185.220.101.46 – Tor Exit Node
77.68.20.217 – Tor Exit Node
104.244.73.193 – Tor Exit Node
Considering that this situation has occurred to many individuals over the years, it is highly likely that it was not a targeted attack against me but rather a part of a password spraying attack. To further investigate the IP addresses that played a role in locking my account, I decided to broaden my research.
Technical Investigation
Attackers’ IP Addresses
When I accessed my e-Government account immediately after it was reopened, and began examining the History page, I quickly noticed that the unsuccessful login attempts were made using IPv6 addresses instead of IPv4.
IP Addresses Lookup
When I checked the WHOIS information of the IPv6 addresses through IPinfo, I found that all of them belonged to cloud service providers named Vultr and Linode.
2001:19f0:6001:20f:9a7f:d317:c645:37eb – Vultr
2001:19f0:6801:8dd:daab:291b:a4d6:dfc7 – Vultr
2001:19f0:8001:e5d:8404:4a87:e3cf:58cb – Vultr
2600:3c03:e000:b44:ec11:517f:1d99:7cbc – Linode
2001:19f0:8001:13a:f42d:4d56:deb9:c465 – Vultr
2600:3c06:e001:7ab:c6a6:9c89:949f:96f9 – Linode
Ports
When I scanned the IPv6 addresses for their most well-known open ports using the nmap tool, I found that only the 22nd port, associated with the SSH service, was open.
Journey from IPv6 to IPv4
When I used the nmap tool again (nmap -iL hosts.txt -6 -sV –script ssh-hostkey.nse –script-args ssh_hostkey=all) to search for the fingerprints of SSH services and queried Shodan, I easily found the IPv4 addresses of these servers to gather more information about them.
2001:19f0:6001:20f:9a7f:d317:c645:37eb
ssh-hostkey: b9:cb:48:39:52:d9:f2:83:d8:ba:12:e9:9f:1d:55:21
2001:19f0:6801:8dd:daab:291b:a4d6:dfc7
ssh-hostkey: 41:4f:6f:b8:3e:96:c0:6e:28:d8:7e:f0:81:e9:10:99
2001:19f0:8001:e5d:8404:4a87:e3cf:58cb
ssh-hostkey: 20:c1:8b:f9:06:9a:bc:e0:89:73:02:07:b3:71:b0:0b
2600:3c03:e000:b44:ec11:517f:1d99:7cbc
ssh-hostkey: 1b:c3:d3:43:b5:b1:9a:09:24:18:d3:d8:14:3f:34:fb
2001:19f0:8001:13a:f42d:4d56:deb9:c465
ssh-hostkey: 5d:2b:6d:11:c9:f5:e2:8f:99:bc:2a:30:19:63:90:3c
66.42.105.202 – b9:cb:48:39:52:d9:f2:83:d8:ba:12:e9:9f:1d:55:21
45.32.148.233 – 41:4f:6f:b8:3e:96:c0:6e:28:d8:7e:f0:81:e9:10:99
137.220.33.75 – 20:c1:8b:f9:06:9a:bc:e0:89:73:02:07:b3:71:b0:0b
143.42.185.244 – 1b:c3:d3:43:b5:b1:9a:09:24:18:d3:d8:14:3f:34:fb
104.207.158.196 – 5d:2b:6d:11:c9:f5:e2:8f:99:bc:2a:30:19:63:90:3c
Threat Research
The information gathered from the obtained IPv4 and IPv6 addresses, when searched on various platforms such as VirusTotal, SOCRadar XTI, AlienVault OTX, resulted in findings only on SOCRadar XTI.
According to the results, an end user system associated with the server having the IP address 45.32.148.233, used by the attacker, was compromised in May 2023. A malware named Racoon, used for stealing information, operated on this system. In 2022, another end user system associated with the same IP address was infected with another information-stealing malware called RedLine. All the stolen information was later put up for sale on the Russian underground market.
Examining the content of the files obtained by the SOCRadar Dark Web team, it became apparent that there was once a phpMyAdmin, a database management tool, on the server. In light of this information, threat actors might have had unauthorized access to this server for a long time and could have been using it in their attacks.
New Ports
When examining the IPv4 addresses on the search engine named Censys and scanning the ports using the nmap tool, I discovered that, unlike IPv6 scans, each server had nearly 2000 new ports, excluding port 22.
Having nearly 2000 open ports on a server is not a typical configuration, so I decided to inspect these ports.
Usually, encountering such a large number of open ports on a system is reminiscent of an open proxy server. Therefore, my initial suspicion was towards a proxy server. As I continued to examine the information about the IPv4 addresses used by the attacker on Censys, a line in the records related to the IPv4 address 45.32.148.233 (Proxy-Connection: close) immediately caught my attention, raising a new question in my mind. Could these be similar to the open proxy servers that were frequently encountered on the Internet in the early 2000s?
Anonymous proxy: This server reveals its identity as a proxy server but does not disclose the originating IP address of the client. Although this type of server can be discovered easily, it can be beneficial for some users as it hides the originating IP address. (Source: Wikipedia)
To find an answer to this question, I used the cURL tool to make a request to the https://ifconfig.me/all webpage, specifying the IPv4 address 45.32.148.233 and a random port (22939) listed as a proxy server on Censys. Upon making the request, I observed that the request from the proxy server to this webpage was sent using the IPv6 address 2001:19f0:6801:8dd:4995:dc24:1643:54d5. In short, the answer to the question was “Yes.” These were indeed open proxy servers, allowing me to make web requests to target web pages while hiding my own IPv4 address.
However, the proxy server with the IPv6 address 2001:19f0:6801:8dd:4995:dc24:1643:54d5, as shown in the screenshot above, was not one of those involved in the temporary closure of my e-Government account (2001:19f0:6801:8dd:daab:291b:a4d6:dfc7). To determine the relationship between this proxy server and the mentioned IPv6, I prepared a simple script that connects to the open 2000 ports of the IPv4 address 45.32.148.233 and sends a request to the https://ifconfig.me/ip webpage.
#!/bin/sh
for ((i=22000; i<=24000; i++))
do
curl -x 45.32.148.233:$i -L -s -k https://ifconfig.me/ip >> ip_check_45.32.148.233.txt
echo '' >> ip_check_45.32.148.233.txt
sleep 1
done
In each response from the webpage, a different IPv6 address was present. According to this result, malicious individuals could perform a brute-force attack on a webpage using 2000 different IPv6 addresses. After the script ran for a while, I was able to identify the IPv6 address that was responsible for the attack on my e-Government account among these addresses.
Why are they using an IPv6 address?
While conducting all these investigations, I began to ponder why the attacker chose to use IPv6 addresses. After some time, I realized that the devil is in the details.
When you rent a server from service providers like DigitalOcean, Linode, Vultr, they allocate one IPv4 address to you, and you use this IP address for all your internet-related activities on that server.
Cybercriminals often rent servers from such service providers to carry out or camouflage their cyber attacks. Over time, the IPv4 addresses of servers used in their cyber attacks get detected, blocked, and added to global blacklists by security technologies. As the attempted attacks get thwarted, and their IPv4 addresses become unusable, and with accounts and servers rapidly getting shut down due to complaint notifications, they find themselves in the quest for new servers.
For instance, if we assume that they perform these cyber attacks from 100 servers, paying $6 per server, they would incur a total cost of $600. The longer they can carry out these attacks without being detected, the more cost-effective it becomes for them. Otherwise, as they get blacklisted, they repeatedly have to bear this cost as their accounts and servers are shut down.
Now, how does using IPv6 instead of IPv4 change the game? These service providers typically grant their customers using rented servers only one IPv4 address. However, when it comes to IPv6, they can produce and use thousands of them. This allows malicious actors to conduct their attacks using over a thousand IPv6 addresses by paying just $6. As they get blacklisted, they can generate and use new IPv6 addresses on the servers they employ, effectively avoiding significant consequences until complaints reach the service provider.
So, did the e-Government application, with its security controls and measures, truly make it difficult for attackers to use IPv4 instead of IPv6? Or did attackers prefer IPv6 to secure their operations? To investigate this, after my e-Government account was temporarily closed due to five incorrect login attempts, I tried to log in with the correct password to my wife’s account immediately afterward and successfully gained access.
According to this result, if, in the application or at the network level, an IPv4 account is not blacklisted or blocked when a brute-force attack is attempted on more than two accounts, attackers could carry out these attacks with a single IPv4 address on multiple accounts for an extended period. Otherwise, using IPv6 addresses becomes their only option.
Since I didn’t have the chance to test and confirm this on more than two e-Government accounts, and considering that attackers conducted these attacks through IPv6 systems, it is highly likely that e-Government security measures were effective against the IPv4 addresses used by attackers.
How Can I Protect My e-Government Account?
In conclusion, we can see that cyber attackers, over the years, have resorted to various methods to hack Turkish e-Government accounts, utilizing compromised systems forming bot networks, occasionally using their systems, employing proxy server software to hide their tracks and avoid detection, and purchasing servers from service providers with IPv6 support. In short, they have explored every avenue.
So how can you protect yourself from the attacks discussed in this article? The most crucial step you need to take is to use one of the two-factor authentication methods when logging into your e-Government account.
On this occasion, I wish you a happy new year and hope that 2024 brings health, happiness, and success to you and all your loved ones.
Hope to see you in the following articles.
Mert SARICA
