Log4j was affected by a vulnerability that allowed Remote Code Execution (RCE) attacks. In short, user inputs into a software could lead to a code execution on a remote server. This represents a severe security risk. It was named “Log4Shell” (CVE-2021-44228) and immediately addressed by the Log4j team, who provided a fix. In the following days, additional Log4j vulnerabilities were found. While these do not have the same impact as the first one, they can also cause severe damage. For this reason, it is very important to check systems and always update to the latest versions.

Since Log4j is included in numerous software products, the manufacturers of the products had to and still have to provide updates as well. This is still ongoing, and more Log4j vulnerabilities may emerge in the future.

As a moving target, Log4j still gets a lot of attention, under various aspects:

  • New (and luckily still less severe) vulnerabilities are found.
  • New initiatives are emerging proactively to check log4 sources, such as Google’s initiative: Improving OSS-Fuzz and Jazzer to catch Log4Shell
  • At Greenbone, we are creating even more vulnerability tests to get better test coverage, and deploy them to our products on a daily basis.

We have already received a pretty good CVE coverage for the additional Log4j vulnerabilities that have been published in the last few days, including:

  • CVE-2021-44228
  • CVE-2021-4104
  • CVE-2021-45046
  • CVE-2021-45105

As mentioned earlier, we do not stop here. More local security checks will follow today and tomorrow, once Linux distributions have published their advisories.

We already published some facts about Log4j and how to deal with it in our recent posts:


Greenbone’s vulnerability management finds applications with Log4j vulnerabilities in systems that definitely need to be patched or otherwise protected. Depending on the type of systems and vulnerability, these can be found better or worse. Detection is also constantly improving and being updated. New breaches are found. Therefore, there may always be more systems with Log4Shell vulnerabilities in the network. For this reason, it is worthwhile to regularly update and scan all systems. The Greenbone vulnerability management offers appropriate automation functions for this purpose. But how are vulnerabilities found, and where can they be hidden? Why are vulnerabilities not always directly detectable? The following article will give you a brief insight into how scanning for vulnerabilities like Log4Shell works.

A vulnerability scanner makes specific queries to systems and services and can read from the responses what kind of systems and services they are, but also what products are behind them. This also includes information such as their versions or even settings and other properties. In many cases, this makes it possible to determine whether a vulnerability exists and whether it has already been eliminated. In practice, these are sometimes highly complicated and nested queries, but above all they are also very, very many. Entire networks are scanned for thousands of different vulnerabilities.

The Log4j vulnerability “Log4Shell” (CVE-2021-44228) is a flawed program library used in many web services products. Therefore, partly it is directly visible through a vulnerability scan, but partly it is hidden behind other elements. That is why there is not only one vulnerability test for Log4j, but several. More are added all the time because the manufacturers of the respective products share relevant information and also provide updates to close the gaps. The list of systems affected by Log4Shell is constantly updated at https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592.

Some of the vulnerability tests require an authenticated scan. This means that the scanner must first log into a system and then detect the vulnerability in the system. An authenticated scan can provide more details about vulnerabilities on the scanned system.

The vulnerability tests that are suitable to find the Log4j vulnerability are provided collectively in a scan configuration. Greenbone keeps this “Log4j” scan configuration continuously up-to-date in order to keep adding new tests. As a result, a scan may report a Log4j vulnerability tomorrow that was not found today. It is therefore advisable to configure the Log4j scan to run automatically on a regular basis. This is especially important in the next weeks, when many software vendors are gathering more findings. Greenbone continuously integrates these findings into the tests and the scan configuration.

scanning for vulnerabilities like Log4Shell
Does a Vulnerability Have to Be Exploited to Find It?

Exploiting a vulnerability to find it is not advisable. And fortunately, it is not necessary either. Doing so could cause the very damage that should be avoided at all costs. Moreover, a product vendor that provides vulnerability exploitation as a feature would potentially strongly encourage misuse of that feature, which raises further – not only legal – issues. Therefore, Greenbone’s vulnerability management does not include such features.

Exploitation of the Log4j vulnerability as attackers would do is also not required to prove the existence of the vulnerability. Greenbone has developed several tests to prove Log4Shell, each of which looks at systems in different depths. Several tests can detect the Log4j vulnerability with 100 % certainty, most with 80 % to 97 % certainty. Some tests also collect indicators of 30 % where they do not get close enough to the vulnerability. Each test at Greenbone makes a statement about detection certainty, which is stated as “Quality of Detection.”

What Is the Role of Software Product Vendors?

Manufacturers of a wide variety of products can use Log4j libraries, which are now vulnerable with it. Product manufacturers have included Log4j in different ways. Usually, a deep scan can find Log4j without the vendor’s help. However, most manufacturers also support the process through public vulnerability reports. These can then be used to write vulnerability tests that can provide a reliable vulnerability statement even with less deep scans. The reason for this is that the scans can use simpler configurations through vendor information. In addition, they also run faster.

In principle, however, a vulnerability scanner can also check and find vulnerabilities without the manufacturer publishing a vulnerability report.

Conclusion

Vulnerability management is an indispensable part of IT security. It can find risks and provides valuable information on how to fix them. However, no single measure provides 100 % security, not even vulnerability management. To make a system secure, many elements are used, which in their entirety should provide the best possible security.

This is comparable to a vehicle, where the passenger compartment, seat belts, airbags, brake support, assistance systems and much more increase safety, but can never guarantee it. Vulnerability management makes risks controllable.


Update from 2021-12-20: information about additional vulnerabilities found for Log4j can be found here.


Update from 2021-12-20: vulnerability tests for products running on Microsoft Windows are now available.

Note: The tests check the existence of Log4j and its version. A separate vulnerability test may not be available for each affected application, but all Log4j files are found and reported (/path-to-log4j-file/).

