Skip to main content
An icon of a telephone receiver
Sign In
Cybersecurity Centre Try For Free

A look back at 2021

This past year has certainly been eventful for cyber security practitioners and now that 2021 is coming to an end we’d like to take a quick look back at some of the most impactful security events of the year.

Emotet takedown, then return

Emotet is one of the longest-lasting cybercrime services in existence, with their first banking Trojan identified in 2014 and was one of the most heavily distributed malware families of 2020. It was typically distributed via malicious Word documents sent by email with language such as “Your invoice,” “Payment Details,” or possible shipping updates. Once infected, it attempts to connect to a Command and Control (C2) server for additional instructions. The Emotet botnet operated as a service that was rented out to other threat actors and used for deploying additional malware, frequently ending in ransomware.

On January 27, 2021, a team of law enforcement agencies from around the world announced that they seized and took down the Emotet infrastructure and arrested an undisclosed number of operators as part of Operation LadyBird. Hundreds of servers used by Emotet for its C2 were seized and sinkholed, with many active Emotet infections around the world now connecting to those sinkholed domains. A sinkholed domain is a domain name where the DNS servers have been configured to respond with false information. In this case, DNS requests for Emotet’s C2 servers return IP addresses that belong to law enforcement, essentially crippling the malware and preventing any further infections. Law enforcement now had control of the Emotet botnet and pushed out a new module that would have it uninstall itself on any infected machines on April 25, 2021.

Since the takedown, there was no further sign of Emotet, until November 15, 2021. That’s when researchers around the world began seeing a new version of Emotet being distributed. The initial sighting showed an Emotet DLL being downloaded by Trickbot, but since then multiple reports have come in of new malicious emails with malicious Emotet attachments spoofing replies from stolen email chains, presumably originating from already infected hosts. The attachments observed so far have been Word *.DOCM, Excel *.XLSM, or Zip files. The newer version of Emotet is mostly the same as the older version; however, the new version now encrypts C2 traffic via HTTPS instead of relying on unencrypted HTTP.

Since then, it has been back to business as usual for Emotet with a several malspam campaigns being launched in the past month that server Emotet. We were hopeful at the beginning of the year that Emotet was dead, but it seems like it will still be around for a while.

Significant Vulnerabilities of 2021

There were several major vulnerabilities disclosed this year that had a significant impact on the security industry.

Microsoft Exchange

We’ll start with a chain of vulnerabilities in Microsoft Exchange originally discovered by DEVCORE and publicly disclosed in March 2021 commonly known as Proxylogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065). Using Proxylogon, an unauthenticated bad actor is able to execute their own code on a remote Exchange server. Microsoft originally had a patch for the Proxylogon vulnerabilities scheduled for March 9th, but then Volexity discovered a threat actor group known as Hafnium were using Proxylogon in the wild to drop webshells on vulnerable Exchange servers across the internet. In light of this information, Microsoft decided to release the relevant patches a week early.

Once the information about the vulnerability was disclosed, it wasn’t long before threat actors and researchers had reverse-engineered Microsoft’s patches and several proof-of-concept exploits were available. We immediately saw mass scanning for this vulnerability and webshells being deployed on thousands of Exchange servers.

Initial activity involved exfiltrating data from mailboxes and dropping webshells. We saw several different groups competing for webshells on the same server. For example, if one group was creating a webshell named “shell1.aspx” there might be another group installing their own webshell named “shell2.aspx” and deleting “shell1.aspx”. Then we saw threat actors creating webshells with randomly generated names.  It wasn’t long before we saw threat actors using these webshells to deploy coin miners, the most common one being an XMR coin miner known as Lemon Duck. It wasn’t too long before new ransomware strains appeared that were specifically targeting ProxyLogon, specifically, DearCry and Black KingDom.

Exchange continued being a major topic of interest throughout 2021. In April, another group of critical vulnerabilities in Exchange that could lead to RCE were patched on Patch Tuesday, CVE-2021-28480, CVE-2021-28481, CVE-2021-28482, and CVE-2021-28483. By September, several new Exchange vulnerabilities had also been disclosed and patched by Microsoft. ProxyToken (CVE-2021-33766), ProxyOracle (CVE-2021-31195 and CVE-2021-31196), and ProxyShell (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207)

Vulnerable Printers EVERYWHERE

Microsoft released a patch in June for a local privilege escalation vulnerability in the Windows Print Spooler service (CVE-2021-1675). A few weeks later, some researchers discovered the patch was insufficient in mitigating the vulnerability and a new attack method was discovered that could result in remote code execution (RCE). Microsoft assigned this new RCE vulnerability a new CVE, CVE 2021-34527, which became commonly known as Print Nightmare. Check out the CRU’s write-up of Print Nightmare for more details at https://www.connectwise.com/resources/a-nightmare-on-spooler-street. An out-of-band patch was released for Print Nightmare on July 6th, but soon afterwards it was discovered that this patch was still insufficient to fully mitigate the vulnerability so Microsoft released additional information with some added mitigation steps required, which we documented here.

