GF - Adversaries Also Lift & Shift: Cloud Threats Through the Eyes of an Adversary

my name is AD inov I have experience of 12 Years in cyber security before moving moving to cyber security I worked at software engineering for seven years hi my name is Roy Sherman I'm the field CTO for mitiga uh I was doing offensive security for the last decade and now I move to defensive I have a bachelor's degree in information security uh and a master's degree in criminology because I have a thing for bad guys um part of the bites Tel Aviv organizing team and amateur home Brewer let's

start when we talk about the cloud it's doesn't just the cloud provider we also include any system or appication that provide services in the cloud you can see here the trends in the SAS Market the number of the sus companies and end user uh spending on public CL Services is expected to increase which why we are focusing on our attackers are adopting their strategy on cloud attacking

there's several good uh thank you thank you there's several good reason why company moving to the cloud companies can reduce spending on purchasing and management Hardware the maintenance it's much easier uh it's allow organization to adopt new technologies uh the time the time downtime is is very low and enable businesses easily to uh to scale their resources up or down based on current needs however it's important to note that security is not one of the reason to be this shift the number of attacks on the cloud also increased those system have become attractive targets for attacker they uh very uh the very large volume of sensitive data and critical businesses processes being handled by S

application make them ey value targets Cloud application are internet facing which make it easier for attacker to find weaknesses and exploit viabilities compared to on pre on premise application that are protected by additional layer security such as firewall or VPN uh let's talk about uh this uh use case uh it's very familiar a Russian cyber group called Midnight blizzard attacked Microsoft by using password sparing attack to access a legacy nonproduction uh test tenant accounts that didn't have MFA enable and moving to the Microsoft corporate production tenants and by that uh they access to internal uh systems and also source code if you're not familiar with uh what is a password spraying attack it's a type of Brute

Force attack so it means that all the attacks that perform over there are very clown known uh simple and very easy everything was cloud only Microsoft are a big cloud provider and still miss this for month like you can see over there Microsoft invest a lot of information sec in a lot of information security but still had a misconfiguration issue in the cloud uh as already know that uh both companies and attackers move to the cloud now let's see the differences between clouds uh attack and defend and defense and defenses uh what is the difference between cloud and on pre you can see here that attacks are much easier on the cloud and uh defense are more

challenging this table shows high level overview of the differences Sherman will drive in uh each or one of them all right so we see that even big companies like Microsoft still struggle both with the basic security in their Cloud even though they are one of the main cloud service providers and we can also see that attackers keeps focusing on cloud we had snowflake very recently which was only a cloud only attack um but we'll start with the attacker POV which is my favorite po to be honest to go through each one of the items we mentioned each one of those topics to talk a bit about how it looks from both the attacker and the

Defenders so from the required skill set perspective we know that when you attack an on Prem environment or technology you have a lot of the basic computer knowledge required like basic networking subnetting um how things work protocols SMB nlms you need to even have a basic understanding on how to compile and run exploits everybody that went through the ocp uh courses saw that we struggle a bit until we figure out how it works we have exploit DB now we have geni and all those fancy things but still you need to have some sort of basic knowledge and understanding how things work before you can come in and start breaking them apart you have a lot of Technology you

need to learn how to bypass one of the most common uh topics discussed today for red teers is how to bypass edrs you have whether it's unhooking and other different types of techniques and almost every other week somebody comes out with a new tool or a new technique against EDR and eventually even if you're targeting the database of a company on Prem or their application or whatever it works on a computer or a server that has an operating system so whether those are Linux or Windows based you still have an operating system you can either Target or interact and try to fight with on the other in Cloud everything has a UI everything has a portal fancy buttons

you can click you don't need to have very deep internal knowledge on how those Services work or operate if you want to interact with them so if you want to download an entire AWS bucket you just have a checkbox you Mark and click download that's super easy also everything is available over apis because Cloud was made to make it lives easier when you want to orchestrate stuff when you want to deploy things everything has an API I so interacting with it is very straightforward has very good documentation and we have wide uh misconfigurations that are super common I'm personally familiar with over 20 different open source tools that Target AWS buckets or Azure storage accounts or

