Victim of Your Own Cyberattack

Welcome back ladies and gentlemen. We are entering into the last leg of bides before you can go on and uh do all the cool cyber stuff you really want to do. So, uh, quick reminder, the last workshop of the day is about to begin on threat hunting, developing and testing a threat hypothesis with, uh, Marvin in the workshop area if anybody's interested. Behind the lovely wall, there's going to be a talk about clouds, dirty little secret. For those following Estonian media, who knows? They might talk about why not to put your photos on Discord because you never know who's sharing them for you or without you. But here on this stage to kick off the last

leg, we're going to be talking about how to become a victim of your own cyber attack. Who else than yourselves? A story from the trenches by Hrik No and Stefan Vanic.

[Music]

[Music]

Good afternoon all. Uh yeah, today we are going to talk about an incident response case Stephan and I have been uh working on uh recently and it was quite funny to see that uh during the cyber attack there was um someone that actually became almost a victim of his own cyber attack. that uh my name is Henrik Norban. I have a large background in offensive security both threat teaming, malware development and pentesting. Uh that was been has been the most of my career until I met Stfan. >> Yeah. So I'm Stefan and um contrary to Henrik, I had more of a defensive background. So that's maybe a bit why we matched so good. Um we actually

encountered each other in a consulting exercise we were doing for another well-known incident response case in Belgium. It was the city of Antworp. They had a ransomware attack. Hrik was a pentester there. I was on the architecture team. And there we basically got the idea, okay, we work so well together, so maybe it's a very good idea to start a company. And that's why we founded Razel. Um, we exist for approximately two years now. We started with the two of us and currently we're at nine employees. >> We have been to a few bides events already. Um and after the two first two we did together, we were like why is there no B sites in Belgium yet? Uh we

are from Belgium of course. Um we reached out to the Bites organization globally and they were like yeah let's hop into a call together and that that way we can explain the current situation and pretty much we entered the call and they were like yeah you guys are interested in organizing besides in Belgium and we were like uh that was not the reason why we reached out but we can do one of two things either way we complain or we just step up and decide to organize our own. We have had one edition so far. The next edition is uh planned in the 13th of March. So feel free to come and visit in Belgium uh in

March. >> We have delicious beer, fries, and waffles. So um if you're not interested about and chocolate uh so everyone is more than welcome. >> We forgot to introduce the most important giraffe in the roof. This is our company mascot. This is Rosali the giraffe. She will be traveling with us to all the events we are attending. But this is boring stuff. Uh introducing ourselves. Let's get to it. Let's get to the juice of the IR story. Before getting to the juice of it, uh I want to make a statement of the day and it's a bit controversial, but uh I believe toddlers are better at preparing hospitals for cyber incidents than most cyber security professionals. Does

anyone already agree at this point of the presentation? Raise your hands. Oh yeah. Do you count yourself as a toddler or perfect all right? We will go through the entire scenario. First we'll give you a little bit of background information on the customer we had the incident response case up on. Uh then we will move on and talk a bit on the intake we had done. Uh and uh move on to the actual CESR hotline call uh how we experienced it. to continue to the investigation and then we go to the impact uh and we end up this talk with the lessons learned uh and hopefully we can learn you something as well today. Yeah. So, uh as Henrik explained um it's

a bit of an odd incident response case because typically customers call us when they are already in misery and we have no standing relationship with the customer. So it's sailing a bit blind in this case. We actually had done an incident response intake with the customer. So we knew a lot of details about their environment. Uh which turned out to be very helpful but uh later more on that. So we knew the customer, we knew the environment. Um it's a hospital in Belgium. We cannot name them of course uh but a bit more uh details uh in a second. So uh aseta it's a hospital um actually they are a chain of multiple hospitals. So um it's two hospital

groups in a city that merge together and they have multiple sites across the city and region where they are located. Um and the merger was kind ofish complete but not fully yet. uh and a big there was a big noticeable difference in cyber security maturity between the party who was taking over the smaller group uh but combined they are one of the largest healthcare providers in uh the Belgian market so they were connected network-wise they um still had a lot of overlap especially in terms of tooling and stuff like that so they were still fully in the progress of integrating uh into one big group. Yeah. >> Yeah. A bit of background information on healthcare uh environments. Um they

