[01:00.880 --> 01:01.720]  Hello, everyone.
[01:01.960 --> 01:04.260]  Welcome back to another exciting talk this afternoon.
[01:04.520 --> 01:05.740]  How's the conference going so far?
[01:06.680 --> 01:07.080]  Excellent.
[01:07.440 --> 01:08.900]  Well, thank you for being here.
[01:09.040 --> 01:13.320]  We're excited to be back in person for another hope, or a new hope, I should say.
[01:14.180 --> 01:15.200]  Thank you for participating.
[01:15.360 --> 01:16.140]  Thank you for all your speakers.
[01:16.140 --> 01:21.360]  I hope it's been as interesting and valuable to you as it has been to everyone who's been here so far.
[01:21.360 --> 01:23.440]  So a couple of quick schedule notes.
[01:23.720 --> 01:27.560]  Tonight, there is a change in schedule in this room, actually.
[01:28.140 --> 01:32.700]  Instead of the social steganography lecture or talk, it has now been changed.
[01:32.820 --> 01:34.820]  That one's been changed tomorrow morning at 10 a.m.
[01:35.140 --> 01:38.800]  We'll now be doing a talk called Medical Devices, Security and Privacy Issues.
[01:39.140 --> 01:40.060]  She's dead, Jim.
[01:40.220 --> 01:40.700]  Not really.
[01:40.940 --> 01:42.720]  So if you can join, please do.
[01:42.820 --> 01:43.960]  I'm sure it'll be an interesting talk.
[01:44.800 --> 01:50.100]  If you are interested in helping out, we still do need workshop helpers, especially for tomorrow.
[01:50.620 --> 01:52.320]  There's some left today, but for tomorrow.
[01:52.520 --> 01:59.480]  If you're interested, go talk to the Info Desk or look up Mitch on Matrix and ask him how you can help.
[02:00.200 --> 02:01.480]  Hackers Got Talent is tonight.
[02:01.920 --> 02:02.780]  Get your talent ready.
[02:03.580 --> 02:04.760]  You don't need to sign up.
[02:04.860 --> 02:07.120]  You can just go up and request to participate.
[02:07.380 --> 02:08.680]  It should be interesting and fun.
[02:08.920 --> 02:11.800]  I'm looking forward to seeing all the interesting talent that comes on stage.
[02:12.640 --> 02:14.780]  Thank you for wearing your mask throughout the conference.
[02:14.980 --> 02:15.920]  We really appreciate it.
[02:16.040 --> 02:20.580]  It has been very helpful to us to help maintain our commitment to everyone's health and safety.
[02:21.500 --> 02:24.820]  If you have a phone, please make sure it's turned off for this talk.
[02:25.080 --> 02:25.600]  It's important.
[02:25.840 --> 02:31.280]  The audio-visual equipment is very sensitive and picks up cell phone chatter very easily.
[02:31.840 --> 02:33.480]  And with that, this is a virtual talk.
[02:33.680 --> 02:35.960]  If you have questions, we'll pin the questions to the end.
[02:36.020 --> 02:40.180]  The speaker won't be able to see you or hear you directly.
[02:40.180 --> 02:41.980]  So they'll go through their talk.
[02:42.160 --> 02:47.740]  If you have questions, you can either enter them in the Matrix chat for this talk, or you can save them to the end of the QA.
[02:48.260 --> 02:54.180]  You can relay them to me, or you can come to the speaker, the microphone, and relay them to the speaker when we get to the QA session.
[02:54.780 --> 03:03.400]  So with that, the talk is Combating Ransom War, Evolving Landscapes of Ransomware Infections in Cloud Databases by Aditya Snu.
[03:03.400 --> 03:05.680]  So with that, off to Aditya.
[03:07.280 --> 03:08.000]  Thanks, man.
[03:08.940 --> 03:10.420]  So let's get it started.
[03:10.880 --> 03:13.940]  First of all, I really want to be, you know, very proud to be here.
[03:14.120 --> 03:24.180]  And the reason for that is because I believe that, you know, HOPE is such a great platform where you can present your research without any hassles of, you know, marketing and all that.
[03:24.180 --> 03:30.260]  It's a pure piece where we actually go ahead and share our research, and that is one of the most driving factor, you know.
[03:30.460 --> 03:37.220]  We love to be here, and we'll really be very thankful to the committee members who are giving this opportunity to us.
[03:38.100 --> 03:39.340]  So let's get it started.
[03:39.700 --> 03:42.360]  So today's topic is about Combating Ransom War.
[03:42.580 --> 03:47.900]  The idea is to understand the evolving landscape of ransomware infections in cloud databases.
[03:48.620 --> 03:55.260]  We have talked about, you know, ransomware infections that are happening in end user systems, you know, and organization and all that.
[03:55.440 --> 03:57.100]  But these guys are not stopping there.
[03:57.300 --> 04:01.240]  They are actually going after databases, whether it's on cloud or on premise.
[04:01.640 --> 04:04.280]  But in this research, we are going to focus on that.
[04:07.460 --> 04:10.080]  So before moving further, a little disclaimer.
[04:10.700 --> 04:16.980]  So the idea behind the presentation of this research is to share the intelligence with the security research community.
[04:17.780 --> 04:21.400]  The target is the research can be used in myriad of ways.
[04:21.640 --> 04:27.200]  You know, every individual can go back and utilize this research, build new stuff, new tools.
[04:27.620 --> 04:34.120]  And actually can, you know, how as a collective, as a security community, we can go ahead and come back ransomware.
[04:35.280 --> 04:36.760]  And that is the most important.
[04:36.960 --> 04:44.920]  Because as a community, we need to come together and share our intelligence and research so that we can make the best of the ability of ourselves.
[04:46.020 --> 04:50.040]  So with that, a little bit background of mine.
[04:50.270 --> 04:50.960]  Who am I?
[04:51.200 --> 04:52.900]  I have added a couple of links.
[04:53.120 --> 04:55.360]  If you're interested, you can take a look at it.
[04:55.680 --> 04:59.830]  The main purpose of having this slide is to show that what we are going to present.
[05:00.020 --> 05:05.210]  We've been working heavily on this part as a part of our research and threat intelligence.
[05:05.260 --> 05:10.090]  We've been into this field and we are going to share pretty interesting insights with you.
[05:10.090 --> 05:16.460]  But you can go and look into some of my links, where you can find background information.
[05:16.760 --> 05:20.000]  And a lot of other additional research that we have done in the field.
[05:23.220 --> 05:25.880]  So let's talk about what the agenda going out today.
[05:26.520 --> 05:30.880]  So at first, we are going to look into the modern applications architecture.
[05:31.360 --> 05:34.580]  Very important to understand how the technology world is evolving.
[05:35.460 --> 05:41.180]  Then we talk about, you know, how cloud databases are heavily used from modern applications.
[05:42.400 --> 05:46.400]  Of course, we are going to look into threats that are targeting cloud databases.
[05:47.240 --> 05:53.600]  And after that, we are going to understand what are the infection root causes for that?
[05:53.720 --> 05:56.200]  You know, why attackers are going after cloud databases?
[05:56.420 --> 05:57.340]  You know, what are the reasons?
[05:57.340 --> 06:01.740]  We will look into the real world examples of infected cloud databases.
[06:02.420 --> 06:16.300]  And then we'll introduce two tools that we have developed, Enfilot and Straffware, that actually help you to figure out what kind of cloud databases are out there that are infected with ransomware.
[06:17.080 --> 06:23.380]  So these are very specific tools to MongoDB and Elasticsearch, which we'll talk about later in this talk.
[06:23.380 --> 06:28.820]  And of course, we will conclude where we stand and what's the future ahead of us.
[06:31.420 --> 06:36.080]  So let's look into the modern applications architecture and why it is important.
[06:36.260 --> 06:42.580]  It is important because, you know, this is a world where we are deploying the infrastructure in cloud, right?
[06:42.780 --> 06:46.900]  Because of mobility, data is expanding at an exponential rate.
[06:47.080 --> 06:48.840]  You know, the way data transactions are happening.
[06:49.020 --> 06:51.240]  So we need a different applications architecture.
[06:51.240 --> 06:57.420]  We just cannot rely on old traditional technologies because that's not how the world is at the moment.
[06:58.800 --> 07:03.840]  So let's take a look into as an overview to just set the baseline.
[07:04.140 --> 07:18.000]  So if you look at into this basic architecture, what we are highlighting here is that, you know, starting from the deployment side, you know, when we perform code development, you know, DevOps operations are being done, you know, the code is spec'd up,
[07:18.440 --> 07:19.620]  code wrappers are designed.
[07:19.820 --> 07:26.060]  Then, of course, we have continuous integration and continuous deployment pipelines with an integration with an automation.
[07:26.060 --> 07:35.820]  And then you have a sporting infrastructure with respect to it, like infrastructure, you know, what kind of security networking, application networking, and the applications to deploy.
[07:36.380 --> 07:43.760]  But if you look at on the right side, the more important part is that when you deploy the code within a proper automated way in the cloud.
[07:43.760 --> 07:47.760]  So what exactly you're going to consume there is a part of the infrastructure.
[07:48.400 --> 07:49.940]  Those are like cloud services.
[07:50.220 --> 07:53.660]  We have either it can be entirely on cloud or we can have a bare metal.
[07:54.440 --> 07:58.880]  And then we have, of course, the most important part here is the the database.
[07:59.960 --> 08:03.960]  And why it is so important, because that's where your currency resides.
[08:04.200 --> 08:06.840]  When I use the term currency, I'm talking about e-currency.
[08:07.100 --> 08:11.760]  And when I talk about e-currency, I'm basically adhering to the data.
[08:12.220 --> 08:17.500]  Because when you process the data, ample amount of information is extracted out of it.
[08:17.640 --> 08:20.300]  And that is the most important key these days.
[08:20.560 --> 08:27.160]  From business purposes, from any part, you know, understanding the insights and everything, you need data.
[08:27.160 --> 08:29.480]  And that's where the money is.
[08:30.540 --> 08:38.140]  Rest is all about a sporting factor, which are going to actually translate, you know, the data factors into many different areas.
[08:38.440 --> 08:42.740]  But the most important part in this case is that, you know, the databases.
[08:43.380 --> 08:47.680]  And that's why attackers are going after them, because that's where the money is.
[08:48.540 --> 08:55.380]  But overall, if you look at it, we have different components these days as a part of our proper DevOps practices.
[08:56.080 --> 09:03.540]  But at the end of the day, when the applications, you know, ingest data, at the end of the day, the data goes back into the database.
[09:04.380 --> 09:12.440]  And with that, we need to look into the different cloud databases that are used by modern applications these days.
[09:12.440 --> 09:21.620]  Why I'm very specific to cloud databases, because our research is focused on the databases that are deployed in the cloud and have an external interface.
[09:22.260 --> 09:24.880]  That's how these applications are interacted with it.
[09:25.340 --> 09:28.460]  Basically, you talk about SaaS applications, right?
[09:28.460 --> 09:31.740]  And that's why we are very specific to cloud databases.
[09:32.060 --> 09:36.500]  But the research cannot be only adhere to cloud databases here.
[09:36.660 --> 09:41.440]  It can be any type of databases deployed in on-premise or in cloud as well.
[09:43.120 --> 09:46.380]  So let's take a look into the cloud databases scenario.
[09:46.640 --> 09:51.860]  In very simple terms, you know, we have a relational databases, we have non-relational databases.
[09:51.860 --> 09:56.420]  These days, non-relational databases are also very important.
[09:56.420 --> 09:59.720]  And if we categorize them, we will have Elasticsearch, Solar.
[10:00.100 --> 10:03.460]  We will have MongoDB, you know, CouchDB and all that.
[10:04.140 --> 10:09.700]  The idea is to do more frequent and fast transactions that happen via an application.
[10:10.180 --> 10:16.640]  Because we need to process the incoming data in a very fast manner and give the responses.
[10:17.000 --> 10:20.800]  And that's why some of the way, you know, people are preferred non-relational databases.
[10:21.400 --> 10:25.080]  But it doesn't mean that, you know, relational databases are out of the way.
[10:25.260 --> 10:28.120]  They are still there with the sticky applications in the wild.
[10:29.300 --> 10:35.480]  But what we are seeing right now is that, you know, where you have to develop cloud applications, non-relational ones are the key.
[10:36.080 --> 10:44.360]  And if we categorize them further, you can clearly see as a part of the structure query languages, we can have no SQL databases or a SQL based.
[10:44.860 --> 10:50.680]  Of course, we have to write down proper structure query language and very definitive queries to query that database.
[10:51.180 --> 10:54.740]  Processing time is high, you know, latency issues and all that.
[10:55.100 --> 10:57.880]  But no SQL architecture is different.
[10:58.480 --> 11:11.320]  More fast operations result in faster responses, which means that you can move your data faster based on a very smart decisions by the infrastructure resources, as well as by the applications.
[11:11.320 --> 11:21.640]  So if user, for example, if user is moving in and out of the different geographical boundaries, you need to ensure that, you know, data transactions are happening at faster pace.
[11:21.900 --> 11:30.140]  You cannot go back to your part of the core data center to just have the database process those requests.
[11:30.140 --> 11:37.020]  But you need to figure it out multiple ways so that, you know, with the mobility and a fast data transaction speed that happens.
[11:38.000 --> 11:41.560]  With that, it also gives rise to the new threat models, right?
[11:42.140 --> 11:52.240]  If we are not following the traditional set of technologies or architecture, and if we are going after new architecture supporting modern applications, the threat model changes as well, right?
[11:52.240 --> 12:04.180]  So what exactly I mean by that, you know, if we're deploying applications in cloud, the threat changes, the perception changes, and the way attackers are going to target these application changes as well.
[12:04.360 --> 12:07.280]  So that's what the perspective is, right?
[12:07.360 --> 12:09.300]  So every threat model is specific.
[12:09.940 --> 12:23.360]  You can have a standard security controls and force, but it cannot serve the purpose in the entirety, because at the end of the day, you have to be very specific to your needs, and you have to build threat models according to that.
[12:24.440 --> 12:31.360]  So with that, let's just understand a few characteristics of white cloud databases used for modern applications.
[12:32.220 --> 12:36.440]  More important part is like a peer-to-peer cloud syncing for mobile and edge computing.
[12:36.600 --> 12:45.760]  You define edge, and you have to make sure that data syncing happens in a very fast manner, or a peer-to-peer in the same node, or in the same cloud, in the same VPC.
[12:46.220 --> 12:51.040]  And that actually helps with the design of new NoSQL databases.
[12:52.640 --> 13:03.960]  We really need a high-performance memory-driven databases that actually help us to build and perform distributed transactions in a short period of time.
[13:04.200 --> 13:07.000]  And that's where NoSQL-based databases are.
[13:07.820 --> 13:25.360]  We really need an integration with a multi-cloud or a hybrid cloud environment, because, for example, in certain organizations, you can have your data stored entirely in the cloud, or they have a hybrid infrastructure, which means some of the data, depending on the criticality or sensitivity,
[13:26.080 --> 13:29.820]  stored in the cloud, and other one will be on-premises.
[13:30.080 --> 13:34.220]  So you really need to build a solution that actually integrates with both scenarios.
[13:35.000 --> 13:43.280]  And, of course, we need something which is, like, accessible via query score, which means you can write very generic queries, and in every infrastructure, it works efficiently.
[13:44.960 --> 13:54.400]  So there are some of these factors why these NoSQL databases like MongoDB and Elasticsearch, etc., are the preferred choice because of these capabilities.
[13:54.780 --> 13:58.980]  And that's why you see heavy deployment of these databases in the cloud.
[14:01.940 --> 14:17.080]  So now the next question is that, at this point of time, we looked into the cloud databases and the modern application architecture, you know, what are NoSQL and SQL databases, you know, what are the preferences these days, and then we actually had a look into,
[14:17.340 --> 14:25.080]  what are the reasons and the characteristics of the preferences that the developers are taking to opt for NoSQL databases.
[14:26.600 --> 14:35.320]  Now, the simple question is, do you think there are no threats that exist for these databases because they are, you know, used for modern application and deployed in the cloud?
[14:35.980 --> 14:37.200]  Let's take a look at it.
[14:38.320 --> 14:44.060]  The very first threat model that we're going to focus here is that the ransomware attacks here, right?
[14:44.840 --> 14:48.820]  As we have discussed earlier, you know, data is the new e-currency, right?
[14:49.040 --> 15:02.320]  Who controls the data, who has an entirely, you know, the complete idea about what kind of data is being stored and what kind of insights that you can get out of it will control the business flow.
[15:03.040 --> 15:07.700]  And of course, data can be processed and used in multiple ways as well.
[15:08.200 --> 15:11.940]  And the similar thought process resides in the attacker's mindset as well, right?
[15:12.660 --> 15:14.360]  What if I control the data?
[15:15.200 --> 15:15.960]  So what?
[15:16.880 --> 15:29.980]  In earlier, if you look at like a 10 years or 20 years back when we had these kind of attacks happening, more for like fun and profit, control and all that, these days, everything is translated back into monetary terms, right?
[15:30.520 --> 15:36.480]  Attackers are thinking we are being, you know, doing these kind of attack-centric scenarios for a long period of time.
[15:36.800 --> 15:38.740]  Why aren't we also going to make some money?
[15:39.300 --> 15:45.160]  And in order to do that, they really need to control the data, which means they really need to compromise the databases.
[15:45.960 --> 15:51.780]  And what is the best solution out of that is with respect to other than ransom era, right?
[15:52.160 --> 15:57.060]  Because once you infect the databases, you control the data, and then you can ask for ransom and all that.
[15:58.840 --> 16:03.000]  Another one that we are seeing all across is like the data destruction scenario.
[16:03.000 --> 16:04.880]  What exactly that means?
[16:05.480 --> 16:06.540]  You know, attackers are in mindset.
[16:06.740 --> 16:08.060]  They don't care about the data.
[16:08.320 --> 16:15.820]  All they care about is totally destructing the data, which means that it's going to resonate back into the availability scenario.
[16:16.620 --> 16:21.140]  And what happens if your applications are not able to access the data that is stored in database?
[16:21.700 --> 16:26.220]  It could have a significant impacts to the organization.
[16:26.220 --> 16:30.880]  And that is the most important threat model impacting the data availability.
[16:31.360 --> 16:44.680]  And we have seen some threats where, you know, they have designed MeowBot or Meow kind of related infections or variants of it to actually completely destroy the data in the database by encrypting it or just making it render useless.
[16:45.100 --> 16:48.740]  And we will take a look into all those scenarios.
[16:52.100 --> 16:55.380]  So let's just look at the practical threat and attack landscape.
[16:55.380 --> 17:00.380]  So in this particular talk, we are going to focus on MongoDB and Elasticsearch.
[17:01.340 --> 17:12.740]  So these are the, you know, news, you know, main headlines that will get taken out of different set of, you know, news that are being released on the Internet.
[17:12.860 --> 17:17.160]  You can clearly see how big this problem is.
[17:17.860 --> 17:19.960]  And it is not related to MongoDB.
[17:20.220 --> 17:23.000]  We'll take a look at Elasticsearch as well.
[17:23.000 --> 17:28.180]  So this actually highlights that how significant threat landscape has changed.
[17:28.980 --> 17:40.760]  Attackers are actually kind of going after MongoDB instances that are deployed in the cloud and trying to find a vulnerability in them and, you know, exploit them and install ransomware on the host.
[17:40.940 --> 17:46.200]  And then which actually basically going after encrypting the data directly into the indices.
[17:47.280 --> 17:53.260]  But this actually highlights that, you know, the problem is significant and we really need to deal with it.
[17:55.520 --> 18:06.580]  Similarly, if you look at some of the headlines that are related to Elasticsearch and factions, you can clearly see that the attackers are not stopping on a very specific databases.
[18:06.580 --> 18:09.120]  They are actually kind of go after a myriad of them.
[18:10.200 --> 18:15.040]  And you can see their started attack campaigns.
[18:15.060 --> 18:25.420]  You know, they are turning the Elasticsearch instances into a storage system which are useless in nature by encrypting the data or destructing the data.
[18:25.860 --> 18:36.280]  And that can have a potential impact on the state of the applications because if you're not going to access the data, you're not going to process the data, what will you do as a part of the business?
[18:37.040 --> 18:40.000]  It's a significant problem that we are facing these days.
[18:43.790 --> 18:49.830]  So, now the most important part that we have to understand here is, what are the infection root causes?
[18:50.170 --> 18:52.230]  You know, why this is happening in the wild?
[18:52.230 --> 18:59.470]  What are the problems or what are the issues that are residing in the environment that could lead to these kind of scenarios?
[19:01.990 --> 19:04.330]  So, there are a couple of them.
[19:04.850 --> 19:09.710]  The most important part, I will be focusing on the technical controls.
[19:11.070 --> 19:13.130]  Exposed database administrative interfaces.
[19:13.410 --> 19:23.750]  You know, you're deploying your cloud database, you know, and then, you know, you're not able to restrict the administrative interface to the specific set of authorized users.
[19:24.410 --> 19:39.750]  Because, you know, you have to configure the security groups, you have to configure some kind of access groups, and, you know, make, you know, wrong configuration there, or your configuration is not in line with the hardening guidelines that could lead to the explorer to anywhere on the Internet.
[19:40.290 --> 19:45.170]  So, once you do that, your administrative interfaces exposed, attackers can do different things.
[19:46.290 --> 19:50.710]  Another one, nobody is like untouched, why it is like a weak and default passwords.
[19:51.290 --> 19:52.610]  It's also a problem.
[19:52.890 --> 20:02.790]  Because then you can actually launch brute force or account cracking attempts to go after controlling the database by simply cracking the credentials.
[20:03.890 --> 20:09.090]  Another important part is that, you know, exploiting security vulnerabilities in the database software.
[20:09.450 --> 20:25.750]  Let's say, for example, most of these cloud databases have a network service associated with it, which means like, you know, you can access the interface any fear from the Internet, or you're residing in any geographical location on the Internet, which means there is a network service.
[20:25.910 --> 20:38.650]  And if there is some sort of inherent flaw or security issue exists, there is this opening channel where you can, attackers can target to actually exploit that vulnerability in order to control the database by sitting remotely.
[20:40.010 --> 20:47.670]  Another one is like, you know, this is an indirect way that what we are going to discuss to actually target these databases.
[20:48.470 --> 21:05.370]  It's like if you're sitting in an organization, you're working for an organization, and the attacker is able to actually control your end user system by installing a malware, and somehow you are an authorized user in a cloud environment for that particular organization,
[21:05.370 --> 21:12.570]  then the attackers can actually use your compromised end user systems to actually attack the cloud as well.
[21:12.730 --> 21:23.610]  By performing lateral movement or doing some kind of another behavioral checks, they can launch other attacks like scanning in the cloud environment once you connect it to the cloud and things like that.
[21:24.550 --> 21:42.770]  Lateral movement in cloud infrastructure, if they are able to compromise one container or they're able to compromise one VM, they can actually try to see which other containers under a specific IP address range reside in the VPC so that they can see if the same vulnerable configuration exists there so that they can actually control it.
[21:43.770 --> 22:01.490]  social engineering attacks to target cloud accounts like phishing attempts and all that, asking targeted users to actually, you know, reveal or leak the information by, you know, conducting trick rates and ensuring then the users fall for it and giving you ample amount of information.
[22:01.810 --> 22:08.970]  So there are a myriad of ways like how cloud databases are being targeted and the infections are being triggered.
[22:09.210 --> 22:13.350]  But we have discussed the main ones here, but there could be many more as well.
[22:15.210 --> 22:23.410]  So now it is important to understand from threat intelligence perspective, right, how we can collect detection signals out of it, right?
[22:23.630 --> 22:36.170]  We really need to see who is actually accessing our databases, you know, what kind of, you know, access has been maintained or what kind of incoming network connections that we are seeing and many more to it.
[22:36.170 --> 22:52.890]  So if you look at it, you know, some of the basic signal collection that you can perform as, you know, file integrity monitoring, we really need to see the critical files that are specific to different databases, how these files are changed, how these files are accessed,
[22:53.230 --> 22:55.510]  what modifications are being performed.
[22:56.170 --> 22:59.930]  And that is you can perform by file integrity monitoring on the cloud host.
[23:00.490 --> 23:12.750]  Of course, you have to go after scanning cloud databases as well, that are both authenticated and unauthenticated scans, which actually gives you the idea, the level of exposure your database is having.
[23:13.390 --> 23:16.370]  And, you know, what are the threat models that are associated with it?
[23:16.710 --> 23:23.230]  So in this particular case, you can also kind of look at the outbound connectivity, which is the most important part.
[23:23.230 --> 23:26.430]  And this is resonate back to the data exfiltration.
[23:27.980 --> 23:29.530]  How that rate is related?
[23:29.750 --> 23:35.090]  So let's say if you're one of the cloud host is infected that is running database software.
[23:35.770 --> 23:41.750]  And if you have not properly protected it, like the security groups are not there, access controls are not there.
[23:41.990 --> 23:50.050]  So the compromised host can be used to set up a communication channel with command and control that is residing somewhere on the Internet.
[23:50.350 --> 24:02.830]  But because the outbound network connections are not exactly filtered or, you know, restricted, there's a possibility that data exfiltration can take place.
[24:03.650 --> 24:11.690]  Also, you have to examine API calls on the host, how they are interacting, you know, what kind of actions they are performing and things like that.
[24:11.690 --> 24:14.770]  And there are many other ways you can collect the signals.
[24:15.410 --> 24:33.370]  But as a part of the research, what we are going to target like on the scanning cloud databases, basically the network level processes and the tools that we have developed are focused on this kind of threat intelligence practice, which means that we are going to see what is being exposed to what level it is being exposed.
[24:33.850 --> 24:36.210]  And what are the configuration of the databases?
[24:36.550 --> 24:37.510]  Can we access it?
[24:37.630 --> 24:39.090]  Can we have an administrative access?
[24:39.370 --> 24:40.570]  Can we run some commands?
[24:40.570 --> 24:43.890]  Can we run some commands and different kinds of these activities?
[24:44.630 --> 24:54.570]  And that's why our two tools that we are going to discuss with you falls into the category of scanning cloud databases sitting remotely.
[24:54.850 --> 24:57.830]  And we will show that as a part of our demo as well.
[24:59.350 --> 25:13.850]  So at this point of time, we have looked into modern application architecture, relational, non-relational databases, supporting SQL and NoSQL layout, how queries can be done.
[25:14.010 --> 25:19.610]  And then we looked into some of the characteristics of these cloud databases and why they are being preferred these days.
[25:20.270 --> 25:25.710]  After that, we'll look into the threat model of cloud databases, you know, Elasticsearch and MongoDB.
[25:26.030 --> 25:32.590]  We looked into ransomware specific threat model, also as, you know, data destruction specific threat model.
[25:33.130 --> 25:37.930]  And then we looked into some of the root causes, try to understand why it is happening.
[25:38.650 --> 25:43.670]  And now we are going to take a deep dive into the real world examples, you know.
[25:44.610 --> 25:54.330]  The idea here is to understand, you know, when Elasticsearch or MongoDB databases are infected, how it looks like.
[25:54.330 --> 25:57.490]  So in this part, we are going to take a deep dive into it.
[25:58.970 --> 26:02.470]  So let's take an example here.
[26:03.090 --> 26:13.950]  So in this specific layout, you can clearly see this one is related to Elasticsearch primarily, but I think this one is also related to the MongoDB, which we'll take a look at it.
[26:14.490 --> 26:22.170]  If you take a look at it in this particular scenario, we were actually going through one of the database, either a collection or an indices.
[26:22.670 --> 26:34.870]  And you can clearly see in this part, there is a ransom message added to it, like all your data is packed up, you must pay this to this Bitcoin ID and things like that.
[26:35.170 --> 26:39.550]  So this is how exactly some of the signals that we collect.
[26:39.910 --> 26:45.350]  And this is giving you the example of how infected database actually looks like.
[26:46.590 --> 26:56.330]  So if I go to the next level, I have not actually masked the IP addresses to just highlight, like these are the real world that are exposed and how it looks like.
[26:56.410 --> 26:59.050]  So you can give it a try later on as well.
[27:00.230 --> 27:04.630]  So in this particular example, this one is related to the Elasticsearch.
[27:04.690 --> 27:06.970]  We are going through the list of indices.
[27:07.170 --> 27:12.850]  And if you look at the list of indices, you can clearly see there are a couple of entries here.
[27:12.850 --> 27:22.110]  And if you look at it in a very detailed manner, you will try to see, hey, what exactly this thing is, like a random string within a tag with a meow.
[27:22.410 --> 27:24.870]  And it is related to a list of other indices.
[27:25.110 --> 27:28.990]  Then you see another entry and then you kept on seeing the other entry.
[27:29.450 --> 27:34.450]  So now what you want to take a look at it, let me grab all the entries that has in a meow.
[27:35.430 --> 27:38.010]  This string identifier associated with it.
[27:38.010 --> 28:04.110]  So when we trigger that command that you can clearly see there, there were a lot of indices that were available in that compromised database that actually highlighted that this database is infected with meow ball, which means that they have made the data completely useless by encrypting it in a multiple way so that you are still not able to grasp that data back.
[28:04.610 --> 28:08.910]  But this is exactly, you are picking all this information sitting remotely.
[28:10.830 --> 28:26.330]  And now, if we take another example of this thing, to look it into a bit of more details, when you... this is an example, I took it from another elastic search, you know, database, which was infected.
[28:27.130 --> 28:31.790]  We try to go into all the indices and then, you know, grabbing up that string.
[28:31.910 --> 28:33.530]  So you see a lot of entries here.
[28:34.790 --> 28:39.230]  And then you have like, you know, all that related information, you know, stuff like that.
[28:39.510 --> 28:45.730]  So when you go into a detail of that entry, let's pick up any entry, this one, and see how it looks like.
[28:45.910 --> 28:56.630]  So insidious, you can clearly see, you know, all the information that are available, like what is related to index creation date, number of shots, replicas, UUID, and things like that.
[28:57.450 --> 29:05.670]  So this... this way, you can go in an iterative manner to dig more deep into it and try to analyze what exactly it is all about.
[29:05.930 --> 29:12.310]  But this... these examples, speaking from the real world, exactly highlighting how the infections are happening.
[29:13.690 --> 29:22.190]  Now, let me discuss more example in a scenario for the infected MongoDB instance.
[29:22.750 --> 29:31.950]  So in this particular case, when we're querying, so as you all know, MongoDB, you actually have a lot of collections in it, right?
[29:32.070 --> 29:36.070]  Which is associated with, you know, a database has a lot of connections in it.
[29:36.330 --> 29:38.090]  So what exactly you have to do?
[29:38.230 --> 29:47.590]  You have to enumerate all the databases, specific available in that instance, and then you go for every single collection in that database.
[29:48.430 --> 29:49.730]  What happened in that case?
[29:49.890 --> 30:02.530]  So you have to enumerate each and every, and then you have go to the level two to enumerate each and every collection for different set of signals that you can extract and figure out, okay, this is somewhat related to ransomware.
[30:02.890 --> 30:10.790]  So in this particular case, as an example, you can clearly see in MongoDB, we have a lot of collections and the collections like system.indices.
[30:11.370 --> 30:13.450]  And that interesting one is, oh, come on, readme.
[30:14.130 --> 30:17.190]  And when you say the name, it says readme to recover your data.
[30:17.190 --> 30:21.390]  This actually started highlighting there's some problem associated with it.
[30:21.810 --> 30:30.610]  And this actually gives you the idea based on intelligence, like this MongoDB is potentially infected or the data is being controlled by some sort of ransomware.
[30:32.650 --> 30:41.210]  And similarly, which we have seen as an example in Elasticsearch, we also want to take a look at it, this database, which is infected.
[30:41.670 --> 30:56.190]  In this particular case, this is also a MongoDB, but this has like a lot of other things available here, which means the indices and how it looks like, although these are green in nature, but most of these are kind of infected with that.
[30:56.290 --> 31:13.350]  So it highlights that in this particular MongoDB instance, the data is completely corrupted, and there's no way you can get it back, which means it falls into the scenario of data destruction, which entails like whole database is now corrupted.
[31:13.630 --> 31:15.290]  There is no way you can get it back.
[31:15.470 --> 31:17.410]  If you don't have the backup, it's a problem.
[31:18.550 --> 31:36.090]  But this actually gives you the idea where we have picked up two different examples of Ransom and Meowbot and mapping and map them to MongoDB and Elasticsearch by analyzing real-world case studies, how these databases are getting infected in cloud.
[31:37.930 --> 31:51.270]  So now, before going further and demonstrating and discussing about the tools that we have designed, I want to discuss a very fantastic real-world case study, you know, how cyber wars are being done.
[31:51.270 --> 32:00.350]  It is usually these wars don't need to be between the nation states, but they can be much more focused and target between the adversaries.
[32:00.670 --> 32:05.010]  And we can categorize adversaries, good or bad, depending on the scenario.
[32:05.290 --> 32:09.370]  But let's say it's between whiteheads and, you know, the proper attackers.
[32:11.210 --> 32:12.610]  So let's talk about it.
[32:12.730 --> 32:21.490]  This will give you a very interesting, you know, understanding, I would say, like how these wars are being fought on the Internet.
[32:21.910 --> 32:25.830]  Many of you might already know about it, but it will be good to discuss it.
[32:26.370 --> 32:43.470]  So we came across, when we're doing this research and all this, we came across very specific, compromised, Elasticsearch and MongoDB instances where, when we are analyzing the indices or collections, we found that, you know, exactly there was some specific company name is being used.
[32:43.470 --> 32:47.290]  And we were like kind of, you know, amazed like why this was happening.
[32:48.370 --> 32:55.070]  So in this particular case, you know, there is a one company associated, which is doing ransomware negotiations and digital investigations.
[32:56.070 --> 32:59.270]  And they are providing very good set of services based on what they do.
[32:59.510 --> 33:12.530]  I'm not going to go deep into, you know, the practices they have, but like they claim, you know, they are going to help you in a post breach scenario and help you to get your data back by simply attacking ransomware operators.
[33:15.270 --> 33:19.750]  Now, this is an example of a compromised Elasticsearch instance.
[33:20.310 --> 33:25.790]  And if you look at it in this one, you can clearly see, you know, everything is yellow and open, which is okay.
[33:26.110 --> 33:31.250]  But then they are seeing read me hacked by Nightline security and all those kinds of things.
[33:31.390 --> 33:34.430]  So you see similar random strings here and all those kinds of things.
[33:34.590 --> 33:42.050]  But in this day, the indices are being encrypted, but they are using the identifier for that company.
[33:42.450 --> 33:45.030]  I'm not going to, you know, I did hide it.
[33:45.470 --> 33:49.470]  Gus will want to show that, you know, how these things are happening in the wild.
[33:50.110 --> 34:06.230]  So this ransomware group compromises exposed databases and alter the name of indices to the name of a security company and highlighting like, you know, these are specifically, you know, these are being managed or the infections have been triggered by this security company.
[34:06.330 --> 34:13.870]  So it was like, I know, a kind of like a cyber war, an arms race, but it was like a tough to predict what exactly going on in the back end.
[34:14.250 --> 34:21.370]  But initially, the idea was that, you know, the ransomware guys say, okay, you give these services, we're going to go utilize your brand and do these kinds of things.
[34:22.570 --> 34:26.050]  But this is a real world example that we have seen in the wild.
[34:27.230 --> 34:31.690]  So now in this particular example, this is for a compromised MongoDB instance.
[34:31.950 --> 34:35.390]  But again, if you look at the ransom message, it is pretty interesting.
[34:36.230 --> 34:39.950]  Now these read this message, you will get an idea.
[34:40.030 --> 34:43.490]  Hey, we are ethical cybersecurity company, this and that, all these kinds of things.
[34:43.510 --> 34:45.450]  If you don't get your data back, we'll help you.
[34:45.450 --> 35:01.910]  But in fact, what is happening, of course, these companies providing that kind of information or services, but the attackers or the ransomware operators are also utilizing that baselining information from this company to actually attack them indirectly.
[35:02.490 --> 35:08.350]  The ransomware group tried to put blame on security company by injecting this and that and those kinds of scenarios.
[35:08.770 --> 35:11.730]  So you can clearly see the world we are living in.
[35:11.730 --> 35:19.890]  And you know, the good researchers are also fighting with the adversaries, the way you actually define the terminology.
[35:20.630 --> 35:30.290]  But the most important part in this case is to understand, you know, when we really need to build threat intelligence in this space, how critical we have to think about it.
[35:30.390 --> 35:31.790]  You know, what exactly is going on?
[35:31.870 --> 35:36.330]  You know, if the company is providing this kind of service, why ransomware operators are going after them?
[35:36.330 --> 35:40.530]  And you see these kinds of things out in the wild pretty effectively.
[35:40.970 --> 35:50.390]  So when you build threat intelligence, you really need to make sure you filter out the right artifacts so that the intelligence can't be compromised in that way as well.
[35:50.630 --> 36:03.110]  But I want to highlight it because this is a very important and interesting case study so that you can figure it out apart from the direct targeted infactions that are happening in MongoDB or Elasticsearch instances or many more.
[36:03.270 --> 36:06.450]  I'm not saying like the CouchDB or MySQL are not untouched by it.
[36:06.690 --> 36:12.010]  Our ongoing research is focused on MySQL and we're seeing a lot of infections there as well.
[36:12.270 --> 36:19.550]  But this case study actually highlights, you know, the fight between security company and ransomware operators as well and how it looks like in the wild.
[36:21.210 --> 36:33.010]  Similarly, continuing on that, you know, we actually went ahead and looked into those indices, what exactly it is all about and all those kinds of things to just figure it out how deep the problem is.
[36:33.770 --> 36:35.450]  But this is a real world scenario.
[36:35.570 --> 36:37.210]  It's happening in front of us.
[36:37.290 --> 36:48.090]  And then we really need to, you know, accept that this is a problem and how we are going to solve it or at least reduce it to minimum to minimize the impact.
[36:49.710 --> 37:00.650]  So now with that, you know, we did all those, you know, look into modern application architecture, look into the root causes, we looked into real world case studies, you know, how cloud databases are impacted.
[37:01.210 --> 37:06.030]  I think it's a time what we have to do as a response.
[37:06.370 --> 37:09.430]  So as a part of our research, we developed two tools.
[37:09.910 --> 37:12.270]  We named them as Straffer and Enfilet.
[37:12.270 --> 37:21.330]  The Straffer tool was designed and to actually detect potential infections and elastic search instances.
[37:21.750 --> 37:31.690]  And Enfilet tool is actually being defined, designed to actually go finding security issues, primarily ransomware infections and meowboard infections in MongoDB.
[37:32.110 --> 37:33.750]  So let's take a look at it.
[37:34.570 --> 37:44.470]  If we look into the Enfilet, so these are the different modules we have, you know, it's going to check the verification for different, you know, authentication and authorization.
[37:45.070 --> 37:46.770]  It's going to help you dump info.
[37:47.110 --> 37:50.810]  It's going to help you to check whether you have an admin access one or the other way.
[37:51.370 --> 37:53.970]  And then there are like four different modules here.
[37:54.170 --> 37:59.070]  The basic check ransomware, where it actually going to trigger a simple query to get an idea.
[37:59.370 --> 38:02.030]  Did we see any initial signals?
[38:02.490 --> 38:05.070]  Whether the MongoDB is infected or not.
[38:05.190 --> 38:07.030]  Then it goes for intrusive check as well.
[38:07.690 --> 38:10.190]  So this is a layout how Enfilet works.
[38:10.630 --> 38:17.610]  And you can get an idea and you can utilize this tool, enhance it, because I'll share the links later on as well.
[38:19.650 --> 38:21.390]  And how it works, right?
[38:21.490 --> 38:25.830]  So if you look at in this one, I typically give an example of intrusive check ransomware.
[38:25.830 --> 38:32.550]  And I'm actually going to have a proper demo as well for you all, so that you can actually enjoy it and see it in the real world how it looks like.
[38:32.790 --> 38:39.170]  But this output actually highlights how it works and how it's going to look into it.
[38:39.250 --> 38:41.910]  So it's going to extract the ransomware message and things like that.
[38:43.550 --> 38:47.810]  But it's a pretty interesting example and layout to see what it is all about.
[38:49.470 --> 38:51.370]  Similarly, we have a Straffer tool.
[38:51.650 --> 38:53.990]  It is focused on elastic search deployments.
[38:53.990 --> 39:02.410]  Again, it's going to check, you know, ransomware infections, miobot, essunny underscore hp, which means like it's going to detect.
[39:03.170 --> 39:06.830]  Honeypot, which is essunny or espot honeypot.
[39:07.050 --> 39:08.890]  It has the capability to detect it.
[39:09.090 --> 39:25.770]  For example, if you are going to scan elastic search instances, it will actually gives you the idea that rather you're scanning a real world instance, which means like it's a real cloud instance exposed on the Internet, specific to an organization, or you are actually scanning a honeypot.
[39:27.010 --> 39:34.270]  We also have an updated version of Straffer tool, which has like intrusive check and basic check, which I'll show you a little later on as well.
[39:35.630 --> 39:55.070]  And then if you look at the example like this, so the tool is actually going after, okay, give me the ransomware output, which means that, you know, we use ransomware module and check whether the remote elastic search and science is infected with that or not.
[39:55.270 --> 40:03.850]  So when it runs properly against the things and patterns and all that, it actually dumps you that, which actually contains the ransom message as well.
[40:03.850 --> 40:06.630]  And it, it usually does it automatically.
[40:06.990 --> 40:08.150]  Everything is automated.
[40:08.370 --> 40:09.170]  You have to just try it.
[40:10.190 --> 40:16.050]  So with these two tools, there are, you can utilize it in a multiple ways, right?
[40:16.250 --> 40:20.570]  You can use these tools to conduct proper track research.
[40:20.570 --> 40:38.550]  You can use these tools in an automated way to launch scan and figure out if your own environment or on cry-stational environment is running these instances, whether these are exposed or not, or whether those instances are, you know, kind of thing infected with ransomware or other data destruction,
[40:39.270 --> 40:39.730]  malware.
[40:40.570 --> 40:47.270]  In addition to that, you can also use this tool to add more modules to, you know, take it to the next level.
[40:47.270 --> 40:52.850]  You can design wrapper functions around it, you know, specific to your own needs because the source code is available.
[40:53.490 --> 41:09.070]  And the idea behind designing these tools is to share, you know, how as a collective community, we can go after and, you know, combat ransomware infractions or data destruction, malware, that is targeting our critical assets in the cloud, which are databases.
[41:10.690 --> 41:14.430]  So with that, let's take a look into the demonstration of these two tools.
[41:14.430 --> 41:20.990]  And I have a recorded videos and it's going to run against, you know, live, you know, IPs.
[41:21.790 --> 41:31.210]  There are high possibility that those IP addresses or different cloud instances are not available anymore, but you will have a good output in that case.
[41:31.410 --> 41:33.890]  So let's take a look into this first example.
[41:36.880 --> 41:39.720]  So we're using Enflat tool in that.
[41:39.940 --> 41:44.360]  It gives you the kind of different modules or stuff it has available.
[41:45.040 --> 41:51.940]  So very first, we are going to use basic check for detecting ransomware against a real-world IP.
[41:54.520 --> 41:56.040]  So let's take a look into it.
[42:02.750 --> 42:14.690]  So when we ran this command against that, so you can clearly see the output, it is exactly showing, okay, MongoDB is hosted on this, with this port address, where it is located and things like that.
[42:15.170 --> 42:21.490]  But did you see, we also see there is a one suspicious database just showing like, read me to recover your data.
[42:21.750 --> 42:22.850]  That's pretty interesting.
[42:23.850 --> 42:27.710]  So with that, we have to actually go ahead with the intrusive check.
[42:28.150 --> 42:29.390]  Let's take a look into it.
[42:36.410 --> 42:46.870]  So when this tool ran, now it gives you the idea that, you know, what kind of ransomware infection is being present in the targeted IP address here.
[42:47.200 --> 42:52.350]  When I say targeted IP address, basically the IP address of the cloud database instance.
[42:52.930 --> 42:59.700]  And now you can get very determined output that, hey, this is infected and what we really need to do with that.
[43:00.500 --> 43:05.480]  And similarly, I'm just doing a rerun again here so that you can get an idea.
[43:06.290 --> 43:10.410]  Again, the basic check for the ransomware infection.
[43:10.680 --> 43:13.240]  Again, it is impact, you know, working pretty fine.
[43:13.430 --> 43:18.180]  And when you run, again, the intrusive check, it gives you the very detailed response with that.
[43:19.060 --> 43:22.680]  So this actually highlights how Enphalite works in real time.
[43:22.890 --> 43:28.480]  You can utilize this tool to actually conduct this kind of activity and many others.
[43:32.170 --> 43:38.470]  So now we are going to take a look into the Straffer tool demo.
[43:38.670 --> 43:39.870]  Let's take a look into it.
[43:42.210 --> 43:50.750]  So the idea in this case is to show how we can still detect infection in elastic search instances using this tool.
[43:53.230 --> 43:57.390]  So this exactly show two modules which are like detecting the honeypot.
[43:57.570 --> 44:00.530]  But what we are going to look into this case is
[44:04.270 --> 44:05.450]  one example here.
[44:05.630 --> 44:07.930]  So this one is related to the elastic search.
[44:08.110 --> 44:10.810]  You can clearly see the output has been different here.
[44:11.450 --> 44:21.450]  This is able to detect several patterns and then, you know, compute some score and then actually went ahead and actually dump that message as well, which is available in one of the elastic search indices.
[44:23.690 --> 44:29.630]  Similarly, you can get in a whole idea and you can imagine you don't have to do anything different here.
[44:29.790 --> 44:35.110]  You got to use the tool, run it against your elastic search instances and try to determine that.
[44:35.470 --> 44:43.470]  And even for that research, you can do, you know, define a wrapper and, you know, utilize this tool to, you know, use it within a mass scanning as well.
[44:43.810 --> 44:48.190]  If you want to, to just get an idea what kind of infections are being seen.
[44:51.080 --> 45:05.840]  So now in this example or a demo, what we are trying to see the Enfilet tool in action again, but this time the tool is going to detect MeowBot in factions.
[45:06.760 --> 45:12.240]  So we have two modules here, basic check for MeowBot and intrusive check for MeowBot.
[45:12.240 --> 45:17.520]  And we are going to run it against the real world instance.
[45:18.100 --> 45:28.440]  And now you can clearly see when you did the basic check, it is actually going through every single collection or database that is available.
[45:28.700 --> 45:31.460]  And then try to figure out what exactly it is all about.
[45:31.460 --> 45:41.780]  So when it went through all the databases that were available and enumerated, you could have seen that it is actually going through the objects, collections and everything.
[45:43.280 --> 45:45.180]  But this is the basic check.
[45:45.320 --> 45:49.300]  So you can exactly kind of go after and do the intrusive check as well.
[45:50.960 --> 45:52.880]  Let's take an output of the intrusive check.
[45:54.480 --> 45:55.820]  It is going to start the loop.
[45:55.960 --> 46:03.280]  It is going to go to every single database, all the collections, and you can keep on dumping what is associated with it and things like that, object IDs and all.
[46:03.560 --> 46:06.500]  So this actually helps you to gather more information.
[46:07.280 --> 46:15.600]  But even at this point of time, you are pretty much sure that remote database, the cloud instances infected with MeowBot.
[46:15.920 --> 46:17.800]  So this was an example of that.
[46:20.060 --> 46:27.540]  So with that, there are certain things that we really need to look into as this as a whole research.
[46:28.800 --> 46:39.320]  So we want to conclude and infer at a certain point so that we can actually get an idea like where this research, you know, why we started this research, where it is leading and what is an outcome.
[46:39.720 --> 46:54.840]  So we understand the whole new posture of modern applications, cloud databases, threats that are residing in cloud databases, infection root causes, you know, how the real world looks like, you know, infections that we have seen and the tools that we have designed.
[46:55.760 --> 47:07.400]  But in order to just get to the pinpoint, we really need to understand and adhere to the reality of this world, which means like ransomware attacks are causing serious disruptions to the businesses.
[47:08.660 --> 47:12.040]  We really need to find a way to handle these attacks proactively.
[47:12.360 --> 47:28.500]  When I say proactively, which means like, you know, we need to have a defense in depth mechanism in place, but we really need additional custom controls that are specific to the organization environment, including educating end users to handle these attacks more proactively.
[47:30.080 --> 47:38.400]  There should be a dire need for conducting regular security posture assessment for different resources on the infrastructure.
[47:39.660 --> 47:47.480]  If that is in a cloud or on premise, there shouldn't be a way like you're doing a penetration testing for, you know, 365 days or one time, and then you are okay.
[47:47.600 --> 47:49.840]  No, it has to be weekly basis.
[47:49.960 --> 47:51.280]  It has to be the monthly basis.
[47:52.180 --> 47:59.120]  We really need... we are in a world where we are dealing with a scalable platforms where a lot of data resides.
[47:59.340 --> 48:00.680]  We are ingesting a lot of data.
[48:00.840 --> 48:16.080]  So we have to harness the power of artificial intelligence or machine learning to detect anomalies, and then having hybrid systems to use signatures as well to ensure we are actually detecting a kind of needle in a haystack, right?
[48:16.700 --> 48:22.700]  If you're deploying cloud databases, you have to go after building a hardened security configuration.
[48:22.700 --> 48:38.740]  There should be a policy which actually talks about in the organization if you really need to deploy cloud instances or databases, there should be a stringent security check that should be available before these resources are being deployed.
[48:39.340 --> 48:42.920]  Of course, maintain the cloud hygiene for databases.
[48:43.160 --> 48:43.960]  Very, very important.
[48:44.320 --> 48:56.280]  You know, patch vulnerabilities, making sure that you should not waste time in patching the critical resources that are required in your organization, typically software-specific or even hardware-specific as well.
[48:56.620 --> 49:05.740]  So overall, one security controls or you can say one set of security controls cannot solve this purpose.
[49:05.920 --> 49:14.320]  There are multiple set of security controls need to work together in conjunction to fight against these threats because these are really advanced threats.
[49:14.500 --> 49:18.060]  So advanced security techniques and tactics are required as well.
[49:18.980 --> 49:22.760]  So with that, there is a tools repository available.
[49:22.760 --> 49:30.240]  You can see that, you know, on the GitHub and fill out stuff where you can get it here, how we have developed this tool and all that.
[49:31.240 --> 49:34.080]  And with that, thank you very much.
[49:34.160 --> 49:40.540]  And I really appreciate for attending this talk and, you know, taking time out.
[49:40.880 --> 49:45.020]  Hopefully, we have shared and learned together the new things.
[49:45.020 --> 49:49.080]  Hope this research gonna be very useful to you.
[49:49.500 --> 49:51.060]  More feedback is welcome.
[49:51.380 --> 49:54.380]  Feel free to, you know, contact and talk about it.
[49:54.740 --> 49:58.280]  I'll be more than happy to work with that.
[49:59.000 --> 50:07.220]  Again, I will be... I'm very thankful to the whole security community and, you know, giving me this opportunity to talk about it.
[50:07.660 --> 50:08.340]  Thank you very much.
[50:08.480 --> 50:09.320]  Really appreciate that.
[50:10.040 --> 50:11.120]  Thank you, Aditya.
[50:11.880 --> 50:15.500]  We have time for maybe one question, if anyone in the room has a question.
[50:16.720 --> 50:17.160]  Sure.
[50:17.960 --> 50:18.340]  All right.
[50:18.400 --> 50:20.480]  We have one question to the Matrix chat.
[50:21.440 --> 50:35.020]  Would such ransomware and Cloud DB attacks be mitigated if the applications employ multi-tier architecture where only the web server can talk to the app server and only the app server can talk to the database, so the database is not directly exposed to the Internet?
[50:36.220 --> 50:36.660]  Absolutely.
[50:36.660 --> 50:43.100]  I think the... I think that the way caution is asked, it actually highlighting the solution as well.
[50:43.340 --> 50:46.580]  See, that's where the defense and depth mechanism comes to play, right?
[50:47.080 --> 50:54.180]  We, as a part of the designing, when we're designing security controls, these are the most important part, right?
[50:54.500 --> 50:59.780]  Why you really need to give a more exposure to the critical services when they are not required.
[50:59.940 --> 51:13.700]  When the application server need to talk to the database, there should be a proper security controls, filters are in place, that should be defined right away at the time of deployment, so that unnecessary exposure can be curtailed, right?
[51:14.040 --> 51:17.780]  Why you really need to have your cloud databases exposed on the Internet?
[51:17.940 --> 51:19.220]  What is the purpose behind it?
[51:19.220 --> 51:29.560]  This is happening because people are... there are ways we are either having, you know, issues by defining hardlining, hardening guidelines.
[51:30.160 --> 51:36.260]  Also, we are also in a process of having a lot of errors because we want to deploy the things without checking the configuration.
[51:36.620 --> 51:39.620]  We are not looking into the alerts and things like that.
[51:39.620 --> 51:45.240]  But in reality, everybody is not used to this kind of advanced technologies, right?
[51:45.380 --> 51:58.320]  That's where the technology experts, the developers, the administrators need to play a very vital role, ensuring that these kind of critical resources when deployed, they should stick to a specific set of controls.
[51:58.920 --> 52:02.740]  Otherwise, it's a tough and it's a nightmare we are living in.
[52:03.040 --> 52:04.940]  People call as, oh, this is a fur.
[52:05.000 --> 52:06.820]  This is not fear, uncertainty, doubt.
[52:06.820 --> 52:07.720]  This is a reality.
[52:07.940 --> 52:10.280]  And we have gone through several cases through it.
[52:10.460 --> 52:22.100]  And that's where we say security design before even exactly the deployment is done is a more important aspect so that people have an idea when they really need to define or deploy these things.
[52:22.400 --> 52:23.940]  They do that properly.
[52:24.920 --> 52:25.580]  All right.
[52:25.760 --> 52:27.140]  Thank you so much for your talk, Aditya.
[52:27.280 --> 52:28.860]  And thank you for the audience for attending.
[52:31.500 --> 52:32.320]  Thanks, everyone.
[52:32.560 --> 52:33.560]  Really appreciate that.
[52:33.680 --> 52:34.140]  Thanks a lot.
[52:34.920 --> 52:37.360]  We'll be doing our next talk in 10 minutes.
[52:37.620 --> 52:39.140]  Cat-shaped hacker hardware.
[52:39.380 --> 52:41.040]  How I accidentally made a business at 18.
[52:41.460 --> 52:43.000]  So, please come back and join.
[52:55.590 --> 52:56.590]  Hello, can you hear me?
[52:56.990 --> 52:57.810]  Yeah, I can hear you.
[53:00.790 --> 53:01.230]  Excellent.
[53:01.830 --> 53:02.570]  Yeah, all right.
[53:03.010 --> 53:03.190]  Yeah.
[53:03.370 --> 53:03.650]  Thank you.