BSides Prishtina 2025 - Day 2 Live

and HTML. If you think about Docker, um that's a wellestablished technology. It's quite secure. Obviously, you can misconfigure it, but by default, it's quite secure. There is Chrome, which is one of the most secure browser out there, browsers out there. And there's HTML, which is a wellestablished standard. It's with us for a long time and is going to stay with us for a long time. And there's PDF as well, which is like it's okay, but let's say it's it's secure, right? So if you add these three and you get PDF out of it and everything is secure then the solution should be secure as well right that's what you would think but most developers don't

think about these things because they are not security specialists so um they make mistakes so my approach is probably the the first one but that's not how the word works anymore which is fine but my point is that uh with the faster pace and with this agile approach and moving fast and breaking things, we definitely break security as well and that's not helping our uh our environments. So I seen this in in real life multiple times I had these issues uh in quite a few engagements so far. So I was thinking maybe I can do a presentation on it and a good presentation. Well uh I like to have a presentation with with demos usually. So I put together a demo and

here what's going to happen is basically I created an environment in AWS Amazon web services u where there is a website where where you can submit HTML content and you get a PDF pack it's going to run on docker ECS fargate ECR services if you if you want to know it in in uh in depth and there is a little bit more in the background that I'm going to talk about. So um I was looking into these docker solutions where you have this uh dockerized container that you can use to generate PDF from HTML. One of the first uh Google um results that I found was this export HTML GitHub repository. You can find it really easily if you Google

it. and it was perfect for for my for my reasoning for this presentation. It's a Docker container. It does what I wanted to do. It basically creates an API that you can post HTML into and it returns a PDF to you. So, what could go what could go what could go wrong with it, right? Well, we will see that. But before I go into the details, I want to uh note something here. So if you open this repository, it it hasn't changed. There is a oneliner security notes which I find really cute. This is totally right. Uh I I fully agree with it. It says this is intended to run as a micros service. Do not directly expose it to

the public internet. And that's a really good note, right? You shouldn't expose it to the public internet. But the issue with this is just a oneliner. So there are quite a few other things that you could add. For example, I would disable JavaScript. I would put it put this Docker container into a fully isolated firewall environment. So it wouldn't be able to access anything else on the network. And also you might want to validate and sanitize all inputs that are going into the container, right? Because I told you if you have improper input validation, input sanitization, and output sanitization, then you are going to have issues. So uh I like to be fair. So I went on

GitHub and I opened a new issue about security implications and I detailed that maybe that oneliner security note which is quite cute should be expanded a little bit. Here are the things that I would put in there. Maybe you can do a little bit of research on that. And I understand that nobody has the responsibility in this case. But if you expose some if you publish something on the internet uh because you want to help people, you might want to do the extra mile and add a few extra security features because people will get those containers. They just going to clone the repository and they will use it as is. They won't care about security. And the

more people use the same se same repository that is vulnerable the more issues we are going to have in different products. So yeah um I didn't expect much from from this uh issue that I opened actually it uh it it it worked out really well. I got two likes. So that's that's basically the implication um well that that's the impact that I managed to got uh from it. And also I need to note that one of the likes is is uh was by myself. So that's that. Uh so what I did I created an environment uh which I thought is going to be really trivial but if you use cloud products then you might realize

that uh this is not that straightforward if you want to do it um quick. Actually I I don't think you can do this quick. So I created IM roles, policies, VPCs, subnets, routting tables, internet gateways. I deployed two different containers with ECS with Fargate and I configured quite a few security groups as well uh to have this environment for for for this presentation. Uh there are two containers I already told you one is the export HTML with that you can render PDF from HTML. Uh not that surprising. And the other one I built a custom one just to make it more enjoyable and just to to uh make it more real life. Obviously this this custom build is is

was um it was purposefully built vulnerable so it doesn't really count but you can find the same issues in in in the wild in real life. So I I wasn't really cheating there. So the customuilt one has two different issues. One is LFR local file local file read. So you can read any file uh with that vulnerability from the local file system. And the other one is SSRF which is server side request forgery. So you can send um HTTP requests to any services on the network or maybe to the internet as well. So let's see the demo.

Sorry, too many windows. So, this is the website. I don't think you can access it. Uh, this is the docker container. And, um, this is usually what you see, but if you know a little bit more about this, uh, I thought I changed it. Oh, it didn't change the one. Oh.

Okay, maybe let's see the video for this

one. So here you have the the Docker container that I was talking about. It's working. is accessible from the internet and in Burp you can send a post request to it. So that's what I'm going to do. This is the endpoint and you can see the content there which is HTML body hello. It it's uh it basically creates a website which says hello there. So we send it. It says 200. Okay. So it was generated and you can see it's a PDF file. That's the content. It even says that it was built it was created on Linux and it's a headless Chrome. So basically a Chrome browser without a GUI. And if you save the content that

was returned into a PDF file, you can open it in a browser. There you go. And that's the rendered PDF, right? So from HTML, you could create a um PDF file which basically the same content that you would expect in the browser. So that's what I wanted to show you in Burp, but it didn't work out really well because of the the font size. And then there are different payloads that you can try against. So I have a set of payloads here. Can you read it in the back? Perfect. Thank you. Yeah. So this payload is basically another HTML. All the payloads are going to be HTML and JavaScript. This one creates an iframe that points to my website

montrainfosite.com and going to load an HTML file. So I wrote a script. It doesn't this is the script. It's just going to help me to execute uh these payloads is going to be sent to the server uh in in a JSON format. So here in the terminal, I'm just going to send to that IP payload one. Okay, that that happened. And in the five view, you can see there's a PDF file. So when I open the PDF file, you can see this frame here because it's an iframe. And inside the I frame I have my logo and a bit of my website. So what does that prove us? Basically it proves that the um that the browser the headless Chrome

browser on the server side has internet access. It could I could connect to my own server from that docker container. So basically I can render any website from that docker container. uh from the web from the internet right so the next thing that I want to check whether it it it has J JavaScript enabled so what I'm going to do I'm going to use that payload or a similar payload oops not that one payload two so you you might see this uh it's a script it's a JavaScript where we write some content into the website. It's basically it's going to be a number and if you execute it and you see the number you will you can be sure

that uh JavaScript is running on your com on on in the browser so it's not disabled. Let's say payload 2 and that's the number right that's basically what we expected. So now we know that it has external internet connection and it it runs JavaScript as well. So let's see the

um back to the slide. So we know that basically we can do cross-ite scripting on the server side. We can render any kind of HTML and JavaScript whatever we want is going to work. So what can we do from h from from a browser? What what can we do with JavaScript? What can we do with cross-ite scripting? Right? So there are quite a few things. For example, you can reference SMB shares and you can do SMB relaying or um you can capture the hashes. Uh other than that you can do SSRF port scanning you can access cloud related metadata read local files probably maybe sometimes and uh do denial of service. So the first thing is this one only

works on Windows. So we saw that the the the Docker container is running on Linux. Uh it was in the PDF header. So this is not going to work for us. But if the Docker container runs on Windows for some reason or we have a similar situation on Windows, you can do SMB relaying or you can steal the hashes and you might be able to log into the server. So that way you can do uh remote command exe remote command execution on the server right away. Obviously, it's not that trivial, but you can do that. Uh, in our case, it's not going to to work uh because it's running on Windows. There is another one, local file read,

which might be really useful if you are using Linux. Uh, you might be able to to read file like etc password or etc shadow depends on the privileges that the browsers has. Well, this only works if the same origin policy um allows it. So what's same same origin policy? Basically, if you um when when you try to open a file or a website, it only allows you if the the origin is the same as the the target. So here you can only read files if the the payload comes from the file. So if it's if whatever I sent to the server to the docker container is written into the file into a file and that file is being opened by

the headrest chrome browser then you can do local fire rate local fire read. I need to note that u about blank doesn't count as a file. So um we will see later whether we have local fire read or not. I'm going to do the demo for that. There is denial of service that you can do but I prefer not to do that because it it makes no uh point for me. I don't like to do harm. But if you are evil or you are a blackhead hacker or runover operator, you might want to do this and you can create a huge financial impact uh on the on the owner of the uh AWS resources. There are quite a few ways to

do that. Okay. Okay. So the next one is cloud metadata. Hands up if you heard about these. Okay, some of you. So basically if you are using clouds uh GCP, uh AWS or or um Asia then you have these metadata host. It seems to be universal between these three across these three cloud providers. the metadata can be useful uh and it sometimes it stores really really important and useful information like username, passwords, different credentials, private keys and so on. So if we are talking about AWS, you have the metadata under that um IP, right? There are two different ways to uh to access it. The the first one is EMDS version one. This is the old one.

they try to um deprecate it because they realize it's not a good idea to have it like that. Basically, it's a simple respend request response method. So, you send a request to that website and it returns the the value. So, it's really simple. There is the EMDS version two which is a newer version. This is pushed on uh everybody now which is the more secure version. Here you need to send a put request first. You get back a session ID. Um and then you need to send a section ID as an extra header with the the default followup get request. So the thing uh with this that you can't do this from HTML itself. You can kind of