almost all struggle with legacy uh software uh OS because they do not control their entire environment. There are often vendors coming in at hospitals putting uh their installation in check and they're like your warranty will end as soon as you touch it. Um basically putting the security team as well um offsite. Yeah. Fun fact actually at this customer when we looked at their active directory environments we had an intern with us. Uh the oldest password we found was actually younger than the was older than the intern we brought along. So just to give you some context on how much they struggle with uh legacy as well. Second big thing we see is with uh hospitals is that they have medical uh

suppliers. So they have the CT scans and they are typically managed by the provider themselves and they're not always doing great job at it. Second thing is that we see procurement of hospitals really struggling with putting key requirements when they ask for quotes at these vendors. There are also a limited number of vendors and thankfully since NIS-2 we saw really an improvement in maturity when it comes to these fenders as well. This type of equipment also costs a lot. So upgrading these is just not as easy as saying like let's upgrade them and buy a new one. Uh it cost a few million and hospitals are not the most rich companies in Belgium. So uh it's very hard for them to just

throw up money and solve the issue that way. >> Yeah. Another one or a big issue at hospitals is the mentality of doctors. Um, for years they have been praised as being gods and they were allowed to do anything because they would save lives and they still do and I'm not trying to put them in the ground or anything. Uh, but the that mentality still stands today in a world that is very fast changing, rapidly evolving in a digital space and doctors are very knowledgeable. Uh a recent case I've seen doctors um being a struggle some uh a little bit was that there was a mailing issue. All his mails got into the junk folder and he was like it's

totally the issue of it. You have modified something and surely we had modified something the weeks before because male security is very important. Um we said like okay will be that issue. Um maybe we should do a little bit more communication around it. But then I took a deep dive to it and we have seen a few talks on AI already. Uh doctors are also very smart on using AI already. Apparently uh they just Googled uh on chach like or they chipit I have to say these days uh they he he just looked up like how to make sure that searchs and emails go to the junk folder and what he actually uh set for himself was that all

the emails that he got went to the junk except the ones on his white list. So the senders from his white list were still forwarded uh to his inbox. All the other ones are went to the junk. So around 50 emails went to junk, 10 to his inbox on a daily basis, but it was our issue. That's something that hospitals are struggling with. It's just a very simple example and nothing that was harmful, but still doctors might can be a pain in the ass sometimes. >> Yeah. Another thing about a hospital is that it's of course a um public service meaning that it's accessible by probably almost anyone. So physical access control can be very challenging and

we'll see that later on when we dig deeper in the case where this basically was a yeah vulnerable uh part uh and the last thing um that we see at hospitals but this may be something typical Belgian. I don't know whether in your country it's the same but we have a centralized system that has the patient information but what hospitals typically do is they do not want to query the central database when they need to fetch information. So they cache a lot at their end as well which causes a lot of complexity because at one hand you have a centralized system but then on the other hand because of usability they try to decentralize it again which makes it

very hard and very complex uh as well and it's key to their operations of course uh because it has the patient information. Second on here it's also that because of the fact that it's very expensive to get all this equipment uh hospitals start to uh say like okay we will specialize in X and hospital the other hospital will specialize in Y uh just to make sure that they have diff different specialties and that they can outsource patients pretty much like this you have an issue with X so you go to that hospital you have an issue with Y you go to that hospital um and that way they can work in a more costefficient way and make sure that they split costs

between hospitals. Now uh what we have done is we have prepared a large incident response framework uh the IRP framework how we call it and we pretty much tackle four main domains. The first one to um to know when you come into a or when you come into a a incident response scenario and you are an external firm, you always have the exact same questions. And we have developed this framework to make sure that we unbburden a CISO at the time of a incident because that person is the most qu asked person at that point in time and you want to make sure you do not get any stupid questions pretty much. So first pillar we have um

