Cutting Through Cloud Policy Obfuscation With SkyScalpel - Abian Morina & Daniel Bohannon

Thank you very much. Follow me. Mita, did I say that right? Yeah. CN. Awesome. Well, thank you so much. Uh, this is Skyscal. Um, and we'll be talking about some fun offiscation related to cloud policies and the like. Um, Unuheim Daniel Bohannan. Uh I'm a principal threat researcher at Promeo Security where we do uh cloud and identity uh detection and some really fun engineering and research. Um uh I've spent my career u solely on the defensive side doing an incident response detection engineering um and now uh research uh in areas of offiscation and evasion um uh which this research uh has has a lot to do with. I'm a big fan of open source tools uh

and and coffee and uh again it's been really nice meeting a lot of you in this room yesterday and so hopefully you find this interesting and um yeah that's that's enough said about me. Uh feel free to call me dbo for short. That's what that's what most people call me by. Hello everyone. Uh my name is Abian Marina. I'm a threat researcher over at Primeo for over probably two years now. Uh uh you can see my blogs over at Aban Marina. uh at Permiso website. Uh I've been over doing threat detection uh lately over at Promeiso. Uh I've been presenting recently. My first year presenting was last year. I was over at SANS uh blue team con and uh three black

hats. And this is our first open source tool that we released together with dbo which was uh my uh manager. So, so yeah, let's talk about it. Uh, we'll keep the intros pretty short um to the problem and then spend most of the time looking at some fun offiscation. Uh, and uh should have a lot of fun. Uh, so sometimes people ask us how did like what's your research process? How did you end up at this kind of weird place? Um, and it really depends. Uh, every research is different. Sometimes it truly does have a very clear starting point and you have the destination in mind and it's a pretty straight path to get there. Uh, this was nothing like

that. This was a really winding road and every finding that we found was honestly not that interesting by itself. But when you start to piece all of these things together, it actually adds up to something quite interesting. Um, and so we're going to share kind of all the building blocks. In this case, most of the building blocks had their greatest effect in the context of cloud logs. So at Promeo, uh, we're doing cloud um, research and detection and investigation. And so we live and breathe by uh event logs, runtime logs, API logs. Um and so the interesting thing here is that when it comes to logging, uh unless you're the developer writing the logs, the consumer just has

to kind of deal with whatever the logs look like. Uh you are you're beholden to whatever the vendor produces in the logs. And um those vendors are also humans. Humans make mistakes and logs are not perfect. And so oftentimes we find logging inconsistencies and even errors or omissions where something should be there and is not or a boolean says it's true but it's actually false. Um and so we have to deal with all these from an engineering perspective uh with our engineering team. But what's really cool is from a research perspective. What are the logging inconsistencies that no one has found yet or that people haven't talked about yet? How does that affect us when we're trying to detect

malicious activity? and then how might that affect an attacker who wants to use that inconsistency to evade uh simple detections. So we'll be talking about some of the syntactical opiscation of JSON at a really generic level because a lot of cloud policy documents are in the JSON uh notation or format and then we're going to talk about some really interesting quirks of JSON uh some of the complexities around cloud policy evaluation which is a really really deep uh topic and then we'll look at not only syntactical but also logical offiscation of these policies. Um, so for anybody who's in the room who has never done anything with cloud, I really I I think you'll find a lot of value out of some

of the JSON sole JSON tricks that we'll be talking about. Um, and so hopefully you'll find that interesting. And if anyone in here has done a lot of really cool work with JSON, we know you have stuff to teach us. And so we'd love to talk with you afterwards and hear what tips or tricks you'd have that you didn't see us talk about. Uh so we're going to talk about these little uh tips and tricks in isolation, but more importantly, we're going to show how stacking these things together can produce some really nice evasive qualities um when it comes to uh the area of uh of cloud uh security uh policies. Um so with that, let's dive

in. Let's talk about these building blocks as well as the kind of recipes of how we combine these to get different evasive qualities. So when we wanted to show you about the RFC, about JSON history and formatting, we thought of reading all the 16 pages of RFC format here on stage. But that was a like a long list. So we thought of doing a Google notebook LM to hold a podcast for us. But then also I thought we can just maybe show you because it's easier. So uh JSON allows uh uni-ode encoding. If we can see here for the country kosovv uh the letter uh which is e with two dots it does escape handling