The issued installation paths must be checked and, if necessary, the vendor must be contacted. It must be checked whether updates are already available for the respective application and whether the find is relevant.

PowerShell execution privileges on a target system are required for the account used in an authenticated scan. Some vulnerability tests execute PowerShell commands to increase the accuracy of the results, which require permissions for the duration of a scan.


Update from 2021-12-15: an additional attack vector was identified and reported in CVE-2021-45046. We are working on vulnerability tests for this vector, although our tests are working for this additional case too. We recommend to update to the latest Log4j version. The attack is more complicated and a protection requires a different configuration. But as this is a very new vector, we advise to better be save than sorry. For more information see https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/.


This article collects answers to the most frequently asked questions regarding Greenbone’s Log4j vulnerability test coverage.

What Is this Vulnerability About?

The “Log4Shell” vulnerability affects a software library responsible for recording events (so called “logging”) in software written in the Java programming language. A malicious attacker can use this vulnerability to execute code on the affected systems.

Since this vulnerability can be exploited through the Internet and without any authentication, this can be very critical for affected systems and companies. As the software is also included in a lot of software and services accessible through the Internet, many companies and services are likely to be affected.

More information about this vulnerability can be found here:

Are any Greenbone Products and Services Affected?

We checked the status of potentially affected systems with the highest priority. None of our products or internally and externally provided services are affected.

Can Greenbone Products Detect this Vulnerability?

Yes, detection routines have been integrated into the Greenbone Community Feed and into the Greenbone Enterprise Feed starting with feed version 202112130808. This means that both our appliances and our cloud product are able to detect this vulnerability.

While detection routines are available, the complex nature of this vulnerability means that a detection cannot be guaranteed to find every single affected system or products. This especially applies to unauthenticated “remote” checks, for the following reasons:

  • The product or service may only be vulnerable under very specific circumstances. As the Log4j library is very complex and highly configurable and it is used differently in many products, it is not possible to find all vulnerable instances through a remote check.
  • Security configurations in the customer’s network may prevent a successful verification of the vulnerability.
  • Products and services may also be affected indirectly.

A custom scan configuration for directly detecting this vulnerability as quickly as possible is also available through both feeds. Please note that the current scan configuration only contains active checks (remote and local). Package-version checks are not included to keep the scan configuration, and thus the scan time, minimal.

Is the Detection Included in the Greenbone Community Feed?

Yes. A basic detection for the vulnerability is included in both feeds. Additional vulnerability tests for potentially affected enterprise products are available through the Greenbone Enterprise Feed.

Which Detection Is Included in Which Feed?

Greenbone Enterprise Feed

We are continuously deploying vulnerability tests into the Greenbone Enterprise Feed, so the following list may be incomplete, but reports the status of 12:00 p.m.

Important: To get the most current information regarding your installation, you can search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Apache Struts 2.5.x Log4j RCE Vulnerability (Log4Shell)
  • Apache Druid < 0.22.1 Multiple Vulnerabilities (Log4Shell)
  • Apache Flink < 1.13.4, 1.14.x < 1.14.1 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check
  • Apache Solr 7.x, 8.x Log4j RCE Vulnerability (Log4Shell) – Version Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Version Check
  • VMware Workspace ONE Access Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Operations Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Log Insight Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Automation Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Orchestrator Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Active Check
  • ArcGIS Server <= 10.7.1 Log4j RCE Vulnerability (Log4Shell)
  • Metabase < 0.41.4 Log4j RCE Vulnerability (Log4Shell)
  • Splunk 8.1.x, 8.2.x Log4j RCE Vulnerability (Log4Shell)
  • Wowza Streaming Engine <= 4.8.16 Log4j RCE Vulnerability (Log4Shell)
  • SonicWall Email Security 10.x Log4j RCE Vulnerability (SNWLID-2021-0032, Log4Shell)
  • IBM WebSphere Application Server Log4j RCE Vulnerability (6525706, Log4Shell)
Greenbone Community Feed

We are continuously deploying vulnerability tests into the Greenbone Community Feed, so the following list may be incomplete, but reports the status of 12:00 p.m.

Important: To get the most current information regarding your installation, you can search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Consolidation of Apache Log4j detections
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check

About Authenticated/Unauthenticated Tests

Some version checks require authentication, others do not. Additionally, some could have both.

The respective information is available through the links returned by the search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

The “Quality of Detection” contains information on the detection method. A value of “package (97 %)” indicates an authenticated check, other values like “remote_banner (80 %)” happen unauthenticated.

For more technical information about this see https://docs.greenbone.net/GSM-Manual/gos-21.04/en/reports.html#quality-of-detection-concept.

About Active Tests/Test Checking Version, QoD

You can see if it is an active check based on the QoD and the “Detection Method” on the web interface when viewing the vulnerability test details.

Note: Only systems which are actually logging input which can be modified by an attacker (e.g., specific HTTP request headers, URLs, …) are vulnerable.

The detection method, Quality of Detection, mitigation and lots of further details are available through the links returned by the search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

Scanning for Nodes on Separate VRFs & VLANs

  • Out-of-band (OOB) scanning is currently not possible. Please scan in each segment.
  • We think of such an Out-of-band (OOB) communication/external interaction possibility to be integrated in the future.


Update from 2021-12-20: information about additional vulnerabilities found for Log4j can be found here.


Update from 2021-12-15: the most important FAQ about the Log4j vulnerability detection with Greenbone can be found here.


A critical vulnerability (Log4Shell, CVE-2021-44228) in the widely used Java library Log4j has been discovered. Greenbone has integrated local security checks and active checks via HTTP in their feeds which will help users with the Log4j vulnerability detection to find out if and which of their systems may be affected. Additionally, a special scan configuration which checks precisely for this vulnerability is available for quick results via the feeds.

log4j detection in Greenbone feeds

