EVA – Extended Vulnerability Assessment
EVA – Extended Vulnerability Assessment
EVA’s penetration testing activity has been developed in its proprietary code to have the exploit mode by default, which allows the identification and exploitation of known vulnerabilities (CVE exploits) following the enumeration of the analyzed hosts, without having a negative impact on the operation of the analyzed system.
What EVA Does?
Surface scan & enumeration
EVA’s surface analysis covers both the network and services aspects, from public IP addresses and web applications to internal corporate IT systems.
Once the target is obtained from the client, EVA performs a black-box analysis of potential attack points exploitable by a cybercriminal. It optimizes its search by determining and tracerouting the hosts used and active services (e.g., Apache, Solaris, Nginx, etc.) by the client.
EVA is able to recognize the types of devices used (e.g., routers, firewalls, DVRs, industrial machines, IP cameras, etc.), identifies the versions of the operating system in use (e.g., Windows, Linux via TCP/IP stack fingerprinting, SCADA), and the types of filters used by the IT system (e.g., IDS/WAF for monitoring anomalous network activities).
The software scans the protocols and services used (e.g., FTP, SSH, HTTP, WebDAV, etc.), identifies the Common Platform Enumeration (CPE), and performs enumeration of the resources found (e.g., NetBIOS, SNMP, LDAP, Kerberos, MySQL, PostgreSQL)10. It extracts information such as service version, Git commit, build date, auth permission, namespaces, pods, etc..
EVA also identifies and detects Web Application Firewall products (e.g., Azure Front Door, ASP.NET Generic, AWS Elastic Load Balancer, Cloudflare, Cloudfront, DataPower, GoDaddy Website Protection, Oracle Cloud, SonicWall, ZScaler, etc.) through the analysis of responses received to HTTP calls.
EVA is capable of balancing its activity, meaning it can be adaptive to the tested resource, across all 65,536 ports of any host, thanks to the use of AI/ML scripts, avoiding detection and banning by Intrusion Detection and Prevention systems (IDS/IPS). To this end, the activities conducted by the software include the analysis of the most commonly used ports to verify
active services, such as mail servers, and their respective protocols (e.g., Telnet, SMTP, SMB, etc.).
EVA was developed to allow vulnerability scanning at the application level as well, including plugins present and, more generally, to analyze and test the most important content management systems (e.g., Drupal, WordPress, Joomla, etc.) and typical development frameworks (e.g., ASP, Jquery, Bootstrap, PHP, Laravel, etc.). EVA is a powerful web server testing tool because part of its activity consists of identifying both existing and hidden web objects, including through dictionary-based tests, combining them with so-called Common Gateway Interface (CGI) tests. It is able to identify the version of the CMS and thousands of resident plugins, including JavaScript libraries and any embedded devices.
Furthermore, EVA’s activity also includes searching for alternative paths compared to those found through classic automated analyses that could be potentially useful to an attacker (e.g., admin panels, readme files, directory browsing, etc.). In the same way, it searches for misconfiguration errors (e.g., injection) and known intrusion methods, including the search for user IDs and brute-force attempts.
Exploitation (Penetration Testing)
EVA’s penetration testing activity was developed in its proprietary code to have the exploit mode by default, which allows it to identify and exploit known vulnerabilities (CVE exploit) following the enumeration of the analyzed hosts, without negatively impacting the operation of the system analyzed.
EVA is capable of generating so-called evasive payloads, meaning those that aim to evade antiviruses (e.g., Windows Defender), without the need for external support from other tools, operating in complete autonomy and black box. All vulnerabilities are verified and tested, where necessary and possible, to avoid impacting the performance of the analyzed systems.
Exploitation tests concern the areas of analysis post surface scanning, thus including, for example, testing of application protocols used (e.g., HTTP, HTTPS), network files (e.g., SMB dumping, Eternal Blue), encryption protocols (e.g., SSH), JBoss and more generally Java server applications (e.g., deserialization, RMI over HTTP, Jenkins RCE, Remote JMX),
databases (e.g., MySQL and Microsoft SQL Server brute-force and dumping) , and Active Directory in the case of a customized service.
EVA can also check the services used to rapidly and easily determine if the enabled services are exploitable, without having consequences on the target (e.g., SQL Injection, RFI, LFI, SMB, FTP, etc.). This is generally done by executing a pingback command, which is essentially harmless to the system. Indeed, given the desire to ensure the operational continuity of the
tested services, the execution of reverse shells is only performed during customized tests.
EVA’s activities do not include the demonstration of the full exploitation of vulnerabilities related to the remote management of the target machine through the execution of commands on the target terminal (e.g., WinRM CMD), as these are considered excessive and not strictly
necessary for remediation activity. In any case, EVA does not execute Denial of System (DoS) attacks.
Encryption test
EVA is capable of analyzing encryption settings and related vulnerabilities present on network resources (e.g., Lucky13, Sweet32, Poodle, Beast, etc.)40. During this activity, configurations related to the encryption protocol used are identified, and any cryptographic defects present, including those at the service level (e.g., Https, STARTTLS for MySQL, PostgreSQL), are located. During this activity, EVA connects to the server and analyzes its SSL/TLS configuration (including SSLv2, SSLv3, and TLS v1.3 versions), in particular searching for advanced encryption settings (e.g., certificates, cipher suites, elliptic curves, etc.) and ensuring that it is not vulnerable to known TLS attacks (e.g., Heartbleed, ROBOT, OpenSSL CCS injection, etc.).
EVA is also capable of performing more specific encryption analyses (e.g., base64, 3DES, RC4, DHE keys) , with the aim of highlighting critical credentials, i.e., those that would allow an attacker to reach the most confidential corporate information.
Configurations test
EVA performs an analysis of the default and authentication settings of the tested services (e.g., anonymous access, git, obsolete OS, etc.). The software is able to check server configuration elements, such as the presence of multiple index files and HTTP server options, and default files and programs that are considered insecure and obsolete. This type of activity is not configurable as a penetration test, but focuses on extremely useful tasks such as the enumeration of user names/IDs and testing access to resources protected by “weak” passwords or misconfigurations using, for example, brute force. Password cracking activity
is only executed in case of customized service requests.
EVA performs a very extensive analysis of website configurations, even at the database level (e.g., wp-config.php file, database dump, etc.) and verifies if these are publicly accessible. Consequently, the software can locate error logs via plugins, checking the so-called full path disclosure, and identifies backup and configuration files (e.g., database)
OWASP checklist
EVA follows the principles of the OWASP Testing Project, meaning it performs its VA/PT activities according to the Penetration Testing Execution Standard (PTES), which defines the testing path in 7 phases:
- Pre-engagement interactions
- Information gathering
- Threat modeling
- Vulnerability analysis
- Exploitation (where possible)
- Post-exploitation analysis
- Reporting
EVA executes the phases based on the analyzed target and the service purchased by the client, choosing the most appropriate activities, meaning avoiding those that could compromise the target’s operation (e.g., DoS attack, including so-called post-exploitation activities.
These are considered excessive and unnecessary for the purpose for which EVA was designed, which is to automatically understand the weaknesses of one’s systems and provide for their resolution, without repercussions on service operation.
EVA, as stipulated by the OWASP framework (phase 4.1 Application Penetration Testing), encourages application penetration testing after it has been deployed, as it provides an additional check to ensure that nothing has been missed, as well as continuous monitoring (Phase 5.2 – Conduct Periodic Health Checks).
EVA’s security tests include the activities provided for by the OWASP Framework, particularly in the Web Security Testing Guide. Therefore, EVA performs tests at the Web Application level (WSTG 4.x), from access misconfigurations (e.g., default credential, browser cache weaknesses, MFA) to weak encryption (e.g., at the transport level) and client-side issues (e.g.,
JavaScript execution, HTML injection, etc.).
In addition to executing the technical part of the test, EVA produces an informative report that follows the Framework’s requirements (WSGT 5.x), meaning it is easy to understand because it is designed to facilitate the work of technical personnel but also to be understood by non-technical personnel (the so-called executive management), highlighting the risks encountered during the assessment phase. To this end, the EVA report follows the OWASP report scheme, including its characteristic elements: 1) Introduction, 2) Executive summary, 3)Findings. In particular, EVA adds other very useful information for remediation activities to the basic OWASP structure (Ref. ID – Title – Risk Level), introducing, in a structured manner, other elements including vulnerability references, descriptions, and PoCs (Proof of Concepts).
OSSTMM Methodology
EVA follows the testing methodology described in the Open Source Security Testing Methodology Manual (OSSTMM), which was designed to test the operational security of workstations, workflows, wireless, and data networks more generally. EVA chose to adhere to this framework also because it is considered a technical reference supporting the ISO/IEC 27001 standard.
To this end, EVA is the security analysis tool that can be integrated into a company as an integral part of the workflow established in the OSSTMM model (cf., Chapter 6 – Work Flow, OSSTMM 3), precisely because it focuses on the activity of searching for vulnerabilities and verifying the robustness of the corporate IT system. As established by the OSSTMM model, EVA promotes the principle of “There is no perfect security” (cf., Chapter 3.1 Critical Security Thinking, OSSTMM 3), encouraging its clients not to view security as a product or a single service, or as a path where a definitive date or step can be established.
On the contrary, EVA promotes continuous monitoring and analysis, as no system is 100% secure and the vectors, types, and severity of threats constantly and rapidly change: “Security is a process, not a product”. This concept requires the organization to adopt a security approach based on awareness of its assets and their correct management through a so-called risk-based model.
In line with the requirements of the OSSTMM methodology, and overcoming the limitations of the “checklist” approach of the OWASP framework, EVA provides its “transparent” report (cf., Chapter 3.6 – Transparent Reporting, OSSTMM 3). Indeed, a cyber security analysis will rarely conclude with all the answers sought, as there might be a visible objective (e.g., public IP) that provides no interaction or information, but it would not be correct to ignore it. Therefore, EVA reports everything that was found with certainty, including elements of possible vulnerability that would require further investigation, such as: non-analyzable targets (e.g., reachable but not active IPs), assets with unknown risk (e.g., no vulnerabilities found), and untested vulnerabilities (e.g., vulnerabilities identified but not tested because potentially harmful/invasive).
Furthermore, thanks to EVA’s AntiPhishing and OSINT services, EVA can be used as a tool to test the human factor within the IT system, as provided for by the model (cf., Chapter 7 – Human Security Testing, OSSTMM 3)105. On one hand, it performs social engineering and threat intelligence activities 106106; on the other, it extends the scope of these activities through phishing tests to increase personnel security awareness, providing a useful measure to understand the gap with respect to the security standard required and defined in the corporate policy of each organization, always respecting the rights of individuals (e.g., GDPR compliance).
The OSSTMM model also provides for network resource testing activities (cf., Chapter 11, Data Networks Security Testing, OSSTMM 3). In this case as well, EVA was designed to support this activity by company personnel, offering an analysis verified by competent and certified analysts in the cyber security field, with adequate knowledge and experience in networking and security testing, as well as critical thinking to ensure that data collection, also carried out through the use of machine learning, produces factual results.
ISO 27001
EVA has set up its testing activities to support companies in being compliant with the new ISO/IEC 27002:2022 standard, which has a new structure and entails a significant modification of ISO/IEC 27001:2013, particularly to realign Annex A. Indeed, the new standard requires controls to be more substantial and performance-related, meaning focused on cyber prevention. In this sense, the following controls explicitly call for the need to use very specific penetration testing and vulnerability assessment activities:
- Control 5.21 (Policies for information security) requires the implementation of a process for monitoring the ICT supply chain through the use of penetration testing activities by qualified third parties, such as EVA
- Control 8.8 (Management of technical vulnerabilities) requires using vulnerability scanning tools suitable for the technologies in use to identify vulnerabilities and to verify whether vulnerability patching has been successful, as well as conducting planned, documented penetration tests by competent and authorized parties to support vulnerability identification
- EVA’s VAPT activity proves suitable for the control, as the test can be performed both externally and internally to the organization’s network, and is adaptive to the analyzed resource, meaning the analysis is specific and calibrated to the technology employed.
- Furthermore, the report provided allows for targeted patching of the identified vulnerabilities, thanks also to the path (PoC) included in the report, and the verification of the success of remediation activities and test planning can be carried out through EVA’s default setting for recursivity on the tested resources.
- Not only that, EVA provides a classification of vulnerabilities such that a remediation plan (so-called remediation plan) is directly implementable.
- Control 8.25 (Secure development life cycle) requires the secure development of software, whether it is related to a service, an architecture, or a system. To this end, a prerequisite for satisfying the control is to perform a VAPT on the system, which is within the scope of the EVA software
- Control 8.29 (Security testing in development and acceptance) is satisfied when security testing processes are defined and implemented in the development life cycle. To this end, the standard specifies that the organization can leverage automated code analysis tools or vulnerability scanners, especially to verify the correction of security- related defects. This activity is fundamental to the EVA software, especially when used in the pre- and post-remediation phases.
Conclusion
EVA is therefore the independent and qualified third-party partner to provide the vulnerability assessment and penetration testing activities required by the standard, usable both before the auditing phase and during continuous compliance with ISO/IEC 27001, as EVA also responds to Control 5.20 of the same standard (Addressing information security within supplier agreements), particularly concerning the methods of conducting tests and the outputs provided, as well as the methods of information exchange, their classification, and the security levels provided
