SANS intern demonstrates Kibana anomaly detection via HTTP charset headers

1. Executive summary

A SANS ISC guest diary by intern Jeffray Spence describes using Elastic Kibana field statistics on DShield honeypot data to isolate a scanning campaign by its HTTP language headers. Filtering on the Accept-Charset value GBK,utf-8;q=0.7,*;q=0.3 and on Accept-Language values beginning zh-CN,zh;q=0.9 reduced roughly 960,000 honeypot records to 31 requests from six IP addresses in Canadian ISP AS-7456, all requesting the same six paths. No CVE, malware, exploit or named threat actor is identified, and no CISA KEV entry applies. The risk to EMEA financial services is low: this is commodity internet-wide web scanning, and the value to a defender is the detection method (language-header clustering), not the campaign. The advisory is single-sourced to one SANS ISC diary and the indicators are honeypot-observed only.

2. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

3. Technical analysis & attack chain

The item describes an analysis technique applied to honeypot traffic, not an intrusion. The confirmed sequence is:

1. A DShield honeypot (Raspberry Pi) running Cowrie and a web honeypot fed roughly 960,000 records into an Elastic SIEM over slightly more than three weeks. Only 15,271 records triggered any of four detection rules; the remainder triggered none.
2. The analyst selected the "Sonicwall Appliance Login Page" rule (41 distinct source hosts) as a working subset, then used Kibana Discover field statistics to find fields with low distinct-value counts (Distribution of 2 to 6) rather than fields common to every record.
3. Two fields stood out: http.request.connection (values "Close" and "close", a casing artefact of log parsing) and http.request.mime_type, which carried the Accept-Charset string GBK,utf-8;q=0.7,*;q=0.3. GBK is the extension of the GB 2312 character set for Simplified Chinese.
4. Filtering on that Accept-Charset string across both the webhoneypot and Cowrie indices returned 47 requests. Field statistics on that subset showed two User-Agents and two source.geo.region_name values: Beijing and Ontario.
5. Filtering to Ontario returned three records, all from AS-7456. Pivoting to source.geo.as.number: 7456 and repeating the distribution analysis surfaced Accept-Language values of zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 (90.3% of 31 requests) and zh-CN,zh;q=0.83 (9.7%).
6. The 31 matching requests came from six IP addresses in AS-7456 and requested the same endpoint set: /cgi-bin/login, /config.json, /sitemap.xml, /robots.txt, /favicon.ico and /. The analyst characterises this as an automated campaign.

The requested paths are generic discovery targets: a CGI login endpoint, a configuration file, standard crawler files and the site root. The source gives no response codes, no evidence of successful exploitation, no payload and no post-compromise activity. The only capability demonstrated is automated HTTP scanning with a fixed header set.

The source also lists four domains seen in source.domain values from AS-7456: leheedu[.]cn, mail.,brossy.com[.]cn (a malformed value as printed), mail.brossy.com[.]cn and tzrhxln[.]cn. The analyst calls tzrhxln[.]cn a "suspect high entropy domain". No resolution data, registration data or malware association is given for any of them.

Confidence caveats. Every fact above rests on a single source: one SANS ISC guest diary written by a student intern, based on one honeypot over three weeks. The geo-IP attribution to Ontario and to AS-7456 is the analyst's own enrichment and is not independently corroborated. The source itself notes that geolocation is weak in a VPS-enabled world and prefers AS number. No actor is named and none should be inferred: a Chinese language preference in a header is a configurable client setting, not proof of operator location, and the source does not claim otherwise. Treat the campaign as unattributed commodity scanning.

4. Mitigation & containment

P1 (within 24h)

• Search web-proxy, WAF and web-server logs for the exact Accept-Charset string GBK,utf-8;q=0.7,*;q=0.3 and for Accept-Language values matching zh-CN,zh;q=0.9* and zh-CN,zh;q=0.83. Where these co-occur with requests to /cgi-bin/login or /config.json, pull the full request and response and check for a 200 on either path.
• Confirm that /config.json is not served on any internet-facing host. A static 404 or 403 is the expected state; a 200 is a finding to escalate.
• Block the six source IPs at the edge only after confirming they are not corporate egress or a known partner. They are honeypot-observed scanners and may be shared VPS addresses.

P2 (within 72h)

