Select Page
Researchers Decrypted Qakbot Banking Trojan’s Encrypted Registry Keys

Researchers Decrypted Qakbot Banking Trojan’s Encrypted Registry Keys

Cybersecurity researchers have decoded the mechanism by which the versatile Qakbot banking trojan handles the insertion of encrypted configuration data into the Windows Registry.

Qakbot, also known as QBot, QuackBot and Pinkslipbot, has been observed in the wild since 2007. Although mainly fashioned as an information-stealing malware, Qakbot has since shifted its goals and acquired new functionality to deliver post-compromise attack platforms such as Cobalt Strike Beacon, with the final objective of loading ransomware on infected machines.

“It has been continually developed, with new capabilities introduced such as lateral movement, the ability to exfiltrate email and browser data, and to install additional malware,” Trustwave researchers Lloyd Macrohon and Rodel Mendrez said in a report shared with The Hacker News.

In recent months, phishing campaigns have culminated in the distribution of a new loader called SQUIRRELWAFFLE, which acts as a channel to retrieve final-stage payloads such as Cobalt Strike and QBot.

images from Hacker News

Iranian Hackers Exploit Log4j Vulnerability to Deploy PowerShell Backdoor

Iranian Hackers Exploit Log4j Vulnerability to Deploy PowerShell Backdoor

An Iranian state-sponsored actor has been observed scanning and attempting to abuse the Log4Shell flaw in publicly-exposed Java applications to deploy a hitherto undocumented PowerShell-based modular backdoor dubbed “CharmPower” for follow-on post-exploitation.

“The actor’s attack setup was obviously rushed, as they used the basic open-source tool for the exploitation and based their operations on previous infrastructure, which made the attack easier to detect and attribute,” researchers from Check Point said in a report published this week.

The Israeli cybersecurity company linked the attack to a group known as APT35, which is also tracked using the codenames Charming Kitten, Phosphorus, and TA453, citing overlaps with toolsets previously identified as infrastructure used by the threat actor.

Log4Shell aka CVE-2021-44228 (CVSS score: 10.0) concerns a critical security vulnerability in the popular Log4j logging library that, if successfully exploited, could lead to remote execution of arbitrary code on compromised systems.

The ease of the exploitation coupled with the widespread use of Log4j library has created a vast pool of targets, even as the shortcoming has attracted swarms of bad actors, who have seized on the opportunity to stage a dizzying array of attacks since its public disclosure last month.

While Microsoft previously pointed out APT35’s efforts to acquire and modify the Log4j exploit, the latest findings show that the hacking group has operationalized the flaw to distribute the PowerShell implant capable of retrieving next-stage modules and exfiltrating data to a command-and-control (C2) server.

images from Hacker News

Meeting Patching-Related Compliance Requirements with TuxCare

Meeting Patching-Related Compliance Requirements with TuxCare

Cybersecurity teams have many demands competing for limited resources. Restricted budgets are a problem, and restricted staff resources are also a bottleneck. There is also the need to maintain business continuity at all times. It’s a frustrating mix of challenges – with resources behind tasks such as patching rarely sufficient to meet security prerogatives or compliance deadlines.

The multitude of different security-related standards have ever stringent deadlines, and it is often the case that business needs don’t necessarily align with those requirements. At the core of what TuxCare does is automated live patching – a way to consistently keep critical services safe from security threats, without the need to expend significant resources in doing so, or the need to live with business disruption.

In this article, we’ll outline how TuxCare helps organizations such as yours deal better with security challenges including patching, and the support of end-of-life operating systems.

The patching conundrum

Enterprise Linux users know that they need to patch – patching is highly effective in closing security loopholes, while it’s also a common compliance requirement. Yet in practice, patching doesn’t occur as frequently, or as tightly as it should. Limited resources are a constraint, but patching has business implications too which can lead to patching delays.

Take patching the kernel of a Linux OS, for example. Typically, that involves restarting the OS, which means the services running on the OS go offline, with predictable business disruption. No matter what you’re trying to patch, the problem remains – it’s impossible to take databases, virtualized workloads, and so forth offline without anyone noticing. The alternatives are complex workarounds or delaying patching.

Risks of not patching in time

But as we all know, delaying patching carries significant risks, of which there are two big ones. First, there are compliance requirements that state a maximum window between patch release and applying that patch.

