Acronis Infrastructure Security Scanner

By Nikita Kelesis, Senior Product Security Expert, Acronis

In today’s rapidly evolving digital landscape, regularly scanning​ ​ a company’s external perimeter for vulnerabilities​ іs not only​ a proactive measure, but​ also an essential defense strategy. Such regular scans are critical for several reasons:

• Evolving threats: Cyberthreats are continuously evolving. Regular scanning helps​ identify new vulnerabilities and maintain​ a robust defense against emerging cyber risks.

• Compliance and standards: Regular security assessments are often mandated​ by industry regulations. Staying compliant helps​ avoid legal and financial complications.

• Network visibility:​ As companies expand,​ sо​ dо their digital assets. Regular scanning ensures​ an up-to-date understanding​ оf the external network — crucial for effective asset management and protection.

• Incident response preparedness: With current scan data, organizations can respond more effectively​ tо security breaches, giving​ them a clear understanding​ оf their perimeter’s state.

To effectively conduct security checks, you need tools like Nuclei, a community-driven, free and versatile vulnerability scanning tool. Nuclei​ іs renowned for its ease​ оf use, customization and extensive template system contributed​ by​ a vibrant community.

An integral part​ оf this scanning process​ іs the effective management and organization​ оf network data. For this,​ we utilize NetBox,​ an open-source web application designed for the documentation and management​ оf network infrastructures.​ It’s particularly advantageous for vulnerability scanning due to:

• Comprehensive data management: NetBox facilitates detailed documentation​ оf all network components, making​ іt​ a comprehensive tool for managing physical and virtual network elements.

• Hierarchical data structure:​ In our use case,​ we leverage NetBox​ tо categorize data into different tenants, such as IT, cloud and web. This hierarchical organization aids​ іn conducting targeted scanning processes efficiently.

• Current and accurate information: The regular updating​ оf NetBox ensures that the data reflects the latest network state, which is critical for effective vulnerability scanning.

• Integration capabilities: NetBox’s API and data export features allow for seamless integration with other systems, setting​ a solid foundation for subsequent scanning phases.

In this article, we dive into how tools like Nuclei, Masscan, Nmap and NetBox’s efficient data organization are integral to our strategy for regular perimeter scanning. We also discuss how we utilize these tools for data processing in the creation of an automation utility named Acronis Infrastructure Security Scanner (AISS).

When designing the utility, we set clear goals to enhance collaboration, efficiency and security within our team’s workflow:

• Collaborative configuration: It was crucial that the scan configuration be user friendly, empowering any team member with the ability to add or alter settings. This democratizes the process, allowing for shared responsibility and collective expertise to refine our scanning tactics.

• Logical segmentation of scope: We aimed to break down the scan scope into distinct, logical elements. Each segment was to have its own targeted checks, making it easier to manage and more effective at identifying vulnerabilities within specific network zones.

• Simplicity in configuration changes: The utility was designed with a philosophy of simplicity. Any modifications to the configuration should be straightforward, reducing the potential for errors and the time taken to implement changes.

To achieve the first two objectives, a ‘checks’ folder with config files was created, divided into four logical elements.

• In the ‘DCO’ and ‘IT’ folders, checks related to allowed or dangerous ports are contained. This is because some services have a list of permitted ports, while others do not. Therefore, in the first case, an alert would indicate an open port where it shouldn’t be, and in the second case, for example, a database port is open, which is potentially dangerous.

• In the ‘nuclei’ folder, there is a ‘disabled.txt’ file, which disables checks that are unnecessary or cause false positives. To do this, you can simply add, for example, ‘CVE-2023-33584’ on a new line, and in the next scan iteration, this check will be excluded.

• The ‘web’ folder contains checks related to HTTP resources: dangerous_files.txt’ — A list of files and directories brute forced using HTTPX:

  - ‘HTTPX_skip_if_exist_in_response.txt’ — This file contains text which, if present in the server response when iterating directories / files using HTTPX, should not be reported in ASAP or Teams as it would be a false positive. Imagine a scenario where the server responds 200 to any directory, and you are always greeted by an authentication form. If there’s a pattern in its HTML code indicating an authentication form, this pattern would be entered in this file.                     

  - ‘popular_http_ports.txt’ — This file contains popular HTTP ports, which are supplemented as needed. When Masscan finishes scanning all ports, the module responsible for creating the list of HTTP resources will take the scan of open ports and additionally create a new list of only open HTTP ports. However, this is only a potential list, which needs further validation using HTTPX, which will attempt to resolve IPs / domains, creating the final list of HTTP resources.

                                               Code block 1: Popular http ports:

                                             Code block 2: Dangerous tcp ports:                                                                                     

                                            Code block 3: Dangerous UDP ports:    

To establish our automated scanning process, we use a virtual machine setup within Google Cloud, specifically choosing the e2-medium instance type. 

To securely connect our Google Cloud VM to NetBox for our automated scanning process, we employ a zero-trust-access model. This approach involves allowing access only from the VM’s specific IP address and utilizing a service account with read-only privileges. An API token is used for authentication, granting only read access to NetBox. This security setup, rooted in zero trust principles, ensures that access to NetBox is tightly controlled, minimizing the risk of unauthorized data alteration while maintaining the integrity of our network security.