for escape nonsi characters but that's not just for that you can do uh that in JSON in both the values and the properties of the JSON as we can see over there. Uh besides that there's also insignificant whites space. Now for insignificant wide space there's space horizontal type line feed or new line and there's carriage return. So uh focusing on just those two uni-ode encoding and in insignificant whites space a simple policy like that one can look into something like this. Yeah that's pretty crazy but uh uni code encoded can be decoded and insignificant whites space is insignificant. So uh that can be removed but something that I want you guys to pay attention at is

this last one the carriage return. Now I'm going to take an example catting three different JSONs and uh by just looking at these JSONs which one of these guys uh do you think is the evil policy? So what are these JSON doing? At the first one we see that is allowing IM list users. So probably listing some users. The second one is doing allow S3 list buckets. So probably just listing buckets. And the third one is just doing deny an action all. So if you thought that all of these are malicious then you were correct. So we can see at the first one if we hit the pipe jq into it we can see that it was hiding two action I am

pass ro and ec2 run instances which is used for privilege escalation vulnerability from rhinoc. Second one we can see that there's a full hidden statement hidden uh at the uh JSON and at the third one we can see that it was denying a decoy action. So it was denying something else and uh it's actually allowing uh everything. So if we pipe jq how this this happened. So this is because of uh the carriage return. If placed correctly the carriage return will put the text that was written and overwrite it. So you won't be able to see it. Uh as we can see uh highlighted in yellow uh we can see how it was placed and uh it removed and uh

you couldn't see it. Now there's another case. Let's uh we're doing the same JSON but using jq and we can see that it's saying n uh name benign example meaning nothing to see here and score zero. Uh this is where uh another thing shows up the duplicate properties. As we can see, there's more. So, uh, without the JQ. So, before we did JQ, now we're doing just cutting the JSON, we can see that there's more at the JSON. We can see that there's two names, there's two meanings, and there is uh five scores. Now, if we check over at the uh uh questions about does this allow it, we can see that in short answer is yes, but

it's not recommended. And we can see that the names within an object should be unique. So it doesn't take a hard stance on uh being different. But also it says in other words if they're uh if they're the same values in the same key uh the last value wins. So we can see the last one that was written it will be shown at the JSON. Okay. So what did we get from this? There are some uncommon rendering tricks when it comes to JSON. But what's important is the context and the truth is dependent on specific tooling that we use. So we saw the cat and the jq. Uh so it's important to validate the findings

in multiple ways. But where else can these tricks really affect us? So that's where the problems of obiscating JSON really show up. Yeah. So if we think about all these are generic to JSON as a looked at the RFC and these are all things that are explicitly defined and allowed or pseudo not recommended in the case uh that he just covered. So if these apply to any JSON document then where how does that affect me in my job you know uh so when it comes to cloud there are many different um places where you'll find uh JSON. Uh so we'll just give a couple examples here. Um I I think specific examples are helpful especially when it starts to look pretty

crazy with all this offiscation. So we'll start with something sane. Um AWS SSM documents when you're doing run commands to basically issue commands on remote systems that are part of this uh SSM service uses a JSON document. Um if you are using cloud formation again kind of think of it like terraform like uh infrastructurees code and you can define all these things as JSON blocks and this one even has JSON within JSON it has an embedded uh IM policy. So these are just three quick examples of yes, JSON is used uh often in the cloud and in fact these aren't just random examples. These are examples of things that are part of known uh offensive attack tools uh that

are open source like uh PCU from Rhinocox um uh from Bishop Fox. Uh and in fact, these aren't just a couple of random tools like these are ones that we actually see in the wild. Um uh right out a year ago, there's a really nice blog post by the Invictus IR team based out of Amsterdam. Um, and uh, the blog post is called the curious case of danger dev proton mail. Uh, and it was really neat because it was a really nice blog post and uh, there's a guy named Nick Fchett who works as a researcher working at data dog and he had a really nice Twitter thread about all the interesting novel things he found uh, in