The vulnerability leads to an extremely critical threat situation, according to the Federal Office for Information Security (BSI). For this reason, the BSI has released a warning of the highest level on the issue. The vulnerability is trivially exploitable, and may allow a complete takeover of the affected systems.

It is a critical risk since attackers can insert code snippets via various ways into the log4j module (e.g., via a regular chat message) and then load code for execution from any LDAP server (which may be under your control).

Customers running Log4j are highly recommend to update their solutions to Log4j version 2.15.0 (or later) to mitigate this flaw, but should be aware of the following:

  • The update currently is “only” restricting access to external LDAP servers by default (will only allow localhost/127.0.0.1) and sets the default of the system property log4j2.formatMsgNoLookups to true.
  • While this mitigates the risk, there may still be applications running Log4j version 2.15.0 that have both (or one) of the above settings incorrect or misconfigured so that the attack vector still exists.

Regarding our solution, customers should be also aware of the following:

  • For a successful detection of this risk, the scanner host needs to be reachable by the target host via TCP.
  • There may be also a flaw in a software which is only gathering and logging the syslog from other remote systems for example, but does not accept logs itself. Such systems could still be attacked by log pollution.
  • It is very important to monitor updates of affected products.
  • In addition, all systems that were vulnerable should be examined for compromise.


The second part of our series on the ongoing professionalization of attacks on IT systems deals with changes in the attackers’ mindset. Automation, commercialization and cloud computing have also left their mark on the typical profile of cyber criminals that admins and vulnerability management have to deal with. Contrary to common Hollywood clichés, the threat of Ransomware as a Service is usually not (anymore) posed by highly talented script kiddies with a lot of time on their hands or anarchistic world improvers in hoodies. Nor from highly qualified intelligence agencies equipped with seemingly endless resources.

Attacks Are Commissioned Work Today

Today’s most dangerous attacks are increasingly working “on contract,” pursuing a business model, and must also be guided by values such as efficiency or probability of success. Just as cloud computing has become an integral part of most companies’ IT, it now also serves cyber criminals to automate, organize and accelerate attacks. With great success: Ransomware has grown to become the biggest threat, and with Ransomware as a Service, attacks can be booked quite easily.

More and more security professionals are just now developing an understanding of the attackers’ business models: their logic is hardly any different from that of other companies. They invest the same resources in developing exploits and tools and want to achieve the highest possible return on investment (ROI). That is why they often pay close attention to the reusability of their tools.

Faced with limited resources, cyber criminals develop exploits for widely used technologies that offer high profit potential for multiple targets.

The Perspective of Cyber Criminals

The attackers have organized themselves, orders are placed on the darknet, and payment is made via Bitcoin. They are profit-maximized, efficiency-oriented and professionally structured: However, the new, economy-oriented logic can and must also be a key to better defense mechanisms. Especially when security managers see themselves buried under an avalanche of security warnings, it is helpful to understand how cyber criminals “tick”.

In order to secure their own systems, defense must now rethink and think outside the box. Understanding the logic of cyber criminals helps decipher key signals and close gaps. David Wolpoff, CTO of Randori, has formulated six key questions in a blog post on Threatpost that describe the mindset of modern cyber criminals well:

  1. What useful information about a target can be identified from the outside?
  2. How valuable is the target to the attackers?
  3. Is the target known to be easy to hack?
  4. What is the potential of the target and environment?
  5. How long will it take to develop an exploit?
  6. Is there a repeatable ROI for an exploit?

The more knowledge cyber criminals can gather about a technology or a person in a company, the better they can plan the next attack phase. In the first step, they thus ask how detailed the target can be described from the outside. For example, depending on the configuration, a web server may not reveal a server identifier or server names and detailed version numbers. If the exact version of a used service and its configuration is visible, precise exploits and attacks can be executed. This maximizes the chances of success while minimizing the probability of detection and the effort required.

No Longer Random

The increasingly important economic interest ensures that cyber criminals have to consider factors such as effort, time, money and risk more strongly. Accordingly, it is not worthwhile to attack or spy on systems indiscriminately. These days, attackers first clarify the potential value before acting and focus on promising targets such as VPNs and firewalls, credential stores, authentication systems or remote support solutions at the network edge. These could turn out to be master keys and unlock the way into the network or to credentials.

Again and again, reports of critical and incendiary vulnerabilities emerge that apparently no one had exploited for attacks. It sounds unbelievable, but often no one has done the work to program an exploit for a vulnerability. Modern cyber criminals increasingly follow the principle of return on investment and make use of existing proof of concepts (POC).

Complexity Is Unwanted

This sometimes yields surprising findings: modern cyber criminals avoid well-documented vulnerabilities. Extensive research and analysis of a particular vulnerability is more an indicator of unwanted complexity and effort, which one wants to keep to a minimum. RaaS hackers search for available tools or buy exploits already created for a particular object. Attackers want to move unnoticed in the systems they compromise. So they pick targets with few defenses where malware and pivoting tools work, such as desktop phones and VPN apps and other unprotected hardware. Many apps there are built with or for Linux, have a full scope of use, and have trusted pre-installed tools. This promises to keep them usable after an exploit and makes them all the more attractive to cyber criminals.

Surprising Cost-Benefit Calculation

Once the target has been set, attackers need to assess time, cost, and reusability. Vulnerability research also goes beyond simply uncovering unpatched devices. Cyber criminals must assess whether the cost of researching and developing the resulting tools is commensurate with the gain after an attack. Well-documented software or open-source tools that are easy to obtain and test mean a relatively easy target.

Also surprising: overall, the severity of a vulnerability does not play the central role for cyber criminals, according to Wolpoff. Planning an attack is far more complex and requires economic thinking. Recognizing that the other side must also make compromises helps defend cloud environments in a meaningful way. Protecting everything, everywhere, all the time from all attackers is illusory. Thinking more like them, however, makes prioritization easier.