Our utility is divided into two logical phases, each tailored to specific aspects of our comprehensive security scanning approach.

1. Extraction of IP Addresses and prefixes and from NetBox and domains from Domain Registry

In the initial phase of our scanning process, the utility retrieves vital network data from NetBox, targeting two key tenants: the "IT" tenant, encompassing all corporate resources, and the "DCO" tenant, which contains all products and services offered by the Acronis. Additionally, it extracts all domains and subdomains from our internal Domain Registry service. This gathered information will be used for scanning.  

2. Removing of disaster recovery IP addresses and prefixes

Disaster recovery solutions allow companies to quickly resume business-critical workloads after cyberattacks, natural disasters, or server failures. The disaster recovery process normally involves a separate physical or cloud site to restore data. Every disaster recovery solution aims to help businesses operate as usual. In this step, AISS utility downloads an internal repository filled with YAML files that detail the IP ranges of our disaster recovery service. Importantly, these IP addresses belong to our clients, not our company. To ensure our scanning is precise and focused, these client IPs are then excluded from the IP addresses of the Cloud tenant gathered earlier, effectively separating our company’s assets from client-owned networks for targeted scanning.

3. Nmap scanning for live hosts

Following the organization and sorting of IP addresses for each tenant, we employ the Nmap utility to perform a SYN (sn) scan. This step is crucial for identifying live, responsive hosts within our network. Upon completing this scan, Nmap initiates phase two of our process, transferring the results — specifically, the details of the open hosts — to the modules responsible for conducting custom checks. This transition ensures a seamless and efficient progression from general host detection to more targeted and specialized security assessments

4. Vulnerability scanning with Nuclei

When using Nuclei for vulnerability scanning with a file containing thousands of IP addresses or domains, there’s a risk of exhausting all available memory, particularly if the server has limited RAM. This can lead to the server becoming unresponsive. To mitigate this issue, our script implements a two-fold solution:

a. Chunking the target file: The script divides the final file into smaller chunks, each containing 25 domains. This chunking method ensures that Nuclei processes a manageable number of targets at any given time, thus preventing excessive memory usage.

b. Running Nuclei in Docker with memory limits: Nuclei is run within a Docker container, where a maximum RAM usage limit is set. This containment approach not only helps in managing the memory consumption effectively, but also adds a layer of stability and predictability to the scanning process.

Additionally, with every new chunk processed, Nuclei attempts to update itself and its templates to the latest versions. This practice ensures that the scanning is conducted with the most up-to-date information and vulnerability detection capabilities, maintaining the efficacy and relevance of the security scans.

5. Reporting and alerting vulnerabilities

After completing the scanning of each chunk, our reporting module reviews the scan results for vulnerabilities rated medium or higher in terms of severity. If any such vulnerabilities are detected, the module sends all relevant information to our internal service named ASAP, which aggregates all security-related tickets. This ensures a systematic and organized approach to addressing and tracking security issues.

Additionally, for the most severe vulnerabilities — those classified as high or critical — we implement an extra layer of alerting by duplicating the ticket submission to a dedicated Microsoft Teams channel. This practice allows for more immediate response and attention to these critical security concerns, ensuring prompt action and mitigation. This dual-reporting mechanism — via ASAP for all significant vulnerabilities and Teams for the most critical ones — ensures that our security team is alerted promptly and can take appropriate and timely actions. In addition to critical vulnerabilities, error logs are also sent to Teams when the utility crashes for any reason. This way, we immediately become aware of any issues with the utility and can quickly restore it to working condition.      

6.  Archiving and reset for new scanning cycle 

Upon completion of a scanning cycle by Nuclei, which involves processing the final chunk of a file within the specified scope, a series of actions are initiated. These include the generation of tickets in ASAP and the creation of corresponding Microsoft Teams channels. The script then compiles an archive containing all the data gleaned during the scan. This data encompasses:

• IP addresses and prefixes linked to a specific data center, alongside a list distinguishing those elements related to disaster recovery that do not belong to us.
• Results from the SN scan, detailing which hosts are active and responsive.
• Outcomes of the Nuclei scan.
• A log detailing the tickets generated in ASAP and Teams.

The resulting archive is organized into a folder, named in the DDMMYY format, where all the above-mentioned results are stored as files. To optimize space, folders older than one month are converted into compressed archives, and data older than six months is purged.

As previously mentioned, phase two commences following the completion of the SN scanning in phase one, which identifies active hosts. This phase is dedicated to performing custom checks on the defined scope.

1. Scanning of TCP / UDP ports using Masscan and Nmap

Certain Acronis services have an established list of authorized ports for their use. Any ports open beyond this predefined list are considered a misconfiguration. To identify such problems, a comprehensive scanning process is undertaken. This includes TCP scanning across all ports and UDP scanning of critical ports, as outlined in the utility’s configuration list. Given the substantial scope of this task, we utilize Masscan, known for its rapid scanning capabilities.

