Haxoris Wiki

ISR08: Information Leakage

How ISR08: Information Leakage works

Information leakage is sensitive data reaching people or places it should not through the estate’s own internal channels. It lives in the places work accumulates: an internal Git server, a wiki page written during an outage, a ticket attachment, a logon script on NETLOGON, an SCCM package, a DNS server that answers AXFR to anyone, an SNMP agent still on community string public, and the pile of disks and printers waiting by the loading dock. Nothing is broken in these systems. Each is doing exactly what it was configured to do, for an audience wider than the data deserves.

Leakage survives because it is a side effect of convenience and nothing alerts on it. A password pasted into a runbook makes the next deployment work; a zone transfer left open makes a secondary easier to build; a laptop put in a cupboard is a logistics problem, not a security ticket. After initial access the payoff is disproportionate: the attacker skips discovery and phishing entirely, reading a credential out of a file or a target map out of a zone dump, with the roles conveniently written into the hostnames. Permissions on the share that holds the file belong to the Overly Permissive File Shares page, encryption of the data itself to the Unencrypted Data At Rest And Backups page, and alerting on the outbound copy to the Missing Data Exfiltration Alerting page. The three chapters below take one disclosure channel each: Secrets In Internal Repositories And Scripts, Internal DNS Zone Transfer And Enumeration, and Insecure Media Disposal And Decommissioning.

Keywords: information leakage, hardcoded credentials, secret scanning, dns zone transfer, null session enumeration, data remanence

Examples/Proof

  • Secret sweep of a mirrored repository
    • Mirror an internal Git project and scan the commit graph rather than the checkout. A credential deleted from the working tree but still present in history, and still authenticating, is the finding.
  • Zone transfer from an unauthorised host
    • Run dig AXFR lab.internal against the internal DNS server from a user VLAN. A returned record set, instead of “Transfer failed”, proves no transfer ACL exists.
  • Anonymous enumeration of a domain controller
    • rpcclient with a null session and an unauthenticated ldapsearch. A returned account list, especially with populated description fields, is a leak before any credential is used.
  • Read-back on media staged for disposal
    • Attach a sampled disk read-only and pipe a sample through strings. Any recoverable hostname, file name or key material means sanitisation did not happen.

Detection and Monitoring

  • Secret-scanner findings per repository
    • Pre-receive hook and scheduled scan counters; a repository whose historical finding count never falls means findings are closed without the credential being rotated.
  • DNS transfer requests
    • DNS analytic or query logging filtered on QTYPE AXFR and IXFR; any request from a source that is not a listed secondary is an incident, not a tuning exercise.
  • Disposal reconciliation gap
    • Assets marked retired in the CMDB versus per-serial certificate lines returned by the disposal vendor; any non-zero difference means media is unaccounted for.

How to fix and prevent ISR08: Information Leakage

  1. Rotate what is already exposed before closing the channel
    • Cleaning a repository or a share does not invalidate copies taken earlier. Treat every discovered secret as burned from the moment it is found.
  2. Move secrets out of files that people and processes can read
    • Broker them at runtime through a vault, a managed identity or a gMSA so the script holds a reference, not a value. Partial: the broker token becomes the next thing to protect.
  3. Restrict bulk-read channels to named peers
    • Zone transfers to listed secondaries only, SNMPv3 authPriv in place of v1 and v2c, null sessions and anonymous LDAP binds disabled on servers and appliances.
  4. Make verified sanitisation a gate on asset retirement
    • No asset leaves the site without a record naming its serial, method and verification result. Full-disk encryption with destroyed escrow keys is the cheapest route for both spinning and solid-state media.
  5. Scan the stores continuously rather than at test time
    • Pre-receive scanning plus a scheduled crawl of shares, wikis, ticket attachments and deployment packages. An annual review misses the window that matters.

Prevention Checklist

  • No credential appears in a repository working tree, commit history, wiki page or deployment package
  • Zone transfers are refused from every host that is not a listed secondary, on forward and reverse zones alike
  • SNMP v1 and v2c, SMB null sessions and anonymous LDAP binds are disabled across internal servers and appliances
  • Every retired asset carries a sanitisation record naming its serial, method and verification result

In this section

Last updated

References