After a lot of work of sample collection, analysis and follow-up, experts discovered some details about this RAT. While these phishing campaigns have not been attributed to a specific threat actor, all indications are that this operation is handled by a Chinese Advanced Persistent Threat (APT) group.

Simultaneous operations

As mentioned initially, hackers deployed four malicious email campaigns since the end of February, working simultaneously and using various lures to attract unsuspecting users.

Below, we’ll briefly review the features of each phishing attack based on evidence collected by Malwarebytes.

Interactive map

Hackers began distributing the RAT in a file identified as interactive_map_UA.exe, an alleged interactive map of Ukraine. The malware distribution started a few days after Russia invaded Ukraine, indicating that hackers tried to exploit the international conflict.

Update for Log4j

Another of the detected malicious campaigns uses a fake update to fix the Log4Shell vulnerability using a tar file identified as Patch_Log4j.tar.gz. Reports of these emails began in March and targeted at least 100 employees of RT TV, a media network funded by Russia’s government.

The messages appear to be sent by the Russian state defense conglomerate Rostec and include various images and PDFs to make it less suspicious.

The attached PDF, named О кибербезопасности 3.1.2022.pdf, contains instructions on how to run the fake patch, plus a bullet list with supposed safety tips.

Among these recommendations, hackers even added a link to VirusTotal announcing that the file has not been identified as malicious by any antivirus engine.

The message also includes links to the rostec.digital website, registered by threat actors and designed similarly to Rosec actual site. Interestingly, the fraudulent website was registered in mid-2021, months before the Russian invasion of Ukraine began.

Rostec

Hackers again use Rostec’s image in the third campaign, distributing a malicious file named build_rosteh4.exe.

Fake job offers

The latest detected campaign uses a Word document containing an alleged job offer at state oil company Saudi Aramco. The attack involves a self-extracting file using the Jitsi icon and creating a directory identified as Aramco in C:\ProgramData.

The document, written in English, includes a message in Russian asking the user to enable macros on their device.

A remote template injection then allows you to download a template embedded in a macro, which runs a macro to deliver a VBS script identified as HelpCenterUpdater.vbs to the %USER%\Documents\AdobeHelpCenter directory. The template also verifies the existence of %USER%\Documents\D5yrqBxW.txt; as long as it exists, the script will be delivered and executed.

The HelpCenterUpdater.vbs script delivers another obfuscated VBS file named UpdateRunner.vbs and downloads the primary payload, a DLL called GE40BRmRLP.dll, from your C&C server. Although they appear to share code, the script provides an EXE instead of a DLL in another related payload.  

The UpdateRunner.vbs script is responsible for running the DLL through rundll32.exe.

The malicious DLL contains the code that communicates with the C&C server and executes the received commands.

The campaign is still active and relatively prosperous, although many details remain unknown, and it is difficult to know what specific purposes the attackers are pursuing. Malwarebytes has committed to continue monitoring this campaign and the malware used by hackers.

Feel free to access the International Institute of Cyber Security (IICS) websites to learn more about information security risks, malware variants, vulnerabilities, and information technologies.

The post How hackers took control of 100 email accounts of employees of RT and other Russian organizations for cyber spying purposes? appeared first on Information Security Newspaper | Hacking News.

The document, titled “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations”, invites buyers and end users of digital hardware, software, and services to conduct due diligence on the origin and security of components of a digital/technology product.

Supply chain attacks have become one of the most dangerous hacking variants, as they allow threat actors to compromise multiple devices at once, in addition to exploiting vulnerabilities in widely used components. Just remember the SolarWinds attack, which impacted thousands of organizations worldwide.

For Ilkka Turunen, software supply chain security specialist at Sonatype, these measures are important to substantially improve the security of organizations: “This document outlines fundamental best practices, such as generating software bills of materials (SBOM), as well as describing the maintenance activities necessary to maintain effective security practices in the supply chain.”

The researcher adds that software risk mitigation begins with understanding how the use of managed and unmanaged software occurs in an organization, in addition to the progressive mitigation of those risks at the vendor level and with the constant participation of customers.

