Adaptive Fingerprinting: HTTP-Basma's Multi-Stage Probing for Granular Server Differentiation

Related Work

This section reviews some of the notable prior work in HTTP fingerprinting.

Documentation — Internals

HTTP-Basma's algorithm's core idea centers on sending 8 specially crafted HTTP requests with different requirements to solicit different responses from the server. Once the server response is retrieved, the HTTP status line is surgically dissected for all elements and encoded optimally. Additionally, select headers from the server response are checked for encoding as well.

The terms HTTP verb and method are used synonymously throughout this document.

HTTP Requests / Probes

Setting the Request-Line. The default setup only includes the headers specified in each probe — the corresponding HTTP server responses are documented in the HTTP Responses section. All requests are sent independently of each other, without reusing the same socket; the DNS cache is cleared between every request.

GET / HTTP/1.1
Host: <example.com>

GET / HTTP/4.2
Host: <example.com>

GET /<wAs49YmHZ0PSFKGo> HTTP/1.1
Host: <example.com>

<MBBVEIIEXE> / HTTP/1.1
Host: <example.com>

get / HTTP/1.1
Host: <example.com>

GET / HTTP/1.1
Host: <example.com>
Accept-Encoding: aes128gcm, br, <grease_A>, compress, deflate, exi, <grease_B>, gzip, pack200-gzip, x-compress, x-gzip, zstd, identity

GET / HTTP/1.1
Host: <example.com>
Accept-Encoding: <grease_A>, compress, deflate, <grease_B>, x-compress, zstd, br

OPTIONS / HTTP/1.1
Host: <example.com>

HTTP Responses

Following each request, the server's response is analyzed to extract specific headers and their values. This extracted data undergoes further processing — dissection and encoding — to generate a reversible fingerprint. If a request fails, whether due to no server response or any other reason, the resulting fingerprint for that probe is a sequence of all zeros.

Status-Line Fingerprint 4 bytes

For P1–P5 and P8 probes, the HTTP Status-Line (a.k.a. the Start-Line) attributes are parsed and encoded. Given a response like:

HTTP/1.1 200 OK

the Status-Line consists of three octet sequences separated by a space, ending with CRLF:

<HTTP-Version><SP><Status-Code><SP><Reason-Phrase>\r\n

The Reason-Phrase is optional, per the grammar *( HTAB / SP / VCHAR / obs-text ).

HTTP-Version Fingerprint 1 byte

The HTTP-Version is encoded as two hex characters: the first encodes the protocol-name casing (HTTP=1, http=2, Http=3, other casing=4, missing/malformed=0), and the second encodes the version number (0.8=1, 0.9=2, 1.0=3, 1.1=4, ≥2.0=7, 1.>1=8, 0.<8=9, missing/malformed=0).

Status-Code Fingerprint 1 byte

1. Per RFC, the Status-Code is a 3-digit code.
2. It is checked against a curated list of 102 known/standardized status codes; if found, the fingerprint is the list index + 1, in hexadecimal. Otherwise it is set to ff.
3. If the Status-Code is missing or not 3 digits, the fingerprint is 00.
4. A status code of 302 in a line like HTTP/1.1 302.1 is treated as valid — only the leading 302 is matched. This is a deliberate design decision.

HTTP-Reason Fingerprint 2 bytes

Handling the HTTP-Reason requires a nuanced approach with specific design decisions that may intentionally deviate from strict RFC standards for practical reasons.

1. The algorithm first successfully matches HTTP-Version and Status-Code, then uses flexible parsing for the reason phrase — strict adherence to the standard status-line format would cause probing checks to fail against many real-world responses with minor discrepancies. This is exercised via: ^HTTP/\d\.\d \d{3}([^]*) (case-insensitive).
2. If the HTTP-Reason is empty, the fingerprint is 0000.
3. If not empty, and it contains any character outside the restricted achars set (obs-text / SP·VCHAR / HTAB), the fingerprint is tagged 0001 (Status-Code followed by SP) or 0002 (otherwise).
4. Otherwise, the HTTP-Reason is hashed with FNV-1a and the upper two bytes of the hash are taken as the fingerprint.

FNV-1a was chosen for its simplicity, speed, small hash size, and collision resistance. Scans of the top 1 million Majestic websites found no collisions from truncating to the upper two bytes, and no collisions between real hash values and the reserved tags 0001/0002.