this cloud attack uh, that Invictus posted. Uh, and so our team was going through a little exercise of hunting and we actually discovered uh, that this attack was actually from a a known tool. In fact, it was this CloudFox tool. And so we we uh tweeted a little something out and had this nice exchange of yeah look at look at the ordering of these API calls. Look at the ordering in the the JSON syntax of the policy in this command. It lines up exactly with what we see uh in the source code. Uh even seeing a year before that there had been a couple updates to that source code. Um, so it's really cool. Like I we're

huge fans of open source tools and especially as defenders, like we should take the time to to hang out with the red teamers to learn the tools they use and to take advantage of the open source tools that are out there. Uh, and if we're actually really really kind and smart, we would hang out and exchange those ideas back with the red team and say, "Hey, how would you evade this detection that we have?" Uh, and so, uh, uh, Ev and I appreciate you because we did that quite a lot back in the day and it really helps refine Red and Blue together. So, uh, hopefully I don't know that's a whole separate conversation, but I hope that's a good takeaway.

There's a lot that we can learn from each other, uh, in exchanging those ideas. So, basically when we got to this point, um, Abon and I realized, you know what, let's just take a policy and let's just poke at it. In fact, this was our internal code name for the project before Sky Scalpel was just policy poking. Let's poke at it. Does it still work? because we can change a couple things and it looks different, but if it still functions the same, then we're getting some good evasive qualities. Um, so how did we go about poking at policies? Well, if we're targeting an AWS policy, let's go to AWS into the actual policy builder. So, here's an

example of us building a pretty simple policy that allows these sets of actions. And we have five actions here. Um, you'll notice the one that's highlighted is actually just uh nonsense. It's not a real action. So um this is helpful to understand can you create policies that contain nonsense and and you actually can. Sometimes the UI prevents you from doing some things but allows you to do others. In this case it allows us to create this policy. Um now this is this is the default view which is JSON. And if you notice there's a nice visual button there. If we were to click that it actually groups all of the actions by their service. Um so the

the service name is the first prefix. AM is the service colon and then the API name. However, when we did this, we realized it actually grouped the IM service into three tabs, which is kind of weird. The whole point of grouping is to make it a little more concise, right? So, if we expand the first one, we see, okay, this is like this this looks normal. It makes sense. It's showing us one of the actions from AM is specified. But if we click the other two, they actually show an error. It says, hey, this we don't even recognize this action. which is weird because when we looked at it before it had no problem recognizing that action and what we

realized was this grouping in the UI is actually case-sensitive grouping because this im is all uppercase this one has an uppercase A and the previous one was all lowercase so even in the UI now we realize okay some of their validation is case sensitive some is case insensitive what what's actually true like we're we're trying to ask the product tell us teach us what's true and what's possible and it's kind of giving us conflicting answers um and so in this case again it comes comes down to correct casing versus incorrect casing. So if we were to say, okay, AWS, you say this is incorrect casing and you don't know what this is. This action totally exists. You

already told us that in the JSON view. Let's click on edit and see where we go from here. So if we click on edit here, it's going to say, hey, we don't recognize this action. Might be a typo. Blah blah blah. Okay, we quickly see it's probably a casing issue. Let's change that a and p to lowercase. Um or let's actually change it to a single character wild card. And here is where we see another bit of information which says, "Hey, the action names must be 2 to 64 characters and contain only alpha numeric or the asterisk wild card." Okay, so that so single character uh wild cards aren't a thing. Got it. Thanks. So, uh let's replace that then.

Uh let's replace those characters with wild cards. Perfect. Now it's happy. It says this matches one action. You're good to go. Perfect. So mission accomplished like uh it already told us alpha numeric wild cards are the only thing that's allowed. Yeah, it's a little flaky on not fully understanding casing but we know that casing uh is not sensitive because we can test this policy and see that we have um that we have the right access. Then uh a month before we finalized this research, a familiar name, Nick Fchett, uh tweeted this little gem and he said, "Hey, Monday night trivia. What actions does this policy permit?" And he has loaded it with a familiar service name

and then uh what is that? Nine nine question marks. And I thought, "What a troll. This guy's awesome. Obviously, it's an invalid policy because the question marks aren't allowed." Um, and immediately Twitter responded as Twitter responds with a classic Simpsons gift. But then when the more serious answers came in, people were saying, "Is it everything? Is it is it these specific ones? Is it all nine?" They're counting these things. And then finally, someone got the right answer, which is none. Like it's like, cool. Somebody gets it. But then right after that, someone else just says, "Nick, no. Don't do this. Don't do this to us, man." And this is when I kind of we thought like, did we