Organizations that struggle to overcome the business disruption of patching risk delaying patching to the extent that they run workloads in breach of compliance regulations such as the recent CISA mandate. That means a risk of fines or even loss of business.

However, even fully compliant workloads leave a window of exposure – the time between the moment criminal actors develop the ability to exploit a vulnerability and the moment it gets patched.

It leaves an opportunity for intruders to enter your systems and cause damage. Delayed patching leaves an extended window, but even patching within compliance regulations can still lead to a very long risk window. It is generally accepted that, today, 30 days is the common denominator of the most common cybersecurity standards for the “accepted” delay between vulnerability disclosure and patching, but that is still a very large risk window – you’ll meet the compliance requirements, but are your systems really safe? Only if organizations patch as soon as a patch is released is this window truly minimized.

While it’s impossible to completely avoid a window where vulnerabilities are exploitable – after all, the recent Log4j vulnerability was actively being exploited at least a week before it was disclosed – it’s still nonetheless imperative to minimize this window.

Bridging the patching gap with TuxCare

TuxCare identified an urgent need to remove the business disruption element of patching. Our live kernel patching solution, first rolled out under the brand KernelCare, enables companies such as yours to patch even the most critical workloads without disruption.

Instead of the patch, reboot, and hope that everything works routine, organizations that use the KernelCare service can rest assured that patching happens automatically and almost as soon as a patch is released.

KernelCare addresses both compliance concerns and threat windows by providing live patching for the Linux Kernel within hours of a fix being available, thus reducing the exposure window and meeting or exceeding requirements in compliance standards.

Timeframes around patching have consistently been shrinking in the past couple of decades, from many months to just 30 days to combat fast-moving threats – KernelCare narrows the timeframe to what’s about as minimal a window as you could get.

KernelCare achieves this without disrupting regular operation of servers and services. End users will never realize the patch has been deployed. One moment a server is vulnerable, and the next it simply isn’t vulnerable anymore.

What about patching libraries?

We’ve got you covered there too, thanks to LibrayCare, TuxCare’s solution for critical system libraries, which covers patching of other critical components like glibc and OpenSSL. Those are fundamental components of any Linux system that are heavily used by third-party developers for providing functionality such as IO or encryption.

Libraries are a high profile target for malicious actors looking to get a foothold in a system. OpenSSL alone is associated with a list of hundreds of known vulnerabilities. The unfortunate side effect of being used by other applications is that any patching applied to a library will incur business-disrupting downtime, just like kernel patching.

Again, that is the factor that contributes the most to patch deployment delays – the inability to deploy patches without affecting the regular flow of business activities on affected systems. For libraries, it also requires planning, approval, and implementation of maintenance windows, an anachronism in a modern IT environment. Thanks to live patching, LibraryCare can effectively patch libraries without requiring even a single service restart on other applications.

Ensuring database security in running, live database services

Databases store the most valuable assets in a company’s arsenal, its data. Keeping it safe is paramount for business continuity and effectiveness, and this is covered by multiple standards like GDPR, the CCPA and other industry-specific standards in, say, healthcare and finance, that translate data breaches into heavy, business-threatening fines. For example, Amazon reported the largest GDPR fine to date, with a staggering USD 887m in value.

However, data has to be reachable at all times under penalty of, again, causing business disruption if patching is attempted. For this reason, the TuxCare team extended live patching technology to also cover database systems like MariaDB, MySQL or PostgreSQL, the most commonly used open-source database systems today.

Now, you can keep your database backend secure from known vulnerabilities, with the timely deployment of patches that no longer need to be scheduled weeks or months in advance. It helps meet data security requirements transparently and with no friction with other users and systems.

Virtualization is covered too

Another TuxCare product, QEMUcare, takes away the complexity of patching virtualization hosts that rely on QEMU. Prior to live patching, getting QEMU up to date was a task that used to imply extensive migration of virtual machines around nodes, a complex and error-prone task that would impact performance and usability of those virtual machines.

Patching used to impact the end-user experience of virtual tenants significantly. QEMUcare solves this by live patching QEMU while the virtual machines are happily running on the system.

Traditionally, virtual infrastructure was planned in such a way that additional capacity was available to cover for some nodes going down for maintenance, thus wasting resources that would be just sitting there most of the time twiddling its proverbial IT thumbs.