do that from JavaScript but because of course uh it's not going to render and it's only re relevant on EC2 um and we are using ECR which is for Docker containers. So let's check the next payload that I have. payload three. So, this is going to give us the window location.

Oops. So, the window location is about blank. This is important because of the same origin policy I told you that if it's a file name a local file name you will you will be able we will be able to read files from the local file system. If it's about blank that's not going to work. So we know that we don't have local file read unfortunately which would be a quick win for us but that's not the case. Um then payload 4 that I haven't shown you yet is basically pointing to the cloud metadata service under that um URL. And as you can see here in an iframe there is this uh set emoji. So it

couldn't load. That's not going to work. It's not running on EC2. So um that's uh not that surprising. So next slide on GPC Azure again it's the same IP. Uh it's it's a little bit different. You need to put an extra header into the get request. Um different for Asia and GCP. But again the issue with this for us as attackers as hackers that because of course it's not going to render in the browser. So one really interesting thing about AWS and ECS Docker containers uh containers in general that there is a there is another metadata host under that different IP right so um you can you can easily open that in an iframe and I'm

going to show you we can get the metadata but if you want to get more juicy things like uh credentials then you need to have the GUID which is a unique identifier quite wrong for the container and it's not that easy to get that but if you can get it then you can get the credentials. So how do you get that? It's basically you go into that file and you read the content of the file but I told you that we don't have local file read. So how do we solve that? So let's see the next payload which is five and then six. I'm going to execute those payloads on the server and render it to a

PDF. Now this is five and this this is a JSON content uh right this is returned as a JSON. This is the metadata for um for the container and the cl and the cluster. You can say the cluster name here which might be useful if you do attacks on the cloud environment. Um what else then? Uh yeah, so IP IPv4 address that's quite important. 227 we might want to remember that. That's an internal IP address that we can attack later. And let's see the oops not this one. Apologies. Yeah. So a lot more information about about the container itself. It might be useful. It might not be useful for further attacks but it's definitely not that great that we have

that there. So um what else can we do? Port scanning is one of the things that we can do. So the the the container is running inside of the AWS environment right. So uh if we manage to discover other IPs, other ports in the same environment which is an internal environment, we might be able to to find other vulnerable services and do more harm uh to the environment or you we can just jump across and and uh get more details, credentials and so on. And that's our that's our goal. So we can do kind of we can do port scan from HTML from JavaScript from cross-ite scripting. And there is a really really cool research under this URL by done by

Nikolai Chair. I'm not sure if I said that name correctly but bigos for the guy. He was using um websockets and images image tags to to do port scanning from HTML and JavaScript. It's based on timing. So um it's not super reliable but it kind of works. And also Chrome and other browsers figured out that maybe this is not the way for to go forward. So they tried to fix these issues by introducing random noise, random delays into the process. So uh even though this is a really cool research, it not always working as intended. But there is the old school way uh that you can use. You can use iframes and you can just include

different website from the internet network into iframes. Obviously, it only works for HTTP and HTTPS. So, that's a limitation. Uh, but what you can do, you can check check for timeouts. So, let's see a demo on that. This is basically the script that I stole from the um from the website that I mentioned. It's quite complex. Um, that is the internal IP that I'm going to use just to speed up. I know there is something listening on that service on that IP on port 8080. So I'm going to execute that payload. But if you are more interested first of all you should read that URL that I put it on the slide. But otherwise this is the script

that I just formatted in a different way because otherwise it wouldn't run. Okay. So let's execute that

seven. And basically it tells you that the port is open. Right? So um I I'm not going to bore you with the port scanning bit because it takes a little bit of time. But the next thing that you can do is to read the content of that web page. So I told you that you can use iframes to do that if it's HTTP or HTTPS. So this is an iframe pointing to the website. It's like a CTF right now. So let's just do eight and I do nine as well just to speed this up. And eight it basically shows you the content of that website that we found on the internet network. And it says that's why I said it's like

a CTF. It I give you the answer for the next step. Basically there is an endpoint called LFR local file read where you can specify a file name. So what I'm going to do I'm going to try to read the etc password file from the docker container. Let's see whether that works or not. I already executed the payload. So payload 9. And you can see that returned the etc password files content which is quite good. So what would be the next step? Right, we want to read the proc self environ file because that has the GUID for the container. So payload 10 is putting the same website into an iframe but with a different file name

that proc self and environ um contains the GUID that I mentioned to you and with the GUID we can get the the session token and other stuff as well. So there you go. This is the uh the content of that file. And here it tells you that AWS container credentials rel relative URI is is under that one. So now I'm going to copy that. This is the GUID. I need to make sure that it's copied properly because it's not always working like expected.

Okay, that looks to me good to me. So, um other than reading local files, you can do SSRF with this service. And uh I mentioned to you that ECR Docker uh ECS sorry has a different metadata um host IP and that's the IP for the metadata if you're talking about ECS and under that if you know the GUID which we got from that local file then you can get the juicy bits the credentials. So I just executed that payload as well. And there you go. If you are familiar with this, basically this is what you get back uh from AWS if you're lucky. It has quite a few things. Uh let me just copy [Music]

this. We need to format it. So there is the access key ID. Then we have the secret access key. Those are the main things that we need and the token. So the token is a bit badly formatted because of the new lines. So I need to format that which takes a little bit of time.

Okay, that might be it.

Just give me a second.

It took some time. Sorry about that. Uh what happened here? Basically, I exported everything in my console so I can use the um AWS command to do anything on the cloud that I can do. Um, and here I use the STS get caller identity command. And you can see that I'm basically logged in. Uh, the next step would be to figure out what I can do with the cloud uh with the cloud at all because it might be restricted. Usually it isn't. So let's just see.

So there is this uh really cool tool that you can use to enumerate your credentials and uh your roles and polies policies in AWS. You can see that basically I have access to everything

uh including e uh s3. So I can read the buckets, I can uh list the buckets, I can create new buckets, download files and everything. There is only one bucket here which is called only for admins. We are definitely not admins by default but with these credentials we are. So yeah I can list the content of that pocket as well. There's a secret that text file. I'm really curious what's in that secret. So um let's just try to get it. And basically the content is I hope you like the presentation. AD AWS owned by owned via serverside cross-ite

scripting. Yeah. So that was the the demo. Thanks for um coming along with this. Basically the last bit I want to talk about is the mitigation bit right um how to fix these issues I already mentioned to you that to fix basically any kind of injection attacks but specifically cross-ite scripting in this time you need to implement one of the three uh input validization one of the following three things input validation input sanitization output sanitization if you have at least one of the three you are going to be fine. You don't need to worry about this kind of issues. On a high level approach, you can do more than that and you should do more than that. So, first of all, you

can do and you should do threat modeling where you sit down, you think about the issues that might uh happening with your with your solution. It doesn't have to be this exact solution, anything in general. So, you just think through if you were an attacker, how would you attack the the environment? what would you do? Um, and you need to consider different angles here. When you have all the angles that you can come up with, you need to find the uh mitigation techniques that you can implement or the fixes that you can implement. If you do that, you are going to be more protected than ever. There is the lease privilege principle and separation of duties.

These are really important. You could see that this cloud user that I use that I abused had access to everything, right? So obviously it doesn't have to to access everything. Why would you need access to S3 and EC2 services in AWS if you are Docker container? That's very little. It doesn't make too much sense for me. And the separation of duties as well. If you have two different roles, you shouldn't merge it into one user. You should use two different policies, two different users. um just to make sure that even if one gets compromised, it won't be able to abuse the the um privileges, the permissions that it it was um assigned to, right? And um

defends in depth. So segregation, firewalling, um in this case the container had access to the public internet. You could download everything. you could load uh render any websites from the web from the internet um and also not just from the internet but from the local network as well. Why does it need to have access to the metadata? Why does it need to have access to to other local services? So if you had proper segregation uh if we had proper segregation in this case then we wouldn't be able to access the the other docker container which was vulnerable for local fire read and uh server side request forgery. Um back to the HTML to PDF I kind of gave you

already answer to this what you can do with this uh to make it more secure. First of all you should reconsider using these kind of technologies in full. uh it's really hard to make them secure and probably the best way to go forward is not to use them at all. But obviously it's not the case, not always the case. You can't just drop a feature request whenever you like. So what you can do in the Chrome browser, you can disable JavaScript that going to help big time. Um you can configure uh like in general settings to make it more secure and you should run it in fully envir fully isolated segregated firewall environment as I mentioned before and um you can do

HTML with embedded stuff. So even if you need pictures you can embed it into the HTML. So you don't need to have access to to the public internet or to the local local network. You can put everything in one file in one payload. And if you can do that, do input validization and summitization. But I think I mentioned that too many times in this in this presentation already. Uh there was this other container which which had the local file read. I put that there because I wanted to make a nice demo uh show you the full attack chain from one cross-ite scripting which has usually no impact. Basically you can own the whole cloud environment and this

happened be previously. So even though this is a madeup environment just for this uh presentation, I had this issue like the exact same issue in the wild and I could own um a few companies like this. So that was the presentation. If you have any questions, uh I think we have time to do that. Nick [Applause]

