Threat Hunting Playbook

Hunting Adversary Infrastructure
with Silent Push

A hands-on walkthrough for CTI analysts. Follow one Loki Bot C2 domain from a single lookup to a mapped cluster of campaign infrastructure, and pick up five pivot techniques you can run yourself. Built by a Silent Push solutions engineer.

Case study domain   montblancgroup.cfd
Jump to a chapter
Your progress
0/7

The Pivot Map

This is the whole investigation in one view. Start at the seed, then follow each pivot to see what it reveals. Tap any step to read what it does, then jump straight to the full walkthrough below.

SEEDmontblancgroup.cfdOne Loki Bot C2 domain
STEP 01IP PivotPADNS A record reverseHigh confidence
STEP 02ssdeep HashFuzzy body hashHigh confidence
STEP 03body_sha256 + ASN4-signal intersectionHigh confidence
STEP 04WHOIS PivotRegistrar + nshashHigh confidence
STEP 05NSHash PivotPADNS reverse by nshashCorroborative

Start here

Every investigation starts from a single observed indicator. Here it is one Loki Bot command-and-control domain. From this one seed, five pivots reconstruct the wider campaign.

Open the walkthrough
The Full Walkthrough

Silent Push is built on two continuously updated datasets. Understanding which one you are looking at makes every pivot faster and more precise.

DNS Data (Passive Aggressive DNS)

  • Records every DNS answer it sees: IP addresses, nameservers, mail records, and more
  • Builds a full timestamped history of where a domain has pointed, going back years
  • When an actor rotates IPs or changes nameservers, those historical states are preserved and searchable

Web Scan Data

  • Records what the server returns: page title, HTTP headers, favicon hash, TLS fingerprint, and HTML body content
  • These become searchable fingerprints
  • Scan records from months ago stay queryable even after a domain has changed IPs, gone offline, or been taken down

Pivoting

  • Almost every value in Silent Push is a potential link to something else
  • An IP leads to co-hosted domains; a nameserver hash links an actor’s other registrations; an HTML fingerprint finds every site running the same kit
  • Each pivot adds more of the actor’s infrastructure to the picture

WHOIS Data

  • Continuously indexes WHOIS registration records, queryable by any field: registrar, nameserver hash, email, creation date, and more
  • Records are indexed at scale
  • Find every domain an actor registered through the same registrar and nameserver setup in one query, even before those domains are active
  What is Loki Bot?

Loki Bot is a commodity credential stealer. Infected machines send stolen passwords and browser data back to a C2 domain. The domain is the actor's "phone home" address. Because the actor needs it to stay reachable, they invest in infrastructure that rotates and evades blocking. That rotation is exactly what Silent Push records.

Before running any pivot, read the PADNS history. It tells you the full operational story of the domain: which hosting providers the actor used, in what order, and when. That history is permanent. It cannot be scrubbed by the actor rotating to new infrastructure.

Start with a domain lookup

Log into Silent Push and search montblancgroup.cfd in the search bar on the main page. This loads the total view page. Before exploring any tabs, note two fields in particular: NS Diversity and ASN Diversity. These are derived from the Passive Aggressive DNS history and tell you at a glance that this domain changed nameservers multiple times and appeared on more than one hosting provider.

Silent Push Total View for montblancgroup.cfd
The Total View page for the seed domain in Silent Push. Note the risk score, the PADNS infrastructure counts, and the threat-feed history before opening any tab.

Opening the A record history

Click the PADNS tab, which loads the A records. Read the table from oldest to newest. What you are looking at is the IP rotation history: every address the domain resolved to, in sequence, with the exact dates each record was first and last observed.

This is the operational timeline of the campaign. Each provider corresponds to a distinct phase: initial registration and parking, staging on a bulletproof server, proxying behind Cloudflare for the active C2 period, a transitional re-parking phase, and then a new deployment. The actor changed infrastructure multiple times, but Passive Aggressive DNS recorded every state.