miss something? Like I I swear I know that AWS literally told us it's alpha numeric or wild cards. Um and so uh one of our other teammates is a guy named Nathan who is uh really smart and really funny and will give you the truth in really unique ways and we shared this with him and he said oh dude that that's totally permitted. I'm like well how do you know that? He's like well let me show you. So sure enough we go and try it and and it does work. But so and then we went back to our notes and was like a niku like were we were we wrong? Did we miss something when we started this

research? So we went back and retraced our steps and we went back and said, "Okay, AW AWS, let's ask you one more time. How do we how do we get this uh this action? Let's start with the letter C invalid." 2 to 64 characters. Again, this should look really familiar. We keep typing create. Okay, it's still not uh resolving to an action. Throw that wild card in there. Perfect. All right, this resolves to 14 actions. Now, here's what's interesting. We remove that wild card and it still says 14 actions. Okay, this add action button went away, but this message was still the same. And then we start taking off character and character and we realize we can

literally put almost anything we want as long as we don't remove all the characters. And the UI is still telling us this resolves to 14 actions which clearly it doesn't. So we play around with it some more and then we finally add a wild card and now it resolves to one. It's like what is going on with this thing? Then we tried some other things. Casing, it still says casing is case sensitive. We know that's not true. Okay, what if we change this to to hex? It doesn't appreciate that even though we know this works in policies. Let's change it to those question marks. It doesn't think it's correct. What is going on? Why not throw an extra

question mark onto the end? What do you think would happen when we did that? The whole thing crashed. Like the UI literally crashed. It's like, okay, clearly something weird is going on. Um, so then we went through and tried to figure out why is it crashing if it ends with three question marks. So, we did some manual testing and then realized, you know what, all the cool kids are just pulling up developer tools. So, we did that and realized it's actually a reax uh error. So, as we're typing into this field, it's performing regular expression evaluations to say how many actions it evaluates to. Uh, and so we found a couple fun scenarios that cause

this window to crash and it makes sense when you look at the reax that it's actually producing and trying to run. Um, so we actually looked at the source code itself to see this makes more sense while it's only updating that one message when an asterisk is present. Uh, and so it caused us to lose even more faith in how we were going about asking the UI uh, for answers. Um, so what do we do then? If you can't trust the UI, you can certainly trust the documentation, right? Right. Okay. So, what does the documentation say? It's it's a little bit better actually. Um, it does say the prefix and action name are case insensitive.

Perfect. The UI was wrong about that, but documentation checks out. You can use a wild card uh in number two and three are two different ways you can the use the wild card. But what is suspiciously missing is the question mark because we know we know the question mark works and our friend Nathan told us it works and Nick Fchett on Twitter says that it works. So why does AWS still to this day not say that this is an option? Well, this is where you have to go to other people who have explored this space before us and were so kind to write a blog about it. Um, and there's a steamp blog from two or three years ago

that actually does say multiple questions can be used to match any single character. Um, this is undocumented and seems of little value. these. If you're big into Google dorking and want to find really small gems like this, look for things like no value, undocumented, or why would somebody do this? Uh those kinds of blogs and comments lead you to things that someone discovered technically work, but they don't know the value of why. Who in their right mind would do that? Uh and that's usually a really good indicator that you're on to something that has a lot of potential. So now Avian's going to show how we can stack all these things together and hopefully not get

crushed in the process as we get into some deeper and deeper offiscation. Okay. So now we did all the research. We know what's allowed, what's not allowed. So let's gather all of those and put it all together and see what we can come up with. So the first one, uh we know that the brackets are optional. So if they're optional, why not just add them? And uh also we can just add another uh action just to make it more interesting. Uh we can do reorder properties. That's not really a big thing, but since it's allowed, we're just testing out and uh we're doing that. We can reorder action array elements. So uh we can do that as

