Detection Rules — Inkognito Russian VPN Phishing & Brand-Impersonation Infrastructure

Campaign: Inkognito-Russian-VPN-Phishing-185.221.196.118-20260516 Date: 2026-05-16 Author: The Hunters Ledger License: CC BY 4.0 Reference: https://the-hunters-ledger.com/reports/inkognito-russian-vpn-phishing-185-221-196-118-20260516/

Detection Coverage Summary

Scope note: Inkognito (UTA-2026-009) is a web-application fraud operation — there are no PE binaries. Detection coverage is entirely at the network, DNS, proxy, and web-content-inspection layers. YARA rules target static web assets (JS bundle, favicon SVG) scraped from the live operator infrastructure. This file does NOT duplicate Cluster A (BellaMain) or Cluster C (Rhadamanthys) detection content from the 2026-05-15 multi-cluster report.

Detection vs Hunting: Detection rules are high-fidelity and evasion-resilient — safe to alert on. Hunting rules are broader, for scoping and threat-hunting — expect to review the hits.

⛔ Retraction, 2026-08-21. Two rules originally published in this file, one Sigma and one Suricata, both keyed on the kittenx 404 decommission tombstone, have been withdrawn. Base-rate testing showed the tombstone is VKontakte’s default server banner rather than an operator artifact. Both are struck through in place below, and both are excluded from the rule counts in the table above. Do not deploy them, and remove them if you already have.

Highest-confidence anchors:

• The wildcarded *.inklens.ru brand-impersonation subdomain query, re-anchored from a static 25-subdomain list to the parent zone so it now covers the operator’s full (467+) and still-growing brand-impersonation inventory rather than only the subset enumerated during this investigation (Sigma Hunting, retiered 2026-09-09: the rewrite closed the enumerated-list weakness but the rule still anchors on nothing but the domain literal itself, which is Hunting per the tiering rubric, not Detection).
• The INK VPN JS-bundle and favicon YARA rules, re-anchored to a brand/API-string combination and a hash-or-string hybrid respectively, so both survive a routine Vite rebuild rather than depending only on one captured build’s exact bytes or hash (YARA Detection).

Atomics routed to the IOC feed: 12 of the original file’s rule-objects (1 YARA, 5 Sigma, 6 Suricata) each keyed solely on a hardcoded IP, domain, file hash, or verification-ID literal, with no behavioral qualifier surviving the literal’s removal. All of these values were already present in inkognito-russian-vpn-phishing-185-221-196-118-20260516-iocs.json from the original analysis — no feed edits were required. See Coverage Gaps for the full retirement list and reasoning.

YARA Rules

Deployment note: These YARA rules target static web assets served by the Inkognito operator — a JavaScript application bundle and an SVG favicon. They are NOT PE-targeting rules (there are no Inkognito binaries). Deploy in web-proxy DLP pipelines, threat-hunting tools that scan cached web content, or endpoint DLP systems that inspect downloaded files. Memory-scanner deployment is not applicable.

Detection Rules

Inkognito INK VPN JS Bundle (Brand/API String Combination)

Tier: Detection Robustness: 2 ATT&CK Coverage: T1036.005 (Masquerading: Match Legitimate Resource Name or Location), T1608.005 (Stage Capabilities: Link Target) Confidence: HIGH Rationale: The original condition required an exact filesize match (== 261587) alongside the string combination — Vite’s content-hashed build filename and exact byte count change on every rebuild, so an exact-size gate is a single-build fingerprint (Robustness 1) despite the string combination looking durable. Re-anchored to a filesize bound instead of exact equality; the 5-of-7 string threshold still requires 5 of the 6 non-build-specific markers (API endpoint paths, brand strings, Russian tagline) when the build-hashed filename itself doesn’t match, so the rule now survives a routine rebuild rather than only the one captured build (SHA256 preserved in meta for reference). False Positives: None known — the required 5-of-6 combination of operator-specific API paths (/api/vpn-hosts, /api/subscriptions), brand strings (INK VPN, Inkognito), and the Russian-language tagline is not plausible in unrelated software. Blind Spots: A full rebrand that changes the API endpoint naming, both brand strings, and the tagline simultaneously would evade; the rule targets the on-disk/cached JS asset, not a memory-only variant. Validation: Fetch the current INK VPN production bundle from the operator’s infrastructure — must match 5 of 7; an unrelated JavaScript bundle must NOT fire. Deployment: Web-proxy DLP pipeline; threat-hunting tool HTTP-response body scanning; endpoint DLP on downloaded-file content.

