Atlassian Confluence Flaw Being Used to Deploy Ransomware and Crypto Miners

 

Description

A recently patched critical security flaw in Atlassian Confluence Server and Data Center products is being actively weaponized in real-world attacks to drop cryptocurrency miners and ransomware payloads.

In at least two of the Windows-related incidents observed by cybersecurity vendor Sophos, adversaries exploited the vulnerability to deliver Cerber ransomware and a crypto miner called z0miner on victim networks.

The bug (CVE-2022-26134, CVSS score: 9.8), which was patched by Atlassian on June 3, 2022, enables an unauthenticated actor to inject malicious code that paves the way of remote code execution (RCE) on affected installations of the collaboration suite. All supported versions of Confluence Server and Data Center are affected.

Other notable malware pushed as part of disparate instances of attack activity include Mirai and Kinsing bot variants, a rogue package called pwnkit, and Cobalt Strike by way of a web shell deployed after gaining an initial foothold into the compromised system.

“The vulnerability, CVE-2022-26134, allows an attacker to spawn a remotely-accessible shell, in-memory, without writing anything to the server’s local storage,” Andrew Brandt, principal security researcher at Sophos, said.

The disclosure overlaps with similar warnings from Microsoft, which revealed last week that “multiple adversaries and nation-state actors, including DEV-0401 and DEV-0234, are taking advantage of the Atlassian Confluence RCE vulnerability CVE-2022-26134.”

DEV-0401, described by Microsoft as a “China-based lone wolf turned LockBit 2.0 affiliate,” has also been previously linked to ransomware deployments targeting internet-facing systems running VMWare Horizon (Log4Shell), Confluence (CVE-2021-26084), and on-premises Exchange servers (ProxyShell).

The development is emblematic of an ongoing trend where threat actors are increasingly capitalizing on newly disclosed critical vulnerabilities rather than exploiting publicly known, dated software flaws across a broad spectrum of targets.

Read More

CVE-2022-33915

 

Description

Versions of the Amazon AWS Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.3.5 are affected by a race condition that could lead to a local privilege escalation. This Hotpatch package is not a replacement for updating to a log4j version that mitigates CVE-2021-44228 or CVE-2021-45046; it provides a temporary mitigation to CVE-2021-44228 by hotpatching the local Java virtual machines. To do so, it iterates through all running Java processes, performs several checks, and executes the Java virtual machine with the same permissions and capabilities as the running process to load the hotpatch. A local user could cause the hotpatch script to execute a binary with elevated privileges by running a custom java process that performs exec() of an SUID binary after the hotpatch has observed the process path and before it has observed its effective user ID.

Read More

Difference Between Agent-Based and Network-Based Internal Vulnerability Scanning

 

Description

For years, the two most popular methods for internal scanning: agent-based and network-based were considered to be about equal in value, each bringing its own strengths to bear. However, with remote working now the norm in most if not all workplaces, it feels a lot more like agent-based scanning is a must, while network-based scanning is an optional extra.

This article will go in-depth on the strengths and weaknesses of each approach, but let’s wind it back a second for those who aren’t sure why they should even do internal scanning in the first place.

Why should you perform internal vulnerability scanning?

While external vulnerability scanning can give a great overview of what you look like to a hacker, the information that can be gleaned without access to your systems can be limited. Some serious vulnerabilities can be discovered at this stage, so it’s a must for many organizations, but that’s not where hackers stop.

Techniques like phishing, targeted malware, and watering-hole attacks all contribute to the risk that even if your externally facing systems are secure, you may still be compromised by a cyber-criminal. Furthermore, an externally facing system that looks secure from a black-box perspective may have severe vulnerabilities that would be revealed by a deeper inspection of the system and software being run.

This is the gap that internal vulnerability scanning fills. Protecting the inside like you protect the outside provides a second layer of defence, making your organization significantly more resilient to a breach. For this reason, it’s also seen as a must for many organizations.

If you’re reading this article, though, you are probably already aware of the value internal scanning can bring but you’re not sure which type is right for your business. This guide will help you in your search.

The different types of internal scanner

Generally, when it comes to identifying and fixing vulnerabilities on your internal network, there are two competing (but not mutually exclusive) approaches: network-based internal vulnerability scanning and agent-based internal vulnerability scanning. Let’s go through each one.

Network-based scanning explained