crafted is the general company information just sector is there part of a group are the networks then connected if it's part of a group or do they have autonomous uh policies um how is it u built up pretty much and what we saw at this company in particular on this case um there was of course a hospital so we already knew uh that context which g gave us a lot of information already. Now a second pillar is the general IT information and you just want to get a grasp like how is it being run like what is the current status of the networks for instance uh what is the current status on um just how is it run from an IT perspective.

Yeah, naming convention stuff can be very useful information in incident response because else you need to ask them each and every single time, okay, what does this machine do? But if you have a general structure of how everything is named, it might be very useful when you ask an incident response party to come in uh and support you that they can look up the information without asking your IT team uh in the moment itself because typically when you are in a incident response case, you need all the resources you can have. So if you can save as much time as possible, it's highly recommended that you do so. >> For example, one of the cases we had

worked on um was a case where we were digging into the forensics a bit. They came out a server with a certain name giving and we were clueless on what is it and we asked the IT team and they were clueless as well. Like we have no clue what that server actually is. Eventually the secretary apparently she knew uh what that server did better than the IT team. So that was very curious to see uh it would have saved us already 15 minutes to half an hour just figuring out what is this exact server and that's pretty much the information we are asking at that point. What we saw in this particular case was that the

networks of the hospitals were just connected following the merger of the two hospitals and they had a very uh different landscape. uh the one had uh switches of vendor X the other one vendor Y um one had already segmented micro segmented the other one didn't so they had a very different posture on IT um related basis then we also have like a third pillar being uh general security information that's when we actually go a bit deeper in what is it the company doing to protect itself and protect its clients and protect u everything they own. Uh what we saw in this particular case was that they had multiple vendors. So they were not into one ecosystem but they definitely chose

for a best of breed scenario. Apart from that we also saw that they had backups in place. So they really thought it through uh on what if tomorrow ransomware for instance strikes we have to recover uh or what if a doctor apparently deletes a file and he did not delete it and it's a major incident all of a sudden how can we recover that one file. Uh so they did think everything through in that sense and the backups were in place. They were also located offsite. Uh we knew how long we could go back as well. That's very important in incident scenarios like when uh is the last restore point. That's uh something you want to know of

course because if you're going into your investigation you need to see like um we saw the entry point of an attacker uh at midnight for instance and we still have backups from the day before then we can say okay it's probably safe to restore them without restoring the artifacts of the attacker however you still need to patch how they got in of course um but that's very important information as well to know and then the last pillar is the security crisis management ment information and that's something like for instance communication templates. Do you know who to contact if entire internet is down? Uh who do you need to contact? Do you have actual email addresses? Do you have

phone numbers? Can you still use the email? What is your fall back mechanism to to go back to? And what we saw in this pillar for the hospital environment was that they actually were well prepared for a crisis. So that DRP and BCP planning was pretty much on point. not so much for cyber security reasons but for pretty much all other crisis. U I think co also did a large part in that. So they were well um prepared on that. They attempted to do a basic mapping to cyber security incidents and we assisted them doing this intake as well to make sure that they are a bit more matured and we gave them a few

focus points like you can do this and that uh to improve yourselves upon. uh but they were still ongoing. We also ran a tabletop where a few focus points uh came out of and that's how we uh first did an initial assessment making sure we knew the environment when uh things would go sideways >> before the incident. This hospital already had another very interesting case. um they had an error invalidation of an application specifically and what happened basically was they got uh patient names mixed on the patient records which is of course very tricky and very difficult. It took them more than six months to figure out which patient name was on the wrong file added

because it become it can become very dangerous in an emergency situation where you need to give some someone I'll give an example antibiotics but he's allergic to penicellin for instance this could become very dangerous so at this hospital the management was already very aware about how vulnerable they were in terms of their digital estate which helped a lot also in the preparation and actually the follow through of the actual incident um itself. Now uh quick question for everyone. When do you think cyber security incidents typically happen? During the week and office hours, raise your hands. Yeah. Uh weekends and holidays, raise your hands. And the Friday before a long weekend, raise your hands. Yep. Exactly.

