Ransomware – a Latent Threat [Part 1]

For a long time now, ransomware has been an issue, but it's far from being a short-lived phenomenon – quite the opposite. That's why Stephan Berger, Senior Cyber Security Analyst at InfoGuard, gave a presentation on the subject of ransomware and the current threat situation at this year's Swiss Cyber Storm. Two blog articles outline the key points of the talk and explain them in detail.

InfoGuard's Incident Response team attach enormous importance to observations, experiences, and lessons learned from past incidents. Many times when we investigate compromised networks, we see the same patterns via which attackers gain initial access to the network.

1) Phishing & MalDocs – stealing credentials and running malicious documents

Despite the fact that user awareness training sessions and phishing campaigns are now regularly carried out at many companies, phishing – the theft of legitimate credentials – and executing malicious documents (MalDocs) are still among the most common attack methods used to gain access to corporate networks. The success of these techniques can be explained, among other things, by the way they cleverly trick users, as I demonstrated at the Swiss Cyber Storm using a real-world case.

In Figure 1 (on the left), a user received an e-mail from a company called "Transfer24 GmbH". In the e-mail, the company writes that a package will be delivered, including a link to where the corresponding documents are stored. What is particularly tricky is that the attackers not only sent a targeted phishing e-mail, but also made contact by phone, which created a sense of trust. Speaking in German without a foreign accent, they pointed out that the receipt of the package needed to be confirmed via a link in the e-mail, and the corresponding software ("Track a Package") had to be installed. Of course, the software was pure camouflage. The download installed a Trojan, which gave the attackers an initial foothold in the network.

Fig. 1: Two examples of malicious mails and files

On the right side of Figure 1 is another scenario; once again, an e-mail. Now you might think that users with greater awareness should be able to identify this e-mail as being suspicious, right? Some probably do, but others, for reasons that are legitimate, do not. In this case, the attackers had taken over an external company's e-mail account and misused an actual e-mail conversation to send prepared documents (in the image in OneDrive) to the target company. In addition, OneDrive is commonly used for exchanging documents with partners within the company, even with the presumed sender, so it was not seen as suspicious. When the prepared document was opened, the attackers were then able to gain initial access to the network, and they did so completely unnoticed.

Vulnerabilities – an Achilles Heel

This year in particular, many critical vulnerabilities have been made public that have enabled attackers to gain access to networks. One popular, heavily exploited vulnerability was “ProxyLogon” in Exchange Server, which allowed attackers to execute code on the server. In addition to quickly applying security patches, one of Microsoft's recommendations was to scan the Exchange servers with the “Microsoft Security Scanner“.

As a result of this vulnerability, our team has investigated dozens of potentially hacked Exchange servers in Switzerland, as well as abroad. In many cases, before contacting InfoGuard, customers had already started the Microsoft Scanner on the systems. In the process, many web shells were already detected and deleted by attackers, but not in every case, as shown in the next example.

Figure 2 shows the path to a web shell (in orange) dropped by an attacker on the Exchange server using the ProxyLogon vulnerability. The customer ran Microsoft Scanner on the server before contacting us. However, it seems that the scanner was unable to detect and delete all traces of the attacks.

Fig. 2: Web shell inside the Exchange path (Red box: date the file was created)

When analysing the web shell placement, two points became clear (Fig. 3):

• The web shell was marked as “hidden” – the file could not be found in Windows Explorer, unless you explicitly enable hidden files to be displayed.
• The file could not be deleted to begin with – see the red error message in Figure 3. This was only possible once the file attributes had been modified.

Fig. 3: Deleting the web shell was more difficult. (Red box: Directory Listing - directory display from Exchange directory. Orange box: Failed attempt to delete the malicious file.)

This problem is most likely related to the Microsoft scanner. It could find the file but could not delete it. This point clearly shows that you can only rely on automatic checks to a limited extent, and in many cases, you need a specialist team like ours to perform a more thorough analysis.

Extending the perimeter into the cloud

Figure 4 shows a screenshot of the vulnerability search engine “shodan.io” It shows that a server in the Azure Cloud exposed the Remote Desktop Protocol port (RDP – port 3389) on the Internet.

Fig. 4: Exposed RDP port on the Internet

The access that was exposed was set up by a major Swiss company for external consultants as a jump host into the internal network. The vulnerability here was that no second authentication factor was put in place, which allowed the attackers to crack the administrator's account password. After successfully logging into the Jump host, the attackers stole more passwords. Furthermore, the Azure host was connected to the internal on-prem network, which led to the network being completely compromised.

Key points & lessons learned

• Use of Multi-Factor Authentication (MFA): All external accesses to the network must be protected with a second factor (VPN, Citrix, TeamViewer, etc.). This reduces the risk of credentials being leaked by phishing.
• “Assume a breach” – even after patches have been installed: The Exchange Server example shows that systems could have been hacked even before security patches were in place. This makes a check by specialists unavoidable in some cases.
• Regular Cloud-System Verification: All major cloud providers offer API and command line access that can be used to create a simple overview of all cloud systems with exposed ports.

2) Persistences and backdoors

Numerous investigations carried out by our InfoGuard CSIRT, in addition to the obviously malicious backdoors such as Scheduled Tasks or AutoRuns, found entries that had been created by attackers that were unable to be recognised as potentially malicious. Within a short time after the network was initially compromised, attackers installed legitimate remote desktop solutions like "AnyDesk" or "Splashtop" on various servers in the network.

Fig. 5: Remote-Desktop Solutions

It is not obvious to the system administrator at first glance that one of these remote desktop solutions has been installed by attackers to serve as a backdoor. For attackers, these kinds of installations have the advantage that anti-virus solutions do not recognise these products as being malicious, and they are in use on many networks. Even after changing the affected users’ passwords and removing the placed attacker code in a targeted manner, network access was still possible by installing the remote desktop solutions.

Not surprisingly, in almost all of the cases they investigated, our team found traces of the well-known “Cobalt Strike” strike framework. Tens of individuals and companies scan the internet for known Cobalt Strike Team servers and publicly publish the information they find to combat them (see Figure 6). Security teams can use these freely available sources to scan their proxy and firewall logs for traces of Cobalt Strike, in order to identify whether the network has been compromised by attackers.

Fig. 6: A List of Cobalt-Strike Team Servers on the Internet (Source: The DFIR Report)

Key points & lessons learned

• Monitoring connections to known remote desktop providers: Connections to known remote desktop providers can be searched for within the proxy and firewall logs. For example, if a critical server establishes an AnyDesk connection, this could signal a deeper compromise.
• Use of freely-available information: Many IP and domain lists are published on the Internet. These can be used to track and search for attackers in your own network.
• Remote-Desktop Product Connection Data: A range of products like AnyDesk and TeamViewer write connection data about what time each user logged in. This data can help to clarify whether the installation of a product is legitimate or whether a potential backdoor has been set up. In the event of an incident, this connection data can provide valuable information about when the attackers logged into the network.

As you probably already know, ransomware is a complex problem that requires experience and expertise. In the second part, you will find out about four more exciting insights and takeaways about ransomware and our day-to-day work at CSIRT. If you don't want to miss out on this and other articles, you should subscribe to our blog updates now! You will receive the latest article directly in your mailbox every week.