Thanks Balash. That was really interesting. Uh in terms of detection for this uh for are the normal burp fuzzer payloads enough to to bring back something that will let you know that is there or would you need to provide your own more specific payload? Sorry I missed the the first the first bit of the question. So what about the detection uh for detection of this? Are the are the standard burp fuzzer payloads enough or would you need different kind of detection customized? Okay. So I I thought that different kind of detection. So if you are an attacker whether you can find it with automated tools that's a question isn't it? Yeah. Yeah. I'm I'm not totally sure whether

you have this in in Burp. Uh well, basically here you had a JSON payload and also I'm I'm not sure whether uh Burp can render and detect PDF content. So I I would say no, you wouldn't be able to access it. Uh you wouldn't be able to detect it with the Burp by default. Thank you. Any other questions? No. Well, thank you so much for coming. It was a pleasure to be [Applause]

here. We'll be having lunch until 1:00 p.m. I'll be upstairs.

Welcome back everyone from lunch. Our speaker will be Arman Bino from Code Labs. His topic will be web security exploiting race conditions and vulnerabilities. His session will dive into the o often overlooked world of race conditions vulnerabilities in web applications, revealing how attackers can exploit concurrencies flaws by bypassing security controls and abuse business logic. Thank you. Um hello again and thank you for coming today in this session. My name is Armen Bino and today we'll be tackling and on revealing concurrency flaws in modern web applications. But uh before we start a quick introduction to myself. I currently work for many years in code labs as a offensive security specialist where I do the standard penetration

testing red teaming and in my free time I try to do as as much as possible in certifications and in of course CTFs. In this session, we will cover different topics with the most important being what are race conditions, the impact they have in the real world, the concurrency problem and how they occur. Of course, the we will also explore a coupon adaption exploit which we will explain later. We will also mention some tools which could help us to find more complex race conditions. And of course in the end we will explain some other attack scenarios which includes two-phase bypasses, attack account takeovers and brute force attacks and in the end we will try to get some

suggestion in regard to race condition vulnerabilities. So we will explore some mitigation strategies. Uh before we start it's important to know what are race conditions. Race conditions are a type of vulnerability which goes in the subcategory of time of check time of use vulnerabilities which are a subcategory of business logic vulnerabilities. So race conditions are um vulnerabilities where um uh par parallel requests are handled in a not a safe way. So basically why these vulnerabilities matter? uh many companies like Apple, GitLab, Apache, Tomcat, AMD and Hacker One um has some kind of race condition vulnerability or even uh has had in the past which um u in most of the cases was a critical vulnerability. That's why um

it's not recommended to overlook the race condition vulnerabilities as many modern webss can have these kind of exploits or vulnerabilities. Basically how they occur in websites are when uh we process our requests concurrently without adequate uh safeguards. uh this can lead to multiple distinct threads interacting with the same data at the same time resulting in that collision that we sometimes call a race window. We also need for a race condition to uh create that carefully timed attack to cause intentionally that collision and exploit um it for malicious purposes. Let's say uh a normal um request uses one thread and for the other endpoint we use another which most of the times would be a safe um implementation of request

handling. But imagine one thread doing all the requests simultaneously like in the image below. If the end point is a critical endpoint, then we potentially can find a race window or even a collision for exploitation. In this example, I will be explaining a race condition where we try to limit overrun a certain feature or endpoint. In this case, we have a coupon reduction exploit where we try to limit uh the the end point with many components so we can exploit that feature. Before we start, let's say we have an e-commerce site uh which should uh um handle the request in this way. So uh it should handle uh the request by checking that the code has uh hasn't

been already used. Uh we apply the discount code and then the database updates uh that discount code to our total order. This should uh be a normal request. But what what happens if uh at the race window where the coupon gets validated, we sent multiple requests. Uh so to to be able to detect and exploit race condition vulnerabilities, it's first important to identify a single used or rate limited endpoint. In this case, we has we have a 20% uh 20% coupon code which we can only use one time. If we try to use it multiple times, it will say code already used. Uh so uh the goal is to overrun that limit and to use

multiple um coupon codes. So we can get a product uh for very cheap or even free. To do that we need to probe probe for clues. Uh in this case uh how we probe for clues are we use a technique called benchmark. Uh the technique identifies how the endpoint would behave in normal conditions. To do that it is recommended to add a group in the repeater tab. Uh so basically for this attack we are using B suite and so we have an easier testing form we group uh 20 requests which are normal postcart QR request and we uh group them in a tab. The reason is to see how to behave and to test if potentially the

endpoint is vulnerable. But before we move on, um Burp speed offers um three sending methods in groups which are uh for group one to send it in a sequence. That means that all of the requests will be sent one by one and so on to test if the connection is handling the request in in the same manner. So let's say we send out 20 requests and all of the requests um have the same response time and the same number of bytes in the response time. So that's basically for testing the behavior of the coupon code. We also can send for testing purposes in separate connections. So let's say it will be sent request one then the

request will be closed then uh request two will be sent and so on to test what would happen if different users would use the that uh feature and the uh third feature which is the most important is the send group in parallel. This feature allows us to send all the requests in a single time window which also enables race condition vulnerabilities. So to do that it's pretty easy. We just uh send a group in a single single connection. So let's say in the group we have 20 coupon codes all of the are the same. it should only validate only the first one because this kind of grouped requests are not meant to find race condition vulnerabilities but

only to test them. So uh when we see the responses of each group, we can see that uh this endpoint is potentially vulnerable as many of the responses have the same number of bytes and the same almost the same um number of response times in milliseconds which both are 123 and 121. uh so we can determine uh that uh the single endpoint is handling uh the requests uh with a similar response time which has which is a big indicator of erase condition vulnerabilities. Now to test to actually prove that this endpoint is vulnerable we can uh try to send the group in parallel. So meaning we can try to send 30 of the same coupons at the same time in the same

window. And uh we can see that uh the application actually processes the apply coupon code in the API which is postcard coupon and uh it validated every one of them leading the discount to be applied multiple times even though the uh coupon is the same for every request and it should only validate the first one. It validated all of them because we did a limit overrun. um exploit where we send the group in parallel and uh of course as we can see the product from being $1,400 went to only $20. Um there are many kind of variation of this vulnerability not only in gift cards. So we can also rate a product multiple times. We can also withdraw or

transfer excessive amounts of money. We also can use or reuse a capture solution and we of course can bypass anti brute force rate limiting solutions. Um there are other tools that help us send requests in parallel not just burp speed repeater tab in a group. We also can use turbo intruder which allows us to do more complex uh race condition attacks. The reason is uh because an enemy of race conditions or the network architecture and the jitter which can add an unintended delay and to make our attack more difficult. That's why it's important that we use turbo intruder as an extensions. So we can add manually our scripts and we can also add manually delays and stuff like that. So we can

exploit multiple endpoint race conditions. Race conditions also can be used not only for um coupon reduction but also for two bypasses. Let's uh consider a a white box penetration testing where we have the password but uh it's the account is logged by two. Uh a way we can bypass that is to send um in parallel all the OTP codes of the 9digit uh two factor authentication onetime password and um in most cases uh if we would try to brute force attack this we have only 10 seconds to find uh the combination which is unrealistic. But if we send with a single packet uh multiple requests uh we can uh find the time window and within uh 12 seconds or 10

seconds we can find the onetime password code of the two and therefore bypassing the this security measure. Other attack scenarios include but are not limited to brute force login. Let's say we have a rate limiter or a web application firewall and um we cannot do too many uh requests. What we can do is group our all our brute force attacks in a group and we can send it in a parallel. What will happen is um bird seed would would send that uh all the requests as a single packet and the web application firewall would count it only as one request therefore bypassing uh uh rate limiting. Other more complex attack scenarios uh happened uh in a company known as

GitLab which was a multiple endpoint race conditions which didn't happen in the first endpoint but in the second. So GitLab had a password reset function which um still modern web apps use this similar functionality. Let's say we forgot our password and we are a legitimate u user of the platform um we could um under certain circumstances uh um reset our password which then gitlab would give us a one one time password a static password uh for generating the reset password link what would happen is uh the uh session or the OTP P of the reset password link would be static and easy guessable which um which if we would attempt to reset another user's password we

would have uh we would need the same token which is used for our account and we would do a race condition where we would send multiple uh requests with the same token but to different email addresses and send them in a parallel. What then what happen is the first request hits the password update logic which uh checks the provided static token and um the second actually hits the logic and the vulnerability where that token can be used for every email and the race condition. uh then would send for every email we provided the reset password link in our email address resulting in spoofed local host or account takeover. So basically um the first endpoint which was to generate the

static password was used for uh every email we provided in our group and the second thread which was the actual password link that was sent to the email was uh used as a race condition where we sent uh 30 emails or more in a parallel request and then uh we would have everybody's uh email because we found found that in a race condition actually um there is cases where it's difficult to find the race conditions because some of them can be find uh via source code but some need actually to be tested as it can get complex. X and because of network architecture and jitter and lag it can be difficult to find but most of