Network-based internal vulnerability scanning is the more traditional approach, running internal network scans on a box known as a scanning ‘appliance’ that sits on your infrastructure (or, more recently, on a Virtual Machine in your internal cloud).

Agent-based scanning explained

Agent-based internal vulnerability scanning is considered the more modern approach, running ‘agents’ on your devices that report back to a central server.

While “authenticated scanning” allows network-based scans to gather similar levels of information to an agent-based scan, there are still benefits and drawbacks to each approach.

Implementing this badly can cause headaches for years to come. So for organizations looking to implement internal vulnerability scans for the first time, here’s some helpful insight.

Which internal scanner is better for your business?

Coverage

It almost goes without saying, but agents can’t be installed on everything.

Devices like printers; routers and switches; and any other specialized hardware you may have on your network, such as HP Integrated Lights-Out, which is common to many large organizations who manage their own servers, may not have an operating system that’s supported by an agent. However, they will have an IP address, which means you can scan them via a network-based scanner.

This is a double-edged sword in disguise, though. Yes, you are scanning everything, which immediately sounds better. But how much value do those extra results to your breach prevention efforts bring? Those printers and HP iLO devices may infrequently have vulnerabilities, and only some of these may be serious. They may assist an attacker who is already inside your network, but will they help one break into your network to begin with? Probably not.

Meanwhile, will the noise that gets added to your results in the way of additional SSL cipher warnings, self-signed certificates, and the extra management overheads of including them to the whole process be worthwhile?

Clearly, the desirable answer over time is yes, you would want to scan these assets; defence in depth is a core concept in cyber security. But security is equally never about the perfect scenario. Some organizations don’t have the same resources that others do, and have to make effective decisions based on their team size and budgets available. Trying to go from scanning nothing to scanning everything could easily overwhelm a security team trying to implement internal scanning for the first time, not to mention the engineering departments responsible for the remediation effort.

Overall, it makes sense to consider the benefits of scanning everything vs. the workload it might entail deciding whether it’s right for your organization or, more importantly, right for your organization at this point in time.

Looking at it from a different angle, yes, network-based scans can scan everything on your network, but what about what’s not on your network?

Some company laptops get handed out and then rarely make it back into the office, especially in organizations with heavy field sales or consultancy operations. Or what about companies for whom remote working is the norm rather than the exception? Network-based scans won’t see it if it’s not on the network, but with agent-based vulnerability scanning, you can include assets in monitoring even when they are offsite.

So if you’re not using agent-based scanning, you might well be gifting the attacker the one weak link they need to get inside your corporate network: an un-patched laptop that might browse a malicious website or open a malicious attachment. Certainly more useful to an attacker than a printer running a service with a weak SSL cipher.

The winner: Agent-based scanning, because it will allow you broader coverage and include assets not on your network – key while the world adjusts to a hybrid of office and remote working.

If you’re looking for an agent-based scanner to try, Intruder uses an industry-leading scanning engine that’s used by banks and governments all over the world. With over 67,000 local checks available for historic vulnerabilities, and new ones being added on a regular basis, you can be confident of its coverage. You can try Intruder’s internal vulnerability scanner for free by visiting their website.

Attribution

On fixed-IP networks such as an internal server or external-facing environments, identifying where to apply fixes for vulnerabilities on a particular IP address is relatively straightforward.

In environments where IP addresses are assigned dynamically, though (usually, end-user environments are configured like this to support laptops, desktops, and other devices), this can become a problem. This also leads to inconsistencies between monthly reports and makes it difficult to track metrics in the remediation process.

Reporting is a key component of most vulnerability management programs, and senior stakeholders will want you to demonstrate that vulnerabilities are being managed effectively.

Imagine taking a report to your CISO, or IT Director, showing that you have an asset intermittently appearing on your network with a critical weakness. One month it’s there, the next it’s gone, then it’s back again…

In dynamic environments like this, using agents that are each uniquely tied to a single asset makes it simpler to measure, track and report on effective remediation activity without the ground shifting beneath your feet.

The winner: Agent-based scanning, because it will allow for more effective measurement and reporting of your remediation efforts.

Discovery

Depending on how archaic or extensive your environments are or what gets brought to the table by a new acquisition, your visibility of what’s actually in your network in the first place may be very good or very poor.

One key advantage to network-based vulnerability scanning is that you can discover assets you didn’t know you had. Not to be overlooked, asset management is a precursor to effective vulnerability management. You can’t secure it if you don’t know you have it!

