Threat Hunting at Different Scales: Lessons Learned from Practice

Okay, so lunch is over. Hope you all had a good meal. Not too good so not to fall asleep uh during the next lectures, but I'm sure you won't on this one. It's going to be exciting hopefully. Uh so we were talking about incidents earlier. How detection triage? How do we triage something which alerts us by why [snorts] start there? Why start when incidents already happen? Why not look for incidents? Well, our next speaker will actually talk about hunting for threats. So he used to work for an MSP so for modeling cyber and now he's using that knowledge to thread hunt in his new company. So please welcome uh Philip Raayage. [applause]

Uh hello everyone. Uh thank you very much for such warm welcome. Uh I hope uh you're ready for this presentation. uh I decided to choose this topic as it's uh quite interesting when you step up step up from small organizations to enterprise environments and everything in between. Uh what are the challenges that arise uh dur during uh searches and how to adapt your mindset to uh to those environments. Uh initial idea was that uh I would have one specific technical example but unfortunately I can't use it. Uh, so I had to uh change it to a little bit more. Um, is it just a second? Oops. One too many minute. Okay. Uh, but I had

to change it. So today I will talk a little bit more about mindset and how to adapt to the environment you're searching for. So uh I'm currently working as a detection instant response uh member at Miran Technologies uh which is a company based in US primarily focusing on manufacturing researching uh radiation medical uh and medical procedures and uh detectors for nuclear power plants. Uh currently I have a little bit over seven years of experience in defensive uh roles uh which varied from malware analysis, reverse engineering, instant response detection engine detection engineering and much more. So I g this experience through MSP uh which proved quite useful uh in my current role. So have you been

hunting lately? I don't know how many of you do thread hunts and uh do you do it once a week, once a month, once a year or do you have some specific schedule or you I don't know you you have hour or two or free time and you decide to just give it in and see what you can find. How often does it turn into ad hoc quering? So you don't have any specific uh hypothesis that you're trying to find to discover and you just start it and you just start to write query type for example I want to see if some cmd has been uh executed powershell uh network connections and so on which won't give

you any specific depth where do you get stuck I know there is a typo I forgot to uh change it so don't mind it uh so where do you get stuck do you find yourself that you don't know what's the next step you want to search for. Uh do you have enough information? Do you understand the context of what you're searching for? This is uh one of the most common pitfalls when you do thread hunting. And lastly, did you meet your expectations? This one has proved to me as one of >> [snorts] >> um more on the motivational side. If for instance if you're doing thread hunting you don't find anything or you're not meeting your expectations with the time

your will to do thread hunting will steadily decline in and in the end you will just do it for the sake of doing it. So let's start from the beginning. Uh when we start thread hunting uh first thing that we need to have is hypothesis. So we need to specifically define what do we want to search for. After that comes writing queries. You know, if you know what's a lot about the environment, you write a query one, two, three or more depending on what you're specifically searching for and then you run it. You open your CM, you open your XDR, open whichever tool you're using and you just press, you copy paste it, press run and magic happens. Computer

does its uh its magic and you find something and you're happy. But there is also possibility that you don't find anything and then most likely you'll be disappointed because you spent hours doing something and which comes to the last point from the previous slide. It is uh about expectations. Uh this is the one simple sentence that uh I tend to use when I do thread hunting that expectations are root of the disappointment. By this I don't mean that uh you know you have to uh look for the best but prepare for the worst not that extreme but you need to be uh aware of uh what your findings might might be or might not be. So the reality results

varies sometimes you find something you don't but unfortunately the truth about thread hunting is that most hunts fail even before they have started. I mean you can do your thread hunt set but there there are couple of things that you need to take in consideration. First of all when you define hypothesis you perhaps were not specific enough. You did not use any constraints or conditions just to narrow down the field and you might end up with open-ended uh results. You have imperfect data that's everywhere situation. I haven't seen any environment which this is not uh true but this I mean you have logs right uh you inest you inest that in CM in any other solution and what what what tends

to happen is that it's not parsed properly you have one full name here another full name there or you just have raw data which you can't use properly as perhaps text search is not uh working as it should be you have partial visibility this adjacent a little bit to this pre one previous one when you're thread hunting and let's say you use some tools which are let's say something in the way of lens sweeper that you need to define some devices into network and gather more information about it what what about situation if lenser can't access those uh those devices or those devices can't lock send locks to your CM you will have a blind spot and you might