In the third part of this series of articles, it’s all about whether the Ransomware-as-a-Service model would be possible without Bitcoin and darknet, and whether the two technologies actually deliver what the attackers promise in that context.

This article is the first of three blogposts about the changing threat landscape in professional environments. “Ransomware as a Service” as a business model has powerful implications for enterprises, which are by no means defenseless. Modern vulnerability management, which Greenbone’s products enable, also plays an important role in this context.

Numbers 2020 – Increase, Revenue, Costs

They are called DarkSide, REvil, Dharma, Egregor, Maze, LockBit or Thanos. Even Emotet is currently celebrating an unpleasant comeback: ransomware attacks are increasing worldwide, seemingly unchecked. Their intensity is also growing massively: REvil and DarkSide paralyzed the Bank of Scotland and an important pipeline on the US East Coast. In Germany, government agencies, hospitals, and entire counties are suffering from ransomware attacks.

Ransomware is malware that encrypts a system and only enables access to the data again if the victim pays a ransom. Common distribution channels for ransomware are spam mails, phishing and drive-by exploits. The latter take advantage of vulnerabilities in browsers, browser plug-ins, operating systems and network services.

Almost all successful attacks on IT infrastructures in recent years can be traced back to this type, which works so differently from the cyber criminals of previous decades. The threat scenario has changed, ransomware is now created and operated by professional infrastructures, they operate for profit and at least as efficiently as the companies and organizations they target. Faced with the new threat, the latter need to rethink when it comes to protecting their infrastructures.

According to manufacturers, one important reason for the great success of ransomware is the increasing spread of cloud infrastructures. On the one hand, attackers use cloud services themselves; on the other hand, they benefit from the larger attack surface that companies offer, even more so in the age of home office. Another reason is a lack of updates or incorrect configurations in corporate IT. Both causes increase the probability of success for attackers. However, resources are very unevenly distributed: in recent years, a global and highly professional industry has established itself that offers cloud services for cyber criminals – “Ransomware as a Service” (RaaS).

From “Software as a Service” to “Ransomware as a Service”

The concept of “Software as a Service” (SaaS), i.e., IT services from the cloud without purchasing software and charging for them only according to use, has proven itself for several decades. Well-known SaaS providers include Slack, Salesforce and WordPress. Major software companies such as Microsoft with Microsoft 365 and Adobe with Adobe Creative Cloud now also offer SaaS versions of their products. Greenbone’s cloud service also works according to this model. The advantages of the service lie in its scalability, flexibility, high IT security, and the strict rules of European data protection, especially if hosting takes place in German data centers, as is also the case with the Greenbone Cloud Service.

By 2020 at the latest, the trend also reached the darknet and the ransomware hacker market. With the SaaS business model in the background, attackers infiltrate local networks, encrypt data and demand a ransom from the victim. RaaS is now using the SaaS model to deliver malware and extort money more efficiently and cost-effectively.

Over 60 % of all known ransomware attacks in 2020 have already been attributed to RaaS models, a highly competitive but growing market. 15 new RaaS providers are reported to have joined in 2020. The business model is clear: the customers, i.e. potential hackers or attackers, no longer need any technical skills, there are discount promotions and professional services. All of this makes RaaS increasingly attractive to cyber criminals and obviously works because countless inadequately protected infrastructures are open to them.

The number of total ransomware attacks increased by nearly 500 percent in 2020. Two-thirds of these are attributable to RaaS offerings, with the trend continuing to rise in 2021 [1]. Attackers made an estimated $ 20 billion in revenue from ransomware in 2020, up from just over $ 11 billion in 2019 [2]. RaaS offerings are available to hackers starting at $ 40/month. Those who want more service can also invest thousands of dollars [3].

The average cost for affected companies to clean up after a ransomware attack has doubled during 2020 and is typically ten times the ransom demanded. These in turn averaged between $ 200,000 and $ 300,000 in 2020 [4]. Whether a corporation or a small business, the demands are usually the same, because not every attack has to be successful. As with spam, mass is decisive.

“Ransomware as a Service” as a Business Model

The business model of “Ransomware as a Service” is comprehensively and clearly explained by websites like AppKnox: RaaS organizations rent software and IT infrastructures operated by and at an external IT service company. Cyber criminals lease them as a service to attack and extort businesses or individuals. RaaS developers and providers are legally on the safe side, as they “only” provide the infrastructure and are thus not responsible for the attack. Today, anyone can book and launch RaaS attacks and cause considerable damage to companies, authorities or private individuals.

There are four common RaaS business models behind this:

  • Monthly payment (subscription model)
  • Partner programs, in addition to the subscription model there are profit-sharing schemes
  • One-time license fee
  • Profit sharing only

No matter which model users choose, some RaaS companies make it very easy: go to the darknet, log in, create an account, choose a model, pay with Bitcoin if necessary, distribute malware and wait for success.

For the money invested, you get an enterprise-level service. A typical product not only includes the ransomware code and the keys to encrypt and decrypt it, but also provides the appropriate phishing e-mails to launch an attack, good documentation and 24/7 support. Billing, monitoring, updates and status reports, calculation and forecasts regarding an income-expense statement are also taken care of.

Potential Victims Are by no Means Helpless

Despite the professionalism, companies and authorities do not have to stand idly by. Although they now face other attackers, they are by no means powerless or helpless.

The FBI regularly warns against accepting demands from extortionists, especially not in the case of organized crime and certainly not in the case of ransomware. The only solution is an expensive, lengthy rebuild or an attempt to crack the encryption. Instead, it is better to be prepared.

Companies can protect themselves with a few simple measures and consistent adherence to best practices. Backups, in different locations and separate from day-to-day operations, protect data. Two-factor authentication hampers attackers who could get passwords. Strong passwords should be standard practice today, as should smart network segmentation. Planning, incident response and recovery plans must be in place and tested regularly. Automation, monitoring and regular training of employees regarding IT security (e.g. phishing emails) are a must. Automation is of particular importance within IT, because attacks sometimes occur so quickly that human reactions come to nothing.

