The recent "meow bot" attacks are the most recent example of cybercrime targeting sensitive customer data. Damaging attacks like these can be avoided with the free security features included in Elastic products.

"Security by default" is the concept that technology&nbsp;needs to be safe and secure right out of the box. It's why your smartphone locks when you leave it unattended, and why&nbsp;Elastic products come&nbsp;with <a href="/blog/getting-started-with-elasticsearch-security">free and open security features</a> like TLS encrypted communication, role-based access control (RBAC), and more. It's also why you cannot disable security in an <a href="/cloud">Elastic Cloud</a> deployment. The simple step of just making security a default priority can go a long way.In this post, we're going to take a look at the recent&nbsp;<a href="https://searchsecurity.techtarget.com/news/252486611/Meow-attacks-wipe-more-than-1000-exposed-databases">"meow bot"</a>&nbsp;attacks. We'll look at how they happen and learn some simple steps to prevent them. 

<h2>Sniffing out unsecured data</h2>The issue of unsecured databases is growing. In 2019, <a href="https://enterprise.verizon.com/resources/infographics/dbir-statistics.pdf">17 percent of all data breaches</a> were caused by human error — twice as many as just a year before. And the IBM/Ponemon 2019 report found that the estimated probability of a company having repeated data breaches within two years grew by <a href="https://www.ibm.com/downloads/cas/ZBZLY7KL?_ga=2.148238199.1762516747.1577395260-1128561362.1577395260">31 percent</a> between 2014 and 2019.
Why is this happening? Unsecured databases are the targets of a new cybercriminal economy that’s thriving for two key reasons: the growing market for customer data and low-cost tools that make it easier than ever for criminals to gain access. This isn't hacking, but simply mining and grabbing as soon as things pop up in the open.
The latest example is the recent <a href="https://searchsecurity.techtarget.com/news/252486611/Meow-attacks-wipe-more-than-1000-exposed-databases">"meow bot" attacks</a>, which have already affected thousands of unsecured MongoDB and Elasticsearch databases. The automated attack script searches for open databases and then overwrites data with the word "meow" and a string of random numbers. The "meow bot"&nbsp;is just one of several inexpensive, large-scale systems that scan the entire Internet each day to find unsecured databases in hours and sometimes minutes. Elastic condemns these attacks and urges everyone to be more rigorous in storing their sensitive data.
Unfortunately, the database owners impacted in this incident mistakenly disabled or did not set up the features that best secure their customer data. This is not an issue of malicious intent, as developers or security personnel within organizations don’t always recognize how seemingly innocuous decisions like leaving a database unsecured during maintenance may have an impact down the line.&nbsp;
<h2>Keeping your Elasticsearch data safe from "meow" attacks</h2>Damaging attacks like these can be avoided with the <a href="/blog/getting-started-with-elasticsearch-security">free security features</a> included in Elastic products. For our cloud users, security is enabled by default in our <a href="/elasticsearch/service">Elasticsearch Service on Elastic Cloud</a> and cannot be disabled, so Elastic Cloud customers are not vulnerable to the problems that emerged in the "meow bot" attacks.&nbsp;
Another free way to avoid these incidents is setting up external scanning systems that continuously check for exposed databases. These free tools, which are also used by the attackers, give security teams immediate notification when a developer has mistakenly left sensitive data unlocked. For example, a free scanner is available from <a href="https://www.shadowserver.org/what-we-do/network-reporting/" rel="nofollow">Shadowserver</a>.
To learn how to get started securing your Elastic deployments, read our blog on <a href="/blog/how-to-prevent-elasticsearch-server-breach-securing-elasticsearch">how to prevent an Elasticsearch server breach</a>. You can find more general guidance on securing your deployment <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.8/configuring-security.html">in our documentation</a>. We also offer a free on-demand <a href="/training/fundamentals-of-securing-elasticsearch">Fundamentals of Securing Elasticsearch course</a>, which covers user authentication, role-based access control (RBAC), node-to-node encryption, IP filtering, HTTPS encryption, and more.

blog-banner-security-pattern-color.png

blog-thumb-security-pattern-color.png

Protect your Elasticsearch deployments against attacks like “meow bot” — for free

The Elastic InfoSec team's internal use of Elastic Security has increased visibility and exponentially expanded its response capabilities to threats.