don't know what to do Next, there are also different operational constraints. These are a little bit different as they are real world uh things that you can't influence such as if the CM is working properly if uh it's west enough if you have a lot of work. I mean tasks can jump in at any second and you might stop doing what you're doing. So this is also that has to be taken into the account. And of course time pressure. Everyone wants everything quick and fast but this doesn't work in that way. So time pressure is something that everyone feels because we all all have 24 24 hours a day eight hours of job and you

have a lot of work to do and just to fit a thread hunting in it's quite the challenge and lastly complexity of the environment. So environments may vary from small environments where you have 50 devices to 10,000 plus devices with thousands of users uh cloud uh cloud uh dependency and so on. So you need to know the context of what you are uh looking at. So basically what changes as organizations grows first of all data volume for instance you have small environment 100 users 50 PCs some servers you will have enough data to go go through to search for something but it won't be uh as much but on the other hand if you look at some enterprise

environment what you will find is that the amount of data you to get in a day in a small environment is like five minutes in the big uh identity surface identities are today everything uh especially if you're looking at small organization and the big one uh number will just rise because the sheer number of people uh rule uh access rules uh and all other possibilities that might might uh might trigger identity and ownership boundaries small environment everyone knows who who owns everything. So you know uh which server is owned by who. While in the let's say enterprise environment it's not as simple because you have a lot of people a lot of organizational structures and uh it will

take a couple of steps and of course context availability. Uh context is something that uh helps you uh understand not only what organization is doing but whether the process of what you're searching for is adequate. you won't search for, I don't know, uh network connections uh from uh some uh airgapped environment to the internet. I mean, yes, you can, but I'm certain that you will have some detection rule that will detect that. So, you need to adjust your uh thread hunting set to a specific uh area. And of course, speed of feedback. Uh if you're in a small environment, you can just take your phone, hey, listen, we found this uh can you confirm that this is legit or not?

and they will tell you because they know they're doing that. While in the bigger organization, this gets more complex because you don't know the whole structure, all organizational units and sometimes in the worst case scenario, you have to submit a ticket which will then bounce around for a day or two and it will just waste your precious time. So some small environments, lower number of devices, we know what's going on. uh we know the users uh we know uh who who we can ask for something specific uh just to get the better context of it. Informal communication. This one is has to be one of my most favorite things because uh when I work like that it was

the easiest thing to call someone and tell tell them okay listen we'll open a ticket a little bit later. Let me just uh confirm whether this is legitimate or not. foster context you don't have so much information to uh to go through to understand what's going on because every organization is different complexity is different and uh and here we can easily go through uh everything and as you don't have that many endpoints you don't have so much telemetry to go through your sim will work properly you will have enough time to process data even though if you if you're looking for 6 months period of time which might be a little bit troublesome in bigger

organizations. So now we have growing medium-sized environments. So first thing number of devices grow number of users grows people get employed you need to have some sort of uh identity management you need to have access rules for some specific groups for instance I might not need access to I don't know uh HR internal software which where they hel where where they have all the employees information but only to uh access to the CM to some uh let's say portals you know defender consoles whatever ever then we have emerging emerging organizational sales. So I don't know if you've heard about this but basically these are uh departments inside the organization. So you have marketing, you have HR, you have security, you have it

and all of those become identity for their their own and to get information from them you you need a good point of contact. you need to have uh a good communication with them with them and just basically uh be be on good terms with them. Uh next next thing we have tool sprawl. So number of tools that are used inside organization rapidly grows uh and especially when the organization is developing you you will find yourself in a situation where one user is using I don't know uh visual studio code the other one is using uh uh jet brains or whatever other uh ID can be and they're basically doing the same thing for example for same programming language

but the issue with that is someone doesn't like the interface of the another or things that resources might be uh overwhelming. So this this this is where things tend to get uh complicated and of course partial logging as number of systems grows uh if you don't have policy about uh logging uh in uh agent installation which pull logs you might find yourself uh where you don't have that agent on all devices and basically uh you will have blind spots. And now we come to the best part actually enterprise environments which uh for which I thought it was way too complex uh and in reality it is but the great thing about is the possibilities that

you have. So first of all complexity grows exponentially. I mean if you have 10,000 users I don't know how many thousand thousands of devices uh you can basically take a finger you know like you roll the globe and just point at something you might find it because the the just the pure amount of data it's uh it's astonishing uh identity spraws well of course we know all about steering models and uh importance of that. So in these type of organizations you might find yourself that you have five six or seven accounts which are special with special access to some uh part of organization. You won't have the same account to go through every to to everything but uh that will