We exactly got the same thing. So, um I actually had my entire long weekend scheduled uh with my wife and kids, but I got a phone call at 12:00 uh from the hospital and they said, "We see some weird network uh things going on um inside our network and we would like to take our seert retainer which they have with both us but also with Proximus. Proximus is Belgium's largest telco provider but they also offer IT services to customers. So the first and main contact line for them was the Proximus uh seesert. Uh so yeah it happened on Friday. Um and I called the sees team explaining okay the customer wants to take their seesert uh intake because

they have they see suspicious activity. And the first thing the search manager said to me okay but we are still occupied at another big incident. can you take over and we'll join later. So that was um a lot of fun. So I called Hrik uh to start the investigation um yeah at Friday at noon. Then we started the investigation um and the first thing uh we had discovered within the logs of any of the tools. So that was a big struggle to us because it was best of breed scenario that we uh had to look at different tools. But the first thing we we discovered was that there was no um external uh attack surface that was

recently vulnerable or known to be exploited. There are a very limited uh external footprint as well which we knew from the intake of course. So we could scout for that. So we pretty much quickly ruled that one out. Um next to that we also did not have any indication of identity theft through fishing instances. Uh also they had very good mail security uh in place. Um and that's also something that we could rule out pretty quickly actually. And then it would leave a third pillar and that was uh actually one of two things. Uh definitely because the logs that we saw or the logs that we were assist to come and assist from uh were all showing

internal IP addresses with no link to external. And then we have two options. It can be either someone showing like a patient just walking in the hospital and acting like he's a patient plugging himself in and trying to uh attack the hospital or dropping a device or something like that. Uh or it can be a ninja, someone trying to show off. Uh or maybe he got fired or something and trying to actually do some harm to the hospital for that reason. Now um that's why we thought it was likely from within the hospital and immediately the security team of the customer said like hm maybe just be aware we have a very good team on CCTV footage if you can

pinpoint something uh please let us know and we can try to uh look at the CCTV footage from there on. Now digging further in the logs, we saw that there actually was already exfiltration of certificates and that pretty much was uh domain admin uh privileges were actually already required at that point in time. So the exfiltration of certificates I would think is pretty much a persistence technique or something. Uh now is there anyone with an offensive background in the uh crowd here today? Raise your hands. None offensive security. They're all wearing blue headsets. So they're on >> the red team is of on the other >> on the other side. >> Now what we saw next to that is that um

a few hours later after the um exfiltration of certificates we saw Elas dumping and reconnaissances. So we saw tools like ID Explorer PSX uh tools definitely known for recon lateral movement and privilege escalation. But to me as an offensive person, it did not make any sense at that point in time because you already had the persistence. Why would you try to move from that point laterally, try to escalate privileges, try to recon? You have all the keys to the kingdom. What are you still trying to obtain? So that was a weird ch uh weird direction in the entire uh investigation. Something also we had seen was that the entire malicious activity from the certain IP addresses uh occurred over a

time span of four to five weeks which is pretty long already. Um as it often ransomware it just comes in and grabs stuff because they want to do as much damage but hey never rule out something more persistent. And next to that we also saw something that does relate to ransomware is the creation of data archives. So we saw that actually multiple zip folders were created based on data dumps um and they were also uh exfiltrated over the course of four to five weeks. So it was like maybe it's a very stealth way to exfiltrate the data to still go under the radar and who knows what might be happening from there on. So there was

some clear indication that there was actually something malicious going on, but also some weird things that we really couldn't fully explain. So it was still a bit weird to us. >> Yeah. So um the entire investigation took us until around 6:00 at night. And as I said before, um I already planned my entire weekend with wife and kids. So, I said to my wife, "Okay, um it's already six o'clock. We haven't figured it out yet." But I said, "If you're driving, I can work from the car and maybe we'll figure it out by then." So, um at 6:00, um we recommended the customer and it was also together with the security team of the customer and with the Cesare team