the times mitigating or preventing these vulnerabilities can be done using mixing data from uh avoid avoiding mixing data from this different storage places and storing sensitive endpoints make static changes atomic by using the data store concurrency features and also and other in-depth measure would be taken advantage of data store integrity and consistency features like column uniqueness uniqueness and constraints and uh of course it is recommended to not use data storage layer to secure another one also it's important to ensure that session handling frameworks keeps sessions internally consistent and in some architectures it should be avoided to use server side states completely to avoid of course race condition vulnerabilities. Some processes uh and operation require strict ordinary

and resource limit. So that can be also used as a a defense mechanism or a bypass technique. That would be it from my side in regards to race condition vulnerabilities. If anybody has uh questions, feel free to ask them. Hopefully, I will know.

[Music] [Applause] [Music]

Hey Armen, great presentation. I have one thing I quite didn't understand in the parts where you would send multiple packets like so multi multiple payloads simultaneously. Okay. uh so there like yes would that be caught by simple let's say like if the thing is on AWS or the thing is in some cloud provider service where the load balancing is not housebuilt so there would like denial of service attack prevention prevent you from doing that that's what I'm trying in most cases no it race conditions can al be also be used to do denial of service Some um uh VAF or web application providers um provide a way to detect this and block this but they are never enabled by

default. So uh because we are sending a limited amount of requests for uh it can be detected for some cases where our brute force attack or denial of service attacks but not in this case for a limit overrun because we only are using 20 packets in the we are sending them in a very short period of time. So uh most of the time it's not uh by default detected. uh uh it uh sometimes it it is needed also to add uh restriction in the source code while um adding threading to the endpoint. So uh it's not recommended to use uh one thread for many endpoints but to separate them because that automatically would add a delay. Hopefully that

answered your question. Thank you. That answered it perfectly.

Anybody else? No, thank you very much. Thank you. [Applause] [Music] [Applause]

Introducing our next two speaker Aban and Daniel Bahaman. They will be uh they are both coming from Primo Primitial Security. Their topic will be covering cutting through uh cloud policy obscurity with Sky Scalpel. This talk will expose the hidden dangers of cloud policy obstrictions and showcase the Sky Scalpel, a powerful open-source tool that slices through Uni code tricks. Thank you very much. Follow me. Mita, Mirita, 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, unuhe Daniel Bohannan. Uh, I'm a principal threat researcher at Promeo Security where we do 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 DVO for short. That's what that's what most people call me by. Hello everyone. Uh my name is Abel

Marina. I'm a threat researcher over at Primeo for over probably two years now. Uh uh you can see my blogs over at Abel Marina. uh at Premiso 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 Debo which was uh my 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 Permiso, 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 often times 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 offiscation 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 will 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 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 LLM 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 kosov uh the letter uh which is e with two dots it does escape handling for escape noni 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 wide 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 code 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-ode 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 role and EC2 run instances which is used for privilege escalation vulnerability from rhinoc 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 overwrited. 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 catting the JSON. We can see that there's more uh 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 answers, 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 Avian just 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 and 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 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 infrastructure is code and you can

define all these things as JSON blocks and this one even has JSON within JSON has an embedded uh IM policy. So these are just three quick examples of yes JSON is used uh often in 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 they're open source like uh Pu from Rhinoc or CloudFox 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 of 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 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 Evan, 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 Avon 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 Skyscal 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. Uh 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 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 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 share 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 I was like avian Miku 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 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 and 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 use 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 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 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 code 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 uni code encode 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 infusation. 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 Djani 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 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 action allow all at the second one we're doing the same thing but uh we're actually uni-ode 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 more offiscation. And if we hit those two we can see add 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 we would 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 Abon 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 six months later. Go try it again with another 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 of 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 uh 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 role 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 Abon 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, we 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 in sky scalpel. The 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 it 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 uni-ode encoding. We do that to whitespace. So we're adding a bunch of whites 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 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 whites space. It will remove the uh uni-ode encoding and we can see that there was a bunch of uh uni-ode and code 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 SEI 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 sky scalpel 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 Skyscal to check what it was being uh said actually and if you're a red teamer you can test it by uh obiscating 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. [Applause] [Music] [Applause] Okay. So, this was Skyhelp. 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, thank you again for your time. Uh, it was really fun to be here and present. We'll be around. Thank you. Follow me [Applause] there. Turn it. Thank you. You guys are great.

[Music]

All right. Now, welcoming our next two speakers. They will be covering over the gray legal zone of cyber conflict. Their presentation will dive into the ethical terrain of cyber conflict uh exploring the growing uh role of civilian hackers as they face risks under international humanitarian law. Okay. Hello everyone. I am Alba. Um so uh I'm so happy to be part of Bisard Pushkina 2025 and also thank you for all staying to uh hear our presentation together with Razarta we decided a topic like the hidden battlefield navigating the legal gray zones of cyber conflicts. Uh so um when you we are going uh through this presentation uh through the parts that um sometimes uh even uh when uh we want to contribute

for a war in cyber for with cyber but we also have to uh know the legal parts but also for everyone that maybe for a near future hope so not but uh we have to need some things. So let's start with the first part as uh with a famous uh u like u Ukraine conflict with Russia uh on uh February 2022. It was a conflict between uh Ukraine and Russia. And also uh the famous um publish call was from uh minister of uh transformation uh digital transformation uh Miko that had uh that wanted to create an IT army. Everyone wanted to be part of uh this army they consider as a noble thing like um students or IT workers uh people who

know cyers and anyone uh wanted to be part of this uh um this organization or IT army but also when they wanted to be part of this army they also thought for some questions for example if uh I can help you behind the screen, but am I protected uh to do this like uh in a legal form also when you um think about that uh it was such a a big influence for this IT army and also someone just wanted to do for the experience and someone wanted to do for help. But uh when you think about that um international norms uh didn't think about this in this form they didn't consider like u help they also thought

uh like um ICRC and ICC thought it in two different way for example ICRC uh said that civilians should not engage in cy uh in cyber conflicts like u helping with cyber in conflicts between two states. Because when you u when you say that you are avoiding uh targeting civilian infrastructure but also uh Ukraine especially the minister was in that mind that uh if we do an IT army we are going uh to destroy uh Russian infrastructure services communication channels that it will be better for Ukraine and of course maybe they try to win on this uh in this cyber wall war between uh those two states. Uh but when ICC uh saw in a

different way and also thought that maybe could have protection uh for those people then wanted wanted maybe to help but they're not helping in a legal way. So uh when they thought on uh that way uh every uh person that enjoyed in this IT army that had a talk between them they had to think that being part of a cyber warfare it's not a game but it's a real thing and also uh they uh gave it some uh other advices that they had to be because uh when you think about it it was very dangerous for that person because you uh you was you wasn't a soldier but you was just a person behind an anc

screen. So uh talking through this, it was cyber attacks against civilians during wartime. uh thinking about two different concepts like uh ICIC and IC uh u IRC uh the United Nation uh think it about in a different way like they have some key factors uh that presented to uh the persons that were behind the screens that wanted to help Ukraine but they said okay you wanted to enjoy or you created it army but when you think about that uh if you do something wrong like for example you uh just block the internet access on a hospital and a lot of people die because uh from your um responsibility do you think that uh u the other country will pick you up or

will pick your state? So you have to also think about that and uh when you also think like I think about it and you will be your uh you will be just for example Albba that did that uh so it's Albba's responsibility so of course um during a lot of um discussion and um conflicts between this IT army they decided to be part and also introduced some international laws that protect those soldiers. Uh so uh they uh decided to go as an IT army Ukraine IT army when you uh when also um you were part of this you had to think or you have to take some responsibility. When you think about this um cyber

operation can uh also uh go to a genotit and when you are going to a genotit uh it will be also when you have all the person's life in your hand you will be responsibility for that but also uh if they uh specifically target a national ethnic or religious group and cause death fear or physical trauma it also kind of geneted. So that it was uh the exact thing that Russia made with Ukra Ukraine also did those things and also tried with cyber to hide some things. So um they um also said that if you want to do that try to not do genot because if you target group uh coions like co three year or physical trauma legal uh legal

repercussions so it was uh kind of that everything that you're doing you are doing under international laws and also you will be protected uh uh at this part but when you think about legal review of cyber weapons. Um for people that was on government part uh they thought that okay uh cyber weapons and also with uh uh kinetic weapons are the same like it was the first question that they made. If you just realize yes they are because uh maybe uh if we need on 1991 or uh 1943 on war uh the like other wars like traditional wars if you have just guns or you fight with them but then we are fighting with cyber. So when

you think about that they said okay if you want the answer yes they are exactly the same but if I want to activate the nuclear uh I will activate by my uh by my screen and not going on physical part. So that was uh the um discussion discussion that they had with the government part but also uh they had too uh many Ramseswear that helped not helped but also helped to do like too many bad things also for going down internet access on hospitals that had a lot of victims. also for uh internet access for um energy, electric uh energy and also for water. And it was such a hard time for Ukraine. But when you think about that

uh can you go at the when you think about that to be a civilian hacker you also just was a civilian. But they think about that why not a civilian civilian hacker to be more to be like uh someone that is like a real soldier that wants to help but also that h they have the three conditions to uh for legally uh targeting civilian hackers like it was a threshold of harm that it was bleant uh also a casual link between the hackers action and the harm and also the uh the third one it was harm threshold when as a civilian soldier you uh completed these three condition you was a new soldier of IT army of Ukraine. So about