The basis for all these measures is provided by endpoint protection solutions and professional vulnerability management. Knowledge of vulnerabilities and weaknesses in networks is worth a fortune here. Admins identify the gaps in your IT defenses and close them before cyber criminals can abuse them – with Greenbone solutions continuously and automatically.

Greenbone products continuously scan the corporate network or external IT resources for potential vulnerabilities. The specially hardened Greenbone Enterprise Appliances or the Greenbone Cloud Service, available as Software as a Service and hosted in German data centers, guarantee daily updates on the latest vulnerabilities. Admins and IT management are informed immediately, if necessary, when threatening security vulnerabilities are revealed. In this way, companies are also well prepared if “Ransomware as a Service” as a business model continues to grow.

[1] https://www.unityit.com/ransomware-as-a-service/

[2] https://www.pcspezialist.de/blog/2021/06/14/raas-ransomware-as-a-service/

[3] https://www.crowdstrike.com/cybersecurity-101/ransomware/ransomware-as-a-service-raas/

[4] https://www.appknox.com/blog/ransomware-as-a-service
The second part of our series on the ongoing professionalization of attacks on IT systems deals with changes in the attackers’ mindset. Automation, commercialization and cloud computing have also left their mark on the typical profile of cyber criminals that admins and vulnerability management have to deal with. Contrary to common Hollywood clichés, the threat of Ransomware as a Service is usually not (anymore) posed by highly talented script kiddies with a lot of time on their hands or anarchistic world improvers in hoodies. Nor from highly qualified intelligence agencies equipped with seemingly endless resources.

Attacks Are Commissioned Work Today

Today’s most dangerous attacks are increasingly working “on contract,” pursuing a business model, and must also be guided by values such as efficiency or probability of success. Just as cloud computing has become an integral part of most companies’ IT, it now also serves cyber criminals to automate, organize and accelerate attacks. With great success: Ransomware has grown to become the biggest threat, and with Ransomware as a Service, attacks can be booked quite easily.

More and more security professionals are just now developing an understanding of the attackers’ business models: their logic is hardly any different from that of other companies. They invest the same resources in developing exploits and tools and want to achieve the highest possible return on investment (ROI). That is why they often pay close attention to the reusability of their tools.

Faced with limited resources, cyber criminals develop exploits for widely used technologies that offer high profit potential for multiple targets.

The Perspective of Cyber Criminals

The attackers have organized themselves, orders are placed on the darknet, and payment is made via Bitcoin. They are profit-maximized, efficiency-oriented and professionally structured: However, the new, economy-oriented logic can and must also be a key to better defense mechanisms. Especially when security managers see themselves buried under an avalanche of security warnings, it is helpful to understand how cyber criminals “tick”.

In order to secure their own systems, defense must now rethink and think outside the box. Understanding the logic of cyber criminals helps decipher key signals and close gaps. David Wolpoff, CTO of Randori, has formulated six key questions in a blog post on Threatpost that describe the mindset of modern cyber criminals well:

What useful information about a target can be identified from the outside?
How valuable is the target to the attackers?
Is the target known to be easy to hack?
What is the potential of the target and environment?
How long will it take to develop an exploit?
Is there a repeatable ROI for an exploit?

The more knowledge cyber criminals can gather about a technology or a person in a company, the better they can plan the next attack phase. In the first step, they thus ask how detailed the target can be described from the outside. For example, depending on the configuration, a web server may not reveal a server identifier or server names and detailed version numbers. If the exact version of a used service and its configuration is visible, precise exploits and attacks can be executed. This maximizes the chances of success while minimizing the probability of detection and the effort required.

No Longer Random

The increasingly important economic interest ensures that cyber criminals have to consider factors such as effort, time, money and risk more strongly. Accordingly, it is not worthwhile to attack or spy on systems indiscriminately. These days, attackers first clarify the potential value before acting and focus on promising targets such as VPNs and firewalls, credential stores, authentication systems or remote support solutions at the network edge. These could turn out to be master keys and unlock the way into the network or to credentials.

Again and again, reports of critical and incendiary vulnerabilities emerge that apparently no one had exploited for attacks. It sounds unbelievable, but often no one has done the work to program an exploit for a vulnerability. Modern cyber criminals increasingly follow the principle of return on investment and make use of existing proof of concepts (POC).

Complexity Is Unwanted

This sometimes yields surprising findings: modern cyber criminals avoid well-documented vulnerabilities. Extensive research and analysis of a particular vulnerability is more an indicator of unwanted complexity and effort, which one wants to keep to a minimum. RaaS hackers search for available tools or buy exploits already created for a particular object. Attackers want to move unnoticed in the systems they compromise. So they pick targets with few defenses where malware and pivoting tools work, such as desktop phones and VPN apps and other unprotected hardware. Many apps there are built with or for Linux, have a full scope of use, and have trusted pre-installed tools. This promises to keep them usable after an exploit and makes them all the more attractive to cyber criminals.

Surprising Cost-Benefit Calculation

Once the target has been set, attackers need to assess time, cost, and reusability. Vulnerability research also goes beyond simply uncovering unpatched devices. Cyber criminals must assess whether the cost of researching and developing the resulting tools is commensurate with the gain after an attack. Well-documented software or open-source tools that are easy to obtain and test mean a relatively easy target.

Also surprising: overall, the severity of a vulnerability does not play the central role for cyber criminals, according to Wolpoff. Planning an attack is far more complex and requires economic thinking. Recognizing that the other side must also make compromises helps defend cloud environments in a meaningful way. Protecting everything, everywhere, all the time from all attackers is illusory. Thinking more like them, however, makes prioritization easier.

