We are investigating a ransomware campaign that abuses legitimate Sophos executables and DLLs by modifying their original content, overwriting the entry-point code, and inserting the decrypted payload as a resource – in other words, impersonating legitimate files to attempt to sneak onto systems. A preliminary check indicates that all the affected Sophos files were part of the 2022.4.3 version of our Windows Endpoint product.

To be sure, this kind of malicious behavior is (unfortunately) nothing new for the infosecurity industry – indeed, for any software developer. Over the years we’ve seen other infostealers impersonating installers; we’ve seen grab-bag collections of fake utilities, including off-brand antimalware relabeled as legitimate Sophos protections; we’ve seen criminals attack closed-source and open-source code with equal fervor. Later in this post we’ll discuss precisely what attackers think to gain from this – and how defenders can respond.

In general, it’s just part of the tech territory — in fact, in the course of investigating this campaign, we also found similar abuses of files published by other defenders, including AVG, BitDefender, Emsisoft and Microsoft, as well as use of a possibly compromised (and definitely expired) digital signature from another company, as well as a bogus “installer” claiming to be for software from yet another company, along with dozens of malicious downloaders, MSI installers, and other indicators of (attempted) compromise. Our investigation continues and will be reflected in the Indicators of Compromise file on our Github; affected vendors will hear from us privately.

The eventual payloads we have seen in our investigation vary – Cobalt Strike, Brute Ratel, Qakbot, Latrodectus, and others. Evidence exists of use by more than one criminal group, but further inquiry into attribution, or into the compromised signature or fake installer mentioned above, is beyond the scope of this post.

That said, it’s always interesting when something like this turns up. In this article we’ll walk through one such discovery and what we found when we dug into it.

Initial discoveries

The event that first drew our attention to this campaign came from a new Sophos mitigation, C2 Interceptor, which detected and flagged a Brute Ratel C2 connection attempt from a customer’s system in early February:

Figure 1: Our good Sophos name, but in bad company

The most startling part was the version info for the malicious HealthApi.dll file, which as shown in Figure 1 claims it is the legitimate Sophos component of that name. We started to search for samples showing the same characteristics, and found a handful that appear to have been created by the same threat actor, including a version (using the possibly compromised digital signature mentioned above) dating back to January. As noted above, we saw a variety of payloads in use; for this article, we’ll mainly focus on what we saw when we unpacked the samples deploying Cobalt Strike or Brute Ratel.

The fake installer appears to be the means by which the corrupted files got onto systems in at least some cases. As for initial access, we identified, in some cases, JavaScript loaders that appear to have been sent to the victim(s) via email.

General characteristics

In the cases we reviewed for this post, the code at the entry point was overwritten by the malicious loader code, and the encrypted payload was stored as a resource within the resources section. This means that the original PE file structure had to be modified to accommodate the additional malicious resource, as shown in Figure 2.

Figure 2: Digging into the maliciously altered PE file

The updating of the PE structure is only partial — for example, the export table is not fixed. In this situation the DLL samples will have exports with incomprehensible (broken) code, since the code was overwritten by the malicious loader code:

Figure 3: The overwritten code

On the other hand, the header fields necessary for properly loading the executable (e.g., image size) were functional. Most notably, the resource section size in the section table is modified, to disguise that all of the resources in the original, clean file were replaced by the resource file holding the encrypted payload.

Figure 4 shows a comparison of the original SophosFS.exe with the trojanized version:

Figure 4: On the left, the real thing from Sophos; on the right, the would-be attacker’s work

DllRegisterServer

In the 25e24385719aede7f4e0359b389a9597cc26df20e1b3a6367bbc04d5d4982fe6 sample, the file is a DLL, and the code of the DllRegisterServer’s export function is what is being overwritten. We can see that a key is being built up onto the stack. Further analysis will reveal that this key is used as a XOR key to decode the attacker’s obfuscated PE resource.

Figure 5: Attacker changes to DllRegisterServer; the key is visible at lower right

Once decoded, we find shellcode that would eventually decrypt another layer to be injected into memory, then executed. This sample ultimately reveals an executable without its DOS header – in this case, Brute Ratel.

Figure 6: 2022 called, and it’s sending an unwanted copy of Brute Ratel

