


Il nuovo modulo di Threat Detection basato su un nuovo algoritmo di Machine Learning è stato realizzato grazie al contributo del Fondo Europeo di Sviluppo Regionale. 

Il modulo consente alla piattaforma Certego PanOptikon di migliorare la propria capacità di rilevamento degli attacchi ottimizzando le attività degli analisti. 

Link al documento.




  • Let's you import also windows event files (BETA)

Installation and Basic Usage

Install Docker-CE and docker-compose:

To start Elasticsearch,Logstash and Kibana run the following command:

sudo docker-compose up -d elasticsearch logstash kibana

Use the following command to check if everything is working properly:

sudo docker-compose ps

The output should be the following:

Name                       Command                       State                    Ports         


Put one pcap file inside the pcap folder.

Start zeek and suricata containers:

sudo docker-compose up zeek suricata


Full documentation

You can read the full documentation on the official github page:

Video Tutorial

Remember to turn on English Subtitles

About the author

Federico Foschini(Twitter)

  • Introduction
  • Malware
    • Execution
    • Defense Evasion
    • Persistence
    • Payload delivery
    • Dropping malware components
      • Credential Access
      • Lateral Movements
    • Download and Update / C&C
  • Detection
    • Detecting Lateral Movements and persistences
    • Detecting Infected Hosts
  • Response
    • Containment
    • Malware Removal
  • Conclusions
  • IOCs
  • About the author
  • Credits














Defense Evasion

The noteworthy defense evasion techniques are the following:











Payload delivery


agen.ps1 sample


The result is a powershell dropper.

Dropping malware components


rein.ps1 sample


a) An XMRig cryptominer:




b) A libpeconv based Process Hollowing injector

This component is never dropped on domain controllers,



c) Re-compiled mimikatz DLL to perform Credential Access:


  1. Inject LSA to dump NTDS.dit credentials
  2. DCSync


d) The powershell script funs.ps1: funs_decoded.ps1.



  1. Remote Service Creation (aka SMBExec)

  2. WMI Win32_Process Remote Process Creation

  3. Remote Task Scheduler Creation:

    This last method leaks the credentials in the commandline twice.
  4. Simple TCP scanner:

  5. EternalBlue Scanner:






  1. testhser:



  2. plant-ags:

e) The powershell script agen.ps1: agen_decoded.ps1:

f) Internal C&C Malware on DC:






g) A simple shellcode


h) A vulnerable driver






For example:

  • Privilege escalation in user space
  • Hinder the operation of security products
  • Hide traces of malware via a ring 0 rootkit



More technical details


Detecting Lateral Movements and persistences



So what are the benefits of identifying lateral movements?















Correlate authenticated sessions and the actions performed by the following processes:

Remote Task Creation


Modifications of this registry paths by the same process:



  • C:\windows\system32\svchost.exe -k netsvcs
  • C:\windows\system32\taskeng.exe

EventLogs: 4624 and 4672 and from 4698 to 4702

Remote Service Creation

Modifications of this registry paths by services.exe:





EventLogs: 4624 and 4672 and 4697 or 7045

Remote Process Creation through Win32_Process and WMI Event Subscription







Detect malware interactively:


Sysmon events: from 19 to 21 .

Detecting Infected Hosts









Malware Removal
















Web resources


WMI class: root\default:systemcore_Updater8



Task Name: sysupdater0

About the author

Gabriele Pippi (Twitter)




  • Introduction
  • Tests scope
  • APT macro analyses
  • Observations
  • Tests carried out:
    • Bypassing CreateObject detection
    • Crafting our easy custom undetected obfuscation
    • Killing ViperMonkey
    • Undetected code execution methods/functions
    • Undetected methods/functions to get our malicious file
    • Undetected autoexec sub events
    • Results
  • Suggestions for improvement
  • Conclusions
  • About the author






Tests scope

  • Macro based PoCs must work with medium integrity level.

APT macro analyses



We decided to report the following three examples:

1) 2019-06-06 gorodpavlodar.doc from APT28

APT28 is one of the groups with advanced  TTPs.

VBA code:

olevba result:


VBA code:

olevba result:


The sample is a CDFV2 Encrypted with password 3209. password source

APT29 is one of the groups with advanced TTPs

VBA code:

olevba result:


One of the more recent APT macro.

VBA code:

olevba result:


We have observed that:

  • There is no known way to obfuscate functions and methods.


      Other undetected alternatives could be:


Tests carried out



  1. An Autoexec Sub Event to trigger our macro.
  2. A code execution method/function

Bypassing CreateObject detection





Crafting our easy custom undetected obfuscation


Here is how to easily get Shell.Application CLSID through powershell:

So instead of:

We used:





Note: without using a variable olevba detects the technique.

Killing ViperMonkey




After some fuzzing we have identified the following simple code:


The vmonkey parser will fail:

Undetected code execution methods/functions



We have identified three interesting examples:





Undetected methods/functions to get our malicious file






During the tests we also found that:


Undetected autoexec sub events


Hunting for undetected autoexec sub event:


We have identified three interesting examples:



The outputs shown below are those of the following command:













Suggestions for improvement





About the author

Gabriele Pippi, Threat Research Lead Engineer ( Twitter)

                                                                                                                  Photo by Jr Korpa on Unsplash

Intel Owl è un progetto di Open Source Intelligence, o OSINT, che permette di ottenere dati di Threat Intelligence riguardanti uno specifico file, IP o dominio, usando una unica API scalabile e semplice da utilizzare. Intel Owl integra un buon numero di analizzatori disponibili online, ed è pensato per chiunque abbia bisogno di un singolo punto da cui ottenere informazioni riguardanti un determinato indicatore.

Nato all'inizio del 2020 (annuncio ufficiale), questo nuovo strumento è stato accettato per essere portato avanti nel progetto Google Summer of Code 2020, sotto il cappello di Honeynet Project. Questa collaborazione ha permesso di aggiungere molte importanti novità a Intel Owl.

In particolare, proprio grazie a Google Summer of Code e la collaborazione con The Honeynet Project, siamo lieti di annunciare il rilascio della versione 1.0.0, con un'interfaccia grafica completamente nuova ed alcune importanti novità nelle API, che vi permetteranno di gestire al meglio le vostre informazioni di Threat Intelligence.

Potete leggere tutte le novità di Intel Owl 1.0.0 nell'annuncio ufficiale del nuovo rilascio, realizzato in collaborazione da Eshaan Bansal (GSoC Student) e dal suo mentor, il nostro Matteo Lodi, e pubblicato sul blog ufficiale di The Honeynet Project.

Photo by Maximalfocus on Unsplash

Certego è lieta di annunciare il proprio ingresso nell’ecosistema di contributors di Virustotal, il più grande aggregatore di antivirus engines, website scanners, strumenti di analisi file e URL del mondo.

Virustotal è un servizio web gratuito che permette all’utente di verificare il contenuto di file, url, domini, sfruttando le potenzialità di oltre 70 antivirus scanners, blacklisting services e strumenti di analisi forniti dai principali vendor di security a livello globale. Fondata nel 2004 da una società spagnola, Virustotal è stata acquisita nel 2012 da Google e, nel 2018, la proprietà è passata a Chronicle, sussidiaria di Alphabet.

Da oggi, molti dei dati di intelligence prodotti attraverso Quokka, la piattaforma di Threat Intelligence sviluppata da Certego, saranno a disposizione della community di Virustotal in modalità totalmente gratuita. L’obiettivo della community, infatti, è quello di mettere in campo le competenze di tutti i principali attori coinvolti nella sicurezza degli utenti finali per contrastare la diffusione di malware, le problematiche relative a falsi positivi e le minacce dei falsi negativi.

La piattaforma “Quokka” nasce dal lavoro di un team esperto di analisi di malware e di raccolta di informazioni legate alle minacce informatiche. Il team di Threat Intelligence ha combinato diversi strumenti tecnologici, tra cui le Honeypot, vere e proprie “trappole” per i cyber criminali e le Sandbox, ambienti virtuali dove vengono studiati ed eseguiti malware in automatico. Il risultato è una piattaforma che permette di raccogliere in tempo reale importanti informazioni che permettono a Certego di tracciare le attività cyber criminali.

Dettagli tecnici

Vogliamo mostrarvi qualche esempio di che genere di informazioni gli utenti possono trovare sfruttando il potere combinato della scansione multipla di VirusTotal con le informazioni di Intelligence di Certego.

