Certego has always been strongly involved and participating in open source projects.

For this reason, we created the IntelOwl project more than 2 years ago (see the blog post). At that moment we did know that the cyber security community really struggled in automating common and daily routine tasks. IntelOwl aimed at filling that gap.

We succeeded. We had strong feedback from the community: we reached almost 2500 stars in Github and more and more people tried to participate in the project.

As Certego, we have been leveraging IntelOwl internally to facilitate and speed up the gathering of Threat Intelligence data. It is a tool that we can’t live without anymore.

For this reason we started to think and to focus about the future of the project: we want to make IntelOwl a complete Threat Intelligence Platform that people can use to perform security-related investigations of any kind.

Today we reached the first step of this process: we are happy to announce that we have published the new major version of one of the most successful Open Source Threat Intelligence projects.

This new version 4 release brings a new revamped Graphical User Interface!

The design was inspired by the same idea we got for Dragonfly, the next generation malware sandbox service that we released almost a year ago.

We strongly suggest you check all the details regarding this new release in the official Changelog and to try the new application by yourself!

As mentioned earlier, this is just the first step. We have been planning to add to the project some new exciting features that would transform it into a fully fledged Investigation platform that everyone working in cyber security could use for his own goal. If you want to be updated on everything that we are doing and participate in the discussions about the future of the platform, don’t forget that the project is public and everyone is welcome to the community around it! You can follow the project in Github here

Thanks for reading and happy hunting!

As a Cisco Solution Partner, Certego implemented the Tactical Response service designed for Cisco Secure Endpoint that integrates Cisco's EDR solution into the Panoptikon SOAR platform.

Secure Endpoint is a CISCO product that provides a unified solution for users and endpoints. Through an integrated platform named SecureX, it provides built-in XDR capabilities and enhanced endpoint protection to maximize operational efficiency of endpoint security. Through Certego Tactical Response integration, when Certego IRT detects malicious activities, it can automatically isolate the compromised hosts to block the attack.

Certego's Tactical Response solution for CISCO Secure Endpoint significantly reduces the time it takes to contain a cyber security incident by preventing further attacks and infections. It also minimizes the risk associated with ongoing incidents (e.g., by blocking resources related to further infection phases), all in a simple and automated way, reducing the workload of customer IT.

Certego has always been strongly involved in researching new ways to analyze malware.

We have been working for some time on new projects aimed to evolve how the threat intelligence analysts work and what kind of tools they need.

You may have heard of the open source project IntelOwl and the recognition it received by the community: we have just reached 2k stars on Github in less than 2 years!

But it is not the only one! We started experimenting and working closely with the community that develops binary emulation frameworks.

And we came up with a new idea! A next generation malware sandbox built on binary emulation tools. We called it Dragonfly.

Today we are proud to announce that we are finally ready to publish the Alpha release of this project to the community!

“So yeah, this is all very exciting! but how does it work?”


The process Dragonfly uses when analyzing a binary can be split in three phases:

1. Environment configuration

The emulation engines that Dragonfly supports at the moment are Qiling and Speakeasy. Both of them allow the configuration of the emulated operating system through a configuration file, a Profile.

Dragonfly differentiates from other sandboxes thanks to the granularity of the customization that its users can do: the emulators, and therefore Dragonfly, allow you to specify which processes are present in the emulated system; which files are where; what system registries have been configured and with what value.

Users can create their own configuration, or use the ones that Certego offers publicly.

Figure A: Profile Creation Modal

2. Sample emulation

The sample is emulated through the engines that the user has selected with the corresponding profile: parallel emulation of more than one configuration is supported by Dragonfly. For each profile, a Report is made, containing every artifact that Dragonfly has been able to retrieve through the emulation process.

All this information is then grouped together and displayed by Dragonfly, allowing users to evaluate every aspect of the emulation.

Figure B: Details of every API called

Each piece of information is accessible either through its detail view, or through the Timeline, where artefacts are grouped together by their timestamp, the moment when they have been retrieved.

Figure C: Details of every artifact for a particular point in time

3. Behaviour evaluation

Dragonfly evaluates the sample behaviour through Rules: a rule is made by Modules; each module matches a particular artifact that has been found during the emulation phase.

Figure D: Rules List

Rules are characterized by a positive or negative weight based on the confidence that the behaviour is malicious or not.

Figure E: Details of the composition of a Rule

A Match is created when the behaviour defined by a rule matches the one expressed by the sample during emulation: according to rules matching a sample, its evaluation will change from clean, to suspicious or even malicious.

Figure F: Example of matched Rules

It is possible to learn more about Dragonfly rules and its modules in the official documentation at readthedocs.

Figure G: Rule Creation Modal

Writing your own rules is encouraged but it is not necessary for using Dragonfly: Certego will continue to improve the builtin set of rules available to every Dragonfly user.


The release of Dragonfly is an important milestone for Certego and its Threat Intelligence Team. Our research and knowledge in the malware analysis field, developed in years of fighting threats, has been leading us to incredible new achievements.

The Alpha version is operated as an invite-only trust group. We encourage all security researchers and threat intelligence analysts to request access here. The next Beta release will provide open registration to everyone.

For more information about Dragonfly, what it offers and how to use it, please refer to the FAQs or send us an email to cti[at] we will be more than happy to answer every question that you may have!

Thank you for reading and happy hunting!

PcapMonkey is a project that will provide an easy way to analyze pcap using the latest version of Suricata and Zeek. 

It can also save Suricata and Zeek logs in Elasticsearch using the new Elasticsearch Common Schema or the original field names. PcapMonkey uses official docker containers (when available) for most images and aims to be easy and straightforward to use.


  • PcapMonkey let's you run one or multiple pcaps and imports all logs to elasticsearch.
  • PcapMonkey keeps the "official" Zeek and Suricata fields names so you can look them up on the official documentation
  • It let you edit directly Suricata and Zeek configuration and scripts so you can test quickly new features
  • PcapMonkey comes with some very useful Zeek scripts like Ja3 and File extractor
  • It's possible to enable logging in ECS to leverage all ElasticSerch SIEM features
  • 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         
pcapmonkey_elasticsearch   /usr/local/bin/docker-entr ...   Up (health: starting)   9200/tcp, 9300/tcp     
pcapmonkey_logstash        /usr/local/bin/docker-entr ...   Up                                             
pcapmonkey_kibana          /usr/local/bin/dumb-init - ...   Up (health: starting)>5601/tcp

Kibana and elasticsearch could take a couple of minutes to start. You can monitor the progress by doing "docker-compose ps" and waiting for starting to go away.

Put one pcap file inside the pcap folder.

Start zeek and suricata containers:

sudo docker-compose up zeek suricata

The containers will print the output on the console and exit when they finish processing the pcap. You can see the results on Kibana: http://localhost:5601

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


This and last week, the Certego Incident Response team handled a powershell based  Active Directory compromise on multiple of our customer networks. Although the actors seemed to be intent on spreading a Cryptominer malware, due to some technical aspects the campaign could hide a second goal.

Considering that more and more attacks are aimed to making lateral movements to compromise enterprise domains, today we decided to share with you some details of detection and response actions performed by Certego IRT to handle these threats.

Note: to prevent antivirus from blocking this site we are forced to share the code via screenshots, the main samples have been uploaded to virustotal.


In most of the scenarios observed the threat came from unmonitored Domain Trusts, in the remaining cases we were engaged after the first access was already performed.

We can assume that the attacker established a foothold through  valid domain credentials usage against exposed authenticated services, like RDP terminal server. The attacker may have obtained valid credentials exploiting data breach of third-party sites, phishing or dictionary attack/password spraying. In some cases we have found poor password policies which could motivate the last hypothesis.

Malware was differentiated between domain controllers, 32 and 64 bit hosts. The one installed on domain controllers has the most features.

The behavior identified by the malware is described below with its respective code block.