Later in July, another local privilege escalation vulnerability in the Windows Print Spooler, (CVE-2021-34481) was disclosed. Similar to when Print Nightmare was first disclosed, Microsoft’s recommended workaround is to stop and disable the Print Spooler service.

Security researchers found another Windows printer-related RCE vulnerability (CVE-2021-36958) in July exploiting the Queue-Specific Files feature in Windows Point and Print capability. This is a feature in Windows that allows a system to connect to a remote printer without having to pre-install the drivers from disk or other installation media. When a system connects to a print server configured with Point and Print, all necessary drivers, files, and configuration information are automatically downloaded from the print server to the client. The exploit involves a malicious print server that will use this feature to install malware or any malicious DLL that will run with SYSTEM privileges on the system connecting to it.

If that wasn’t enough, another printer-related vulnerability was disclosed this summer. A high-severity local privilege escalation has been discovered in HP, Samsung, and Xerox print drivers since 2005. Specifically, CVE-2021-3438 is a buffer overflow vulnerability in the SSPORT.SYS driver that can be used to escalate privileges from a normal user to the SYSTEM user. So far, there has been no evidence that this vulnerability has been exploited in the wild, but it’s been around for 16 years. HP has released a bulletin listing all impacted devices, as has Xerox, along with patches to mitigate the issue.

Log4j

Now we come to what many have called the worst vulnerability in a decade or more, Log4Shell. Log4j is a Java logging framework that is part of the Apache Logging Services. Log4j is also the most commonly used framework used by Java applications for logging. Log4Shell (CVE-2021-44228) is a remote code execution vulnerability in Log4j2 versions 2.14.1 and below originally disclosed by the Apache Foundation on December 6, 2021.

The vulnerability uses the Java Naming and Directory Interface™ (JNDI), an API which allows Java applications to lookup remote services in a resource-independent way. For example, JNDI can be used to perform an LDAP lookup by connecting to an LDAP server with a URI like “jndi:ldap://$ldaphost:$ldapport”. The vulnerability in Log4j comes into play when a malicious user can get Log4j to log a JNDI URI that points to a malicious LDAP (or some other JNDI resource) service hosting malicious code. When the malicious JNDI URI is logged on a system running a vulnerable version of Log4j, Java will attempt to connect to the malicious URI, download the payload, and execute it. All a malicious user needs to do to exploit this vulnerability is create a log and this can be done in a variety of ways depending on the application in question. For example, the most common method we have seen is by targeting Java web applications and including the malicious URI in the HTTP request or even the User-Agent. Log4Shell has also been exploited in applications such as Minecraft by sending a malicious URI via game chat. There have been claims from security researchers that they were able to trigger exploits in LinkedIn and Twitter by making posts that including malicious URIs.

The potential attack vectors for this vulnerability are mind-boggling. There are hundreds of thousands of applications that use Log4j and any one of these could potentially be affected by this vulnerability. The most common method we’ve seen so far is targeting exposed web services, but there are countless other attack vectors. For example, Ghidra is a Java-based reverse engineering application originally released by the NSA that is commonly used by researchers, such as the CRU, for reverse engineering malware. We were able to confirm with our own testing what others have also discovered that Ghidra can be exploited with a malicious EXE file, for example, https://github.com/zhuowei/GhidraLog4Shell. A bad actor could potentially embed this attack in malware and compromise the system of a security researcher looking into their malware. Security researchers at Blumira disclosed that CVE-2021-44228 could also be exploited using JavaScript WebSockets. The list of potential attack vectors for this, and other Log4j vulnerabilities could go on and on.

Several additional related vulnerabilities in Log4j have been discovered since the original Log4Shell, though none of them are nearly as severe or as far reaching. After Log4Shell (CVE-2021-44228), came CVE-2021-45046, originally reported as a Denial of Service (DoS) vulnerability but then later upgraded to an RCE. This vulnerability applied to Log4j 2.5.0, the latest version at the time that included a fix for CVE-2021-44228, and as a result Apache released 2.16.0. Then there was CVE-2021-4104, an RCE in Log4j 1.2. The previous vulnerabilities only applied to Log4j 2.x and even though 1.2 has reached end-of-life (EOL) and is no longer supported by Apache, we saw many vendors claim they were not affected because they were still using this older version. Then there was CVE-2021-45105, a new DoS vulnerability in 2.16.0. According to the Apache Software Foundation’s advisory at https://logging.apache.org/log4j/2.x/security.html:

“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.”

And more recently, we have CVE-2021-44832, another RCE, this one in 2.17.0 which was released to patch CVE-2021-45105. According to Apache, “an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.” The latest versions of Log4j, 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6), address all currently known vulnerabilities.