P3 / P4 Probes — Reason-Phrase Exception

Some servers echo the generated resource string (P3) or the rejected verb (P4) back into the Reason-Phrase to signal absence/prohibition. In these cases the echoed string is stripped from the Reason-Phrase before the FNV-1a hash is applied.

P3 examples — ~451 of the top-million Majestic servers exhibit this behaviour (generated resource string underlined in the original data):

P4 examples — ~163 of the top-million Majestic servers exhibit this behaviour (generated verb underlined in the original data):

Content-Length & Transfer-Encoding Fingerprint (C-L_T-E) 1 byte

With probes P2–P5 and P8, the algorithm looks for the Content-Length header first; if absent, it falls back to Transfer-Encoding. Computation depends on the Status-Line first passing validation.

1. If the Status-Line fails validation, the fingerprint is 99.
2. If neither header exists: fingerprint is 00 if the body is empty, otherwise 1 + encode_length(size), where length encodes as 0 (=0), 1 (=1), or 2 (>1).
3. If Content-Length exists: fingerprint = encode_name(cl_name) | encode_length(value), where the name-casing digit is 2=Content-Length, 3=content-length, 4=Content-length, 5=content-Length, 6=any other casing that lowercases to content-length.
4. If Transfer-Encoding with value "chunked" exists: fingerprint = encode_name(te_name) | encode_length(body size), where the name-casing digit is 7=Transfer-Encoding, 8=transfer-encoding, 9=Transfer-encoding, a=transfer-Encoding, b=any other casing.

Strict-Transport-Security (HSTS) Header Fingerprint 1 byte

For probe P1, the HSTS header is fingerprinted in detail. It signals that a site must only be accessed over HTTPS, e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. If the Status-Line is invalid the fingerprint is 99; if the header is absent, it is 00. Otherwise, only the first 7 bits are used, bit-encoding these attributes (all occurrences accounted for):

If the bitset is all zero (HSTS present with no attributes) the fingerprint is set to ff.

Content-Encoding (CE) Header Fingerprint 1 byte

For probes P6 and P7, the Content-Encoding response header is fingerprinted against the compression algorithms offered in Accept-Encoding (the 13-item A-E_List: aes128gcm, br, <grease_1>, compress, deflate, exi, <grease_2>, gzip, pack200-gzip, x-compress, x-gzip, zstd, identity). Invalid Status-Line → 99; header absent → 00. All occurrences are accounted for. Bit layout:

Allow, Access-Control-Allow-Methods & Public Headers Fingerprint (AAP) 3 bytes

In probe P7, the response is examined for Allow, Access-Control-Allow-Methods (ACAM), and Public headers (collectively AACAMP). Allowed verbs across every occurrence of these headers are collected, bit-encoded, normalized, and FNV-1a hashed — producing a 3-byte fingerprint: AAP_FP = <1-byte bitset+count><2-byte FNV-1a hash>. Invalid Status-Line → 999999.

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Allow: OPTIONS,GET,HEAD,Trace
Allow: POST
Public: POST, TRACE

1. Collect & sort verbs per header type: Allow = {GET, HEAD, OPTIONS, POST, Trace}; ACAM = {GET, OPTIONS, POST}; Public = {POST, TRACE}.
2. Concatenate in order Allow → ACAM → Public: GETHEADOPTIONSPOSTTraceGETOPTIONSPOSTPOSTTRACE
3. FNV-1a hash, take upper two bytes: 0xd02f8e3f → d02f (or 0000 if no verbs exist).

The 1-byte bitset+count prefix: bit 0 = Allow header exists, bit 1 = ACAM exists, bit 2 = Public exists, bits 3–7 = total verb count across all headers (capped at 31). For the example above this is 01001111 = 4f.

Connection Header Fingerprint (Cnx_FP) 2 bytes

For probes P2, P3, P4, P5 and P7, a 2-byte bit-encoded fingerprint tracks whether the Connection header value is Keep-Alive or Close (checked case-insensitively). Every occurrence is registered, even where a server sends the header more than once with conflicting values (e.g. Connection: keep-alive, close or a repeated header). Format: Cnx_FP = <1-byte keep-alive bitset><1-byte close bitset> — each byte uses its first 5 bits, one per probe.

