Live BSides Amsterdam 2025 - Tech Track

What the f does it it will loop over all these um input parameters generate a random value for them if it can uh and then invoke the procedure and it will then uh uh store the results into another JSON file. So let's see if we can uh get that to work correctly.

if I can type correctly. Uh first of all we specify the necessary argument for the outping results and um we can just pipe the resource file to the invoke fisser to specify our target f

like this and that's basically all it needs. So then it will just loop over all the procedures uh and start invoking them with our randomly generated uh input. So because it's five um interfaces it will loop uh or it will uh go over all the five interfaces and also over which endpoints it was actually accessible to see the differences between those results and it will uh based on the output it will generate an allowed file an denied file or an error that file. So if you take a look at the allowed file uh we can see uh for example we were able to call RFC delete printer driver um and that contains some of our fing

input uh in this case it took three strings. So it generates uh these random three strings and in this case uh is a windows message which says the file directory name or value label syntax is incorrect. And also if you take a look at the error file, these are the procedures that we couldn't uh uh actually invoke. Uh we see errors like no matching onion selector with Marshall onion 2 and this has to do with some structure issues. Um so yeah that's a bit of the flow about how you can actually start using this tooling. uh I will show another demo but uh for now uh I want to get back to some more complex things.

So a large part of the functionality of the fer is actually generating uh input values for the uh procedures that have input parameters. Uh and for primitives like strings or integers this can be quite easy because you generate a random value. But there's also more complex complex types of uh input parameters for example context handles. And uh if you find a procedure that needs a context handle. Um, you will first of all need to call some other procedures to actually get such a context handle. And a context handle, you can think of it as an session token. Uh, because some uh sometimes within uh in the process communication, it will need to remember the state of uh of of

some kind of information. And in this example uh if we open the printer it will return the session or the contact handle and then we can provide that context handle to another procedure to actually close the printer again or do some other operation with it. Uh by default the fisser will uh create an instance for uh the context handle but this is just a null handle and a large part of the procedures that uh take an context handle and it is a null session or a null context handle then it will just throw an error like yeah this is just an invalid handle and that also uh comes down to a dependency problem because by default

what the fer does it will go over uh over all the procedures in uh for example this order. Uh but um what you can see is that the first procedure here already needs a context handle but uh the second procedure only uh guesses that context handle. So actually what we want to do we want to turn this around so that we first of all call the procedure with which returns that valid context handle and then uh um call the procedure which needs the context input parameter but there's another issue and some procedures actually close that context handle again for example RC close printer and then the last one in this order then needs a context handle

that again but we uh closed it. So then it's again a null session or nil handle. So what we also want is to uh put the procedures that actually close our handle at the end. So then it doesn't matter anymore if we close it or not because no other procedure needs it anymore. And I've done some research and I've implemented an algorithm uh which actually does this. So it will first of all sort all the procedures based on the input and the output parameters that it needs. And then uh once it actually finds a valid context handle, it will um store it to uh and then another procedure which comes along within the within the loop that actually needs a

context handle can take that out of the out of the array where I store all my complex types and then uh uh it will actually be able to invoke it with a valid context. So that's nice. um I've implemented that within uh an argument which uh specifies which version type to use and in this example I provided the uh sorted first type which actually implements that algorithm. Uh so by default it doesn't use this one uh because it can happen that this will provide other results that you perhaps may miss some vulnerabilities. So make sure to always uh test both of the first types to see the differences between them. So let me show you a quick demo about how um how

that goes.

Um in this case our target is going to be the the spooler service again but this time uh we are going to put our focus or the fisser at this RC interface and also just over this uh endpoint. So then the fer will be done um faster. Um so we invoke the fisser. Uh we provide um the fer type which is now uh a choice between default and sorted. And um also we're going to provide in this case an integer input uh because in this case uh what we want we don't want is generate random integers but we also we always want to provide an uh one as an integer input. Um and also I want to look at what my IP

address is uh because opening a context handle can be quite picky. Uh in in this case uh to actually get return a valid contact handle for RC open printer. Um we need to provide our IP address as a string input. So in this case our uh string string input what am I typing? Yes our string input uh will be un path of our IP address.

Uh yes. Then of course I need to specify the right file. See spooler

space. Ah, okay. Thank you.

And also uh I will be providing a blacklist because some procedures will actually hang for example like waiting for a change. Uh so in this case my blacklist contains one procedure RPC wait for printed change and then it will uh go over it. So if everything went well and we look at the errors um uh see so I will just clear it to make it a bit more clear.

Yeah. Okay.

Uh so the thing I wanted to highlight on is uh this procedure because when we actually invoke it, we suddenly we see an error message that the AOPC message request is no longer available. So this could mean that something crashed. Uh and if we take a look at um the event log within of the event viewer within Windows uh go to the Windows logs uh system takes a while.

you will see that the spooler server sort of crashed and that's interesting because um I'm running this as a low privacy user and the spooler service is actually being ran as uh a high priv identity because I I cannot stop this by normally and now I'm able to crash this and remember that we uh over over which endpoint we actually uh we're able to crash this and this endpoint was exposed remotely So this is a vulnerability that I discovered recently and uh yesterday published a blog about um and I also uh prepared like a demo for proof of concept uh to show the actual export on a remote system but I don't think we have a lot enough time

for that. So I recommend if you want to learn more about this vulnerability uh to take a look at my blog because uh yesterday I published a blog about this vulnerability. So let's uh get back to the uh presentation.

Uh the last part is analysis because as you have seen I went through the JSON file but that wasn't really convenient. It took a long time to actually find some interesting things that actually happened. So for example, if your JSON file is 50,000 lines long, you want some solution to actually pick out the interesting interactions and this is where uh I thought it would be a good idea to use N forJ to actually show the relations uh between our data and this is where the command import data to N4J comes in. So what it does uh it uses nej which is a database to show relations between your data and you can query the data using cyber queries and I written a

command for that. So you can pipe your uh fishing results, your JSON file to the input data for N data to N forJ and then you provide your credentials and your uh IP or your system where it actually has uh this NFj database running. So this can either be remotely or locally and then if you provide the right cyber queries uh you will actually be able to map the relation between uh your data So this provides already some more insight but we uh invoke procedure but we're still talking about blackbox fing because we actually have no idea if we invoke a procedure where our input lands on the system. So to get a better insight into where our input actually

lands uh we can use a tool for example process monitor which is a tool within the sys internals uh which monitors processes for example you can view which process it starts and how it interacts with the file system within windows or the registry and you can apply filters to it. So remember when you see those random strings being generated by my fusser, they also contain this static uh string which is which I call the canary uh which no other thing on the oper operating system will basically use. So I'm sure that if something pops up using that string within the path that it was my first that actually did it. And uh if we take a look at that spooler service

for example, it will uh interact with the registry using my strings. So based on my input, I'm able to uh well let the entity authority system open some kind of key on the path that I chose. Um and this uh process monitor file can actually be exported to a CSV and then imported uh into the N forJ database as well. So now we have our fizzing input results and a log file for process monitor. And now we can actually map that uh Windows 32 functions to the input which I generated using my faser. And this opens some new ways and to get better insights into interesting procedures. For example, we can map for registry rightes because um we just make

a cyber query which contains ref set or ref right and then it will map uh exactly which uh fing input uh led to this function call or for example priv file operations where I basically wrote a rule that if it's being executed by the by an hypervis identity uh and it contains the windows 32 function call uh file then it will mark it as a private file operation and that of course is interesting to read as well. So some results uh I found some service crashes remote and local just as I've demoed the school service and of course some quite a few more uh system crashes where I was able to bd uh systems a nice

CV and a bounty uh some spoofing vulnerabilities and even more uh future work contains like testing multiple paths because now we uh still have an order uh where kind of sorted, but we also want to test different kinds of um of orders to see if that would lead to other results and also structures within RPC are a thing that are more complex and to generate the right structure for the input parameter is something that I need to work on because a lot of procedures take uh a structure as input parameter. Um and uh uh currently it's creating just a default instance for this. Uh but actually what you want you also want to include your random inputs uh to this

string to this structure to see how it uh actually behaves differently and of course uh to see if I uh can find more fun abilities. So uh that's it wrapping up. Thank you everyone for listening and I hope you learned something new today.

Uh are there any questions?

Thank you for the presentation. That was really interesting. Um the question is uh did you try to uh so since you know which DLL on the file system uh >> say that um provides the the RPC functionality you can disassemble it and checks what what caused the the exception and why the service uh became dead. So did you try to learn by this way this route? So you mean like the example of the spooler service crash? >> Yeah. >> Yeah. So you can also read it on my blog. Uh I uh disassembled it using GRA and also with DBG and it's basically a no pointer being dreferenced. >> Yeah. Thank you. Actually I read it.

>> Okay. >> Yeah. Already I didn't expect uh to to meet you here but yeah thank you. That was interesting. >> Thank you. Are there any more questions? Uh otherwise I will be around uh for the conferation the whole day. So let me know if you have any more questions. Thank you. >> Thank you much very much. Due to fantastic time management from our speakers uh our coffee break starts on time. So from 11:30 to 12 coffee will be in this area. Uh there is still you can catch the rest of the talk in the main track in the meantime. And uh without yeah without delay please enjoy.

It's really cool to show like really good research, really recent research. Yeah,

>> even though

they did. >> So the thing is you have to at least get weeks before

they said the rules

are great. >> Thanks.

Yeah super

good. Yeah. >> Oh yeah. Sorry.

Yes.

Well, you have your

Okay.

Hello. >> Hey.

I have vision.

in the middle.

We had to open them or

>> what would be my

I don't know.

That's All right.

Have them already.

Right.

>> Yeah.

Careful.

That was

me. Look good.

Yeah. >> Yeah.

Yeah. Yeah.

>> Okay.

Oh yeah.

>> Yeah.

Do you start?

No. Mike

Q&A

as well. In a moment,

might open.

What is happening now that uh the factories and uh the warehouses the logistics centers are connected uh well with it so that it can fulfill the demand and speed up the process of supply chain. and it is going to be increased but since uh everything is connected to the internet connected through the network we have a lot of exposure of attacks as well so uh we've seen a few recently one big news came about land uh Jaguar Range Rover attack which made them shut down for five weeks in production so it was a bit of a misconfiguration and uh vendor third party vendor issue because of that they have faced so much of loss in the business. Uh

similarly few days back cloud flare also had a attack which inflicted whole internet and everybody because cloudfare is kind of backbone of internet which also impact OT and supply chain business. Similarly uh some more attacks ransomware one big name is MPM attack which uh affected only security a lot and other important uh hacks which happened recently. So these are few example including stuckness as big as stuckness attack uh to tell you that OT security is not just about the computer. It's much more than that. It is about sensors. It is about uh the devices connected. It was it is about people people awareness and uh all the things involved. So what is the motivation behind having

supply chain attacks? One is of course the financial game. Everybody need money. Attackers also need money. So uh ransomware is one big example. I'm hoping everybody who worked in the supply chain environment knows about how big uh the ransomware attacks scenarios are happening and it is growing and there's hardly uh you know uh any uh control flaws into it. So we need to be very much proactive to stop the ransomware attack. Then intellectual property which lies with the any company or their vendors. So that can also be theft and that can directly impact to the brand. Then yeah the recent example of Range Rover attack was also operation dis disruption just with a small issue

of let's say rangeover or uh cloudfare it impacted that bigly uh very big and also it impacted in their business and their face the loss then uh there are competitors in the market which want to do research in your business and try to make the name down so That is strategic uh spinage is one reason uh for supply chain attack. Then geopolitics is involved. It is much more than IT or business. It is about the governments who wanted to do bad to other. There are three big wars going on in the uh in world. So yeah OT uh and connected networks are on their target and it's not so difficult to find vulnerabilities into those network and attack and

probably just make them shut down for some hours. It will impact them big and of course including everything it impacts the corporate brand value of any company. So uh the threat actors in this scenario would be application because everything which is running in OT is run through applications. It runs on the infrastructure and network. So uh let's say uh in a distributed environment if the network is not segmented and there are multiple vendors third party vendors are involved. So if the network segmentation are not there one network can expose to other and one vulnerability can you know travel through other network and that's how the escalation can happen. Then multi cloud environment is very common in supply