Total Viewmontblancgroup.cfd
A (12)
AAAA (7)
CNAME (0)
NS (14)
MX (10)
SOA (434)
TXT (4)
query Equals montblancgroup.cfdANDtype Equals A
CompareBasic Raw Data
Total Results: 6Results on current page: 6
IP AddressFirst SeenLast SeenProvider
162.255.119.2462025-03-122025-09-23Shared hosting
196.251.89.332025-09-242025-09-24cheapy.host, AS401120
188.114.96.32025-09-252025-10-14Cloudflare
172.67.147.2162025-10-142026-03-11Cloudflare
172.234.24.2112026-03-112026-04-22Akamai / Linode
44.192.95.1272026-05-292026-06-15AWS

The 196.251.89.33 entry is notable: it appeared for a single day, at exactly the transition point between parking and the first active phase, and belongs to a known bulletproof hosting ASN. This is the IP to click for the first pivot.

  Why historical IPs matter more than the current one

Both IPs are worth pivoting on, but they work differently. The IP that appeared briefly during the staging phase, 196.251.89.33, belongs to a dedicated server with very few co-tenants, so every domain that touched it is likely part of the same operation. The current AWS IP hosts many more domains, but a PADNS reverse lookup still surfaces campaign infrastructure, you just need to filter by shared attributes like registrar and nameserver rather than treating co-residence alone as confirmation. Passive Aggressive DNS preserves both: the brief early resolution the actor probably considered temporary, and the active deployment running today.

The NS record history tells the same story

Switch to the NS Records sub-tab. Where the A records showed IP rotation, this view shows the nameserver rotation across four distinct configurations over the domain's lifetime. The sequence maps directly to operational phases: registrar defaults while parked, Cloudflare when active, back to registrar defaults when re-parking, then a custom provider for the latest deployment. Each row has a unique nshash, a fingerprint you will pivot on in Chapter 5.

Total Viewmontblancgroup.cfd
A (12)
AAAA (7)
CNAME (0)
NS (14)
MX (10)
SOA (434)
TXT (4)
query Equals montblancgroup.cfdANDtype Equals NS
CompareBasic Raw Data
Total Results: 5Results on current page: 5
NameserversnshashFirst SeenLast Seen
dns1/2.registrar-servers.com12241179c5...2025-03-122025-09-24
isla/matias.ns.cloudflare.combb2045485f...2025-09-252025-10-14
love/woz.ns.cloudflare.comef94264fe1...2025-10-142026-03-11
dns101/102.registrar-servers.comd0edbce840...2026-03-112026-05-29
ns1–4.csof.net8fbcec1929f7b0122d09640a65e76d2a2026-05-29

The first four NS configurations are all generic. Millions of domains share Cloudflare and Namecheap registrar nameservers. The csof.net configuration is specific to a small provider. Note its nshash for Chapter 5.

STEP 01 Enrich the Seed Domain

Start every investigation by pulling a full enrichment on the seed domain. This baseline captures registration metadata, hosting history, DNS records, and the web scan fingerprints Silent Push has collected over time. Every subsequent pivot decision flows from what you find here.

Domain Enrichment / BaselineTotal View Page → montblancgroup.cfd
Domain:     montblancgroup.cfd
Registrar:  Namecheap  (ASN 22612)
Created:    2025-03-11
TLD:        .cfd  (high-abuse zone)
Nameservers: ns1–ns4.csof.net  (recently changed, see Step 6)
Registrar
Namecheap · ASN 22612
Created
2025-03-11 · ~15 months old
Nameservers
ns1–ns4.csof.net · non-default
TLD
.cfd, high-abuse zone
  What to look for in enrichment

The most useful signals at this stage are registrar, TLD, nameserver provider, and domain age relative to when it first appeared in scan data. A recently registered domain on an abuse-prone TLD like .cfd or .shop, pointed at a non-default nameserver, is worth pursuing regardless of any numeric score.

Open the PADNS tab and run a forward A record lookup on the seed. This returns every IP the domain has resolved to over time, with first-seen and last-seen timestamps. Each IP is a potential pivot, but before pivoting on any address, run an NS Diversity check to determine whether the IP is dedicated actor infrastructure or a shared cloud pool.

