Cofense Intelligence has observed several recent Sigma ransomware campaigns that demonstrate either a new iteration or a fork of this malware. Prior to these new campaigns, the actors behind Sigma stuck rigidly to two very distinct phishing narratives, as detailed in Cofense’s recent blog post, and relied on the same infection process. With these newly observed changes, Sigma’s operators have eliminated various infrastructure concerns and improved the UX (User eXperience) of the whole ransom process, representing the first major shifts in Sigma tactics, techniques and procedures (TTPs).
The actors behind Sigma have made two additional radical changes to the infection and extortion model. The first change is a move away from the standard downloader model (Figure 1) to an introduction of an intermediate downloader, as seen in Figure 2. This change demonstrates a step toward the more standard deployment TTPs of most mainstream actors. It is possible the actors behind Sigma took this unusual step as a proof-of-concept to test the time it takes for security actors to respond to the campaigns, relative to the originals. It is also possible this was a move borne of desperation, given the consistent infrastructure disruptions that have likely contributed to the overall decline of ransomware activity in 2018.
Figure 1: Standard Sigma infection process
Figure 2: Updated Sigma infection process
In a second change, the actors have shifted from relying on .onion services for ransom payment communications to an encrypted email platform, thereby making it easier for victims to pay and removing opportunities for infrastructure disruption.
Reaching the Endpoint: Distributing Stage One
The two campaigns identified by Cofense Intelligence both use an intimidating narrative intended to force the potential victim off-balance and make him or her more likely to open the attachment: a subpoena commanding the recipient to appear in court, as seen in Figures 3 and 4
Figure 3: Example message from the first campaign
Figure 4: Example message from the latest campaign. Note all visible content is identical
The fabricated subpoena demands the presence of the victim at a ‘time, date and place’ that is unspecified within the message body and supposedly within the malicious attachment. The call-to-action is buried within the text and requires the victim to study the contents of the attached document carefully to avoid further indictment.
The message bodies are an inline image, as opposed to text. Although they may appear identical, each image has a different hash, indicating at least a small difference. This technique is used for several reasons, chiefly to complicate the process of identification. Combining a textless body and a password-protected document provides very little concrete data for a security application to latch onto, limiting their efficacy. An example message body can be seen in Figure 5.
Figure. 5: A redacted message body, demonstrating a lack of identifiable features
Astute readers will note the empty body of the text/plain mime section. This means any recipients who either do not have an HTML-enabled MUA (mail client), or have chosen to disable HTML, will see an empty message, with attached .png and .doc files (Figure 6).
Figure 6: Messages as viewed in plaintext.
Attachments
The attachments in both campaigns contain weaponised macros, written to facilitate the download and subsequent execution of the intermediate payload. The macros contained within the documents across both campaigns are identical; an example can be seen in Figure 7.
These attachments lack any real obfuscation, likely because the actors rely on the protection layer offered by Office’s own symmetric encryption once the password is added to the documents. The password here is provided as an image within the message body, as opposed to a plaintext password. Although this is trivial to overcome, an Optical Character Recognition (OCR) software or something similar is required to retrieve the password automatically. Such a maneuver has the same objectives as code obfuscation: to slow or prevent analysis and to prolong the viability of the threat actors’ infrastructure. Although this tactic requires an increased number of total stages in the infection process—contrary to a mainstream preference for fewer stages and thus fewer possible points of failure or disruption— here, the priority is getting the phish past automated technology and to the user’s inbox.
Figure 7: The macro used across both Sigma campaigns
The only obfuscation technique is a simple encoding of Unicode characters to their decimal equivalents, instead of including them directly. A tidied-up version of this code can be seen in Figure 8.
Figure 8: Tidied up and commented macro
The file downloaded by this macro is the new intermediary downloader. The downloader is an NSIS installer (similar in action to an SFX archive), which is tasked with downloading and executing the primary Sigma payload. The installer contains two DLLs – InetC.dll (Figure 9) and <random_chars>.dll (Figure 10) – responsible for internet connectivity and encryption/decryption, respectively. It should be noted that both of these DLLs are benign and merely abused by the threat actors involved. In addition to the two, clean DLLs, the installer also contains a .nsi script.
Figure 9: INetC.dll exports
Figure 10: <random>.dll exports
The .nsi (NullSoft Installer) file is a script, written in a simple, proprietary language. The script files are typically responsible for bootstrapping embedded executables. In this instance, it is repurposed to function as a downloader. A snippet of the original script (Figure 11) contains the script actions, as well as comments that detail the execution flow in a stack-like manner. Figure 12 details the same script, with superfluous comments removed, and pertinent comments injected.
Figure 11: Original NSIS installer script
Figure 12: The NSIS installer script, with additional comments and decryption
The installer contains two different encrypted strings, together with the values required to decrypt them:
URL
nqI5r2b9B2gXQwzIU+OSP6ZhqB5mYdo1JDTZXrnN0/JJe2GS6jtGx+ogdNNq0tlB
Key
g3kteHb9xhvAxLrMbkEWZfap9Xm9B7X3
IV
a2gRazGA2jASynt8
Filename
08cTOVZM9VK9bTVm8TPPxw==
Key
m2uk23cFjyX6by7erZ7tBDaGtCLyNnx2
IV
Rnpr6aKVdMJHZABH The encryption algorithm used is 3DES (TripleDES) in CBC mode. The NSIS documentation details the arguments and the order in which they’re passed to the DecryptSymmetric function:
NsisCrypt::DecryptSymmetric “base64 encoded cipher” “algorithm” “base64 encoded key” “base64 encoded iv”
With this detail, decryption of the strings is trivial, and reveals not only the target URL from which the resultant payload will be obtained, but also the filename with which it will be saved.
While not incredibly sophisticated, the intermediary NSIS downloader demonstrates greater effort to protect the final payload location.
The Final Link in the Chain: Sigma Ransomware
If the downloader is successful, it will retrieve and execute a RAR SFX archive, which is password protected with the password 252589. Similarly, in principle, to the NSIS installer, this RAR SFX archive is a type of installer with an installation script built-in to the executable itself. Details of the execution procedure can be seen in Figure 13.
Figure 13: The RAR SFX archive execution instructions
The SFX archive silently extracts its contents to the current user’s %temp% directory, and subsequently executes the file svchost.exe. The password-protected SFX archive is extremely problematic to detect. At the time of writing, it has 7/67 detections on VTI. Extracting and scanning the embedded executable, however, is a completely different matter. Indeed, svchost.exe has a detection of 22/67 that, while not amazingly high, is certainly better than its encrypted parent. This shows the extent to which simple password protection, using free and commonly-used utilities, can significantly reduce the efficacy of anti-virus scanners.
After execution, Sigma tidies up its installation files and waits for a short amount of time. After confirming internet connectivity, it will retrieve files necessary to facilitate communication with the TOR network. Next, it will check-in with a hardcoded .onion service before continuing connections with anonymous TOR nodes. This is all standard behavior for Sigma ransomware until it comes time to demand the ransom. Sigma has classically relied upon .onion service to host its extortion services. This variant, however, abuses protonmail.com, and demands the user email sigmacs[@]protonmail.com to begin ransom negotiations. The “cs” in this example most likely stands for “customer support” – an example of the client/business model ransomware authors frequently attempt to emulate. An example ransom note can be seen in Figure 14.
Figure 14: Example Sigma ransom note in plaintext
As is standard with Sigma, the user’s Desktop background is changed to a copy of the ransom note; Figure 15 shows an example.
Figure 15: Example desktop background, post-encryption
Why is the Move Away from .onion Services to Email Significant?
The actors have taken a step away from using .onion services as a ransom payment medium, to the more direct engagement process of email, namely through the encrypted and anonymous email service Protonmail. Such a move removes the need to host and maintain .onion services, and it allows the actors to demand arbitrary ransoms rather than assign a one-size-fits-all amount demanded by a static service. This shift likely enables the actors to extort more money overall by finding a price that victims can and will pay. Further, this approach prevents any reliance on a C2 infrastructure that could be taken offline.
In addition to a more stable, “user-friendly” infrastructure, removing .onion services from the extortion chain reduces barriers to payment for the victim. Instead of requiring victims to download the TOR browser (which may be blocked by corporate policy or local anti-malware solutions) and then browse to a .onion or TOR gateway service (which, again, could be blocked), the victim simply needs to open their mail client and send an email to an address hosted on a reputable service. Easy; sending an email is something that any email user will feel capable of doing.
As ransomware infections are generally decreasing, their operators are consistently looking for ways to successfully compromise targets and increase the total payments they can receive. The recent Sigma campaigns are good examples of this trend. Here, the process has been tweaked and even made more inefficient, likely to evade detection and deploy successful infections. Threat actors have also streamlined the ransom communications and payment process in a manner that makes it easier to generate revenue. The threat actors have also integrated some unpopular TTPs to target users in this case. This further proves how critical it is to employ a broad network defense program to adequately combat such threats. Accurate and timely threat intelligence can help prevent as many of those phish as possible from reaching the inboxes of potential victims. However, as our reporting shows, threat actors are constantly finding new ways to get malicious emails past your automated network defenses. Without educating your users to identify, report and prevent successful phishing attacks, any phish that successfully reaches user inboxes becomes a substantially bigger threat to your organization.
To see the past year’s malware trends and what to expect now, read the Cofense Malware Review 2018.