The runnig malware is usually found on an infected systems in the form of a powershell.exe or a schtasks.exe process usually spawned by WMI Provider Host ( wmiprvse.exe). The most of executables are loaded into the powershell memory space through a fixed version of ReflectivePEInjection script extracted from Invoke-Mimikatz or they are written into schtasks process via a Process Hollowing injector.

The powershell process is easily recognizable by its base64 encoded commandline. The schtasks process, on the other hand, occurs without any parameters and it's harder to notice.

If the XMRig has been written to the schtasks process you will notice a consumption of the CPU and network connections to suspicious ports. In general, since schtasks.exe without parameters displays basic information of tasks and exits, any schtasks process without parameters is potentially malicious.

Defense Evasion

The noteworthy defense evasion techniques are the following:

1) As shown in some screenshots below,  iex/Invoke-Expression and other dangerous cmdlets used for detection are obfuscated through environment variables.

2) Before making a lateral movement the malware adds an exception for powershell.exe inside Windows Defender through Add-MpPreference cmdlet

3) In-memory execution through powershell ReflectivePEInjection and a libpeconv based Process Hollowing injector.

4) In the most recent malware updates we noticed this powershell amsi bypass.



In some cases we observed successfully running malware launched from a remote host without a local persistence.

The persistences used by the malware are two WMI event subscription. The filters trigger the payload after 1 minute and about 6.5 or 3.8 hours from the system startup:

Some information used by the malware is inserted into the following custom WMI class:

The payload is a classic base64 powershell encoded command as shown in the screenshot.

Payload delivery

The payload served by the domain controller and the C&C is a powershell module encrypted with TripleDES and ciphermode CBC: 

agen.ps1 sample

The module and the function de is called, the password and the salt are passed as parameters to the function:

The result is a powershell dropper.

Dropping malware components

The powershell dropper is a base64 blob of data containing multiple components:

rein.ps1 sample

Once the content has been decoded, the malware could drop one or more of the following components:

a) An XMRig cryptominer:

A simple XMRIG cryptominer which does not appear to be installed on domain controllers nor on low-performing hosts ( 32bit ).

To make the cryptominer work at its best the attacker disables sleep mode, standby and hibernation via powercfg. It also checks via netstat if there are connections from other previous versions of the cryptominer and stops the processes that make them.


b) A libpeconv based Process Hollowing injector

This component is never dropped on domain controllers,

It was used to write the XMRig into the  schtasks.exe process usually spawned by wmiprvse.exe


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

This component is installed on all hosts. We saw it running on the domain controller for the following steps:

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


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

This component is downloaded to any host, but with different functions.

By default it contains ReflectivePEInjection and Lateral Movements capabilities from Empire and PoshC2 projects for:

  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:

  6. test-net function, a multithreaded function to verify that the host is not already infected before a lateral movement:

Through lateral movements the attacker executes a command to download or update the malware. Domain controllers malware are installed or updated via the web resource "/update" of the internal or external C&C.

If the host is not a domain controller the web resource " /sync" is used instead.

The version of the malware is monitored via the web resource " /banner" by comparing the WMI filter name.

In addition, these two functions are also dropped on the domain controller:

  1. testhser:

    This function drops the internal C&C server who will listen on port 49636 , the malware launches it and verifies that it works correctly.

    The rein script adds a rule on Windows firewall to allow server binding:

  2. plant-ags:
    The function used by the domain controller to deploy the malware on targets through internal C&C. To performe the deploy it exploits lateral movements techniques and a powershell module masked as gpt.ini downloaded through SMB.

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

f) Internal C&C Malware on DC:

A small and simple http server masked as a fake and unsigned  dfsvc.exe process ( a licit Windows Server process )

The server is developed through Mongoose OS "an Internet of Things (IoT) Firmware Development Framework" designed to be small and light.

This server and the plants-ags function are command and control system, by matching the agent on virustotal the server is identified as a cryptominer but this is a false positive.

During the installation phase the malware extract the agent.ps1 script from the server binary, easily viewable between the strings. By matching this code the antivirus incorrectly report the server as a cryptominer malware.


g) A simple shellcode


h) A vulnerable driver


This driver is dropped on all hosts except the domain controller. Even though it is used directly by XMRig, the driver is present in the most common vulnerable drivers blacklists.

This driver allows any user to perform a local privilege escalation and in generally some ring 0 activities:

"WinRing0 allows users to read and write to arbitrary physical memory, read and modify the model specific registers (MSRs), and read/write to IO ports on the host" 2020-14979

Not needing other privileges at these points of the killchain it is likely that the attacker will use it only for XMRig, however leaving the driver there can expose the host to very serious security problems related to LPE and to the execution of ring 0 code.

For example:

  • Privilege escalation in user space
  • Hinder the operation of security products
  • Remove process protection from critical processes and add process protection to malware components
  • Hide traces of malware via a ring 0 rootkit

This technique is called Bring You Own Vulnerable Driver (BYOvD) and allows you to bypass the following Microsoft security measures:

  1. “The 64-bit versions of Vista require that all device drivers be digitally signed, so that the creator of the driver can be identified” wikipedia 2006.
  2. “Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change.” Jul 26, 2016

More technical details


Detecting Lateral Movements and persistences

Due to the complexity of corporate networks it is common to spot an attacker from an unmonitored internal network. The detection carried out in this phase of the killchain is much more complex due to false positives and unknown/poorly documented protocols.

A common approach used is to identify the effects of a lateral movement, therefore the activities of the malware installed on board through blacklisted IOCs, anomalous network and host activities.

So what are the benefits of identifying lateral movements?

  1. The attacker does not necessarily perform the same actions on all machines. In this scenario, for example, some distinctions were made for both domain controllers, 64 and 32-bit hosts.
  2. In the absence of vulnerabilities, lateral movements are carried out through Microsoft internal network protocols, these protocols have in many cases some juicy plain text information.
  3. In some cases it is possible to delete a persistence created remotely on the target before the malware is executed for the first time.
  4. Studying the lateral movement can allow us to contain host infection in the response phase.

Where the detection IOCs produces a high number of false positives it is possible to use these indicators to carry out threat hunting activities.

To detect lateral movements through network traffic it is necessary to receive infralan traffic on a network sensor, this is difficult due to the volume of traffic but theoretically possible through internal network segmentation. However, even if it is only a small part, it is possible to identify the internal traffic passing through the firewall. 

Since the first analyzes we have identified that the attacker used the following MS-RPCE network sub-protocols to perform lateral movements:

  • MS-SCMR, through CreateServiceW,StartServiceW and DeleteService operations. This traffic is completely in plain text if used via named pipe over MS-SMB2. Among the main information in clear text we find the name of the service and the command executed. MS-RPC over TCP traffic is normally preferred over MS-RPC over named pipes but in this case the attacker forces the traffic on the 445.
  • MS-WMI through ExecMethod operation, encrypted by default but traceable through timestamp, authentication and MS-RPC operation names.
  • MS-TSCH through SchRpcRegisterTask, SchRpcRun, SchRpcEnableTask, SchRpcDelete operations, encrypted by default but traceable in the same way of WMI protocol.

Together with  WinRM they are the main protocols used to perform lateral movements, this is because in case the target uses the windows firewall they are often enabled for systemic reasons. For this reasoning, the most widely used protocol, enabled by default in each domain is SCMR, used for example by the PsExec utility and supported by any malware or redteam tool to perform lateral movements

Note: In scenarios where the windows firewall is disabled the possible lateral movement techniques are a lot.

To track this type of activity it is possible to do it over the network or aboard the host.

To correlate information on the host it is possible to proceed with an EDR, with Sysmon or through Windows Eventlogs. Since we do not believe that collecting logs alone without Sysmon is enough, we will assume that either an advanced EDR or Sysmon is present on the machines.