chain because it's not just one vendor one company's handling every company has multi- uh cloud environment so that's also big uh threat actor in that case then there are IoT device and OT devices those are hardware chips and hardware chips have vulnerabilities to be exposed which can be researched and very difficult to patch at least for the OT environment Because uh for the companies it is a big investment. The SLAs with the vendors are huge but to patch they cannot afford a downtime and just because of that reason that downtime should not be there. Sometime we accept some risk which are very hard for the business. So that is the reason uh the hardware security hardware uh uh risk

are going more and more and more research are happening on the hardware security as well. Then there are supply chain risk which are related to third party libraries, vendors, identity access management of multi- vendor ecosystem and of course there are insider threat because OT environment is mostly connected but it's very easy if somebody who's insider can probably put just a USB in your system and try to exploit that. The big example is stucket. So uh the new ecosystems supply chain is going to be big. It is going to be growing each day by day. So that's why it is going to become the best target for hackers and do research on security on the OT security. So I have a few case

studies which I'm going to present and will be helpful for us to understand how OT security and supply chain can you know help be harmful. So uh first example of case study I have of hacking connected system uh my goal is to find any sensitive information out of it. So architecture is something like uh we have a CNC kind of device which uses in OT environment. It is connected to a application server which connects to a back end. It's a simple uh breakdown I did for this. So a OT device first of all would be a device which can have a connectivity first of all have a chip inside it. That is the basic of any OT

system. So uh there are a few ways we can do enumeration into a device and try to dig down more what bad can happen in a device. So the process is something like if uh a researcher or a hacker wanted to do no want to know about a device what he can first of all search about their devices from Google. So Google will tell let's say I'm searching u uh let's say ping pong bar what kind of a coffee machines they use is it connected I can search probably on Google that I saw an S cafe machine and it is connected so Google is the best uh example of that then there are IoT search engines or OT

search engine for connected devices shoddan and sensus. So in that you directly get all the connected system list and also the open port and services running on that and that is easy and public information which outside outsider or attacker can search then if you find that information let's say uh I get to know that uh this particular device is using uh a particular brand or that brand used uh a firmware which is on GitHub available maybe they've configured it by themselves but you at least get the base code from GitHub and if the library of GitHub of that firmware itself has some vulnerability which is not yet public that could also be one entry point for attacker to know

about one particular device and that device is connected to the OT environment. So from there the attacker can plan the entry and attack into OT system. Then there are communication challenge on the OT devices like that it is connected to Wi-Fi, Bluetooth and bus protocol like mod bus can scan bus IC protocol and ziggp so all these protocols have their own vulnerability Wi-Fi can be attacked Bluetooth can be attacked mod bus uh and any other bus communication protocols also have their MITM sniffing and uh modification attacks which can be done also zero days can happen here because of any vulnerability. Then there are communication protocol in it CP MQTT or web or maybe custom port

or custom uh services sometime devices run on on the internet. So sometime generally what happens in OT industry is for the uh servicing the manufacturer put a back door or a service port which is not patched or maybe not known to a company who is using it but it is for easy servicing but if attacker get to know or he find out it can be backed for whole ecosystem. Then there are application interface which are on public which can be exploited. So it could be uh on the web or maybe a console machine on the top of OT which let's say it doesn't have authentication but probably you can con um you can control the conveyor. So if

it doesn't have you can change the configuration if you are insider. So that kind of flow can also be there on the application. Then there is there are hardware interfaces which can be found for by the research. So uh if uh let's say attacker have access to the device let's say I'm taking the example of another coffee machine which this bar has I can also buy it from market do some research and find vulnerability into it if I can exploit it in local environment I can also do it in the network environment so if such scenario can happen it can also lead to attacks on the network in supply chain network. So uh I'm taking one example of a

hardware either it's a PCB or control system everything runs on the PCB boards in the PCB board a few basics which we can find out are uh the debug ports let's say for example J JTAG pins JTAG pins are used for servicing and debugging on the interface so if we find out we can actually dump and interact with the hardware so that is one. Then there are microcontrollers connected to function those PCBs and PLC's. So uh in MCUs there would be firmware which can have vulnerability. It can it is also possible that it is not encrypted. If that's the case we can also dump information from it. Then there are memory chips for example E2B ROM. If the

credentials or any uh let's say commands or the values are stored in your square v room for researcher it's not very hard to get those information and try to do reverse engineering and malfunction the device. So these are few example of hardware attack which can happen on the OT environment by the researchers. So uh I'm taking this example to exploit the G Jtag port. Through the JTAG we can actually uh first of all basically it was originated to debug the device but it can also be used to interact with the device to dump the firmware and by dumping the file system we can also get to know what kind of key exchange happening what kind of information it is

asking or storing. So uh if you find that we can find these kind of sensitive information or the keys from the devices for example the information was stored like say a personal information or public or private key for the vendor. So uh although it's a big machine but inside it is a chip and chip can be read out. So easy example is J tagulator. This is one easy tool for hardware attackers which they use to interact with the hardware. It can basically use uh to read JTAG, SWD or any kind of debug port on a device. It's basically also uh automate so that you need not to actually know uh which pin connects to what. So it it does the automation and

it's just easy to find out the port and once you find out you can read the information out of the system. So uh just a bit of example like once you dump the firmware uh how do you uh probably find out uh what's there inside it. So I've dumped probably a firmware from a dummy device and I find out this uh firmware is not encrypted. So uh to read the data I can just go uh into the uh uh Linux system and use the Linux keys uh to the Linux command to extract the information out of it. And you can see here there are public and private keys are exposed if it is not encrypted. So

it's just a easy uh tool to uh to dump the information out of it. So uh if you understand that the firmware was not encrypted and by bin this simple tool I would able to dump the firmware and from there the private and public keys which were used to interact with the device are exposed which can lead to bigger attacks. So uh simple misconfiguration at the vendor level can lead to a big bigger attacks. Apart from that there could also be some data which is stored into a device uh which can be read out and can be sensitive for the compliance and for the brand value. So to mitigate those risk first of all patch the latest level of the firmware

which is very hard in OT environment because in OT the downtime is more crucial. We accept those risk because of uh not taking care of the timeline of the patching. So make sure that security advocates should enforce that the patching should be happening on the time. Then uh the encrypted information which we are processing or story should be encoded and encrypted within the process on the channel uh that is uh uh on the network also when it is being stored. then uh the hardcoded credential and keys in a firmware or any device is not preferable. So one way let's say I'm a security uh expert in my company and then and I'm trying to say yes I have a

good PKI so I'm trying to implement public and private key but but the keys are stored within the low panel environment so that means it's not total secure so we need to have a strong mechanism of PKI as well into OT devices then I also have another example of a Bluetooth device which is connected connected to a porty system. So to uh the target uh to do that the goal is to do that is to find out any information from that device or to interrupt the operation. So architecture is something like OT system with a Bluetooth enabled function and it connects to application and talk to a backend server. So uh what an attacker would do is if it

is Bluetooth enabled and attacker is within the range it can try to search for that Bluetooth device interact with its services which is happening on the interface of gat g and try to modify those services. If he cannot modify the g services, it can actually first of all uh malfunction the device, shut down the device and if the device is shut down that means uh it can also interrupt the operation of OT of supply chain which impacts OT. So to go ahead uh this is the process I'll just go to directly a video which will show you how does it work. So if you tear down a sensor, it will have a PCB which is running with Bluetooth. And

to run the Bluetooth uh you need to have a uh probably Bluetooth 4.0 which is classic or Bluetooth 5.0 with encryption. In the OT environment we generally see the 4.0 the old devices are still being used because we cannot afford to replace them and it is being used for let's say last five 10 or 15 years. we are still using it but the problem is those are already malfunction devices we just need to take care of their security configuration so if the old device is there uh what I'm doing here is I'm scanning the Bluetooth device first from the gat tool which is a a common get scanning tool it can be available on either on python or

probably in a mobile device as well nowadays so I'll scan the device. I'll find out this Bluetooth particular Bluetooth sensor. Once I find it out, I'll try to connect it to its services on the G network. So I need to connect to the get database and it is automated tool. So I need not to even write script for it. So I'll connect to the get database and then I'll find out services which are readable and writable. So if the services are writable that means I can also write on that right in in Bluetooth uh let's say there are services for listening audio visual and everything so if the characteristics is writable I can change its value. So what I'm doing in

this video is changing one characteristics of uh one function and uh by doing that I'll try to malfunction this device. So it is it was writable. I put the value as something else and the device was shut down. So I it doesn't need a very uh big research as well. It's just a mobile tool which can hack your Bluetooth for if it is not uh modern if it is not securely configured. Right? So this is another example. Then uh the mitigation for this vulnerability would also be secure configuration because uh here what happens is because of small uh get characteristics uh function which was not used but kept writable I was able to rewrite that. So uh we should not put

any mess configuration in our devices also make sure that the devices which we are using for third party vendors also are using secure configurations. Then uh another example we can take of mode bus hacking. Uh mod bus is one of the protocol uh which is used in uh OT environment. Uh other examples are also like canvas IC protocol. So uh mod bus is also very common to do MIM attack if there's no encryption or authentication in that. So uh uh if let's say there is no segmentation in the network and uh your modeus device is running on one network other devices on the same network can also sniff on the plain text communication. If the communication is

sniffed then it can also be used for malfunction. So this is like one example of uh uh the device which has support for mod bus. Uh there are tool like MB slave we can use to interact with mode bus. So if the communication is not encrypted we can send command or probably try to interact with mode bus and it is same as Bluetooth characteristics. If you put the offset value, it will reply for its characteristics. And in the mod bus uh uh you can try to uh brute force all of all the offsets. If you try to brute force offset and you find offset which is uh probably changing the value then you'll be able to uh probably change the

value of the modwork function and the device will m function. Another thing can happen here is when the uh manufacturer make a device they put the back door for servicing and it can interact to the mode bus control commands. If uh by sniffing you find any function which is used uh for nothing probably on a port connected to a port or maybe used for nothing then it is also possible that attacker can find it to misuse on the network. Plus uh if it is not used that can also be used to probably put back the back door on the device and uh attacker can continuously monitor the device. So yshock basic tool and uh MB slave we tried to do u MB

interaction with the mortals and capture the traffic. Here we found one function which were unknown that was probably a back door from the vendor which uh used it for servicing. But if as a as a commoner I get to know that this function is used to interact on particular port I can also interact with that and if there's already have access to uh to the network I can probably shut down the device or malfunction the device. So this is also one example of what OT device is lacking. Mitigation for this would be again encryption and authentication because uh if mode commands doesn't have authentication probably somebody who insider can interact with simple tool like MB slave and then segmentation was

not there so that if somebody's there on the same network whether it is a third party vendor he can also interact with the device on the network outside of the company because generally we also provide VPN and network access and if it is the same segment it is exposed to third party vendors as well. Then integrity check yes of course if it is affected somebody change something into characteristics and we are not monitoring that we're not checking the integrity of current state of the system we will never know that we have a back door in our OT system. Another example of uh probably a mobile application I have uh there are a lot of mobile application which connects to

different sensor humidity sensor, light sensor, occupancy sensor nowadays are there on OT those devices are also if not properly configured can also lead to a attack and it is very simple because for example let's say there's a Bluetooth sensor uh sorry uh there's a humidity sensor which connect to a mobile app which is uh from a company called ABCD and I also use the same app at my home and probably the device is discover discoverable. So as an attacker if I reverse that mobile application and I know where it connects to I have the backend information probably I have the uh I I have some more vulnerability known about the application I can actually attack that in the supply chain

network. So in my uh uh example I'm using uh probably a mobile application which serves to a machine. This mobile application could have a insecure data storage, broken cryptography. It could have hardcoded secrets and it could also have a backend connection. But I need to find out whether I I have information about backend uh backend uh server or not if it is hardcoded in the in the application. So uh I'll directly go to the demo. This is a general analytics application I made for serving a server and in that application uh I could see that uh yeah this uh can I can do reverse engineering into it and uh do a reverse APK once I do reverse APK of