the other part and other cases that happened uh Razarta will continue. Okay. So uh before continuing I just wanted to present myself. So hello everyone. I'm Pazar Tatace. I am currently a senior DevOps engineer Kosovo at the same time a PhD researcher at the University of Rishina. So until now told us some of the legal parts the legal reasons uh different events that are directly related to cyber warfare. But what I'm going to show you now it's uh how can we uh supposed to know who is the target and who is the cause for every cyber attack or cyber attack war between two or more countries or vice versa like we have here a decision tree

for legal targeting. So as we all know uh we saw decision tree only in machine learning as an algorithm right but in our case we were going to use this to answer some question for three of the case studies that I'm going to show you in the next slides based on some answers of these questions that I showed in this slide like for example in the next three uh case studies we're going to see if there is a conflict underway is there a hacker or a member of the armed force or is the hacker a part of or a member of an organized crime group? The cyber attack result in death or injury? Was a

cyber attack directed against the critical infrastructure where that were there any blackout violent effects etc. And also we're going to see three main steps that are going to help us in this direction to assess the conflict to evaluate the status and also to determine the impact. So there are several case studies uh that illustrate the complexity of the cyber warfare and also its legal complications. So if we go now the first case study that is Yunate Hussein I don't know if you have heard this case study but until we analyze what is the main cause of his death from the US drone strike that happened in August 2015 we're going to see who was he and

what was uh his intentions his attacks etc. So, United State was just a cyber attack hacker that was a propagandist in the social media platforms especially on the US and UK ones and how this happened. So, uh first he tried uh to simulate some attacks as a hacker that he were uh to get personal information from the US military persons that were serving for us but also for the UK. So if we go back to those questions that will help us to decide of what was the main reason that the importance of this target was raised. So what is the main intention of this drone strike from the Yaz in August 2015. So uh if we see uh in the overview

of this attack and what was the reason uh we can see that from this cyber attack that there weren't any death or injuries this case but there were also only uh the stealing of the personal data of the users or the person that were serving. Uh and also if we look at the other questions we can see that there was uh weren't any conflict underway or that hacker wasn't any member of the armed forces but we see the third question if he was a member of an organized crime group then yes so that person in the first case study was part of a crime group with different other person that had as a target these

personal data of the US military services in order to use against them. So if you continue to all the parts we can see different things and different answers for each of the questions that we saw from the slides before. So the second case study that was uh very interesting and it was something that was witnessed for for the first time in the world uh is the ISIS anonymous war. So what is this? This says anonymous war. A group of people that are anonymous uh stated or declarated the war between two Islamic states that were started. But if we see this war wasn't like a physical war, but it was uh from the cyber attacks that were going to be

used. Cyber cyber attacks was a tool. was going to be used as a war against these two countries from another part that were anonymous. So uh if we see also those questions from before. So is there a conflict underway? We can see that yes because uh this case study also uh triggered a conflict between those two states. You can we can see another the other questions uh for example uh was the hacker member of armed forces organized crime group was the cyber attack resulted in death or injury then we will have no. So uh in this case we can see that this target cannot be legally target or to have a reason maybe to kill

him or to remove him from the country or to get him in prison or something. But we can see from the case study itself that was a direct impact especially in 2017 that it also serve in many other different conflicts that were through the way that were related to cyber attacks. The third uh case study is the Ukraine power grid attack. So this case study is very interesting because this is for the first time that a cyber attack was done uh to a critical infrastructure. In this case it was a cyber attack that was done towards the power grids of Ukraine. So after this attack in December 2015, uh the power grids was attacked and

almost more than 200,000 users were blacked out and didn't have uh power or there was a power outage for one to six hours. This was attributed uh first to some Russian hackers but then uh later it was blamed on the Russian governments towards Ukraine. But it was said then that from a thread group known as sandworm has done this and then it was attributed at the first point of faults for all this attack that were happened to the power grids of Ukraine and this was the first publicly acknowledged success successful cyber attack on a power grid. So if we go to the questions here, we can see a question that was a cyber attack directed against a critical

infrastructure like a power grid. So in this case we have yes or was there any blackouts? Was there any violent effects? We saw that in that case study that we were blockout for a lot of users that were using that power from the power uh power grid. So uh in this cases we saw that we didn't have positive answers in all of the questions. So if we want for example if state want to have legally targets a person or a group of people for any situ situation or any attack that have uh happened to their state we just need to have those answers yes as many as possible in these questions that we have we had in this slide. So even there was

like a drone strike for the first case study. There weren't enough positive answers to be as a reason uh for United State to be as a target uh for this attack that has been done in the state neither for the other two case studies studies that we saw before. So what we can what can we conclude from all this presentation? Uh so we saw also before the impact that AI may have uh for detecting and for evolving this legal parts of cyber attacks uh not only for different countries but also uh for different person against uh different critical infrastructures. So we saw that also cyber weapons or some of the tools that can help to shape

the conflict between two states or more because we saw that cyber attacks was the most uh reason the biggest reason uh that helped to like to evolve the war in this case between those countries. If we see the three key factors, uh we saw the main key factors that we had through the presentation was the harm, intense and the participation. And what we also discussed the most through this case studies was the participation part and also what harm or intent did that member have towards this cyber attack in order to have its importance as a target. And also the last but not least uh was this ICC precedence proceedings. Then we're the international courts that are

setting proceedings like for example in this case what could be better for the uh states governments or the other people that are working uh towards the prevention of the cyber attacks between the states or between the people uh to use as more uh regulation from the ICC and also from IRCR uh towards to prevent this and also to use this AI and cyber weapons because we can see the cyber weapons uh has started to be used in order to prevent a lot of conflicts uh that are towards these cyber attacks that are happening happening today but also in the past. So thank you all for your attention. If you have any questions we will be glad to answer. Thank you.

Okay. So, if there isn't any question, thank you very much for your participation our presentation today and I hope that we'll have a great time in the other presentations. Thank you. Thank you very much. We'll be taking our coffee break until 3:15.

Hello, welcome back everyone. Um our presenter now is And his talk will be describing about the inner workings of compromised business emails through real real world cases revealing how attackers can exploit inbox rules, social engineering and credentials and very uh discreetly bypass [Music] defenses. I guess it's okay. Hello everyone. Thanks for coming to my not so boring talk, Daniel. Um, we're going to uncover today some TTPs and some real world attacks related to business email compromise. And uh, I know that business email compromise can be sometimes boring. Some people call it call it boring. I'm not don't want to mention names, but I'm going to try my best to be not so boring. I'm going to try my

best to uh uncover a part where uh not all of us have heard of maybe some of you had but personally I didn't. So um agenda going to go quickly about introduction the best part which is going to introduce myself. We're going to talk about uh uh really quick overview of business email compromise. Uh we're going to talk about inbox rules uh how they are being u leveraged into the real world uh and instantly we're going to talk about some uh business email compromise scenarios which happened um what were the tactics that the attacker used and um of course we need to talk about how to prevent them and uh detect them and a quick summary

uh my name is Amiti uh I live from and come from Pristina. So from this uh city I've obtained my uh bachelor degree at University of Pristina and currently pursuing my master degree there. Um I've started my uh journey uh in security as everyone as an offensive uh security then jumped into uh permisso and where I work as a threat researcher for the past two years and I've had the pleasure of working with um some great people from Albania and Kosovo uh also from US they're not bad they're good they're doing good and yeah so um at Permiso we are a cloud security company focused on identity and we love to catch bad guys and um also uh besides catching uh bad

guys I also inherited a a strong desire to develop open source tools and also present them at various conferences uh one of them being uh cloud grabbler which is a defense cloud defensive framework uh tool and also cloud console cryptographer uh a tool which I co-authored and presented at Blackhead Asia with my beloved ex manager Daniel Bahannan which he happens to be here. Thanks. Okay. Um agenda first we're going to talk about business email compromise. Just a quick highle overview. Uh as we know there has to be initial access and that can be gained various different methods of fishing. um uh where we can lure the victim into give us the credentials to hop into

their account and that can be achieved through different methods of social engineering and yeah or you can just find them online if there's a data leak or you can buy those uh credentials after you have the initial access to to go into the victim's email account. Um attackers typically don't jump straight into the attacking phase. They will start snooping around and read emails just know who is the uh to to get some key points. Who is the CFO, who is the CEO, who are the um security uh guys. So they just want to know more about uh your environment as you would if you if you had initial access to a server. So you first do some enumeration phase.

Next, they will try to forward those emails to their own account so they have more time or they know that if they lose access to their to the uh compromised account, they still have those emails and also they will try to elevate uh their their privileges. After the recon and preparation phase is done, we have the execution phase where now the attacker after having more knowledge and uh getting to know more about our environment, they start start to impersonate the victims uh the victim which they compromised and that can uh be different in it varies. So if they compromised uh a financial officer officer, they start to uh impersonate that person and start sending out invoices and stuff. If they