In the third part of this series of articles, it’s all about whether the Ransomware-as-a-Service model would be possible without Bitcoin and darknet, and whether the two technologies actually deliver what the attackers promise in that context.

The employees of Greenbone are currently developing a completely new scanner for version comparisons. The new vulnerability scanner “Notus” should significantly accelerate the comparison of software versions, CVEs and patches in the future.

Scanner architecture of the new vulnerability scanner

A large part of modern vulnerability management consists of comparing software versions. If you want to find out whether your server is immune to a vulnerability, you need to know which version of a particular software is running on that machine. For example, version 1 may be affected by a vulnerability that is already fixed in version 2. Whether vulnerability scanners like the new vulnerability scanner “Notus” issue a warning depends, among other things, heavily on the result of these comparisons.

Björn Ricks, Unit Lead Services & Platforms at Greenbone explains, “Such tasks alone accounted for more than a third of a scanner’s work, and the scanner we have optimized specifically for version comparisons is designed to speed this up significantly.”

Performance Shortcomings of Classic Scanners

At the beginning of the work of a classic scanner is an advisory with a gap found by experts. Greenbone employees then search for matching (affected) software versions and those that have already corrected the error. This information must now be made available to the scanner.

“It then rattles off the relevant servers and records software running there. For the actual scan, it essentially only gets the info about affected and fixed packages,” Ricks explains. “With the OpenVAS scanner and its predecessors, we usually had to start a separate process per version check, meaning a separate manually created script. Generating these scripts automatically is costly.”

JSON Data Helps Speed up the Scanner

The new scanner, on the other hand, only loads the data it needs from files in JSON format, an easy-to-read plain-text standard. “This means the logic for the tests is no longer in the scripts. This has many advantages: fewer processes, less overhead, less memory required.” Ricks believes the approach is “significantly more efficient.”

Elmar Geese, COO of Greenbone Networks explains, “Our new Notus scanner will be a milestone for our users, it will significantly improve performance. Our well-known high detection quality as well as performance are key goals of our product strategy, and the new scanner supports this in an optimal way.”

The “Notus” project consists of two parts: a “Notus” generator, which creates the JSON files containing information about vulnerable RPM/Debian packages, and the “Notus” scanner, which loads these JSON files and interprets the information from them. Greenbone plans to complete the new vulnerability scanner “Notus” in the next few months.

About Greenbone and OpenVAS

When the development team of the vulnerability scanner Nessus decided to stop working under open source licenses and switch to a proprietary business model in 2005, several forks of Nessus were created. Only one of them is still active: the Open Vulnerability Assessment System (OpenVAS).

The founding of Greenbone in 2008 aimed to drive the development of OpenVAS and provide users with professional vulnerability scanning support. Greenbone started to lead the further development of OpenVAS, added several software components and thus transformed OpenVAS into a comprehensive vulnerability management solution that still carries the values of free software. The first appliances hit the market in spring 2010.

With the help of Greenbone products, known vulnerabilities in an IT infrastructure can be detected and subsequently eliminated. Assessing the severity of a vulnerability is an essential tool for planning and prioritizing subsequent remediation actions. CVSS provides such an assessment according to a metrics system. Since 2021, Greenbone’s current solutions also support CVSS versions 3.0 and 3.1, and at the same time, Greenbone started to provide all vulnerability tests for which a respective rating is available with it. As of October 2021, this work is now complete and there is – as far as possible – full CVSSv3x coverage in the Greenbone feeds.

Helpful Severity Metrics

Every cyber attack needs a vulnerability to be successful. Most vulnerabilities, namely 999 out of 1,000, have already been known for more than a year and can therefore be proactively detected and eliminated. For detection, a Greenbone vulnerability scanner is used, which finds the known vulnerabilities in an IT infrastructure.

If vulnerabilities are discovered, they can subsequently be eliminated using a wide variety of measures. The most urgent vulnerabilities to be eliminated are those that pose a critical risk to the IT system. Prioritization is required for selecting the measures and the order.

The severity is an essential tool for prioritization. However, we will take a closer look at how vulnerabilities are assigned a severity level in the first place and how it is calculated.

How Severity Ratings Are Created

In the past, different organizations and security research teams discovered and reported vulnerabilities at the same time and named them with different names. This resulted in the same vulnerability being reported by, for example, multiple scanners under different names, making communication and comparison of results difficult.

To address this, MITRE founded the Common Vulnerabilities and Exposures (CVE) project. Each vulnerability was given a unique identifier as a central reference, consisting of the year of publication and a simple number. The CVE database is used to link vulnerability databases with other systems and to allow comparison of security tools and services.

CVEs thus do not contain any detailed, technical information or information regarding the risks, effects or elimination of a vulnerability. In some cases, the version in which the vulnerability was removed is stored.

Further information about a vulnerability can be found in the National Vulnerability Database (NVD). The NVD – a U.S. government vulnerability management data repository – supplements CVEs with information regarding remediation, potential impact, affected products, and also the severity of a vulnerability.

How is the Severity of a Vulnerability Calculated?

The Common Vulnerability Scoring System (CVSS) was developed to enable the assessment of vulnerabilities. CVSS is an industry standard for describing the severity of security risks in IT systems. It was developed by the CVSS Special Interest Group (CVSS-SIG) of the Forum of Incident Response and Security Teams (FIRST). The latest CVSS version is 3.1.

The CVSS score evaluates vulnerabilities according to various criteria, so-called “metrics”: base-score metrics, temporal-score metrics and environmental-score metrics.

  • Base-score metrics: base-score metrics represent the basic characteristics of a vulnerability that are independent of time and the IT environment: how well can the vulnerability be exploited and what is the impact?
  • Temporal-score metrics: temporal-score metrics represent characteristics that can change over time but are the same in different IT environments. For example, the deployment of a patch by the deploying organization would lower the score.
  • Environmental-score metrics: environmental-score metrics represent the characteristics that apply to a specific IT environment. Relevant here are how well the affected organization can intercept successful attacks or what status a particular vulnerable system has within the IT infrastructure.