Similar to the discussion around coverage, though, if you’re willing to discover assets on your network, you must also be willing to commit resources to investigate what they are, and tracking down their owners. This can lead to ownership tennis where nobody is willing to take responsibility for the asset, and require a lot of follow-up activity from the security team. Again it simply comes down to priorities. Yes, it needs to be done, but the scanning is the easy bit; you need to ask yourself if you’re also ready for the follow-up.

The winner: Network-based scanning, but only if you have the time and resources to manage what is uncovered!

Deployment

Depending on your environment, the effort of implementation and ongoing management for properly authenticated network-based scans will be greater than that of an agent-based scan. However, this heavily depends on how many operating systems you have vs. how complex your network architecture is.

Simple Windows networks allow for the easy rollout of agents through Group Policy installs. Similarly, a well-managed server environment shouldn’t pose too much of a challenge.

The difficulties of installing agents occur where there’s a great variety of operating systems under management, as this will require a heavily tailored rollout process. Modifications to provisioning procedures will also need to be taken into account to ensure that new assets are deployed with the agents already installed or quickly get installed after being brought online. Modern server orchestration technologies like Puppet, Chef, and Ansible can really help here.

Deploying network-based appliances on the other hand requires analysis of network visibility, i.e. from “this” position in the network, can we “see” everything else in the network, so the scanner can scan everything?

It sounds simple enough, but as with many things in technology, it’s often harder in practice than it is on paper, especially when dealing with legacy networks or those resulting from merger activity. For example, high numbers of VLANs will equate to high amounts of configuration work on the scanner.

For this reason, designing a network-based scanning architecture relies on accurate network documentation and understanding, which is often a challenge, even for well-resourced organizations. Sometimes, errors in understanding up-front can lead to an implementation that doesn’t match up to reality and requires subsequent “patches” and the addition of further appliances. The end result can often be that it’s just as difficult to maintain patchwork despite original estimations seeming simple and cost-effective.

The winner: It depends on your environment and the infrastructure team’s availability.

Maintenance

Due to the situation explained in the previous section, practical considerations often mean you end up with multiple scanners on the network in a variety of physical or logical positions. This means that when new assets are provisioned or changes are made to the network, you have to make decisions on which scanner will be responsible and make changes to that scanner. This can place an extra burden on an otherwise busy security team. As a rule of thumb, complexity, wherever not necessary, should be avoided.

Sometimes, for these same reasons, appliances need to be located in places where physical maintenance is troublesome. This could be either a data center or a local office or branch. Scanner not responding today? Suddenly the SecOps team is picking straws for who has to roll up their sleeves and visit the datacenter.

Also, as any new VLANs are rolled out, or firewall and routing changes alter the layout of the network, scanning appliances need to be kept in sync with any changes made.

The winner: Agent-based scanners are much easier to maintain once installed.

Concurrency and scalability

While the concept of sticking a box on your network and running everything from a central point can sound alluringly simple, if you are so lucky to have such a simple network (many aren’t), there are still some very real practicalities to consider around how that scales.

Take, for example, the recent vulnerability Log4shell, which impacted Log4j - a logging tool used by millions of computers worldwide. With such wide exposure, it’s safe to say almost every security team faced a scramble to determine whether they were affected or not.

Even with the ideal scenario of having one centralized scanning appliance, the reality is this box cannot concurrently scan a huge number of machines. It may run a number of threads, but realistically processing power and network-level limitations means you could be waiting a number of hours before it comes back with the full picture (or, in some cases, a lot longer).

Agent-based vulnerability scanning, on the other hand, spreads the load to individual machines, meaning there’s less of a bottleneck on the network, and results can be gained much more quickly.

There’s also the reality that your network infrastructure may be ground to a halt by concurrently scanning all of your assets across the network. For this reason, some network engineering teams limit scanning windows to after-hours when laptops are at home and desktops are turned off. Test environments may even be powered down to save resources.

Intruder automatically scans your internal systems as soon as new vulnerabilities are released, allowing you to discover and eliminate security holes in your most exposed systems promptly and effectively.

The winner: Agent-based scanning can overcome common problems that are not always obvious in advance, while relying on network scanning alone can lead to major gaps in coverage.

Summary