this application I can read out about the application code itself. So from the code I'll directly to go to the code. I could see after reversing that a backend server configuration was saved into the app file and it was hardcoded. So that means even though I don't know about the company, I don't know about uh anything about the app. I just reversed one APK and find out where it connects to and I have IP address uh and the credential of admin. Now if I try to connect to that with uh just simple Linux command I'll try to ping this and then try to uh uh serve it on the given port. I'll use metasloit for this and through metasloit

I am connected to the system.

So here you can see my system is connected to the back end server which was hardcoded to the application and once I connected to the application I also can harm the back end. So in this uh uh video going ahead I will also show you that the back end information is now a root having a root access and in the back end I can also read out information who am I and change a lot of back end. So if that is the case, this can also harm not only the web application locally or the device locally, it can harm the control the full ecosystem of the back end. So uh these were a few examples of uh

recent case studies of the devices worked on OT. Uh the the problems for this uh case study was that there was no encrypted uh information. The uh hardcoded server credential was storage APK and also there if that is needed and the company of APK made a patch maybe vendor did not patch it. So uh as a OT OT company we should also be uh proactive to patch all the APK and update it. uh a bit of defense in depth. It includes everything including server to the back end to the front end uh everything about OT security zero to strong network segmentation uh secure by design communication protocol everything need to be secure in defense in depth to

make sure that supply chain goes smoothly. That was it about this talk and if you have any questions let me know.

just to give the reference you can connect to me. I'm also shamelessly open to work so promoting it. >> All right. Thank you so much. Are there any questions?

>> Um hi. So I was wondering uh what you expect from the future of OT security uh especially because uh you mentioned a lot of hardware is uh not replaceable and a lot of those hardware have open vulnerabilities that uh hackers will exploit but we're not going to see replacements in the coming 10 years. >> Yeah. At least first of all it's humans who are managing the OT and supply chain. So of course nothing can be patched in one day. We have vulnerability which was which are never just uh discovered. So human awareness is needed. Insider attack should not be there. We should maintain uh identity and access management for the vendors. We should segment our network. These are

some basic things we can do in case we are not able to replace those hardware or not able to patch. But of course in future uh let's say a small loophole in whole network can lead to a bit bigger gap. We should not take any risk very lightly. We should uh handle each and each each small risk uh to be considered as like it can lead to a big risk. But yes there are levels of defense we can do at least which is on network level or identity access level patch management as quickly as possible. But yes in future we have to replace or modify the firmware or patch it and this just starting the AIdriven attacks on the OT

are still coming that will be more dangerous. Blockchain are also being impact impacted into OT. Uh it's positive and negative. So yeah since the technology is evolving the OT should also adopt that. Any more question? All right. Thank you, J. Thanks a lot.

Wanted to say hi.

So this is for you. I brought one for you.

No, >> I hear anything.

Hello.

>> Yeah, the room I think in the menu. Yeah,

>> I got some chocolate.

Okay.

>> That's one, I think.

You need to have a screw.

Give me your wallet.

Anyway, >> I

Oh

>> You don't know.

I'll pay my

like

always. One day you walk in the parking business and then they take your house.

Please Elbow vagin.

Oh yeah. >> Yeah.

Thank you for

the one.

Look at Apple.

All

right. Go. Nice.

to go

Manager

Just use a USBC. Number three

share slides with you or something.

Okay, we're getting

What's

that?

when you have

always guy myself.

Okay, ladies and gentlemen, the next talk is about tracking the adversaries in the middle or AITM. And we have Lex Crears and the stage.

Hi, welcome. Uh my name is Lex Kilas and my normal job title is absolutely too boring to mention. So I'm going to call myself a dark web tour guide for now. Uh what I mostly do is a uh storytelling. So I have a story here for you today and this is a story about adversaries in the middle or AITM which is uh a thing that has exploded a lot in the past uh with the adoption of MFA multiffactor authentication. Uh threat actors have been trying to find ways around it. It used to be easy. They would steal your username. They would steal your password and then ta we would have access to your account and your

bank account and this and that. And then we started deploying this very annoying two-factor authentication. You would get a text message of a code or a TTP or something like that. And then h we have thwarted all the threat actors and then the threat actors thought ha we're going to think about something that we can fort you back and it's the infinite cat and mouse game between uh us and them. So how does it normally work? when you log into I don't know Microsoft or Google or whatever you are on your laptop you go to that particular website you fill in your username or password you get a request for a two-factor authentication and then that website

sends you a session token and then with that session token you have logged in and that session token is actually kind of powerful I'll explain later now adversary in the middle is the same thing except the bad guys they inject themselves in the middle of this stream. So when you as the victim think you are logging into the official Amazon, Google Microsoft SharePoint, whatever website, you're actually on a fake website and the fake website is run by the threat actor and then they proxy your login request to the actual website and then the actual website says, "Hey, I need a two-factor authentication code." And then the threat actor proxies that back to you and then you oh of course I need to give

my two-actor authentication because I am on the legitimate website. You are not. And then you fill that in and then the adversary adversary says well thank you. I can now log in as you with your username and your password and your 2FA code and I'm going to steal your session token. And now with that session token I can authorize myself at that website as you. And the additional downside of having your session token stolen is that it is usually a long live token by long live I mean 30 days 90 days not two years and that if you reset your password or something like that the session token is still uh active in most cases. So you think haha they may have

stolen my username and password but I'll just reset my password and then I am safe again. Wrong. So now we know a bit about the adversary in the middle. Um how does this live in the cyber realm uh domain? Well, it's mostly actually uh fishing as a service. There are a lot of cyber criminals out there who offer this to other cyber criminals because I mean if you can't make money off of unsuspecting victims uh out there in the world then you can always make money off of other criminals, right? Um, so they offer this as a service to other people. There we go. And um basically the entire pyramid from from script kitties to cyber criminals to

financially motivated to nation state allied to nation state funded to actual nation states use this uh model in order to gain access to uh credentials and accounts of people that they want to get uh access to. Um, some of these are pretty professionally developed, some of these are not so professionally developed and you can just smell the chat GPT through the codebase. Um, but the threat actors use adversary in the middle attacks for a variety of reasons. Um, sometimes it's just to uh gain access to somebody's account. It can be for business email compromise. Hey, I'm going to fish you. And then when I've successfully fished you, I get have access to your email account. Then I'm

going to email you because you know that guy. You trust that guy. Oh, I got an email from him. Ah, of course I'm going to click this link. And then I have access to your account. And then I'm going to send him an email. And you know that guy. And then before you know it, I have all your email accounts. And you have just trusted the guy or gal that you normally have contact with. And then tada, I have an entire web of email accounts that I now have access to with your other credentials, your mailboxes, and so on. So, and from there I can do all kinds of bad things. Trademark. Um, having access to your account,

especially if it's your corporate account, allows me to do a lot of data exfiltration. I can steal uh data from their things like ransomware attacks and things like that. Or I can just sell the account because hey, you work at this and that company and that might be somebody out there that wants to target that company and will buy the initial access from me, the session token or just the credentials or whatnot. uh for a nice sum of money and then they can do whatever they want and I don't want to know about it and you know Bob's your uncle. Goodbye. Okay. A lot of threat actors um want to do fishing but don't know how to do

fishing or at least not technically. So what they do is they go out and buy fishing kits. And these fishing kits there's quite a few of them now. Um these are the ones that we have eyes on. the ones that are in bold. So, Tycoon, Kratos, Mamba, Naked Pages, Saiga, and Flowers are the ones that we have uh pretty much automated the entire process for ingesting threat intelligence around the deployment of these fishing kits. And the other ones uh evil proxy, evil engineext and so on are the ones that we still do manually because uh they change things, they try to stay under the radar and so on. But we um look at these uh

fishing kits because they have commonalities in the way that they are being deployed, in the way that they work. And by finding these unique identifiers, it helps us when scanning the internet and when being provided submissions of fishing sites and say, "Hey, this one is actually from Tycoon or this one is actually from so and so." And then we build signatures and detection logic on that and then help protect our customers. So but before we started doing all that we asked ourselves should we even do this because there is actually quite a lot of threat intelligence around adversary in the middle attacks already out there. SEOA uh media news um are a few companies uh health nert in Norway

they do a lot of um work around sorry in the middle these fishing kits and is it really important that we also start to do our own research well uh yes why um it is one of the most common attack vectors that we see in our security operation center even though there are very many ways to protect protect yourselves against ad 30 mil attacks. Now, uh it's still a very easy to do, it's very cheap to do for a threat actor and it's still very successful unfortunately. Um so we still see a lot of them and given the fact that we have quite a reach as an organization ourselves on sensor data and things like that, we can actually

fill in a piece of the pie charts of what all the other organizations might miss. So we complete the picture even more. Even though there is still there is already a relatively complete picture with our information added to it and sharing with everybody we make an even more complete uh picture. So so how do we do this? How do we, you know, let's get into the nitty-gritty. We have something called uh URLquery.net. Uh you might have heard of something called urlcan.io. URLquery.net that is uh basically the same but not exactly the same. It was developed by our uh log team. Uh actually one guy uh Las Ulaf. Let's give it up for Lass. Hey, well done, Lass.

Hey, I'm going to show him this on YouTube. He'll be happy. Uh and what does it do? Well, it analyzes URLs just like URLs scan does. uh you put in a URL, URL gets sandboxed andub and and before you know you have a full report around this website and a uh suspiciousness score of is this website legit or is this website absolutely not uh legit. The difference with uh URL scan there's a few things. um URL query dumps the entire website and the entire uh JavaScript engine and all the resources uh that belong to that page for analysis and we run it through a wide range of sandboxes in order to say hey is this website actually legit or

not. And when people submit fishing websites from for instance tycoon 2fa and things like that, we use the markers that come from there and the indicator of compromise to uh feed that into uh our threat intelligence. So the difference between URL scan and URL u urlquery.net is there is a pro version for URL scan. There's a free version that you can use, but if you want to, you know, disable internet access or make the endpoint that you come out of a different country and things like that, you have to get the pro subscription and then you have to pay. Uh, this one's entirely free. So, the next time you want to submit a website to URL scan, not saying that you

should skip URL scan, but you know, like the meme says, why not both? It's free. So give it a go and see if uh this scratches a different need that you might not get with a URL scan. It comes with an API. So if you want to integrate it in your workflow and want to automate your submissions, you can also that is a uh free for free for use. And what do we use it for? Well, we use it and the information that we get from there for for threat hunting. We automatically harvest IOC's from uh URL query. Um, and we use it for something called secure DNS. You're like, "What's secure DNS?" Well, secure DNS is another

free service that we have. It's these four IP addresses. Um, they do what you expect them to do. They DNS your uh traffic and they translate the URLs into IP addresses. But if there is a DNS request that is malicious according to our threat intelligence, we synch it. You can use this uh by simply changing the DNS servers on your whatever home router at your grandpa and grandma's parents or your parents if they're like you know not exactly technically illiterate and you're kind of worried that they might click on a fishing link and you're tired of them calling you up every time saying that is this email for real? Do I really need to pay? And then you're like no mom you

don't need to pay the IRS again. It's this is fishing. Um, so what I've done is at my parents and grandparents put these IP addresses as their DNS server. So I know that when they go to something that is slightly less legitimate, they get a blank website, they get a sinkhole page explaining, they don't understand. Then they call me and then I know, aha, okay, it was a sinkhole because of our secure service. Um, nonDNSC and DNSC versions are available. Free service. Knock yourself out. So example, we'll take one of these fishing kit websites. This one is from uh Tycoon 2FA. So it was generated with that particular uh fishing kit. And what does that look like? Well, as a user, it

looks kind of like this. You are you get an email or text message, whatever. They they they lure you to one of these landing pages and then you're like, "Oh, a document. Oh, I need to pay. Oh, I need to whatever." And then you click. Okay. So, what you need to know is that with most of these fishing kits, as you start typing, everything that you type is automatically sent that way. You don't have to hit submit. Especially if you end up in uh fill in your credit card here and you fill in your credit card and you fill in your CV uh V code and your expiration date and then you're like, "Oh, wait. This is fake. This is a