On the other hand, Cequence Security experts recently alerted the cybersecurity community about the persistence of attacks exploiting flaws such as Log4Shell, discovered a few months ago and that allows abusing the Apache Log4j login utility, considered omnipresent.

A new wave of attacks, identified as LoNg4j, demonstrates the interaction between modern enterprise IT infrastructure and the digital supply chain, spreading across all kinds of applications and creating a critical attack vector in case any vulnerability is exploited.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post NIST updates the Cybersecurity Supply Chain Risk Management Guidance (C-SCRM) in Response to Executive Order Signed by President Biden appeared first on Information Security Newspaper | Hacking News.

To prevent Log4Shell exploitation, AWS security teams released several hot patches, each suitable for a different environment, including servers, Kubernetes, Elastic Container Service (ECS), and Fargate. The first patch was included in an RPM or Debian package, an active patch daemonset for Kubernetes clusters and another included as a set of OCI hooks and intended for Bottlerocket hosts.

However, experts at Palo Alto Networks found that, after the hot patch was installed, any container on the server or cluster could exploit it to take control of the underlying host. In addition, any non-privilege process could exploit active patches to escalate privileges and execute code as root user.

According to the report: “After installing any of the patches, new containers can exploit the patch to escape and compromise its underlying host; on hosts that installed the Hot Patch service or the Hot Patch Daemonset, existing containers can also escape.”

To address JavaScript processes on the fly, solutions invoke certain binary containers; without the proper containerization process, the limitations that typically apply to container processes would not also apply to new processes.

A malicious container could have included a binary called ‘java’ to trick the installed solution, leading to invocation with elevated privileges. The malicious ‘java’ process could abuse its elevated privileges to escape the container and seize the underlying host.

In other words, these fixes treat unprivileged processes similarly, meaning that a malicious process without privileges could create a binary called “java” and abuse the hot patch service to elevate its privileges: “These bugs can be exploited regardless of container configuration, so even environments that allow isolation techniques are affected,” adds the report.

AWS has already fixed the issues with these patches, so customers are invited to install the fixes as soon as possible to mitigate the risk of exploitation.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post AWS patches to fix Log4j vulnerabilities could be exploited for privilege escalation or container escape attacks appeared first on Information Security Newspaper | Hacking News.

This ransomware group was first identified in late 2021 and appears to be focused on attacking enterprise networks. Although it is not yet clear how many victims of this group exist around the world, it has been confirmed that threat actors always demand a ransom of $800,000 USD.

This week, Microsoft also reported the detection of a campaign associated with the exploitation of this flaw in order to compromise VMware Horizon systems, used for the virtualization of cloud applications and desktop computers.

While the company managed to fix the Log4j flaws in Horizon and issue workarounds for customers who couldn’t install the latest version, there are still thousands of vulnerable deployments, which would facilitate ransomware infection: “Our research shows that successful intrusions stemming from this attack led to the deployment of NightSky ransomware.”  Microsoft points out.

This malicious operation has been identified on previous occasions by distributing other ransomware variants, including LockFile, AtomSilo, and Rook. In these incidents, cybercriminals exploited other flaws known as CVE-2021-26084 and CVE-2021-34473, which reside in Confluence and Exchage implementations.

About this attack vector, cybersecurity experts mention that Log4Shell is a very attractive attack vector for hackers because the Log4j component is present in all kinds of computer systems. In addition, exploiting the bug requires minimal effort from hackers and can trigger all kinds of risk scenarios.

The flaw can be exploited remotely in vulnerable deployments exposed on the Internet or from a local network, allowing local threat actors to move laterally to sensitive internal systems.

One of the hacking groups that began to exploit this flaw was the Conti ransomware operation, deploying massive attacks just a couple of days after the appearance of proof of concept (PoC). Khonsari ransomware hackers also deployed attacks linked to Log4j from an exploit available on GitHub.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post New ransomware exploits vulnerabilities in Log4j to encrypt VMware servers appeared first on Information Security Newspaper | Hacking News.

