Cyber criminals are taking over computers to weave a complex traffic anonymizing service. CounterCraft’s team of experts has discovered a unique scheme in which threat actors are abusing SSH servers on captured machines as part of the final layer of traffic delivery. Instead of the traditional VPN traffic anonymization, these attackers are building their own infrastructure into a standard and necessary tool (SSH) so that it goes unnoticed among the regular computing activity.
This allows a variety of threat activity to pass by security controls on all kinds of websites. We discovered this traffic thanks to one of our own deception environments. Fortunately, there are some simple things you can do to detect this type of activity, which affect everyone from blogging sites to retail sites and mail providers.
Read on to find out how ongoing criminal innovation is finding more and more sophisticated ways around traditional security measures.
A Look into How
Attackers have been using hijacked internet servers for ages. One of the most popular uses of a hijacked server is to anonymize connections and use the server as a proxy. There are many different mechanisms for proxying communications through a host, such as using a dedicated process, exploiting vulnerabilities or abusing existing services.
In this blog post, we are going to describe how attackers currently abuse SSH servers in the Internet for a variety of malicious purposes, based on recent findings seen when using our specific cloud-deployed deception campaigns.
Brute-force Attacks
When you connect a device to the Internet, it is immediately recognized by massive Internet scanners; in a few minutes there will be multiple brute-force login attempts against your SSH server (unless you use a non-standard SSH port).
Whenever any of those attempts succeeds, the most likely scenario is that an automated bot will install a cryptominer and perhaps use the device for scanning the Internet looking for more victims. They are only interested in using the device for mining more cryptocurrencies or finding other possible victims to compromise.
However, SSH servers have a nice feature (well appreciated by system administrators) that allows them to create TCP tunnels forwarding ports. This feature is called SSH Port Forwarding, also known as SSH tunneling. SSH tunneling is a method of transporting arbitrary networking data over an encrypted SSH connection. Sometimes attackers are not interested in installing anything in the device; they just want to take advantage of this feature to tunnel their communications. This makes their malicious activity within the operating system difficult to detect as there won’t be any commands or new processes.
Abusing SSH
In this case, everything started with one of our cloud-based deception campaigns. These campaigns are built to be as realistic as possible, and, using our Active Behavior technology, we are able to automate the creation and maintenance of these deception machines. We started to get some notifications of valid logins (from a user with weak credentials). The attackers thought it was a real machine and then decided to use it. However, it seemed that the attacker wasn’t executing any commands on the compromised server. At the beginning we thought that perhaps they were just looking for accessible servers (to be used in future stages), but there were other types of events at the same time that forced us to investigate a little deeper.
There were two additional types of event (apart from Valid Authentications) that helped us to identify what was happening: new outgoing TCP connections and DSN queries.
In the following image we can see how the SSH daemon is connecting to a number of servers to their SMTP port (25/tcp)
The next image shows how they connected to IMAP servers from well-known email providers:
Or just connected to websites:
After analyzing these events, it was clear the attackers were using our server for tunneling their own communications using SSH Port Forwarding. If the system administrator had logged in the server, she would be able to see lots of SSH processes as there were multiple concurrent tunnels at the same time:
Since we had all the events, we could easily find all the tunnels to remote port tcp/443 using the following EQL rule:
sequence with maxspan=1s [network where event='DNSResolution' and parent_process_path='/usr/sbin/sshd'] [network where event='CreateConnection' and remote_port=443 and parent_process_path='/usr/sbin/sshd']
MITRE ATT&CK Techniques
Protocol Tunneling (T1572): attackers tunnel network communications to and from a victim system within a separate protocol to avoid detection/network filtering and/or enable access to otherwise unreachable systems. Tunneling involves explicitly encapsulating a protocol within another.
Proxy – Multi-hop (T1090.003): to disguise the source of malicious traffic, adversaries may chain together multiple proxies.
Remote Services SSH (T1021.004): attackers use Valid Accounts to log into remote machines using Secure Shell (SSH).
Valid Accounts – Local Accounts (T1078.003): attackers abuse credentials of existing local accounts for creating the SSH tunnels.
The Entire Architecture
Even though there were hundreds of connections per second to multiple different destinations, the traffic was coming from one or two source IP addresses. Our guess is that the attackers created an advanced proxy and anonymized network topology using SOCK servers that were using the compromised hosts.
By using hundreds, if not thousands, of compromised SSH servers, it is possible to create a huge VPN-like anonymizing network that can be offered as a service. Attackers can use this service for a variety of malicious purposes without the need to use Tor or any other VPN services that can be blacklisted (known Tor exit nodes, known malicious VPNs, etc.). The biggest advantage of this network is that the output nodes are compromised machines, with legitimate services that are more difficult to blacklist. The network owners just need to keep scanning the Internet looking for more SSH servers to be added to their malicious network.
Tunnel Destinations
Now that we had gained a clear understanding of what was happening in those servers, it was time to analyze the traffic being tunneled through our SSH servers. Following the trail, you can find some of the most common destinations, although there were many other destinations similar to the ones described in the next section.
Depending on the objectives of the users of the anonymizing network, we would be able to see different types of traffic.
SMTP Servers
The old-school massive SPAM distribution method, so nothing special here; just hundreds of SMTP connections per minute.
IMAP Servers
In this instance, there were many connections to IMAP servers trying to authenticate using an username and password. Many of those connections failed, so we suspect that they were using an old stolen credentials database, but those who were able to login were adding SPAM emails to the users inboxes.
This is a smart method of sending SPAM without being detected and blocked, since the majority of the mail providers will block SPAM emails when they reach the SMTP server, but not in the IMAP server.
There are some tools for automating the entire process like Email Appender, as researchers from Gemini pointed out some time ago.
Example of a failed IMAP connection traffic connecting to the AOL IMAP servers:
* OK [CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=XOAUTH2 ID MOVE NAMESPACE XYMHIGHESTMODSEQ UIDPLUS LITERAL+ CHILDREN X-MSG-EXT OBJECTID] IMAP4rev1 Hello
001 LOGIN "[email protected]" "196824@SerXXX"
001 NO [AUTHENTICATIONFAILED] LOGIN Invalid credentials
Blogging Sites
Another common attack technique we detected was authentication attempts on blogging sites using the xml-rpc.php file that is occasionally not well-protected.
The majority of the requests were just testing the existence of the xml-rpc.php, so it is very likely that the attackers were using a specific tool that:
– Checks for the existence of xml-rpc.php
– Tries to authenticate using xml-rpc.php
– Injects JavaScript in existing blog posts or comments.
They weren’t using random usernames and passwords, so it seemed that they were using a dictionary or some stolen credentials database.
Again, many of those brute-forcing attempts were unsuccessful (99%), so it seems that they didn’t have an updated credential database.
Example of a failed authentication:
POST /xmlrpc.php HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 198
Content-Type: application/x-www-form-urlencoded
Host: xxx.com
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.109 Safari/537.36
<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value>juanmv23</value></param><param><value>T*uckYou^M</value></param></params></methodCall>
Search Engines
Many of the search engine connections were searching for websites, services or electronics, but they included a suspicious parameter in the URL:
/search?gl=ru&num=100&q=samsung+galaxy+s+7&uule=w+CAIQICIUTW9zY293LE1vc2NvdyxSdXNzaWE Moscow
/search?gl=ru&num=1&q=site%3Acable.ru%2Fcable%2Fgroup-apvg.php&uule=w+CAIQICIUTW9zY293LE1vc2NvdyxSdXNzaWE
The UULE region parameter (&uule=) of some search engines allows you to see the actual search results by region, which corresponds to geolocation when directly located in an arbitrary region (in other words, it is possible to get search results for your region of interest in your browser without the need for additional plug-ins (GeoClever and the like) or directly physical presence in the region).
In our examples, if we decode the UULE parameter (w+CAIQICI ++ ‘Canonical Name’ Base64 format) we then discover that the search was for ‘Moscow,Moscow,Russia’.
Those searches were trying to improve the search engine ranking of those search terms for users in the same location. Retail Sites
The majority of the connections to retails sites were internal searches in the online stores, suggesting possible click fraud schemes or altering the views of specific items.
In this case they were targeting online stores from China (AliExpress, AliBaba, TaoBao); Russia (Svyaznoy, Tecnopark, Utkonos, market.yandex.ru, dns-shop.ru, UniZoo, Sima-land) and Kazakhstan (Kaspi, Sulpak), among others.
Cryptocurrency Sites
We observed two different behaviors in the connections to well-known cryptocurrency sites: authentications and user creation.
Many of the authentication requests were done after solving a CAPTCHA challenge, so it seems that they were able to automate it.
Example of authentication:
POST XXX/mywallet/enable HTTP/1.1
Connection: keep-alive
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=UTF-8
Content-Length: 847
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.4157.143 Safari/537.36
Accept-Language: en-US;q=0.9,en
Upgrade-Insecure-Requests: 1
Accept: application/json, text/plain, */*
Referer: https://www.google.com/recaptcha/api2/anchor?ar=1&k=...
{"login":"[email protected]","password":"9bf1f8efef60a4a3..","captcha":"03AGdBq26...","platform":"Web","version":"master:cb03011","two_factor_token":null,"device_name":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.4157.143 Safari/537.36"}
The operations to create new users were performed from the cryptocurrency site mobile app, but they were also done automatically. Device Farms or Click Farms have been used for different purposes, and this could be an example of another one.
Example of user creation:
POST /XXX HTTP/1.1
X-App-Version: 6.45.0
X-App-Build-Number: 64500
Accept-Language: en
X-Locale: en_US
X-Device-Model: HO-3931RO
X-Device-Product: RR-8047BP
X-Device-Brand: OPPO
X-Device-Manufacturer: Zoji
X-System-Name: H-3149K
X-System-Version: 23
X-System-Board: VK-7140BKF
X-System-BOOTLOADER: uboot
X-Os-Version: 6.1.0
X-Os-Name: Android
X-Android-Id: 159aebf6986eccdaf82403efa6352e0c
X-Advertising-Id: 8bb1c1d8-e231-4acd-8f80-db132642438c
Content-Type: application/json; charset=UTF-8
Content-Length: 205
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/3.6.1
{"first_name":"vu","last_name":"O","email":"[email protected]","password":"N7xvzXX","accept_user_agreement":true,"application_client_id":"34183b03a3e1f0b74..."}
Banks
Some of the connections we detected were trying to authenticate against different online banks using stolen credentials. We saw hundreds of these connections per second. It seems that they were just testing if those users were still valid.
Example:
POST //api/Authentication/login HTTP/1.1
Host: amfirst.onlinebank.com
User-Agent: ecFmDsqZrp6gQs5I
Content-Type: application/json
Content-Length: 69
Accept: application/json
Accept-Language: en-US;q=1
Cache-Control: no-cache
Accept-Encoding: gzip, deflate
{"rememberMe":false,"loginName":"chelfarr2XXX","password":"donaldxxx"}
Adult sites
There were many connections to adult advertisements, affiliate pages and tracking pages but we didn’t have enough evidence of click fraud or other fraud methods.
How can I detect this type of SSH Abuse?
This kind of SSH abuse can be detected easily by remaining vigilant for particular trends:
– A significant spike of the outgoing traffic from Internet servers that have SSH
– An increase of the number of valid SSH authentications
– An increase of the number of SSH processes
If you detect someone abusing any of your SSH servers, you can also disable the SSH Port Forwarding feature with the AllowTcpForwarding parameter. However, as the documentation states, disabling TCP forwarding does not improve security unless users are also denied shell access. This is because they can always install their own forwarders. So the bottom line is to make sure you don’t have any users with weak credentials and use 2FA in your SSH access.