well. Uh we can uh use action wild cards. And if we take these two, we can have uh multiple uh character wild cards and single character wild cards. And we know that question marks and uh uh asterisk is allowed. So let's add those. Uh we can do random casing. So we can uh also we added the random casing. We can also do uni-ode encoding. Now when it comes to uni-ode encoding uh we can uni-ode also the column and everything into the action. But we learned at the beginning that uh we can put any any part of the JSON we can uniode and code it. So let's add that. And uh let's not forget the insignificant wide space. And uh I'm not

going to get into the all the carriage return stuff, but just wide space alone. Now with just these, a simple policy can look like this. But uh this is a small policy. What happens if uh we play with larger policies? Now there's a few things that we should take a look at when we're dealing with this. So, we went over to the documentation for inline policies and manage policies to check if there's limitations. And we can see that there's a limitation from 2,000 to 10,000 characters. Uh so, we tested that out. And uh of course, one character uh in in a JSON, it counted as one, but with uni-ode encoding, a single character like letter A will be counted

as six uh when written into the console. Uh also we can see uh in green that there's a note the uh in quote IM doesn't count whites space when calculating the size of a policy. So we tested that out. Uh we created a policy. We added a bunch of whites space into it and it gave us an error actually. So uh the documentation was wrong over here. So it says that it should uh not have more than 131,000 characters. So if we just go below that number or into that number uh we're going to get success but it's going to show up like this. So in request parameters uh normally it will show what was requested. So it will

show the full policy that was being requested but in this case since it was uh having oversized it will just show request parameters too large and omitted true. So it will not give us the information of what was being requested even though the policy uh wasn't that long as we can see over here. Okay. So this uh cloud trail uh logging evasion happens from 102,000 characters to 131,000 characters. And uh we disclosed this to AWS a few months back and they're applying the fix on Q5 uh Q4 this year. So uh >> so there's there's still time to use this trick. >> Yeah, you can go for it. >> Okay. So besides the uh uh normal

offiscation, there's also logical infuscation. So we know we have principle, action, resource. But what about uh not principle, not action and not resource. So this is really interesting. So if we say for example uh effect, allow and action wild card, we're actually allowing everything. But what if we do affect allow and not action and we just do a random uh action. So we're excluding that but taking everything else. So basically we're allowing everything else. So where should we as defenders look at this? So to the IM policies so the service control principle managed uh policies and inline policies. So we can do that via the API but that will show us just the the last request. So uh it will show

us what was being requested at the time. So in a better way that's looking at the runtime events but uh that will show us just the last five. So it will show if in case someone did a malicious uh policy first and then it gave uh five more benign ones. We would actually miss that. So it's important to look at the runtime events. But where else does these policies actually show up? These show up we we just covered the IM part of these. So there's a lot of places where these uh uh IM policies show up. Uh some of them are STS assume RO or get federation token which is an important one. So uh that's where we can look at

specified events and uh in that case shout out to a dean for her tool cloudtail. You can use uh her tool to actually just select a few events and then you can uh just check the logs of those events and try it out. So uh you won't have you won't need a CM for that. So yeah uh now we go over and test this out uh with get federation token and we can see we're doing the same thing in three different ways. So at the first one we're uh doing uh action allow all at the second one we're doing the same thing but uh we're actually uni code encoding the the whole JSON and at the

third one we're just doing uh a random action. We're just not allowing that random action. So, we're allowing everything else. And at the request parameters, as I said earlier, if it's not requested, omitted true requested too large omitted true, it going to show what was being requested. So, if you're hitting the cloud trail logs, it will actually show up like this. Imagine being a blue teamer checking the logs to see what was being handing and what was being requested and you see something like this. So uh that's where tool selection actually matters. So we tested this out with the CLI and the PowerShell SDK. We just created the same policy as we can see l more offiscation. And uh if

we hit those two we can see at the um uh the the CLI version it will deoffiscate the carriage return. So it will normalize it and formats it. But at the second one we can see that it actually hold uh it will remain uh the carriage return. Uh also AWS CLI normalized everything. So if you're checking at the logs as defender to see if there was a malicious policy being requested through the CLI, you will actually miss what was being requested and would miss that what attacker was trying to do and why he was trying to offiscate things. So you show up a clear policy of being requested. But in SDK in the other hand uh it will