This report was published by Blumira researchers, who say that this behavior dismisses the idea that Log4Shell faults were only exploitable remotely: “This means that anyone with a vulnerable version of Log4j can be exploited through a listening server path on their machine or on the local network when navigating to a vulnerable website,”  experts point out.

In other words, there is more malicious potential for exploit development and successful attacks: “New attack vectors include everything from malvertising to creating watering holes for drive-by attacks,” says Matthew Warner, a researcher at Blumira.

WebSockets allows communication between a web browser and web applications, such as chats and alerts on websites. While it allows the browser to quickly send data back and forth to these types of applications, it can also be used for system detail logging and port scanning, so in itself it poses a security risk.

Experts mention that in the case of Log4j, threat actors could make malicious requests via WebSockets to a local host or a vulnerable local network server, so hackers don’t have to target an exposed target on the network.

To make matters worse, this attack could be considered even stealthier than its remote counterparts, as the researchers mention that it can be difficult to get a complete security approach to WebSocket connections within a host, increasing the complexity to detect the attack.

To detect a potential attack, Warner recommends looking for instances of “.*/java.exe” which is used as the primary process for “cmd.exe/powershell.exe”, which can be considered the most accurate indicators of compromise.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post New Log4j attack allows hacking devices that are not exposed to internet via localhost appeared first on Information Security Newspaper | Hacking News.

Tracked as CVE-2021-44228 and dubbed Log4Shell, this flaw would allow threat actors to send a snippet of malicious code that registers in Log4j v2.0 and earlier, allowing full access to the affected system and the ability to execute code remotely.

While online deployment managers and software developers continue to grapple with this flaw, cybersecurity specialists report the detection of two new vulnerabilities associated with this utility that could put millions of deployments around the world at risk.

Incomplete patches

According to a report by Cyber Kendra, on Tuesday the finding of CVE-2021-45046 was confirmed, an error derived from the incorrect implementation of a patch to address the previous flaw, specifically in the correction of errors in certain non-default configurations.

In more detail, the researchers mention that mitigating the previous flaw required upgrading to the latest available version of Log4j (v2.15); however, this update still left thousands of systems vulnerable to remote code execution (RCE) attacks if only the noMsgFormatLookups flag was enabled or if %m{nolookups} was configured when setting data to ThreadContext with attacker-controlled data.

Threat actors with control over thread context map (MDC) input data when registry settings use a non-default pattern layout with a context lookup or thread context map pattern could create malicious input data using a JNDI search pattern, resulting in a denial of service (DoS) condition.

Fully fixing this flaw requires updating Log4j to v2.16.0.

A third flaw appears

On the other hand, this week researchers from the security firm Praetorian revealed the detection of a third vulnerability in Log4j v2.15.0 whose exploitation would allow threat actors to extract sensitive data in certain circumstances.

The researchers did not share great technical details about the flaw, but say that their findings have already been presented to the Apache Foundation, so they recommend users of affected implementations to upgrade to v2.16.0 as soon as possible, although it is not known with certainty if this version is immune to the exploitation of this new vulnerability, which has not received CVE tracking key.

This week, CloudFlare and Microsoft detected multiple threat actors exploiting Log4Shell flaws for various purposes, although one of the hacking campaigns that most caught the attention of the cybersecurity community was detected by Bitdefender, whose researchers discovered that a hacking group was exploiting this flaw to infect affected systems with Khonsari ransomware.

Since the emergence of these dangerous flaws, researchers have been trying to find the best possible mitigation methods, plus Log4j developers have been in constant communication with users to keep them abreast of any new security risks related to Log4Shell.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Details of CVE-2021-44228 & CVE-2021-45046, the two new Log4j vulnerabilities affecting millions of devices appeared first on Information Security Newspaper | Hacking News.

This report was taken up by Cado Security researchers, who obtained a sample of the ransomware for a detailed analysis. According to this report, this strain is part of a new ransomware family identified as Khonsari, targeting Windows servers; the exploit used by the hackers loads the malicious Java code into hxxp://3.145.115.94/zambo/groenhuyzen.exe, sample retrieved for analysis.