of Proximus. Given the exfiltration, given the fact that he had domain admin privileges, we might think something might happen over the course of the weekend because that's typically what happens and especially with a long weekend. So we said to the customer, OTK, we might think it can be ransomware although we didn't find any real artifacts in the EDR locks. Um so it was very strange but our recommendation was cut off the hospital from the internet so that we can continue our investigation but then at least we make sure it's not coming from the outside in again and if there is any commanding control we cut the connection and the customer said okay thanks a lot for the

advice but of course it has a giant impact meaning that um as soon as they cut the internet connection as said before they have no access anymore to the central database and that would mean that any planned surgery would be postponed. Now that wouldn't have been such a big impact because it's the weekend and typically surgeries are not planned in the weekend but it would have a very big impact on the ER. Now again it was a chain of hospitals around a large area of uh Belgium. Um so closing the ER would have a huge impact because again they are one of the largest health care providers we have in the country. So dispatching all the different ER uh

rooms they have across the uh across the board would overload the other hospitals. So this would have been actually a national crisis if they really had to cut off the internet. Um so that was our advice. They said okay we need to discuss this with our management just to make sure. Uh they also contacted a lot of other parties um in order to make the call. Uh but I said okay we are in full crisis mode now. We will also communicate it to the management but give us one hour. let us check the CCTV footage again and also the batch reader because uh at around 10 after 6 we figured out the actual location within the hospital from where

the activity was coming. So they located the physical network port uh where it was coming from. So they said okay give us an hour. So by then I was already in the car and indeed after one hour they called me back and they said okay we figured it out. We looked at the CCTV footage. We know who it is. Um, and it was an internal employee. It was a SIS admin uh within the organization. Um, so yeah, they had to take some uh some serious steps. So internal IT admin uh that was causing the mayhem and this is also a bridge back to the toddlers. uh the reason why in the hospital they are so experienced at CCTV analysis is

because toddlers getting lost within the hospital so they are used to look at small children or elderly people who uh are lost. So um yeah that's where their true skill lies. So that's the statement we made earlier. So they said okay uh the case can be closed no further action is taken. They already had a meeting with HR at that moment. Uh, and what would you do typically when you find out it's one of your employees? Yeah, they fired him uh on the spot, which is of course the right thing to do. Funny story that we learned later. Apparently, before they gave us a call, they already asked him, "It's certainly not you because they had some suspicion

that this person was doing some funny stuff." Uh, and he said no. So, that's the reason why they called CERT and us. And that's when we started doing the investigation and figured it out. >> I mean, I've done as well a lot of funny stuff on corporate networks. Um, and sometimes it was uh it was always approved of course by someone at least in the management or someone that was involved my N plus1 or something. Um, and definitely if nobody knew from it and got the question, then I would always say yes. not in a red team scenario, but once again there is always one person at least in the management stuff. Then if you're doing red team

engagement that knows about it. So doing something soly uh on your own thinking like I need to make a point is never okay. >> Yeah. So the guy was fired. He took his bicycle to ride home. He got into a car accident actually. So someone ran him over. He was brought back to the same hospital where they just fired him. He had surgery on his leg and he had to stay there for seven more days. So, it's kind of an awkward situation. >> Karma is a >> Yeah, Karma is indeed a Um to be in now. Um so, they brought him back, had surgery. Uh the guy was there for a couple of uh extra days.

So, he was brought back to the ER. Now, this is of course extremely hypothetical speaking, but let's say they got off the internet access and this person would still drove home and was in the car accident. He would have actually been the first or at least as far as I know, the first victim of his own cyber attack because that would mean he would have been dispatched to a different hospital which might have already been overrun. Uh, that's the the funny part about the story. Now, a few weeks later, Stefan got texted me like, "See what I see passing on LinkedIn." A job posting of the hospital for the uh job opening for the person that just got fired. We both

had a giggle and was like, "This is such a good story. We're never going to have such a good story to tell to people." So, we were telling it to you guys. >> Yep. >> Yeah. Some lessons learned uh out of it. um especially when you're in a best of breed scenario and you have multiple different tools. So they had a system for email security, they had an EDR system and they were all different vendors but they had no centralized overview of what it was. It's actually very hard when you're in an incident case and you needed to investigate and then certain people were not on call or could not be reached. So the expertise