With the adoption of any new system or approach, it pays to do things incrementally and get the basics right before moving on to the next challenge. This is a view that the NCSC, the UK’s leading authority on cyber security, shares as it frequently publishes guidance around getting the basics right.

This is because, broadly speaking, having the basic 20% of defences implemented effectively will stop 80% of the attackers out there. In contrast, advancing into 80% of the available defences but implementing them badly will likely mean you struggle to keep out the classic kid-in-bedroom scenario we’ve seen too much of in recent years.

For those organizations on an information security journey, looking to roll out vulnerability scanning solutions, here are some further recommendations:

Step 1 — Ensure you have your perimeter scanning sorted with a continuous and proactive approach. Your perimeter is exposed to the internet 24/7, and so there’s no excuse for organizations who fail to respond quickly to critical vulnerabilities here.

Step 2 — Next, focus on your user environment. The second most trivial route into your network will be a phishing email or drive-by download that infects a user workstation, as this requires no physical access to any of your locations. With remote work being the new norm, you need to be able to have a watch over all laptops and devices, wherever they may be. From the discussion above, it’s fairly clear that agents have the upper hand in this department.

Step 3 — Your internal servers, switches and other infrastructure will be the third line of defence, and this is where internal network appliance-based scans can make a difference. Internal vulnerabilities like this can help attackers elevate their privileges and move around inside your network, but it won’t be how they get in, so it makes sense to focus here last.

Hopefully, this article casts some light on what is never a trivial decision and can cause lasting pain points for organizations with ill-fitting implementations. There are pros and cons, as always, no one-size-fits-all, and plenty of rabbit holes to avoid. But, by considering the above scenarios, you should be able to get a feel for what is right for your organization.

Read More

Potent Emotet Variant Spreads Via Stolen Email Credentials

 

Description

Emotet’s resurgence in April seems to be the signal of a full comeback for what was once dubbed “the most dangerous malware in the world,” with researchers spotting various new malicious phishing campaigns using hijacked emails to spread new variants of the malware.

The “new and improved” version of Emotet is exhibiting a “troubling” behavior of effectively collecting and using stolen credentials, “which are then being weaponized to further distribute the Emotet binaries,” Charles Everette from Deep Instinct revealed in a blog post this week, citing research from HP Wolf Security’s latest threat insights blog.

“[Emotet] still utilizes many of the same attack vectors it has exploited in the past,” he wrote. “The issue is that these attacks are getting more sophisticated and are bypassing today’s standard security tools for detecting and filtering out these types of attacks.”

In April, Emotet malware attacks returned after a 10-month “spring break” with targeted phishing attacks linked to the threat actor known as TA542, which since 2014 has leveraged the Emotet malware with great success, according to a report by Proofpoint.

These attacks—which were being leveraged to deliver ransomware—came on the back of attacks in February and March hitting victims in Japan using hijacked email threads and then “using those accounts as a launch point to trick victims into enabling macros of attached malicious office documents,” Deep Instinct’s Everette wrote.

“Looking at the new threats coming from Emotet in 2022 we can see that there has been an almost 900 percent increase in the use of Microsoft Excel macros compared to what we observed in Q4 2021,” he wrote.

Emotet Rides Again

The attacks that followed in April targeted new regions beyond Japan and also demonstrated other characteristics signaling a ramp-up in activity and rise in sophistication of Emotet, Deep Instinct noted.

Emotet, like other threat groups, continues to leverage a more than 20-year-old Office bug that was patched in 2017, CVE-2017-11882, with nearly 20 percent of the samples that researchers observed exploiting this flaw. The Microsoft Office Memory corruption vulnerability allows an attacker to perform arbitrary code execution.

Nine percent of the new Emotet threats observed were never seen before, and 14 percent of the recent emails spreading the malware bypassed at least one email gateway security scanner before it was captured, according to Deep Instinct.

Emotet still primarily uses phishing campaigns with malicious attachments as its transportation of choice, with 45 percent of the malware detect using some type of Office attachment, according to Deep Instinct. Of these attachments, 33 percent were spreadsheets, 29 percent were executables and scripts, 22 percent were archives and 11 percent were documents.

Other notable changes to Emotet’s latest incarnation is its use of 64-bit shell code, as well as more advanced PowerShell and active scripts in attacks, according to Deep Instinct.

History of a Pervasive Threat