fake site. Oh, just in time. I didn't click submit." You're already too late. it was already sent to their back end. Remember that very handy password manager that you have with autofill and you know credit card information in there that just like fills in your credit card information at the push of a button or sometimes even automatically. Yeah. Gone. Okay. So, these guys have been around since 2023. They're one of the biggest ones, which is why we're using them as an example here. And what you need to know is that uh this is actually a three-stage thing. There is a landing page. There is the back end that is for the uh for the threat actor and there is

then a uh a service page which is the checker and then the stealer page. So this is not one website where everything happens. There's actually one, two and three steps u included here. They use a user agent of Axios and uh the target resource that they have is a home office in order to you know flow away in the traffic as you as you analyze it. So like oh office home sure fine whatever. But for us these are things that we use in our signature detection in order to find these guys. So one of the advantages of URL query is like I said we dump the entire JavaScript engine and all the resources. So, we have all the

code that uh belongs with that particular website. Here's a small part of uh of the code uh because part of it is that you get a turnstyle challenge. It's uh this one. You've probably seen it a million times. Prove that you're a human. Prove that you're not a robot. What check marks don't look like a traffic light or you know those those types of things. There is an invisible ID on the website called AN7 and it renders the capture into that ID making it visible and then in the code there is obfuscation and obuscation in this case is writing backwards. You can see it here in the code for instance you can see which is expired backwards or

error backwards. So it's not really obuscation but you know they're just trying to make it one layer uh more difficult that when you uh do your regular uh regular expressions through this for these types of keywords that you don't find it. So yeah you see here a couple of examples of those backwards uh strings and then they join them and then they reverse them and then you get the uh original word again language timeout. Okay. So if that is successful, you move on to the checker function which is the next one because they actually check if you're like um a legitimate if you are fishable is what they uh what they want to check. So in

the checker they create a form with all the information that you have put in there and then they post it to a specific u URL but that only happens after they check that this um uh uh checker domain is actually reachable. If you can reach that because it's not being blocked by any type of threat intel or smart firewall or something like that. Can you reach that? Yeah. Okay. and then post uh the information and check if it was successful or if it was an error. If you cannot reach their checker domain, they just dump you to amazon.com, they say go do your Christmas shopping and then buy. So if you've ever gone to a website,

expected one website and then ended up on Amazon, you're like how did I end up in Amazon? Probably something like this happened. So the landing page that you get sent to from the fishing mail or link or whatever is one thing, but this checker domain is actually a lot more valuable from a threat intelligence perspective because those landing pages, they just create them and dump them and create them and dump them like non-stop. So if you think like, aha, I have a domain name for this uh for this landing page. I'm going to put this in my threat intelligence and everybody that goes to this page will know that it's a fishing. It's too late.

it's already gone and they've already created a new one five minutes later with a different name. So those landing pages, they just come and go non-stop. But those checker domains, those are a lot more valuable. Those are not being created and destroyed and created, destroyed every 5 minutes. Those stick around for a while. So having those checkered domains and having those in your threat intelligence feeds is actually uh kind of valuable. Now when they actually go to steal the credentials, we go to the stealer domain and the uh formatted arcs that you have those are the credentials that you have uh sent in the uh in there and they are posted to this hardcoded domain over

here. And now that's interesting to happen. That's interesting to know and that's interesting to have because those domain names they stick around for a while and those are valuable to have in your threat intel. Like I said those landing pages, nobody cares. But the checker and stealer domains those are interesting. So those we uh those we keep and those we uh use in our threat intelligence to determine if uh users, customers, victims have visited that particular website or not. So uh they check if it's a reply then they decrypt the uh the formatted arcs that came in and then they grab the session. And then when we see this happening in the traffic of our customers, we know what

time it is. We know it's too late and we can, you know, fire up the response engine and start with the reset passwords, revoke session tokens and etc etc etc. So what do we do um with this data that we get from UL query? Well, we use this to write uh detection logic, Jara rules in in this case mostly. Uh here's a couple of examples um variables when it comes to uh parts of the domain name u the formatted arcs that happen. If you go back here, you see those formatted args, they come back here as well. The plus rand route which is over here. So we use things that we see in the code as

variables in Yara signatures uh to detect traffic that matches these things. And of course um the bad guys they they tweak and tune and then we have to tweak and tune as well in order to stay up to date. So that infinite cat and mouse game keeps going up. But when it works, it works. And then you get results like this where you don't know that there is a new checker or stealer domain. But based on the Yara rules you have and the traffic you've seen, you're like "Hey similar traffic to a new domain that we hadn't seen yet. And now we found that new stealer and or uh checker uh domain because of the signatures in the traffic

and not so much the fact that we have seen the website and know that it is actually a stealer or a checker uh domain. So that's nice. Now we track uh all this traffic as much as we can and we visualize that in some graphs. Why? uh very simply because the bad guys don't give us a phone call and tell us that hey we updated our code or this or that. So you also need to update your detection logic. my job would be a lot easier if they did that. But they don't. So we need to stay on the up and up by tracking them and seeing that oh wait uh certain things are going like

flatline. they might have changed things which is our input moment to go in dig in again uh find the latest version of their codebase and see if they have made changes to the way that they send their code send their credentials to where from where etc and if we need to revise our signature uh rules in order to catch them again. So yes infinite cat and mouse game. Okay. So, threat intelligence, why are we doing all this? Um, threat intel as a thing is a pyramid. At the bottom, you have data in its rawest form, IP addresses, URLs, things like that. Uh, but they don't mean anything until you process them into information, which is

data, but in processed form. And then at the top, when you actually say, "Haha, now I have information. Now I'm going to do something with that information." Now, we speak of intelligence. Um, so we want intelligence not for the sake of intelligence, but we want intelligence for the sake of making uh educated decisions around the way that we deal with these uh fishing kits and how we work around them and how we continuously keep uh detecting them. And what we need to keep in mind is that when we build this threat intel, who do we do it for? I mean we do it mainly for the security analysts that operate our uh our sock because they see all the

alerts incoming. They need to do triage and analysis on that correlate with existing and outside threat intel and then eventually make that decision. Yes, this is a true positive. No, this is a false positive. It goes into the bin and then next secondary. We do this for our customers and we do it for the detection engineers because the detection engineers need to know what's going on so that when new versions of these fishing kits come out that they can modify, create, update, life cycle, whatever the detection logic that they already have in order to stay uh ahead of the curve so that future fishing kits can also be uh detected. So we need to make sure that this process is in line

with the needs of the people that we do it for and not just you know why are you doing it because we can. I mean it's also a valid reason but it's good if it has a second real reason that supports a uh the security processes that we have. So kind of already mentioned the uh this for the sock analyst what does data mean? data for them would be a list of IP addresses and domains that are for instance those fishing domains from tycoon to fay. Uh but if I just give them a list of IP addresses and URLs they're going to be like what's this? So in order for them to understand what it

is that they're looking at it needs context. So if I give them the list and say hey these are uh fishing websites and these are the checker and seed domains then suddenly for them it's information and then on that we can say with this information you can make educated guesses around the incidents and alerts that you are triaging then it becomes intelligence and that helps them on the split minute decision when it comes to is this a true positive or is this a false positive and if this is a true positive what should I to reset password of a user, revoke session tokens, reinforce MFA enrollment and you know things like that. And then for the detection engineer,

they zoom out and they say, well, we're catching these fishing kits today, but you know, they might change it tomorrow. They might change their codebase. They might change the way that they're doing business now and sending information back and forth. And we need to make sure that our signatures are wide enough to catch it when they make small modifications to that codebase. but not too wide that we get a lot of false positives and they need to be narrow enough that we find them but not so narrow that we miss any true positives. So they need that information in order to do their job. Now you know the best thing of course is to make sure that you

are uh not exploitable in the first place. So when it comes to uh adversary in middle attacks there are very good ways out there to not be exploitable. Um most organizations are uh in Azure in some way or shape or form. So conditional access policies have loads of capabilities of saying that oh user is logging in with a different user agent for the first time from a location that they've never logged in from and so and so. I mean it happens after the fact. The user has already been fished and their credentials have been compromised and the threat actor is then using those credentials from a different location, different user agent and so on and so and so. Uh so you're still going

to have to act but at least conditional access policies will kick the threat actor out and then from there you won't have to deal with you know more compromise and more data exfiltration and uh and so now together with uh making sure that you only allow compliant devices and then risk based policies will make it quite difficult for threat actors to successfully exploit uh credentials if the user has been fished. And if that doesn't work, I know they're not the cheapest around, but the 502 pass keys, the UB keys, and you know, things like that. Uh if only for your most sensitive employees that if they get compromised, you're like really uh upshed creek without a paddle. Um would

also be a suitable uh solution in order to make sure that they become relatively hardened to uh being fished. And then it becomes a a bit of a math game like how much time are you spending on even if you've gotten the process down to a tea and you can do it like click click click click click click okay this user has been uncompromised we've revoked and this and that and so and so and so how much time is that taking you because even if it takes you only 10 minutes if it's happening 40 times a week that's still 400 minutes and compare that to a solution uh with a bunch of phto keys or

actually setting up proper conditional access policies or one of the other ways to do adversary middle mitigation might eventually actually be worth it. With that I would like to say thank you. I hope that this was entertaining andorformational

and if you have any feedback please scan the QR code. It is not a fishing website I promise. And if not then they come find me after show and if you have any questions or now. >> Very insightful talk. Thank you next. Uh are there any questions? >> My presentation was so clear. There are no questions. >> All right then. Yeah. Thank you so much, Lex. >> Yeah. You're welcome. Enjoy today.

That's always

good.

I'll get out of here.

Yes, I know.

I'll come back in.

Thanks for helping us.

Are we good to go?

Guys working.

>> All right. >> Are we good? Okay, perfect. We have Marvin and GMA here and he's going to talk about EDR blind spots and exploits which is another cool and technical talk again and yeah the floor is yours. >> All right. Awesome. Wow, it's loud. Great. All right. Good afternoon everyone. >> Good afternoon. >> I I live in Sweden and the Nordic people are not very conversational. Um, so I was told the Dutch are a little bit more open, so please show it to me. Good afternoon. >> Good afternoon. >> Afternoon. Perfect. Say hi to the person next to you. Just check if they're okay. I know it's a little bit weird, but I like to keep stuff interactive. Just

check on the person. Even if you don't know them, just are you having a good time? Just check with them, you know, just make sure everyone is good. I know it's after lunch sessions, so it tends to be a little bit, you know, um, there's a food coma that kicks in as well, right? Um, all right. Welcome to my talk. My talk is uh entitled catch me if you can. How attackers outsmart edr2s. How many of us work with endpoint security? All right. You know what? I know there's going to be a lot of questions today. It's almost the entire the entire room, right? Okay. Um so we do know that EDR2s have evolved. They've just developed.

They're doing amazing stuff in our environments and they've become a big target by attackers or for attackers, right? So um that's going to be a little bit of my focus. um of of my talk today. Basically, what are attackers doing to evade those EDR2s? A little bit about myself. U my name is Amavin GMA. I work for Elastic. Uh I'm a principal security specialist. I'm part of the global security specialist team. I'm passionate about security operations and intelligence. I've been with Elastic for about four and a half years now. Previously with IBM in the Nordics again where I did security intelligence and operations consulting. So I just love everything around intelligence and operations and basically helping

organizations develop their security operations capabilities. Um I know cyber security people are very obsessed with tech but I also have hobbies. I love to travel. I love seafood. I'm a Manchester United fan. Don't laugh. Um I play best guitar as well and I like to explore new hobbies as well. If anyone wants to connect on LinkedIn those are my details um in that sense. So what agenda do I have for you today? So, I'll look at basically how EDR2s work. We know that they're there to stop malware from running in our environments, but we'll just take a few steps uh back and just go a little bit into the internals of how EDR basically works. And then we'll