• Add the language-header correlation to SIEM detection (rule in §6) so the technique runs continuously rather than as a one-off query. The source's method maps directly onto Elastic: field statistics on http.request.mime_type and http.request.accept-language, filtered to low distinct-value counts.
• Review whether the organisation's own internet-facing estate exposes /cgi-bin/ paths at all. Where a legacy CGI login exists, retire it or place it behind the WAF with an explicit deny for non-allowlisted source geographies, accepting that geo blocking is weak against VPS egress.
• If the four .cn domains appear in DNS or proxy logs, treat as reconnaissance and review any session that followed.

P3 (within 7 days)

• Extend the same low-cardinality field analysis to other log indices (VPN, mail, API gateways) where optional client headers are retained. The technique depends on logging full HTTP headers; confirm header capture is enabled and retained long enough to query.
• Document the header values as detection content, not as blocklist entries, since the same scanner set will rotate addresses within the AS.

No vendor fix applies: no product vulnerability is described.

5. Indicators of compromise

No malware indicators are present. The atomic indicators below are honeypot-observed scanner addresses and domains, single-sourced to the SANS ISC diary. Verify before enforcing.

ipv4  165[.]154.36.91
ipv4  165[.]154.29.93
ipv4  165[.]154.11.140
ipv4  165[.]154.120.226
ipv4  165[.]154.33.72
ipv4  165[.]154.182.221
domain  tzrhxln[.]cn
domain  leheedu[.]cn
domain  mail.brossy.com[.]cn
asn  AS-7456

Behavioural indicators

6. Detection

The source gives no file artefacts, so a YARA rule is not appropriate. The usable material is HTTP request-header and path content, which suits a Sigma rule against web/proxy logs.

title: Chinese-language HTTP header scanning cluster
id: 7f3c2a91-4d6e-4b8a-9c1f-2e5a0b7d4c33
status: experimental
description: Detects web requests carrying the GBK Accept-Charset string or zh-CN Accept-Language values observed in a DShield honeypot scanning campaign, optionally combined with common discovery paths.
author: Adverse Trace
date: 2026/10/26
references:

  - https://isc.sans.edu/diary/rss/33442
logsource:
  category: webserver
detection:
  selection_charset:
    cs-method: 'GET'
    cs-uri-stem|endswith:

      - '/cgi-bin/login'
      - '/config.json'
      - '/sitemap.xml'
      - '/robots.txt'
      - '/favicon.ico'
  selection_header:
    cs-accept-language|startswith:

      - 'zh-CN,zh;q=0.9'
      - 'zh-CN,zh;q=0.83'
  condition: selection_charset and selection_header
fields:

  - c-ip
  - cs-uri-stem
  - cs-accept-language
falsepositives:

  - Legitimate users or crawlers with Chinese locale settings hitting the same paths
level: low

The Accept-Charset string GBK,utf-8;q=0.7,*;q=0.3 is not a standard field in most web log schemas; where full headers are captured (for example in a proxy or WAF event field), add it as an additional selection on the raw header value and OR it with selection_header. Tune against a week of production traffic before alerting: Chinese-locale clients are legitimate and will match the Accept-Language values on their own.

7. Sources

• Jeffray Spence, SANS ISC Guest Diary, "Looking for a Language [Guest Diary]", https://isc.sans.edu/diary/rss/33442, published 2026-10-26 (diary dated Wed, Oct 21).
• DShield honeypot tooling referenced by the diary: https://github.com/dshield-isc/dshield
• DShield SIEM build referenced by the diary: https://github.com/bruneaug/DShield-SIEM
• Fortinet PSIRT blog on reported FortiGate credential compromise, cited by the diary for context only: https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices

8. Adverse Trace position

Adverse Trace assesses this item as informational: no CVE, no CISA KEV entry, no malware and no named actor, and the only source is a single student-written SANS ISC diary built on one honeypot over three weeks. The scanner addresses and .cn domains are low-confidence, single-sourced and should be verified against your own logs before any block is enforced; the durable value is the detection method, which we will fold into our web-log detection content as the Sigma rule above and tune against client traffic to control false positives from legitimate Chinese-locale users. Clients with internet-facing /cgi-bin/ or /config.json paths should confirm those paths return 404 or 403 within 24 hours and report any 200 response to us.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.