/*
   Yara Rule Set
   Identifier: Inkognito Fraud Operation — Web Asset Detection
   Author: The Hunters Ledger
   Source: https://the-hunters-ledger.com/
   License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/
*/

rule MALW_Inkognito_JSBundle_VPN_SPA
{
    meta:
        description = "Detects the Inkognito INK VPN Vite/React SPA production JavaScript bundle via a combination of hardcoded API endpoint paths, operator brand strings, and a Russian-language tagline. Anchored on 5 of 6 non-build-specific markers so the rule survives routine Vite rebuilds (the content-hashed output filename changes every build) rather than only the exact bytes of one captured sample."
        license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
        author = "The Hunters Ledger"
        reference = "https://the-hunters-ledger.com/hunting-detections/inkognito-russian-vpn-phishing-185-221-196-118-20260516-detections/"
        date = "2026-05-16"
        hash1 = "8a69fe67a7e9908aa1248c632ffd784033fc4dc613d0b5589279ccc62f717978"
        family = "Inkognito-FraudOperation"
        malware_type = "Web Application Fraud Infrastructure"
        campaign = "Inkognito-Russian-VPN-Phishing-185.221.196.118-20260516"
        id = "44286d43-385c-5646-afcc-1d855cb8dd6b"
    strings:
        $api_auth     = "/api/auth/login" ascii
        $api_vpn      = "/api/vpn-hosts" ascii
        $api_sub      = "/api/subscriptions" ascii
        $brand_ink    = "INK VPN" ascii
        $brand_inkogn = "Inkognito" ascii
        $bundle_name  = "index-CoeWw2zM.js" ascii
        $tagline_ru   = "\xd0\x9d\xd0\xb0\xd0\xb4\xd0\xb5\xd0\xb6\xd0\xbd\xd1\x8b\xd0\xb9 VPN \xd0\xbe\xd1\x82 Inkognito" ascii
    condition:
        filesize < 700KB and
        5 of ($api_auth, $api_vpn, $api_sub, $brand_ink, $brand_inkogn, $bundle_name, $tagline_ru)
}

Inkognito INK VPN Favicon SVG (Hash-or-Brand-String)

Tier: Detection Robustness: 2 ATT&CK Coverage: T1036.005 (Masquerading: Match Legitimate Resource Name or Location) Confidence: HIGH (hash branch) / MODERATE (string branch) Rationale: The condition is a hash-OR-strings hybrid: the exact-hash clause alone would be Robustness 0 (a pure hash, already carried in the IOC feed), but the rule’s or branch requires three brand markers (Inkognito, INK, inkconnect) simultaneously and remains functional even with the hash clause removed — so the rule as a whole survives the underlying sample changing, unlike a pure-hash rule. False Positives: LOW — the three-marker AND-combination in the string branch is unlikely outside Inkognito-controlled content; the hash branch has no FP risk by construction. Blind Spots: A favicon that drops all three brand markers while changing content would evade the string branch (the hash branch would also miss it, being sample-specific). Validation: Scan the analyzed favicon or any modified variant retaining the three brand markers — must match; an unrelated SVG file must NOT fire. Deployment: Web-proxy DLP pipeline; endpoint DLP on downloaded-file hash/content.

import "hash"