Significant Attacks in 2021

Ransomware has been a significant and costly problem for years now and it’s only getting worse. We saw several large scale or significant Ransomware attacks in 2021 that will have long lasting affects for us all.

Colonial Pipeline ransomware attack and the aftermath

On May 7, 2021, Colonial Pipeline, the largest oil pipeline in the U.S., was targeted by a ransomware attack from an affiliate of the ransomware-as-a-service (RAAS) group known as DarkSide. The entire pipeline that carries gasoline, diesel, and jet fuel from Texas to the East Coast was shut down as a precaution, which resulted in fuel shortages and panic buying all along the East Coast. The pipeline was down for nearly six days, with operations spinning back up late in the day on May 12 and returning to full operation on May 15.

While this is perhaps one of the most public ransomware attacks, and Colonial Pipeline paid a $4.4 million ransom, it is not by any means the largest payout in recent history. Some reports from 2020 suggest payouts as large as $10 million, and ransom demands as high as $30 million.

This year, we’ve seen major vulnerabilities (such as those mentioned above) being used to target tens of thousands of organizations around the world within a short time. And then there’s the SolarWinds supply chain attack that we continued to see new information revealed throughout the year, such as an update in May from the SolarWinds CEO that the attack dates back to at least January 2019. The US suggested in January that Russian state actors were behind the attack, and President Biden imposed new sanctions against Russia in April in response. Meanwhile, Russia’s foreign intelligence service made unsubstantiated claims that the US and UK were actually behind the hack.

The hit to critical infrastructure has spurred several official responses from the US government. In response to all the above, US President Joe Biden released an executive order on May 12 dictating new guidelines and regulations for government contractors as well as companies that provide IT and OT services. If you’re interested in learning more about how the executive order will impact MSPs, check out this webinar.

Also, there were five bi-partisan cybersecurity bills submitted in the House this week alone.

The five bipartisan bills introduced in House on Monday include:

So far, these bills are still all in review and have not been enacted yet.

In October, the US convened 30 nations from around the world to discuss strategies for combating ransomware, intentionally omitting Russia who is seen as one of the biggest sources of the problem.

On June 7, the Department of Justice reported that the FBI was able to recover $2.3 million of the cryptocurrency ransom paid by Colonial Pipeline. Bitcoin transaction are all recorded in a public blockchain that anyone can access. These transactions are recorded based on a unique Bitcoin wallet address which is not directly tied to an individual identify within the Bitcoin protocol itself. One method of cashing out Bitcoin is to get a Bitcoin wallet from one of many public crypt exchanges. Exchanges in the US do require individuals to prove their identity before being able to cash out, and in most cases the exchange itself is actually in control of the wallet. The FBI was able to track the movement of the Bitcoin used in the Colonial Pipeline ransom payment to a public exchange within the US and then was able to seize the Bitcoin with a court order.

The Colonial Pipeline attack, and the US government’s response, also prompted responses within the RaaS ecosystem itself. Two major cybercrime forums (XSS and Exploit) that have been used by RaaS groups to recruit affiliates banned ransomware ads. The admins of the Exploit forum state the recent attention that the indiscriminate targeting of recent ransomware attacks has caused as the source for their decision to ban ransomware ads and the removal of all topics related to ransomware operations and all affiliate programs. The full statement is as follows:

Good day,

We are glad to see pentesters, malware specialists, coders, but we are not happy with lockers - they attract a lot of attention. This type of activity is not good to us in view of the fact that networks are locked indiscriminately we do not consider it appropriate for RaaS partner programs to be present on our forum.

It was decided to remove all affiliate programs and prohibit them as a type of activity on our forum.

All topics related to lockers will be deleted.

After the attack, DarkSide released a statement stating that they will now vet targets and forbid their affiliates from targeting certain companies. The press release issued by DarkSide states:

We are apolitical, we do not participate in geopolitics, do not need to tie us with a defined government and look for other our motives.

Our goal is to make money, and not creating problems for society.

From today we introduce moderation and check each company that our partners want to encrypt to avoid social consequences in the future.” - DarkSide gang.

However, soon after this press release, DarkSide reported that several servers in their control were shut down “at the request of law enforcement agencies,” and a significant portion of their cryptocurrency was transferred to an unknown wallet. Then, DarkSide shut down all operations and sent the following message to their affiliates (provided by Intel471):

Starting from version one, we promised to speak about problems honestly and openly. A couple of hours ago, we lost access to the public part of our infrastructure, in particular to the

  • Blog
  • payment server
  • CDN servers

At the moment, these servers cannot be accessed via SSH, and the hosting panels have been blocked.

The hosting support service doesn’t provide any information except “at the request of law enforcement authorities.” In addition, a couple of hours after the seizure, funds from the payment server (belonging to us and our clients) were withdrawn to an unknown account.