uh preserve all the offiscation. So uh if we also change that with the uh uh if we replace the whites space we can also see that the courage return was also present. So as Albon showed tool selection matters both offensively and defensively. And so for each of these building blocks like I would encourage all of you whatever tool you're using like even offensively if something doesn't work try it with another tool because the tools sometimes are being helpful like AWS CLI is being helpful in removing that offiscation but if we're using this to find the offiscation we don't want it removed uh and so there were several times where we kind of uh in our notes just said hey this didn't

work come back to those notes the things that didn't work 6 months ago you know more things 6 months later go try it again with another SD SDK or in the UI and you'll find different results which makes it harder to research but more interesting uh to know that there are different tools that do behave differently. So with all this being said with all the JSON level tricks of of encoding uh and whites space and all these things and then all the logging evasions uh and then all the multitude of runtime events where policies are present and some of those preserve this differently than others. Where do defenders go from here? So, as defenders, we do this research to make

sure that we're building a solution that we're going to open source that is open source to help defenders. Uh, and this is where it actually, this is kind of a similar problem to some of the LDAP stuff yesterday. We need our own parser that doesn't fully parse and deserialize the JSON. We want to do that first step without cleaning up any of the insignificant white space because we actually want to see and measure and know that the insignificant things are present. Um so we wrote a custom JSON parser um and uh and again very similar to any parser. This involves taking JSON strings as one big uh one big string tokenizing into its individual pieces

and then grouping it together as a parse tree or a syntax tree so that we can understand the relationships between all these tokens and then as we actually tokenize uh a policy like this uh we can see that we have kind of inline decoding but we still preserve the raw content. So in this case the decoded value is allow action but we can see the actual plain text version is still held there as well as the exact position you know the line the start the end and indexes and again this is all important because we're not just interested in what we're visually seeing. We want this to be something that we can measure so that

when there are millions of these events the measurement is something that we can detect and then present that much smaller set of data to human eyes to validate what we're seeing. Um and uh we also uh have this was actually kind of interesting because let me go back real quick. One of the things that can't just be decoded is wild cards because wild cards is actually truly the absence of data. Now if this policy started fully define uh defining I am colon pass ro then this is a loss of information. The attacker intentionally dropped characters out and replaced it with a wild card knowing that logically it would resolve to that one value. So in

this case we actually can't just rely on decoding. We have to have additional enrichment. So whenever we see wild cards in the parser it will automatically check uh the updated database of all the IM all the actions that AWS supports which is now like 18,000. Um they're adding a couple hundred every few months. Um, and it will basically say, hey, this action right here with this um, this uh, hex encoding, so this unic code syntax, these two single character wild cards, it resolves to all of these actions right here. And this is also a really cool detection opportunity. What if you were able to take a policy action by action and say this one action resolves

to 16 specific um, actions? That's a pretty unique capability that we have that's in the tool because of the way we're doing the parsing and the enrichment here. Um, and then lastly, we wanted to make all this as easy to use as possible. So, you can just uh pipe this into the find evil function, which has all of our detections that Avon and I wrote to detect all these really interesting scenarios. Um, and to kind of assign a score, a description, as well as well as a summary, and to really go ahead and highlight uh the specific reasons this rule matched as well as what the characters look like in their content as well as their decoded values.

So, I try to make this as easy and as fun to use as possible. Um, so instead of talking about the solution some more, let's show you some demos and then we'll wrap up with a few key takeaways. Um, whenever you're doing this kind of research, there's a certain point at which you get so tired and frustrated that you almost lose motivation. That's usually when you have to say, what are we naming this tool and what's the asky art? And that's usually the motivation we need to finish it. So, uh, we went with a sky theme. Uh, and sky scalpel. idea being it's like it's like a scalpel razor that we can really cut and and

slice these uh policies apart and then reassemble them together in really fun ways. Um so let's take a quick look at one of those offiscated examples that Avon showed. Um is it lump lump? I'm probably not saying that right. My apologies. But let's just get the content of that policy. It looks like this. There's one statement. There's a bunch of weird new lines. Now if we pipe that into our out JSON object, we'll actually see, hey, there was a whole hidden statement here. So there must be some of those weird backspaces that are involved. Um, so now if we go uh and uh what are we going to do? Pipe into jq. No, convert to JSON. We'll use