a little bit in in a way it will make your hunting a little bit easier but also a little bit harder because you need to look all the activities from the very same user. Uh cross boundary trust. Well, if you're having some devices that are purely on on premise, if you have hybrid, if you have cloud solution, you know, a AWS and Azure, basically communicating together, you need to know what are normal things and uh what what is expected to happen and what uh might be the issue. And of course fragmented ownership uh which is uh a little bit tricky because you never know who's the fully uh owner of some specific I don't know host or service or uh some testing

environment and telemetry overload. This is usually thing at the end environments but it can also happen in smaller because if you don't uh set uh configurations uh for log collecting you might end up with a thousands of well thousand millions of logs of which are just noise which don't mean anything like status info okay I mean that you won't collect that because uh it's just useless so and that tends to happen in this kind of environments So when we're looking at uh the thread hunting uh on these different scales, things change and I I use three extremely simple examples just to show you how to do how what does it mean? So uh these are following at first

uh we have some detection on one server uh which is let's say fileshare uh and someone has access it and in small environment what will happen uh you're searching for that and okay I found connection to that someone some user has connected has copied some files uh and I'll be like yeah I'll take my phone call hey listen is this normal for this user or call that very user Hey, did you do that? In enterprise, it might be unclear. You have the user, but you need to find the context of that uh user. Is he someone who actually works in the department that is using that fileshare? Does he have the right to use the data

to copy it, to modify it or anything else? So, at first it's unclear, but it takes time to unravel it. Uh next one let's say we have a service account uh which does something 12 times a day. No like every two hours. Uh and let's say that for we have noticed that every day at 2 p.m. it just launches 15 minutes or 10 minutes later than usual. So in smaller environments is it's easier to to determine whether this is something malicious or not because it can be some sort of uh I don't know network uh overload because some backup is going through. It might be actually something malicious that some actor has uh made some configuration and in enterprise

it's hard to baseline especially if you have uh if you have work all over the uh actually offices all over the all over the world because lat because for example oops uh because for example uh we had some situation in Japan for uh one service account and it turned out it was just basically nothing malicious. ious but uh it was something worth investigating while in the let's say US it's usual activity and is it easy to trace the identity well in small environments it's straightforward you have limited amount uh limited number of users you know exactly who works where and uh how to get to them in the enterprise it's complex you have daily people who are

arriving who are leaving you don't know which device has been wiped has been freshly installed uh where does that user live Does he travel a lot? Uh perhaps uh you have someone who likes to let's say he's from US and likes to uh go to travel to I don't know let's say Asia and he's in Japan works from there connects to VPN. Is it normal? Is it not? It it gets complex here and that's basically the gist of it to know that everything can be adapted to but not in the easiest way uh possible. So now we have different environments but same approach. If you're doing thread hunting hypothesis is good written hypothesis is must because you will find yourself

looking for something and just looking for it and it will last and it will last for days. Right? So [sighs and gasps] this is another sentence that I like to use uh about thread hunting that it is uh search space reduction under constraints. What does it mean? I don't know if any of you have used this formal term or not but space uh space reduction actually space search uh those are different entities inside your organizations which you can use uh in order to help yourself to find something uh that you're looking for. For instance, let's let's do just a quick hypothesis, right? So we have identities. Identities are everywhere. you know everyone has when uh in in the

organization let's say we want to check if administrators are doing something administrator accounts are doing something suspicious so let's say we'll take it um I don't know uh everyone who has access to execute to connect and to execute some uh sort of files on different machines next one okay so we have administrators next one let's say we want to check if those administrator accounts have connected to servers or better better yet to uh workstations of uh people who work in finance. Okay. So we narrow down the scope and let's say time time is you know it can be 5 days, 5 minutes, 6 months, a year depending on uh your log capability but let's for the

sake of this case let's say last week. So we will also narrow it down. We we already have hosts, we already have who are we searching for, what are we searching for, where are we searching for actions. So we can also add this layer to say okay let's see if someone has opened a file or someone has copied a file or deleted something. So there is a lot of possibility to uh to improve that and of course context. some administrator might log into that uh workstation and let's say he deleted something and it turns out it's not malicious because someone has broken files, broken links or something an administrator had to step in just to