PADNS / A Record HistoryPADNS Tab → Forward Lookup → A
montblancgroup.cfd  →  Full IP resolution history

  44.192.95.127    AWS us-east-1    current  (2026-05-29 → present)
  172.234.24.211   Linode                    (2026-03-11 → 2026-04-22)
  172.239.57.117   Linode                    (2026-03-11 → 2026-04-22)
  172.67.147.216   Cloudflare CDN            (2025-09-26 → 2026-03-11)
  104.21.63.165    Cloudflare CDN            (2025-09-26 → 2026-03-11)
  188.114.96.3     Cloudflare CDN            (2025-09-25 → 2025-10-14)
  162.255.119.246  Namecheap                 (2025-03-12 → 2025-09-23)
  196.251.89.33    Unknown          ←        (2025-09-24, single observation)

Two IPs stand out: 196.251.89.33, a brief early observation with no obvious owner, and 44.192.95.127, the current AWS address. Run NS Diversity on each to understand what kind of pivot each IP supports.

NS Diversity / Triage Before PivotingNS Diversity Tool → get_host_diversity(ip / netmask=32)
196.251.89.33  →  num_domains: 10      dedicated IP, every co-resident domain
                                        is likely actor-controlled  ✓
44.192.95.127  →  num_domains: 1,848   shared AWS pool, co-residence alone is
                                        not confirmation, but PADNS reverse still
                                        surfaces campaign domains via shared attributes  ✓

The PADNS reverse lookup on 196.251.89.33 returns a clean, small set of co-hosted domains, all within the same campaign window as the seed:

PADNS Reverse / 196.251.89.33PADNS Tab → Reverse Lookup → A
196.251.89.33  →  All domains resolved to this IP:

  montblancgroup.cfd      seed       (2025-09-24)
  sellea-ims.cfd                     (2025-09-24 → 2025-10-14)
  dddotx.shop                        (2025-02-16 → 2025-07-06)
  ddrtot.shop                        (2025-02-16, brief window)
  lubipumps.cam                      (2025-02-16 → 2025-03-04)
  sebel.sbs                          (2025-02-16, brief window)
  taurusfood-com-ua.cfd              (2025-02-16 → 2025-02-22)

Running the same PADNS reverse lookup on the AWS IP 44.192.95.127 returns 100+ co-hosted domains. Most are unrelated, but scanning that list for domains sharing the seed's registrar pattern and TLD surfaces celosiapatroen.shop: registered via Dynadot, pointed at csof.net nameservers, same .shop TLD family. The shared AWS IP is what finds it; the matching attributes are what confirm it. This domain becomes the anchor for the web content pivots in Steps 3 and 4.

DomainTLDIP SourceSignal
montblancgroup.cfd.cfd196.251.89.33 / 44.192.95.127Seed
sellea-ims.cfd.cfd196.251.89.33IP co-resident (dedicated)
dddotx.shop.shop196.251.89.33IP co-resident (dedicated)
ddrtot.shop.shop196.251.89.33IP co-resident (dedicated)
celosiapatroen.shop.shop44.192.95.127Co-hosted + csof.net NS match
  Thread A, 196.251.89.33 staging cluster

The web scan history of montblancgroup.cfd includes a capture from October 2025 when the domain was serving a specific nginx default page titled "This is the default server vhost". Silent Push recorded the ssdeep fuzzy hash of that page body. Use this hash in the Web Search tab to find every other domain running the same server configuration.

SPQL / ssdeep Fuzzy Hash PivotWeb Search Tab → SPQL Query
datasource = ["webscan"] AND html_body_ssdeep = "24:n1wTfr3TuDbltxxtF1lEgZF/DemS14dq41g6AwRoVUzxx:nEXuDjAylDZS14dq4W61Rr"

This returns 7 unique domains, all confirmed members of the 196.251.89.33 staging cluster:

DomainIPFirst ObservedTitle
montblancgroup.cfd188.114.96.22025-09-26This is the default server vhost
sellea-ims.cfd196.251.89.332025-09-26This is the default server vhost
dddotx.shop196.251.89.332025-02-27This is the default server vhost
ddrtot.shop196.251.89.332025-02-25This is the default server vhost
lubipumps.cam196.251.89.332025-02-28This is the default server vhost
sebel.sbs104.21.19.1292025-02-22This is the default server vhost
taurusfood-com-ua.cfd196.251.89.332025-02-18This is the default server vhost
  ssdeep vs exact SHA256