go into the gist of the talk. How do attackers basically try to evade the capabilities of EDR? I'll try to touch on some real uh case studies time allowing and then I'll close it off by just giving some practical guidelines on how you can basically do defenses. Who recognizes this wave? This is from math and physics and sciences. What wave is this? >> Is it s or cosine? >> Is it s or cosine? >> Now I see who was paying attention in math class. It's a cosine. It starts half phase, right? Yeah. So, it's a cosign. It's got nothing to do with my talk except for the fact that you might find this content to be very technical some

of you. And you might find this content to be very light for some of you that work with EDR2s. I usually get mixed feedback about this talk. Some people go like, "Oh, it was too technical." Some people go like, "Oh my god, we're expecting a little bit more." You know, so it's going to be like that. Some parts are going to be very technical. Some parts are going to be light. Okay. The reality today is there's so many abbreviations, acronyms and names within the endpoint security space, right? So historically we've called these tools AV, antivirus. If you talk to certain vendors, they'll call these next generation antivirus. Some people call them endpoint protection platforms. At

Elastic, we call this EDR. So basically endpoint detection and response. Um, some other vendor friends of ours came up with a new tag called XDR. And this some sometimes gets a bit confusing but let's be honest at the end of the day all we're trying to do is find malware in our environments right so that's what I think about all these names in the industry today u my focus is going to be on ed because I think we should just call it edr from that perspective okay so in a nutshell we've we've we've grown so accustomed to antivirus right so antivirus has gone through a lot of innovation if we can call it that and And that's been driven

by what we're seeing in the endpoint security space from a threat point of view. Right? So ransomware has been on the rise. We've seen botn nets. We've seen polymorphic malware and different malware family types as well. Right? So it drove AV2s to go beyond signature detections, right? We needed to get to a place where we can also identify zero day kind of stuff. So we introduced huristics and behavior analytics on the endpoint. uh we introduced machine learning endpoint ccentric machine learning kind of capability and then some edr vendors or antivirus vendors also have what we call heats and hips so host uh based intrusion detection systems and host based uh intrusion prevention systems as well as well as

firewalls but then those of you that work in the endpoint security space you were like nah this is not enough right we need a little bit more so we're looking for anti-malware and exploit prevention capabilities Right. Um, and then also we're looking for telemetry cuz we want that context. It's great to get an alert that malware fired, but we want a little bit more context in terms of what is a telemetry that is surrounding a very malicious um activity. So this is my conclusion of what EDR is supposed to be. Your EDR2 is supposed to give you antimalware capability, telemetry collection capability, and then ultimately from an in incident response point of view, you want to do that response action. So

let's look at the components that make up an EDR. There's primarily three components. The first one is the agent itself, the piece of software that you install on the endpoint. So basically, the agent controls and consumes data from multiple sensors. A sensor is something that is basically just sensing the stuff that's going on and then it's picking up hints on what's really going on on the endpoint itself. The agent is also responsible for things such as alerting. So it's got detection capability or prevention capability, blocking and deception capability as well, right? Um then we talk about sensors. So sensors are just basically there to observe activity that is happening on the endpoint. So I hope you're beginning to

get the gist of it, right? So the agent is what we install on the endpoint. There's a sensor component as part of the agent as well. It's sensing activity. It's a super fast processor. And then the agent has got inbuilt logic that is using that activity to see what is malicious and non-malicious in that sense. And then ultimately we get the telemetry itself. So this is the raw data produced by a sensor or the actual endpoint itself. When you log in there's an activity that goes on. It's an activity, right? So there's a sensor that's tracking that as well. When new processes are coming on the endpoint that's telemetry and the sensor is sensing that activity. When you create a

new weight file on the endpoint that is also an activity and the sensor is sensing all these things and then reporting it to the agent itself. Key to the telemetry is there has to be completeness in the data that we're collecting on the endpoints themselves. What do we mean by completeness? If we're tracking file activities, you want to track the entire life cycle, right? from file creation to all the file changes that happen to a file. Ultimately, when the file is deleted, you want to be tracking that completeness of the data as well. So, we're talking file activities, it could be a process, it could be a network communication, but it has to be telemetry that is complete in terms of

the story that it's telling you. So, this is where now we begin to go a little bit into the weeds. I hope I don't lose people here. Some people are already familiar with this type of architecture. But basically this is the basic composition of an EDR agent, right? So if I start on the left hand side, you have what we call a static a static scanner, right? So this is basically scanning the binary files. So the services that are running on if we're talking from a Windows perspective. Um by the way, this talk is going to focus on Windows, but there's equivalent implementations on other operating systems as well. But we do know that Windows is one of the most common

operating systems um in the world. So I'll stick to Windows in that sense. So you've got the static scanner, right? So there's portable executables on our endpoints that execute and you just basically want to do scanning of those PE files. And then when we come in the middle, there's what's called a kennel mode driver. So we do know that on the endpoint, there's a user space, there's a kennel space as well. And most EDR2s also reside in the kernel in the form of a kernel driver. Some people love that, some people don't love that. It's a big debate currently whether we should be doing it um in that way. I'm a huge fan of having edrs as part of the kennel

drivers. Reason being they give you raw telemetry. They give you that visibility you wouldn't really get in the user space as well. So we're getting a lot of telemetry, registry activity, memory activity as well. And then we're sending that into the agent agent service itself. And then you've got a hook DL and I'll expand on what that is, but there's a whole lot of telemetry that we're collecting. Some EDR vendors extend this basic EDR architecture. So they give you the static scanners, but they'll also give you what we call a file engine. It's just going to be monitoring file activity on the file system. And then there's also filtering that happens in in the in the context of

the memory itself. Right? So everything that is running in memory, the processes, the threads and associated memory information that is also being tracked as well. Some EDR2s also give you a network engine. So every network activity that is going on on the endpoint is going to be tracked from that perspective. And then finally some EDR2s also extend this with emulators or sandboxes. So if the EDR2 is not so sure whether a certain process is malicious or not, it will execute it in a little sandbox, do the malware analysis and then make a decision whether to allow that to continue or not. So again, different vendors give you different flavors in terms of capabilities. So far

so good. You look so serious. You're scaring me. Or it's either you're paying so much attention. We'll find out at the end. Okay, so we talked about hooking DLS, right? So this is a a nice scenario of what really happens on the endpoint. There's something that is going on in the user space. And maybe I should have shown a much simpler example, but also this is simple for those of you that work with these tools. Let's take a simple example where you want to create a word a word document on your on your laptop, right? You're creating a file. Now a file needs to be mapped to the file system as well. So you're doing

that in the user space, but for you to create a file, you need permission from the kernel, right? So you still need to make a call to the kennel say hey I'm creating a a word document. So it's userland making some calls system calls into the kennel space and what most edr2s will do or av2s is basically they'll do a man in the middle and basically do a hook. So whatever parameters you're sending into the kernel, whatever functions you're calling and the parameters that you're sending, they'll do a hook and then also monitor for the responses that come from the kernel. And if there's malicious intent, basically this is where they'll stop it. So we talked about telemetry

collection. Um I work for elastic. I'm not here to market elastic, but we also collect quite a lot of telemetry on our edr2. There's a nice project on GitHub. It's called edr telemetry project. How many are familiar with it? Okay, about half the half the audience. That's really good. So, if you're wondering, hey, um the EDR tools that we have on the market, what kind of telemetry do they present you with? You can check out that uh project on GitHub. But yeah, different vendors give you different levels of visibility. And this telemetry also has an impact in terms of the anti-malware capabilities that the ADR gives you. So, we've looked at the basic composition of an agent. We've looked at

the functionality of an EDR agent, right? Um, but we we also see that for a long time attackers have also been coming for these tools, right? Um, and basically they adapt faster than we do. So, it's amazing we're innovating machine learning, you know, endpointcentric machine learning huristics and all these juicy things, but attackers always trying to find ways on how to evet the EDR and it's become a powerful tool as well and they know it right. So now the focus is not to attack you only but to disable the functionality of the EDR itself. So the way I look at EDR evasion I like to classify it in two categories. The first one it's the old way of doing it.

I think most vendors are now u akin to these techniques. Um I think most vendors can pick up on this. The first one is on disk evasion. So mware is just basically software right? It's code that runs on our endpoints. it needs to find its way on our endpoints. Right? So in the past, evaders used packers. So this is where they really compressed the file in such a way that it makes it hard to do analysis on that file and determine whether it's malicious or not. Then they went into the whole obiscation space as well. Basically trying to hide the code that is running within the malware files. And then they use cryptors as well. But today most of the EDR2s are

able to um identify on disk evasion. The next one is in memory of fless evasion. What does this mean? So basically attackers know that the services that we're running on our endpoints that we trust, especially on Windows as well. There's so many DL files we trust. There's so many services behind some of these DLs and they're going for those things that ideally we tag as normal traffic or as normal executions on the endpoints and mostly they're doing this in memory, right? So going directly in memory without leaving trace on disk as well. A more modern lens to look at EDR evasion basically looks at three aspects right. So we're looking at blinding, we're looking at blocking and we're

looking at hiding. What does this mean? So the attackers will first aim to do blinding, right? Um so with blinding they're looking to stop or temper with the sensors so activity isn't observed. So if you remember what we defined an EDR to be, one of the components was a sensor. It's sensing activity that is going on on the endpoint and then the agent has got that logic based on the telemetry is collecting from the sensor to make a call, right? Are these activities malicious or are they not malicious in that sense? But then if the sensor is not creating the telemetry, the prevention capability of the EDR is not going to work. So one of the things

they try to do is to do the blinding. So the EDR agent does not really observe the data. The other aspect is blocking right. So yes, telemetry is being generated but then that telemetry is not uh basically reaching the analysis pipeline. And again it's dependent on where your EDR your EDR logic resides from an anti-malware perspective as well. And ultimately there's hiding as well. Hiding is where again they those services and the stuff that we trust on our endpoints is used for blending in right so the attackers still execute their shell code but they just blend in with those things that um we accustomed to on our endpoints so far so good I hope okay you all look too serious I'm

the only one smiling okay another way to look at ed evasion is attackers will also look at hey how does the configuration of your EDR operate right what are the settings and then and then is there loopholes that can be exploited in the configuration of the EDR um we've we've heard of agent tempering attackers come in they just look at how basically you deploy your EDR and then they take certain steps to basically go for that configuration and then there's also perceptual right um you alter what the telemetry and the sensors are actually seeing right it could be some poison reasoning of the telemetry um or it just could be um basically changing the that

perception and then there's a logical aspect. Um so if we trace this back to the D hooking so you look at the user space and the kennel space we said most EDR2s would do a hooking and then intercept the communication and look out for malicious activities right so there could be a logical evasion where the attackers run things in the user space and then they just bypass the hooking right so that's one way of doing um a logical aspect the last one is classification so we said the agent is the one that's got anti malware capabilities. It's the one that makes the call. Is something malicious or not? Now, if the attacker can be so smart to

evade your detection logic, then they find the leeway in because again, they're blending in and they're intercepting some of those configurations. So, let's look at the evaders toolkit. What are the different ways that attackers are doing evasion today? So, the first one is user mode hook evasion. We'll touch on that in a bit. And then there's ETW and AMZ tempering, right? So ETW on Windows is event tracing with Windows. I hope people are familiar with that. And Amy is just basically the anti-malware scanning interface. So Microsoft on the Windows operating system because they know there's a lot of EDR vendors out there. They've actually made it super easy for you to bring your EDR as a vendor and then make

it work on Windows as well. One of the interfaces they give you is the anti-malware scanning interface. So attackers basically try to temper with that interface and like we've already established they try to do memory like memory only executions and then there's low bin abuse as well. So leaving off the land binaries and then ultimately and this we've seen become very common in the recent months in this part of the world they do can driver misuse. So bring your own vulnerable driver in that sense and we'll touch a little bit on that. So far so good easy to follow. Okay. All right. So the first one we saw um hooked DS and how they operate on the edrs, right? So