Che tu sia una persona tecnologica o meno, sicuramente ti sarà capitato di trovare uno strano link all'interno di una email ricevuta. Prima di cliccare sul link sospetto, è bene sempre verificarlo. Un modo per farlo è quello di visitare il sito di VirusTotal, selezionare la scansione degli URL, inserire il link da verificare nella casella di input e, infine, eseguire l'analisi.

Dopo pochi secondi, puoi trovare i risultati dell'analisi.

Per questo esempio specifico, l'engine di Certego ha rilevato l'URL come "Phishing".

Questa valutazione aiuta l'utente in quanto, nel caso in cui avesse visitato il sito, avrebbe trovato una pagina di phishing di account Outlook identica a quella reale.

Oltre che a "Phishing", ci sono altre possibili valutazioni che l'engine può fornire come risultato dopo una scansione URL.

Le valutazioni “Malicious” e “Malware” servono per indicare quando uno specifico URL o dominio è stato visto ospitare malware o, più semplicemente, è stato coinvolto in attivita cyber criminali. Esempio:

La valutazione “Suspicious” serve a specificare quando uno specifico URL o dominio è o è stato probabilmente coinvolto in attività malevole. Per questi casi, l'engine non ha una prova certa per cui suggerisce di non visitare il sito in questione a scopo precauzionale. Esempio:

L'ultimo caso è la valutazione "Spam" che serve ad indicare quando uno specifico URL o dominio è stato inserito all'interno di un gran numero di email inviate massivamente a diverse caselle di posta: perciò, probabilmente non è un link da cliccare. Diversamente, gli indirizzi IP sono taggati in tal modo quando sono stati osservati inviare molta spam e perciò sono probabilmente correlati alla presenza di uno "spambot". Esempio:

Certego è orgogliosa di contribuire alla sicurezza di tutti gli utenti del mondo attraverso la community di VirusTotal.

Autore: Matteo Lodi, Threat Intelligence Lead Engineer (Twitter).

Certego ha il piacere di sostenere la quarta edizione di ITASEC, la conferenza annuale sulla sicurezza informativa organizzata dal Laboratorio Nazionale di Cybersecurity del CINI – Consorzio Interuniversitario Nazionale per l’Informatica si svolgerà quest’anno ad Ancona dal 4 al 7 febbraio, in collaborazione con l’Università Politecnica delle Marche e l’Università degli Studi di Camerino.

La conferenza, che si svolgerà nelle sale dell’UNIVPM, ha l’obiettivo di riunire ricercatori e professionisti provenienti dal mondo accademico, industriale e governativo per discutere le sfide emergenti e i bisogni consolidati nel campo della cybersecurity.
Al filone principale, dedicato alla scienza e tecnologia della sicurezza informatica, si affiancheranno poi workshop e tutorial riservati agli specifici aspetti economici, politici e legali della cybersecurity.


Bernardino Grignaffini, CEO Certego, prenderà parte alla sessione “Nuove Sfide e Opportunità” il giorno 6 febbraio alle ore 9.45

Vendor Session: Certego e VEM organizzeranno due incontri dedicati a Cybersecurity e Industrial Cyber Security nel corso di ITASEC.

Vi segnaliamo che tutte le sessioni plenarie e vendor session sono gratuite, mentre per partecipare ai workshop formativi sarà necessario versare una quota di iscrizione.

L’ultima data utile per iscriversi e partecipare con la QUOTA RIDOTTA è il 22 GENNAIO 2020.

Per maggiori informazioni visita il sito ufficiale dell’evento e PARTECIPA A ITASEC!


04 Febbraio 2020 - 07 Febbraio 2020


Via Brecce Bianche
60131 Monte Dago (Ancona)

Happy new Year to everyone!


Main features:

  • official client available on Github: PyIntelOwl
  • easily and completely customizable, both the APIs and the analyzers



Matteo Lodi, Threat Intelligence Lead Engineer (Twitter).

Every suggestion or contribution is really appreciated.

Keep hunting malware! We cheer on you :)


I want to share this simple password-based FTCODE decryptor.




Why should a password-based decryptor be useful?


Network Traffic


ext = extension of encrypted files
ek = password in plain text
r1 = Base64 chunk containing the encrypted password



What does the tool do?


It offers the following features.


Additional Details


For further FTCODE details, please refer to this article FTCODE article

About the author