Since, in general, only the base score metrics are meaningful and can be determined permanently, only these are usually published and used.

CVSSv3.0/v3.1 Support Since GOS 21.04

Since GOS 21.04, which was released in April 2021, versions 3.0 and 3.1 of CVSS are also supported. Although some CVEs – and thus also the associated vulnerability tests – still contain version 2 CVSS data, this mainly affects older CVEs from the year 2015 and earlier, for which no CVSSv3.0/v3.1 score is yet stored in the NVD.

Let’s look at the biggest changes that versions 3.0 and 3.1 include.

Compared to CVSS version 2.0, version 3.0 retains the main groups of metrics – base, temporal, and environmental – but adds new criteria. For example, the metrics “Scope (S)”, which indicates whether a vulnerability can also affect other components of an IT network, and “User Interaction (UI)”.

Some existing criteria have also been replaced by newer ones: “Authentication (Au)” has become “Privileges Required (PR)”. It is no longer measured how often attackers have to authenticate themselves to a system, but what level of access is required for a successful attack.

In addition, the severity levels were subdivided more finely. In version 2.0, the values from 0 to 10 were divided into three severity levels: “Low” (0.0 – 3.9), “Medium” (4.9 – 6.9) and “High” (7.0 – 10.0). Since version 3.0, there are five levels: “None” (0.0), “Low” (0.1 – 3.9), “Medium” (4.0 – 6.9), “High” (7.0 – 8.9) and “Critical” (9.0 – 10.0).

CVSS version 3.1 did not bring any changes to the metrics or the calculation formulas. Instead, the focus was on emphasizing that CVSS measures the severity of a vulnerability rather than the risk it poses. A common mistake was to view the CVSS score as the sole characteristic of a vulnerability’s risk, rather than performing a fully comprehensive risk assessment.

In the course of this, the definitions of the metrics were formulated more clearly and the glossary was expanded.

Full CVSSv3.0/v3.1 Coverage in the Feed

With CVSSv3.0/v3.1 support in April 2021, Greenbone began updating all vulnerability tests assigned a CVSSv3.0/v3.1 score in the NVD to include a CVSSv3.0/v3.1 score.

This was done in daily stages of 500 – 600 vulnerability tests. The update and conversion were thoroughly reviewed and tested. Since October 2021, this work has now been completed. Thus, there is – as far as possible – full CVSSv3x coverage in the Greenbone feeds.

The goal of vulnerability management is to detect all security gaps in an IT network before an attacker does so. The Greenbone Security Feed (GSF) provides the vulnerability tests (VTs) that the scanner of the Greenbone solutions performs for this purpose. As a component of the Greenbone Security Manager (GSM) and the Greenbone Cloud Services (GCS), it is updated daily and provides protection against major and well-known vulnerabilities such as SUPERNOVA, BlueKeep and PrintNightmare.
We are happy to announce that the success story is growing steadily and that since this month our Greenbone Security Feed contains more than 100,000 vulnerability tests!

Let’s take a look at the history of the feed.

In 2005, the development of the Nessus vulnerability scanner decided to stop working under open source licenses and switch to a proprietary business model. By that time, members from Intevation and DN-Systems – the two companies that would later found Greenbone Networks – were already contributing developments to Nessus. In 2006, several forks of Nessus were created in response to the discontinuation of the open source solution. Of these forks, only one remains active: OpenVAS, the Open Vulnerability Assessment System.

In late 2008, Greenbone was formed to push OpenVAS. In the same year, two other companies became active: Secpod from India and Security Space from Canada. Both focused on providing vulnerability testing and partnered with Greenbone to create a reliable and up-to-date feed of vulnerability tests.

This started with the removal of source code and vulnerability tests where the license was unclear or incompatible. Several thousand vulnerability tests were eliminated to get a clean baseline with just under 3000 vulnerability tests at the time.

Shortly after, the content of the feed grew rapidly and steadily to over 10,000 vulnerability tests. 50,000 tests were then contained in the feed after about 8 years of development in 2016. The next 50,000 followed after only 5 more years and represent the current state with more than 100,000 vulnerability tests.

Number of vulnerability tests over time up to more than 100,000 vulnerability tests

Number of VTs over time

How Is the Feed Composed Anyway?

It is also interesting to see how these 100,000 vulnerability tests in the feed are put together. In our SecInfo Portal, you can easily take a look at all the included tests yourself.

About half of the tests detect vulnerabilities with a high severity class – i.e., with a severity between 7.0 and 10.0. Another 40,000 tests such with the severity class “Medium” (severity 4.0 to 6.9).

Distribution of the more than 100,000 vulnerability tests among the severity classes

Distribution of VTs by severity class

Vulnerabilities for the same area are grouped into families. Among the largest families of vulnerability tests are mainly those for local security checks, i.e., authenticated scans. In these, the target is scanned both from the outside via the network and from the inside using a valid usage login. Thus, more details about vulnerabilities can be found on the scanned system. Vulnerability tests for such authenticated scans already account for over 60,000 tests. The largest VT families with a total of almost 30,000 vulnerability tests are “Fedora Local Security Checks” and “SuSE Local Security Checks”.

Number of vulnerability tests of the top 10 families of vulnerability tests

Number of VTs in the top 10 VT Families

Globally Known Vulnerabilities Are also Covered

The general public is unaware of many vulnerabilities. But every now and then, particularly significant and spectacular cyber attacks make it into the media – especially when many large companies or governments are affected.

