Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Windows API. Show all posts

Kazakhstan Has Been The Target of a PowerShell-Based Attack

 

Malwarebytes discovered a multi-stage PowerShell attack on November 10 that used a document lure imitating the Kazakh Ministry of Health Care. On November 8, a threat actor using the handle DangerSklif (perhaps in reference to Moscow's emergency hospital) set up a GitHub account and posted the first part of the attack. 

PowerShell is a sophisticated scripting language that gives you full access to a computer's inner workings, including Windows APIs. PowerShell also has the advantage of being an integral part of Windows that is entirely trusted, thus security software normally ignores the commands it executes. The ability to execute PowerShell remotely via WinRM makes it an even more tempting tool. This functionality allows attackers to bypass Windows Firewall, run PowerShell scripts remotely, or simply drop into an interactive PowerShell session, giving them complete administrative control over a system. 

When PowerShell is used in a fileless malware attack, the line between infecting a single machine and compromising the entire enterprise is entirely blurred. The route to total compromise is paved the instant an attacker obtains a user name and password for a single system. 

The attack began with the distribution of the RAR archive “Увeдомление.rar” ("Notice.rar"). The archive file contains an lnk file with the same name that pretends to be a PDF document from Kazakhstan's "Ministry of Health Care." When the lnk file is opened, a PDF file is shown to confuse victims while numerous stages of the assault are being carried out in the background. The fake document is an update to a Covid 19 policy released by the Republic of Kazakhstan's Chef State Sanitary. 

The attack began with the execution of the lnk file, which invokes PowerShell and uses an autorun registry key to accomplish multiple techniques such as privilege escalation and persistency. The entire attack was stored in a single Github repository called GoogleUpdate. On November 8th, a user named DangerSklif created this repository. On November 1st, the DangerSklif user was created on GitHub.

It used cmd.exe to call PowerShell to download and execute the first stage of the attack from the Github account (lib7.ps1) after de-obfuscating the embedded lnk file. The fake PDF file is downloaded from the same Github account and saved in the Downloads directory by lib7.ps1. The following step is to open a decoy PDF to fool the user while the remainder of the procedure is carried out in the background, including obtaining the OS version and downloading the next stage based on the OS version.

PRIVATELOG Relies on Common Log File System to Evade Detection

 

Researchers have revealed data about a new malware family that uses the Common Log File System (CLFS) to conceal a second-stage payload in registry transaction files in order to avoid detection. The malware, named PRIVATELOG, and its installer, STASHLOG, were discovered by FireEye's Mandiant Advanced Practices team. Details about the threat actor's identity and motivations are still unknown. 

CLFS (Common Log File System) is a general-purpose logging subsystem for producing high-performance transaction logs that is available to both kernel-mode and user-mode applications. It debuted with Windows Server 2003 R2 and has since been incorporated into subsequent Windows operating systems. CLFS can be used for event logging as well as data logging. TxF and TxR employ CLFS to save transactional state changes before committing a transaction. Any integrated Windows utility will not be able to examine the Binary Log File(s) created by CLFS. 

CLFS's goal, like that of any other transactional logging system, is to record a series of steps required for a particular activity so that they can be accurately replayed in the future to commit the transaction to secondary storage or undone if necessary.

Despite the fact that the malware has yet to be found in real-world attacks aimed at consumer environments or seen launching any second-stage payloads, Mandiant believes PRIVATELOG is still in development, might be the work of a researcher, or could be used in a highly targeted attack. 

“Because the file format is not widely used or documented, there are no available tools that can parse CLFS log files. This provides attackers with an opportunity to hide their data as log records in a convenient way, because these are accessible through API functions. This is similar in nature to malware which may rely, for example, on the Windows Registry or NTFS Extended Attributes to hide their data, which also provide locations to store and retrieve binary data with the Windows API.” explained Mandiant researchers.

PRIVATELOG and STASHLOG have features that allow malicious software to remain undetected on infected machines, such as the use of obfuscated strings and control flow techniques that are specifically designed to make static analysis difficult. 

Mandiant researchers examined a PRIVATELOG sample that is an un-obfuscated 64-bit DLL named prntvpt.dll that contains exports that are similar to those found in legal prntvpt.dll files. By hijacking the search order used to load DLLs, PRIVATELOG expects to be loaded from PrintConfig.dll. YARA rules are provided by Mandiant to detect PRIVATELOG and STASHLOG malware, as well as it's variations.

Windows API Used as a Doorway in a MountLocker Ransomware Operation

 

Threat actors are now using MountLocker ransomware via ‘Windows Active Directory enterprise APIs’ to target website developers and organizations. MountLocker started operating in July 2020 as a Ransomware-as-a-Service (RaaS).

MountLocker core team receives a small portion of 20-30% of a ransom payment and the affiliate receives the remainder, as part of this tie-up. In March 2021, ‘Astro Locker’ ransomware group emerged and started using a customized version of the MountLocker ransomware with ransom notes pointing to their own payment and data leak sites. 

"It's not a rebranding, probably we can define it as an alliance," Astro Locker told BleepingComputer when asked about its association to MountLocker. Eventually, in May 2021, a third group emerged called 'XingLocker' who additionally makes use of a personalized MountLocker ransomware executable. 

Earlier this week, MalwareHunterTeam shared a sample of what was believed to be a brand new MountLocker executable that incorporates a new worm feature that permits it to unfold and encrypt to different gadgets on the network. After installing the sample, BleepingComputer confirmed that it was a personalized pattern for the XingLocker workforce. 

A brief evaluation by BleepingComputer showed that you could enable the worm feature by running the malware sample with the /NETWORK command-line argument. As this feature requires a Windows. After sharing the sample with Superior Intel CEO Vitali Kremez, it was found that MountLocker is now using the Home windows Lively Listing Service Interfaces API as a part of its worm characteristic. 

"Many corporate environments rely on complex active directory forests and computer within then. Now MountLocker is the first known ransomware to leverage unique corporate architectural insight for the benefit of identifying additional targets for encryption operation outside of the normal network and share scan," Kremez told BleepingComputer in a dialog about the malware.

“This is the quantum shift of professionalizing ransomware development for corporate network exploitation. As Windows network administrators commonly use this API, Kremez believes the threat actor who added this code likely has some Windows domain administration experience,” he further added. 

While this API has been seen in other malware, such as TrickBot, this may be the first corporate type ransomware for professionals that are using these APIs in order to perform built-in reconnaissance and spread to other devices.