Note: ETW and Audit Policy Windows event logs Categories are considered out of scope since they are not supported by main security tools functions to perform detection and threat hunting.

Through the host it is necessary to correlate the connections of the following processes:

svchost -k RPCSS : MS-RPC over TCP ( 135 TCP , 593 HTTPS )

ntoskrnl.exeMS-RPC over named pipes (139 TCP, 445 TCP)

NB The first phase of an MS-RPC connection, the endpoint mapper (EPM), although reachable through a named pipe is usually available through TCP.

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

Remote Task Creation

Modifications of this filesystem path by " C:\windows\system32\svchost.exe -k netsvcs ( -p -s Schedule on recent OS)": C:\windows\system32\tasks\*

Modifications of this registry paths by the same process:

software\microsoft\windows\ nt\currentversion\schedule\taskcache\*\path
software\microsoft\windows\ nt\currentversion\schedule\taskcache\tree\*

The task is spawned as a child of one of the following processes depending on the operating system:

  • C:\windows\system32\svchost.exe -k netsvcs -p -s Schedule
  • 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:


In the registry path before the imagepath there will be the name of the service.

This indicator also allows us to identify a variant of this technique that plans to modify a pre-existing service through ChangeServiceConfig* operations in order to stay under the radar: Remote Service Modification

The malware process, that is the malicious service, will be spawned as a child of services.exe

EventLogs: 4624 and 4672 and 4697 or 7045

Remote Process Creation through Win32_Process and WMI Event Subscription

Since there is no persistence, the creation of the remote process can be identified by directly correlating the child processes of wmiprvse.exe.

In case of persistence it is possible to detect the modification by  C:\Windows\system32\svchost.exe -k netsvcs of the following registry key:


The data is saved in these files from C:\Windows\system32\svchost.exe -k netsvcs -p -s Winmgmt:

  1. C:\Windows\System32\wbem\Repository\OBJECTS.DATA
  2. C:\Windows\System32\wbem\Repository\INDEX.BTR
  3. C:\Windows\System32\wbem\Repository\MAPPING*

Unfortunately these files are modified too frequently for other reasons and they make too many false positives also for threat hunting operations, we therefore recommend using the registry key.

Detect malware interactively:

  1. powershell /c "Get-WMIObject -Namespace root\Subscription -Class __EventConsumer | ? { $_.CommandLineTemplate -Match \".*powershell.*-W\ Hidden\ .*\ -E\ \"}"
  2. powershell "Get-CimClass -NameSpace 'root\default' | ? {$_.CimClassName -Match 'systemcore_updater'}"
  3. findstr /i "powershell.exe Event8" C:\Windows\System32\wbem\Repository\OBJECTS.DATA

Sysmon events: from 19 to 21 .

Detecting Infected Hosts

Despite the complexity of the attack in this case it was rather easy to detect infected hosts.

Excluding the most recent versions of the malware, most of the C&C are present in the main blacklists. Through good threat intelligence it is possible to find the indicators automatically and detect these network activities.

Detect at network level hosts where the miners was running via plaintext  json-rpc usage is trivial and it is a very strong indicator for most of the widespread miners.



Once learned that the malware was a distributed cryptominer worm, for the most critical situations we have decided to apply Certego's lockdown procedures.

These procedures rely on enabling, managing and exploiting windows firewall and some of its dependencies to selectively block the protocols used by the malware to perform lateral movements maintaining proper functioning of Active Directory.

These procedures along with network-wide restrictions on the firewall and our telemetry systems allowed to block lateral movements and C&C activities keeping the network under close monitoring, giving us time to carry out the necessary analysis.

Malware Removal

Once the malware was isolated, it was trivial to remove it. For older versions it was enough to simply manually remove the persistence using the following commands:

  1. powershell /c "Get-WMIObject -Namespace root\Subscription -Class __EventConsumer | ? { $_.CommandLineTemplate -Match \".*powershell.*-W\ Hidden\ .*\ -E\ \"} | Remove-WmiObject -Verbose"
  2. powershell "([WmiClass] 'root\default:systemcore_Updater8') | Remove-WmiObject -Verbose"

Considering that the action is irreversible, we recommend that you first check with the commands present in the detection that it is not a false positive.

Once persistence is removed a good updated antivirus is usually enough to kill most of other malware components. If the components have just been updated it is common that the antivirus is not able to kill them. In that case we recommend that you look for the indicators described in the malware execution part.


Given the rapidity of intervention, we cannot exclude that the malware is able to drop other threats in addition to those observed. However, we have not found any other types of malware other than those listed in this article.

We have handled a large number of Active Directory compromises based on this type of cryptominer worm. The attacker's goal seems to be to periodically update cryptominers on all machines in the domain through domain controllers causing a periodic denial of service on the whole domain.

More and more actors begin to perform lateral movements and to exploit AD mechanisms to achieve their goal. Knowing these mechanisms is now an essential prerequisite for managing this type of threats.








Web resources


WMI class: root\default:systemcore_Updater8

WMI filter names: "SCM Event8 Log Filter" or "SCM Event8 Log Filter2"

WMI consumer names: "SCM Event8 Log Consumer" or "SCM Event8 Log Consumer2"

Task Name: sysupdater0

About the author

Gabriele Pippi (Twitter)


Thanks to Davide Setti (Twitter) and Marco Giovanetti (Twitter) for the collaboration.


  • 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


One of the most common techniques for getting a foothold on a network client is based on  Office files containing a malicious VBA macro.
VBA macros are still widely used in a business context and, despite the mitigations offered by security vendors and Microsoft, it is still essential to detect evasion techniques in order to catch smart attackers.

On the attacker's side, there is plenty of public projects to setup, weaponize and obfuscate a macro while on the defenser's side there is a reasonable number of public projects, among the most famous projects to de-obfuscate and detect malicious VBA macro there are certainly  olevbaMacroRaptor and ViperMonkey. At Certego, we also use these tools to perform automatic static analysis of VBA macro.

Today we would like to share a test carried out last week on the resilience of public logic offered by olevba, mraptor and vipermonkey. These tests were even more motivated by some autoexec sub functions identified in the wild that were not detected by our implementation of olevba.

All the tests carried out are aimed at encouraging the red teams to test new bypass techniques and improving the detection of olevba, mraptor and vipermonkey public projects.

Tests scope

  • All tests were carried out on a fully patched Windows 10 client with last build and version.
  • Macro based PoCs must work with medium integrity level.
  • The tests carried out focus on the static analysis that can be performed by mraptor and olevba; in these tests we will consider out of scope the dynamic analysis from the point of view of a sandbox, an EDR and any ASR bypass.
  • During the tests, we decided to include vipermonkey vba emulator in the scope.
  • All the tests carried out start from the assumption that the latest versions of olevba, mraptor and vmonkey have been implemented out of the box.
  • Common users are not always able to complete certain tasks keeping all ASR rules enabled, for this reason we consider disabled at least the following rules:

APT macro analyses

There are many ways to obfuscate a VBA macro, but how much do I have to obfuscate my macro to completely evade the analyses of a prepared blue team? It is important to know the weak points of a VBA obfuscation/evasion technique in order to detect it.

We started by learning from public examples of high-level attacks, then by analyzing through the tools mentioned above some noteworthy APT macro samples.

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:

2019-06-06 graphic.doc, document dropped from the previous sample and called through Word.Application COM.

VBA code:

olevba result:

2) 2016-11-09  election-headlines-FTE2016.docm from APT29

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

APT29 is one of the groups with advanced TTPs

VBA code:

olevba result:

3) 2020-03-03  비건미국무부부장관서신20200302.doc from Kimsuky APT

One of the more recent APT macro.

VBA code:

olevba result:


We have observed that:

  • Some useful functions to obfuscate our macro are used to detect it. Ex: Evilclippy tricks like VBA stomping/pcode obfuscation are currently detected by olevba.
  • There is no known way to obfuscate Sub Events, like AutoExec.
  • There is no known way to obfuscate functions and methods.
  • There are many examples of APT macros that prefer to leave the macro in plain text rather than obfuscate it through a well known technique or suspicious functions.
  • Spotting Win32 Windows API through the Lib Declare Statement is trivial and in some contexts blue teams are beginning to block them through ASR.
  • We also identified the following technical details related to the detection of the examined tools :
    • Obfuscation performed through the Mid and the Array functions is not detected by the examined tools. There are plenty of ways to obfuscate the code and it does not seem worth detecting them all through a static approach.
    • ExecQuery and other dangerous WMI methods to perform code execution like Create are not detected by the examined tools.
    • ExpandEnvironmentStrings method of WScript.Shell Object is an Environ alternative to retrieve environment variables which not trigger by the examined tools:


      Other undetected alternatives could be:
  • In the common implementations of these tools some hits are systematically discarded to avoid false positives. Hex string detection in olevba is an example.

    However, in well-managed infrastructures, it is possible to research some mandatory subroutines, methods and functions to systematically detect macros through a static approach, and to engaging an analyst.

Tests carried out

Starting from these osservations we have tried to build at least one PoC that performs 0 hits on olevba and a "macro ok" result in mraptor.

These are three minimum requirements for getting a foothold through a VBA macro:

  1. An Autoexec Sub Event to trigger our macro.
  2. A code execution method/function
  3. Except for some trivial cases, you will normally need at least a COM/OLE/ActiveX Object, so you need to call at least one function like CreateObject.

Bypassing CreateObject detection

Even if performing alerting only on CreateObject is pretty impossible due to FP, it is possible to avoid this hit in some scenarios through  GetObject.

At the time of writing, GetObject is not reported as a suspicious function by olevba.

Some automation servers have a running instance by default. Using one of these objects, it is possible to use GetObject, avoiding the call to CreateObject at all. See: differences between GetObject and CreateObject.

For these tests we decided to start with one of the most common objects with a default instance: Shell.Application.

Crafting our easy custom undetected obfuscation

After a first look we decided to use the  CLSID avoid Shell.Application pattern match detection. 

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

So instead of:

We used:

However the string was detected in a heuristic way by exchanging the CLSID with a hex string.

As mentioned above, it is a olevba hit that makes tons of FPs like this. 

Despite this fact, we still tried to obfuscate this string creating our own obfuscation technique. It would also come in handy later to obfuscate our exploit.

After some research we discovered that adding chunks of strings to a variable containing an empty string prevents olevba from detecting and deobfuscating the string:

Note: without using a variable olevba detects the technique.

Killing ViperMonkey

After a quick test, we realized that  ViperMonkey is able to decode our obfuscation method.

Despite being a big project, ViperMonkey is a experimental emulator, developers who integrate it into their platform are used to handling considerable number of crashes with legitimate macros, ergo seeing a ViperMonkey crash is not suspicious at all.

To crash vmonkey you need to find some VBA code accepted by our office program that crashes the vmonkey parser.

After some fuzzing we have identified the following simple code:

A declaration of a function with at least one argument inside an if statement will do the job. Microsoft Word will successfully run the macro:

The vmonkey parser will fail:

Undetected code execution methods/functions

We started  digging into the documentation looking for unknown execution methods of Shell.Application Object

This is the section in the olevba code where the suspicious methods/functions list is defined by regex or keyword.

We have identified three interesting examples:

  1. InvokeVerb and InvokeVerbEx: dropping an executable and calling the verb "Open" it is possible to run it. As soon as I spotted these methods I tweeted them.
  2. DoIt: slightly more tricky but same concept of invokeverb.
  3. ControlPanelItem: by dropping a malicious .cpl into the current directory, it is possible to execute malicious code

While we were looking for undetected methods to perform code excecution, we have observed that, surprisingly, the   Create method of Win32_Process, retrievable only through GetObject, is not yet detected by olevba.

However, we decided to avoid it because it has been used in  many opportunistic campaigns and some custom implementations, such as ours, easily detect it.

All other interesting methods of WMI code execution, which are not detected by the analyzed tools, require a  high integrity level, which is out of scope.

Undetected methods/functions to get our malicious file

Since we have identified three methods to launch an executable without arguments, we need a function to get our malicious executables.

In order not to leave our executable embedded in the document we decided to download our sample remotely through an  UNC path

To achieve this task we decided to exploit  SMB redirector or WebDAV redirector, this is because it is not possible to map a UNC resource on a unit or link it with a medium integrity level.

Allowing outbound SMB traffic is a bad practice, so we decided to take advantage of  Webdav over SSL (HTTPS).

So we decided to exploit the  CopyHere Shell.Application method to download our executables via WebDav SSL.

During the tests we also found that:

We decided to avoid FileSystemObject because it didn't work through GetObject, even if it is not enough to detect our samples it was interestingly keeping us on the 0 hits..

Undetected autoexec sub events

This is the section in the olevba code where the autoexec list is defined by regex or keyword

Hunting for undetected autoexec sub event:

Docs/Office/VBA/Reference/<program>/Object model/<object>/Events/<eventname>

We have identified three interesting examples:

  1. Document_ContentControlOnEnter:  it triggers when a user "enters" a content control, there are several content controls that can easily attract a user click.
  2. Worksheet_FollowHyperlink: it triggers when a user clicks on a link inside a worksheet, the link can also point to a worksheet component.
  3. Worksheet_Calculate: "Occurs after the worksheet is recalculated for the Worksheet object", this autoexec sub event is the most interesting we have envied: by using a cell with a formula that points to itself, it is possible to perform an autoexec without user interaction. As shown in the gif of the next section a prompt is shown to the user but, whatever the answer is, the macro is still executed.


The outputs shown below are those of the following command:

 olevba --decode --reveal <doc> # 0.56dev6 on Python 2.7.17



In this case the VB_Base attribute triggers olevba, olevba exchanges the GUID for a Hex String. This is a known and usually filtered false positive. For this reason we can safely consider this sample as one with 0 hits.


Also here as in the previous sample the hit is due to the VB_Base attribute.


For these tests only static analysis is significant, however these are the samples:




As you can see there are few known antivirus and only heuristic signatures.

Suggestions for improvement

In order to detect the techniques proposed through olevba / mraptor, it would be important to note the following:

The previous list was proposed on the public project through the following pull request:


  • We have shown that digging in the documentation and with a little fuzzing it is possible to craft a 0 hit macro.
  • Chaining these samples with an unknown sandbox detection check and esoteric COM objects could have really unpleasant effects.
  • Implementing an open-source out-of-the-box solution may not be enough to defend your infrastructure.
  • It is very important to carry out periodic internal tests on all the detection components of your platform.
  • Performing periodic internal tests on all the detection components of the platform could significantly increase the detection capacity of your platform.

About the author

Gabriele Pippi, Threat Research Lead Engineer ( Twitter)

                                                                                                                  Photo by Jr Korpa on Unsplash

Intel Owl is an Open Source Intelligence, or OSINT solution to get threat intelligence data about a specific file, an IP or a domain from a single API at scale. It integrates a number of analyzers available online and is for everyone who needs a single point to query for info about a specific file or observable.

Born at the start of 2020 (announcement), this fresh and new tool was accepted as part of the Google Summer of Code under the hat of The Honeynet Project. Great improvements have been developed since the start of this project.

Now, thanks to the ongoing collaboration with Google Summer of Code and The Honeynet Project, we are excited to announce release 1.0.0, with a completely new and revamped web interface and some new features in our API to help you better manage your threat intelligence data.

You can read some more details about Intel Owl 1.0.0 in the official release announcement, co-authored by Eshaan Bansal (GSoC Student) and his mentor, our own Matteo Lodi, and published on The Honeynet Project's blog.