Gabriele Pippi, Purple Team (LinkedIn)



  1. The Threat
  2. Payload Delivery
  3. Environment Preparation
  4. Ransomware Attack
  5. Version Changes
  6. Conclusion
  7. Suricata Signatures
  8. IoC

1. The Threat

Malicious actors are evolving and trying new ways to infect computers.










Mainly we analyzed two samples from two different campaigns:


2.Payload Delivery








3. Environment Preparation








We believe that this mistake will be corrected in future versions.


with the following parameters:

  • ver=930.5, version number
  • vid=dpec2, probably to identify the campaign
  • guid=the GUID generated previously, to identify the victim
  • ek=the previously generated password encoded in base64



Similar behaviour is performed by Sodinokibi: Certego blog

4. Ransomware Attack






5.Version changes


  • status=”start” or “done”
  • res=number of successfully encrypted files







Suricata IDS signatures




About the authors

Matteo Lodi, Threat Intelligence Lead Engineer (Twitter)

Marco Bompani, Security Analyst (Twitter)


Creative Commons License



  1. The Threat
  2. The Loader
  3. Mutex and Configuration
  4. Machine information recovery
  5. Encryption preparation inspired by GandCrab
  6. Ransomware attack
  7. C2 Registration
  8. Conclusion

1. The Threat




Coincidence? We’ll see.



Mainly we analyzed two different samples:

  • version 1.01: md5: e713658b666ff04c9863ebecb458f174
  • version 1.00: md5: bf9359046c4f5c24de0a9de28bbabd14

2. The Loader








3. Mutex and Configuration




These are the keys found in the configuration.

  • pk” -> base64 encoded key used to encrypt files
  • pid” -> personal id of the actor
  • dbg” -> debug mode
  • fast” -> fast mode
  • wipe” -> enable wipe of specific directories
  • wht” -> whitelist dictionary
    • fld” -> keyword in whitelisted directories
    • fls” -> whitelisted filenames
    • ext” -> whitelisted file extensions
  • wfld” -> directories to wipe
  • prc” -> processes to kill before the encryption
  • dmn” -> domains to contact after encryption
  • net” -> check network resources
  • nbody” -> base64 encoded ransom note body
  • nname” -> ransom note file name
  • exp” -> unknown, expert mode?
  • img” -> base64 encoded message on desktop background


4. Machine information recovery



  • ver”: version (100 or 101)
  • pid”: previous config “pid”
  • sub”: previous config “sub”
  • pk”: previous config “pk”

  • unm”: username
  • net” : hostname
  • grp”: windows domain

  • lng”: language


  • os”: full OS name



5. Encryption preparation inspired by GandCrab







6. Ransomware attack





7. C2 Registration






The following are examples of some of these URLs:




8. Conclusion







About the author

Matteo Lodi, Cyber Threat Intelligence Team Leader



Creative Commons License



  1. The Threat
  2. The Check-In phase
  3. Encryption routine
  4. Injected Internet Explorer? Or not?
  5. Conclusion

1. The Threat



2. The Check-In phase










Decoded data:

  • soft -> major version
  • version -> minor version
  • user -> unique user id
  • server -> unique c2 server id
  • id -> bot group id
  • uptime -> time elapsed from initial infection (seconds)




All of this without any need of manual reverse engineering.


This is an example of how to run the script:

and the related output:

3. Encryption routine







4. Injected Internet Explorer? Or not?












About the author:

Matteo Lodi, Cyber Threat Intelligence Team Leader 




Creative Commons License

Today we are going to start a new series of blog posts called “Malware tales”: the intent is to go deep on code-level analysis of most widespread malware to allow everyone to get a better picture of everyday cyber threats. Also, we’d like to demystify malware and show that we are just talking about a bunch of code


  1. The Threat
  2. Payload delivery
  3. Gootkit executable
  4. Stage 1: Packed Gootkit
  5. Stage 2: Gaining a foothold
  6. Stage 3: Check-in phase
  7. Last stage
  8. Additional findings
  9. Conclusions

The Threat:

Gootkit belongs to the category of Infostealers and Bankers therefore it aims to steal information available on infected machines and to hijack bank accounts to perform unwanted transactions.

It has been around at least since 2014 and it seems being actively distributed in many countries, including Italy.

Previous reports about this threat can be found following this link: Malpedia

Today we are going to dive into the analysis of a particular variant that came up the last week.

Payload Delivery:

The infection vector is an email written in Italian. In this case adversaries used one of the most common social engineering techniques to trigger the user to open the attachment.

The downloaded file is a heavily obfuscated Javascript file called " GLS_Notifica.js". If the user opens it, the native Javascript interpreter wscript.exe would be executed by default and it would perform the following HTTP request:

The result is the download of a cabinet file that is an archive file which can be extracted natively by Windows. Inside there is a Portable Executable file that is saved into the %TEMP% folder (“C:\Users\<username>\AppData\Local\Temp”) and launched.

Javascripts downloaders are a common payload delivery because a little obfuscation can be enough to make them very difficult to be detected by antivirus engines.

Gootkit executable:

First run of the sample in an automated environment revealed that something new was added in this version. As we can see in the following images, malware authors added a new layer of protection to the malicious agent. The comparison has been made with a variant spread during December of 2018 in Italy. (images are from AnyRun)

This means that the original program was “packed” with the aim to slow down reverse engineers and to make ineffective static analysis tools like Yara rules.

Stage 1: Packed Gootkit

In such cases, a malware analyst knows that he has to extract the original payload as fast as possible without losing time to try to understand the inner workings of this stage.

A great open-source tool exists which can resolve the problem in a matter of seconds. It’s called PE-Sieve (Github). Even though it does not always work, in this case it can dump the unmapped version of the original executable because the malicious software uses a technique called Process Hollowing a.k.a. RunPE. This method consists in starting a new process in a suspended state, “hollowing” out the content of the process, replacing it with malicious code and, finally, resuming the thread.

In the image we can see that the 6th parameter of "CreateProcessW" was set to "4", indicating that the process will start in a suspended state.

We are talking about a well known technique that is easily detectable with the monitoring of the Windows API calls that are needed to perform the injection. But here comes the trick.

Following the flow of execution we couldn’t find all the needed API calls: we got NtCreateProcess, NtGetContextThread, NtReadVirtualMemory and NtSetContextThread.

The most important ones that are used by monitoring applications to detect the technique were missing:

  • NtUnmapViewOfSection to “hollow” the target process
  • NtWriteVirtualMemory to write into the target process
  • NtResumeThread to resume the suspended thread

Let’s find out what’s happening!

After some shellcode injections inside its memory space, the process executes a call to IsWow64Process API that is used by the application to understand if the process is running under the WOW64 environment (Wiki): this is a subsystem of the Windows OS that is able to run 32-bit applications, like this one, on 64-bit operating systems.

The result of this check is used to run two different paths of code but with the same scope: run one of the aforementioned missing API calls in the Kernel mode. This means that, in this way, classic user-level monitoring tools would not catch these calls and the RunPE technique would remain unnoticed.

Specifically, in case the process is running in a 32-bit environment, it would use the SYSENTER command to switch into the Kernel mode, while, on the contrary, it would use the SYSCALL command to perform the same operation.

To complicate even further, the SYSCALL command can’t be called in the context of a 32-bit application. This means that the executable needs to perform a “trick-into-the-trick” to execute this operation. We are talking about a technique known as The Heaven’s Gate.

Practically, thanks to the RETF instruction, it’s possible to change the code segment (CS) from 0x23 to 0x33, de facto enabling 64-bit mode on the running process.

In the following image we highlight the entrance and the exit of the “Gate” which contains the 64-bit code that performs the SYSCALL operation.

Instead, in this other image, we can see the process status before opening the gate (grey=suspended process) and after having closed it (orange=running process).

Also, Gootkit takes advantage of The Heaven’s Gate as an anti-debugging technique because the majority of commonly used debuggers can’t properly handle this situation, not allowing the analyst to follow the code of the Gate step-by-step.

For further details, this method was deeply explained in this blog (MalwareBytes)

Going back to the point, the first stage resulted more complicated than expected because it pushed over the limits of obfuscation and stealthiness with the combination of various techniques.

Stage 2: Gaining a foothold

At this point we can proceed with the analysis of the unpacked Gootkit.

The very first considerable finding was the check for the existence of a mutex object named “ServiceEntryPointThread”. If it exists, the process would terminate itself.

But how mutexes works? Mutexes are used as a locking mechanism to serialize access to a resource on the system. Malware sometimes uses it as an “infection marker” to avoid to infect the same machine twice. The fascinating thing about mutexes is that they are a double-edged weapon: security analysts could install the mutex in advance to vaccinate endpoints. (ref: Zeltser blog)