Verbosus Fingerprint 38 bytes

The verbosus fingerprint is a 38-byte (76-character) string: 01[0-9A-Fa-f]{74}. The initial byte, "01," indicates the hash version, while the subsequent 37 bytes contain the combined fingerprints from all probes (P1–P8) and the Connection fingerprint (Cnx_FP). Version "02" is reserved for the Pacto fingerprint and cannot be reused.

Using the HTTP-Basma tool against example.com:

HTTPBasma.exe --domain example.com --port 80

Dissected:

P1: 140a85e400   P2: 1420958a22   P3: 142494d622   P4: 1320958a22
P5: 1420958a22   P6: 08           P7: 00           P8: 144d9e7f22000000
Cn: 1b04

The tool can emit CSV/JSON with the full dissection: fingerprint (p1_fp…), status line (p1_sl…), and raw response headers (p1_rh…) per probe, plus an experimental response-header fingerprint per probe (p1_rh_fp…, see Tool). In CSV/JSON output, P6/P7/P8 are represented as p6f_fp, p6l_fp, and p7a_fp respectively.

Pacto Fingerprint 32 bytes

For example.com, the Pacto fingerprint is:

The leading 02 marks it as a Pacto fingerprint. The remaining 15 bytes are the first 15 bytes of the SHA-256 hash of the verbosus fingerprint excluding its version byte — i.e. SHA-256 of 140a85e4001420958a22142494d6221320958a221420958a220800144d9e7f220000001b04, truncated to 15 bytes, then prefixed with 02.

If verbosus_fp is all zeros, pacto_fp is likewise set to all zeros.

Tool — HTTP-Basma

HTTP-Basma is a C++ tool developed to showcase the practicality and viability of this algorithm. It leverages Chilkat's library for all HTTP socket interactions and other supporting classes. The tool includes a demangler feature that can dissect and reverse the verbosus fuzzy-hash into a comprehensive JSON object.

Some tool output uses slightly different probe labels, but the underlying order is consistent: P1→P1, P2→P2, P3→P3, P4→P4, P5→P5, P6→P6F, P7→P6L, P8→P7a.

When requesting a given domain/IP, results can be saved to a CSV or JSON file with detailed information about server response headers and each probe's fingerprint. The tool supports HTTP redirects (enabled by default).

Experimental response-header fingerprint

An experimental algorithm fingerprints the full set of response headers (for comparison purposes), used for the p1_rh_fp…p8_rh_fp columns:

1. Collect all response headers except Connection: Keep-Alive, Connection: Close, and any header starting with X- (checked case-insensitively).
2. Save all unique header names into a vector.
3. Sort the vector alphabetically.
4. Concatenate all sorted header names into one string.
5. FNV-1a hash the string and take the full 32-bit hash as the fingerprint.
6. If no headers are present, the fingerprint is zero.

Date: Wed, 19 Mar 2025 15:02:53 GMT
Content-Type: text/html;charset=UTF-8
Cache-Control: max-age=1
Connection: keep-alive
X-Powered-By: ASP.net
Content-Length: 0
Sever: Microsoft-IIS/10.0

Sorted, concatenated string: "Cache-ControlContent-LengthContent-TypeDateSever" → FNV-1a → df0062c6

The Demangler

The tool's demangler (-i / --demangle_json) takes a verbosus fingerprint and reconstructs the attributes of each probe as a JSON object. To reverse FNV-1a hashes back into human-readable values, it consults two local lookup databases — options.csv (allowed HTTP methods) and status_line_db.csv (status-line reason phrases) — both compiled from a scan of the top 1 million Majestic websites. If either file is missing, the corresponding hash-reversal feature is automatically disabled.

Demangling the verbosus fingerprint for example.com:

The Comparator Option

The comparator (-C / --compare) compares two verbosus fingerprints and prints the differences across each probe's major components.

HTTPBasma.exe --compare 01140a85e40014514bd522142494d622144d9e7f221420958a220800140a85e4202931de1609,01140a85e40014514bd522142494d622144d9e7f221420958a220800140a85e42029e4a01609

< FPrnt-1 Vs. FPrnt-2 >
[ P1 ] [ P2 ] [ P3 ] [ P4 ] [ P5 ] [ P6F ] [ P6L ] [ P7a ] {Allow Header(s) Hash}
allow header: 31de != e4a0