Certego has always promoted and supported Open Source Development culture. Some of us are active members of the Honeynet Project and have contributed to some famous open source tools like Cuckoo Sandbox or Thug.

With the goal to help the security community to fight cyber threats, we have released two new projects this year: Intel Owl to aid cyber threat intelligence operations and Pcapoptikon2 to help analysts with writing IDS signatures.

Meanwhile we have been focusing our research on finding new ways to analyze complex malware. Our own Simone Berni has been working on the development of a new open source tool and just recently, also thanks to his work, its first 1.0 version was released: Qiling, an advanced binary emulation framework.

On the 25th April 2020, Simone had the opportunity to show the results of his work at the famous Hack In The Box Security Conference together with the Qiling creator, Lau Kai Jern

For those interested in technical details, you can find them in the next section; you may also find the full video of the conference here: Youtube

HITB Conference: Technical details

Qiling is an advanced binary emulation framework that supports Windows, MacOS, Linux and BSD.

Written in Python and based on Unicorn EngineQiling is designed to provide high level APIs and fine-grain instrumentation, allowing you to place hooks at every level.

Certego chose to help the development of Qiling with Simone Berni's work.

During his presentation, Simone showed how it is possible to use Qiling as a sandbox to analyze arbitrary malware.

In particular, he prepared two different demo scenarios: Al-khaser and Gandcrab.

Al-Khaser Demo

The first scenario is a POC malware application that aims to stress an anti-malware system by checking if the sandbox is fortified and stealthy enough.

During the emulation of Al-khaser, it is possible to understand two things mainly: how stealthy Qiling is and how much it is easy to use. Not everything of Al-khaser has been emulated, Simone implemented only the debugger detection task.

Moreover, Qiling does not pass every single test made by Al-khaser (it passes 85% of checks) but the developers are working on them even right now.

The second point of this demonstration is to understand how we can use Qiling to perform a deep analysis: for example, the emulation of the function that prints the output had an issue: thanks to the API offered by Qiling, Simone was able to replace this function entirely with just 3 lines of code, thus obtaining the expected outputs.

GandCrab Demo

Here, we are talking about a famous ransomware, which is very interesting because it uses different sandbox evasion techniques before executing itself.

The demo of Gandcrab shows how powerful Qiling can be when used as a sandbox. Simone, during his work, implemented the concept of "Profiles", later extended by the Qiling team, and the core feature to analyze malware.

The profile is just a configuration file that describes everything about the emulation: it started as a simple file containing only the Windows version that Qiling has to emulate; later, it was extended to contain information about the Volumes, Drives, Permissions and Network configuration. Now it is possible to have a profile for every OS (Linux, BSD e MacOS are supported), and it is even possible to change the emulation parameters from this config file.

Simone demonstrated how much information it is possible to retrieve thanks to Qiling during the analysis of a ransomware like Grandcrab: every registry accessed is stored, every "printf" is saved (so it is possible to retrieve memory that has been copied from one place to another), every syscall and kernel call is stashed for future analysis. With a little bit more details, he explained how Gandcrab tries to retrieve every piece of information about the victim machine and how the malware stores the stolen information.

At the end of the demo, Simone shows how it is possible to change the Profile to change the behaviour of Gandcrab.

For example, you can change its permissions: when Gandcrab is executed as a user, it will spawn a shell to re-execute itself as administrator.

Another strange behaviour Simone discovered can be observed when you apply a russian keyboard layout in Qiling. Again, this is possible to do so by simply adding a registry key and the desired value to the profile. When executed in an environment that has a russian keyboard, Gandcrab would kill itself.


Qiling is a powerful tool, continuously developed and improved every single day: in the future it will be a common framework that malware analysts have to be familiar with.

Certego will continue to contribute to this project to improve the chances of everyone in fighting malware.

Photo by Maximalfocus on Unsplash

We are proud to announce that Certego has joined the community of Contributors to VirusTotal, the biggest aggregator of antivirus engines and website scanners.

VirusTotal is a free service that everyone can use to check for virus or threats in a file, URL, domain or IP address by leveraging more than 70 antivirus scanners, blacklisting services and analysis tools provided by the global security vendors. Founded in 2004 by a Spanish company, VirusTotal was acquired by Google in 2012 and, in 2018, the ownership switched to Chronicle, a subsidiary of Alphabet.

Starting from this week, most of the intelligence data generated by Quokka, the Threat Intelligence Platform developed by Certego, is available to the VirusTotal community.

The Quokka platform was designed by a team of experienced malware analysts with passion and a strong commitment. The Threat Intelligence Team has mixed different tools, including Honeypots, real “traps” for the cyber criminals, and Sandboxes, virtual environments where it is possible to execute and study malware automatically and at scale. The result is a platform that enables Certego to gather relevant information in real time to track cyber criminal activities.

Additional technical details

We would like to show some examples of what kind of information users can find by leveraging together the power of VirusTotal multi scan engine and the Certego Intelligence information.

You could be a tech guy or not. In both cases, it surely happened that you found a strange link inside a suspicious email you received and you wanted to verify it before clicking it. One way could be to go to the VirusTotal website, select the URL scan, insert the suspicious link in the input bar and ask for an analysis.

After some seconds, you would find the results of the analysis.

For this specific example, the Certego engine detected the URL as containing “Phishing”.

This evaluation helps the end user because, if he had visited the site, he would have found an Outlook account phishing page identical to the real one.

Other than “Phishing”, there are other possible evaluations that can be found after an URL analysis.

The “Malicious” and “Malware” detection are used to notify if a specific URL or domain was observed to serve malware or simply it was involved in cyber crime activities. Example:

The “Suspicious” detection is used to notify when a specific URL or domain is or was probably involved in malicious activities. For these cases, the engine does not have a clear evidence so it just suggests that the site should be avoided as a precaution. Example:

The last case is the “Spam” detection that is used to notify when a specific URL or domain was embedded inside a lot of emails that were sent massively to many inboxes so it is a link that you probably do not want to click. Otherwise, IP addresses are tagged as “Spam” when they have been observed to send a lot of spam, so they are probably related to the presence of a spambot. Example:

Certego is proud to contribute to the security of all the users in the world through the VirusTotal community

About the author:

Matteo Lodi, Threat Intelligence Lead Engineer (Twitter).

Hello everyone, this is Gabriele Pippi, from the Certego Purple Team.

Today we are ready to publish the tool we are using to perform digital forensic and incident response on Citrix Netscaler ADC based on FreeBSD.

Our point of view on CVE-2019-19781 exploitation

After the first mad release of the POC for CVE-2019-19781 by the github account @projectzeroindia and first exploitations, trustedsec and other members of the community provided the first details to carry out digital forensic and incident response operations.

Our Incident Response Team from the first engagements has verified the following conditions:

  1. All the Netscaler ADC analyzed run on FreeBSD kernel version. Unlike in FreeBSD core, there were several utilities installed on the machine, such bash2, used for this script.
  2. The code executed remotely with the CVE ran with nobody user, there were no easy privilege escalations and the persistence on the machine was easily circumscribed; we found cronjobs, php webshells and perl scripts.
  3. Some attackers tried to exfiltrate a file called ns.conf, which contains a large number of sensitive information, especially encrypted passwords and hashes. This is an advanced way to exfiltrate ns.conf.

After the first engagements there were some important implications:

  1. The hashes contained in the ns.conf file were already supported and crackable by hashcat since 2014Reference
  2. Some passwords in the ns.conf are encrypted with AES256-CBC or AES256-ECB algorithms using a well-known key, compiled in a library. These passwords can be decrypted immediately. Among these we also found AD domain admin.
  3. The default root password of Citrix Netscaler AMIs is set to the instance ID: this makes trivial a privilege escalation on all installations of this type. Reference
  4. Recently, some actors are starting to exploit this CVE for ransomware campaigns. Reference