This means that this is a great indicator of compromise that we can use not only to detect the infection but also to prevent it.

Moving on, we found that malware authors implemented a lot of checks to understand if the malware is running inside a virtual environment. Some of them are:

  • It checks if the registry key “HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString” contains the word “Xeon”

  • it checks if the computer name is “7SILVIA” or “SANDBOX”, if the username is “CurrentUser” or “Sandbox” or if “sbiedll.dll” has been loaded.

  • it checks if “HKLM\HARDWARE\Description\System\VideoBiosVersion” contains the word “VirtualBox”

  • it checks “HKLM\Software\Microsoft\Windows\CurrentVersion\SystemBiosVersion” for the string “VBOX”

In the case one of this check fails, the program would execute a Sleep operation in a infinite cycle in the attempt to thwart automated sandbox execution.

After that, we encountered the implementation of a particular persistence mechanism that it seems Gootkit has been using for many months: it’s already documented in various blog posts, for ex. ReaQta blog.

Briefly, the infostealer generates a INF file with the same filename of itself.

Content of the INF file:

Then it creates 3 different registry keys (“ Count”, “Path1” and “Section1”) inside “HKCU\Software\Microsoft\IEAK\GroupPolicy\PendingGPOs” with the purpose to allow the threat to execute on reboot.

It seems that this technique was reported to be used only by Gootkit.

Famous security tools still can’t detect this mechanism even if it has been used for months.

For example, the famous SysInternal Autoruns tool, that should be able to show all the programs that are configured to run on system bootup or login, fails the detection of this persistence method.

Stepping through the code, we noticed that, at runtime, Gootkit decrypts the strings it uses with a custom algorithm to evade static analysis detection of anomalous behaviour.

It’s a combination of “stack strings”, XOR commands and the modulo operation.

An exhaustive explanation of the decryption routine can be found here: link

Skipping further, eventually there’s a call to “ CreateProcessW” to start a new instance of Gootkit with the following parameter: --vwxyz

Stage 3: Check-in phase

Quickly we found out that executing the malware with the cited parameter allows us to skip all the previous anti-analysis controls to get into the part of the code that starts to contact the Command & Control Server.

The first check-in to home is done to the following URL via HTTPS:

As we can see from the image, many headers were added to the request to send different informations of the infected machine to the C&C Server.

In particular one of the headers caught my attention: “ X-IsTrustedComp”. Digging into the code we found that the value would be set to “1” if an environment variable called “crackmeololo” was found in the host, “0” otherwise.

That seems another “escaping” mechanism implementing by the author, probably to stop the infection chain for his own debugging purposes.

Last stage:

The response that arrives from the previous connection contains the final stage of Gootkit, configured to work properly on the infected machine.

The malware dynamically loaded “ RtlDecompressBuffer” call to use it to decompress the payload; then, it injected into an area of the current process memory.

Afterwards the flow of execution is transferred to the start of the injected code.

The final payload is a DLL file that is bigger than 5MB because it contains the Node.js engine which is probably needed to run some embedded javascript files. At this time we decided to stop our analysis and leave the rest to future work.

Additional findings:

While debugging, we noticed that Gootkit does not check only if a parameter called “ --vwxyz” was passed to the command line. Also it checks if other 3 parameters:

  • --reinstall

  • --service

  • -test

Pretty strange thing. We haven’t found the malware to actively use these arguments yet. However, stepping through code we discovered that:

1 - the “ --reinstall” command leaded the execution to some curious code. First, the malware used “CreateToolHelp32Snapshot” to retrieve a list of the current running processes.

Then, it iterated through the retrieved list via “ Process32FirstW” and “Process32NextW” with the aim to get a handle to the active “explorer.exe” instance.

At this point it killed “ explorer.exe”. The following image shows the process list before the “TerminateProcess” command.

After having executed that command, we found that a new instance of the malware spawned as a child of “explorer.exe”.

What happened? We performed some tests and it seems that “ explorer.exe” was killed and then automatically restarted by “winlogon.exe”. Therefore “explorer.exe” accessed the keys involved in the persistence mechanism previously explained:

Using this trick, the malware is able to “reinstall” itself, without the need to use suspicious API calls like “ CreateProcessW”.