rule MALW_Inkognito_Favicon_SVG
{
    meta:
        description = "Detects the INK VPN favicon SVG (inkconnect.ru/favicon.svg) by exact SHA256 hash OR, for modified variants, by the simultaneous presence of three Inkognito brand markers in the SVG content."
        license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
        author = "The Hunters Ledger"
        reference = "https://the-hunters-ledger.com/hunting-detections/inkognito-russian-vpn-phishing-185-221-196-118-20260516-detections/"
        date = "2026-05-16"
        hash1 = "53b3515fda56dbbd1f8071a9ef3dc3be80cb7994df22ce8afc2e79147e899b70"
        family = "Inkognito-FraudOperation"
        malware_type = "Web Application Fraud Infrastructure"
        campaign = "Inkognito-Russian-VPN-Phishing-185.221.196.118-20260516"
        id = "60df7df5-6a62-58de-816b-8e7db27ba08d"
    strings:
        $svg_open     = "<svg" ascii
        $brand_inkogn = "Inkognito" ascii nocase
        $brand_ink    = "INK" ascii
        $inkconnect   = "inkconnect" ascii nocase
    condition:
        filesize < 100KB and
        $svg_open at 0 and
        (
            hash.sha256(0, filesize) == "53b3515fda56dbbd1f8071a9ef3dc3be80cb7994df22ce8afc2e79147e899b70"
            or
            ($brand_inkogn and $brand_ink and $inkconnect)
        )
}

Sigma Rules

Deployment note: Sigma rules in this section target DNS resolver logs and web-proxy logs. No Sysmon process-creation rules are included — Inkognito has no on-host malware execution surface. Translate rules to your SIEM query language using pySigma or Sigma CLI before deployment.

Hunting Rules

Inkognito Brand-Impersonation Subdomain DNS Query (Wildcard)

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1566.002 (Phishing: Spearphishing Link), T1684.001 (Impersonation), T1036.005 (Match Legitimate Resource Name or Location) Confidence: HIGH Rationale: The original rule enumerated 25 specific brand-impersonation subdomains via QueryName|contains — a static list that could never catch the remaining 440+ subdomains in the operator’s inventory, let alone future additions (Robustness 1). Re-anchored to a wildcard on the parent zone (QueryName|endswith: '.inklens.ru') with a filter excluding the operator’s own enumerated DevOps subdomains, so the rule now covers the entire brand-impersonation platform regardless of which specific brand name is queried — a technique-level chokepoint (the platform itself), not an enumerated list. False Positives: Security researchers or threat hunters explicitly querying inklens.ru subdomains for investigation purposes; automated scanner infrastructure probing known-bad domain lists. Blind Spots: Misses entirely if the operator abandons inklens.ru for a new phishing platform domain (an infrastructure-rotation event that would require a rule refresh regardless of rule design); the DevOps filter could itself be evaded if the operator names a new brand-impersonation subdomain with one of the filtered prefixes (currently no evidence of this). Validation: Query any subdomain of inklens.ru (e.g., a brand-impersonation subdomain) — must match; a query for one of the filtered operator DevOps subdomains (e.g., staging-agent.inklens.ru) must NOT fire. Deployment: Windows DNS debug logs (Event ID 5158 / DNS Analytic), Zeek dns.log, Sysmon Event ID 22, Cloudflare Gateway, Cisco Umbrella.

title: Inkognito Brand-Impersonation Subdomain DNS Query
id: 4a7b2e1d-8f3c-4a5b-9c0d-6e2f1a8b3c7d
status: experimental
description: >-
  Detects DNS queries for any subdomain of inklens.ru, the Inkognito fraud
  operator's (UTA-2026-009) dedicated brand-impersonation phishing platform.
  The operator pre-stages 467+ subdomains targeting Wells Fargo, Tencent,
  AnyDesk, Outlook Web Access 2013, Jenkins, Asana, Tele2, and other
  enterprise/consumer brands, and adds new subdomains continuously.
  Anchored on the wildcard parent zone rather than an enumerated subdomain
  list so the rule survives new subdomain additions; a filter excludes the
  operator's own internal DevOps tooling subdomains (argo-cd, redis-commander,
  staging/uat/prod-prefixed hosts) hosted on the same zone.
references:
    - https://the-hunters-ledger.com/hunting-detections/inkognito-russian-vpn-phishing-185-221-196-118-20260516-detections/
author: The Hunters Ledger
date: 2026-05-16
tags:
    - attack.initial-access
    - attack.stealth
    - attack.t1566.002
    - attack.t1036.005
    - detection.emerging-threats
    - stp.1
logsource:
    category: dns_query
    product: windows