behind the tool was not always present which makes it a bit yeah difficult. Not only the expertise was sometimes lacking, also the access was lacking. Uh how do we gain access to that certain tool? Oh yeah, that person is currently not working. >> Okay, so we had to be creative sometimes. It was a big struggle to us. >> Some tools had logs that covered the four to five weeks period. Other tools like the EDR system only had 14 days of logs. So it's very difficult to do your uh your analysis in that case. >> Another thing was that they just connected their networks. they integrated uh without a proper investigation beforehand. uh like in the

entire merger and acquisition stage that might be also something to take up with your company. If you know that their mer merger is incoming ask them how is their cyber security maturity, how is their IT maturity, what are they doing, can we easily uh combine it or do we need to put a lot of effort in actually making it a uniform environment. So that's also definitely something that we learned from this one. In a merger and acquisition, make sure you tackle it and cyber security related topics as well. next to all the finance um and and other stuff that is being uh audited during an audit uh during an emer acquisition process. I had a meeting with the

customer a couple weeks ago and uh yeah this happened approximately a year ago. Uh but they found out a lot of stuff that this person was doing. So there were a lot of servers which they couldn't bring back. Apparently it was also set up by this person. And another fun thing he did apparently was he got the NFC chip out of his badge and he implanted it in his hand. There is no real story on why he did it. No one ever asked on why he did it, but what was seen on CCTV footage was that when he left the server room, for instance, with a colleague, he would wave his hand in front of the batch reader and would then

re-enter the room. So in terms of um the batch locks, the person was actually out of the room while they actually walked back in again. And he could do that quite stealthy because the chip was in his hand. >> Biohacking on the next level. >> Biohacking on the next level. Yeah, indeed. >> Another thing uh I've learned personally um I'm always as a redeemer and pentest background person uh thinking about how to breach a company doing some fancy exploits. Um, well, sometimes you can just walk through the door and that's easier. So, just walk in, drop a device, connect it to the network and do your thing. Or you can also implement a chip in your hunt. That might be also easier

than to write advanced exploits depending on how well you are in biohacking. I'm not sure. Yeah, another thing we discovered about this person was that apparently at his previous job, he was also fired for exactly the same reason that he was at his new job. So, he did some unauthorized, yeah, let's call it pentesting of the previous organization. Now, I don't know how it is in Estonia, but background checks in Belgium are getting kind of hard. Um so for instance um that you have no criminal records as an employer you are not allowed to ask about it anymore. So it's very difficult to verify someone's background. So what we also said to the customer was first of all um if they

have a role with high privileges like domain admin for instance ask them for security clearance because that's done by a third party in Belgium it's done by the military secret service. Um, and you're allowed to ask that. So, you can put that in your contract instead of doing a background check. They will do it for you and you will only get a yes or no reply. So, you're either granted the security clearance or you are not. So, you're outsourcing that to a third party. Second thing we also told them was um that it's good to trust your employees and we typically do within our organizations as well but always verify the activities that they're doing if

they're actually doing what you're paying them uh to do. The last lesson learned uh and I think it's the most important one we have learned from this case and are preaching everywhere we go is prepare for disaster. make sure that the incident response framework we had uh previously gone through with the customer really assisted us make sure that the CISO didn't have to answer all the uh annoying questions uh from basically um what are the backup schemes and then what is this server exactly doing? We knew that already up front and we gained a lot of time having that document. Even if it wasn't us doing it, we could have just read through the entire

documentation. The CISO can say please go through it first. If you still have remaining questions, come to me, but first read this. That's really something to unburden yourself as a CISO, something to burden yourself as IT team. Uh, as soon as someone externally is coming in, they need to know a bit about your environment. They cannot magically know everything about your environment. Just be aware of that. Half a day in incident response from getting the first call to actually solving it is rather uh untypical. So um yeah, the preparation most definitely helped there. So I hope we brought you some uh some key knowledge about the incident response case. It's of course a very um yeah