2 - the “ --service” command did not change the flow of execution with the exception of creating a new environment variable called “USERNAME_REQUIRED” and set it to “TRUE”.

Eventually we found that the final stage checks if the aforementioned variable exists.

3 - the “ -test” command just terminate the process. Indeed it’s a test.


We explored some of the functionalities of one of the most widespread Infostealers of these days, revealing new and old tricks that is using to remain undetected as much time as possible.

Certego is actively monitoring every day threats to improve our detection and response methods, continuously increasing the effectiveness of the incident response workflow.

PS: Let us know if you liked this story and feel free to tell us how we can improve it!


gootkit 1st stage
gootkit 2nd stage
gootkit DLL module

About the author:

Matteo Lodi, Cyber Threat Intelligence Team Leader


Licenza Creative Commons

Hi everyone, here is Matteo Lodi, Threat Intelligence Analyst in Certego.

Recently, we saw a particular new spam campaign targeting italian users with the focus of delivering a downloader known as Sload.

Nowadays, attackers are trying harder and harder to make difficult the analysis and the detection. The most common tool misused in this way is Powershell: it's installed by default in every recent version of Windows and is commonly used to perform administrator tasks.

The infection chain

Let's dig in the infection chain:

1. A user receives an email with subject "<TARGET_COMPANY_NAME> Emissione fattura <random_number>" containing a reference to a fake invoice.

The user is tricked to click on the malicious link that points to a randomly generated domain hosted with HTTPS in 91.218[.]127.189. The following is an example:

2. Once downloaded, if the user opens the archive, it would find two files. The first one is a legit image, while the second one is a .lnk file. We have already seen the misuse of shortcut files with powershell to perform the download of malicious samples. But this time it seemed different: in fact, the .lnk points to the following command:

3. Where is the download? At first glance, that seemed very strange: what is the aim of this execution? After having analyzed the command, the trick was clear. The attackers wants to call "Invoke-Expression" command to run a string hidden inside the zip itself!! But where?

As we can see in the following image, at the end of the original downloaded zip file we can see readable strings that are the real first stage downloader!!

The zip file is still a legit and correctly working archive! Powershell commands are written after the EOCD (End of central directory) which determines the end of a zip file.

This clever trick can deceive many signatures-based detection tools.

4. The extracted command is the following:

5. The result is the download and the execution of another powershell script from a server hosted in 185.17[.]27.108. We saw different domains used but, in the last week, the Dropzone IP never changed. Also, we noted that the CnC server was blocking requests without the "Microsoft BITS/7.5" User-Agent to prevent unwanted download by non-infected machines.

This script was very well detected by antivirus engines as you can see in the following image!

How funny was I? Static analysis is completely useless in such cases.

Going forward, the malware drops the following items before deleting itself:

Therefore it registers a task called "AppRunLog" to maintain persistence

6. At the end, it calls the registered task. This will execute the dropped Visual Basic Script file that, in turn, will execute the dropped Powershell script:

This script parses arguments and it won't execute properly in case they are not what it expects. It needs the numbers from 1 to 16 as arguments because, in fact, they are the key to decrypt the last stage.

7. The final payload is decrypted from the "config.ini" file and is called with "Invoke-Expression". It's loaded directly in memory: this makes very difficult for antivirus products to detect the threat. At the moment, this execution method is widely known as "fileless" because, indeed, the malware is never written on disk.

The payload is the last (finally) powershell script: it is the real Sload downloader which performs various malicious steps that were already explained in details in the article written by Proofpoint.

In few words, Sload can:

  1. Load external binaries
  2. Take screenshots
  3. Update configuration and CnC servers
  4. List running processes
  5. Detect Outlook usage

The variant we spotted in the last week uses the following CnC domains, which resolve in the same IP used by the second downloader stage (185.17[.]27.108)

However, we expect that this configuration won't last long, because, as we said before, Sload is able to update his CnC servers at any time.


We had a fantastic journey that made us understand, hopefully, how powerful can be Powershell and how attackers are misusing this tool to evade analysis detection.

We analyzed 5 different powershell scripts and that was only the "downloader" phase of the infection.

In case of a successfull one, Sload was seen to download known malware like Ramnit, Gootkit, DarkVNC or Ursnif (reference: Proofpoint). At that stage the threat would be really important.

Certego is monitoring the campaign and it's updating its signatures to correctly detect possible infections.