gcp storage all of them Target the same things publicly accessible with Anonymous access that you can do pretty much everything so from we mentioned a few tools and and that's the thing tools are something easy to burn or to Mark as a Defender you either get signatures you either get how they operate on on Prem what they target what they do what they execute so from a defense perspective mimicat probably gets an update twice a day today but still we get those signatures from our defense tooling and our security structure we also have the C2 Frameworks but those now come with a cost some of them open source which are a bit harder to maintain harder to use

if you're are less experienced but if you want the top tier you need to pay money and it's not very easy because those when you pay and you need to have a license they try to crack down on the uh frat actors that are using them for malicious purposes which makes it harder for criminals to obtain them unless they go for the pirated version which usually is much less secure for them but for us that the red teamers the pan testers we have mimik cats which is commonly a available and everybody already knows how to use it we have the endday exploit so when CV comes out usually in a few days you'll have a walking exploit

somewhere and you have those Frameworks that collect all of those exploits whether it's Metasploit for the the Legacy folks out there but also other options in Cloud it's very hard to defend against those tools because you don't really have a hash you don't know when somebody's running a specific tool against your infrastructure because as we mentioned everything is tied to the API so those tools to attack Cloud are basically somebody that's coding how to interact with specific apis as a specific order to automate those types of activities and as an attacker you don't really need or or use a zero day or an end day unless you are a state Nation or something like that because

you don't really need it and it will Target the actual infrastructure which is much harder to exploit and compromise rather than specific services that probably are misconfigured by your uh victim the security tax stack so a lot of acronyms I'm sorry that's the industry we live in but um in on-prem we have many we have the edrs for the end points we have IPS and idses for Network neack for the physical connection uh internal firewalls for segmentation we have bir directional firewalls we have a lot of different technology that we are already familiar with a lot of the companies already bought over over 100 different types of security tooling for their own Prem where in Cloud we are

only starting so we are all familiar with a cspm because they almost sold for Google for like 24 billion dollar but we have some common acronyms to be honest we're doing Cloud for a living we don't remember all of them I had to Google some of them to put them in the slide of of what they actually mean but the common theme for at least the first the the top three of them is security configuration they look at how are you configured and not how you are actually ready to do something detect something or respond to something the last category the tdir and the CDR are looking at that portion to see all right we have the configuration thing sorted

out is and now we need to see what we do for actual uh active defense and the perimeter that's something everybody already heard of that the new perimeter in cloud is identity it's a cliche it's funny but it's still true because when you want to get your initial access and you want to compromise a company or Target their own Prem infrastructure you need to get a foothold within the environment so whether it's fishing and you need to land with a Mel on the host or fishing for credential and you need to find a way to remotely connect whether it's Citrix VPN any type of remote connection into the company or you can find the vulnerability which one of their uh

external Footprints so whether it's an un Pet Service a shadow it somebody forgot about or something you need to compromise or for some of us that's the favorite way physically get into their offices plug something into the network and then you have that access so you have that actual step of breaking sort of a boundary in order to get into the company so it's not necessarily more difficult but it's still more work and we already know that hackers are lazy that's what makes us good at what we do so we'll try have the least amount of uh in um investment on our side to get the biggest amount of um value in Cloud all you need is identity and it doesn't

really matter if it's a human identity like username and password and MFA fatigue or no MFA um or just a non-human credential an API key somebody forgot in one of the commits in GitHub or anything you manage to get from a different company at the end of it we'll talk about a different another use case where a company was breached using a non-human identity and then what was stolen from them are a bunch of non-human identities for their customers which makes this cycle much more uh vicious so attackers stopped from breaking in we started to log in and talking about detection so as we mentioned where we talk about on-prem we already know sort of what's suspicious