basically again I'm just creating a Google doc file. I want it to be registered on the file system. My EDR will do the hooking. It will intercept the cause and see if I'm trying to do something malicious, if I've attached malicious macros in that document or not and things like that. Right? So that's where it happens. So the EDR observes API calls but ultimately attackers will bypass the hooks by doing direct operating system calls right. So instead of their shell code or the payload going through this hooking basically they implement techniques where they actually do a bypass or they do um a clean API restoration. So they do something malicious and then quickly clean it up um before the EDR actually

picks on it. So this reduces or removes that user level visibility and ultimately they do bypass that hooking DOL. A lot of EDR vendors have moved away from hook DS and they're using um different implementations for um their EDRs. The next tool kit that we talked about is event tracing with Windows and AMZ tempering. Right. So um with this technique basically so how many are familiar with ETW event tracing for Windows? Okay this is great right so we've already established that the agent has got a sensor which senses activity in addition to sensing um telemetry on the endpoint most EDR vendors also depend on Windows itself and the events that the operating system creates for you. So,

Windows provides you with so many channels uh for different types of data, different type of activity that is being done on the operating system itself. And most EDR vendors will consume that telemetry as part of the logic for the anti-malware as well. Right? And then these the anti-malware scanning interface basically inspect script content. Right? So, we do know that a lot of malware is in the form of scripts as well. before they execute you can actually intercept them at kennel level in the army as well and we see that attackers try to disable or patch these components right so either they'll patch the ETW ideally it stops creating this telemetry that means you're not really

getting the telemetry that you need for um your anti-malware capabilities as well so this leads to significant loss of script and event telemetry so you can't really see what the scripts are doing on your endpoints you can't really see um any telemetry coming from the operating system itself. This is um there's a nice article and I do link to it as well. This was early in February of 2025. There was certain attacks. So this is a remote access Trojan that was targeting European organizations and they basically used new techniques for ARMSY and ETW evasion as well. I would recommend it for reading for further reading. I don't want to go into the details of some of

these techniques because again it might get too technical. So I'll just leave it at a high level but this is quite quite a very good read in terms of basically what attackers are doing in that ETW and AMZ tempering space. The next one is memory only execution. So remember what I said there's two categories. Attackers can write files to disk and then u go on to try to um achieve the objective or they can actually go straight into memory. So there's certain things that are executing in memory and they try to find themselves um executing in the context of those processes and ideally those are processes that we've come to trust. So we do know that code runs entirely

from memory with no on disk artifacts and then some of the techniques that attackers are are using or employing is reflective loading injection and process hollowing. I would not go through all three, but I'll just touch on two of them. The first one is the PE injection, right? The portable executable, theexe files that we have on Windows. So, how do attackers come for those executables that we've come to trust, right? So, the malware can copy itself or its malicious code, the shell code into an existing open process and cause it to execute, right? So, basically there's four steps. So, there's a process that we trust. It's executing in memory. The first thing that I'll do is open that target

process. The certain cause on the operating system um that Windows supports, open process is one of them. The second step that the attacker takes is to allocate a chunk of memory in the context of the executing process and then ultimately the attacker writes their payload into that memory space. So if you're doing process monitoring, all you're seeing is hey there's this executable that it's executing. It's something I'm familiar with. We're all good. But in the context of the actual code it's executing the attacker actually has managed to um infuse their shell code. Does this make sense? Okay. Basic stuff for some people. I know that. And then ultimately what you want to do is create a new thread of execution

right in the remote process to execute your shell code. So there's a process and a process we know can spread the the tasks through threads as well. So one of the threads is actually going to execute the shell code and ultimately um the attacker is going to accomplish the objective. So let's do a quick recap. Right? So we know that processes execute on an operating system. A process is just basically a file that is executing. Right? Um and when there's that execution that's happening, there's certain states that the process takes. So a process can be in the new state. So you've actually just started executing something on the operating system. um it's new and then it's ready. So meaning

there's memory allocated to it and it's going to be executing and there's a whole lot of other states as well. So what attackers do is they try to take advantage of these process states, right? And this leads me to what we call the process hollowing. So we looked at injection, right? So injection is a process is executing and then basically you call an open process. So you've got access to that process. Then you write your shell code in the context of the memory of that executing process and then you call a thread to execute your shell code. In process hollowing though the attackers take a bit of a different approach. Right? So the malware basically hollows out legitimate code.

So again this is something that we trust that is executing on the endpoint and then we overwrite the memory space of the target process with a malicious executable. How does that work? The steps include you suspend a target process. So remember the states of a process right a process can be new can be ready can be running when it's running it's allocated memory on the operating system on the on the endpoint right so what happens is the the attacker will suspend the target process and then secondly it will replace a malicious ex uh it will replace that with a malicious executable image. So the actual process with allocated memory has been suspended and then you replace the executable

image and finally the process is resumed. Now when a legitimate process is resumed it just continues executing in the context of the memory that was allocated to it. But then when it resumes it's executing the payload that the attacker planted into the context of that process. Make sense? Okay. All right. The next one I want to talk about is the low bin abuse. Right. where we just abuse trusted tools on the endpoints themselves. So we've already talked about you know things that we trust but what are those things PowerShell right? How many people do PowerShell logging from a security perspective? Few hands in the room it's painful. Let's be honest especially if your environment has got developers. The

moment you begin to do PowerShell logging and you begin to track malicious patterns you will get a call from the people doing the CI/CD pipelines. That's just a fact, right? It's annoying. But then again, when you look at it from a blue teaming point of view, attackers are exploiting PowerShell a lot. PowerShell is powerful, but again, it also opens up vectors where you can literally download shell code from the internet and then it's going to be run in the context of the memory of PowerShell. So if the only thing that you're doing monitoring on and logging on is PowerShell, sometimes you might not really get context into what PowerShell is executing within its memory space. Right? So there's so many

documentations on how things that we trust on operating systems can be abused. Um and here basically contextual analysis is key to detection. Right? I know there's a big fighter on how we do monitoring of these things in production, but again um it's really important because attackers are blending in. There's two projects that are very famous at this point, right? One is living off the the land lowest basically. Anyone familiar with it? Yeah. Wow. It's the entire room. This is impressive. And then there's the Unix vision as well is called get the off bins. I don't use bad language, but that's what they call it, right? So, it's GTFO bins. Um, very good for Linux as well. There's so many interesting

attack vectors that are covered by the binaries that are running on Unix. and basically what we've seen in the world in terms of attackers using some of these services. So really good projects. Please check them out on GitHub and on their websites as well. There's another one that I referenced. We had a meetup yesterday. It's leaving off false positives. Like you would never guess it, but attackers also leave off false positives, right? So usually when there's false positives in our environment, we just ignore the false positives. We don't turn off those rules that are noisy. We just say, "Oh yeah, it's always firing an alert." Right? And sometimes attackers know you're ignoring those things. So they'll try and blend

in using those attack vectors. But that's a story for another day. Okay. Finally, we're going to look at kel and driver misuse. So basically bring your own vulnerable driver. Let's just do a recap. Right. So uh okay fine. First firstly an introduction when we talk about kenno drivers. So we saw the edr architecture right. Um the edr today most of the edr2s are basically keno drivers. So, Windows allows them. They sign and say, "Hey, this is legitimate. It's elastic agent. We allow it to be run on Windows operating systems. Could be Microsoft Defender. It could be CrowdStrike, whatever you want to use, right? But basically, the EDR of today is that kennel driver, but has it has to

be signed, right? It has it has to be something that you trust to really run within the kennel space of your endpoint. with kernel and driver misuse bas basically attackers are looking at a way of bringing vulnerable signed drivers to be loaded into your kernel and ultimately get system level privileges and then do the disabling of your edrs as well. So basically they'll disable bypass the kernel callbacks um and you're not receiving telemetry as as we've already seen and then the attacker basically gains freedom to execute whatever they want to execute on the operating system itself. So that EDR either loses deep visibility and detection capability or sometimes it's fully uninstalled as well. And we've

seen real life stories where EDR2s have been completely wiped out by vulnerable drivers within the kennel space. I like visuals. So this is just a visual. Again, we're looking at the user mode and the kennel mode, right? So we already know that from an operating system perspective. The user mode is where we basically do random standard user activity as well. So you do have user mode drivers and then there's also a concept of ko mode drivers. A driver that is residing within the kernel either needs to be signed by Microsoft in most cases or you need to also have like some sort of PKI public key infrastructure where you can also um have signed stuff running within the

context of the ko mode itself. So let's look at an example right what would an attacker do from a vulnerable driver perspective. So the first step is they always t target you know our users right we always say human beings are the weakest link in our organizations and we see it even with vulnerable drivers so the initial part is that initial access compromise credentials credential dumping fishing attacks those lowhanging things but ultimately we know that attackers want to do privilege escalation on our endpoints so they find an initial access point also try to find a vector where they do a bit of that privilege privilege escalation and then once they get those privilege privileged um privileges the high privileges

they'll basically do a driver installation. So again Microsoft are great but sometimes the model doesn't work because sometimes they do sign things that actually have vulnerabilities in them. So attackers spend a bit of time just looking at hey what is it that Microsoft has signed off to be run on Windows machines that runs with high privileges right and this is where the whole patching game comes into the play but once they identify that vulner vulnerable driver they'll install it since they've got high privileges from step two and then they'll use it they'll see hey what rights does this vulnerable driver have can it fully uninstall stuff on the endpoint or can it actually modify certain kernel

structures so certain drivers are very powerful vulnerb vulnerable drivers, they'll fully and totally uninstall the EDR or actually they'll play around with those structures and ultimately you want to disable the security controls. Make sense? Okay. Okay. So, just a few examples, real life examples. How many are familiar with Netto lock shields? How many have played Netto lock shields? Okay. At least half you've played in lock shields. I love lock shields. If you haven't, try and see if you can play in your team. I know the Netherlands takes part in lock shields as well. We've supported lock shields for the past four years, I think. Yeah, about four years. We saw this last year. One of the teams were

supporting during lock shields. So, for those of you that don't know what lock shields is, um NATO member countries have got um this cyber security exercise, arguably the biggest cyber defense exercise in the world where they just train member countries to defend your critical infrastructure. So, usually it's red team versus blue team. It's a sim it's real systems but it's not production systems right so we've taken part and what we saw last year and this happens in real life as well we get calls every day as elastic attackers were trying to do evasion of our EDR one of the ways that they try to do this is you can see all the smileies at least

they were nice enough it's nothing very disturbing no yeah at least it was just fire icons but they did log poisoning right and they tried to basically stop the telemetry collection of the agent itself. So when we saw this in the exercise um it was a bit worrying and funny as well but you see that red teamers and the guy we we had a chat with the guy that did this. He's a red teamer in real life as well and he said his objective was to actually evade elastic defend. Now you'll meet different red teamers. They're trying to evade other EDR2s as well. But again this is just a real life example of people that are actually trying to do

evasion of EDR2s. There's also another tool that we saw this year in lock shields. It's called edr silencer. How many are familiar with edr silencer? Okay, a few hands in the room. Um this is another hobby project from another red teamer. But basically again what they're just trying to do is that blinding and blocking of telemetry that's being produced by the edr tools as well. So we're seeing a lot of these things coming up is close to home. Um attackers are actually trying to disable your EDR. So what can we do um in terms of avoiding EDR evasion right? So the first one is turn on script block and script logging as well. I know this is

painful in terms of logging what your scripts are doing but we need to do it. So log whatever is happening with your PowerShell log whatever is your VBS scripts are doing in your environment your bash scripts. We need to have a bit of visibility into um what the scripts are doing within our environments because those are huge vectors that attackers are doing. and then apply Microsoft driver block list updates as well. So it's okay for things to be signed by Microsoft but also just monitor for hey does micros Microsoft still trust some of these things to run on our endpoints as well. Really really important. I know it sounds easy on paper but in reality it's

such a very hard thing to do. And then the other thing is monitor your agent heartbeat. We've seen the crucial part that the agent plays in terms of edr. you just always want to make sure that your EDR or your agent is always checking in home, right? So, it's alive and doing what it's expected to do. Um, and then also we saw that ETW and the AMZY, so the anti-malware scanning interface, the one that scans the scripts and also the ETW telemetry can be tempered with. So, you just want to have temper hands as well. Microsoft are really good with telemetry. So if some of these channels have been disabled or these capabilities have been disabled,

