TrickBot DNS-Tunnel Variant — Hunt Pack

FortiGuard Labs published analysis on 2026-07-22 of a 64-bit TrickBot build whose module set is recognisably the historical TrickBot codebase, but whose transport layer has been rewritten. Instead of HTTP POSTs to a C2 web server, the bot smuggles its command channel inside ordinary DNS lookups: command data is XORed with a single-byte key, hex-encoded, chopped into 63-character chunks separated by periods, and appended to an attacker-controlled apex. Responses come back encoded three bytes at a time inside the IPv4 addresses of the DNS answer records, with an index packed into the high bits of the first octet so the bot can reassemble fragments even when a resolver reorders them.

Three packet types carry the protocol: 0x30 (command request), 0x31 (response-size query so the bot can size its buffer) and 0x32 (response data). Measured throughput was roughly 30.7 KB/s, enough to move a 1.2 MB module in about 40 seconds. Persistence is a Windows scheduled task that fires at boot and repeats every five minutes, named to look like a routine software updater by concatenating a randomly chosen %AppData% folder name with the literal string autoupdate # and a random number. The task name and the executable path are stashed in NTFS Alternate Data Streams named $TASK and $FILE. Capability retained from prior builds: module download and execute, execution through rundll32.exe via the Control_RunDLL export, process hollowing, process doppelgänging, command-shell and PowerShell execution through anonymous pipes, and raw shellcode execution in the bot's own memory.

The defensive angle that matters: the atomic indicator surface is deliberately thin. One C2 apex and six sample hashes were published, and the operator can rotate both cheaply. What cannot be rotated cheaply is the shape of the traffic. A host that emits hundreds of 100-plus-character DNS names whose leftmost label is a long run of hex, all under one parent domain, is running a DNS tunnel regardless of which apex it uses today. That signal, plus the five-minute update-shaped scheduled task, is where this pack puts its weight.

Defender priority: if your endpoints can reach an external resolver directly, this channel works and your web proxy never sees it. Force all endpoint DNS through internal forwarders you can log, then run Q2 and Q3 against that log. Everything else in this pack is secondary to closing that egress path.

Hunter notes and decisions

• All four sources verified live and snapshotted to TrickBot-DNSTunnel-Hunt-sources/. No cited source 404'd, and none required dropping.
• No prompt-injection content observed. None of the fetched pages contained text addressed to an automated agent, instructions to fetch further URLs, or claims of authorisation.
• Every source traces to the same origin. Tiers 2 and 3 are reporting on the Fortinet write-up, not independent telemetry. Treat "corroborated" here as "consistently reported", not "independently observed" — which is why nothing in this pack ships at prevent + critical.
• The resolver the sample used was dropped from the indicator set entirely. The vendor report names a well-known public resolver (Google Public DNS) as the tunnel's egress. It appears nowhere in the IOC table, the import CSV or any query, because it is not campaign infrastructure — carrying it as an indicator invites someone to block it, which breaks resolution and stops nothing. The concept it illustrates is preserved as prose in §4 and as the egress audit in Q9.
• The sandbox executable path in the vendor report was discarded. The report shows a task action pointing at a randomly-named binary on a lab drive. That name is generated per-infection and is worthless as an indicator, so it became a behavioural pattern (task-spawned binary in a user-writable path) rather than a filename IOC.
• No campaign IPs were published, and none were invented. The response-side IPv4 addresses in this protocol are encoded data, not infrastructure — blocking them would be meaningless.

Attack chain

Hunt hypotheses (fidelity order)

Why nothing here is prevent + critical: the six hashes and the apex come from one Tier-1 vendor. The other three outlets restate that vendor rather than contributing independent telemetry. Per the two-independent-source rule, they ship at prevent + high. Promote to critical only after your own tenant corroborates a hit.