impersonate a security intern, we know all what happens next and they always love to uh have special requests. So everything is urgent for them. Uh I think that's the best way into tricking human emotion. It's better than uh and it's it happens to be more uh successful than tricking machines because till now they don't have feelings. And last but not least, they complete their mission can be data theft. Uh it varies based on their motivation. If it's just financial gain or to just to mess with someone. Okay, the BC is done. Don't worry. Now we're going to the the good stuff. So we're going to talk about inbox rules and uh their role. Now who from the

audience knows what this inbox rule is? Don't read it but just if you have used it or you know its meaning. Yeah. Nice. Lots of you. So an inbox rule is a set of conditions which are applied to all incoming emails and when these conditions are met spe uh specified actions are applied to those emails. Okay. it really really uh easy and straightforward. Now let's just um highlight some key keywords. So we have two condition and actions. So conditions are grouped into five categories in um in Outlook. So the first one is the people condition where you can basically filter down on from uh so this should be an SMTP address an email address. You

can also filter based on the emails that you're sending. So two or emails received for other. The third one I never understood what it does but okay it's there. Uh we have the my name is if you this condition just checks if your uh name is present in any of these fields. A highly used one is the keywords condition. So you can basically say okay if this keyword exists in any of these fields. So if it exists on the message body on the sender address on the recipient address or on the message header. And another one is where you can filter down on the subject where you can filter if a keyword exists on the

subject or on the subject or body. And the on the others which is quite nice one is um the first two are where the uh conditions where you can filter down on uh message size. So you can say basically if a message has uh is larger than 10 megabytes just delete it or whatever action you do. And the bottom two ones are uh conditions where you apply them based on a daytime. Next is uh actions. So there are some other actions uh group of action but I just uh want to highlight three of those so you don't get sleepy. Uh the organized one where you can essentially move emails uh to another folder. You can copy them,

delete them, pin to top. You can mark a message as read as junk. So all of these are again actions where u they go with inbox rules and you can change the route of the email. So you can forward them to another email. You can forward forward them as attachments and you can also redirect them to another email. Okay, now enough talking. Let's start and actually create an inbox rule. So this is the Outlook web application view. You can also do this on the thick client on desktop. So we're calling a rule name delete immediately. And if you click on the condition tab, let's choose the from condition. So we're specifically deleting any email from this specific

person. And uh yeah, we can see that the action is delete. So essentially, if this guy sends me an email that will straight uh go uh straight down to trash. So it will get deleted. Another useful way for to use inbox rules is deleting marketing emails. Let's say you created a an account and you accidentally click on the on the button that you want to receive new offers or uh discounts from that specific uh uh page. So essentially here we are adding a condition which says if the subject or the body of the email contains any of these keywords just delete it. Okay. So these are some useful ways uh that you can uh use inbox rules. If you look

closely on the second paragraph, it says that when inbox rules are set up correctly, they can significantly decrease the amount of time that you spend on inbox management every day, they will reduce the likelihood of you accidentally opening a malicious message and make it easier to notice new messages from important senders among other things. So, I specifically uh stopped at those uh words because we're going to keep them on our on our u I don't know what this is. I forgot. Yeah, no worries. So, we have four words. And now um let's let's think from an attacker's mindset. Now, what if we get this uh words and uh we just want to we want to be attackers. Now, uh let's

put the attackers cap. So we're going to just do a foo with them and let's let's do a revert them. Let's get the anonym of these words. So instead of having um correctly, we're going to use misused, instead of decrease, we're going to use increase. And instead of easier, we're going to use harder. Now let's take these words and put them back on their places. So now we have some a new definition about inbox inbox rules. When it says that when inbox rules are misused, they can significantly increase the amount of time you spend on inbox every day. they can increase the likelihood of you accidentally opening a malicious message and make it harder to

notice new messages from important sender. Now knowing this like having an attacker's mindset let's see what is an important email and let's try to recreate all this definition that we just uh said and uh the first one is deleting an important email. Now an important email can be different. It varies. Now this is not an important email to me and if you're a fellow University of Christina colleague this is also not important email. It comes every second hour. So yeah, you get the point. But to us as a security persons, important emails are when a new security info is added on your Microsoft account of or if your password is changed, if u you get a

security uh report about suspicious activity on your account. So these are at least to me as a security person and to all of us important emails that we they are deemed to be uh necessary. So now let's delete this one. Let's h call the rule name inbox optimization. The reason why we call the um rule name inbox optimization. There's no clear answer, but we'll find that later on slides. And we're adding a condition where it says that if the subject or the body email includes any of these keywords, so that you can you can be generous on keywords. Uh just move it to the deleted items. Now moving to the deleted items and specifically adding

the delete action essentially does the same thing but it just um looks different on locks. Now so yeah uh I forgot I added this. So essentially if we were to get an email from our from octa or from any IDP or from uh I don't know Microsoft it doesn't matter that your password is changed that essentially let inboxer will get swiped out. I don't know if I did this how I should but yeah so this will never reach our inbox rule but deleting emails or using inbox rule where uh uh where the deleted items is specifically mentioned can trigger some alarms they are they can be and they are highly monitored I hope they are but now

we instead of deleting them we are just hiding let's call a rule uh archive all emails we're going to use the same uh conditions. But now we are adding an action which will move these emails to a folder called old receipts. Let's say that we uh we are a financial officer or we did um compromise someone who deals with uh receipts and if the defender are not doing the proper if they are not looking how you should properly on the uh condition but let's say you are just doing some sort of baselining based on rule name or actions you will totally miss this one because uh all the receipts it it shouldn't be a malicious

folder at least. is not deleting it. Now another u interesting found find is the lookalike folder. So uh we all know what the inbox folder is. So technically you cannot delete it but can you create another folder which says that uh it has the name of inbox. Clearly not because that's already that already exists. But what what if we add another space at the end? Yeah, this gets this is this is different. Uh so we just created a new inbox called inbox and a space at the end. What we found is that by using the Microsoft graph API on and combined with PowerShell exchange module is that we can add another flag which is the is

hidden. Now how many of you have you actually known that you can create a hidden folder inside your inbox and or let's rephrase the question. How many many of you have uh tried to change the view of your inbox in Outlook? One. Two. Okay. Personally, I didn't I didn't know that's an option. But if you specifically add this u uh flag, uh the folder will get created, but you will not see it on your uh Outlook web application, neither on your thick client. So that's a nice way to or let's say UI way to obiscate and to hide this folder from the user. Now instantly after I found this I said like yeah I have an idea

where I can use this hidden folder where create a new inbox rule which will essentially filter down on uh admin keyboard and it will move it to this folder and the folder we just created is called inbox. It has the space at the end plus it's hidden. And the reason why and if you check the Microsoft graph API so if you query the get inbox rule you will see that it's moving to move to inbox the the folder that this um email gets forwarded is to inbox which makes no sense at all because if you get a new email it will it will go to inbox but still you can you can trick you can

trick defenders into doing that. So yeah, on the left on the your left side you can see the u Outlook web application and the view. So there's no inbox folder. There is but uh there's not the one we just created. And on the right side we have the runtime logs where if you are not really careful this would look like a an inbox folder but essentially it contains the space at the end. So it's a it's a completely uh different folder. Uh another useful way is forwarding forwarding important emails. So yeah, you can use uh I didn't mention you can use more than one uh condition. You can use two conditions. So let's say we want just to forward everything that

uh has to do with confidential or uh invoice whatever to a to our attacker's uh email address. Okay. So we know what inbox rules are. Let's see how they are being used in the wild. The first scenario is um we got a suspicious login from a from a VPN and that immediately triggered a risky sign on u alert. Also we got some access anomaly based on uh IP address the Joe location and user agent and our beloved threat hunting team did jump straight in and started to investigate this case. So the activity was as follow. We got the mailbox login. So an intruder we think that uh that intruder successfully logs in into the account using probably

compromised credentials. And right after that that uh the the attacker uh retrieves 170 emails. So it the mail items accessed event was called 170 times. So that that does include does conclude the point of reconnaissance and preparation. So the attackers first are getting to know more about the environment. They just compromised right away that they did um they did move an email. So they moved email from the junk folder to the inbox. So we we all know what uh what gets stored on on on a junk folder. And last but not least, they did uh create a new inbox rule. Now let's stop more about this inbox rule and just uh uh put this uh inbox rule on a

suspicion scale. So first the intruder creates a new inbox rule to automatically delete any email which is received after the date of 17th February and that was the date of let's say the imaginary date of uh compromise. So any emails that are being uh sent to this uh compromised account will go straight down to the uh trash folder. Um first we got the delete emails which let's put it to uh to the score two for this one. So uh it doesn't have to be uh suspicious. We have the stop processing rules which is another flag which essentially says that uh any emails any new inbox rules which uh are um let's say have to do

something with the uh date they will not be prioritized. So the the inbox rule we just created uh is has the uh priority regarding the uh condition it just we just created. Next we use the received after date. So this is another condition but what stood out the most it was the rule name. So if you remember I told you that you need to create some uh if you are an attacker uh create a normal rule name if you don't want to be um instantly to trigger alarms on on the defender side because this this is just I don't know it just like they they didn't have a decent of just creating a normal rule name and maybe maybe they