detection:
    selection_inklens_subdomain:
        QueryName|endswith: '.inklens.ru'
    filter_operator_devops:
        QueryName|startswith:
            - 'argo-cd.'
            - 'redis-commander.'
            - 'redisinsight.'
            - 'staging-agent.'
            - 'staging-analytic.'
            - 'uat-aka.'
            - 'uat-dashboard.'
            - 'prod-aka.'
            - 'integration-cicd.'
            - 'app-admin.'
            - 'vfemea-admin.'
    condition: selection_inklens_subdomain and not filter_operator_devops
falsepositives:
    - Security researchers or threat hunters explicitly querying inklens.ru subdomains for investigation purposes
    - Automated scanner infrastructure probing known-bad domain lists
level: high

Inkognito Operator KittenX Decommission Tombstone HTTP Response — RETRACTED 2026-08-21

⛔ This rule has been cut. Do not deploy it, and remove it if you already have.

The rule selected on sc-status: 404 and sc-bytes: 148 only. The Server: kittenx check had already been dropped from it because Sigma’s proxy logsource category does not expose arbitrary response headers, which left the rule matching any 404 carrying a 148-byte body. Measured against a 142.7M-document web-scan corpus, that pair returns 175,432 matches in a 30-day window.

The companion Suricata rule below, which could inspect the header, is retracted for a separate and more fundamental reason: Server: kittenx is VKontakte’s web server banner. Of 7,083 observations of that header in 30 days, 6,844 (96.6%) sit on AS47541, VK’s own ASN, and of the 84 hits on the full three-signal triplet, 83 (98.8%) are VK. The tombstone is a hosting-platform default that two Russian-hosted operator domains inherited, not an operator-deployed fingerprint.

No tightening recovers this. The only discriminating element was the Server header, and that header is the platform’s. Excluding VK leaves nothing to match, and both observed domains are decommissioned. The two domains remain in the campaign IOC feed as domain indicators, which is their correct home.

Coverage cost of the cut: none. Neither rule ever matched operator-specific behaviour.

The campaign report stated this exact failure mode as assumption (b) — “treated as an operator-deployed fingerprint, not a default from a third-party hosting platform … if it were a platform-level default … the cross-domain attribution weight would drop significantly.” That assumption has now been tested and invalidated. The other two operator fingerprints, the custom X-Admin-Token header and the Yandex Webmaster ID, were base-rate tested at the same time and both returned zero with a passing control, so they stand.

Suricata Signatures

Deployment note: All HTTP rules use the http application-layer keyword with destination port any per the workflow standard — Suricata matches by protocol recognition, not port number. Local sid placeholders (9001xxx) are unique within this file; the published-feed generator maps them to stable feed SIDs and is not run by this file.

Detection Rules

Inkognito KittenX Decommission Tombstone HTTP Response — RETRACTED 2026-08-21

⛔ Cut, published SID withdrawn. Do not deploy; remove if already deployed.

This rule matched Server: kittenx + status 404 + Content-Length: 148 and carried “False Positives: None known”. That claim was never base-rate tested and is false. kittenx is VKontakte’s web server banner: 6,844 of 7,083 observations in 30 days sit on VK’s own AS47541, and 83 of the 84 full-triplet hits are VK. The rule fires $EXTERNAL_NET -> $HOME_NET on to_client, so in any subscriber environment it alerts whenever a user loads VK-hosted content that 404s.

See the retracted Sigma rule above for the full measurement and the reasoning on why no tightening recovers it.

Hunting Rules

Inkognito Custom X-Admin-Token Header in HTTP Request

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1071.001 (Application Layer Protocol: Web Protocols), T1583.004 (Server) Confidence: MODERATE Rationale: X-Admin-Token is not defined by any public RFC and is the Inkognito operator’s own admin-API authentication primitive, giving it real durability (survives domain rotation) — but the header name itself could plausibly be independently invented by another developer, an acknowledged non-trivial false-positive path rather than a rare one. That combination (durable but not rare-FP) places it in Hunting rather than Detection. False Positives: Internally-developed web applications that independently use X-Admin-Token as a custom auth header name; developer workstations testing API endpoints. Deployment: Suricata IDS/IPS at perimeter or inline; tune to external-only traffic (exclude RFC1918 destinations) before considering promotion to alerting.

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"THL HUNT Inkognito Custom X-Admin-Token Header in HTTP Request (Admin API Auth Primitive)"; flow:established,to_server; http.header; content:"X-Admin-Token"; nocase; threshold:type limit,track by_src,count 1,seconds 3600; classtype:trojan-activity; sid:9001003; rev:2; metadata:author The_Hunters_Ledger, date 2026-05-16, reference https://the-hunters-ledger.com/hunting-detections/inkognito-russian-vpn-phishing-185-221-196-118-20260516-detections/;)