The nginx default page has a consistent structure but minor per-scan byte variations, whitespace, charset declarations, that cause the exact SHA256 to differ between captures. ssdeep tolerates those differences and still matches. Use ssdeep for server config pages and templated content where structure matters more than exact bytes. Use exact SHA256 for application-layer payloads like C2 response blobs where byte-level identity is the signal.

  Thread B, AWS C2 fleet

The web scan of celosiapatroen.shop reveals the domain serving a 39-byte empty nginx response with Content-Type: application/octet-stream and a final resolved URL of data:. This is the LokiBot C2 listener fingerprint: the server accepted a connection and returned a raw binary blob, no redirect, no page, nothing a browser can render. The url = "data:," field in Silent Push scan data captures exactly this behaviour.

The SPQL query below combines four conditions. None of them alone produces a clean result, the precision comes from their intersection:

SPQL / C2 Listener FingerprintWeb Search Tab → SPQL Query
datasource = ["webscan"] AND body_analysis.body_sha256 = "0c62c11e910d7c0d6b6c9800b70e78bfd9220e1f78bd7bb34ae4c3646d05f6e5" AND url = "data:," AND tld = ["cfd","shop"] AND geoip.asn = 14618
  • raw binary blob, no HTTP page
  • anchor to observed TLD family
  • ASN 14618 = Amazon.com, Inc.
  What each condition contributes

body_analysis.body_sha256, exact match on the 39-byte C2 listener blob. Shared across every active node in this campaign.

url = "data:,", the browser received a raw binary payload with no HTTP location to resolve to. This is not normal web behaviour and is a reliable behavioural marker of an active LokiBot C2 listener. The body_sha256 alone matches thousands of unrelated nginx servers; this condition cuts them out.

tld + geoip.asn, anchors results to the TLD family and hosting provider established by the seed and celosiapatroen.shop, removing coincidental matches on other infrastructure worldwide.

The query returns ~50 domains, all active AWS-hosted C2 nodes across the campaign window. Two distinct naming conventions appear in the same result set, confirming they are part of the same deployment:

DomainIP (AWS)First SeenNaming Pattern
celosiapatroen.shop44.192.95.1272026-04-22Anchor domain
secretionsuitcasenioise.shop54.146.6.2532026-05-26Dictionary-combo
contintnetksows.shop3.222.192.2112026-05-26Dictionary-combo
civilianurinedtsraov.shop34.229.166.502026-04-25Dictionary-combo
moutheventushz.shop54.146.6.2532026-04-23Dictionary-combo
giampaolidolciaria.cfd18.206.193.2142026-01-02.cfd brand-lookalike
017b7cbd2b597369b11f0226db12babd.shop44.192.95.1272026-04-10MD5-format
9f6872fbdb9e30eae00832389b9eb7ab.shop3.222.192.2112026-03-23MD5-format
8bd39b99b3e28aa7114d8a25d6a25d6a.shop50.16.27.2362026-02-04MD5-format
+ ~40 additional domains across ASN 14618
  Thread C, WHOIS registration pattern

The previous steps established two infrastructure signals: the csof.net nameserver set (nshash 8fbcec1929f7b0122d09640a65e76d2a) and the Dynadot registrar observed on celosiapatroen.shop. Query the WHOIS datasource to find every domain that combines both, this surfaces the full registration campaign rather than just the domains that happened to be scanned.

SPQL / WHOIS Registrar + NSHashWeb Search Tab → SPQL Query → WHOIS Datasource
datasource = ["fullwhois"] AND nshash = "8fbcec1929f7b0122d09640a65e76d2a" AND registrar = "Dynadot Inc."
  • csof.net nameserver set

The query returns 50 domains, all registered through Dynadot, all pointed at csof.net nameservers, with a registration wave spanning August 2025 through March 2026:

DomainRegisteredPattern
celosiapatroen.shop2024-07-11Anchor domain from Step 2
moutheventushz.shop2026-03-28Dictionary-combo
complaintsipzzx.shop2025-10-23Dictionary-combo
bassizcellskz.shop2025-10-23Dictionary-combo
patternapplauderw.shop2025-09-28Dictionary-combo
barebrilliancedkoso.shop2025-08-xxDictionary-combo
aa4c792ced23324cc1208e21f52d70dd.shop2025-08-06MD5-format
be9d9051f11af39b1cb32bbf7bbf4865.shop2025-08-10MD5-format
9f53137ff9d73a6dbb6f953bbfe339de.shop2025-12-15MD5-format
ddrtot.shopAlso found in Step 2 IP pivot
+ 40 additional domains, all Dynadot + csof.net
  Why this query produces clean results