On the resolver the sample used: the vendor report names a well-known public resolver (Google Public DNS) as the tunnel's egress. That address is deliberately absent from this table and from the import CSV in §10, because it is not campaign infrastructure and treating it as an indicator is actively harmful — blocking it breaks name resolution for anything legitimately pointed at it and stops nothing, since the operator can reach the same C2 through any recursive resolver. The defensive lesson is about the path, not the address: if an endpoint can reach any external resolver directly, this channel works and your web proxy never sees it. That is what Q9 audits and what §13.2 closes.

Run these where Falcon has no event, or where you want a second opinion that does not depend on sensor policy.

7.1 · Windows DNS Server — analytic log

The highest-value log for this threat, and it is off by default. Enable it on your internal forwarders, then look for the two shapes Q2 and Q3 hunt: long names and hex leftmost labels. Event ID 257 (RESPONSE_SUCCESS) and 256 (QUERY_RECEIVED) in Microsoft-Windows-DNSServer/Analytical carry the queried name and the client IP.

wevtutil sl Microsoft-Windows-DNSServer/Analytical /e:true /q:true /ms:1073741824

# then, per forwarder, rank clients by long-name volume
$ev = Get-WinEvent -LogName 'Microsoft-Windows-DNSServer/Analytical' -Oldest -MaxEvents 500000
$ev | ForEach-Object { $x = [xml]$_.ToXml()
      [pscustomobject]@{
        Client = $x.Event.EventData.Data | Where-Object Name -eq 'Source' | Select-Object -Expand '#text'
        Name   = $x.Event.EventData.Data | Where-Object Name -eq 'QNAME'  | Select-Object -Expand '#text' } } |
  Where-Object { $_.Name.Length -gt 100 -or $_.Name -match '^[0-9a-fA-F]{40,63}\.' } |
  Group-Object Client | Sort-Object Count -Descending | Select-Object -First 25 Count, Name

7.2 · Scheduled task sweep — the naming scheme

Get-ScheduledTask | Where-Object { $_.TaskName -match 'autoupdate\s?#\s?\d+' } |
  Select-Object TaskPath, TaskName, @{n='Exec';e={ $_.Actions.Execute }},
                @{n='Args';e={ $_.Actions.Arguments }},
                @{n='Repeat';e={ $_.Triggers.Repetition.Interval }} | Format-List

# broader: any task repeating every 5 minutes that also runs at boot
Get-ScheduledTask | Where-Object {
    $_.Triggers.Repetition.Interval -eq 'PT5M' -and $_.Triggers.CimClass.CimClassName -match 'BootTrigger'
} | Select-Object TaskPath, TaskName, @{n='Exec';e={ $_.Actions.Execute }}

7.3 · NTFS Alternate Data Stream sweep (covers the Falcon gap)

The loader hides its task name and its own path in ADS named $TASK and $FILE. Falcon does not publish stream names, so this sweep is the only mechanical way to see step 3 of the chain.

$roots = @($env:APPDATA, $env:LOCALAPPDATA, $env:ProgramData, "$env:SystemRoot\Temp")
foreach ($r in $roots) {
  Get-ChildItem -Path $r -Recurse -File -Force -ErrorAction SilentlyContinue |
    ForEach-Object {
      Get-Item $_.FullName -Stream * -ErrorAction SilentlyContinue |
        Where-Object { $_.Stream -in @('$TASK','$FILE') } |
        Select-Object FileName, Stream, Length
    }
}
# decode a hit (read-only, no execution):
# [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String((Get-Content -Path FILEPATH -Stream '$TASK' -Raw)))

7.4 · Perimeter and resolver posture check

• Firewall: report every source IP that sent UDP/53 or TCP/53 to anything other than your approved forwarders over the last 30 days. Any endpoint on that list can run this tunnel today.
• Resolver: report the top 50 parent domains by distinct subdomain count per client. A DNS tunnel is a near-perfect outlier on that metric — a normal client resolves a handful of names under a given parent, a tunnelled one resolves thousands.
• Resolver: report clients whose mean query-name length sits far above the fleet median. This survives apex rotation and encoding changes.

No query below carries an in-query time filter. Set the search window in the Falcon console instead — a function call on the right of a comparison does not parse in CQL filter context. Start at 7 days for Q1/Q4/Q8/Q10 and 24 hours for the volume queries (Q2/Q3/Q9) until you know your data rate.