clear it up. So it might be malicious, it might not, but you have a possibility to narrow it down as much as possible to help yourself find if something is right or wrong. And basically what we'll be looking for are signals. I will cover signals a little bit later. So when you're scaling up your research uh actually organization size what thinking scales up perfectly. You know you can always adjust yourself. Uh for instance you want to think okay I have limited number of devices. I have a little bit more but I can make a little bit better constraints. Structural reasoning is the good one because you allow yourself to you know to as we mentioned before

you're making structure you you're making logical decisions you know how to uh process all this information and when you need to talk with someone together additional information it's easy to uh communicate especially if you have some sort of communication matrix because if you have to use ticketing systems to get to the person who is responsible for something it's it's not as uh good as submitting. And lastly, you have freedom to search and be creative. So when you have smaller number of devices, you have you can search for some specific things. But when you have uh some larger environment, especially enterprise, it's just playground. You can pick anything and just go nuts with it. You search for

whatever you want. And that's the one of the best things that I like regarding this topic. So, but also there are things that are not so good uh while scaling up. I at the start I mentioned ad hoc queries right everyone tends to do them. I I used to do them. I still do them. Uh it's nothing embarrassing but they do not scale well because the larger organization the more results you you will have especially if the query is not properly written and uh search space reducted. If you're using single tool [sighs] for instance you pref prefer some XDR console over let's say CM uh you will find yourself that that XR console might not have the access to the sites that

you want to devices that you you you're looking for and uh it will just waste your time without uh possibility of taking everything again back and uh I'm also guilty of this one so context switching so you want to search for something and then during thread hunting, oh this this is shiny. I'll just start looking for this and you just end up going all over the place without any real results and you will just find yourself wasting time and you will be in the end you will be disappointed because you didn't find anything and open-ended hypothesis uh I mean if you don't define well let's say that we for that administrator account connecting to uh

finance uh workstation uh if we ended up there we would have enormous amount of logs well maybe not enormous but we'll have a lot of logs to go through and we will just have a lot of noise of forest which you can go through and which will just slow you down and you won't find anything and [sighs] after all of this when to stop a hunt this is also uh really really important when you when we when we talk in context of time when we reach the defined hypothesis so we have as for per previous example we have found out that someone has been connected uh and it turned out to be malicious. We know

what's our next step. We have reached our hypothesis. We put a check mark. Uncertainty is reduced. So this one is a little bit more tricky because when you're searching for something uh you will know that well you have a hunch that something's going on but you can't prove it and you decide to go through all of the logs that you have and uh just the amount of uh data you'll go through is enormous and in the end you won't have exact solution. Is it something malicious? Does it exist or it doesn't? But you will have uh uncertainty reduced. So you will know that something might be happening but you let's say you don't have enough enough information or

logs uh to support your uh hypothesis. Uh you will be okay I know that this is certainly not happening but this smaller part uh might still be uh in question to for [snorts] searching. So you uh reduce it and you know what your next step is where is it to improve data logging or uh some other improvements. Exit condition reached. Uh this is this this one I called uh uh went through loop like you will go through logs and uh search for something constantly rotating through one another and you'll find yourself back at the start and you think okay I'll try something different but you end up on the same result and you need to know when to cut your losses

right because you will just go in circles without reaching uh anything uh uh exactly expanding the search. This one uh took a lot of time for me because I started hypothesis went down didn't find anything but I was eager to find anything and um you know let's just spread a little bit more uh the scope of the search and then a little little bit more and basically you end up with bunch of logs that means nothing and uh you're again disappointed and of course out of time it's self-explanatory. I mean, everyone has a lot of tasks to do and when you're doing thread hunting, it's often not priority. So, when something comes in, you always take that.

Uh, now, okay, we have defined everything. We have defined hypothesis, we have defined uh ending uh we know what uh we are looking for. So, but exactly what are we searching for? Those are signals as I mentioned on several slides before. So signals are basically logs which will tell you if something is happening or not. So strong signals are clear malicious intent. You know someone opened malicious email uh downloaded malicious file ran it and infected the uh the PC. It's high confidence indicator. You know if it happens it happens. You know it's malicious. There is no ambiguity about it. and uh you you you know what what are your next steps. Uh and they are

rare and loud. So it's kind of easy to to find out about them. And now weak signals. Weak signals are well really interesting to find uh because they represent slightly unusual behaviors as it mentioned that service account which might be drifting for 10 15 minutes at one point of the day. uh but it might not be malicious. Uh here comes in the context if it's dependent you know for in so if the network has been uh clogged some uh tasks might not might not go through and that's the reason why it uh why it uh wasn't detected and it's pattern based. It doesn't have to be one specific event. It can be many events through a day, through a month, through