there's a way of actually getting event codes that actually um give you a hint into um that activity happening. And then also you want to baseline and monitor low bin usage, right? So we saw that there's certain binaries and services that run on our endpoints that attackers are going for. So similar to the PowerShell logging, you just want to make sure that you're monitoring some of these aspects. I'll not go so much into all these uh parts. The third last one is hunting for read, write and executor locations and remote threads. Um and this is in the context of processes, right? So you just want to make sure that your EDR capability can also uh just basically

monitor what are the threads doing, what are processes doing on the endpoints, are they trying to do certain things in the context of other processes as well. So this is something that a lot of EDR2 tools are doing but just make sure that these capabilities are actually turned on as well. Okay, with that I just want to end it with some recommended reading. This is how many are familiar with this book evading EDR? Matt hand now you're familiar with it. Okay, few hands. If you're interested in this topic, this is a very good book. I think it's arguably the best book I've seen on evading EDR. There's a lot of references about elastic. So I like it even more because

of that because I love elastic. Um and then also the technical review of this book is one of our uh VPs within the endpoint security space as well. Really good book, really nice concepts. I urge you to um read up on it. There's a lot of public writeups on ETW and AMSY and driver abuse and legend tempering as well. And then even if you're using another vendor, please check their threat research and also their community blogs because most of the vendors are actually doing continuous monitoring of what's going on. We have our own SEC elastic security labs as well. There's a lot that we're doing in the EDR evasion space as well. So please have a look at

some of the work that we're doing from that perspective. With that I can say that's all folks. Any questions?

Thank you. Thank you, Marvin. Are there any questions, guys? >> Yeah. >> Okay. All right. No tough questions. Thanks a lot. Thank you. Thank you. >> Oh, was that a question then? Oh, okay. Damn, I thought I got away with it. Oh my god. No tough questions. They're recording. You know, this is going on YouTube. So I'm curious what your opinion is on um an EDR living in or operating in the well user space or kernel space. >> I was I wish I put money on it. I knew that would be the first question. Every time I give this talk that's the question that comes up. Uh so you got the question right? So should we

continue having EDR2s operating in the kennel space or should we let EDR2s operate within the user space? It's a tough one. I personally, this is my personal opinion, um I I think we should continue having EDR2s operating in the kennel space. Uh reason being it's a no-brainer. They it just gives us so much access to easily identify malicious stuff. The user space is such a very unprivileged space. It's not even interesting from an attacker perspective as well, right? Because I mean, yes, user space, less privileges, there's not so much you can do to change and alter the functioning of the endpoint itself. So again attackers if we operate in the user space attackers always find their

way in the kennel space and if you're in the user space and then in the kennel space it it's so hard to monitor you know from a less privileged position monitoring what's so privileged it's like it's a private party and you're not invited but the attackers are invited right so I I do understand the problem now is if we as edr vendors operate in the kennel space then you need to install us with multiple privileges so if we have not so good in terms of our own sanity checking and we're abused. We've seen I think the previous talk or the talk before that the OT talk spoke about you know the npm package compromise that's been happening in the

past few months. So if you're either a vendor and you're using those npm packages there's a supply chain attack and I'm operating in the kennel space of your machines then I'm bringing a risk to your organization as well. So, it's a bit of a it's a tricky situation, but ultimately I think the benefits of of operating in the kennel space outweigh the benefits of EDR being in the user space. >> I share an opinion, but I'm curious why Microsoft >> out of the K. Now, I've been I've been tracking that as well. Um I would say as long as EDR vendors get special treatment even if we operate in the user space I don't care what Microsoft do as

long as they still give us access from the user space to get into the telemetry that we need from the kernel space. If they can also have an interface where they provide what we need in the kennel space in user space great but the problem with that is what's the difference right so there's no difference at the end of the day right because we still need to have that visibility into the kennel space the beauty with what they're trying to do is if we are compromised as an edr um I don't know how they implement this but they're trying to really minimize what we can do in the kennel space I don't I don't know we'll see how it

evolves Microsoft. >> We blame Microsoft. Yes. I know we're recording this, but yes. >> No, I'm just kidding, but yeah. Um, that's just my opinion on it. Very good question, by the way. All right. Any other questions? >> More question. >> Any more? >> I was hoping he doesn't raise his hand. I told him yesterday, no questions from you. Okay. >> Marlin, thank you for the talk. It was really interesting to listen to. Uh my first question is uh I think from my perspective my EDR if I install it should definitely detect any privilege escalation uh exploitations. What's the problem in doing that? So why still we have uh these vectors applicable in real life scenarios? That's a very good

question. I think security is not static. Security is dynamic. Right? And then also one of the things that we tend to usually forget is technology in general is created to create a better experience for the end user. So the focus for me is always going to be innovation before security. And as long as innovation always comes before security, there's always going to be vectors to do things such as privilege escalation. So as edr vendors u we can catch up as much as we can but attackers always find a way in because again tech is a very constantly changing space and I think privilege escalation will continue um even if we have very good protections in that sense.

>> Uh let me let me clarify. So I think that if if we have uh some unprivileged process which spawned um highprivileged process that should be detected detection is yes it will be and this is why I said when you start doing PowerShell logging it usually causes a lot of noise especially if you an environment with a lot of developers because in most times developers also will be operating in the user space legitimately also want to do things in the kernel space using PowerShell. when we look at it from a security perspective, we will get that alert. Hey, there's a user that started PowerShell and it did something in the background that went into a privileged

state. So again, it's usability versus cyber security in that sense, right? And I I don't see that ending. So I think the EDR tools will be able to tag that. But the question is what's the context of that alert? Is it a true positive? Is it a false positive? If it's a developer doing it, then it's a true positive. But again, I mean, it's a yeah, it's a true positive and well, false positive, but it's a legit thing that they're doing. But then also, it could be that another time the attacker does a compromise of the developer and does the very same thing. And that's where it becomes a little bit of a cut and mouse kind of

scenario. It's going to be a tough one. And that's why, yeah, we talked about this at the meetup. Those of you that were there yesterday, there's a lot of context you need to bring into your workflows. Just try to understand, is it a developer? and maybe in real time also just check hey are you the one that actually did this in real time a slack message or a team's message from a soul perspective as well but it's a whole topic on its own but generally speaking I don't see these things stopping anytime soon >> okay thank you uh may I ask another question >> yeah we have time >> do we do we we have time oh

>> uh next question is uh did you have you observed any uh time based attacks like um for example As far as I know, EDR always work with events uh based on or limited by some time frame. So if do you know let's say a way how we can still detect those time based attacks uh except using sandbox because obviously there we can um how to say that uh we can skip those long sleeves delays and so on but can you do that in real time? >> That's a good question. a little bit of a tough question, but uh yeah. Yeah, let me get back to you on that one. From an EDR perspective, it's going

to be a bit tough and that's why for me it's like uh I've met security teams that depend on EDR only. I don't agree with that. I've met security teams that depend on CM only or analytic platforms only. I don't agree with that. I think the two complement themselves. And the reason why I like that is the EDR is going to do on endpoint prevention and stop things before they actually achieve their objective. But you still need that telemetry that I talked about ending in your analytic platform cuz that's where now you can build nice detections that are able to detect things such as that cuz most telemetry also comes with timestamps, right? the original time

stamp on the endpoint itself, timestamps on when you picked up the telemetry in your analytic platform. And it just allows you to still establish sort of an after the-act kind of approach. So if the EDR is not able to detect the time based attacks, I don't know if Elastic does that. I need to check. But again, if you're collecting the telemetry, I always think it's easy to create the detections that can detect for those scenarios. >> Thank you. >> Thanks for the question. >> Thanks again for the talk. It was amazing. >> Thank you very much. >> Please give him a round of applause.

Thank you so much. >> All right. Thank you very much. Thank you.

Thank you very much.

I will put a timer just in case.

Well done.

>> Oh, I thought you presenting the other All right.

I don't know what

Hello. No no no.

Hell yeah.

You know what?

>> Yeah. Uh, one second. I'll see you soon.

All right. Uh, so the last talk but definitely not least. So we have Newer here on the stage and he's going to talk about detect and defend against business logic attacks in APIs. >> Hello. >> Yeah. Hello. >> Hi everyone. Uh, welcome. Uh, this is the last talk of the tech track. I hope you are not too tired. I'll try to make this as interesting as possible. Um, so today we're going to talk about abusing the rules. Uh, finding business logic attacks. Uh, but I kind of focused on uh our latest research which is about vioded applications. Um, so welcome. Oh Oh well, why did it okay? The clicker is not on my side. So, uh, my

name is Noi. I'm a research and development engineer at Escape. Um I lead the ASM project and uh basically my job is to automate discovery and pentesting. Uh I'm kind of at scale nerd. So I love to take stuff and running at a large scale like internet scale and I do open source too. Um oh wow the clicker is really buggy. Uh sorry for that. Okay so what's escape? Escape is an automated uh pen testing platform and we do uh everything from discovery to security testing and we try to automate uh this process. Okay. So at escape we have a habit of uh pres uh doing research on exposed applications. We've published several reports. Today we are going to focus on

the state of uh security of vcoded applications. Uh you can read the full report here. I will of course not have time to present everything in the report. So this will be like a synthetic view of that. Uh but there it is. The clicker is really buggy. Um so first little introduction what is vip coding and how did we get to like from LLMs to vibe coding. Um so as you all know there has been like a big rise in uh adoption of LMS to generate code around 2023 uh with just like plain chatgbt or like tools in your browser where you were like outside of your ID you will just like prompt the LLM and then copy paste

the code and run it wherever you want. Then we started to see some tools appearing inside of the ids. The first one being GitHub copilot and then some more advanced tools like cursor or clude code which run directly close to your code. And this created a trend which is called like five coding which is um you just prompt the agent you never touch the code and you let the AI do everything on its own. uh and now we see a shift to full AI platforms like Lovable or B4 uh which brings it back out of the IDE and the idea is that you just have a chat interface but the platform will uh deploy the code for you. We'll deploy

the front end the back end uh set up everything the infrastructure you need and basically just generate uh your application. So little question to the audience. How many of you do use LLMs or AI in your day-to-day job? Yeah, basically almost everyone. And is it to code? Who does use it to code? Yeah, a lot of people do. Uh so you probably have the same gut feeling as I do. Uh the LMS they create weird results, bugs, hallucinations. Um and they do even when you supervise them. So probably fully AI generated code might be worse. Um also those platforms they lead to unreviewed code. It's completely obscure. You never see the code you are running and it's also

created by less technical people. The the full appeal of those platforms is to bring everyone to develop code. Like probably some of you have experienced your CTO by coding something like hey I have the next billion dollar app. Let's just ship it to prod and it's connected to your database and you're basically screwed. Um and those platforms uh what changed is that they can now generate the front end. This is kind of old but now they also generate your back end and your database. Um and this database and this infrastructure that it generates can handle sensitive data etc. So might be a problem that the AI is the only one in control. So we wondered there might be

some security issues there. Uh and we wanted to test that. Oh wow. Yeah. Uh on top of that uh there is a first catalyst which is there is a clear increase in API services uh count and complexity in companies in general. Uh our previous re research identified that there is on average about 15,000 API endpoints per organization which is like that many uh entry points to your code and that many entry points for potential vulnerabilities. Also we found some extreme cases of organization having like 3,000 API services uh for a single organization multiplied by thousands of endpoints very large surface. Uh the second one oh okay uh sorry the second one is there is also an increase in attacks on

those APIs. uh this is a report by Kong and they basically forecasted that by the end of the decade there will be a thousand% increase in API attacks. So if we combine all of that so our gut feeling and those catalysts we kind of get an explosive cocktail. Uh the companies they have more APIs and endpoints that they can track. uh those APIs they are more diverse and complex than ever and there is an increase in attacks and boom v coding on top of that there is no more human in the loop uh what could go wrong and so that's what we wanted to test so we started trying to pentest those vipoded applications so

