ReconnaissanceAttack surfaceOSINTMITRE ATT&CK

Nine billion scans in six months: reconnaissance is now the busiest phase of the attack

What grew fastest was not the attack, it was the phase that comes before it. How an attacker builds a target list without sending a single packet to your server.

By Equipe VorvexPublished on August 19, 20266 min read

FortiGuard Labs recorded 249.3 billion attack attempts and malicious cyber activity against targets in Brazil during the first half of 2026. The number that actually changes a security decision, though, sits inside that total: nine billion active scans in six months, a volume 44% higher than everything recorded across all of 2025. The fastest growing phase was not the attack. It was the phase that comes before it.

The cheapest phase of the chain is the one growing fastest

Active scanning is technique T1595 in MITRE ATT&CK, under the Reconnaissance tactic (TA0043). It is the moment when the attacker has no target yet, only a method: sweep IP blocks (T1595.001), look for vulnerable versions (T1595.002), and probe known paths from a wordlist (T1595.003). The rest of the Fortinet report follows the same curve. Malware jumped from 187.5 million occurrences across all of 2025 to 406.8 million in the first half of 2026 alone, trojans tripled from 32 million to 100 million, cryptominer activity reached 69,000 occurrences and passed the entire previous year, and there were 6,932 ransomware incidents. But reconnaissance growth is the indicator that shows up first, because it happens weeks or months ahead of everything else.

The practical consequence is a reversal of logic that has still not reached most risk conversations. In a mass reconnaissance campaign, the target is not chosen, it is found. Nobody decided to attack your company: somebody swept the internet looking for one specific version of one specific product, and your instance answered. Company size, industry and brand relevance never enter that calculation.

Diagram of a mass reconnaissance funnel narrowing from the whole internet address space down to a small set of reachable vulnerable hosts — The mass reconnaissance funnel: the target is not picked at the start, it is whatever survives successive filters applied across the entire internet.

The reconnaissance that never touches your server

A large share of modern mapping is passive, and therefore invisible to anyone who only watches their own access log. The technique is T1596, searching open technical databases, and the most productive sub-technique is T1596.003, digital certificates. The reason is structural: since RFC 6962, every publicly trusted TLS certificate is recorded in Certificate Transparency logs, append-only and auditable by anyone. Browsers require that proof of logging before they accept the certificate, which means there is no option to issue a public certificate and keep it secret.

Issuing a certificate for staging-api.company.com publishes that hostname to the world within seconds. The host can sit behind a firewall, with no public DNS record and no link pointing at it anywhere. Its name is already out.

bash

# Certificate Transparency lookup via crt.sh.
# No packet ever reaches the target: the data is already public.

curl -s 'https://crt.sh/?q=%25.exemplo.com.br&output=json' \
  | jq -r '.[].name_value' \
  | sed 's/^\*\.//' \
  | tr 'A-Z' 'a-z' \
  | sort -u

# Typical output for a real corporate domain:
#   api.exemplo.com.br
#   homolog-api.exemplo.com.br
#   jenkins.exemplo.com.br
#   vpn.exemplo.com.br
#   webmail-antigo.exemplo.com.br

Every publicly trusted TLS certificate lands in an append-only log (RFC 6962). An internal hostname with a public certificate is a published hostname.

What tends to come back from that query at a mid-sized company is always from the same family: a staging environment, an old admin panel, a VPN concentrator, a continuous integration server, a webmail nobody ever shut down. Those are exactly the assets that rarely make it into a pentest scope, because the inventory feeding that scope usually comes from team memory rather than from a query against what is already public.

Fingerprinting: how you find everyone running the same product

The second half of reconnaissance is not scanning, it is querying. Public scan databases (T1596.005) have already swept the entire IPv4 space and keep the result indexed. The attacker does not need to generate any traffic, they run a search. And the search is not 'port 443 open', it is 'this specific installation of this specific product'.

Three fingerprints carry that. The first is the favicon hash: Shodan indexes the http.favicon.hash filter, computed with MurmurHash3 over the base64-encoded icon, so a product that serves its own default favicon stays identifiable even behind a fully customized login page. The second is the TLS fingerprint, exposed through the ssl.jarm filter, which identifies the server by how it answers the handshake. The third is FoxIO's JA4+ suite, which extended the JA3 idea to TLS client (JA4), server response (JA4S), HTTP client (JA4H) and X509 certificate (JA4X), sorting ciphers and extensions precisely to defeat the manipulations that used to break JA3.

python

# Favicon hash in the exact format Shodan indexes: MurmurHash3 over the
# base64-encoded icon. Identifies a product behind a fully custom login page.