Certego Netscaler Threathunter

I developed this bash2 compatible script in order to automate all checks and facilitate threat hunting operations.
The script is designed to provide output to an analyst who will then carry out the analysis.

Note #1: we take no responsibility for any improper use of this script. We recommend using it with caution on critical systems in production.

Note #2: except for its optional log file, the script does not perform any writing operations, does not need any installation and can also be launched in fileless mode.


  • Netscaler running on FreeBSD Kernel Version.
  • nsroot or root privileges.


This script aims to:

  • validate patch of CVE-2019-19781.
  • enumerate persistences and artifacts related to CVE-2019-19781.
  • guide users to change ns.conf credentials to avoid future campaigns and to patch quickly.
  • spot possible advanced privilege escalation.

For further technical details and to download the script, please refer to the official github project Netscaler_Theathunter.

All Citrix Official Advisories

About the author

Gabriele Pippi, Threat Research Lead Engineer (Twitter)

Happy new Year to everyone!

We would like to open this new decade by releasing a new tool that is called Intel Owl. We hope that it could help the community, in particular those researchers that can not afford commercial solutions, in the generation of threat intelligence data, in a simple, scalable and reliable way.

Main features:

  • modern Django-Python application: easy to understand and write code upon it
  • it can get data from multiple sources with a single API request
  • 40 available analyzers that you can use to generate or retrieve data about a suspicious file or observable (IP, domain, …)
  • official client available on Github: PyIntelOwl
  • easily integrable with other tools thanks to the REST API framework and to the PyIntelOwl library.
  • easily and completely customizable, both the APIs and the analyzers
  • early compatibility with some of the AWS services. More in the future.
  • fast and reliable deploy: clone the project, set up the configuration and then you are ready to run it via docker-compose

For more information, we invite you to check the documentation and the code available on Github.

Feel free to ask everything it comes to your mind about the project to the author:

Matteo Lodi, Threat Intelligence Lead Engineer (Twitter).

Every suggestion or contribution is really appreciated.

Keep hunting malware! We cheer on you :)

Hi there, this is Gabriele Pippi, from the Certego Purple Team.

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

Note #1: this must be considered a beta version of the script; the author assumes no responsibility for any damage caused by running it.

Note #2: currently the malware sends the password both as plain and cypher text; we believe the behavior may change soon as the malware is updated, and the plain text form may not be available anymore.

Note #3: decrypting files with an incorrect password may make them unrecoverable; so, we recommend taking a backup of the files before running the script.

Why should a password-based decryptor be useful?

Since the first observed campaigns, documented in this article, we have noticed that FTCODE was sending the password in plaintext within the body of an HTTP post request to the C&C.
Once implemented the relevant Suricata signatures, I decided to develop this tool internally, in order to make the decryption operation feasible.
In all of the cases we had the opportunity to put hands on, we were able to recover the encrypted files up to version 1018.1.

Network Traffic

In order to be able to decrypt the files successfully, it is necessary to intercept the contents of the POST request that the malware sends to the C&C at infection time; an example of such request follows:

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

In order to intercept the POST request, we developed the following Suricata signature, and deployed it to our network monitoring system:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CERTEGO TROJAN FTCODE Registration Request (m.bompani)"; flow:to_server; content:"POST"; http_method; content:"ext="; http_client_body; content:"guid="; http_client_body; content:"ek="; http_client_body; classtype:trojan-activity; sid:9000931; rev:1;)

What does the tool do?

Given the extension and the password, the tool is able to recursively decrypt the encrypted files in all the mounted disks or in a given path.

It offers the following features.

  • In-memory fileless utilization: it is possible by wrapping the script in a function, leveraging the built-in PowerShell cmdlet Invoke-Expression
  • Logger: it traces the activities carried out, leveraging two cmdlets described at Start/Stop Transcript
  • Backup: it backs up all the files that the tool will try to decrypt.
  • Some options were added to the script for possible future uses.

Additional Details

For further technical details and demonstrations, please refer to the official github project FTdecryptor

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

About the author

Gabriele Pippi, Purple Team (LinkedIn)

Hi everyone! Today we are talking about a new ransomware we spotted being distributed in the wild dubbed as FTCODE.


  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.

At the start of this year, a specific actor started to leverage a legitimate certified mail service, mainly used in Italy, called PEC (Wikipedia). This service is particularly trusted by its users and is commonly used to deliver electronic invoices. Therefore, it’s of special interest because it’s easier to lure potential victims with malicious emails that refer to fake invoices.

Until the last week, the Gootkit banker was delivered as the final payload of the infection chain. (Certego Gootkit analysis)

During this year, the way to deliver this threat changed: they started to leverage a new simple but effective downloader dubbed as JasperLoader to deliver upgrades and additional modules when needed. (Talos research).

However, even if sophisticated, Gootkit is old malware. Also, it does not monetize fast and does require special interaction by the user. So, they have started experimenting with ransomware, maybe to understand if they can get more from this kind of infection.

We are talking about a raw ransomware fully written in Powershell code, called FTCODE.

Even if the name could seem new, the first appearance of this threat was in 2013, as stated by Sophos. Then, almost nothing was seen for about 6 years. Strange, but we have to remember that technology changes. Windows XP was widespread at that time and, by default, Powershell is installed only from Windows 7 on. That can be a problem because actors need to install powershell itself before running ransomware. Also, cyber security was not mature as it is nowadays so, for instance, classic Zeus-like bankers were more effective.

Indeed, last year we saw the arrival of a new downloader and backdoor written in Powershell that was called sLoad and it’s still being actively distributed (Certego sLoad analysis).

KISS (“keep it simple and stupid”) they teach you during software engineering courses. So, why strive with sophisticated malware when with a bunch of code written in Powershell you can perform every kind of wickedness?

So let’s dive in more technical details to understand how FTCODE works.

Mainly we analyzed two samples from two different campaigns:

  • version 930.5, md5: a5af9f4b875be92a79085bb03c46fe5c, day: 01/10/2019
  • version 1001.7, md5: 8d4c81e06b54436160886d78a1fb5c38, day 02/10/2019

2.Payload Delivery

As stated before, the user receives an email that refers to a fake invoice with an attached document called "Fattura-2019-951692.doc". The threat actor leverages a commonly used template to trick the user to disable the “Protected View” mode and to trigger the execution of the malicious macro.

Once enabled, the macro runs and spawns the following Powershell process:

The result is the download of a piece of Powershell code that is run using the "Invoke-Expression" command (“iex”). Note that the function “DownloadString” saves the result of the request only in memory, in an attempt to avoid antivirus detection.

The new Powershell code is FTCODE itself. On execution, it performs the following GET request:

to download a Visual Basic Script file and save it in "C:\Users\Public\Libraries\WindowsIndexingService.vbs".

This is a variant of JasperLoader, a simple backdoor that is able to download further payloads.

Then, it tries to create a shortcut file called "WindowsIndexingService.lnk" in the user's startup folder that runs the JasperLoader. Finally, to achieve persistence after reboot, it creates a scheduled task called "WindowsApplicationService" pointing to the shortcut file.

3. Environment Preparation

After having installed the JasperLoader backdoor, FTCODE starts to prepare the environment for the ransomware attack.

It verifies if the file "C:\Users\Public\OracleKit\w00log03.tmp" exists. If yes, it would check the presence of some files with the extension ".FTCODE" in all the drives with at least a free space of 50 KB. If there are some, it means that the machine was already attacked by the ransomware, maybe by a previous version: therefore, it would exit.

De facto, this indicator can be used to “vaccinate” the endpoints from this threat. It’s enough to create the mentioned file with any kind of content to let FTCODE believe that the computer was already infected.

Afterwards it generates a random globally unique identifier (GUID) and a password consisting of 50 characters with at least 4 non-alphanumeric characters.