// HUNT: TrickBot DNS-tunnel C2 apex lookup
// MITRE: T1071.004 | CONF: high  FP: low  COST: low
// REQUIRES: DnsRequest
// FALSE POSITIVES: malware-analysis VMs and researcher workstations detonating the sample
#event_simpleName=/^DnsRequest$/
| DomainName=/(^|\.)westurn\.in$/i
| groupBy([aid, ComputerName, ContextBaseFileName, DomainName], function=count(as=Lookups), limit=200)
| table([ComputerName, aid, ContextBaseFileName, DomainName, Lookups])

// HUNT: Hex-encoded oversized DNS labels (0x30/0x31/0x32 tunnel encoding)
// MITRE: T1132.001, T1071.004 | CONF: medium  FP: medium  COST: medium
// REQUIRES: DnsRequest
// FALSE POSITIVES: AV/EDR reputation lookups and anti-spam services that hex-hash into the leftmost label
// TUNING: exclude your reputation providers once baselined, e.g. append
//         | !DomainName=/\.REPLACE_WITH_REPUTATION_VENDOR_DOMAIN$/i
#event_simpleName=/^DnsRequest$/
| DomainName=/^[0-9a-f]{40,63}\./i
| length(DomainName, as=QueryLen)
| QueryLen > 60
| groupBy([aid, ComputerName, ContextBaseFileName], function=[count(as=HexLookups), count(DomainName, distinct=true, as=UniqueLabels), selectLast([DomainName])], limit=200)
| HexLookups > 20
| table([ComputerName, aid, ContextBaseFileName, HexLookups, UniqueLabels, DomainName])

// HUNT: DNS query-length + volume anomaly per host (tunnel transport)
// MITRE: T1572, T1071.004 | CONF: medium  FP: medium  COST: medium
// REQUIRES: DnsRequest
// FALSE POSITIVES: Azure/Office device-registration names, CDN edge names, telemetry SDKs
// TUNING: baseline first, then exclude the benign long-name parents that dominate, e.g. append
//         | !DomainName=/\.(azureedge|akamaiedge|trafficmanager|REPLACE_WITH_YOUR_CDN)\.net$/i
#event_simpleName=/^DnsRequest$/
| length(DomainName, as=QueryLen)
| QueryLen > 100
| groupBy([aid, ComputerName, ContextBaseFileName], function=[count(as=LongLookups), count(DomainName, distinct=true, as=DistinctNames)], limit=500)
| LongLookups > 200
| table([ComputerName, aid, ContextBaseFileName, LongLookups, DistinctNames])

// HUNT: Scheduled task registered with the " autoupdate #" naming scheme
// MITRE: T1053.005, T1036 | CONF: high  FP: low  COST: low
// REQUIRES: ScheduledTaskRegistered
// FALSE POSITIVES: none observed - this is not a Microsoft or common-vendor convention
#event_simpleName=/^ScheduledTaskRegistered$/
| TaskName=/autoupdate\s?#\s?\d+/i
| table([ComputerName, aid, UserName, TaskName, TaskExecutable, TaskAuthor])

// HUNT: schtasks.exe creating a task that repeats every 5 minutes
// MITRE: T1053.005 | CONF: medium  FP: medium  COST: low
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: RMM/patch agents and installers create minute-interval tasks routinely
// TUNING: exclude your management agents by parent, e.g. append
//         | !ParentBaseFileName=/^REPLACE_WITH_RMM_AGENT\.exe$/i
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^schtasks(\.exe)?$/i
| CommandLine=/\/create/i
| CommandLine=/\/sc\s+minute/i
| CommandLine=/\/mo\s+5(\s|$)/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine])