PowerShell's version of that. Um uh uh no, we won't. We're going to use our version of that. We're going to convert to a JSON object and parse it. And we can see uh this is the the content as well as for every token, the start, the end, the line, etc. So let's slice that up a little bit so we can see it top to bottom. and we'll see we have some offiscation, some unic code, some wild cards, etc. Now, we're going to go back and say instead of parsing it as a JSON token, let's do a JSON token enriched. That's going to give us the decoded value for each one of these as well as

some additional context objects um that we'll see in just a moment. So, this allows us to see the true values that's going to be interpreted as well as the original values. And even just comparing the difference between these two is a great way to see that there is some offiscation uh in play. And now if we pipe it into find evil, we'll see it's doing all that parsing and then running it against all the rules. And so we can kind of slice that to say what's the what's the rule ID, what's the score, what's the reason, the description. Uh and you can very easily see the before and after as well as the cumulative score um for um for all the individual

rules that fired for that specific policy. So again, if you have a large cloud environment, you literally might be seeing thousands of these in runtime logs. scoop them out of the runtime logs, pipe it into this tool, and it will go through and say, "Hey, of all the policies, these are the only ones that had hits, here are the hits, here are the reasons why this is interesting. You should probably take a look at this, and you can continue your analysis um in here." Um, and so this is kind of more of the defensive side of the analysis. So, for a lot of people, this might be the only thing that you care about, and

if so, we hope it's helpful. But if you're of the more red persuasion, you might like what Avon's going to show. Okay, so in this other case, we're just going to get a policy that is also written into our tool. And uh this is just a random policy that we're going to play around. And let's invoke that into our tool, which is invoke skysc.

So uh over here we have a full uh menu of things that we can use. If we go over to the tutorial, it will show us what we can do, what we can load, how it works. So uh if we do show it will show up what was the policy that we uh piped into it and which one are we using. So this we're just going to use the offiscate module first. So we're going to add a bunch of uni-ode encoding. We're just pressing a few numbers. So uh we show how much percentage we want to add to uniode encoding. We do that to whitespace. So we're adding a bunch of wide space as well. We add also to the

AWS policy which we can use as multiple wild cards as well. And if we go all the way back, we can just uh uh use single character wild cards and multiple character wild cards. And uh if we just do show, it will show us what was the policy and what detection score and detection count it has. So if we do find evil, it will give us a full summary of everything that happened. It will show us the score. It will show us the unique events uh the unique signals that were triggered. It will show each uh uh s uh each line what it had and what was the content and the content decoded uh of that uh JSON. So

if we go back to the menu and uh we use the deoffiscate module which deoffiscates everything and we just put a bunch of wild cards which will uh randomly run into the menus and deoffiscate everything. Uh we can see that this is the policy that we had over. So it will remove the white space. It will remove the uh uni-ode encoding and we can see that there was a bunch of uh uni code encode left. So we can manually go over and we can see over here that detection count was zero. So the policy was completely returned into uh normal. Now if we go over to uh the reset and uh show what we did so far it

will show us a full history of how it started and uh we can also if we don't want all the uh SI art or we just like a recipe we can just uh use command line syntax. So it's important to just uh use this uh as defender if you want to uh see the uh what the attacker was doing. You can use this as a blue team but also you can use the uh offiscate module as a red team to uh offiscate your uh policies as well to test it out in your environment. So what are the three main takeaways from this? So we know that JSON offiscation is not new but is largely unexplored. So not uh many people know

about it. Uh it's it's u in in context of uh cloud security not many people talk about it. Second is uh it's important to identify and monitor suspectable services, APIs and data sources and using uh well tested and well understood tooling. And third is just using Skype scalp. So if you're a blue teamer uh you can use it to deoffiscate uh policies that you see in your environment. If you see it on the wild and uh in your environment, you can use skysc uh said actually. And if you're a red teamer, you can test it by uh offiscating the policies and sending it over to and try and u see if your detection actually catches it or if uh

you can uh if you can uh bypass the your detection with it. So with that being said, thank you so much for your time.

Okay. So, this was Sky Scalpel. If you have any questions, uh we're free to uh reach out or we can also uh answer around. We'll be around or you can uh ping us on LinkedIn or Twitter or Axe. Any brave souls with a question? Awesome. Well, hey, thank you again for your time. Uh, it was really fun to be here and present. We'll be around. Thank you. Follow me there.