wouldn't have stood up uh as they did but yeah a key point or a major red flag is a uh not gibberish but I don't know a rule name which doesn't make sense. It's just like typing on the keyboard. The next scenario is a funny one. So again we have the initial access they triggered alarms uh and uh we jump straight down to it. So first uh the user instantly created two SharePoint folders. So it did create a share uh sharepoint folder under the app uh and created a folder called apps and another folder under the shared documents uh folder called attachments. They didn't upload a file there. It just created them instantly. They did create a new

inbox rule and these attackers were ruthless. So they didn't really care to filter down. They just said like you know what everything that comes any email that comes from now on just just delete that. it doesn't have it's not necessary. So on a suspicion scale this was quite interesting. It did because um it did not use the a condition but still the rule name was quite suspicious because they just used four uh characters and those characters were like uh dot semicolon uh I don't know not something which makes sense. After that uh the user did create an email and uh as a draft message with a subject important update which is kind of suspicious because as I said they are

always on a hurry. They always tend to exploit human nature and human emotions into uh clicking on or downloading the the uh email. And next uh we have the user did send that email he just created before receiving the uh hygiene tenant uh uh API limit exceeded. So we see that the the compromised user or the attacker did send this email to 118 uh users uh before hitting the uh yeah the API limit. Special shout out to the to our threat hunting guys who are our first responder to such events like this and uh they do a really really great job. They do a really great job at at at Permiso and yeah this was a AI generated

uh AI generated photo so it didn't look good so I thought yeah just use the normal one. Next uh detection defense strategies. Um first before starting talking about how you should defend yourself, how you should detect this stuff, you need to have your logs enabled in order to see these things. And um it's a really it's a really generous thing to say, but yeah, some some logs are not enabled by default and you always want to have them because the attacker clearly won't do that for you. The next uh the first thing is um enabling the unified audit log which must be enabled in some subscriptions. The mailbox audit login which is enabled by default but still

you want to double check it won't hurt and uh also use some exchange online logs like get inbox rule or get mailbox out log to just kind of surf around what's going on on the mailbox. Next is detect suspicious login activity. Again, it's a generous thing to say because I say no Yeah, I should detect some suspicious activity. But still, I I cannot go without uh saying it. So, u what is suspicious or what a suspicious login activity? Uh what does that mean to you? There are million ways, not million less, but yeah, there are different use cases how you deem to to find a a login suspicious. I just threw a bunch of them

here. Some of them are uh geob based anomalies. So impossible travel login from like uh impossible geographic distance locations. So if a user logged in from Kosovo and lo next time it log from I don't know let's say London u under 30 minutes you know that there's something going on. But still you need to do more more research on that because technically you could be using a VPN. But yeah, that's another another talk. A first time country or maybe unusual geoloccation for that role. And you always want to do some sort of baselining based on the device and and client anomalies. Uh and last but not least is uh monitor suspicious network which can be a to exit nodes or

commercial VPNs which are which are highly used by threat actors nowadays. And how to detect inbox rule abuse. Now um the first and most important thing is find the inbox rule. Next is see if that inbox rule uh has any filter or condition set to keywords. So this tells you that the keywords condition is the most used uh type of condition. Let's say if that's the case again these are the keyboards. So uh we have six of them. And um yeah, if that's if that's the case, you want to see if these keyword looks suspicious. Again, we have shown some suspic uh suspicious keywords, but that can be a different case. So you you you are the one who who

are the judge to what is suspicious to you. But yeah, in our case, uh suspicious keywords can be admin, MFA, reset, anything related to security or even invoice and payment. Uh if that's the case, uh if there's no uh set to filter keyboard, you jump straight jump down to the actions. Uh so is there a delete or move to actions. So you know that um if these two are correct, then the next step is just to kind of check if there are any suspicious activity prior to this rule creation. And if there is that can be marked as true positive and if there is not you can mark it as false positive and I just uh

uh saw that I didn't put the rule name but yeah another another key point is um check the rule name if that makes sense sometimes the user will just uh create a fake rule name which says inbox optimization or uh archiving old emails but what it does actually is doing is just deleting emails. So, you want to be extra careful uh on that one. So, it can be a key uh low-level indicator, but not something to actually deem it as as suspicious. I went by fast. Okay. So, the summary threat actors continue to target business email uh for various purposes. They're not never going to stop. And um next is configuring the necessary cloud login option where you can uh you should

retain your logs. You can forward them and uh start querying them for uh uh to enhance your capabilities to detect this uh bad guys. And yeah, look out for suspicious uh inbox rules where stealthy persistence is known to be attackers uh is known to be uh attackers's favorite dessert and evading defenders can be a major milestone for attackers. Uh thanks for your time. I'm 10 minutes earlier, but yeah, I didn't catch your breath. So if you have any questions, any brave soul to ask any question said the old friend. [Applause]

Uh thank you for the excellent presentation. Could you maybe share with us your thoughts on where these types of attacks uh are going? What's new? What are some interesting things that attackers are doing in the cloud and cloud apps? And how do you see this evolving in the near future? Yeah, great question. So um I'm going to stick to only himbox um instead of just talking about the whole cloud apps but still yeah I think that u attackers love a new way or new research which has to which has to do with initial access like if somebody sees uh post exploitation tool they said screw it it's not it's not important or it's not as exciting as uh initial

access tool. But um I do think that um as I as I mentioned earlier um a persistence if you find a persistent way into um not like uh not uh actually triggering alarms for for defenders or just trying to to uh screw up with defenders and instantly also screw up with the with the user. That's a that's a a really interesting and it's a really uh I would say it's the best way for an for attacker. I don't know if that I I completely u did answer your question correctly but

yeah. Hey, thank you for the presentation. Uh the rules that you mentioned, they were new to me and they are amazing. I'm gonna start using them. Yeah. Uh I I have a question here in Kosuru. Do you know if we have actors acting in Albania and targeting Albanian businesses? Yeah. And I guess I'm not the right person to speak about that, but uh I don't know. I'm sure they they are but um yeah I'm sure they are. It depends like I'm not the right person to talk about that but yeah we can we can chat afterwards not on live. Any other question? I'm not sure.

in in what you saw with the the the logs, do you normally see commodity based thread actors using those or do you have you all noticed like real APs also using those types of filters as well? Uh I guess so uh I have a completely another resource related to inbox rules. I won't spoil it but um I think that uh as business email compromise are are growing there are definitely uh new ways into leveraging inbox rules like for example uh if you were in the at depot's presentation and ambiance about skyscap if you're using different ways so you can create inbox rules in three different ways you can leverage Microsoft graph API you can use the

powershell exchange module and you can use the the UI. Now if um you do this uh create a inbox rule in all three of them, there will be like small minor differences. So I think attackers are starting to understand that um there will be and there are differences between using an SDK using the u uh command line tool and also the uh the UI. But yeah, I don't know if that does answer your question, but yeah. Yeah, it was one of the things like we noticed that a lot of like people trying to just steal money or like you mentioned the invoices keyword and a few other ones as well. Multiffactor authentication or just security alerts in general to try

not to tip off the user that they got compromised for example. Um but we've seen both like commodity based and nation state. But like from a practicality perspective on the detection piece enterprisewise, you know, you could be sending those logs to a SIM and an alert on the SIM itself. Let's just say a smaller company that doesn't have a SIM. Like in your opinion, if someone wants to implement what you're suggesting and detect on these logs, what platform would be something that you would suggest? like is it you know in Azure if you're using exchange or what would you suggest from like enforcement of these? Yeah. Yeah. So um let's say you are a small company you don't own a seam or

you're not uh you cannot afford one. There are lot of open source tool who do uh actually uh have some common TPS about this one. Uh I did mention cloud grabbler which is a detection framework and it actually has the ability to um find some of these uh malicious inbox rules and with some TTPs or you can use cloud tail another open-source tool developed by by our uh colleague but um yeah I think this there might be also other open source tools who uh can do the same thing.

So that was a great presentation. I just uh had a quick question about the effectiveness and how early on the stage these kind of problems can be detected and uh fixed. uh because let's say it's also on the potential danger of these Outlook breaches because let's say there is a a threat actor which actually has gotten access to the has breached the the Outlook uh mail and but let's say he's he works really slowly. Let's say he he's doing the recon really slow like a grandma in a wheelchair and he's just looking around and uh just finding and just waiting for the right moment to get the right information. M uh how effective you think these new these

inbox rules will be into actually preventing that and getting him in the early stage? Uh I don't know if inbox rules are the for example if an attackers just snoops around and reads emails there's not much inbox rules can do. uh but uh yeah I think just doing some sort of baselining based on how many like if you're uh if that specific user has created an inbox rule which is a deletion inbox rule you want to do some sort of anomaly how many times has that user created an inbox rule fine 10 times okay has it always been a delete inbox rule yeah all 10 times so that you can mark it less suspicious but um I think

what you're asking is more about on the initial access phase whether how you can detect an anomaly or anomalous um a login rather than detecting an inbox rule. But u yeah [Applause]

All right, this will be our final presentation for today. uh Tim from Bishop Fox. His talk will reveal of the next evolution of Sliver 2 capabilities showcasing how randomized HTTP traffic patterns in version 1.6 blur into network noise to evade modern detection and offering a deep dive into design modification and stealth advantage in in the new framework.