The following actions will be taken to solve the current issue: You will be given decryption tools for all the companies that haven’t paid yet.

After that, you will be free to communicate with them wherever you want in any way you want. Contact the support service. We will withdraw the deposit to resolve the issues with all the affected users.

The approximate date of compensation is May 23 (due to the fact that the deposit is to be put on hold for 10 days on XSS).

In view of the above and due to the pressure from the US, the affiliate program is closed. Stay safe and good luck.

The landing page, servers, and other resources will be taken down within 48 hours.

On the same day, another RaaS group, Babuk, made a similar announcement claiming they were handing over their ransomware source code to another group, and they would focus only on data leaks. Since then, REvil and Avaddon released coordinated statements regarding amendments to the rules of their organizations, barring affiliates from targeting government, healthcare, educational, and charity organizations and that any other targets must be pre-approved.

In July, a new ransomware group going by the name BlackMatter began operations, and is believe by many to be a rebrand of DarkSide, the RaaS group associated with the Colonial Pipeline attack.

Kaseya

On July 2, 2021, Kaseya was compromised and used to spread Sodinokibi (aka REvil), the successor of GandCrab, ransomware through their on-prem VSA appliance. According to Kaseya, around 40 MSPs had their VSA appliances compromised, which REvil then used as a platform for a Buffalo Jump to target their clients, reaching as many as 800-1500 small-to-medium sized businesses, including Swedish grocery retailer Coop, forcing them to close 800 stores that Saturday. REvil is the same Ransomware-as-a-Service Russian cybercrime gang linked to the JBS meat processor attack in May and was particularly busy over the summer months, targeting energy companies and even a US nuclear weapons contractor.

In the aftermath of the attack, REvil suddenly shut down all operations and disappeared without a trace leaving may victims unable to pay ransoms if they chose and no way of decrypting their data. On July 22, Kaseya was able to obtain a master decryptor key from a “trusted third party” and distributed it amongst their customers.

It was generally believed that REvil would return eventually under a new name; however, in September, their dark web server suddenly returned to life after two months of silence. On September 9, a new user on a common Russian cybercrime forum named REvil began posting with their explanation of events leading to their shutdown and the disappearance of their spokesperson, UNKWN. Below is a translation of that post:

As Unknown (aka 8800) disappeared, we (the coders) backed up and turned off all the servers. Thought that he was arrested. We tried to search, but to no avail. We waited - he did not show up and we restored everything from backups.

After UNKWN disappeared, the hoster informed us that the Clearnet servers were compromised and they deleted them at once. We shut down the main server with the keys right afterward.

Kaseya decryptor, which was allegedly leaked by the law enforcement, in fact, was leaked by one of our operators during the generation of the decryptor." - REvil

After a month of operations, REvil’s sites went down again in Ocbtober. A user named “o_neday” believed to be affiliated with the RaaS gang posted on the XSS cybercrime forum stated that someone had hijacked their domain, “But since we have today at 17.10 from 12:00 Moscow time, someone brought up the hidden-services of a landing and a blog with the same keys as ours, my fears were confirmed. The third party has backups with onion service keys,” Then in November, the U.S. Department of Justice announced charges filed against a 22-year old Ukrainian national believed to be an affiliate of the REvil RaaS program involved in the July attack targeting Kaseya and their customers.

Conclusion

This has been an eventful year.

Ransomware continues to be a major problem. Law enforcement has become more effective at tracking the bad guys, taking down their infrastructure, and we’ve had several significant arrests; however, as we saw with Emotet, when a threat actor is taken down, they either come back stronger, having learned from their experiences, or are quickly replaced by more bad actors.

Software vulnerabilities will continue to be a problem. If software exists there will be vulnerabilities. Unfortunately, that is just the way of things. Yes, there are best practices that can help, secure coding techniques, code audits, thorough testing, etc., but no one has discovered a method for completely removing the risk

All that being said, it is not all doom and gloom. There is no way to completely remove the risks, but if you understand them, you can plan accordingly and mitigate much of the risk. A good vulnerability management plan is important. Keep track of software on your systems, especially public facing ones, and plan time for regular patching. Patching for vulnerabilities should not be a reactionary process but should be proactive. Accept that most likely every piece of software you use could potentially be used against you and plan accordingly. Work through what could happen, for example, if someone gains full root control of a switch, a mail server, or a DVR. Compromises are never good things, but good planning can significantly limit the impact. Prevention is important but work on the assumption that someday you will be ransomed and keep good backups. Don’t forget to test them regularly as well and keep them in a location where they will remain safe if your entire network is compromised. Yes, the threats and related risks are significant and continue to get worse but following established best practices (more than we can cover in a single article) will significantly reduce your overall risk. And as always, the CRU is here to help in any way we can.