Meanwhile, for the Cobalt Strike samples, the payload is the usual 64-bit http shellcode:

Figure 7: The usual 64-bit http shellcode

Or, alternately, the Cobalt Strike beacon executable:

Figure 8: Signs of the executable of the Cobalt Strike beacon – the decryptor for the final payload on the left, and the extracted Cobalt Strike configuration on the right

In some Cobalt Strike-related cases, we saw the TitanLdr loader, which is fairly complex multifunction shellcode, doing the work of loading the Cobalt Strike payload. In other cases, simpler shellcode handled the Cobalt Strike loading process. We have also, as mentioned above, noted JavaScript loaders, which may have entered the customer systems via email, that loaded an MSIinstaller, which in turn loaded the fake EXEs / DLLs.

Later findings

Our investigation continues, and at the time of publication our IoC file (linked below) contains well over 400 entries. Other, more curious findings have also come to light. For instance, in at least one case we found an abused binary signed by a (revoked) certificate. The payload was Qakbot. A check on VirusTotal indicates that this is the only file signed by that particular signature, which may mean that the adversary registered it for themselves.

So… why?

A reasonable person may well ask what the attacker means to accomplish by doing these things. After all, the “modifications” break the digital signatures on those files rather badly – so much so that most tools cannot identify the files as having been signed at all. They don’t fool processes that rely on those signatures, and if Sophos protections are running on the targeted machines, this sort of masquerading is very visible to us, and we shut it down (and share our findings with other defenders).

So… why? Essentially, this sort of thing aims to confuse anyone taking a cursory look at the files. Bad guys don’t want to draw attention to themselves, so “joke” or “133t” names are a poor choice; respectable-looking files, particular those from a known infosecurity company, have a greater chance of confusing or just not catching the eyes of analysts, especially when some of the remaining code in the altered files is legitimate – strings, source references, and the like.

Does all this mean there’s a vulnerability in the software? No – which is both a relief (no bug = good) and not a relief (no way to prevent it = bad). As we’ll see in the next section, the affected files in this case came from a specific version of a specific package – not because that package was buggy, but just because the attacker was able to get a copy of the package.

Samples

To this point, this investigation has uncovered samples affecting multiple Sophos executables or DLLs; this happened more than once with two files, though for no file did we spot more than one affected version . A preliminary check indicates that all the files involved were part of the 2022.4.3 version of our Windows Endpoint product. (The version currently completing its rollout is 2023.2.)

We provide in this section a sampling of the files found as this investigation ramped up, what legitimate function they serve in Sophos products, and what the attacker was attempting to do in each case. The list is ordered by affected Sophos file.

We saw multiple files targeted by two separate subversion attempts. Here are two, to show what that looks like:

Detections and protections

Multiple Sophos protections detect or block these maliciously altered files. These include ATK/ScLoad-N, ATK-ScLoad-L, ATK/SCLoad-M, ATK/SCLoad-O, Troj/Cobalt-JA, Troj/Mdrop-JXD, and dynamic shellcode protection, as well as the C2 Interceptor mitigation mentioned at the very beginning of this article.

Industry responses

A campaign like this is noisy, and other defenders are likewise on the hunt. We note with pleasure that Palo Alto Networks, which is also seeing the same sort of activity, has also posted information related to this campaign, including one visualization of the campaign’s attack flow. Additionally, some spotters are reporting a fresh malware strain tentatively called Oyster/CleanUpLoader that is appearing in conjunction with the campaign; Sophos customers are already protected, but we’re watching that development with interest.

As noted above, we have reached out to the companies mentioned in this post and to a number of others also affected; as the investigation continues, so does our outreach. As part of that process, Bitdefender (one of the companies with affected binaries) has reviewed the data pertaining to their files and asks that we relay the following:

Bitdefender has been informed of the binary modification used in these attacks. Bitdefender acknowledged that, as the binaries were used independently, outside of the normal software functionality, no further action is required. The Bitdefender products installed on a system are not vulnerable to this method of binary corruption.

IOCs

A set of indicators of compromise associated with this campaign is provided on our GitHub. As this is a continuing investigation, this file may be augmented over time.

Acknowledgements

Colin Cowie and Jordon Olness of the MDR Threat Intel team contributed to this research.