Inkognito X-Admin-Token in CORS Allow-Headers Response

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1071.001 (Application Layer Protocol: Web Protocols), T1583.004 (Server) Confidence: MODERATE Rationale: Same underlying artifact as the request-header rule, observed instead in the CORS Access-Control-Allow-Headers response context — slightly more deliberate (server-controlled CORS configuration rather than any client request) but the header-name collision risk is identical, so it carries the same tier and robustness. False Positives: Internally-developed web applications that independently expose X-Admin-Token in their own CORS configuration; security research or authorized assessment of Inkognito-controlled domains. Deployment: Suricata IDS/IPS at perimeter; requires inline traffic inspection for HTTPS (TLS inspection or plain HTTP).

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT Inkognito X-Admin-Token in CORS Allow-Headers Response (Admin API Auth Primitive)"; flow:established,to_client; http.header; content:"Access-Control-Allow-Headers"; nocase; content:"X-Admin-Token"; nocase; threshold:type limit,track by_src,count 1,seconds 3600; classtype:trojan-activity; sid:9001004; rev:2; metadata:author The_Hunters_Ledger, date 2026-05-16, reference https://the-hunters-ledger.com/hunting-detections/inkognito-russian-vpn-phishing-185-221-196-118-20260516-detections/;)

Coverage Gaps

Atomics routed to the IOC feed (12 of the original file’s 20 rule-objects). Every rule below keyed solely on a hardcoded IP, domain, file hash, or verification-ID literal, with no behavioral qualifier surviving the literal’s removal — per the tiering rubric’s routing test, these are IOC-feed entries, not rules. All underlying values were already present in inkognito-russian-vpn-phishing-185-221-196-118-20260516-iocs.json from the original analysis — no feed edits were required.

• YARA — MALW_Inkognito_BrandLogo_PNG (1 rule). The rule’s only operative condition was hash.sha256(0, filesize) == <value>; the PNG-magic-byte check adds no discriminating power (matches any valid PNG). Per the YARA hashes-are-IOCs workflow, a rule whose detection is only a file hash belongs in the IOC feed, not a YARA rule. The hash (d1ae63c928fd07d51cf79c5165e4431765201ca04a2bee3c309dc00092c4de7c) is already carried in the feed’s file_hashes.sha256 with full context.
• Sigma — sigma_inkognito_dns_operator_domains (1 rule). A 7-domain / 6-suffix OR-list (inkconnect.ru, inklens.ru, inklens.co.uk, cryptone.bot, bikaf.ru, unloki.ru, bigass.monster, 00000xtrading.ru) with no shared naming convention or technique-level invariant to re-anchor to — unlike the brand-impersonation subdomains, these are deliberately un-linked brand names, so there is no wildcard salvage path. All domains are already BLOCK-listed in the feed’s network_indicators.domains.
• Sigma — sigma_inkognito_proxy_xadmintoken (1 rule). The original selection used cs-headers/sc-headers fields, which are not part of Sigma’s standard proxy-category field set (W3C/Squid-derived proxy taxonomies expose connection metadata, not arbitrary header dumps) — a selection on a non-existent field can never match. The underlying signal (custom X-Admin-Token header) is genuinely durable and is preserved both in the feed’s operator_fingerprints.custom_http_headers and as a Suricata Hunting-tier rule pair (network-layer header inspection is well-supported via Suricata’s http.header sticky buffer, unlike the Sigma proxy-log field set).
• Sigma — sigma_inkognito_webcontent_yandex_verification (1 rule). Response-BODY content matching (sc-body|contains) is not a standard proxy-category field either — and, more fundamentally, this indicator is an OSINT infrastructure pivot (search Censys/Shodan/Google for pages carrying the Yandex Webmaster verification ID), not something enterprise DNS/proxy logs observe from victim browsing activity. This is the same category of indicator as the Google Search Console TXT records documented below and is now treated consistently with them. The verification ID (98466329) is preserved in the feed’s operator_fingerprints.search_console_verifications.
• Sigma — sigma_inkognito_proxy_inkconnect_api_auth (1 rule). Removing the r-dns|endswith: inkconnect.ru domain anchor leaves only cs-uri-stem|startswith: /api/auth, which is far too generic (matches any web application’s auth endpoint) to stand alone. The domain is already BLOCK-listed in the feed.
• Sigma — sigma_inkognito_dns_cryptone (1 rule). A bare single-domain QueryName|contains: cryptone.bot match. Already BLOCK-listed in the feed.
• Suricata — SIG_Inkognito_Via_Caddy_Operator_IPs (1 rule, SID 9001005). “Via: 1.1 Caddy” alone is common (Caddy is a widely-used legitimate reverse proxy); the rule’s entire discriminating power was the 5-IP source scope (185.221.196.118, 176.124.211.174, 77.239.101.23, 193.46.56.182, 79.137.203.87), functionally equivalent to a pure IP-match rule with decorative content padding. All 5 IPs are already BLOCK-listed in the feed’s network_indicators.ipv4.
• Suricata — SIG_Inkognito_TLS_SNI_Operator_Domains (5 rules, SIDs 9001006–9001010). Each was a bare single-domain TLS SNI match (inkconnect.ru, inklens.ru, inklens.co.uk, cryptone.bot, unloki.ru) with no additional qualifier. All 5 domains are already BLOCK-listed in the feed.