a year, throughout any any uh type of constraint that you decide to. Uh this one is uh is not based on uh some specific uh information data that I have found but this is just general representation of complexity uh of threat hunting. So the blue line shows so from small organization to enterprise level complexity rises. You will have a lot of more data, a lot of more identities to go through and the red line is uh signal uh ratio to noise. So in smaller environments you will have a lot more signals that you can detect uh because the sheer amount of logs that you have. So you won't have many and as the organization rises uh grows expands

uh you will find yourself with a lot of noise with a lot of questionable data and uh generally those uh weak signals are even harder harder to find. So why strong signals scale better? I mean this is basically true because they're easier to automate. you know if you're having uh you can easily make detection rule you can uh if you have some indicators you can uh apply them to your system which will be later detected uh you know what they're supposed to do for instance if you're having uh someone who who has failed log into some uh service number of times in a short period of time it's a clear indicator it's it's a clear signal that

something malicious is uh going on low ambiguity you know what That's for what it's used for. Uh if it's malicious, if it's not and you you have clear ownership as I [clears throat] mentioned that uh user who downloaded uh some executable from email ran it, you have a clear uh steps who did what and we signals are harder to track. So this single small drift from baseline is uh quite hard to detect especially as organization grows. Uh usual activities are let's say baseline but without proper logging and understanding the context of the environment you will get lost uh with this one. uh so and context uh is fragmented you have many organizational units uh as I mentioned

someone is from marketing HR finance uh developers developers can have production environments testing environment so there is a lot of possibilities and information that you have together uh logs can be inconsistent some might not be parsed well some might be some which you should collect you might not collect And that's something that you will find out through hunting. And noise [snorts] is growing rapidly. There is uh the amount of data that can that should be possible to reduce but it isn't uh is enormous. Uh especially when you have when you work on the enterprise environment and hunting basically lives here. It's a combination of strong signals so which are usually used for detection engineering actualiz detection

and weak signals for hunting. So uh hunting operates where strong signals don't exist yet and this is your search space that you're looking for. You won't often search for some malicious file because most likely your antivirus will detect it or any other security product. But these activities that are kind of suspicious maybe yes maybe not these are one you are looking for and one of common misconception that I hear and heard a lot of is that uh every hunt must produce malicious finding it doesn't if if find something malicious every time uh in the end you will end up turning off the network turning all the servers workstations and everything will be fine right uh if you have more data it doesn't mean

you will get better results it means that most likely you will have more noise which will enable you to search properly and hunting is writing queries well technically it is but it but the difference is that it's structured and with special purpose it's not just render mouse sit down I'll search now for command lines I'll search now for network connections I'll search if someone is playing video games or something And the best one that I had isn't thread hunting just to glorify detection engineering. Well, when I get this question, I often say this uh exploration tolerates uncertainty. Operationalization requires definition. And this is something how I differ the thread hunting from detection engineering. And why is that? When we

have exploration, exploration is investigative. You're researching. You're searching for something that you don't know if it might exist or not. It is open-ended. You don't know uh where you will end up. You will I don't know you might start searching the HR. You will end up in someone's workstation who doesn't have any remote connection to the HR and it is hypothesisdriven. You know exactly what you want to find and you change that every time. While operationalization uh it's formalizing logic. So if you have some let's say it's a result uh if you have some thread hunt which was successful and can be repeated you can create a detection rule and thus you reduce that uh surf space requirement

converting knowledge into repeatable detection as I mentioned and of course you can automate correlation especially if you're using some advanced features which will allow you to uh to to be more productive and of course there is trial and error uh these are the most common things uh which I have uh been myself and uh which cost me a lot of time but uh in the end it uh worked out. So first of all, explicit scope definition. If you don't define it, you will find yourself searching for who knows what. You might end up just go going on and on and on without uh end. Uh you need to [sighs] find you have to have defined end goal. So you

want to find something well actually those can be two things. First one I want to have finding that someone is using command line who shouldn't be using it. And the second one is okay we didn't find anything but we don't have logs which would support that. So basically we're in a win-win situation. You you won't uh you won't feel bad at the end. You need to define exit criteria so you don't go around around the same same things all over again and document negative findings. Uh this is useful in a situation especially if you have a big environment that you're working in uh where you are uh constantly uh bombarded with all sorts of uh data and you basically forgot. I