import codecs
import mmh3
import requests

response = requests.get("https://exemplo.com.br/favicon.ico", timeout=10)
b64 = codecs.encode(response.content, "base64")
print(mmh3.hash(b64))

# With the hash in hand, one query returns every host on the internet
# serving the same icon. No scanning traffic required:
#
#   shodan search 'http.favicon.hash:-1234567890'
#   shodan search 'ssl.jarm:<tls server fingerprint>'

The favicon, the TLS stack and the certificate identify the product even when the page never mentions its name.

The side effect is what matters. When a critical CVE lands for product X, the list of exposed instances of product X does not need to be built: it already exists, indexed, one query away. Leaving the product name off the page does not help, because the icon, the TLS stack and the certificate identify it on their own.

Diagram showing a scanner matching a favicon hash, a TLS fingerprint and a certificate signature against an indexed grid of internet hosts — Favicon hash, TLS fingerprint and certificate all converge on the same result: the list of who runs a given product is ready before the CVE is published.

From scan to exploit, the window has shrunk

This is the link that closes the argument. We wrote here on 18 August about CVE-2026-59310, the unauthenticated RCE in VMware vCenter: Broadcom published the advisory on 29 July 2026 and five days later there was already mass exploitation, with 361 compromised IP addresses across 47 countries. Five days is not enough time to develop, test and distribute an exploit from scratch. It is enough time to take a target list that already existed and run the exploit against it.

That is why the practical patch deadline for edge products, meaning VPN, hypervisor, CI/CD server and management console, is counted in days rather than in quarterly maintenance cycles. The reconnaissance had already been done before the flaw was public. Once it goes public, all that is left is execution.

The good news is that reconnaissance is the only phase of the chain you can observe before anything happens, and it leaves a trace in your own log.

text

# Illustrative access log excerpt. Not a real incident: this is the pattern
# that shows up on any exposed perimeter, every single day.

203.0.113.44 - - [19/Aug/2026:03:14:02 +0000] "GET /.env HTTP/1.1" 404 162
203.0.113.44 - - [19/Aug/2026:03:14:02 +0000] "GET /.git/config HTTP/1.1" 404 162
203.0.113.44 - - [19/Aug/2026:03:14:03 +0000] "GET /actuator/env HTTP/1.1" 404 162
203.0.113.44 - - [19/Aug/2026:03:14:03 +0000] "GET /server-status HTTP/1.1" 403 199
203.0.113.44 - - [19/Aug/2026:03:14:04 +0000] "GET /favicon.ico HTTP/1.1" 200 4286
203.0.113.44 - - [19/Aug/2026:03:14:05 +0000] "GET /login HTTP/1.1" 200 8921

Wordlist scanning (T1595.003) in practice: six requests in three seconds, each probing a known path belonging to a different product. The two 200 responses at the end are what the scanner wants, one identifies the product and the other confirms there is an authentication panel.

Blocking every scanner is not feasible and is not the goal. The useful signal is the change in character: generic port scanning is constant background noise, but a burst of 404s against paths specific to the stack you actually run is directed reconnaissance, and it is usually the earliest event a response team can catch.

How to respond to mass reconnaissance

Treat external inventory as a continuous process, not an annual spreadsheet: query the Certificate Transparency logs for your own domain and treat a new hostname as a scope change
Treat issuing a public certificate as publishing: anything that must stay private should not carry a public CA certificate with its real name in the SAN field
Fingerprint yourself first: run the same favicon hash, ssl.jarm and banner queries against your own IP ranges and see what the world already sees
Prioritise patching by exposure, not by CVSS alone: a 7.5 on an internet-reachable panel carries more real risk than a 9.8 on a service that only exists on the internal network
Shorten the window for edge products: VPN, hypervisor, CI/CD and management consoles need deadlines in days, with an emergency process rehearsed before you need it
Monitor directed reconnaissance, not raw volume: alert on bursts against paths specific to your stack, not on the total count of blocked requests

A pentest starts where reconnaissance starts

A test that starts from a target list handed over by the client has already skipped the first phase of the real attack. The attacker gets no list, they build their own, and the most expensive findings live precisely in the gap between the two lists: the staging subdomain holding production data, the old panel nobody remembered, the service stood up for a project that ended and never came down. That is why the first deliverable in our engagements is usually the inventory, not the finding.

The 44% figure is not about attack volume, it is about order of operations. Mapping now happens before the target is chosen. 'Nobody would attack us' has stopped describing how the target gets picked, because at this phase nobody is picking.

← Back to blog