Cut: dead-code Suricata rule (1 rule, SID 9001001 — not an atomic). The original SIG_Inkognito_KittenX_Tombstone_Response section paired two alert rules intended to work together via flowbits: SID 9001001 matched any outbound HTTP GET request and set flowbits:inkognito.kittenx.request with flowbits:noalert (so it never itself alerts), apparently intended to gate SID 9001002’s response check. However, SID 9001002 never checks flowbits:isset,inkognito.kittenx.request — it alerts independently on the full response signature. SID 9001001 as published therefore matched essentially all HTTP GET traffic, set a flag nothing reads, and alerted on nothing: zero detection value, so it was retired rather than kept as a broken rule. SID 9001002, the tombstone-response rule this one was meant to gate, survived that backfill as a Detection-tier rule, but it was itself withdrawn on 2026-08-21 after base-rate testing showed the kittenx tombstone is VKontakte’s default server banner rather than an operator artifact. Neither SID is deployable. The full measurement is in the retracted Suricata rule block above.

Resolved by this backfill: 467+ Subdomain Inventory Partial Coverage. The original Sigma rule enumerated only the 25 highest-value brand-impersonation subdomains documented in the underlying analysis, with a documented gap noting the full operator inventory exceeds 467 and sketching a wildcard alternative. That wildcard has now been implemented as the rule itself (Inkognito Brand-Impersonation Subdomain DNS Query, above) — QueryName|endswith: '.inklens.ru' filtered against the operator’s known DevOps subdomain prefixes — so this gap is closed. If DNS logging in a given environment cannot support endswith wildcard matching, the enumerated-list fallback covers the 25 highest-value brand names documented during the original investigation: wellsfargo, accenture, adyen-no-stripe, asana, tele2, tencent, sina, siri-search, stanley, rafael, anydesk, autodiscover.blog, owa2013, espace-client, swdcdownloads, development-jenkins, signals, connect-pro-portal, democrm, demo-insights, travel, travelid, weatherzone, e-shop, and onlineforms (all .inklens.ru).

Gap: No PE/Binary YARA Rules

Status: Intentional — not a gap in detection methodology.

Inkognito has no PE binary samples. The operator runs a web-application stack (Vite/React SPA, nginx + Caddy reverse-proxy, EspoCRM back-office, Marzban Xray/V2Ray panel). There are no executables, DLLs, shellcode stubs, or malware droppers to write YARA binary patterns for. The two remaining YARA rules in this file target web-asset file types (JavaScript bundle, SVG) — this is the correct coverage posture for a web-application fraud operation.

What would enable binary YARA coverage: Discovery of a PE binary associated with the Inkognito operator (a VPN client installer, a downloader, or a credential-stealer deployed against phishing victims). None were recovered in this investigation.