This blog post is one in an occasional series about how we at Elastic embrace our own technology.
The Elastic InfoSec team is responsible for securing Elastic and responding to threats. We use our products everywhere we can&nbsp;— and for more than just logs. By harnessing the power and breadth of capabilities of the Elastic Stack, we are working on tracking risk and performance metrics, threat intelligence, our control framework, and control conformance information within Elastic.&nbsp;
Security has been and continues to be a top priority internally as well as in the products we develop and deliver. We’ve doubled down on these efforts when we joined forces with <a href="https://www.elastic.co/blog/endgame-joins-forces-with-elastic">Endgame</a> to craft Elastic Endpoint Security, and with <a href="https://www.elastic.co/blog/welcome-perched-security-training-for-siem-threat-hunting-and-more">Perched</a> to help create Elastic SIEM. Teaming up with these companies brought a whole new set of security professionals to the Elastic organization. Each professional brings a diverse set of skills and experiences that we can lean on to help protect our organization using our own security products — <a href="https://www.elastic.co/endpoint-security">Elastic Endpoint Security</a> and <a href="https://www.elastic.co/siem">Elastic SIEM</a>.
Our internal use of the Elastic Security solution has increased the Elastic InfoSec team’s level of visibility and has exponentially expanded its response capabilities to more fully empower the broader organization to protect the Elastic enterprise from the threats of today and tomorrow. For our Elastic community of users and customers, this also translates to us delivering a better, leading security solution.&nbsp;
We are excited to share our story….
<h2>“Customer Zero”</h2>We have the expressed goal of being Customer Zero for all of our solutions, and this applies especially to Elastic Security. To ensure that what we deploy to our customers has been tested in a real production environment before it gets distributed more broadly, we’re an early adopter of build candidate (pre-release) versions of the Elastic Stack and each of our solution deployments.
We’re excited about having an industry-leading Endpoint Detection and Response (EDR) tool available to use within our environment. You can read all about the effectiveness of Elastic Endpoint Security in third-party reports from NSS Labs, Gartner, and AV Comparatives in <a href="https://www.elastic.co/blog/introducing-elastic-endpoint-security">this post</a>.
Having leading detection and response capabilities on the endpoint is great on its own, but we’re really thrilled by the possibilities that come with its native integration with the Elastic Stack and Elastic SIEM.&nbsp;
It’s remarkable to have the ability to create automated responses and advanced analytics in addition to having the data and visuals we as analysts need — all in a single platform.
<h2>Piloting Elastic Endpoint Security</h2>Replacing an endpoint security agent is not a task that is frequently undertaken, and it often comes with unexpected challenges. So when we announced our intent to bring Endgame into the Elastic fold, we immediately began planning our migration from CrowdStrike to Elastic Endpoint Security (formerly Endgame).&nbsp;
After officially joining forces with Endgame, we began to deploy the Sensor Management Platform (SMP) for our end user pilot. We were easily able to import our whitelist and trusted applications that we had previously configured in CrowdStrike. Then, we created a single detection policy within the SMP and enabled all threat and adversary behavior detections. We also enabled all event collection features and set up event streaming to Elasticsearch.&nbsp;
We ran the pilot on a small percentage of endpoints in a detect-only mode for a little more than a week. With our pilot users streaming endpoint data back to the SMP and to our endpoint monitoring Elasticsearch cluster, we began migrating our existing Auditbeat and Winlogbeat dashboards, queries, and Watcher alerts to use the endpoint index. The data received via the endpoint agent is similar to the data collected by Auditbeat and Winlogbeat without having to manage yaml configurations.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltec0e916e79b25bd3/5e470e8a7c62095ce7b37118/Securingendpoints-blog-canvas-dashboard-overview-Elastic-Endpoint-Alerts-1.jpg" data-sys-asset-uid="bltec0e916e79b25bd3" alt="Securingendpoints-blog-canvas-dashboard-overview-Elastic-Endpoint-Alerts-1.jpg">

<figcaption>A Canvas dashboard giving an overview of Elastic Endpoint Alerts</figcaption><h2>Investigating with Elastic SIEM </h2>We were then ready to perform investigations in the Elastic SIEM app by simply adding the “endgame-*” index pattern to the default index for SIEM in Kibana. Investigating Elastic Endpoint Security alerts or other anomalous behavior in the SIEM app is easy with Timeline. Timeline allows us to stitch together processes by process ancestry similar to the ResolverTM view within the management console. It also allows us to see a population of events and data (process names, process arguments, etc.) across our entire endpoint fleet with the speed of Elasticsearch.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt85eaeb609b10986e/5e470e9894aef92989eeff6a/Securingendpoints-blog-configuring-indices-Elastic-SIEM.png" data-sys-asset-uid="blt85eaeb609b10986e" alt="Securingendpoints-blog-configuring-indices-Elastic-SIEM.png">