so sorry um yeah thank you um so everything that interacts with Els that's not common we already know it's weird it's suspicious it's something want to look at if something you want to block um we have the signatures we mentioned we have the old technology all right ntlm or in some cases LM um we have technology designed to identify when exploits are running through the network um fancy ways for execrating information whether it's DNS that's uncommon anomalies stuff that's out of pattern in Cloud every activity the attacker takes is the same activity as an admin or a developer would take the only difference would be their intention and currently it's very very hard to build detections for intent

because in the end of the day you might have anomalies but every organization is different and as a Defender you also want something that's still made for your organization but when you work with a community everything has to be generic so everybody can adopt it so it makes it much uh harder for us to improve our detections in the cloud because somebody replicates a cloud or a storage account we don't know if it's an attacker replicating it for an unplanned backup they're going to do for us or it's an actual it guy doing their own backup routines people adding integration apps whether it's slack uh code repositories whatever we have today that's integrated with SAS whether it's something they

want need and approve to do or or is it something an attacker puts in to have additional access to our infrastructure somebody spinning up huge GPU instances in the cloud they might be playing with generative AI they might mining uh cryptocurrency we need to figure out which use case is it and of course the creation of non-human identities we we have developers building cicd pipelines or building automations but we also have attackers creating back doors and persistency for themselves so we had all how it looks from the attacker perspective but we're here to talk about also about defense so same structure same things but from the defense perspective so technology nonrem didn't really change much so everybody

talks about gen post Quantum encryption um whatever nothing really changed we already familiar with the architecture of how companies are build so they might be a little bit different but the Core Concepts are still the same all of us are familiar with a active directory lateral movement PR escalation common attacks blood hound attack paths all of those things we monitor for specific event IDs if you take a blue teamer that's doing this for a couple of years and you ask them wait what's the event ID for a uh account lockout or a karo's ticket being extracted or anything like that they know all of those numbers from the top of their head we have common ensured seam queries and

playbooks very easy to to investigate to match against but in Cloud it's it's very different when a bucket leaks out that's a fancy code of unwanted access and it's very hard to determine all right does it actually licking or we wanted it to be accessible what's the architecture when you talk about the cloud footprint because different companies use different clouds some of them are multicloud resources might be for the same purpose but they are built and Inter interconnected in a different way so it's much harder for the Defenders to figure out how how our architecture looks like and should that service communicate with that service on the cloud are they related uh is it something going to backend from our

providers and of course when we want to start an IR and we know the attacker access the SAS platforms so in this case let's take HR and let's assume they change the payroll uh details on a bunch of employees we don't control that app we don't host it we don't have the operating system logs on it and now we're depending on a third party that might have the logs or not they might lie about having the logs and then we can't figure out what really happened and in the end of the day when you build a Playbook and you build it for a Windows Os or a Linux Os or something within your own Prem it's very generic

you can use it across the board but when you build something for aw it won't work with gcp and it also won't work with Azure and won't work with any other provider especially not with any SAS platforms so some of the common figured out security for defense we already have so for on pram we have ioc's we have hashes we have signatures we mentioned that a lot of times so far but we have also Sigma Yara snow tools we have things that are already out of the box or require a bit of customization we can isolate resources and host using our EDR we can patch V ities when they come out usually um but in Cloud we are much more

limited from an ioc perspective we have IPS and domains because we don't really have mware running on our own resources we might have some threat actors if somebody works for a fret Intel company I'm sorry don't come at me that that's the truth but we have IAS indicators of activity as we mentioned so we know somebody's doing something but is it a bad thing is it a a routine or is it just somebody doing something they shouldn't do we can't really isolate resources we can take them down we can limit access but it's not really isolation and it's not centralized the way we have it on Prem and of course we can't really patch if a cve comes in for

the infrastructure for AWS or Azure we're um for security tax TX so as we mentioned from we have a lot of acronyms again but all of them sort of make sense because on CL on on Prem they work together they're interconnected they're centralized it's easier to see everything in the same place or at least most of it in the same place in Cloud we have a problem so we have logs there are never real time in best case they're near real time because stuff happens then your vendor your Cloud security provider so your cloud provider needs to process them generate them and then ship them to your own Sim and that takes time so in some cases signing logs