Gap: Live JARM Hash Not Recovered

Status: Gap — JARM fingerprinting of operator TLS stack not completed.

JARM (https://github.com/salesforce/jarm) produces a deterministic fingerprint of a TLS server’s implementation from its handshake response. The Inkognito operator’s nginx + Caddy stack would produce a distinctive JARM hash recoverable by active probing of the live endpoints (185.221.196.118, 176.124.211.174). A JARM hash provides a passive TLS-layer pivot for surfacing additional operator-controlled servers not linked to the known domain/IP inventory.

What would enable JARM coverage: Active JARM probe of operator IPs 185.221.196.118 and 176.124.211.174. Note that inklens.ru deliberately rejects non-browser TLS clients (tlsv1 alert internal error) — JARM probing of that host may return a rejection fingerprint rather than the full stack JARM. A JARM lookup on inkconnect.ru (Cloudflare-fronted) would return a Cloudflare JARM, not the operator’s backend JARM.

Gap: BEC Burn-Domain WHOIS SOA Monitoring

Status: Partial gap — behavioral indicator documented; automated WHOIS monitoring rule not producible in Sigma/Suricata format.

The operator’s BEC burn-domain WHOIS fingerprint (admin@<domain>.eu SOA email on .eu domains hosted on Stark Industries AS44477/AS209847) is documented in the underlying analysis but cannot be expressed as a standard Sigma or Suricata rule because WHOIS SOA data is not captured in standard enterprise log sources (DNS logs do not include WHOIS SOA fields).

What would enable coverage: Integration with a WHOIS monitoring feed that can alert on new .eu domain registrations where the SOA email matches the admin@*.eu pattern AND the authoritative NS points to Stark Industries IP ranges (193.46.56.0/24, 77.239.101.0/24). This is a proactive threat-intel feed task, not an endpoint/network detection task.

Gap: Search-Console / Webmaster Verification-ID Pivots (Google + Yandex)

Status: Gap — infrastructure pivots documented; no standard Sigma/Suricata rule type applicable.

Three operator-controlled site-verification identifiers are high-value pivots for surfacing additional operator-controlled domains where the operator verified the same account: two Google Search Console TXT records (_Lq_FX-CDt3OmZqq5PNFfmQTZtLSHTNsVkViLTzpTwk for inkconnect.ru, xskfj4k4tX_-enfPvu9WrUiWauHFlbuVmyV7thcjwds for inklens.ru) and one Yandex Webmaster HTML meta-tag verification ID (98466329 for inklens.ru). None are observable in standard enterprise DNS or proxy logs because they are not triggered by victim browsing activity — they are third-party verification artifacts recoverable only by an active OSINT pivot against the verification provider or an internet-wide scan corpus. (The Yandex ID previously had a standalone Sigma rule attempting HTTP-response-body matching; that rule used a non-standard proxy-category field and has been retired in favor of this consistent gap treatment — see the atomics-routed-to-feed list above.)

What would enable coverage: SecurityTrails / Censys TXT-record and HTML-meta-tag reverse-lookup for all three verification strings. New operator domains where the same account is verified would surface as sibling infrastructure.

Gap: CryptOne Fake Exchange — Origin IP Not Recovered

Status: Gap — Cloudflare-fronted origin not demasked.

The CryptOne fake exchange at cryptone.bot is fully Cloudflare-fronted with a Turnstile bot challenge. The operator’s origin IP behind the Cloudflare proxy was not recovered from passive DNS history (domain registered 2026-03-02; Cloudflare fronting in place from first observation). The retired Suricata SNI rule (see atomics list above) fired on the Cloudflare edge, not the operator origin — network-layer detection at the edge is preserved via the IOC feed’s domain BLOCK entry, but a direct-IP block against the true origin is not available.

What would enable coverage: Origin demasking via certificate transparency logs (search for TLS certificates issued to cryptone.bot before Cloudflare fronting was applied — narrow window between the 2026-03-02 registration and first Cloudflare observation), or via HTTP response header fingerprinting that Cloudflare passes through from the origin.

License

Detection rules are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
Free to use, including commercially, with attribution to The Hunters Ledger.