Emotet started its nefarious activity as a banking trojan in 2014, with its operators having the dubious honor of being one of the first criminal groups to provide malware-as-a-service (MaaS), Deep Instinct noted.

The trojan evolved over time to become a full-service threat-delivery mechanism, with the ability to install a collection of malware on victim machines, including information stealers, email harvesters, self-propagation mechanisms and ransomware. Indeed, Trickbot and the Ryuk and Conti ransomware groups have been habitual partners of Emotet, with the latter using the malware to gain initial entry onto targeted systems.

Emotet appeared to be put out of commission by an international law-enforcement collaborative takedown of a network of hundreds of botnet servers supporting the system in January 2021. But as often happens with cybercriminal groups, its operators have since regrouped and seem to be working once again at full power, researchers said.

In fact, in November 2021 when Emotet emerged again nearly a year after it went dark, it was on the back of its collaborator Trickbot. A team of researchers from Cryptolaemus, G DATA and AdvIntel separately observed the trojan launching a new loader for Emotet, signaling its return to the threat landscape.

Read More

3 Takeaways From the 2022 Verizon Data Breach Investigations Report

 

Description

Sometimes, data surprises you. When it does, it can force you to rethink your assumptions and second-guess the way you look at the world. But other times, data can reaffirm your assumptions, giving you hard proof they’re the right ones — and providing increased motivation to act decisively based on that outlook.

The 2022 edition of Verizon’s Data Breach Investigations Report (DBIR), which looks at data from cybersecurity incidents that occurred in 2021, is a perfect example of this latter scenario. This year’s DBIR rings many of the same bells that have been resounding in the ears of security pros worldwide for the past 12 to 18 months — particularly, the threat of ransomware and the increasing relevance of complex supply chain attacks.

Here are our three big takeaways from the 2022 DBIR, and why we think they should have defenders doubling down on the big cybersecurity priorities of the current moment.

1. Ransomware’s rise is reaffirmed

In 2021, it was hard to find a cybersecurity headline that didn’t somehow pertain to ransomware. It impacted some 80% of businesses last year and threatened some of the institutions most critical to our society, from primary and secondary schools to hospitals.

This year’s DBIR confirms that ransomware is the critical threat that security pros and laypeople alike believe it to be. Ransomware-related breaches increased by 13% in 2021, the study found — that’s a greater increase than we saw in the past 5 years combined. In fact, nearly 50% of all system intrusion incidents — i.e., those involving a series of steps by which attackers infiltrate a company’s network or other systems — involved ransomware last year.

While the threat has massively increased, the top methods of ransomware delivery remain the ones we’re all familiar with: desktop sharing software, which accounted for 40% of incidents, and email at 35%, according to Verizon’s data. The growing ransomware threat may seem overwhelming, but the most important steps organizations can take to prevent these attacks remain the fundamentals: educating end users on how to spot phishing attempts and maintain security best practices, and equipping infosec teams with the tools needed to detect and respond to suspicious activity.

2. Attackers are eyeing the supply chain

In 2021 and 2022, we’ve been using the term “supply chain” more than we ever thought we would. COVID-induced disruptions in the flow of commodities and goods caused lumber to skyrocket and automakers to run short on microchips.

But security pros have had a slightly different sense of the term on their minds: the software supply chain. Breaches from Kaseya to SolarWinds — not to mention the Log4j vulnerability — reminded us all that vendors’ systems are just as likely a vector of attack as our own.

Unfortunately, Verizon’s Data Breach Investigations Report indicates these incidents are not isolated events — the software supply chain is, in fact, a major avenue of exploitation by attackers. In fact, 62% of cyberattacks that follow the system intrusion pattern began with the threat actors exploiting vulnerabilities in a partner’s systems, the study found.

Put another way: If you were targeted with a system intrusion attack last year, it was almost twice as likely that it began on a partner’s network than on your own.

While supply chain attacks still account for just under 10% of overall cybersecurity incidents, according to the Verizon data, the study authors point out that this vector continues to account for a considerable slice of all incidents each year. That means it’s critical for companies to keep an eye on both their own and their vendors’ security posture. This could include:

• Demanding visibility into the components behind software vendors’ applications
• Staying consistent with regular patching updates
• Acting quickly to remediate and emergency-patch when the next major vulnerability that could affect high numbers of web applications rears its head

3. Mind the app

