How Attackers Become Domain Administrators in Active Directory—and How to Prevent It. An Overview of Attack Vectors, BSI-Compliant Hardening, and the AD Penetration Test.
Continue reading
Find out which penetration test is right for your company: ISO 27001, TISAX, web applications, APIs, AI services, or assume-breach scenarios. A clear explanation of black-box, gray-box, and white-box penetration tests, along with tips for choosing a professional penetration testing provider with transparent pricing.
Continue reading
COM hijacking is often used after a system has been successfully compromised and provides attackers with an effective way to maintain persistent access. This technique can execute malicious code undetected and thus poses a significant risk to system security. In this article, we explain how COM hijacking works, the risks it poses, and the measures that can help detect and prevent such attacks.
Continue reading
Technical vulnerabilities are often the focus of IT security—but the biggest point of vulnerability remains the human factor. Two recent methods show just how easy it is to bypass security measures:
✅ ClickFix: Deceptively realistic CAPTCHA pages trick users into executing harmless keyboard shortcuts. In reality, these shortcuts launch PowerShell commands—without warning and without an admin prompt.
✅ FileFix: Even more insidious—a supposed file path is inserted into the Windows Explorer address bar, but it is actually a system command.
Both techniques rely on trust, routine, and UI tricks—not technical exploits. Traditional antivirus solutions rarely detect them.
Protection? A combination of monitoring, restrictive policies, and, above all, awareness. Users need to be aware of these deceptions before they click.
The article explores how an SQL injection security analysis led to a more in-depth examination of URL normalization and the Apache mod_rewrite module. It explains how mod_rewrite can redirect different URL formats to uniform paths—a process that, however, poses security risks if not implemented correctly. Particular attention is given to the risk that inadequate normalization can create attack vectors, such as through double slashes or alternative encodings. The article offers technical insights and presents solutions for the secure configuration of rewrite rules.
Continue reading
Especially for companies that operate larger infrastructures, a pentest can often provide more insights than is typically assumed. We show you how to interpret pentest results correctly and get the maximum benefit from them.
One of the main reasons is a wrong perspective on the results of a test. Typical assumptions are:
A first important realization is that penetration tests can never detect all vulnerabilities on a target system. This is for the following reasons: Firstly, the test is limited in time, and secondly, not all configuration parameters are known about the system for most tests.
Conclusion: A pentest alone cannot be used to make a target application more secure. A pentest report without critical findings does not mean that the application can contain absolutely no vulnerabilities.
Consequence: Use the full range of testing options for application audits: Code reviews, peer reviews, Secure Software Development training. The earlier vulnerabilities are discovered, the higher the profit. Early code reviews focusing on weaknesses, code complexity and “bad smells” can uncover errors in the design, data model or programmer understanding. A pentest usually only takes place at a release status of the application where major changes are no longer possible.
If vulnerabilities are identified in a pentest, it should always be evaluated whether these errors may also be present in other application components. Particularly in the case of input validation vulnerabilities, it is often not possible to identify all vulnerable parameters in a test. It should also be analyzed whether the faulty design may have been used in other applications.
A pentest is always just a snapshot of currently known vulnerabilities and the target system in its configuration and version at the time of the test. Just because a current report shows “low” as the overall risk does not mean that a new vulnerability will not be published in the future that compromises the entire system.
Pentests should therefore not be seen as a one-off measure, but rather as a method for regularly checking an application or IT system for known vulnerabilities.
We often see that pentest results are processed further without a more detailed discussion of the risk. The risk assessment of the pentesters is seen as “set in stone”. Here we would like to point out that a discussion of the identified vulnerabilities with your IT security team can lead to a meaningful weighting or prioritization of the results. Depending on the threat model you have developed (e.g. in a risk/impact analysis as part of ISO 27001 certification), there may be vulnerabilities whose elimination should be prioritized differently than the external assessment of the pentest report.
As Pentest Factory, we are happy to support this discussion (e.g. in a joint meeting) in order to create an overall picture of the target system and risk in its environment.
Another aspect is the risk assessment system itself. When using the standard CVSS system (without environment metrics), the overall risk is calculated from a formula that leaves us as testers little room for context-dependent upgrading or downgrading of risks. For example, you can only choose between “High Attack Complexity” and “Low Attack Complexity” for the “Attack Complexity” metric. Accordingly, attacks of medium complexity cannot be mapped here. This is similar for the other metrics in the CVSS system. This means, for example, that we may classify a finding with medium criticality as “high risk” because the CVSS formula calculates this.
In general, it makes sense to discuss the individual results and assigned risks in the team.
The result of a pentest is a final report. This lists identified weaknesses and provides specific recommendations for remedying the findings.
At first glance, it appears that the main task after the test is completed is to eliminate these weaknesses.
However, as a pentest service provider, we often see that remedying vulnerabilities is the only activity resulting from a test result. For this reason, it is all the more important to understand that the real value of the pentest lies in the identification of faulty processes. It is worth asking about every weak point “Why did this vulnerability occur? How can we correct the process behind it?“
This is the only way to ensure that, for example, a missing patch management process or inadequate asset management is corrected and that software deployments are not running again with missing updates after a month.
Since we very often see that a root cause analysis is omitted after the pentest has been completed, we would like to show a second example in which an understanding of the process that went wrong can bring significant added value in terms of safety:
–> Monthly session on “Secrets in the source code”
–> Customization of the CI/CD pipeline to automatically stop sensitive commits
–> Pentest result can be transferred to similar systems and processes
–> Analysis of the entire repository for sensitive commits
Just because a “critical” vulnerability is identified does not mean that the development or the product is “bad”. Products that provide a particularly large number of functions have a particularly large number of potential attack surfaces. The best examples are well-known products such as browsers or operating systems that release monthly security patches.
As experts in the field of cybersecurity for many years, we see that the biggest problems arise from a defensive mindset and an inadequate response to risks. Specifically, the following fatal decisions are made:
–> Maximum transparency is the only correct response, especially after a vulnerability becomes known. What exactly is the weak point? Where does this occur? What is the worst-case scenario? Maximum transparency is the only way to determine the exact cause and ensure that all parties involved understand the risk sufficiently to initiate countermeasures.
The vulnerability should never be seen as the fault of an individual or the company, but as an opportunity to react. The response to a vulnerability (not the vulnerability itself) determines to a large extent what damage can actually be done.
–> These or other restrictions lead to an incorrect risk image of the target system. Instead of recognizing vulnerabilities as early as possible, the complexity and risk potential of the application grows step by step. If a vulnerability is detected late, it becomes more time-consuming and therefore more costly to close it.
As a pentest service provider, it is important to us that our customers get the maximum benefit from a pentest. For this reason, we often hold team discussions to identify trends and make the best possible recommendations. This article is the result of these discussions over the last few years and aims to open up new perspectives on the pentest results.
Do you have any questions or need support with pentesting, secure software development or improving internal processes? Please use the contact form, we will be happy to assist you.
Often, in discussions with new customers, we can see that the market of penetration testing services seems opaque and it is difficult to decide on a service provider. The focus is often on the price of a pentest and other decision criteria are omitted.
With this article, we want to provide you with a basic guide to qualitatively evaluate penetration testing service providers and simplify your decision-making process.
One issue that arises in pentesting is the issue of experience. Attacking computer systems requires creativity, flexibility, and an understanding of a breadth of technologies and platforms. While several years of experience as a developer or security officer can make it easier to get started, they are still no substitute for practical knowledge of how security mechanisms work and how they can be attacked.
For this reason, we recommend focusing on how many years a penetration tester has been performing tests and what practical qualifications they have. Below we have listed some commonly found qualifications and what knowledge is hereby effectively attested.
As can be seen from the descriptions, of the certifications listed here, only the OSCP demonstrates actual practical knowledge in compromising computer systems. We recommend that you hire testers who have a practical qualification similar to OSCP. To view successful qualification and validity, we recommend asking the service provider for proof (e.g., digital link to Credly, Credential.net, or a scanned copy of a tester’s acquired certificate).
As described before, the OSCP certification provides a good reference point to verify essential competencies of a penetration tester. OSCP certification demonstrates knowledge of enumerating and testing individual hosts and services.
However, since modern applications have grown extremely in complexity, we recommend asking the service provider what specializations the individual testers have and having these specializations proven (e.g., certifications, customer references, CVE records). Especially for complex test objects, the tester should be familiar with the technologies and have specialized in the corresponding area. This is especially true in areas such as web applications, API interfaces, Active Directory, mobile application testing, SAP testing and many more.
When you request a quote, the quote should be tailored to the application or infrastructure you are testing. To do this, the service provider should find out what the scope of the test object is and, on this basis, make an estimate of how many days of testing are required.
If the service provider does not ask for details about your test object and sends you a quote “blindly”, it may either be that too few days have been calculated in, which means that the application can be tested less deeply or even that certain components are omitted. Alternatively, it can equally happen that too many days are estimated for the test object and you simply have to pay for them, although the test could have been completed in advance.
Tip: If you approach several service providers at the same time (e.g. in a tender), you should describe the test object as precisely as possible (technologies used, typical application functions and processes, number of hosts). This information makes it easier to create an appropriate quote and reduces the likelihood of choosing the wrong test scope or methodology.
After a penetration test has been performed, the final report is the key document that records the results of the pentest. Therefore, pay particular attention to the quality of the final report and obtain a sample report in advance of the engagement.
Each finding should include a clear description, with screenshots, of how to identify and exploit the vulnerability so that you or your developers can understand the issue and recreate it if necessary. Also, each finding should include an explanation of what risk has been assigned to the vulnerability and what this assignment is based on (e.g., using risk assessment methods such as CVSS or OWASP).
The report should clearly list all the framework parameters of the test and explain typical W questions, such as:
– When was the test performed (period)?
– What was tested (test scope)?
– What, if anything, was not tested (scope)?
– How was it tested (methodology)?
– Who performed the test (contact person)?
– What risk assessment method was used?
– Which tools, scripts and programs were used?
Ask the service provider for a sample report and compare reports to choose the ideal report format for you. Also be sure to include a management summary that summarizes the test results in non-technical, management-level language. This is especially important because the details of findings are often very technical or complex and can only be understood by technical personnel.
Often the terms vulnerability scan and penetration test get mixed up. A vulnerability scan is an automated procedure by which a program independently or based on certain scan parameters tests the test object for vulnerabilities. No manual testing by a human is performed here.
Be careful when a vulnerability scan is advertised instead of a penetration test. Many vulnerabilities are contextual and can only be identified through manual testing. In addition, vulnerability scanners can return false positive results, which are not actual vulnerabilities.
To test efficiently, one or more automated scans can be part of a penetration test. However, you should ensure that the service provider has a focus on manual verification of results and manual testing of the test object. The automatically generated test results should not be included directly in the report, only after manual verification. Each finding should include a detailed account of how the vulnerability was verified.
Before a penetration test can be legally performed, it is mandatory to obtain the hoster’s permission. If you do not host your application or infrastructure yourself, be sure to ask the hoster for permission to test it. Exceptions to this are some cloud hosters that explicitly allow penetration testing (e.g. Microsoft Azure, Amazon AWS, Google Cloud). Make sure that all approvals have been given before starting the test. The penetration test service provider should raise this issue on its own and be sure to clarify it with you before testing begins.
In order to clearly assign which attacks are carried out by your service provider and which attacks represent a real threat, the service provider should carry out the tests from a fixed IP address. To do this, ask your service provider whether such a static IP address exists and find out in advance of the tests. You can also search your log files for the IP address during the test and get insight into what volume of requests the test generated. Be careful when choosing a service provider should they not use a unique IP address for their testing. In addition, always obtain the contact information of the person performing the technical tests. This way you have the possibility to contact a technical contact person directly in case of problems or technical questions and to get feedback immediately. Furthermore, this allows you to exclude the possibility that a subcontractor was commissioned to carry out the tests in a non-transparent or possibly unofficial manner.
A penetration test of a web application should follow the public standard test methodology “OWASP”. The OWASP consortium provides procedures for testing all current vulnerability categories. This should definitely be tested.
If you want to test an application that provides a user login and protected user areas, we recommend performing a “grey-box” test. Here, test accounts are provided to the service provider, allowing internal areas behind a login to be tested more efficiently and granularly. Pay attention to whether the service provider suggests this test methodology or, if necessary, actively ask for the test methodology.
If an API interface is to be tested, the service provider should request interface documentation or a collection of sample API requests (e.g. Swagger.json, Postman Collections). Without API documentation, testing APIs is not purposeful because endpoints and parameter names have to be guessed. This can result in important endpoints being overlooked and vulnerabilities not being detected.
An infrastructure test where multiple host systems are tested for their available services usually consists of several automated scans at the beginning of a test combined with manual test units and a subsequent verification of the scan results.
Active Directory environments are very dynamic and require specialized knowledge beyond a basic qualification such as OSCP. Make sure the tester of your AD environment has advanced training and certifications in Windows and Active Directory security. These may include, for example, the Certified Red Team Professional (CRTP) or Certified Red Team Expert (CRTE) hands-on certification. However, also many other trainings in the area of Azure AD and Windows environments.
Almost everyone is familiar with the issue of spam: you receive e-mails telling you about unbeatable discounts, millions in winnings for your wallet or a blocked bank account. Often these are already filtered by spam filters before delivery or are unmasked by the numerous spelling mistakes and a strange sender address.
However, during our daily work at Pentest Factory, we were able to uncover a much more effective method to trick us into clicking on a malicious link: After a quick call to our mobile device, we receive the following SMS:
We open the link in a locked down virtual machine:
After a simple 301 redirect we reach the following page:
However, there is nothing out of the ordinary to be found at first glance. Even after analyzing the source code of the page, there are no special peculiarities to be seen.
However, we remember that the SMS was sent to a mobile device. Maybe it is possible to trigger a different behavior with a mobile user agent. We change our user agent to an ordinary Android Firefox browser. And look! We are now redirected to another page:
If we analyze the code of the page, we can see that it consists of 95% JavaScript code:
In our analysis of the code, we note that a series of checks are run to enumerate the properties of the browser and the underlying device:
These checks are located in separate functions (A1 to A91). These are iterated in a for loop and all parameters are queried. Afterwards all parameters returned by the check functions are converted to a JSON string.
This JSON string is then AES CBC encrypted using the JavaScript library “CryptoJS”:
The individual function calls and their names are obfuscated to make it difficult for a reader to understand the code:
An encoding function like 0x4ee32b takes an array position and a key as parameters. The section of JavaScript code we have called “encoded JavaScript” is a large array containing encoded function names (a so-called lookup table). If the function 0x4ee32b(index, key) is called, the value is read in the array at the corresponding index and this is decoded by means of the key parameter. This results in a final function name. Example:
This way CryptoJS[‘enc’][‘Utf8’][‘parse’] is called. A different way of writing CryptoJS.enc.Utf8.parse(string)
We stopped our debugger at the point where the array parameter is passed to the encryption routine:
You can see that, among other things, it reads out which user agent we use, CPU, operating system, device manufacturer, browser, as well as many other parameters, which functions are allowed or possible on our device.
Then, an encryption of these values takes place and, the page transmits this encrypted string to another page:
Once we arrive there, the server constructs a new redirect pointing to another host:
This next host receives an encrypted URL that is passed as a GET parameter, which is then redirected to in the final step.
In our case, we are redirected to the “TikTok” app in the Google PlayStore:
In an article from Google it is described (https://blog.google/threat-analysis-group/protecting-android-users-from-0-day-attacks/), how similar behavior was used in 2021 to infect Android devices with a 0-day vulnerability. Here, a link was sent to the victims via e-mail. After clicking on the link, an exploit was executed in the browser to gain control over the underlying device. Similar to our example, the page finally redirects to a legitimate website.
Since we did not have a vulnerable Android device available, we can only guess if the site we analyzed also had a 0-day vulnerability or an attack planned against our device. However, we can assume that the detailed and obfuscated testing of all system parameters of our device is a preparatory step to analyze the compatibility of an attack with our device in advance.
Be vigilant against phishing attacks – not only emails but also SMS messages can reference malicious sites and prompt you to install malware (disguised as a useful app) on your device. As can also be seen in Google’s article, just one click (to find out what is behind the link) can be enough to launch an attack on the device and take it over completely.
In general, we recommend the following measures to protect against such attacks:
Note: These recommendations are not an exhaustive list. If you are unsure whether you and your company are adequately protected against phishing, please contact us – we have many years of experience in protecting against phishing attacks and offer various services on a technical and personnel level. This includes:
Penetration testing is a useful tool to improve the security of IT infrastructures as well as applications. They help uncover security vulnerabilities early on and give the company a chance to fix security issues before they are actually exploited. Penetration tests are therefore an effective means of improving the security of a company or having it evaluated. Be it customer requirements, an upcoming certification, or your company’s intrinsic need for security. Often, a penetration test by an external service provider is the requirement.
In advance to a penetration test, however, it is often assumed that one’s own company is secure in principle. Accordingly, a penetration test should identify few to no vulnerabilities, and remediation of these findings should also be feasible in a timely manner. The use of monetary and human resources is predictable. Accordingly, a timely pentest is carried out by an external party, which evaluates the security of one’s own company concluding in a final report. That definitely sounds like a desirable process, and not just for you!
"What actually happens if you don't find any vulnerabilities? Will there even be a final report?"
Problem definition
In reality, however, the results of a penetration test often differ from the expected result. Even in the few cases where applications or IT infrastructures are securely built and operated, the associated pentest reports are usually never empty. A variety of deployed standard configurations of web servers, firewalls, or other network components provide a multitude of findings to report in a final report. Coupled with a standardized risk assessment methodology such as the Common Vulnerability Scoring System (CVSS), these misconfigurations often end up as a medium risk finding in the final report.
The result of the penetration test is then perceived by companies as a surprise, as the final report does not confirm the company’s security with a green seal. This often brings up the need for a second test (a retest) after corrective actions have been implemented. This leads to potentially unplanned and additional costs, as the initial result of the penetration test is not desired to be passed on to third parties such as customers, insurance companies, etc.
Even if this very probable course is already addressed in advance of the penetration test and the offer also lists a re-test, customers are often taken by surprise by the result of a penetration test. The combination of faulty expectations and a cognitive bias such as “survivorship bias,” where only other companies are hacked and you yourself have never had an incident, often make the emotional experience of a penetration test a negative one.
However, this does not have to be the case. By preparing for a penetration test independently, many findings can be avoided in advance. This brings you, the customer, a little closer to your desired goal of a blank final report and allows us penetration testers to test in a more targeted manner. This can lead to an earlier completion of the pentest project and effectively save costs, should the pentest provider, such as Pentest Factory, charge transparently according to maximum effort.
Means of preparation
The preparations for a penetration test are, of course, based on the frame parameters of the underlying penetration test. Since there are a variety of test types and test objects, we will focus on general preparation options. These can and should be incorporated into an internal corporate process that is executed regularly and deliberately. Regardless of whether a penetration test is due or not.
In addition, we would like to clarify that preparation in advance of a penetration test is not always desirable. For example, if you’ve been raising the lack of resources for your IT department with management for years and finally get approval to conduct a penetration test, don’t do anything yourself up front. Temporarily glossing over the results would be the wrong approach here; after all, you are hoping for a realistic result from the penetration test that represents your company’s current situation and defenses. Only a negative result can signal grievances in your company to the management. You should also stay clear of preparative measures when conducting phishing campaigns, interview-based audits, or audits of your external IT service provider. After all, a real attacker does not announce himself beforehand to sensitize his victims.
The following preparation options are available in principle:
Carrying out port scans
For all non-technical readers of this blog entry, we would like to briefly explain what port scanning is and what advantages it brings. Network services, such as a web server for providing a homepage, are operated on so-called network ports. A network port is a unique address that can be used to clearly assign connections to applications. A website like this blog therefore waits for incoming connections on the standardized ports 80 and 443. Network port 80 is usually used for an unencrypted connection (HTTP) and should automatically forward to the secure port 443. Behind port 443 is the secure and encrypted HTTPS protocol, which loads the page content from the server and makes it available to your client browser for display. From an attacker’s point of view, these network ports are very interesting, as there are usually services or applications behind them that can potentially be attacked. There are a total of 65353 ports, each for connectionless (UDP) and connection-oriented communication protocols (TCP). The assignment between a port and the service behind it is standardized. However, the configuration can vary freely and does not have to be based on the standard. From an attacker’s point of view, these ports must therefore be enumerated in order to know which services can be attacked. From the company’s point of view, these ports are important to ensure that only those services are offered that are intended to be reached. All unnecessary services should be closed or their front door secured by a firewall.
Network ports can be identified using freely available network tools. One of the best-known tools for identifying open ports and recognizing network services is called “Nmap”. This program is free, open source and can be started under both Windows and Linux. It provides a large number of call parameters, which cannot be fully explained and discussed in detail.
Nevertheless, in this blog post we would like to provide you with the basic information you need to carry out your own scans. To successfully start an Nmap port scan, you only need the IP address(es) of the IT systems to be scanned. Alternatively, you can also provide the DNS host name and Nmap will automatically resolve the IP address behind it.
You can use the following command to start a port scan after installing Nmap. All open TCP ports in the range 0-65535 are identified and returned. An explanation of the call parameters can be found here.
nmap -sS -Pn –open –min-hostgroup 256 –min-rate 5000 –max-retries 3 -oA nmap_fullrange_portscan -vvv -p- <IP-1> <IP-2> <IP-RANGE>
As a result, you will receive three result files and an output in your terminal window as follows:
The results of the first port scan only list the network ports identified as open. In addition, we receive the network service behind it, which should be located behind the port by default (RFC standard). However, as already mentioned, network operators do not have to adhere to these port assignments and can tend to operate their services behind any port. For this reason, we need a second port scan to reveal the real network services behind the ports that have now been identified as open.
To do this, we execute the following command, specifying the previously identified ports and the same IT systems to be scanned. An explanation of the call parameters can be found here .
nmap -sS -sV –script=default,vuln -Pn –open –min-hostgroup 256 –min-rate 5000 –max-retries 3 –script-timeout 300 -d –stylesheet https://raw.githubusercontent.com/pentestfactory/nmap-bootstrap-xsl/main/nmap-bootstrap.xsl -oA nmap_advanced_portscan -vvv -p <PORT1>, <PORT2>, <PORT3> <IP-1> <IP-2> <IP-RANGE>
After completion, we again receive three result files and a new output in the terminal window as follows:
The resulting “nmap_advanced_portscan.xml” file can also be opened with a browser of your choice to visually display the results of the port scan as an HTML web page. HTML reports are not supported by Nmap by default, but an individual stylesheet such as “https://raw.githubusercontent.com/pentestfactory/nmap-bootstrap-xsl/main/nmap-bootstrap.xsl” can be defined when the scan is called up, which visualizes the results as an HTML report. Furthermore, the results can be filtered and there is an option for CSV, Excel and PDF downloads.
The results of the port scan should now be checked by a technical contact, preferably from the IT department. Make sure that only those network services are offered by your IT systems that are really necessary to fulfill the business purpose. In addition, take a close look at disclosed software versions and check whether the versions used are up-to-date and have been hardened with all available security patches. Also check the validity of identified SSL certificates and refrain from using insecure signing algorithms such as MD5 or SHA1. For internal IT infrastructures, you will usually have identified a variety of network services because you have scanned from a privileged network position within the organization. Here, firewall restrictions are generally implemented somewhat less strictly than for publicly accessible IT systems or services within a demilitarized zone (DMZ).
Execution of automated vulnerability scans
Vulnerability scans are usually performed using automated software solutions that check IT systems for known vulnerabilities and misconfigurations. The resulting findings are problems which are publicly known and for which automated scripts have been written to detect them. Please note that automated vulnerability scanners are not able to identify all potentially existing vulnerabilities. However, they are a great help to detect standard problems quickly as well as automatically.
The regular execution of automated vulnerability scans should be integrated into your internal business process. This process is independent of whether and how often you perform penetration tests. However, it is generally recommended to also have penetration testing performed by an external service provider, as both automated and manual techniques are used to identify vulnerabilities. Only by combining both types of testing by an experienced penetration tester a majority of IT vulnerabilities be detected and ultimately fixed by you. Accordingly, implement a vulnerability management process in your company and scan your IT assets regularly and independently.
Several products can be used to perform an automated vulnerability scan. For this blog post, we are focusing on free variants. This includes the following products:
The products are usually self-explanatory after an installation. After specifying the scan type and the IT assets to be checked, an automated scan takes place and the results are clearly displayed in the vulnerability scanner web application. All findings are usually reported with a description, risk assessment, and recommendation for remediation. Moreover, you get the possibility to export the results as CSV, HTML, PDF, etc.
Not only for penetration testing it is interesting to know, which vulnerabilities exist for a certain software product. Also from the perspective of an IT team it can be useful to quickly obtain information about an employed product version. So far various databases existed for these queries like e.g., https://nvd.nist.gov/vuln/search, https://cvedetails.com or https://snyk.io/vuln
However, during the last years, we could identify several issues with these databases:
Figure: Incorrect vulnerability results for Windows 10
Figure: Keyword search returns a different product than the originally searched for product
This is why we decided to implement our own solution. We considered the following key points:
Upon finding vulnerabilities in products, security researchers commonly register a CVE entry per vulnerability. These CVE entries are given a unique identifier, detailed vulnerability information, as well as a general description.
They can be registered at https://cve.mitre.org and are indexed in the National Vulnerability Database (NVD) in real time (https://cve.mitre.org/about/cve_and_nvd_relationship.html). NIST publishes these data sets publicly and freely, which contain all registered vulnerabilities. We use this data stream as a basis for our own database.
The technical details of the data import and subsequent provisioning are illustrated as follows:
Figure: Overview of the technical components of the vulnerability database
The data sets are organized by year numbers and refreshed daily by NIST. Every night we download the latest files onto our file server.
Afterwards the files are pre-processed to make them compatible with the Elastic Stack Parser. One process that happens here is the expansion of all JSON files: The downloaded files contain JSON objects, however they are often nested, which makes it harder to identify single objects for the parser. We read the JSON and write all object seperators into separate lines. This way we can use a regex ( ‘^{‘ ) to precisely determine, when a new object begins.
Furthermore we strip the file of all unneeded metadata (e.g., autor, version information, etc.), which leaves only the CVE entries in the file as sequential JSON objects.
After the pre-processing, our Logstash parser is able to read the individual lines of the files using the Multiline Codec (https://www.elastic.co/guide/en/logstash/current/plugins-codecs-multiline.html). Every time a complete JSON object is read in, Logstash forwards this CVE object to our Elasticsearch instance.
After all CVE entries were read and stored in the Elasticsearch database, we have to understand, which format these entries have and how we can search them for specific products and product vulnerabilities. Our final result is illustrated in the following screenshot: Using unique identifiers, we can return exact vulnerability reports for the queried product version.
Figure: Preview of our vulnerability query frontend
The general format of product versions is specified in the NIST specification. Section 5.3.3 gives a short overview (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf):
cpe:2.3:part:vendor:product_name:version:update:edition:sw_edition:target_sw:target_hw:language:other
A colon is used as a separating character. Asterisk (*) is used as a wildcard symbol.
In our screenshot: “cpe:2.3:o:juniper:junos:17.4r3:*:*:*:*:*:*:*” we can determine that the operating system JunOS of the vendor Juniper in version 17.4r3 is prone to a vulnerability.
Looking at the JSON file, it becomes apparent that there are two formats that are used to store the version number of a vulnerability.
To query the database for specific products, an easy interface to find correct product identifiers is required. We have decided to implement this component using JavaScript Auto-Complete, that displays products and associated CPE identifiers dynamically:
Figure: Autocomplete mechanism of the query frontend
After a choice was made, the vulnerabilities matching the specific product identifier can be queried.
A big advantage that storing vulnerability data in an Elasticsearch database has, is its direct connection to Kibana. Kibana autonomously queries Elasticsearch to generate visualisations from it. In the following we illustrate a selection of visualizations of vulnerability data:
Figure: Amount of registered vulnerabilities per year
Figure: Fractions of the respective risk severity groups per year
We see great potential in using this data for real time statistics on our homepage to provide vulnerability trends which are updated on a daily basis.
Another item on our CVE database roadmap is the implementation of a system that automatically notifies customers of new vulnerabilities, once they are released for a certain CPE identifier. Elasticsearch offers an extensive REST API that allows us to realize this task with the already implemented ELK stack.
Currently we are working on implementing live statistics for our homepage. As soon as this milestone is complete, we will continue with the topic of “Threat Intelligence”. As you can see, we not only focus on the field of penetration testing here at Pentest Factory GmbH, but also have great interest in researching cybersecurity topics and extending our understanding, as well as our service line.
You are currently viewing a placeholder content from Vimeo. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from YouTube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More Information