By the end of June 2019, we assisted to an incident were a high number of computers had started to reboot abnormally. In parallel, Kaspersky detected a file called swaqp.exe, which apparently was not available on any antivirus aggregator or public platform at that time. We tried to determine if such file may have caused those reboots and if we were actually facing a malware threat.
It caught our attention that in a first quick analysis we noticed that the sample downloaded the KB3033929 legitimate security update for Windows, although from an unofficial server. In other words: it installed the legitimate file (signed by Microsoft) from an unofficial server. It is not a typical malware behavior for two reasons:
• Malware creators usually develop their artifacts by minimizing additional dependencies (libraries) that might not be included in potential victims’ computers.
• Malware is rarely interested in updating computers, still less in attempting to update them with any patch. It is not the usual behavior in the context of a potential malware sample.
Following this, we began to investigate. We found an APT that we have called APTualizator.
Why would it update?
The code of swaqp.exe checks if the system has an earlier version of Windows 7 on the desktop and Windows Server 2008 R1 on server version. In such a case, code execution process will terminate. The mentioned security patch is only available for these versions, so it makes clear its goal with that action.
For the executable downloaded from the C&C to run at the kernel level, it will be installed as a driver of the operating system. As we know, on Windows this involves that the binary must be signed by one of the Certification Authorities allowed on the operating system to be executed as a Kernel, thereby offering certain guarantees to the critical software triggered on the system. Driver signature and authorization system on Windows is very demanding in recent times.
So far, we have a malware that performs legitimately an update on the system and downloads what seems to be a driver (that must be signed to be installed). Why would the attacker update the operating system of a victim? To answer this question, we need to understand the changes included in this patch and how it is related to the rootkit installation.
If we go over the details of the certificate used to sign this executable, we can see that SHA256 as a hash algorithm is used. Here is where we start to infer the malware behavior. KB3033929 is a Microsoft update issued in 2015, which is in turn an update of a patch released by the end of 2014. Windows 8 versions or later support signature verification with SHA256, but Windows 7 or Windows 2008 R2 do not. Microsoft had to issue this patch to continue supporting these versions (Windows 7 and 2008 R2), while the earlier ones (Vista, 2003, XP…) remain unable to verify those signatures created with hashes SHA256, and the later ones have natively this feature.
Therefore, the attackers apply the patch KB3033929 so that the verification of the signed driver may be valid. We infer that the attackers only had that signature possibility, so they had to adapt the victim to the malware (by updating the capacities of the operating system) and not the other way around.
For this purpose, we check the driver signature:
Surprisingly, it is signed with SHA256, but with SHA1 as well. This is a usual practice of Windows updates, for instance, for some time now, for the updates to work on Windows 7, 2008 R2 and the remaining systems. But in the case of updates, SHA1 hashes are signed by certificates different to SHA256 hashes in the same sample. In the case of this malware, both hashes SHA1 and SHA256 are signed by a SHA256 certificate.
This is a little strange action performed by the attacker. We infer that it only had a single certificate SHA256, so needing to update the system for the target Windows to verify the validity. The fact that it was signed by SHA1 may constitute a simple previous test performed by the attacker.
References to McAfee and Potential attribution by country
Over the sample execution there are constant references to McAfee that make it change the malware behavior depending on whether antivirus processes are running or not. This is the main antivirus engine installed in the affected computers. A significant part of the malware behavior is contingent upon the existence of this antivirus on the computer. This might suggest a targeted attack.
As an example, in the first line of the following image we can see a reference to a function that we have renamed as writeLog_if_mcafee. We found at least seven more references or internal verifications related to the existence of McAfee.
Moreover, we found a code snippet where the sample checked the language of the victim’s keyboard, according to which they would go ahead with the infection or not. This is quite usual. Nevertheless, the case found here is a little bit different. Instead, we found a range of up to 43 languages that, through consecutive language identifiers, would be freed from the infection.
This report has been issued by the team of researchers from the CSIRT-SCC, in collaboration with ElevenPaths.
Those countries that would not be affected -and among which the presumably threat source is located- are the ranges between 0x18 and 0x43. Russia is precisely within the list of these 43 countries. This may suggest that:
- The authors are within the range, and the remaining ones were included to make unclear the authorship of the attack.
- The attack was targeted, since if it had been an undefined-victim attack, it would make no sense to have excluded so many potential infections (up to 43 different language identifiers would be excluded from the attack). It is important to point out that the only relationship between these identifiers is that they are consecutive. In other words: they do not constitute a close group neither geographically nor politically.
A report issued by the team of researchers from the CSIRT-SCC, in collaboration with ElevenPaths.