Then we found a hardcoded RSA public key that is used to encrypt the password. In this way the password cannot be deciphered without the proper private key controlled by the malicious actor and can be sent, in a secure way, to the attacker’s server.

Surprisingly, the encrypted password, after being generated, is never used elsewhere in the code and, instead, is just sent the basic base64-encoded password to the attacker’s server.

The consequence is that, if the traffic against the attacker’s server is being monitored, it’s possible to retrieve the key that will be used to decipher the files, without paying any ransom.

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

After that error, FTCODE performs a POST request to the following URL:

with the following parameters:

  • ver=930.5, version number
  • vid=dpec2, probably to identify the campaign
  • psver=Powershell Major Version, probably to understand if FTCODE needs an update from JasperLoader
  • guid=the GUID generated previously, to identify the victim
  • ek=the previously generated password encoded in base64

if the server response is "ok", it creates the file "C:\Users\Public\OracleKit\w00log03.tmp" containing the GUID. If the server response is different, it would exit. This is another protection mechanism to evade execution in simulated environments.

Afterwards, it tries to run the following commands that are commonly used by almost every ransomware to avoid the chance that the victim can recover the encrypted files without paying:

Similar behaviour is performed by Sodinokibi: Certego blog

4. Ransomware Attack

At this moment, everything is ready to perform the real attack phase.

FTCODE checks for all the drives with at least 50 KB of free space and it looks for all the files with the following extensions:


Then, it encrypts the first 40960 bytes of each of them using the “Rijndael symmetric key encryption”. The key is created based on the previous generated key and the hardcoded string “BXCODE hack your system”. The initialization vector is also based on another hardcoded string ("BXCODE INIT").

Finally it appends the extension ".FTCODE" and creates the file "READ_ME_NOW.htm" in the folders that contain the encrypted files. We are talking about the classic ransom note with instructions on how to recover the encrypted file.

5.Version changes

We believe that this ransomware is in active development. Just one day after the delivery of the version 930.5, we saw another version distributed (1001.7). Malware authors noticed that, in the first version, there was no mechanism to tell the threat actors if the file encryption was successful or not. So, they added other 2 lines of code that trigger other 2 C&C POST requests with the following new parameters:

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


Actors change their tactics faster and faster. But we understood that they could be lazy and they can make mistakes too. They are humans after all.

Some of them are starting to prefer ransomware like FTCODE over classic infostealers and bankers.

Also, we found that, monitoring the network traffic, it’s possible to retrieve they key used to encrypt the files.

So, it’s important to continuously monitor your own assets, both on a network and an endpoint level, to fight against these kind of threats.

Certego Threat Intelligence Team has been studying upcoming cyber threats for years in order to provide the best protection to their customers.

Suricata IDS signatures

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CERTEGO TROJAN FTCODE Payload Request"; flow:to_client; content:"FTCODE"; http_server_body; nocase; content:"vssadmin"; http_server_body; nocase; reference:url,; classtype:trojan-activity; sid:9000999; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CERTEGO TROJAN FTCODE Registration Request"; flow:to_server; content:"POST"; http_method; content:"vid="; http_client_body; content:"psver="; http_client_body; content:"guid="; http_client_body; content:"ek="; http_client_body; reference:url,; classtype:trojan-activity; sid:9000998; rev:1;)



About the authors

Matteo Lodi, Threat Intelligence Lead Engineer (Twitter)

Marco Bompani, Security Analyst (Twitter)


Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Hi everyone! Today we are looking at a threat that appeared recently: a new ransomware called Sodinokibi.


  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

The first noteworthy appearance was at the end of April (Talos Research).