Between Log4Shell and Spring4Shell, the past 6 months have jolted developers and security pros alike to the realization that their web apps might contain vulnerable code. This proliferation of new avenues of exploitation is particularly concerning given just how commonly attackers target web apps.

Compromising a web application was far and away the top cyberattack vector in 2021, accounting for roughly 70% of security incidents, according to Verizon’s latest DBIR. Meanwhile, web servers themselves were the most commonly exploited asset type — they were involved in nearly 60% of documented breaches.

More than 80% of attacks targeting web apps involved the use of stolen credentials, emphasizing the importance of user awareness and strong authentication protocols at the endpoint level. That said, 30% of basic web application attacks did involve some form of exploited vulnerability — a percentage that should be cause for concern.

“While this 30% may not seem like an extremely high number, the targeting of mail servers using exploits has increased dramatically since last year, when it accounted for only 3% of the breaches,” the authors of the Verizon DBIR wrote.

That means vulnerability exploits accounted for a 10 times greater proportion of web application attacks in 2021 than they did in 2022, reinforcing the importance of being able to quickly and efficiently test your applications for the most common types of vulnerabilities that hackers take advantage of.

Stay the course

For those who’ve been tuned into the current cybersecurity landscape, the key themes of the 2022 Verizon DBIR will likely feel familiar — and with so many major breaches and vulnerabilities that claimed the industry’s attention in 2021, it would be surprising if there were any major curveballs we missed. But the key takeaways from the DBIR remain as critical as ever: Ransomware is a top-priority threat, software supply chains need greater security controls, and web applications remain a key attack vector.

If your go-forward cybersecurity plan reflects these trends, that means you’re on the right track. Now is the time to stick to that plan and ensure you have tools and tactics in place that let you focus on the alerts and vulnerabilities that matter most.

Additional reading:

• A Year on from the Ransomware Task Force Report
• Are You in the 2.5% Who Meet This Cybersecurity Job Requirement?
• What’s Changed for Cybersecurity in Banking and Finance: New Study
• How to Strategically Scale Vendor Management and Supply Chain Security

NEVER MISS A BLOG

Read More

EnemyBot Malware Targets Web Servers, CMS Tools and Android OS

 

Description

A rapidly evolving IoT malware dubbed “EnemyBot” is targeting content management systems (CMS), web servers and Android devices. Threat actor group “Keksec” is believed behind the distribution of the malware, according to researchers.

“Services such as VMware Workspace ONE, Adobe ColdFusion, WordPress, PHP Scriptcase and more are being targeted as well as IoT and Android devices,” reported AT&T Alien labs in a recent post. “The malware is rapidly adopting one-day vulnerabilities as part of its exploitation capabilities,” they added.

EnemyBot Working

The Alien lab research team study found four main sections of the malware.

The first section is a python script ‘cc7.py’, used to download all dependencies and compile the malware into different OS architectures (x86, ARM, macOS, OpenBSD, PowerPC, MIPS). After compilation, a batch file “update.sh” is created and used to spread the malware to vulnerable targets.

The second section is the main botnet source code, which includes all the other functionality of the malware excluding the main part and incorporates source codes of the various botnets that can combine to perform an attack.

The third module is obfuscation segment “hide.c” and is compiled and executed manually to encode /decode the malware strings. A simple swap table is used to hide strings and “each char is replaced with a corresponding char in the table” according to researchers.

The last segment includes a command-and-control (CC) component to receive vital actions and payloads from attackers.

AT&T researcher’s further analysis revealed a new scanner function to hunt vulnerable IP addresses and an “adb_infect” function that is used to attack Android devices.

ADB or Android Debug Bridge is a command-line tool that allows you to communicate with a device.

“In case an Android device is connected through USB, or Android emulator running on the machine, EnemyBot will try to infect it by executing shell command,” said the researcher.

“Keksec’s EnemyBot appears to be just starting to spread, however due to the authors’ rapid updates, this botnet has the potential to become a major threat for IoT devices and web servers,” the researchers added.

This Linux-based botnet EnemyBot was first discovered by Securonix in March 2022, and later in-depth analysis was done by Fortinet.

Vulnerabilities Currently Exploited by EnemyBot

The AT&T researchers release a list of vulnerabilities that are currently exploited by the Enemybot, some of them are not assigned a CVE yet.

The list includes Log4shell vulnerability (CVE-2021-44228, CVE-2021-45046), F5 BIG IP devices (CVE-2022-1388), and others. Some of the vulnerabilities were not assigned a CVE yet such as PHP Scriptcase and Adobe ColdFusion 11.