But sometimes, Masscan marks a port as open when it’s actually filtered or open / filtered. Therefore, we further scan the list generated by Masscan using Nmap, and only retain those host:port pairs that are confirmed as open in both scans.

Following the completion of the scan, we compile a list of hosts along with their ports that shouldn’t be open, and report these findings to the respective service owners.

2. Creating a list of HTTP resources

In the AISS setup, we maintain a list of well-known HTTP ports. This list is crucial for shaping our search for web resources from the Masscan data. Essentially, we check each port from our list against those found open in the Masscan results, leading us to a list of potential web resources. Once this list is compiled, we use the HTTPX tool. It’s really effective at swiftly resolving each ip:port or domain:port combination, helping us pinpoint the actual HTTP resources out there.

3. Check http → https

Next, with the resolved list of HTTP resources in hand, AISS makes requests to each IP:port and domain:port combination, both over HTTP and HTTPS. If the server’s responses are both 200 but the response lengths differ, or, in the case of an HTTPS request, the server response is 401 or 403, but for an HTTP request, it is 200 and one doesn’t show the standard web server page, we generate a ticket in ASAP. We then manually check to see if there’s actually an issue. This check is vital as we’ve had several bug bounty cases where an internal resource required authorization over HTTPS, but not over HTTP. Another aspect of this step is identifying those hosts that only respond over HTTP and not HTTPS, marking them for further review.

4. Brute forcing dangerous files and directories

For each HTTP resource, we use HTTPX again, but this time to hunt for risky directories and files. There are plenty of great dictionaries out there, but https://github.com/Bo0oM/fuzz.txt and https://github.com/ayoubfathi/leaky-paths stand out for brute force attempts. Also, we’ve occasionally found some sensitive files on the perimeter, which are definitely included in our final list.

However, a 200 response from the server doesn’t necessarily confirm that a dangerous file was actually found. Different web server configurations and behaviors can be misleading. That’s why we’ve implemented an additional check in AISS. If 10% or more of the entries from the dictionary are found on a resource, we don’t raise a ticket in ASAP and Teams. Instead, we flag it locally as a false positive. This approach has almost completely eliminated false alarms for us.

5. After completing all the scans, the process of reporting and archiving the results is identical to what we do in phase one. The results are archived and categorized into logical segments.       

• Scanning of hosts for all TCP ports and some UDP ports.

• Scanning of hosts for all TCP ports and some UDP ports.

•  Identified open ports that should not be open on certain hosts.

• Detected open dangerous ports that could pose a theoretical risk.

•  A list of all resolved web resources.

• Checks for HTTP to HTTPS misconfigurations.

• A list of brute-forced dangerous files and directories.

In addition to the AISS utility described above, we also use Nessus for external scanning, as well as some other custom checks.

1. To maintain an up-to-date scope in Nessus, we have created a watcher that extracts data from NetBox once a day and updates the scope information using the Nessus API. To make it easier to navigate through scans, they are also divided into logical elements, with each scan covering either individual data centers or a service with all its components. After the scan is completed, the watcher extracts the vulnerabilities found in Nessus and creates tickets in ASAP.
2. To search for the possibility of subdomain takeover, a watcher has been created that extracts all domains belonging to Acronis from the internal resource, domain registry, and using https://github.com/EdOverflow/can-i-take-over-xyz, checks each for the possibility of subdomain takeover. After the work is completed, the results obtained will be sent to ASAP.
3. A TLS-watcher has been written to check the validity of TLS certificates, which receives information from the domain registry about all domains every day and checks the expiration date of the TLS certificate. If the expiration date is less than 14 days, it creates a ticket in ASAP.

As mentioned earlier, ASAP is the main source of information about security issues found using various utilities or watchers. This enables us to create small utilities for specific checks, which significantly speeds up the coverage time of a particular problem. When a watcher is committed to the internal git, the build system will automatically create a Docker image from it, which we can then select in Portainer, configure and then launch the watcher.

Securing a company involves a complex array of measures and processes that must operate in tandem to achieve comprehensive protection. Continuous scanning of external company resources is one such critical process. By leveraging free utilities and frameworks like NetBox, Nuclei, Masscan, Nmap and others, you can quickly and easily create an automated scanning process for your external perimeter. For rapid decision making, the most critical vulnerabilities can be duplicated to communication platforms such as Teams, Slack, Telegram, etc.

By consistently updating Nuclei templates before each scan and by developing custom checks, you maintain a daily insight into the security posture of your external perimeter. This proactive approach ensures that your security measures evolve in step with the ever-changing threat landscape, enabling your company to stay one step ahead in maintaining its security defenses.

Nikita Kelesis has more than seven years of experience in offensive and two years in defensive security. His primary interests include the security of web, API and cloud environments. Over the years, he has conducted numerous penetration tests, both external and internal, as well as engaging in social engineering efforts. Recently, his main responsibilities and interests have shifted toward developing automation for vulnerability scanning, covering both the external perimeter and cloud environments, including Helm charts and Docker images.