mean we all have short-term memory and you don't you don't remember what happened yesterday or what you ate 5 days ago. So how could you remember something that happened in the especially in the big environments? So this is something useful to document and uh it will in the future it will pay off. And so some additional ways to improve uh use 9010 approach uh this one was quite interesting for me when I learned it. Uh and what does it mean from 100% so the total amount of time you're using for thread hunting 90% of time used for preparation. If you do that then 10% of time you will do actual threat hunting and you won't get lost throughout the

process and you will understand what what what's your actual goal. Uh combine creativity with already familiar. You know there are different uh creativity techniques uh which are useful and if you if you're familiar with the environment you will easily get creative to understand and to get more ideas how can you find something improve something or in the end create a detection rule which will cover uh some specific cases and also avoid complexity. Keep it simple. Don't lo don't lose yourself into creating some movie scenarios which are possible uh but quite rare because in the end you will get really hyped up but uh won't uh you'll get up hyped up but in the end you will be kind of

disappointed and also you will also have some sort of fine against mentioned before you will know you will have something to prove you will have something to work on you will know it's malicious or not And for the last one, manage your expectations. Expectations are everything here because if you start to doubt in yourself, uh you will start losing a focus, you won't uh be creative anymore and by the end you will just stop thread hunting and possibly stop start avoiding security at all. So, thank you very much for your attention. I hope you didn't sleep through after lunch. So if you have any questions um feel free to ask. [applause] Thank you Phillip. A quick question for my side while you

think of your questions. So what you find yourself mostly hunting for is it like there was an incident and there was an artifact on one machine and then you're looking for that artifact in the entire environment or have you woken up in the morning looked at you know hacker news and you found some new fancy attack there is some IOC's there is some hashes some binaries and you just think ah I had the whole afternoon to kill I will try to find those or are you like going through like meter and okay, I haven't seen this threat actor in my house. Let me double check whether or not any of his TTPs have ever been here. So, what

do you find yourself hunting most for? Uh, well, I would say it it depends the context of uh of the organization I'm currently in. What what is my current job? So, this is something that uh changes on weekly basis. I don't always do the same thing. So, I don't know. I might be sitting behind uh my laptop uh looking outside. It's a sunny day. I could go outside. No, I'll do thread hunting. And I tend to do some things that are not so common because I found I find uh it the most appealing. So, those weak signals like I try to correlate things to see if something is going on or not. So, there there's actually no specific

uh you know topic which I'm covering. So what you're saying is for all of you sock managers out there, you should keep your sock super engaged and overworked, but your threat hunters idle and boring so that they have free time on their hands to look for things you never thought of actually searching for. >> Exactly. >> Yeah. Good. [laughter] Any other questions for Phillip?

Okay.

While we are waiting for the slow walk down the runway, uh just a quick reminder, there has been a some slight change in the uh schedule for today. So, some shifts from uh track one to track two. So, do check your agendas so you don't go to the wrong lecture uh later on. So, do check your phone and check the schedule. end screens. >> Wait a minute. We can't hear you. >> Yeah, thank you. So, let's say I conduct 10 thread hunts and none of them was successful. How can I improve on my mistakes and make a successful thread hunt? >> Uh, I would say that you need to consider the surf space uh uh

constraints. So uh don't keep it too broad or open-ended hypothesis uh which will allow you to find something or uh in the worst case scenario as I mentioned you will find that something is not parse or data is missing so you find a blind spot which you can use uh as a le leverage to say okay I didn't find anything but we can improve it by adding this data source. Thank you. Anybody else? Okay. Uh over here in the lady in the first row, >> you can tell me about your >> Wait for the microphone. The recording will not catch you. You will be incognito if you don't use the mic. >> Um yeah, thank you for the presentation.

Um just a soft question from me. U maybe you can uh tell us about the most uh interesting fighting uh >> that you follow uh recently maybe. Oh, well, this is a good one, but uh and I think it would be a great story, but uh unfortunately I can't the most recent one uh because it's still under investigation, a little bit more serious. uh but I can tell you that uh in let's say last uh year or so uh we've managed to find uh let's say sort of data excfiltration through some web server that was exposed to the internet that that was uh quite a trick one

anybody else in that case I Thank Philip one more time for his presentation [applause] and heaven owl. >> Oh, uh now we have 15 minutes till the next lecture. Uh do come back. It will be about cyber crime, uh cryptocurrency and all of the fancy stuff. So,