• Log4shell vulnerability – CVE-2021-44228, CVE-2021-45046
• F5 BIG IP devices – CVE-2022-1388
• Spring Cloud Gateway – CVE-2022-22947
• TOTOLink A3000RU wireless router – CVE-2022-25075
• Kramer VIAWare – CVE-2021-35064

“This indicates that the Keksec group is well resourced and that the group has developed the malware to take advantage of vulnerabilities before they are patched, thus increasing the speed and scale at which it can spread,” the researcher explained.

Recommended Actions

The Alien lab researcher suggests methods to protect from the exploitation. Users are advised to use a properly configured firewall and focus on reducing Linux server and IOT devices’ exposure to the internet.

Another action recommended is to monitor the network traffic, scan the outbound ports and look for the suspicious bandwidth usage. Software should be updated automatically and patched with the latest security update.

Read More

EnemyBot Linux Botnet Now Exploits Web Server, Android and CMS Vulnerabilities

 

Description

A nascent Linux-based botnet named Enemybot has expanded its capabilities to include recently disclosed security vulnerabilities in its arsenal to target web servers, Android devices, and content management systems (CMS).

“The malware is rapidly adopting one-day vulnerabilities as part of its exploitation capabilities,” AT&T Alien Labs said in a technical write-up published last week. “Services such as VMware Workspace ONE, Adobe ColdFusion, WordPress, PHP Scriptcase and more are being targeted as well as IoT and Android devices.”

First disclosed by Securonix in March and later by Fortinet, Enemybot has been linked to a threat actor tracked as Keksec (aka Kek Security, Necro, and FreakOut), with early attacks targeting routers from Seowon Intech, D-Link, and iRZ.

Enemybot, which is capable of carrying out DDoS attacks, draws its origins from several other botnets like Mirai, Qbot, Zbot, Gafgyt, and LolFMe. An analysis of the latest variant reveals that it’s made up of four different components -

• A Python module to download dependencies and compile the malware for different OS architectures
• The core botnet section
• An obfuscation segment designed to encode and decode the malware’s strings, and
• A command-and-control functionality to receive attack commands and fetch additional payloads

“In case an Android device is connected through USB, or Android emulator running on the machine, EnemyBot will try to infect it by executing [a] shell command,” the researchers said, pointing to a new “adb_infect” function. ADB refers to Android Debug Bridge, a command-line utility used to communicate with an Android device.

Also incorporated is a new scanner function that’s engineered to search random IP addresses associated with public-facing assets for potential vulnerabilities, while also taking into account new bugs within days of them being publicly disclosed.

Besides the Log4Shell vulnerabilities that came to light in December 2021, this includes recently patched flaws in Razer Sila routers (no CVE), VMware Workspace ONE Access (CVE-2022-22954), and F5 BIG-IP (CVE-2022-1388) as well as weaknesses in WordPress plugins like Video Synchro PDF.

Other weaponized security shortcomings are below -

• CVE-2022-22947 (CVSS score: 10.0) - A code injection vulnerability in Spring Cloud Gateway
• CVE-2021-4039 (CVSS score: 9.8) - A command injection vulnerability in the web interface of the Zyxel NWA-1100-NH firmware
• CVE-2022-25075 (CVSS score: 9.8) - A command injection vulnerability in TOTOLink A3000RU wireless router
• CVE-2021-36356 (CVSS score: 9.8) - A remote code execution vulnerability in KRAMER VIAware
• CVE-2021-35064 (CVSS score: 9.8) - A privilege escalation and command execution vulnerability in Kramer VIAWare
• CVE-2020-7961 (CVSS score: 9.8) - A remote code execution vulnerability in Liferay Portal

What’s more, the botnet’s source code has been shared on GitHub, making it widely available to other threat actors. “I assume no responsibility for any damages caused by this program,” the project’s README file reads. “This is posted under Apache license and is also considered art.”

"Keksec’s Enemybot appears to be just starting to spread, however due to the authors’ rapid updates, this botnet has the potential to become a major threat for IoT devices and web servers,’’ the researchers said.

“This indicates that the Keksec group is well resourced and that the group has developed the malware to take advantage of vulnerabilities before they are patched, thus increasing the speed and scale at which it can spread.”

Read More