// HUNT: rundll32.exe invoking Control_RunDLL on a DLL outside System32
// MITRE: T1218.011, T1105 | CONF: medium  FP: medium  COST: low
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: third-party control-panel applets and vendor installers use this export legitimately
// TUNING: after the System32/SysWOW64 cut, exclude named vendor applets, e.g. append
//         | !CommandLine=/REPLACE_WITH_VENDOR_APPLET_NAME/i
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| FileName=/^rundll32(\.exe)?$/i
| CommandLine=/Control_RunDLL/i
| !CommandLine=/\\(System32|SysWOW64)\\/i
| table([ComputerName, aid, UserName, ParentBaseFileName, CommandLine, SHA256HashData])

// HUNT: Scheduled-task-spawned binary in a user-writable path (loader relaunch)
// MITRE: T1053.005, T1036, T1055.012 | CONF: medium  FP: medium  COST: medium
// REQUIRES: ProcessRollup2
// FALSE POSITIVES: signed per-user updaters (browser, chat client) run from AppData under the task host
// TUNING: exclude known-good per-user updaters by name, e.g. append
//         | !FileName=/^(GoogleUpdate|MicrosoftEdgeUpdate|REPLACE_WITH_APPROVED_UPDATER)\.exe$/i
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2/
| ParentBaseFileName=/^(svchost|taskeng|taskhostw)\.exe$/i
| ImageFileName=/\\(Users|ProgramData|Windows\\Temp)\\/i
| groupBy([aid, ComputerName, UserName, ImageFileName, SHA256HashData], function=count(as=Launches), limit=500)
| table([ComputerName, aid, UserName, ImageFileName, SHA256HashData, Launches])