Then, at the start of this month, we gathered different reports of this threat being spread in Italy (eg: JAMESWT_MHT's tweet), both via malspam and known server vulnerabilities.

Also, there was the announcement of the shutdown of the GandCrab Operation (Bleeping Computer), just some days earlier.

Coincidence? We’ll see.

Our guess is that this new payload could be used as a replacement of GandCrab in the RAAS (Ransomware-as-a-service) panorama.

Therefore, in order to protect our customers effectively, we went deep into the analysis of this ransomware.

Mainly we analyzed two different samples:

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

2. The Loader

Like every malware who deserves respect, Sodinokibi is protected by a custom packer that is different for each sample.

The method used by the version 1.01 sample to reconstruct the original payload is called “PE overwrite”.

To perform this technique, the malicious software must allocate a new area inside its process memory and fill it with the code that has the duty to overwrite the mapped image of the original file with the real malware payload. In this case, first the process allocates space in the Heap via LocalAlloc, then it writes the “unpacking stub” code, it signs that space as executable with VirtualProtect and finally it redirects the execution flow to the new memory space

In order to slow the analysis, the loader contains a lot of junk code that will be never executed.

Also, in the following image, we can see that it tries to hide some important strings from the static analysis like “ kernel32.dll”. It leverages “stack strings” plus the randomization of the order of the characters.

At this point, the unpacking stub resolves dynamically the functions that he needs like VirtualAlloc. Then it performs the overwrite of the original image base with the new decrypted payload.

Finally, it transfers the execution to the OEP (Original Entry Point) of the unpacked Sodinokibi payload.

3. Mutex and Configuration

Once unpacked, the sample tries to create a mutex object. It calls CreateMutexW, then, if there was an error, with RtlGetLastWin32Error it would extract the generated error. Indeed, if the mutex already existed, the error would have been “0xB7” ("ERROR_ALREADY_EXISTS" ref docs). In that case a function is called that terminates the process.

We found that the mutex name is different for each sample but following this pattern: “Global\{UUID}”. Therefore it’s a method to detect the malware or to vaccinate the endpoint (Zeltser blog) that is reliable only for a specific sample.

Going forward, we found the configuration in an encrypted form in the section “ .zeacl” for v.1.01 or “.grrr” for v.1.00. Once extracted, we noticed that it’s a JSON file.

These are the keys found in the configuration.

  • pk” -> base64 encoded key used to encrypt files
  • pid” -> personal id of the actor
  • sub” -> another id, maybe related to the specific campaign
  • 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

If you are interested in manually checking the configuration files we have extracted in the samples we have analyzed, follow this link and download the archive (password:sodinokibi):

4. Machine information recovery

Afterwards, Sodinokibi starts to gather information about the infected machine and builds another JSON structure that stores in an encrypted form in the “HKEY_LOCAL_MACHINE\SOFTWARE\recfg\stat” registry key.


  • ver”: version (100 or 101)
  • pid”: previous config “pid”
  • sub”: previous config “sub”
  • pk”: previous config “pk”
  • uid”: user ID. It’s a 8 byte hexadecimal value generated with XOR encryption. First 4 bytes are created from the processor name, while the others are created from the volume serial number extracted with a “GetVolumeInformationW” API call.

  • sk”: secondary key, base64 encoded key generated at runtime
  • unm”: username
  • net” : hostname
  • grp”: windows domain

  • lng”: language

  • bro”: brother? Sodinokibi retrieves the keyboard language with GetKeyboardLayoutList. Then it implements an algorithm that gives “True” as value for this key only if the nation code ends with a byte between 0x18 and 0x2c. It’s not odd that inside this range there are the majority of the East-Europe language codes, like Russian, Cyrillic and Romanian. It’s a clear indication of the origin of the malware authors.

  • os”: full OS name

  • bit”: Sodinokibi extracts this value from “GetNativeSystemInfo” then it compares with 9 that corresponds to the x64 architecture. Further processing will generate “40” if the architecture is 64bit, “56” otherwise.

  • dsk”: base64 encoded value generated based on the drives found on the machine.
  • ext”: new in 1.01. The random extension used for encrypted files.

5. Encryption preparation inspired by GandCrab

At this time, before performing the encryption, Sodinokibi replicates a behavior that is very similar to what GandCrab performs, suggesting that Sodinokibi authors learned from GandCrab ones or that they are strictly related.

Sodinokibi extracts the running processes with the combination of CreateToolhelp32Snapshot, Process32First and Process32First and checks if they match the names in the configuration. In that case, those processes are killed. The reason is that these programs could hold write access on files and therefore they could not allow the ransomware to encrypt them.

The list of the version 1.00 contains only the “mysql.exe” process, while the list of the version 1.01 is a lot longer and almost matches the ones used by GandCrab (source: Symantec).

Afterwards, like his predecessor, Sodinokibi deletes the shadow copies with the leverage of the “vssadmin” native utility. In addition, it uses “bcdedit” to disable windows error recovery on reboot.

Another check done by the ransomware is for available network resources with WNetOpenEnumW e WNetEnumResourceW with the aim to find other files to encrypt.

Last operation before the encryption is to find all the directories with a name that matches the configuration key “wfld” and to wipe them. In this case, the list contains only “backup”. So, for example, Sodinokibi deletes Windows Defenders updates backups.

6. Ransomware attack

Finally (or not?) Sodinokibi starts to iterate over the available directories with FindFirstFile and FindNextFile.

It skips files and directories that match conditions on the whitelist configuration. The others are encrypted by the ransomware that adds the random generated key as extension to the name.

In each directory the malware also write the ransom note “{ext}.readme.txt” extracted from the configuration and a lock file.

Then it creates a file with a random name “{random}.bmp” in the %TEMP% which contains the image that will be put as a background with the help of DrawTextW and FillRect functions.

7. C2 Registration

Once the encryption is finished, Sodinokibi starts to iterate through a giant list of domains hardcoded in the configuration (about 1k). These domains are the same across the samples we analyzed but they are ordered differently in order to mislead the analysis.

At a first glance, these domains seem legit and most of them are correctly registered.

This is not a classic DGA but the result is almost the same because the purpose is to hide the real C&C Server used by cyber criminals.

For each domain listed, Sodinokibi generates a random URI. Then it uses the winhttp.dll library functions to perform HTTPS POST requests with the created URLs.

The data sent with the POST request is an encrypted form of the JSON configuration saved on the “HKEY_LOCAL_MACHINE\SOFTWARE\recfg\stat” registry key and described on the “Machine information recovery” section. In this way, malicious actors can collect important information of the infected machine.

The following are examples of some of these URLs:

Looking at an analysis of this sample in a sandbox (AnyRun), we noticed that HTTPS requests where not correctly listed. The malware can avoid traffic interception by proxies like Fiddler or Mitmproxy that are used for manual or automatic analysis.

How? The second parameter of the WinHttpOpen function is 0 which corresponds to “WINHTTP_ACCESS_TYPE_DEFAULT_PROXY”: this means that the configured proxy is skipped and the HTTP connection won’t be logged. This trick could mislead the analysis if not properly handled.

I suggest to read the following blog post where it’s further explained how these URLs are generated and why also this routine is inspired by GandCrab code: Tesorion analysis

8. Conclusion

Sodinokibi could be the heir of GandCrab. It’s still at version 1.01 so maybe it’s not mature yet but is actively developed and updated

Malicious actors have started to use Sodinokibi to generate profit, even in Italy.

It’s important to continuously monitor your own assets, both on a network and an endpoint level, to fight against these kind of threats.

Certego Threat Intelligence Team has been studying upcoming cyber threats for years in order to provide the best protection to their customers.



About the author

Matteo Lodi, Cyber Threat Intelligence Team Leader



Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

Today we are going to talk about one of the biggest threats that is spreading in these days, in particular in Italy: Dreambot, the most recent version of a malware also known as Ursnif, or Gozi.


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

1. The Threat

Ursnif belongs to the category of Infostealers. It was already analyzed by a lot of skilled researchers. I list just some of the best analysis you could find:

In this article, we'll focus on the initial communication with the Command & Control infrastructure.

2. The Check-In phase

At the time of the compilation of the malware, spreaders can choose a list of domains that will be hardcoded in the sample in an encrypted form.

For example, the following image shows 3 different domains uploaded into the memory of one of the variant that we analyzed.

The malicious agent tries to perform its initial communication with the first of the list, then, if it fails, it would try with the next and so on.

We underline that this "beacon" is always performed via plain HTTP while the following steps of communication are done via SSL encryption and custom certificates.

This is important because, with the right eye, even without SSL interception, we can pretty easily spot if something is going wrong.

The following image shows 3 different attempts to communicate with the C2 server in a sandbox environment. 

If the pattern is not known, an untrained analyst could be misleaded by this behaviour while performing threat hunting on network logs or artifacts.

The file extension ".avi" refers to video files. Also, the path "/images/" is deceptive. In addition, it's performed as a "GET" request. All of this evidence could be seen as a normal download of a video file from a site hosting media.
In fact it's the check-in of the malware that is sending basic information about the compromised machine, hiding them in plain sight in the URI path.


Decoded data:

  • fjidtflrb -> junk param, always present at the start of the URI to generate randomness (and always different)
  • soft -> major version
  • version -> minor version
  • user -> unique user id
  • server -> unique c2 server id
  • id -> bot group id
  • crc -> payload to retrieve (1-DLL 32bit, 2-DLL64 bit, 3-ps1)
  • uptime -> time elapsed from initial infection (seconds)

The following image represents the phase when the malware creates the first parameter:

After having seen a lot of this kind of patterns on Ursnif samples in last years, I decided to create a simple and raw tool that is able to decrypt the URL created by the malware on the fly.

In this way it's possible to spy the configuration sent to the Command & Control server and, at the same time, to check if the URL is related to this threat. 

All of this without any need of manual reverse engineering.

You can check the simple tool that I created on the following link on: Github

This is an example of how to run the script:

and the related output:

3. Encryption routine

The custom algorithm starts with a symmetric encryption that leverages the Serpent cipher in CBC mode and a null IV (initialization vector). 

Afterwards the result is encoded with a classic base64. Considering that base64 encoding is pretty easy to spot, malware authors decided to change things a little more. They removed padding characters("=") and substituted the other special characters ("+", "/") with the relative ASCII code, after having prepended them by an underscore ("_2f", "_2b"). The last tweak is to add slashes at specified offsets to let the URI to appear like a real one.

Obviously, the Serpent encryption needs a key. We can find it hardcoded on the malware sample. Some code level analysis could be required to get that info.

However, observations led to the fact that the key is usually shared among a lot of samples and rarely changed.

If you don't have one, just run the script: it would try a predefined list of known keys for you.

It's really appreciated if you want to share new keys that you find with us. Feel free to contact us on Twitter or LinkedIn

4. Injected Internet Explorer? Or not?

While investigating the check-in phase, we noticed an unusual fact that we think it's worth to mention.

As you can see from the analysis of AnyRun, the malicious beacon seems to be sent by an Internet Explorer instance after the malware has run.

Considering that Ursnif is known to perform injection on browsers to steal information, an unaware analyst could think that the malware already decided to perform some form of memory injection into a new spawned instance of Internet Explorer to masquerade the communication as a legit one.

However this is unecessary. It's enough to use the COM (Wikipedia) library that is provided by Microsoft.
Looking at the code, we can detect this behaviour with the finding of the function CoCreateInstance that were made just before the network communication.

This one is a stealthy way that could mislead both analysts and security products if it has not been taken in consideration.

If you like to have a more detailed explanation on COM and, in general, on how to detect malware C2 communications while reverse engineering, I suggest the following reading: FireEye Blog


Ursnif has been trying for years to make analysis difficult for people and detection for security products.

We went deep into the communication performed during the check-in phase and created a new tool to help to analyze and detect the malware.

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


About the author:

Matteo Lodi, Cyber Threat Intelligence Team Leader 

If you know something more about protocols used by Ursnif for C2 communications or if you'd like to improve the tool(Github), feel free to contact me at any time.



Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.