If you don’t need to take your hosts down or migrate virtual machines around anymore, you don’t need to acquire extra hardware to accommodate those operations, saving on equipment, electricity, cooling, and vendor support bills. Your systems are patched within a very short period after patches are available and your infrastructure is more secure.

Legacy systems are not left behind

Companies commonly have legacy systems that for one reason or another have not or cannot be migrated to more recent operating systems. These older systems will go out of support eventually, thus crossing the commonly referred to “end-of-life” (EOL) date.

At this point in time, the vendor behind those systems will no longer support them or provide patches for emerging threats. That means that organizations running those systems automatically fail compliance standards because, of course, you can’t patch if you don’t have patches available to you.

Developing patches in-house is a steep hill to climb. The amount of effort that goes into the development, testing, deployment, and maintenance of patches quickly gets overwhelming in anything other than the simplest situations. Even then, you won’t have the comfort of having a dedicated team of developers with the experience and expertise to help you if anything goes wrong.

TuxCare has that experience, and our Extended Lifecycle Support (ELS) service is the result. It has, for years, helped users of EOL Linux distributions such as CentOS 6, Oracle 6, and Ubuntu LTS. TuxCare backports relevant fixes to the most used system utilities and libraries.

TuxCare provides ongoing cover for patching

We are continuously adding EOL systems as these reach end of life, with CentOS 8 the latest addition to the supported distribution list, given that CentOS 8 reached EOL on January 1st, 2022.

With our established live patching service now also joined by patching across libraries, virtualization and more, TuxCare provides a truly comprehensive patching service that fills the major security gaps that so many organizations battle with.

Thanks to live patching you can now rest assured that your critical systems are protected against newly discovered exploits as fast as possible, and with minimal disruption. That powerful combination gives TuxCare live patching the power to be a key weapon in your cybersecurity arsenal.

images from Hacker News

US Cyber Command Links ‘MuddyWater’ Hacking Group to Iranian Intelligence

US Cyber Command Links ‘MuddyWater’ Hacking Group to Iranian Intelligence

The U.S. Cyber Command (USCYBERCOM) on Wednesday officially confirmed MuddyWater’s ties to the Iranian intelligence apparatus, while simultaneously detailing the various tools and tactics adopted by the espionage actor to burrow into victim networks.

“MuddyWater has been seen using a variety of techniques to maintain access to victim networks,” USCYBERCOM’s Cyber National Mission Force (CNMF) said in a statement. “These include side-loading DLLs in order to trick legitimate programs into running malware and obfuscating PowerShell scripts to hide command and control functions.”

The agency characterized the hacking efforts as a subordinate element within the Iranian Ministry of Intelligence and Security (MOIS), corroborating earlier reports about the nation-state actor’s provenance.

Also tracked under the monikers Static Kitten, Seedworm, Mercury and TEMP.Zagros, MuddyWater is known for its attacks primarily directed against a wide gamut of entities in governments, academia, cryptocurrency, telecommunications, and oil sectors in the Middle East. The group is believed to have been active at least since 2017.

Recent intrusions mounted by the adversary have involved exploiting the ZeroLogon (CVE-2020-1472) vulnerability as well as leveraging remote desktop management tools such as ScreenConnect and Remote Utilities to deploy custom backdoors that could enable the attackers to gain unauthorized access to sensitive data.

images from Hacker News

Hackers Use Cloud Services to Distribute Nanocore, Netwire, and AsyncRAT Malware

Hackers Use Cloud Services to Distribute Nanocore, Netwire, and AsyncRAT Malware

Threat actors are actively incorporating public cloud services from Amazon and Microsoft into their malicious campaigns to deliver commodity remote access trojans (RATs) such as NanocoreNetwire, and AsyncRAT to siphon sensitive information from compromised systems.

The spear-phishing attacks, which commenced in October 2021, have primarily targeted entities located in the U.S., Canada, Italy, and Singapore, researchers from Cisco Talos said in a report shared with The Hacker News.

Using existing legitimate infrastructure to facilitate intrusions is increasingly becoming part of an attacker’s playbook as it obviates the need to host their own servers, not to mention be used as a cloaking mechanism to evade detection by security solutions.

In recent months, collaboration and communication tools like Discord, Slack, and Telegram have found a place in many an infection chain to commandeer and exfiltrate data from the victim machines. Viewed in that light, the abuse of cloud platforms is a tactical extension that attackers could exploit as a first step into a vast array of networks.

images from Hacker News