first we have to discover them how do how do we build a data sets of such applications we needed a source uh our first source was lovable launched It's like a kind of um dashboard know like rankings of vipoded applications where you can submit stuff that you made on the platform. So very easy to scrape uh good source of lots of applications. We combine that to other sources. We identified some fingerprints in the JS code that those uh frameworks like applications will inject in your JS code. So you are we are able to take that. We also enumerated the subdomains on which they deploy the applications and other techniques. And so in the end after filtering a bit, we get 5,000 base

targets to pentest. Uh we fed those 5,000 targets into the escape attack surface management um to perform even more discovery and security testing at scale. Basically uh this platform works as the following. We take assets which can be like of very various types. uh what interest us today are mostly host API services and web applications. We run that through scanners which can be of v various types too. So either ASM to do discovery or some DA or business logic security testing to find vulnerabilities and those scanners will output assets so discovery and this creates a feedback loop and we can put those asect back into the scanners etc etc expanding the attack surface and it

will report some vulnerabilities. Um let's take a look into one of those scanners which is the main one that we used in this research. It's our uh web application test um because those were mostly web applications. So basically how it works is that you get you take the application you start a browser you go to the application you crawl it uh with like some AI or different techniques to get into all the possible path and then we perform some injections and security checks uh to find issues. While we are doing that, we hook into the browser. So we are able to get all the JS sources of the web the the application and we also hook to every

network call and from that we are able to run some passive checks uh to detect eventual secrets of personal information and uh we also are able to extract the APIs that those front ends use and uh to reconstruct the schemas from the runtime uh requests and we also associate that to the authentication like we can extract the cookies or the the JWT session or whatever. So, uh after running that, oh yeah, we quickly discovered that um Lovable uses Superbase as default to generate their backends. Um for those who are not aware, Superbase is basically just a posgress as a service. Um and what they do is basically they generate your front end and then they call um Superbase via

their LLMs and agents to configure your database and your API that is uh built on top of the database and they configure everything for you like the schema u the role level security which is what you use uh in superbase to control which tables or objects are accessible on or exposed in the rest API and um this raised some concerns to because because generating uh your schema from an agent is probably a bad idea. generating the access control is probably a bad idea too. And having used superbase myself from small some small projects, uh the RLS is easy to mess. Uh even if you are experienced and you know what you do, it's easy to just miss

something and expose a table that you don't want to expose. And there has been a reported CVE on that which was that lovable was basically setting up the database with like everything is accessible first and then trying to buy to like control um blacklist some of the tables which is like not what you should do. You should do the opposite of course. Uh so we'll try to see if we can identify this CV. Did they fix it? They told that they kind of fixed it but you'll see. Um so from this discovery we started with about 5,000 targets. We discovered 15,000 assets in total and out of which we extracted about 1.5 web apps that we want to pentest and about

500 superbase APIs. Uh I'll just explain why we filter those and how did we do that. Um basically uh for the front end a lot of those were just like either landing page or broken or authenticated. Authenticated sometimes it was even just like join a waiting list or something like very we could not register. Um and so a lot of broken apps too like viped applications were really broken just like websites you go to the website it's just like 500 or you click on a button it doesn't work it just crashes the website. Lots of broken applications. Same for the the APIs. Uh we focused on the superb basease APIs. So we removed the rest and we had a lot of dead APIs

or broken APIs. So we focused on the green parts there. Then okay now that we have those targets how do we assess the business logic security testing of those backends and those APIs. Um let me explain a bit how we do that at escape. Um so this is the full scheme. We start with the lovable for a quick recap. We run it through the ASM scanner, the scanner that I presented and some other scanners to find some metadata stuff that could interest us. And from that we extract the superbase API and the JWT that is needed to connect to it that is usually hardcoded in the JS files and uh we construct the schema for it and then we

are able to fit it in our uh security testing scanner. Um how do we do this testing? Basically our scanner it takes uh an exposed service and a schema. Then we run our uh technology to find business logic flows and leaking data or uh secrets. Uh let me explain how this works and why it's hard to actually assess the business logic of applications. When you try to automate pentesting of APIs, you face two main problems. The the main one is that if you just randomly fuzz or you just try to brute force the API, you will not ever be able to get past the validation layer or very unlikely. You will just send requests and it will get rejected if the

application is correct um because you do not know what to send to the API. Um and that caused most of your request to be blocked and so you end up not testing the application itself or the business logic. just test the network layer and the validation layer which is not interesting and which is where a lot of dust tool fails. Um our solution for that it's a bit of a buzz word but sorry we use uh AIdriven semantic API exploration basically that means that we are able to quickly learn from the API and we are able to craft payload that will get through the validation layout to identify which of those payloads work and then reuse them uh to build

exploits. I will come back to that later. The second problem is that even if you are able to get past um this validation layer, it's basically impossible to explore every possible combination in the API. Like this is a classic problem uh when you try to break something. So what we do for that is we use reinforcement learning to build uh basically a tree of possible outcomes we are searching for in the API and we prune the branches that we are not interesting in. Um let's take a quick example on how we do that. It's very simplified but so you get the idea. Uh let's take a graphql mutation. I took graphql because it's just easier to represent than rest but

basically it's the same. Uh we have um imagine like a hotel room booking system. We have a mutation that is book room. You should pass it like a hotel ID which is an integer room type which is a string and a guest email which is a string too. The naive approach very naive approach would be to just generate random stuff and send it to the API. Of course, this will like never ever get to any code path if your API is not completely stupid. Um we send like one to three for the hotel ID random string random string. This only respects the schema like the primitive types but not the intended logic that you should send

to the API. So what we do here is we combine what I mentioned before and we basically use previous responses like imagine we have a query list hotels we are able to extract stuff from that from that like for instance the room type which is like an enm and we will reject it the ID2 we will list it reject it and the email which we might have created from some register root or login or whatever and then with this request we are able to actually craft a valid payload and get deep into the code path. Uh once we are able to do this, we basically just export the API, map all the possibilities, print the stuff that

is not interesting and then build chain of attacks. So basically here very simple chain uh we register then we take the email we could take the hotel ID room type from what I presented before inject the guest email and then boom we modify the request that was uh legitimate and successful and just try to inject stuff in this legitimate request which is much more likely to get uh deep into the API and actually find stuff. Um so the benefits of using that is that with a naive approach to dust you just basically test the network layer or the headers or whatever and you will have issues like hey some control security header is missing which is not very

valuable still why not but it's not what you want to test when you have pentesters. Um with this approach you are able to test very complex business logic flows such as like tenant isolation. You create two accounts. You check okay yes I'm able to create this resource. Can I access it from the account B? Uh can I modify it from the account B? If it was created from the accounts A etc etc. Um so if you want to learn more we have an article on that too. It's very hard to explain it all in just uh a few words but this was a very simplified version of it. Of course, it's much more complex and you can read that if you're

interested. So, the interesting part, what did we find? Uh, enough words. Let's go to the results of the findings. Just a little disclaimer, as I mentioned, uh, a lot of those applications were broken or untestable. Uh, yeah, 500 applications are really broken. You can trust me on that. Um, a lot of those were behind authentication. We are trying to automate authentication right now. We ran it a bit but just on a tiny portion of it. It's really hard to scale. Um, and also we run all of our scanners in a surface or production mode which means we made them as harmless as possible not to break stuff on the internet for people that did not that

did not ask us to. Uh, so we disabled a lot of checks like very hard injections etc. And we disabled state altering operations like post like delete user or stuff like that. But we still found quite a lot of stuff, quite a lot of nasty stuff. Around 35,000 vulnerabilities, uh, of which we identified 100 as critical and manually reviewed the critical and high ones, 2,000 high impact ones and a lot of secret leaks and personal data leaks too. Let me go a bit more in depth. Uh for the vulnerabilities we on the high ones we had SSRF zero click account takeover uh about 250 dependencies vulnerable uh with CVE. Um we reconfirmed the CV that I mentioned

earlier. So they did not fix it. Um and uh we also confirmed a lot of broken access. Uh some file closure. This was pretty weird because some people actually they generate this was really interesting to to find some people they will generate it but not deploy it on the bubble file because it's you have to pay. So they will just we like whack the code in their like home laptop and serve it on the internet so you can access like the git repository or stuff like that just like leaking stuff on the computer and uh a lot of misconfigured uh permission or broken access control which came from the RLS that I mentioned before. So our guess was pretty good to

say that this was probably very vulnerable. Uh in the secrets we identified GitHub tokens um a lot of OpenAI API keys too because they love to build LLM wrappers but who needs a back end when you can hardcode the key in the front end. It's so much easier. Uh so yeah they just like throw the API key in the front end make calls directly to CHGPT and ta you have a wrapper. Uh we also found some admin payments API tokens that were uh actually active. One of which was a stripe token and a lot of like passwords, JWT, blah blah blah. Um for the PII, we found medical records, ibands, phone numbers, uh emails, the

whole package. Um let's deep dive in a few of those vulnerabilities. Uh the first of which uh it was an application that leaked all of the uh GitHub application tokens. So you can basically steal the GitHub apps which can be very problematic. And this is related to the C CVE that as I was mentioning it uses the same vector. Um which is basically just you bypass the whole level security by just passing you a select that is select everything in the table and tada. Um this one is a very nasty one. Uh it was a medical platform like connecting doctors to patients and with a certain chain of requests you were able to leak all of the doctor's info containing uh

the full name, the birth date, the phone number, the license number which is like a medical license number. Uh the bank Ian, the email, the password which is clear of course and uh you can see that this guy is a clinic. Uh this one was really really scary. And uh last one is zero click account takeover of basically every active session on the website. Uh so you are able just to dump the all the sessions of the users and you can just take the tokens. I didn't like impersonate someone and do whatever you want including the admin accounts of course. Um yeah. So to conclude um a lot can go wrong when you v code your front end but

a lot more can go wrong when you v code your back end and your database so please don't do it um some mitigation strategies this is very enterprise focused but first uh try to have a continuous mapping of your attack surface whether it's APIs but not only like your web applications or whatever uh either do it internally that's the best way just like map everything right from your code or if you cannot do that because you are a large enterprise you have a lot of teams just use some tool escape does that but a lot of applications does that too um do some continuous pen testing on it uh manual pen testing is amazing I

always say that like no tool escape or any other tool will ever replace that but it's a very nice addition to just be able to start a scan right when you deploy your code like from your CI/CD uh and to just get all the low hanging fruits and make sure not to deploy something too vulnerable on the internet. So do that. Um third uh try to apply some security by design. Uh this is everywhere too. It's a bit of a buzz word too but the shiftcliff security to try to just communicate with the developers uh to inform them about security to think about security right into the like prototyping phase or development phases. And last um please

if you do use AI to generate your code I do too. It's great. It saves a ton of time, but review the code and do not vibe code like your access control layer or your database schema. I beg you. So, thank you. Um, I hope you like the talk. You can give feedback with this QR code and if you have any question, I'll be happy to answer. >> Thank you. Thank you so much. We only have time for one quick question.

Uh thanks for the session. Um you said that you gathered some targets from the internet. I'm just wondering about the legality and if you faced any issues because you didn't like that. >> As said the previous speaker I should have bet on this question. It's always the first question of course. Uh so basically TLDDR yes it's legal if as long as you disclose the stuff and you are not using what you find in like malicious ways. It also depends on the country where you perform that. But yes, this was done in a legal environment. Uh and no, we did not face um any issue. Uh the platform themselves, they probably didn't notice because it's just not that

much traffic. We tried to make it like not so aggressive. As I mentioned, we try to send as few requests as possible both for not destroying stuff and being fast and scalable. Uh this is like the full thing of scaling stuff to scan. Um and we disclose vulnerabilities but most of those company they never reply because you know if you just v code your application you won't ever just have an email to some of them reply but yeah most of them do not and don't care and a lot of applications were actually already pawned or pawned after that and tokens were like revoked or yeah thank you. All right, let's give Noah a round of

applause then. Thank you for attending the talks here and please um go to the next room for the closing ceremony.

I can bet on the first question. Next

up,

you're never asleep. life of the Nautica.