Hello. Okay, here we go. Uh, hi everyone. My name is Tim. I work at Bishop Fox and I'm one of the developers working on Sliver. Uh, this is a very improvised talk, so please bear with me. Uh, the slides were only made yesterday, but let's talk a bit about Sliver. So, Sliver is uh one of the uh well-known C2 uh platform used by red teams. Uh specifically, it's uh the type of tool that you'd use uh in a security assessment that requires stealth where you need to evade detections, try to stare under the radar, and uh slowly move your way across uh your targets environment. Let's talk a bit about an assessment I had a while ago. uh as we

typically do in these, we started with looking at their external parameter uh searching for vulnerabilities and anything that could allow us uh to gain an entry point into our targets network. And lucky for us, after a while, we found an RC. And it wasn't just an RC. It was an RC as the root user on some random web server. After a bit of enumeration on that host, we quickly noticed there was actually no EDR running on there. And even better, looking at the network interfaces, it seemed to have some way to pivot to the on-remise environment. At this point, this is really uh the perfect scenario for us. We have a pivot point. We can quickly deploy some

implant on there and use it to start targeting uh our client's internal network. Basically, uh jackpot. However, after a couple hours, uh we lost access. All our beacons were all our beacons died and we're no longer able to reach into the environment at all. So, as we typically do in these scenarios, we started doing some investigation trying to find out what actually happened. We talked with our clients and as far as we could tell, the domain was good. Our implants weren't causing any uh alerts in their or in their logs or anything like that. We just couldn't figure out what had happened. It turned out later on the client had actually caught it through network traffic for a

very simple reason. and they'd been compromised with sliver before. So they wrote some customized detections and got us caught. Pretty pretty dumb scenario. So at that point in time, I started taking a look at uh how sliver actually uh handled its HTTP traffic uh to see if I could maybe improve on that. And so to give you a quick description, this is uh the situation scenario 1.5. When you generate your implants, you have a single uh C2 configuration where you define extensions for the different operations that uh your implant is going to do and a bunch of URLs, a bunch of paths and uh your implant will just generate your traffic on the fly. Uh and

you end up with URLs that look essentially like this. The extensions always have to stay the same. Uh and the rest is just procedurally generated based on the uh configuration that you provided. the configuration is going to be the same across all implants for that uh sliver host. Which means that over time uh you're going to see a lot of requests uh going to uh JS. Why? Because that is the one used for poll requests. Essentially, every time the implant is looking whether there's a new activity to to run, it's going to call ajs uh URL, which ends up generating a lot of very predictable uh network traffic. And so uh the other thing that you have is

by default you have this uh little URL parameter. This is actually an encoder ID. So it's used to determine uh what method the implant used to hide uh the data it's exchanging with its backend server. In this particular case for example it's using an English language uh encoder which is essentially data encoded in the lengths of the different words that you're seeing around the screen. It can also do PGs and a few other things. But the problem is you always have the single ID. So if you start adding all of this up together, you start getting to a situation where it's actually possible to write uh some detections for this particular network traffic. And so I spent uh the last 6

months essentially trying to address these problems uh allowing more flexibility in the plant by uh removing the need for specific extensions uh making sure that the content type actually matches the request. Like if you look at this here, we're calling it JS file, but this is actually random English or it could be a picture or anything else. And finally, also removing the need for that encoder ID allowing to hide it in other places like for example in cookies or uh inside the URL instead of a random parameter. So what you're seeing here is uh the latest release as of uh Thursday uh where I've implemented a lot of these fixes. And essentially uh what you'll see here is first of all uh

we actually allow having multiple uh C2 profiles now. So you're no longer tied to one specific type of traffic, but rather you have the ability to switch between as many as you want. Uh you can

have you you here we go you can have uh as many extensions as you want and the implant will just randomly pivot between all of these and for each extension uh you will have specific types of encoder that are specified which allow you to tie uh the right content type to the right network traffic request and kind of avoid that small uh discrepancy there. And so essentially when you generate your implant, you now just specify whichever C2 profile you wanted to use. Uh and once it starts running, we'll have a look at the logs here. You can see that it now uh no longer has that URL parameter because in this particular case, it's hiding it inside

of the URL. It's randomly switching extensions as it goes on. uh which makes it a lot more difficult to fingerprint using the methods that the client had used in that assessment I mentioned earlier. So uh this is it for my talk. Sorry it's pretty short. Uh we have a website with our documentation and this is an open source project. So if you want to contribute or learn more about the tool uh here you go. [Applause]

Hello. Thanks for your talk. It was short but great. Uh question for you. Have you had do do you have the ability or have you considered to do like malleable C2 profiles and and using like CDNs to you know kind of blend in with traffic with like Azure um domains and other like legitimate domains like like for example Cobbot Strike would do. [Music] Um so we actually do use uh these domains but this isn't something that we've included in the tool itself. It's more uh automation that we build on top of this. Um as far as malleable C2 profiles, uh this is another ongoing project uh that we're working on, but it is not currently included in SLE itself.

very

Well, we have we are a bit ahead of schedule. So, uh I think we'll need to wait about 20 minutes. So, the CTF players come here here and uh a lot of people that got raffle numbers are in the other rooms. So we will need to gather them all here and then uh quickly do the raffle game where we will uh well choose randomly 10 uh well numbers and uh they all win uh one month membership on pentaser lab and then right after that uh we will announce uh the CTF uh winning teams. So this way we also have some minutes to double check that uh let's say they played fairly and they didn't share flags and so so we

will validate some some of the flag submissions to make sure that they didn't share flags between each other and then yeah finishing the raffle and after the raffle we just uh announce the winners and give the CTF prizes to everyone. So maybe yeah, a short coffee break and then see you in 15 minutes down here.

Let's go.

So uh well first of all thank you for uh being here given that uh the kay team has a flight to catch. Uh we will start first with the CTF uh vener team an ann announcements. So the first team is Panta Hub and we have Timotei uh Vini and Dylan over there but they don't want the well the prizes but we still want to to announce them like unofficially as the the winners um given that they are giving place to to well to the younger people here and and students and so on. The first team is uh Winrar. So we have them there. Well, wait no where are they? Well, actually they are not in the room.

They are still probably in the other room. And uh we will start as I said with the conc team which uh well won here the third uh third place but given that the first uh team winning team is giving uh place then they are the second team. So please uh come on stage and someone will bring the uh certificates and then you will receive the information uh via email and you can still catch your [Applause] flight. Do I want to give

Okay.

So uh congratulation on winning the second place. As uh you know the second place has uh well two prizes if the internet works. Uh yeah.

Thank

you. Okay, now we switch to the well, let's do the third team first. Third place first and then we go with the winning team. So, can the Padon team please come on stage?

Okay. Uh while we wait actually we we can uh start the raffle game and then continue with the city winning teams.

So uh as you know for the third edition in row now we do offer do a a raffle game and I hope that you all picked a raffle number uh at the registration desk yesterday and today. So uh we have 10 one month subscriptions for pentester lab. So uh let's start with the first one. Anyone has number five? No one. Okay, let's do another round. 29. No one.

92

51

16 17

80 again. 16.

What? Which one do you have? 80. Yeah, it's okay. You can take a picture and email it to info@besidespino.org and you will receive the voucher via email. 16. You can also email it. Uh uh I mean just take a picture of the number and email it. 40. We also have uh the 40 over there. Please do the same. Send a picture. 54. We have 54 as well. Six more to go. 97. We have 97. 13. We have 13 as well. 27. 27 as well. Three more to go. 61. We have 61 as well. 86. No one. 13 is already gone. 64 bits. No one 96. We have 96. And the last one, 75. We have 75 as well. So,

congratulations [Applause] [Music] everyone. And now we can go back to the CTF. Uh well winners and I would like to have the poston team on stage.

[Applause]

Proxima. Congratulation guys and you you have won the uh 6 month subscription on Panther Lab. So we hope that you get way stronger for next edition and you win it again as you did last year. So wishing you the best of luck and and thank you for well we enjoyed it a lot. It was great just like last year and just like the year before that. We hope to be coming the next four, five and more years in the future. Thank you.

And now we have to announce the the winning team. And the winning team is the the Winroar team. So please come on stage.

Nice.

Four.

Okay. So, as you know the first place uh has won,000 euros uh which are given by bankom which is one of our silver sponsors and is the fourth fourth edition that they uh well support the event and we are really grateful for it. So on top of the uh€,000 in cash, they also get four CRTP vouchers from Altered Security as well worth $1,000. So it's a great uh first place uh to to win this these prizes. So congratulations everyone and yeah, best of luck.

[Applause] So yeah, this closes this edition of besides Christina. you will uh well you will see the the the pictures and the registration of all the talks in the coming days and uh we hope to see to see you again in uh well next year in 2026 and thank you for for coming from I mean some of the speakers from very far away uh from the United States and and other countries and uh yeah we hope that you enjoyed this uh this uh fourth edition And next year uh we will organize something special for the the fifth edition and we hope to see all of you again. Thank you and see you soon. Go.