Silent Push uses domain and DNS analytics, infrastructure-variance metrics, and module fingerprinting to attribute threat actors, detect Fast Flux activity, and identify soon-to-be-malicious infrastructure despite attackers abusing CDNs and cloud services. Jensen emphasizes proactive, data-driven defenses (IOFA feeds, Domain Search, ThreatCheck) and notes automation and modularization are reliable fingerprinting vectors. #SilentPush #FastFlux
Keypoints
- Silent Push identifies threat actors by recurring infrastructure patterns, module fingerprints, and proprietary hashes that enable exact and fuzzy matching of malicious infrastructure.
- Fast Flux detection is supported by change analytics and an “Infrastructure Variance” view that highlights IP diversity and rotation history for domains and IPs.
- Practical limits of domain/IP prediction include discovering infrastructure before it is spun up or weaponized; these are addressed with baseline metrics, change data, and attacker-specific fingerprints.
- Attackers abuse CDNs and cloud services (infrastructure laundering) to mask activity; defenders need access to rich data and tooling to separate malicious from benign usage in shared environments.
- Automation and modularization in phishing kits can actually aid defenders: scale, consistency, and standardized modules provide fingerprinting opportunities despite obfuscation.
- Silent Push recommends focusing on what adversaries control and are preparing to use (IOFAs) rather than purely reacting to past IOCs, and offers ThreatCheck and IOFA feeds for proactive defense.
- Baseline and pivotable-field monitoring allow defenders to tie together disparate campaigns and detect obfuscation techniques like rapid provider rotation and DGA usage.
MITRE Techniques
- [T1583] Acquire Infrastructure – Use of domain registration patterns, DGAs, and rapid movement across hosting providers to establish attacker infrastructure: “…use of domain generation algorithms (DGA) for the domain itself rapid movement across different hosting providers (i.e., Fast Flux) presence on bulletproof hosting infrastructure”
- [T1591] Gather Victim Identity Information (infrastructure reconnaissance) – Monitoring domain/IP changes and baselining to identify likely targets and infrastructure before weaponization: “…establishing baselines of normal or expected movements…we can pierce the veil of threat actor obfuscation”
- [T1574] Hijack Execution Flow (infrastructure laundering) – Abuse of CDNs and cloud services to mask campaigns and map abuse back to actual infrastructure: “…attackers are abusing Content Delivery Networks (CDNs) and cloud services to mask campaigns…infrastructure laundering…describe such activity”
- [T1204] User Execution (phishing kits) – Use of modular phishing kits and automation to scale campaigns, with modules leaving identifiable artifacts for fingerprinting: “…Phishing kits are growing more modular and harder to fingerprint…automation and modularization are not the ‘fog of war’…scale and consistency are dead giveaways”
- [T1588] Establish Accounts – Rotating hosting and DNS providers and rapidly provisioning infrastructure to avoid detection, tracked via change analytics and provider movement: “…threat actors increasingly rotate hosting and DNS providers…monitoring both for changes, as well as for deviations across any of our pivotable fields”
Indicators of Compromise
- [Domain ] examples of malicious domain behaviors and contexts – domains showing Fast Flux/IP diversity and DGA-like names (example contexts described in article; specific domain names not published), and references to Funnull CDN as an abused CDN.
- [Hosting/Provider ] contexts showing rapid provider rotation and use of bulletproof hosting – “rapid movement across different hosting providers” and “presence on bulletproof hosting infrastructure” (no specific providers listed).
- [Infrastructure Patterns ] contexts for fingerprinting and module artifacts – proprietary infrastructure hashes and module fingerprints used to identify exact and fuzzy matches (examples summarized as “proprietary hashes” and “module fingerprints”).