interesting case to tell and I hope you enjoyed the story. Uh if you want to connect with us, we are around the entire afternoon or you can scan the QR code if you dare to at least but it links to our LinkedIn page. Uh so thank you very much and we are here for any questions. >> Thank you. We're going to need headphones if you want to hear questions. Oh, here we go. Number one.

Hello. Yeah, thank you for your presentation. Very interesting uh case. Uh maybe not so cyber security question but um I wonder why this person haven't met any legal actions after first time he committed uh cyber attack. >> Yeah that's a good question. We asked the customer as well but we have no background information about the previous incident he did. Um apparently it was not on his criminal record. So the previous employer wasn't charging him with any uh criminal activity basically. So he was never in front of a judge and yeah we only figured it out later. So I have no idea why they didn't take any legal action. >> Did uh this customer took any legal

actions? >> They are planning to. Yeah. >> Thank you. >> Any other questions? >> Uh right there. >> Do I take my Okay. Um, I'm wondering, isn't there like a least privileged way of uh wouldn't there have been a least privileged way of preventing that he would do like whatever he wants freely, a twoman rule, something that would because this seems crazy and it was the easiest uh solution. By the way, great talk. It was like a CSI like was going to be the super super thanks. Um would it have been possible? Now the domain admin credentials he had was actually needed for his role. The for principle I agree on you with that. It might have

been better that they did recent checks on the activity he was doing or for at least when they used the domain admin credentials that they had to check. But yeah hospital IT teams they're overloaded. It's uh small teams less budget. So yeah while they are very important in our um society and ecosystem they are treated like small SMB companies. So yeah so a tool which would like maybe send a summary mail like hey this guy used domain admin on a daily basis or or a script let's say would not be such a bad idea then. >> No definitely not. Yeah I agree. There's also something we recommend often like when you have the logging and start

implementing monitoring on it and alerting as soon as high privilege actions are have been taken and these days it's getting easier and easier in the cloud with nice reports weekly basis. Uh but often IT teams struggle to implement that on local AD environments >> and then look at the reports you get because that's something we see often as well in incident cases. Oh yeah, we had the information but no one looked at it. Yeah. Okay. Thank you for your question. >> Hi, thank you. Well, weird. I just wanted to come back to the first question. Did you discover why he did this? Like, >> yeah. >> Was it just like interesting or ego thing or why?

>> He was very frustrated that a lot of topics he brought um that needed attention didn't get the attention that they yeah that it deserved and he was absolutely right about it. So there were a lot of issues that they needed to fix for many years, but no budget, no priority as it always goes. Now um he definitely has a point about the parts, it's only the way how he conveyed the message which might not be the best uh way to do it and it's also not that they did not they were aware about the fact that they had a lot of work on on the staple. So um they were trying to their best the IT team. So it's not really the

IT team that was a struggle. the budget was and to work your way around when you do not have all the clues to the puzzle. That might not be the best u way to >> we might have a bit of sympathy about what he did, but then when they ask you at least come clean, it could have saved first of all lives because he was playing with human lives. Let's not forget about that. And second of all, yeah, it would save them a lot of trouble. >> A quick random question. Uh does the matching sneakers are part of the uniform? >> Yes. Yes. Thank you for noticing. You just bought him today in the mall.

>> You just bought him today. Yeah. >> Amazing. Uh, so there was wait a second. There was a question there. I remember. Yeah. Lady over there. Then there's a gentleman over there. And then we're going to go to the back. So I saw you as well. So basically you saw Die Hard for in real life. >> Yeah. >> Yeah. Okay. >> I saw you already today. >> Hi. Thanks for sharing your story. Um, you showed that one of the indicators of what he was doing was that he was extracting private keys for cert certificates. So, what were some of the other things that you saw him doing that you consider was serious enough to get

ready for a ransomware attack? >> Well, as soon as an attacker gains that amount of privileges in your environment, um, you know that he has full control of your environment and that already is a big big indicator. Um apart from that there were different uh topics um where we saw that activity and he touched a few servers uh which we had no visibility about like what did he do there we had no clue about it. Uh >> so what do you mean he touched the servers like he sshed into them or >> Yeah. Exactly. So he just went on them and what he did there we had no clue about it. There was a struggle as well