Malware scanning

Experts mention that Khonsari uses the .NET framework and is written in C♯, so retrieving the source code by decompiling is relatively simple using tools like ILspy. After decompiling the sample, it was possible to obtain a detailed description of its capabilities.

This does not appear to be a highly sophisticated ransomware variant, as it weighs only 12KB and barely has the functionalities of any other encryption malware; however, Khonsari operators use this simplicity to their advantage, as some antivirus engines might not detect it. After execution, the malware begins to list the drives on the affected system and encrypt the contents.

On the encryption of the C:\ drive, experts mention that this is a more specialized process, since the malware only encrypts specific directories, which store documents, images, videos and downloads. Files are encrypted using the AES 128 CBC algorithm.

Forensic analysis

At the end of the static analysis, the researchers imported a disk image of the hard drive of a Windows Server 2019 machine infected with Khonsari in an attempt to confirm their hypotheses. This analysis revealed that the malware’s main executable is hosted in a Windows temporary folder:

This is suspicious behavior, as this is a non-standard location for executable files in Windows and goes against conventional development practices. Another remarkable fact is that the .khonsari extension was added to the encrypted files.

Finally, like other ransomware variants, Khonsari issues a ransom note on the target system, which includes information such as the amount required and instructions for making the payment.

At the moment this is a limited campaign, especially compared to cases of exploiting the flaw in Log4j for purposes other than a ransomware infection. However, experts mention that this could be taken as a warning, so it would be worth thinking of this vulnerability as a new attack vector.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post This 12Kb-sized ransomware can exploit Log4j critical vulnerability and encrypt your network appeared first on Information Security Newspaper | Hacking News.

While the vulnerability has already been addressed, since it was first reported hundreds of developers expressed doubts about Log4j and how to check its installation on a given system.

Although some developers assume that, being a Java library, if the administrator does not use Java applications his system cannot have Log4j installed. However, cybersecurity experts mention that applications can include their own JRE, so it is not necessary to have installed Java for Java applications to run on the system.

Through Stack Exchange, a developer shared a script that can help other users identify the Log4j installation on a system:

Subsequently, the command shown below is executed:

Additional comments are available on GitHub.

The researcher who initially reported the flaw in Log4j also mentions that it is only possible to exploit CVE-2021-44228 if the log4j2.formatMsgNoLookups option in the library settings is set to false. The most recent reports on this issue indicate that the latest version of the affected library keeps this setting set to true, which definitely prevents any attempt at exploitation.

However, threat actors are still looking for vulnerable deployments, so administrators should manually set the feature to true before their systems are affected.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post How to check if you have Log4j installed on your servers? Fix the vulnerability in seconds by setting the log4j2.formatMsgNoLookups variable to true appeared first on Information Security Newspaper | Hacking News.

The official assures that so far no exploitation attempts have been detected in government platforms, so the measure is completely preventive: “The risk is critical and according to the new protocols of the head of IT, we must close the vulnerable systems,” says Caire.

The risk is associated with a critical vulnerability in the Apache Log4j log library. Because most Quebec government websites use this tool, it was decided to discontinue its use temporarily, so they will be available again until the flaws in Log4j are addressed. Most vulnerable websites are quite unused, so authorities expect the outage to have minimal impact on the user experience.

Detecting this flaw is a relatively simple process, although depending on how system administrators address these issues the process could take a few days.

In this regard, cybersecurity specialist Eric Parent recommends adopting a systemic approach to address this class of vulnerabilities and thus minimize the risk of exploitation: “We have identified various threat actors exploiting this vulnerability, so it is better to be prepared.” The researcher concludes by mentioning that the best security recommendation is to shut down everything and restart the systems when the risk passes.

Other organizations have warned about this security risk; in recent days, multiple websites frequented by users of the popular video game Minecraft warned about the exploitation of this vulnerability, which could put at risk the enthusiasts of this video game.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Canada shuts down 4,000 government websites fearing cyberattacks exploiting a critical vulnerability in Log4j appeared first on Information Security Newspaper | Hacking News.