<figcaption>Configuring indices for the Elastic SIEM</figcaption>During the pilot, we had a single malware detection on one of our Mac workstations that had been present on the system with CrowdStrike installed. We were able to use the response capability in Elastic Endpoint Security to remotely remediate the malware with minimal impact and downtime to the impacted user. The user was actually able to continue working; the only interruption experienced was us telling them we were remotely working on their laptop.&nbsp; 
We were very happy with how easy it was to remove a fairly complex piece of malware that had several persistence mechanisms.&nbsp;
We’re a distributed organization with currently 1,900+ Elasticians located across 40+ countries, and a lot of our employees rarely, if ever, find themselves in an Elastic office. With this in mind, we were impressed with the Elastic Security solution’s ability to enable an Elastic analyst sitting in their house in Germany to successfully remediate malware on the device of a Tennessee-based employee. This was not a capability we had on Macs before installing Elastic Endpoint Security.
<h2>Deploying Elastic Endpoint Security</h2>After the pilot period, we deployed the Endpoint agent to the remainder of the endpoint fleet in detect mode over a period of five days while removing CrowdStrike at the same time. During this period, we deployed to 1800+ endpoints — our fleet of user devices at that point in time — with no reported issues from any of our fellow Elastician users. If you’ve ever deployed an agent to user endpoints (especially security agents), you know it never goes this smoothly. But for us, it did.
Once we rolled out to the fleet at large, we had 23 systems report malicious files that needed to be remediated. The surprising part for us was the extremely low false positive rate on threat detections.&nbsp;
The Adversary Behavior detections, however, were noisier and filled with false positives because of the diverse skill sets, and subsequent behavioral trends, of our Elasticians. We saw things like Elastic security professionals conducting research and exploit proof of concepts, developers creating software, and sales architects running containers and other interesting tools. Our initial pilot users, along with the 23 systems that had true positive threat detections, were moved into prevent mode in less than a month with no reported impact.&nbsp;
Shortly after moving the pilot users to prevent mode, we migrated the entire fleet of user devices to prevent mode with zero reported issues.&nbsp;
The difference in visibility we now have into our endpoints is amazing. We can be using remote response on an endpoint across the globe and see the signals from the endpoint in both the endpoint console and in Kibana — in close to real time. The level of detail in the signals is better than we have typically seen with other endpoint security tools we’ve used in the past.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc00422b5bf702433/5e470eacca06ad274a65b76f/Securingendpoints-blog-elastic-SIEM-signal-and-resolver-view-console-1.jpg" data-sys-asset-uid="bltc00422b5bf702433" alt="Securingendpoints-blog-elastic-SIEM-signal-and-resolver-view-console-1.jpg">

<figcaption>(Top) A Signal in the Elastic SIEM app for an Elastic Endpoint Alert with logs for the same host inline with the Signal. (Bottom) The Resolver view, in the Elastic Endpoint Security console, showing the process lineage associated with the same alert.</figcaption><h2>From Elastic workstation to server fleet protection and beyond </h2>Now that our Elastic workstations are fully protected by Elastic Endpoint Security, we have begun our pilot of placing the Elastic Endpoint Security agent on our server fleet. We’ll be targeting all our server resources that bring you Elastic Cloud and enable us to deliver the Elastic Stack.&nbsp;
This rollout will probably take a bit more time than our endpoint rollout. We have a broader set of operating systems and cloud providers to test on than we did for workstations, but we’ll get there soon enough.
We’re excited to continue using the Elastic Security solution and all the integrations it has with the Elastic Stack. We’ll keep providing feedback directly to the Elastic teams working on the product, workflows, and integrations. We see this as a really great internal partnership.&nbsp;
Best of all, we’ll continue being Customer Zero so that our customers can benefit from well-tested and thoroughly deployed Elastic solutions and products.
Mandy Andress is CISO at Elastic; Darren LaCasse is Principal Analytics and Detection Lead I at Elastic; and Brian Milbier is Principal Security Assurance Analyst I at Elastic.

AUTHOR

Articles By Mandy Andress

Protect your Elasticsearch deployments against attacks like “meow bot” — for free

Elastic on Elastic: Securing our endpoints with Elastic Security

注册 Elastic Cloud 免费试用版

产品和解决方案

公司

资源

解决方案

Elastic (ELK) Stack

新增功能

AUTHOR

Articles By Mandy Andress

Protect your Elasticsearch deployments against attacks like “meow bot” — for free

Elastic on Elastic: Securing our endpoints with Elastic Security

注册 Elastic Cloud 免费试用版