with the uh hospital. Um like the maturity of the one was rather low, the other one was high where the matur where the incident happened was the one with the low maturity. Um so yeah, there was no visibility on that end uh yet. >> And the account used with the domain admin privileges was not his account. So that was also something that was off. >> So he had gotten credentials to somebody else's account as well. >> Correct. Yeah. >> Thank you. Thank you for your question. >> Question over there, gentlemen, in in a yellow white shirt. >> I feel like I'm in a in a certain governmental establishment when they shine light in your face and answer the

question now. >> Yeah, thank you. Great talk. Uh, did you actually figure out what his end goal was? Was it to do ransomware or something else? >> Yeah, we will never know, but it was just to prove a point basically. That's what he said at least. Yeah, that's what he said. But can you trust him? Really? No, I don't know. >> And now, yes, please. >> Yes. Uh uh hi, thanks for the presentation. I have actually two questions. One is regarding the tooling that he used that left in the environment. Uh later in the investigation, did you figure out why he like used those tools or did he use them at all? And the second question is about

the car accident that I guess you mentioned he stayed later for seven weeks within the hospital and are you sure that it wasn't part of plan of some getting long-term persistence within the hospital and staying there? >> That's next level thinking actually. >> That's next. >> Are we sure of that? >> Welcome to the James Bond movie. >> Yeah. Yeah. About the second part, we are not sure um about the tools that he used. Um yeah, he was just poking around. Um, given also the explanation that Henry gave because not following the logical steps in a typical attack kill chain gave us also an idea that he was not the most technically advanced guy. Um, but why he used certain tools,

I will never know. But he used mainly legitimate tools within the network. So nothing creating alerts or anything like that. The main indicator we had on that end is that he just read a few thread reports and saw some tooling being named on there and he tried to run it as well. Like what does it do? That's my biggest guess at this point. >> But then again, you know, next time you see a guy in a car crash, >> we think about it. >> We need to check the server first and we're going to get to you. Um, okay. That would that was a bit harsh. Sorry. Uh, anybody else? Oh, here we go. things happening in Bel.

>> Uh hello, thank you for the presentation. As a part of this uh previous joke, uh I would uh offer that uh the car which was uh by was probably the Stephen was sitting in. But uh okay, let's uh move to the real question. Have you checked the data center logs also >> during forensics >> for what was available? Yes. >> And uh was it the real part of the your uh forensics uh plan or uh just a casual case for you to check the data center physical locks? Definitely as we saw the archives being created uh we could see what data was in there and even the full uh database files were uh being put in archives as well. Um so

that's definitely something that we stumbled upon. Um and yeah that's just what we indeed do in a normal incident response scenario and just look at what uh certain uh people have touched at at that point or or gathered and uh all of that. So yeah, >> thank you. And this this is getting more exciting by a minute. Like next time I'm going to Belgium, I don't need waffles. I'm like, where is the spy thing? >> Where's the hospital? >> Yeah, where's the hospital? I need the guy with the car crash. And we're going to solve Die Hard for And there's plenty of things happen. Oh, there we go. >> Another question. Yeah. Uh, so did I get it right that he

implanted a chip in his hand? Did he get to keep that? >> Uh, if he kept it or not, I'm not sure. But yeah, he did. He cut out the NFC chip from his badge and implanted it in his hand, but his badge has been deactivated. But I don't know whether they forced him back into the hospital to cut it out. I'm not sure. >> Well, as he was in the hospital and was in surgery, they could have might as well. Maybe >> there's a privacy issue there. >> Sorry, I went to law school. Sometimes I utilize that LLM of mine. Um, anybody else? No. Okay. But we we we this is something that definitely goes

on a history books. I was about just saying that every year I come to B size there's some crazy story happening where I thinking that you know I've seen Die Hard for where did they got the idea? Apparently from Belgium. Thank you very much gentlemen. Thank you guys. Thank you.