Neither nshash nor registrar alone is sufficient, csof.net hosts ~50,000 domains across many registrars, and Dynadot registers millions of domains across every nameserver. The intersection is precise: domains that were specifically pointed at csof.net and registered through Dynadot represent a single actor's provisioning workflow. The registration timestamps confirm this: a consistent wave of new domains across a 7-month window is bulk campaign infrastructure, not coincidence.

  Taking the WHOIS pivot further

The WHOIS datasource supports full PCRE regex on domain names. If the actor uses a consistent naming pattern across registrations, you can add a domain ~= "pattern" clause to surface pre-deployment domains, registered but not yet actively serving C2 traffic. This is Silent Push's core preemptive capability: finding attacker infrastructure before it is weaponised.

The nameserver hash (nshash) is a Silent Push fingerprint computed from the exact set of nameservers a domain uses. The WHOIS query in Step 5 already used nshash as a filter. The NSHash pivot goes further: query the PADNS datasource directly to find domains sharing this NS set that may not yet appear in WHOIS scan data, including very recently registered or newly pointed domains.

PADNS / NSHash Reverse LookupPADNS Tab → NS Record → Reverse by NSHash
# Pull the nshash from the NS record history of the seed:
montblancgroup.cfd  →  ns1.csof.net, ns2.csof.net, ns3.csof.net, ns4.csof.net
nshash: 8fbcec1929f7b0122d09640a65e76d2a

# PADNS reverse returns 25+ domains currently on this NS set,
# including domains registered after the last WHOIS scan cycle:
  kezxwnfgxxzuthr.com      (first seen 2026-04-27, newer than WHOIS data)
  dpmgfd35c8779c89.com
  dplni266cef04ee7.net
  yossxjbgxxkastbxneic.com
  vlgyd10dfa1945df.top
  ekmkyf95a7c94005.top
  aaefouageoeougaeol.in
  rpwwknsm.com             (active since 2022, pre-dates this campaign)
  Evaluate NS provider density before pivoting

Before treating an nshash result as a cluster signal, check the NS server domain density in the enrichment output. csof.net hosts ~50,000 domains across many registrars. The PADNS NSHash pivot here should be treated as medium-confidence corroboration, useful for catching fresh registrations that haven't propagated to WHOIS yet, but not for primary attribution. Domains from this lookup that also match the body_sha256 from Step 4, the ssdeep from Step 3, or the Dynadot registrar from Step 5 cross the threshold to high-confidence membership. The nshash alone does not.

  When nshash alone is a strong signal

The nshash pivot is most precise when the NS provider is small and atypical, a private resolver, a privacy NS like Njalla, or a boutique hosting company with fewer than 5,000 domains. In those cases an nshash match is near account-level attribution. Always check NS server domain density before deciding how much weight to give it.

Investigation Summary

Five pivot techniques mapped three infrastructure threads from a single seed domain. Each technique surfaces a different slice of the campaign, cross-referencing across threads is what confirms cluster membership with high confidence.

StepTechniqueDomains FoundConfidence
2PADNS IP reverse, 196.251.89.337High, dedicated IP
3ssdeep fuzzy hash pivot7High, shared server config
4body_sha256 + url=data:, + tld + ASN~50High, 4-signal intersection
5WHOIS nshash + Dynadot registrar50High, combined registration pattern
6PADNS NSHash reverse25+Medium, corroborative, density caveat
196.251.89.33
44.192.95.127
18.206.193.214
3.222.192.211
34.229.166.50
ssdeep: 24:n1wTfr3TuDb...W61Rr
body_sha256: 0c62c11e...d05f6e5
url = data:
nshash: 8fbcec19...76d2a
Dynadot + csof.net
TLD: .cfd / .shop · ASN 14618

See These Pivots on Live Infrastructure

You just mapped a full campaign from one domain. Bring your own indicators to a Silent Push analyst and watch the same pivots run against adversary infrastructure in real time.

Request a Demo