Greenbone reacts immediately when such incidents become known and starts developing a corresponding vulnerability test. Such notable vulnerabilities in recent years include Heartbleed (2014), POODLE (2014), DROWN (2016), Meltdown (2018), Spectre (2018), BlueKeep (2019) and PrintNightmare (2021). Most people probably also particularly remember the Solarwinds attack in 2019 and 2020. The attackers had exploited a previously unknown vulnerability to inject the malicious webshell “SUPERNOVA”.
All of these vulnerabilities can be detected via tests in the Greenbone Security Feed.

In the future, we will continue to work on expanding the scope of our feed to provide users with the opportunity to detect vulnerabilities at an early stage and not give attacks a chance. So with our solutions constantly updated to cover the latest and most critical vulnerabilities, you can relax. The next 100,000 vulnerability tests will follow – stay tuned!

Since 2021-04-30, the latest GOS version – version 21.04 – is available and, as always, it brings a lot of new features and improvements! What exactly? Get an overview of all important changes with GOS 21.04 here!

New Hardware Models for Our Midrange Class Available

A new hardware generation has been introduced for the Midrange Class hardware appliances, which are used for medium-sized companies or for branch offices of large, distributed companies.

The new hardware now uses SSD-type hard disks instead of HDD, which are 10 times faster, quieter and lighter. There is also more hard disk space available. The RAM has also been improved. It is now DDR4 instead of DDR3, which makes it significantly faster with a higher clock rate (3200 MHz). Furthermore, twice to four times as much main memory is available than before. In addition, a new, faster CPU of the latest generation has been installed. The ports of the appliances also change: instead of 6 ports GbE-Base-TX and 2 ports 1 GbE SFP, there are now 8 ports GbE-Base-TX and 2 ports 10 GbE SFP+.

The model names remain unchanged.

Boreas Alive Scanner now as Standard

The Boreas Alive Scanner is a host alive scanner that identifies the active hosts in a target network. It was introduced with GOS 20.08, but was previously optional. With GOS 21.04, the Boreas Alive Scanner became standard.

Compared to the Nmap port scanner, which was previously used by default, the Boreas Alive Scanner is not limited in terms of the maximum number of alive scans performed simultaneously and is therefore faster.

The Boreas Alive Scanner significantly reduces scanning time for large networks with a small percentage of reachable hosts. This also makes it possible to get the first scan results faster, regardless of the percentage of alive hosts in the network.

Clearer Results Thanks to New Report Formats

Two additional report formats are now available for exporting reports, replacing the previous standard report formats: Vulnerability Report PDF and Vulnerability Report HTML. The report formats are clearly structured and easy to understand. Specific information relevant to the target group can be quickly identified and understood.

The report formats provide a basis for user-defined reports, which are planned for future GOS versions.

 

New Network Backend for a more Stable Connection

With GOS 21.04, the network configuration backend in GOS has been improved by introducing the gnm networking mode. This prevents connection losses in certain network configurations as well as connection problems with SSH sessions. In addition, the GSM no longer needs to be restarted after certain network settings have been changed.

New Hypervisors for Our Virtual Appliances

The officially supported hypervisors for the virtual appliances have been changed with GOS 21.04. The GSM EXA/PETA/TERA/DECA and 25V can be used with Microsoft Hyper-V, VMware vSphere Hypervisor (ESXi), and Huawei FusionCompute; the GSM CENO can be used with Microsoft Hyper-V and VMware vSphere Hypervisor (ESXi); and the GSM ONE can be used with Oracle VirtualBox, VMware Workstation Pro, and VMware Workstation Player. Additionally, GOS 21.04 supports the ARM instruction set on Huawei FusionCompute.

Improvement of the Web Server, Ciphers and Web Certificates

With GOS 21.04, the nginx web server is used in addition to the Greenbone Security Assistant Daemon (gsad). This web server uses OpenSSL instead of GnuTLS to define the available ciphers and protocols of the server. There is now a new menu in the GOS administration menu for configuring the TLS version. In addition, the menu for configuring the ciphers has been adapted.

Another change can be found in the generation of HTTPS certificates. Here it is now possible to define one or more Subject Alternative Name(s) (SAN). These are used to cover multiple domain names and IP addresses with one certificate.

CVSS v3.0/v3.1 Support for Severity Calculation

CVSS version 3.0 and 3.1 are now supported for calculating the severity of CVEs (Common Vulnerability Enumeration).

VTs and CVEs can contain version 2 and/or version 3.0/3.1 CVSS data. If a VT/CVE contains both CVSS v2 data and CVSS v3.0/v3.1 data, the CVSS v3.0/v3.1 data is always used and displayed.

The page CVSS Calculator now contains both a calculator for CVSS v2 and a calculator for CVSS v3.0/v3.1.

Open Scanner Protocol Makes all Sensor GSMs Lightweighted

Already with GOS 20.08 it was optionally possible for all sensors to be controlled via the Open Scanner Protocol (OSP). This results in the sensors becoming lightweighted and avoids the need for additional credentials on the sensor.

With GOS 21.04, only OSP is now used as the protocol to control a sensor GSM via a master GSM. The Greenbone Management Protocol (GMP) is no longer used.

Simplified and More Intuitive Functions on the Web Interface

With GOS 21.04, some minor changes have also been made to GOS and the web interface to make GSM operation and scanning clearer and more intuitive.

For example, the Auto-FP function and the alternative severity class schemes – BSI Vulnerability Traffic Light and PCI-DSS – have been removed.

Some devices – especially IoT devices – can crash when scanned across multiple IP addresses simultaneously. This can happen, for example, if the device is connected over IPv4 and IPv6. With GOS 21.04, it is possible to avoid scanning over multiple IP addresses at the same time by using the new setting Allow simultaneous scanning via multiple IPs when creating a target.

See for Yourself!

Check out our new features and changes for yourself! New appliances with GOS 21.04 are now available and existing appliances can also be upgraded to the latest version. Also our free trial version can be used with GOS 21.04.