// HUNT: Same host shows hex-label DNS AND an autoupdate-style task registration
// MITRE: T1071.004, T1053.005 | CONF: high  FP: low  COST: medium
// REQUIRES: DnsRequest, ScheduledTaskRegistered
// FALSE POSITIVES: effectively none - both independent halves must land on the same aid
#event_simpleName=/DnsRequest|ScheduledTaskRegistered/
| selfJoinFilter(field=[aid], where=[
    {DomainName=/^[0-9a-f]{40,63}\./i},
    {TaskName=/autoupdate\s?#\s?\d+/i}
  ])
| table([@timestamp, ComputerName, aid, DomainName, TaskName, TaskExecutable])

// HUNT: Endpoint talking DNS directly to an external resolver (tunnel egress path)
// MITRE: T1572, T1071.004 | CONF: medium  FP: medium  COST: medium
// REQUIRES: NetworkConnectIP4
// FALSE POSITIVES: split-tunnel VPN, roaming laptops off-network, agents with hard-coded public resolvers
// TUNING: exclude your approved forwarders and roaming fleet, e.g. append
//         | !RemoteAddressIP4=/^REPLACE_WITH_APPROVED_RESOLVERS$/
#event_simpleName=/^NetworkConnectIP4$/
| RemotePort=53
| !cidr(RemoteAddressIP4, subnet=["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"])
| groupBy([aid, ComputerName, ContextBaseFileName, RemoteAddressIP4], function=count(as=Conns), limit=500)
| Conns > 500
| table([ComputerName, aid, ContextBaseFileName, RemoteAddressIP4, Conns])

// HUNT: Published FortiGuard TrickBot DNS-tunnel sample hashes on disk or in execution
// MITRE: T1204, T1027 | CONF: high  FP: low  COST: low
// REQUIRES: ProcessRollup2, PeFileWritten
// FALSE POSITIVES: none - exact hash match
#event_simpleName=/ProcessRollup2|SyntheticProcessRollup2|PeFileWritten/
| in(SHA256HashData, values=[
    "df527a5c2fbde43816cd02f4cd49eee4bb82fb4a3c7045021360888c7d504c98",
    "6c677eb2b3ffd288083c59a13d7bb712d4754af61a5563873f76c440962346f4",
    "105f652e6b8f31c371f2385877e43b6772aff5d3168d5d4635f8a1fcbb321421",
    "33c331ededbf8ee9829895424423ce3fd17e359d2e784fcbce396aacff458cf5",
    "3b19a82e1354ac14a3da7c840cbdd0ce50db38432d78e767b36f08e45024c23d",
    "bf80245ba792992fbfe24abac33f8fd66f24cdeb5f0f21cfdf45a29d107c8d3b"])
| table([@timestamp, ComputerName, aid, UserName, FileName, ImageFileName, SHA256HashData, CommandLine])

Do not build a Custom IOA for the DNS shape. Custom IOAs match on process and file attributes, not on aggregate DNS name statistics, and a per-query regex IOA on DomainName would fire thousands of times a day on reputation lookups. Q2, Q3 and Q8 belong in Scheduled Searches with an aggregation window, not in the IOA engine. Q8 is the right first promotion.

13.1 · Disable browser DoH (GPO-backed registry, all three browsers)

# Run as SYSTEM via GPO startup script, Intune, or your RMM. Machine-wide policy keys.
# 1. Microsoft Edge
New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Edge' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Edge' -Name 'DnsOverHttpsMode' -Value 'off' -Type String

# 2. Google Chrome
New-Item -Path 'HKLM:\SOFTWARE\Policies\Google\Chrome' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Google\Chrome' -Name 'DnsOverHttpsMode' -Value 'off' -Type String

# 3. Mozilla Firefox - 5 = "off by user choice cannot be overridden by rollout"
New-Item -Path 'HKLM:\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS' -Name 'Enabled' -Value 0 -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Mozilla\Firefox\DNSOverHTTPS' -Name 'Locked'  -Value 1 -Type DWord

# Verify
'Edge','Chrome' | ForEach-Object {
  $p = if ($_ -eq 'Edge') { 'HKLM:\SOFTWARE\Policies\Microsoft\Edge' } else { 'HKLM:\SOFTWARE\Policies\Google\Chrome' }
  [pscustomobject]@{ Browser = $_; DoH = (Get-ItemProperty -Path $p -Name DnsOverHttpsMode -ErrorAction SilentlyContinue).DnsOverHttpsMode }
}

13.2 · Pin endpoints to approved forwarders and block external 53 locally

# Defence in depth behind the perimeter ACL. Replace the two forwarder IPs first.
$approved = @('REPLACE_WITH_FORWARDER_1','REPLACE_WITH_FORWARDER_2')

Get-NetAdapter -Physical | Where-Object Status -eq 'Up' | ForEach-Object {
  Set-DnsClientServerAddress -InterfaceIndex $_.ifIndex -ServerAddresses $approved
}

# Block outbound 53 to anything else, from any process, on the domain profile.
New-NetFirewallRule -DisplayName 'Block external DNS (UDP)' -Direction Outbound -Action Block `
  -Protocol UDP -RemotePort 53 -Profile Domain -RemoteAddress Any -Enabled True
New-NetFirewallRule -DisplayName 'Allow approved DNS (UDP)' -Direction Outbound -Action Allow `
  -Protocol UDP -RemotePort 53 -Profile Domain -RemoteAddress $approved -Enabled True
New-NetFirewallRule -DisplayName 'Block external DNS (TCP)' -Direction Outbound -Action Block `
  -Protocol TCP -RemotePort 53 -Profile Domain -RemoteAddress Any -Enabled True
New-NetFirewallRule -DisplayName 'Allow approved DNS (TCP)' -Direction Outbound -Action Allow `
  -Protocol TCP -RemotePort 53 -Profile Domain -RemoteAddress $approved -Enabled True

# Allow rules win over block rules in Windows Firewall, so ordering is not a concern here.
# Verify
Get-NetFirewallRule -DisplayName '*DNS*' | Select-Object DisplayName, Direction, Action, Enabled

13.3 · ASR rules — prevalence gate and injection constraints

# Start in Audit (2). Review Defender operational logs for 7 days, then switch the value to 1 (Block).
$rules = @{
  '01443614-cd74-433a-b99e-2ecdc07bfc25' = 2   # Block untrusted/unprevalent executables
  'd1e49aac-8f56-4280-b9ba-993a6d77406c' = 2   # Block process creations from PSExec and WMI
  '9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2' = 2   # Block credential stealing from lsass.exe
  '56a863a9-875e-4185-98a7-b882c64b5ce5' = 2   # Block abuse of exploited vulnerable signed drivers
}
foreach ($id in $rules.Keys) {
  Add-MpPreference -AttackSurfaceReductionRules_Ids $id -AttackSurfaceReductionRules_Actions $rules[$id]
}

# Verify current state
$p = Get-MpPreference
for ($i = 0; $i -lt $p.AttackSurfaceReductionRules_Ids.Count; $i++) {
  [pscustomobject]@{ Rule = $p.AttackSurfaceReductionRules_Ids[$i]
                     Action = $p.AttackSurfaceReductionRules_Actions[$i] }
}

13.4 · Enable DNS Server analytic logging on internal forwarders

# Run on each DNS server. The channel is disabled by default and is the single
# most useful log for tunnel detection.
wevtutil sl Microsoft-Windows-DNSServer/Analytical /e:false
wevtutil sl Microsoft-Windows-DNSServer/Analytical /ms:1073741824 /rt:false
wevtutil sl Microsoft-Windows-DNSServer/Analytical /e:true

# Confirm it is collecting
wevtutil gl Microsoft-Windows-DNSServer/Analytical
(Get-WinEvent -ListLog 'Microsoft-Windows-DNSServer/Analytical').RecordCount

# Point your SIEM forwarder at the channel, then build the two standing reports:
#   - distinct subdomain count per parent domain, per client
#   - mean and p99 query-name length, per client

13.5 · Fleet sweep — persistence and ADS in one pass

# Read-only. Safe to run fleet-wide via RMM. Emits one object per finding.
$findings = New-Object System.Collections.Generic.List[object]

Get-ScheduledTask | Where-Object { $_.TaskName -match 'autoupdate\s?#\s?\d+' } | ForEach-Object {
  $findings.Add([pscustomobject]@{
    Host = $env:COMPUTERNAME; Type = 'TASK-NAME'
    Detail = "$($_.TaskPath)$($_.TaskName)"; Exec = $_.Actions.Execute })
}

Get-ScheduledTask | Where-Object { $_.Triggers.Repetition.Interval -eq 'PT5M' } | ForEach-Object {
  $exe = $_.Actions.Execute
  if ($exe -and $exe -match '\\(Users|ProgramData|Temp)\\') {
    $findings.Add([pscustomobject]@{
      Host = $env:COMPUTERNAME; Type = 'TASK-5MIN-USERPATH'
      Detail = "$($_.TaskPath)$($_.TaskName)"; Exec = $exe })
  }
}

@($env:APPDATA, $env:LOCALAPPDATA, $env:ProgramData, "$env:SystemRoot\Temp") | ForEach-Object {
  Get-ChildItem -Path $_ -Recurse -File -Force -ErrorAction SilentlyContinue |
    ForEach-Object {
      Get-Item $_.FullName -Stream * -ErrorAction SilentlyContinue |
        Where-Object { $_.Stream -in @('$TASK','$FILE') } | ForEach-Object {
          $findings.Add([pscustomobject]@{
            Host = $env:COMPUTERNAME; Type = 'ADS'
            Detail = $_.FileName; Exec = $_.Stream })
        }
    }
}

$findings | ConvertTo-Json -Compress

Validation: the gates in §11 are the promotion path for this map. Nothing above moves from Partial to Good without G3 (a real baseline) and G8 (seven silent days in Monitor). The two GAP rows are honest gaps, not to-do items — ADS stream names and in-process shellcode have no Falcon event to query, so they are covered by the native sweeps in §7.3 and §13.5 and by the sensor's own prevention layer, and this pack does not pretend otherwise.

Source snapshots. The verbatim fetched text of every cited primary and corroborating source is stored alongside this pack in TrickBot-DNSTunnel-Hunt-sources/ (01-fortinet.txt, 02-infosecurity.txt, 03-hackread.txt, 04-cybersecuritynews.txt). Every atomic indicator shipped in §10 traces mechanically back to those files.