First stage download: (many and changing fast)
Second stage download: (many and changing fast)
CnC servers: (stable through the last week)
Hash (sha256):
first stage
second stage

Nelle ultime settimane i sistemi di monitoraggio Certego hanno rilevato un significativo aumento nella diffusione del malware Ursnif.

Questo aumento è dovuto al particolare sistema di spear phishing recentemente impiegato per diffondere tale malware. Questo sistema, già segnalato lo scorso Novembre da Barkly e ripreso questo mese da LibraesvaMetis, si basa su una tecnica che possiamo definire di thread injection: la vittima si vede recapitare un messaggio email come risposta ad una precedente conversazione con un suo contatto, con tanto di citazioni dei messaggi precedenti e firma del mittente, in cui si invita l'ignaro e fiducioso destinatario ad aprire il documento allegato.

Come è facile immaginare, l'allegato in questione, spesso in formato doc di Microsoft Word, in questione contiene in realtà delle MACRO il cui scopo è scaricare da un server remoto una copia del malware Ursnif e così infettare un altro host.

Come anticipato, i vantaggi di questa tecnica di phishing sono evidenti: il rapporto di fiducia che esiste tra le utenze riduce l'attenzione della vittima finale quando questa riceve il documento malevolo. Esiste però anche un altro vantaggio rispetto allo spam "tradizionale": si vengono a colpire esclusivamente utenti attivi e, contemporaneamente, si aggirano i sistemi di raccolta passivi dello spam.

Tuttavia, finora non si avevano prove certe su come operasse il malware per recuperare tali informazioni. Essendo Ursnif un malware la cui principale funzione consiste nel manomettere le connessioni verso i siti bancari (session hijacking), era abbastanza facile supporre che effettuasse la stessa operazione verso i client di posta e/o le webmail; così da raccogliere alcune conversazioni e inviare le mail di phishing sopra descritte. Il malware è così riuscito a trasformare le sue vittime in complici, per quanto ignari, della sua propagazione.

In questi giorni è però emerso un fatto interessante. Durante la sua attività di analisi di un esemplare di Ursnif, il ricercatore noto come  JAMESWT ha individuato su uno dei server utilizzati per distribuire gli eseguibili del malware una cartella contenente numerose informazioni relative ad account di posta.

L'analisi del contenuto della cartella indicata da JAMESWT ha portato alla luce una serie di file testuali in cui erano presenti accurate informazioni per accedere a diversi account di posta compromessi. Per ciascuna utenza sono riportati: nome utente, password, indirizzo del server email e protocollo di accesso.


Poco tempo dopo la segnalazione, i file con le credenziali compromesse sono stati rimossi dal server.

Questo rilevamento ci permette di affermare che, per quanto riguarda le campagne attualmente in atto, i responsabili della diffusione del malware Ursnif abbiano completo accesso e disponibilità delle caselle di posta delle loro vittime, senza alcuna necessità di utilizzare bot o strumenti di intercettazione. Inoltre, espone tutti i contatti delle vittime ad attacchi di spear phishing tramite thread injection, come quelli sopra descritti.

Analizzando alcune mail appartenenti a queste campagne in cerca di anomalie, abbiamo rilevato che il bounce address non corrispondeva con l'indirizzo presumibilmente compromesso. Il controllo degli header Received delle mail ha confermato che il server da cui venivano trasmesse queste mail apparteneva all'organizzazione del bounce address. In base a questo possiamo dire che, al momento in cui scrivamo questo articolo, gli account compromessi non vengano utilizzati per inviare attivamente le mail di phishing. Molto probabilmente si tratta di una scelta ponderata da parte degli attaccanti, in modo da aggirare eventuali filtri in uscita da parte dei server delle loro vittime: infatti un errore di consegna potrebbe allarmare l'utente (o il responsabile della gestione della mail aziendale) che andrebbe quindi in cerca di anomalie, utilizzando invece mail server di una terza parte si evitano questi "inconvenienti".

Il miglior modo per difendersi da questo genere di attacchi è non abilitare in alcun caso le MACRO di qualunque documento ricevuto via mail (o tramite link ricevuti via mail). È comunque importante possedere, e mantenere aggiornato, un buon sistema di difesa sia perimetrale (antispam, firewall) che locale (antivirus), così da ridurre il rischio e contrastare eventuali infezioni.