The diff isolates a mismatch in the hash component of the P7a (Allow-header) probe.

Scanning a List of Domains

For batch scanning of domains, IPs, or URLs, supply the list via -f / --file and choose an output format with -c/--csv or -j/--json (one is required). Scanning runs sequentially by default; add -P/--parallel to parallelize.

• Each domain must be on its own line; lines starting with ;, //, or # are skipped.
• -p/--port or -s/--ssl apply the same port/SSL setting to every domain in the file.
• Port and SSL can instead be inferred per-domain from its URL: an https prefix sets SSL and port 443; the default port is 80 otherwise; a trailing colon sets an explicit port (e.g. https://www.nohereorthere.com:8083 → SSL on, port 8083). The same applies to -d/--domain.

Experimentation

For experimentation, we scanned the top 1 million Majestic websites (986,910 reachable sites) as well as several malware C&C servers and frameworks, from February 2024 to late March 2024 — server fingerprints may have since changed.

Observations

• Amazon.com and similar servers return varying response-header sets across identical requests — likely CDN/load-balancer intermediaries injecting request-specific headers (e.g. a Cloudflare cache miss adds X-Cache: Miss from cloudfront). Standalone servers keep a consistent header set.
• Header-name casing can change across requests — observed for connection, server, content-type, and date, sometimes returned fully lowercase.
• The presence of the Connection header is inconsistent across repeated queries to the same server.
• Per spec, a 405 Method Not Allowed response should include an Allow header listing supported methods — thousands of servers fail to do so.

C&C RAT Frameworks Fingerprints

Top 1 Million Majestic Websites

All requests sent over port 80, no SSL, follow-redirect enabled.

Top 10 Fingerprints (Top 1-Million Majestic Websites)

Some Interesting Content-Encoding Values

Values seen across the top 1 million Majestic websites that deviate from the standard, highlighting a lack of uniform adherence.

Some Interesting Options Allow Header Values

P8 (OPTIONS) elicited unusual Allow-header values that either don't follow standard comma-separated syntax or are rarely seen — not all servers adhere to the specification. Of particular interest: servers responding with an empty Allow header, signalling the resource currently accepts no HTTP methods.

Access-Control-Allow-Methods — interesting values

One notable example returned the literal value true and, in a separate response, leaked an origin URL (https://eu-app.contentstack.com) directly into the header value.

Public header — interesting values

Status-Line Reason Phrases

A sample of the distinct status-line reason phrases observed — approximately 680 unique phrases were returned in total across the servers analyzed:

Conclusion

HTTP fingerprinting a server to generate a specific impression for identification is an ad-hoc approach of trial and error. However, creating a truly effective fingerprint — one that's reversible, modular, shareable, compact, and optimized — requires sophisticated techniques like bit-encoding, hashing, and data transformation. The HTTP-Basma verbosus fingerprint format is the first algorithm to successfully achieve these objectives.

This paper showcased HTTP-Basma's practical application and feasibility by successfully grouping fingerprints into clusters based on server configurations and behaviours, validated against both the top one million Majestic websites and malicious C&C servers.

HTTP-Basma has limitations, including vulnerability to false positives and false negatives. A minor alteration — such as replacing a status-line reason phrase — can change the fingerprint for an otherwise-identical server; depending on interpretation, that evasion technique itself constitutes an identity change requiring a new fingerprint. Inconsistencies in whether a server returns the Connection header across different execution times also produce different fingerprints.

Bibliography

1. Kotarak, A. (2003, May 23). WebServerFP-Source.zip. Retrieved May 14, 2026, from PACKET STORM: packetstorm.news/files/id/31157
2. Lee, D. W. (2001). HMAP: A Technique and Tool For Remote Identification of HTTP Servers. University of California, Computer Science. Davis: Computer Security Lab. Retrieved May 14, 2026, from seclab.cs.ucdavis.edu
3. Ruef, M. (2007, December 6). httprecon project — advanced web server fingerprinting. Retrieved May 14, 2026, from computec.ch: computec.ch/projekte/httprecon
4. Shah, S. (2004, May 19). An Introduction to HTTP fingerprinting. Retrieved May 14, 2026, from Net Square: net-square.com/httprint_paper