Asset management in Blackbox mode

Bokov Fyodor, Security Vision

“I want to see the whole picture, but I’m not ready to give you the keys to all the doors” – this is one of the most common and contradictory requests from a customer who has purchased an asset management product but doesn’t want to provide any data for connecting to target hosts, network devices, and other IT assets. How can the vendor help in this case? By managing assets in Blackbox mode.

Asset discovery

It all starts with a simple question: what does the customer actually have on their network? When you don’t have access to internal documentation or configurations, you have to search for assets blindly. The first and main method is network scanning. In this case, a custom‑written scanner or any Open‑Source scanner will help us — for example, nmap or masscan. After scanning the network, we understand which IP addresses we have in our infrastructure and which ports are open for further interaction with them. The mere fact of an open port is already a valuable finding. It indicates that some service is running on the host and is ready for interaction.

Identification

Identification is one of the most varied processes in asset management. When the list of open ports is ready, real detective work begins: you need to understand what exactly is hidden behind them. For this purpose, everything that an active service can tell about itself is used. Each asset, in response to external requests, unwittingly leaves behind many clues. The task of identification is to collect and analyze these clues. These include technical banners, the content of HTTP headers, page titles (title), website icons (favicon), the structure of HTML code, and even unique behavioral patterns (fingerprints). The key to correctly collecting information lies in the open ports themselves. Based on their standard purpose, we choose the appropriate method of interaction — which protocol to use and what questions to ask the service — in order to get the most informative response from it.

Let’s take a classic example. Upon detecting an open 22nd port, we can assume with a high degree of probability that an SSH server is running. We establish a connection and first of all receive a banner from the system — a service greeting message. It may contain a key string, for example: OpenSSH_8.9p1 Ubuntu-3ubuntu0.13.

Its analysis immediately gives us several facts. First, we can conclude that the OpenSSH server is being used. Second, the operating system is explicitly stated — Ubuntu. But we don’t have to stop there. By comparing the specific package version (8.9p1 Ubuntu-3ubuntu0.13) with the distribution’s repositories, we can confirm that this is a build typical of Ubuntu 22.04 LTS (Jammy Jellyfish). Thus, from the banner we extract not only the type of service but also the exact version of the operating system.

Another clear example is the analysis of the web interface available on the standard port 443. When accessing such a service, the system transmits not only the page content but also the service HTTP headers. In some cases, they constitute a complete response. For example, if in the responses we see the http-title header: GAiA, and among the metadata the value Server: CPWS, this is already sufficient for an accurate conclusion. The combination of these features unambiguously indicates a network device running the Checkpoint Gaia operating system. Thus, even without access to the internal configuration, we can accurately classify the asset and understand its role in the infrastructure.

Obtaining software

Two key stages have been completed: network scanning to detect assets and initial identification; however, in blackbox conditions, this cannot be the end of the process. Since it is impossible to carry out an inventory, the only way to get a complete (as far as possible) picture is to analyze each detected open port in as much detail as possible in order to extract information. In essence, this means conducting a methodical survey of all available interfaces.

For example, upon detecting open ports 443/HTTPS and 1433/MsSQL on a host, we apply targeted data collection methods to each of them. We treat port 443 as a web service: we analyze not only the connection banner but also retrieve the HTML page, examine all HTTP response headers, and study the JavaScript code. This allows us to identify the web framework, interpreter, CMS, or specific web application running on the port. To identify the service on port 1433, we use two main methods: we try to connect to it as to a database via the appropriate client and/or analyze its response to web requests. This allows us to determine whether we are dealing with a DBMS, a web interface, or another service.

In our case, after analyzing all the available information from the ports, namely the banner for port 1433: Microsoft SQL Server 2017 14.00.1000, and the HTML page on port 443:

https://www.example.ru/ [200 OK] Bitrix-Site-Manager, Cookies[PHPSESSID], Country[RUSSIAN FEDERATION][RU], Email[example@email.com], Frame, HTML5, HTTPServer[nginx/1.28.0], HttpOnly[PHPSESSID], IP[192.168.156.166], JQuery, Open-Graph-Protocol[website], PHP[8.2.29], Script[text/javascript], Title[Example], UncommonHeaders[x-powered-cms,content-security-policy,x-ammina-module], X-Frame-Options[SAMEORIGIN], X-Powered-By[PHP/8.2.29], nginx[1.28.0],

we can draw conclusions about the following running applications:

• Microsoft SQL Server 2017, version 14.00.1000,

• nginx web server, version 1.28.0,

• PHP interpreter, version 8.2.29.

This list, which includes names, types, and, most importantly, the exact versions of the software, becomes the foundation for the final and most critical stage – the targeted search for vulnerabilities in this specific software stack.

Having collected information about the application software, we deepen the analysis. The next logical step is to examine the operating system itself — the basic platform on which all the detected services run. This stage allows us to restore the key parameters of the environment, which is critically important for risk assessment, even without directly connecting to the system.

A number of system parameter values can be identified indirectly. For example, the system architecture and bitness (x64, ARM) are often determined based on the available list of packages in repositories (for Linux systems) or through specific responses from certain services designed for specific platforms. To understand the role of an asset, you need to find out its network name. When connecting via certain protocols (RDP, SMB), the system often reports its hostname or FQDN, as well as its domain affiliation (Active Directory). This simple information may indicate whether the host is an ordinary server or an important element, for example, a domain controller.

Temporal parameters may seem secondary, but they are also informative. Analyzing timestamps in HTTP headers or the deviation of the system time obtained via certain protocols allows us to judge whether there are synchronization issues with the NTP server.

MVP practice

Managing assets without internal access requires a special approach based on a continuous monitoring cycle. Since inventory cannot be used, this is compensated for by three interrelated processes that function as an automated security conveyor.

The first process is the constant search for something new. The basis of the approach is regular and frequent scanning of the external and internal perimeters. We cannot obtain a complete network map through network devices, but we can create a preliminary layout of the assets’ location. Automated tools go through all the company’s known domains and ranges of its IP addresses, recording any changes: a new subdomain, a previously invisible server, or an unexpectedly open port on an existing host. The goal is to detect such changes within a short time.

An example of a network map created using the Security Vision Assets Management module.

The second key process is establishing a continuous monitoring system for all already identified assets. Detection and initial identification are just the starting point, after which each host transitions to a regular monitoring mode. To achieve this, a periodic re‑profiling cycle is launched, carried out according to a specified schedule. It is important not just to record the initial state of the system, but to consistently track any deviations from this baseline: changes in the versions of installed software, modifications to service configurations, the appearance of new open ports and network services. This approach allows for clear detection and classification of events, distinguishing scheduled updates from unauthorized changes.

The final process is continuous analytics. The collected data is automatically systematized. Each asset is assigned roles based on its affiliation with a particular category, and the criticality level is established based on the asset’s criteria. This allows you to move from a simple list of problems to a clear action plan: what to fix first, what to monitor with close attention.

Blackbox is not a magic pill. It is a basic, but absolutely necessary, level of work. It won’t replace a full inventory, but it will give you a specific list of problems that need to be addressed first, allowing you to move from abstract threats to a concrete list of gaps in your infrastructure: open ports, outdated versions, insecure configurations. This is a view of your infrastructure through the eyes of someone who wants to get into it without permission. And this view often turns out to be the most useful.