which are critical logs in most cases will take at least 15 minutes before they uh populate in your environment so that's super difficult and the visibility which is one of before the left piece we have on Prem we can enable policy across the board easy we build it once run it everywhere same structure for the logs so we vent logs from every operating system so every windows in system we look the same have the same structure the same content everything's figured out common types whatever we use we know it's the same everywhere in Cloud first of all most of the logs are turned off by default because they cost money and when you want to enable them

you need to understand what you're enabling where you're enabling it and to enable it everywhere so in AWS for example when you enable something it's only in the region unless you go and do it everywhere it's not super easy or straightforward unfortunately and it's something that's usually being missed and the content of the logs and the structure is very different so AWS logs looks very different from Azure logs that look different from gcp logs because those are almost non-existent um and SAS does SAS have logs most of them claim they do then you go for an IR and they start like saying yeah we are working on it let us like come back at a

week or so when we can in other cases and in this casee slack and Microsoft I'm looking at you it's blocked based on your license level so if you're using the basic tiers for Licensing in some of those sess platforms you don't have logs available for you in any case and for the last piece our responsibilities accountabilities all of that structure so in on Prem we know who is going to do what we can yell at each other afterwards that they did a poor job but we know who should do what so it's much easier between it security cyber security socks sa Ops whatever usually they also have administrative access so they can either go with in the

network or isolate using their own tooling every time something new gets spun up on your environment on Prem it automatically gets your security policies or your sock package basically in Cloud a lot of different teams they have Team devops Dev sa Ops sack Ops suck nobody really knows who doing what where and when the sack Ops doesn't have administrative access they don't manage the cloud that's different teams and then when they want logs enabled they ask a different team that's not a security team those are clicking a few buttons and nobody really knows if it was configured correctly and of course again we don't have any control about Cloud recess vulnerabilities so if tomorrow slack Monday walk day snowflake

has a problem which is a vulnerability we can't patch it for them we have to wait for them to figure it out so just to wrap it up another use case I want to go through and this was what happened with cens so basically somebody bad managed to compromise one of the gitlab accounts which got them code access and there they found a non-human identity they use that to go into their AWS S3 bucket and steal all of that which is terabytes of information and cens are serving hundreds if not thousands of customers and within this bucket they had more excess keys for other companies which make this go round and round and round and now targeting a lot of other

companies and those those companies needs to figure out all right which credentials we had with cens can we map those against our environment can we see which activities and actions They carried out do we know which time frame because it came out in April but we don't know where the actual breach occurred or we cannot be certain of it and the only recommendation cing out out of this whether it's cisa or C ciso or whatever was to rotate your credentials so it basically was a simple attack somebody got access to something no vulnerabilities no exploit no zero day uh no nation state attackers nothing fancy but in the end of the day somebody got credential it's a non-human

credential got terabytes of information with more credentials and now we need to figure it out so to wrap up few I would say recommendations from us to you so next we walk on that visibility we mentioned because we know we don't have logs and we don't have good visibility we might have logs available that we do not collect or not enabled or if they're enabled we need to make sure they're enabled across the board all regions all Cloud providers all SAS platform that we already use we might don't see it in their configuration so it's worth reaching out and asking them do you have security logs because in a lot of cases they will have sort of application SL

debug logs which are less effective for security and next month try to see how you can enable security tooling available from your provider so AWS has guard uty Azure has security Center and Microsoft Defender for cloud gcp has the Google Cloud security Command Center GE that's long um I don't know if all of them are free depends on tier licenses whatever check it if you have it available start using it they generate some of the alerts you want to see as a starting point and then you can expand on doing all right uncover your unknown unknown which is another cliche I hate but it's still true get a red team a good red team to start breaking things and then

when you can see what they broke and you don't know where they went when they got into that specific s platforms that's a visibility Gap you want to address and then start building your anomaly detection and your behavioral detections that means that we said we can detect tools however if you have a tool you can start seeing how it's structured which API it calls in which uh way method which time frame between each call it helps with detections it won't solve security unfortunately uh but it's still something better for your Cloud environment thank you for having us [Applause]