# MediaChunks

chunk_text:
  the device, it became the new device owner. So, then it can actually recover the BitLocker keys that are stored in the device because, by default, users can read BitLocker keys for devices that they own. So, if the BitLocker keys were stored in Azure AD, then you could read this after you overrode the device. You could read this after you overrode the device. And also, the nice part is that the original device still kept its link to Intune. So, like I said, the registration in Azure AD and Intune is separate. So, if you overrode the Azure AD part, the device would still be talking to Intune and would still report its compliancy. And basically, Intune would keep reporting the device as compliant to Azure AD even though the device was no longer the original one, but was now one controlled by the attacker. And the device retained its compliancy status. So, just to the complete chain, you could do a few commands in a low-privilege session of the victim. You could request a single sign-on token to register a new device. You could request a device ticket to override the legitimate compliant device. And then you could gain access to the primary refresh tokens for the victim user. You could have an MFA claim also included in that. You could have the compliant device claim from Intune. And basically, this way, you could comply with very strict conditional access policies. This bypassed the need to do MFA for your victim user, bypassed the TPM protection of secrets, and it also bypasses the need to dump LSS or have administrative privileges at all because this could all be done from a user without any administrative privileges. So, I reported this all to Microsoft actually already quite a while ago. So, they fixed overwriting a device or registering a device using single sign-on. They fixed it in September 2021. And also, they already made some other fixes to cover some scenarios. So, they did basically interface rollout. And nowadays, you cannot use any tokens that originate from single sign-on to register new devices anymore. Now, overwriting a device via device tickets, that was something I reported in May 2021. So, it's also quite a while ago. They patched this a year later. So, it took them a while to actually fix this. And it actually took them even


chunk_text:
  could gain access to the primary refresh tokens for the victim user. You could have an MFA claim also included in that. You could have the compliant device claim from Intune. And basically, this way, you could comply with very strict conditional access policies. This bypassed the need to do MFA for your victim user, bypassed the TPM protection of secrets, and it also bypasses the need to dump LSS or have administrative privileges at all because this could all be done from a user without any administrative privileges. So, I reported this all to Microsoft actually already quite a while ago. So, they fixed overwriting a device or registering a device using single sign-on. They fixed it in September 2021. And also, they already made some other fixes to cover some scenarios. So, they did basically interface rollout. And nowadays, you cannot use any tokens that originate from single sign-on to register new devices anymore. Now, overwriting a device via device tickets, that was something I reported in May 2021. So, it's also quite a while ago. They patched this a year later. So, it took them a while to actually fix this. And it actually took them even longer to enforce the server side. So, they actually rolled out the final enforcements that prevent you from overwriting a device and getting it compliant in February, or at least so I thought. So, this is actually a fun part of this. So, actually, I was making some screenshots for the presentation earlier this week. And I found out that actually the device overwriting still worked. So, they said it was fixed, but it wasn't. And then there was some conversations with Microsoft involved. So, they actually rolled out the final fixes for this yesterday. And it's still a bit of a question, like, if this is fully fixed. So, basically, what they did, the device registration method, that's unchanged. So, that's not something they changed. You can still overwrite the device using the device tickets, but it does remove the compliancy status. So, it's not immediately compliant anymore. But when I was playing with this, I found out that after the original device syncs back in Intune, then Intune would happily write back the compliancy status to the new device. So, you could still kind of get it compliant. So, this is what they fixed yesterday night. So, I


chunk_text:
  longer to enforce the server side. So, they actually rolled out the final enforcements that prevent you from overwriting a device and getting it compliant in February, or at least so I thought. So, this is actually a fun part of this. So, actually, I was making some screenshots for the presentation earlier this week. And I found out that actually the device overwriting still worked. So, they said it was fixed, but it wasn't. And then there was some conversations with Microsoft involved. So, they actually rolled out the final fixes for this yesterday. And it's still a bit of a question, like, if this is fully fixed. So, basically, what they did, the device registration method, that's unchanged. So, that's not something they changed. You can still overwrite the device using the device tickets, but it does remove the compliancy status. So, it's not immediately compliant anymore. But when I was playing with this, I found out that after the original device syncs back in Intune, then Intune would happily write back the compliancy status to the new device. So, you could still kind of get it compliant. So, this is what they fixed yesterday night. So, I was actually chatting with them until 1 a.m. to confirm whether this was fixed or not. And so, now they basically disconnect the device in Intune with the device in Azure AD when you overwrite the device in Azure AD. So, it doesn't get the compliancy claim anymore, but you can still overwrite the original device. So, I'm not sure if I would consider this 100% fixed, but at least it's no longer possible to get that compliancy claim by just overwriting a device that's already compliant. So, to conclude, the secrets in hardware were not very efficiently protected. Basically, you could just pre-calculate whatever you needed without needing to dump anything from the TPM. You could obtain a PRT by simply registering a device. A low-privileged user on the device could take over the device identity, and you could all do that using some single sign-on magic. So, this should be all fixed if you patch your endpoints. Of course, the cloud is already patched for you. It doesn't mean that there's no bypasses for this. So, I have some new research that basically defeats the whole TPM protection again, but that's something for another time. If you want


chunk_text:
  was actually chatting with them until 1 a.m. to confirm whether this was fixed or not. And so, now they basically disconnect the device in Intune with the device in Azure AD when you overwrite the device in Azure AD. So, it doesn't get the compliancy claim anymore, but you can still overwrite the original device. So, I'm not sure if I would consider this 100% fixed, but at least it's no longer possible to get that compliancy claim by just overwriting a device that's already compliant. So, to conclude, the secrets in hardware were not very efficiently protected. Basically, you could just pre-calculate whatever you needed without needing to dump anything from the TPM. You could obtain a PRT by simply registering a device. A low-privileged user on the device could take over the device identity, and you could all do that using some single sign-on magic. So, this should be all fixed if you patch your endpoints. Of course, the cloud is already patched for you. It doesn't mean that there's no bypasses for this. So, I have some new research that basically defeats the whole TPM protection again, but that's something for another time. If you want to play with this yourself, all the tools I've shown here are open source. So, they're part of the RhoTools framework, and you can play with devices and tokens using RhoTX. I also have some RhoTools stickers for those of you who are interested. If there are any further questions, feel free to ask them now. Ask them later via Twitter or mail. And, well, thank you for your attention. Okay. So, if there is any question, please raise your hand so I can bring you the microphone. Okay. Thank you for your talk. My question is more about the enrollment process of a device to the identity platform. You said there are two types of keys generated, one for the device. It was called device key, and the other one was the transport key that are generated with the TPM and are stored there. Yes. In your research, have you looked on how those keys are protected by the TPM? Because from what I know, you can use the TPM as a normal user. You can generate keys, blah, blah, blah. But if they are not protected by certain policies that restrict access to the keys, you should be


chunk_text:
  to play with this yourself, all the tools I've shown here are open source. So, they're part of the RhoTools framework, and you can play with devices and tokens using RhoTX. I also have some RhoTools stickers for those of you who are interested. If there are any further questions, feel free to ask them now. Ask them later via Twitter or mail. And, well, thank you for your attention. Okay. So, if there is any question, please raise your hand so I can bring you the microphone. Okay. Thank you for your talk. My question is more about the enrollment process of a device to the identity platform. You said there are two types of keys generated, one for the device. It was called device key, and the other one was the transport key that are generated with the TPM and are stored there. Yes. In your research, have you looked on how those keys are protected by the TPM? Because from what I know, you can use the TPM as a normal user. You can generate keys, blah, blah, blah. But if they are not protected by certain policies that restrict access to the keys, you should be able to access them. Do you have some insights on how Microsoft protects this kind of keys with the TPM or was out of the scope of your research? So, it was not part of this specific research, but I did some research into the crypto internals last year. So, basically, there's different levels of protection. So, Microsoft uses some layers below the TPM to provide software access. And basically, they store parts of the parts on disk and parts are stored, like, protected with the TPM. The keys are always restricted to system only. So, a normal user cannot load the keys. They cannot use the keys because they have access controls on them, which only allow system to use them. And also, like the transport key, it's a storage key from the TPM. So, you can only perform certain operations with it. So, you cannot like, okay, I want to use the storage key to decrypt this encrypted session key, but you can only derive new keys from it. So, those are restrictions imposed by the TPM on it. And what I found, they implemented that quite well. Another thing is that I know Azure has an identity


chunk_text:
  able to access them. Do you have some insights on how Microsoft protects this kind of keys with the TPM or was out of the scope of your research? So, it was not part of this specific research, but I did some research into the crypto internals last year. So, basically, there's different levels of protection. So, Microsoft uses some layers below the TPM to provide software access. And basically, they store parts of the parts on disk and parts are stored, like, protected with the TPM. The keys are always restricted to system only. So, a normal user cannot load the keys. They cannot use the keys because they have access controls on them, which only allow system to use them. And also, like the transport key, it's a storage key from the TPM. So, you can only perform certain operations with it. So, you cannot like, okay, I want to use the storage key to decrypt this encrypted session key, but you can only derive new keys from it. So, those are restrictions imposed by the TPM on it. And what I found, they implemented that quite well. Another thing is that I know Azure has an identity system for embedded devices. Have you considered also looking in the embedded environment and the identity part that goes there? I have not, no. Because things get a little complicated with identity when you don't have users. And I find this field of research quite interesting. How do you protect your keys when you don't have a user? Yeah. So, there's also like autopilot enrollment scenarios in which the device enrolls itself based on some TPM attestation. I also have to look into that still because, well, it's a different flow. This was a user-driven registration. So, you always need a user account to register it. But there's also ways that devices can enroll themselves, but I've not looked at that yet. Okay. Thank you very much. Any other question? Great talk. I would like to ask you, because you use the same device ID to overwrite the device in the Azure ID. But at the same time, I assume you regenerate the transport key, the session key, stuff like that. What happens to the old device? Because it assumed, based on what you said, it overwrote once again to add the compliance to the Intune. So, shouldn't the session


chunk_text:
  system for embedded devices. Have you considered also looking in the embedded environment and the identity part that goes there? I have not, no. Because things get a little complicated with identity when you don't have users. And I find this field of research quite interesting. How do you protect your keys when you don't have a user? Yeah. So, there's also like autopilot enrollment scenarios in which the device enrolls itself based on some TPM attestation. I also have to look into that still because, well, it's a different flow. This was a user-driven registration. So, you always need a user account to register it. But there's also ways that devices can enroll themselves, but I've not looked at that yet. Okay. Thank you very much. Any other question? Great talk. I would like to ask you, because you use the same device ID to overwrite the device in the Azure ID. But at the same time, I assume you regenerate the transport key, the session key, stuff like that. What happens to the old device? Because it assumed, based on what you said, it overwrote once again to add the compliance to the Intune. So, shouldn't the session key and the transport key from the old device be revoked on the server side, but it wasn't or something like that? Yeah. So, once you have a primary refresh token that has its own session key and that you can use irrespective of the device identity. So, if I overwrite a device key, then the original device can no longer request new primary refresh tokens, but any old ones still work. So, it cannot use its device identity anymore because the certificate is not valid anymore. It doesn't match anymore with the one that's registered in Azure ID, but the primary refresh tokens, they still work. Okay. Thank you. Any other question? I would like to go back to the TPMs. There is a trusted root system where the TPM should autostate the state of the device. Isn't that tied into the onboarding of the device? So, they use some attestation in the Intune registration, but not in the Azure ID registration. So, there's no need to prove to Azure ID that your keys are in the TPM or not. Azure doesn't actually care or show you if the keys are in TPM. So, if I am an administrator


chunk_text:
  key and the transport key from the old device be revoked on the server side, but it wasn't or something like that? Yeah. So, once you have a primary refresh token that has its own session key and that you can use irrespective of the device identity. So, if I overwrite a device key, then the original device can no longer request new primary refresh tokens, but any old ones still work. So, it cannot use its device identity anymore because the certificate is not valid anymore. It doesn't match anymore with the one that's registered in Azure ID, but the primary refresh tokens, they still work. Okay. Thank you. Any other question? I would like to go back to the TPMs. There is a trusted root system where the TPM should autostate the state of the device. Isn't that tied into the onboarding of the device? So, they use some attestation in the Intune registration, but not in the Azure ID registration. So, there's no need to prove to Azure ID that your keys are in the TPM or not. Azure doesn't actually care or show you if the keys are in TPM. So, if I am an administrator and I look at the list of the devices, there's no way from Azure ID to see like, oh, those keys are in a TPM or those are not. It uses a different format to register them, but Azure ID doesn't care if you use a software key or a TPM key. It doesn't enforce you to do anything. You can enforce that there should be a TPM with Intune, but that's separate from the device registration. So, they don't require you to prove that keys are in a TPM or offer you a way to only allow devices that have a TPM to actually register or join. All right. Thank you very much. We are kind of running short in time. So, I think we can move on to the next speaker, Charlie.


chunk_text:
  and I look at the list of the devices, there's no way from Azure ID to see like, oh, those keys are in a TPM or those are not. It uses a different format to register them, but Azure ID doesn't care if you use a software key or a TPM key. It doesn't enforce you to do anything. You can enforce that there should be a TPM with Intune, but that's separate from the device registration. So, they don't require you to prove that keys are in a TPM or offer you a way to only allow devices that have a TPM to actually register or join. All right. Thank you very much. We are kind of running short in time. So, I think we can move on to the next speaker, Charlie.


chunk_text:
  { "webpage_url": "https://www.youtube.com/watch?v=SfBj0xnd_XI", "title": "Targeted Social Engineering Attacks: Weaponizing Psychology by Christina Lekati", "description": "", "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA", "duration": 2746, "channel": "scrt.insomnihack", "uploader": "scrt.insomnihack", "upload_date": "20230411" } This text was transcribed using whisper model: large-v2 This talk is about targeted social engineering attacks, how psychology is being weaponized against people, but really it's also about what's coming, what we have been observing in the sphere of social engineering attacks, how the attacks have been evolving, and what we will have to face in the coming years. We already see different types of attacks, we will see more of those in the years to come. But first, a couple of words about me. Who am I to talk about that? My name is Christina Lecate, I have a background and degree in psychology, but I have been working in cyber security. Specifically, I have been working for Cyberiske GmbH, based in Zurich, as a trainer and consultant on the human element of cyber security. I have been conducting the social engineering awareness trainings, trainings for the board of directors. We specialize in custom, specialized trainings for specific needs. But I'm also the lead investigator when it comes to open source intelligence vulnerability assessment for high value targets and corporations. Last, I have been a very happy and proud member for the OSINT Curious project. But let's dive right in. We start with a case, a case that we had the luck to have a reported case on these types of attacks. This came from Proofpoint. It's a very good report, if you want to read it, the link is there. It's about Marcella, Marcella Flores, a fake online account, who behind this account actually was a state-sponsored threat actor. Very well-crafted Facebook profile with this inviting lady who had a very soft spot about people working in the aerospace defense industry. Most of her contacts were employees and people working in the aerospace defense industry. She was connecting with them, talking with them, and at some point, let's say in 2019, with one specific individual, we observed that there was an initial contact, a friend request. He accepted, she stayed there, didn't do anything for one full year. In fact, it's one of the very few long-term social engineering attacks we have been observing. And fun fact, these are the types of attacks that we had so many people thinking, oh, this


chunk_text:
  assessment for high value targets and corporations. Last, I have been a very happy and proud member for the OSINT Curious project. But let's dive right in. We start with a case, a case that we had the luck to have a reported case on these types of attacks. This came from Proofpoint. It's a very good report, if you want to read it, the link is there. It's about Marcella, Marcella Flores, a fake online account, who behind this account actually was a state-sponsored threat actor. Very well-crafted Facebook profile with this inviting lady who had a very soft spot about people working in the aerospace defense industry. Most of her contacts were employees and people working in the aerospace defense industry. She was connecting with them, talking with them, and at some point, let's say in 2019, with one specific individual, we observed that there was an initial contact, a friend request. He accepted, she stayed there, didn't do anything for one full year. In fact, it's one of the very few long-term social engineering attacks we have been observing. And fun fact, these are the types of attacks that we had so many people thinking, oh, this would never happen. But it happens a lot more than we think. It doesn't see the light of day that often. So for one full year, she didn't do anything. Why? We'll see. 2020, November 2020, almost many months after she initiates contact with her target, that individual we are examining in the report, based on just one common interest, something they were both interested in. He responds, he likes it. Let's also think it was November 2020, the time of the pandemic, where everybody was a bit home and alone. And they started talking, they started building a relationship, escalating from one social media platform to the phone, WhatsApp messaging, exchanging little pictures, exchanging little videos, having nice conversation. And that goes on for eight months. Eight months for a social engineering campaign, wasting so much time. Why? We will see. But here is the first thing we have been observing in the way social engineering attacks have evolved and in the way they are starting to go. They are not these quick hit and runs anymore. And they do start targeting more and more what people want and what people need. We have mass hierarchy of needs, and


chunk_text:
  would never happen. But it happens a lot more than we think. It doesn't see the light of day that often. So for one full year, she didn't do anything. Why? We'll see. 2020, November 2020, almost many months after she initiates contact with her target, that individual we are examining in the report, based on just one common interest, something they were both interested in. He responds, he likes it. Let's also think it was November 2020, the time of the pandemic, where everybody was a bit home and alone. And they started talking, they started building a relationship, escalating from one social media platform to the phone, WhatsApp messaging, exchanging little pictures, exchanging little videos, having nice conversation. And that goes on for eight months. Eight months for a social engineering campaign, wasting so much time. Why? We will see. But here is the first thing we have been observing in the way social engineering attacks have evolved and in the way they are starting to go. They are not these quick hit and runs anymore. And they do start targeting more and more what people want and what people need. We have mass hierarchy of needs, and we see that, yeah, we all need to feel love and affection. We all need to feel a sense of belonging with one another. We need a social circle that's going to be around for us. And that raises our self-esteem, that makes us feel confident, that is a reliable listening ear, a shoulder to lean on. Is this a human weakness? We have been hearing so often this same thing again and again. Oh, people are the human, the weakest link of security. You cannot patch stupid. But is it stupid to just have your human nature and have social engineering trying to exploit it? This is the name of the game. It's not about people being stupid. It's the simple fact that we are humans, and some will try to exploit our human nature. So, yeah, sure, we still have a lot of the phishing, hit-and-run campaigns, the ones that have time pressure, the classic funny-looking email address from the sender, the awkward grammar. Yeah, we still get those, and we keep going to getting those. These are not going out of fashion all of a sudden because they still work. But we also see that some, some


chunk_text:
  we see that, yeah, we all need to feel love and affection. We all need to feel a sense of belonging with one another. We need a social circle that's going to be around for us. And that raises our self-esteem, that makes us feel confident, that is a reliable listening ear, a shoulder to lean on. Is this a human weakness? We have been hearing so often this same thing again and again. Oh, people are the human, the weakest link of security. You cannot patch stupid. But is it stupid to just have your human nature and have social engineering trying to exploit it? This is the name of the game. It's not about people being stupid. It's the simple fact that we are humans, and some will try to exploit our human nature. So, yeah, sure, we still have a lot of the phishing, hit-and-run campaigns, the ones that have time pressure, the classic funny-looking email address from the sender, the awkward grammar. Yeah, we still get those, and we keep going to getting those. These are not going out of fashion all of a sudden because they still work. But we also see that some, some organizations have started to become a bit more sophisticated. They start to recognize them. But we also see the attackers evolving into more elaborate campaigns because they are much more successful, ones that involve longer reconnaissance, ones that have a more tailored and personalized approach to them. So not just these random numbers game phishing emails being sent out or those rather standard spear phishing. They are really, really tailored. They use more elaborate mind games. They exploit our psychological nature. And slowly, we start seeing deepfakes getting into the mix as well. And we see those especially from state-sponsored threat actors. Now, if some of you are in companies that belong to the highest risk profile, the ones that have sensitive research, the ones that belong to the critical infrastructure, yes, you should be very much worried about this. But let's see what happened with Marcella. Yeah, she was talking with that person for eight months. How did this conclude? Well, in the report, and what ends up in the report are the results, like just the facts. And there are a lot of things that happen in between the lines that get missed. So in the end, Marcella


chunk_text:
  organizations have started to become a bit more sophisticated. They start to recognize them. But we also see the attackers evolving into more elaborate campaigns because they are much more successful, ones that involve longer reconnaissance, ones that have a more tailored and personalized approach to them. So not just these random numbers game phishing emails being sent out or those rather standard spear phishing. They are really, really tailored. They use more elaborate mind games. They exploit our psychological nature. And slowly, we start seeing deepfakes getting into the mix as well. And we see those especially from state-sponsored threat actors. Now, if some of you are in companies that belong to the highest risk profile, the ones that have sensitive research, the ones that belong to the critical infrastructure, yes, you should be very much worried about this. But let's see what happened with Marcella. Yeah, she was talking with that person for eight months. How did this conclude? Well, in the report, and what ends up in the report are the results, like just the facts. And there are a lot of things that happen in between the lines that get missed. So in the end, Marcella sent out an email. They were talking about the pandemic. They were talking about diets. And she said, hey, my dear. This is a diet survey. It should fill out. You should fill out your experiences, especially during the pandemic period at home. Please press enable editing to enable content and to see the full page. This is the link. It was a Google Drive link. Send me soon. Thanks for your kindness and your participation. Cheers. Marce. Let me tell you, of course, there was some flirting added to the mix. But so he did. He said, yeah, I'm going to help this friend and who knows what else. I'm going to help her out. He clicked on the link. Yes, there was a trusted relationship by then, which was the whole point of this engagement lasting so long. And enabled the content, downloaded the macros, and eventually downloaded what was done as the LEMPO malware, which was designed to establish persistence, perform reconnaissance, and actually create sensitive information. And as I say, there is this history. Was there one case, scenario, did this happen just once? Is it the black swan, one of the things that you cannot


chunk_text:
  sent out an email. They were talking about the pandemic. They were talking about diets. And she said, hey, my dear. This is a diet survey. It should fill out. You should fill out your experiences, especially during the pandemic period at home. Please press enable editing to enable content and to see the full page. This is the link. It was a Google Drive link. Send me soon. Thanks for your kindness and your participation. Cheers. Marce. Let me tell you, of course, there was some flirting added to the mix. But so he did. He said, yeah, I'm going to help this friend and who knows what else. I'm going to help her out. He clicked on the link. Yes, there was a trusted relationship by then, which was the whole point of this engagement lasting so long. And enabled the content, downloaded the macros, and eventually downloaded what was done as the LEMPO malware, which was designed to establish persistence, perform reconnaissance, and actually create sensitive information. And as I say, there is this history. Was there one case, scenario, did this happen just once? Is it the black swan, one of the things that you cannot anticipate? No. This is something that we see happening a lot, but doesn't get out in the news all that often. There were more cases. Facebook reported a whole set of similar accounts trying to do the same. LinkedIn is full of those. You probably have heard that. There are many, many others as well. The kill chain is usually the same. They target specific people in key positions. They perform long reconnaissance, mostly through social media, because social media is a gift that keeps on giving for reconnaissance. And now, if you were wondering, what did it take her so long to establish a connection? Well, they were studying their targets. And they do study their targets nowadays. So, yes, of course, then you have the online persona, which is the medium through which the attack can happen. The approach is personalized, like we said. And very, very often we see them escalating their targets from one platform to another to appear more legitimate and believable. Facebook from Facebook to LinkedIn to an Instagram, because if you have an online presence, you must be a real person. No. Of course, then eventually to WhatsApp, phone numbers, email addresses, work


chunk_text:
  anticipate? No. This is something that we see happening a lot, but doesn't get out in the news all that often. There were more cases. Facebook reported a whole set of similar accounts trying to do the same. LinkedIn is full of those. You probably have heard that. There are many, many others as well. The kill chain is usually the same. They target specific people in key positions. They perform long reconnaissance, mostly through social media, because social media is a gift that keeps on giving for reconnaissance. And now, if you were wondering, what did it take her so long to establish a connection? Well, they were studying their targets. And they do study their targets nowadays. So, yes, of course, then you have the online persona, which is the medium through which the attack can happen. The approach is personalized, like we said. And very, very often we see them escalating their targets from one platform to another to appear more legitimate and believable. Facebook from Facebook to LinkedIn to an Instagram, because if you have an online presence, you must be a real person. No. Of course, then eventually to WhatsApp, phone numbers, email addresses, work email. Perfect. And through this casual relationship building that looks a lot like the way we make friends in everyday life, they take this trust building and exploit it in a very regular, casual, everyday manner. Nothing out of the ordinary. These were the details. You don't have to read them. Whoever wants the slides can ask me for them after the talk, and I will be happy to email them to you or send them. But they all have common characteristics. The difference is only roughly in the exploitation, how they decide to exploit the contact. Did they want to harvest credentials? Other times they want to send out a malicious email that downloads malware. And, of course, the goal sometimes differs as well. Most of the times the case is epic. What's behind it is an espionage operation, and they need to collect sensitive information. Why go through all these troubles for so long? What do they gain out of it? What is it in it for them? Because don't forget, threat actors, they also care about return on investment. They care about how they spend their time. So, yeah, there is the case where there is an


chunk_text:
  email. Perfect. And through this casual relationship building that looks a lot like the way we make friends in everyday life, they take this trust building and exploit it in a very regular, casual, everyday manner. Nothing out of the ordinary. These were the details. You don't have to read them. Whoever wants the slides can ask me for them after the talk, and I will be happy to email them to you or send them. But they all have common characteristics. The difference is only roughly in the exploitation, how they decide to exploit the contact. Did they want to harvest credentials? Other times they want to send out a malicious email that downloads malware. And, of course, the goal sometimes differs as well. Most of the times the case is epic. What's behind it is an espionage operation, and they need to collect sensitive information. Why go through all these troubles for so long? What do they gain out of it? What is it in it for them? Because don't forget, threat actors, they also care about return on investment. They care about how they spend their time. So, yeah, there is the case where there is an attack that harvests credentials in the end or a malware infection. But this whole time there is also an effort to elicit sensitive information. Human intelligence tactics that we used to see in espionage operations are now happening in cyberspace through virtual human intelligence operations, through these fake profiles, through casual conversation whose goal is to blend in specific targeted questions. We're going to talk about that a little later. But, yeah, eight months. Marcella Flores took eight months to exploit the relationship. Imagine how much information she gained on the targets in that time, about technologies, about things that are happening at work. I've seen these conversations and people talk. Of course, in other cases, we also have insider threat grooming. This is not random. They spot the ones that are unhappy at work, that have needs in life, that a threat actor or someone money could fill in. And by establishing a connection and a relationship, eventually they groom them into willful, knowledgeable insider threats. Again, it supports long-term espionage operations as well. But once you have a connection with someone in a key position, imagination is the limit. Any number of things can happen. And what we


chunk_text:
  attack that harvests credentials in the end or a malware infection. But this whole time there is also an effort to elicit sensitive information. Human intelligence tactics that we used to see in espionage operations are now happening in cyberspace through virtual human intelligence operations, through these fake profiles, through casual conversation whose goal is to blend in specific targeted questions. We're going to talk about that a little later. But, yeah, eight months. Marcella Flores took eight months to exploit the relationship. Imagine how much information she gained on the targets in that time, about technologies, about things that are happening at work. I've seen these conversations and people talk. Of course, in other cases, we also have insider threat grooming. This is not random. They spot the ones that are unhappy at work, that have needs in life, that a threat actor or someone money could fill in. And by establishing a connection and a relationship, eventually they groom them into willful, knowledgeable insider threats. Again, it supports long-term espionage operations as well. But once you have a connection with someone in a key position, imagination is the limit. Any number of things can happen. And what we know about social engineering is that there are no rules. And this is the whole point of weaponizing psychology. Yes, we deal with a lot of technical challenges and we must. It's an essential part of the work. But this is also a behavioral problem. How do you go around telling your employees you shouldn't talk to strangers? You should keep a secret secret. This is a behavioral issue. Employees and managers that can provide access to technology, information or assets become targets. And they have the responsibility to protect those assets. Can they do it? Do they have the skills and knowledge necessary to detect those attacks? Not always. And that's the thing. Cyber security and security technology has been advancing. But identifying and exploiting human vulnerabilities, also human psychology, has remained the same across centuries and across the globes. The human stimulus response in human triggers is consistent. And exploiting these triggers is also consistently successful. And if you just think about it from the side of the threat actors, it's efficient. It is low cost. It is low risk. And it's high reward because it works consistently. Is it that hard to find somebody's unmet needs? Is


chunk_text:
  know about social engineering is that there are no rules. And this is the whole point of weaponizing psychology. Yes, we deal with a lot of technical challenges and we must. It's an essential part of the work. But this is also a behavioral problem. How do you go around telling your employees you shouldn't talk to strangers? You should keep a secret secret. This is a behavioral issue. Employees and managers that can provide access to technology, information or assets become targets. And they have the responsibility to protect those assets. Can they do it? Do they have the skills and knowledge necessary to detect those attacks? Not always. And that's the thing. Cyber security and security technology has been advancing. But identifying and exploiting human vulnerabilities, also human psychology, has remained the same across centuries and across the globes. The human stimulus response in human triggers is consistent. And exploiting these triggers is also consistently successful. And if you just think about it from the side of the threat actors, it's efficient. It is low cost. It is low risk. And it's high reward because it works consistently. Is it that hard to find somebody's unmet needs? Is it that hard to find this one thing that triggers them? No. We said before that social media is a gift that keeps on giving. We can scout somebody's digital footprint and we do that when we conduct vulnerability assessments and find exactly what makes them tick because they share it, either explicitly or implicitly, in one way or another. If there is a digital footprint, there will be traces of behavioral patterns as well. People that have addictions, people that need more money for whatever reason, people that are lonely, a very human thing. These are all gaps and needs that the threat actor can spot and try to fill. And since I have conducted risk profiles on high value targets, again, these are just some of the data points that we have found we can collect on individuals. Only from social media profiles, the locations, where do they go? Where do they frequent? Do they go to the gym every so often? Do you think attacks only happen during office hours? No, they also happen at the gym. They happen at the golf club. They happen anywhere really, at conferences, during travel. You have this stranger that suddenly


chunk_text:
  it that hard to find this one thing that triggers them? No. We said before that social media is a gift that keeps on giving. We can scout somebody's digital footprint and we do that when we conduct vulnerability assessments and find exactly what makes them tick because they share it, either explicitly or implicitly, in one way or another. If there is a digital footprint, there will be traces of behavioral patterns as well. People that have addictions, people that need more money for whatever reason, people that are lonely, a very human thing. These are all gaps and needs that the threat actor can spot and try to fill. And since I have conducted risk profiles on high value targets, again, these are just some of the data points that we have found we can collect on individuals. Only from social media profiles, the locations, where do they go? Where do they frequent? Do they go to the gym every so often? Do you think attacks only happen during office hours? No, they also happen at the gym. They happen at the golf club. They happen anywhere really, at conferences, during travel. You have this stranger that suddenly comes in and starts talking to you. We see what their connections are. Who are the key people? Who do they trust? Do they have a family? Are they lonely? Do they have nobody? Did they just divorce? All these are the data points that are collected and could be weaponized against them in one way or another. And then, of course, you have the whole psychological profile. You see these individuals. Are they extroverted? Again, there is no problem with you having an online presence. But the point is, you need to know where to draw the boundaries when you communicate with others, especially when it comes to practicing certain cybersecurity habits, like downloading attachments or disclosing sensitive information. Because I know this sounds a bit too much, and it is too much. People, threat actors, will spot if you're an extrovert, if you're willing to talk to others, which is perfectly fine. They will try to exploit it, though. What are your interests? What do you want? What do you miss? They collect that. But let's go back to sensitive information, because I feel this gets a bit overlooked at times. And yes, there is a digital layer


chunk_text:
  comes in and starts talking to you. We see what their connections are. Who are the key people? Who do they trust? Do they have a family? Are they lonely? Do they have nobody? Did they just divorce? All these are the data points that are collected and could be weaponized against them in one way or another. And then, of course, you have the whole psychological profile. You see these individuals. Are they extroverted? Again, there is no problem with you having an online presence. But the point is, you need to know where to draw the boundaries when you communicate with others, especially when it comes to practicing certain cybersecurity habits, like downloading attachments or disclosing sensitive information. Because I know this sounds a bit too much, and it is too much. People, threat actors, will spot if you're an extrovert, if you're willing to talk to others, which is perfectly fine. They will try to exploit it, though. What are your interests? What do you want? What do you miss? They collect that. But let's go back to sensitive information, because I feel this gets a bit overlooked at times. And yes, there is a digital layer to what happens with information. But there is also the human layer of what happens with information, the people that know about things. It has a very high value. Think about business plans, strategies, biddings, negotiation strategies. Also credentials, of course. Also passwords and access to systems technology, giving entry. But yeah, according to the U.S. Department of Defense, classified information and the unauthorized disclosure of classified information is a communication or physical transfer of classified information or controlled, unclassified information to an unauthorized recipient. And this can happen intentionally in the case of a mistake or in the case of an insider threat. But it can also happen unintentionally when an individual elicits this information out of you and throws them out in a casual conversation. It has many attackers, like cybercriminal organizations, hacktivists that oppose your company's moves and what your company stands for, nation states with a geopolitical agenda, journalists that want to get a good story out of your business's operation, and corporate espionage operatives. Again, it's not in everybody's threat model, but critical organizations that belong to the critical infrastructure are an extremely attractive target for these types of operations. Let's take another case study.


chunk_text:
  to what happens with information. But there is also the human layer of what happens with information, the people that know about things. It has a very high value. Think about business plans, strategies, biddings, negotiation strategies. Also credentials, of course. Also passwords and access to systems technology, giving entry. But yeah, according to the U.S. Department of Defense, classified information and the unauthorized disclosure of classified information is a communication or physical transfer of classified information or controlled, unclassified information to an unauthorized recipient. And this can happen intentionally in the case of a mistake or in the case of an insider threat. But it can also happen unintentionally when an individual elicits this information out of you and throws them out in a casual conversation. It has many attackers, like cybercriminal organizations, hacktivists that oppose your company's moves and what your company stands for, nation states with a geopolitical agenda, journalists that want to get a good story out of your business's operation, and corporate espionage operatives. Again, it's not in everybody's threat model, but critical organizations that belong to the critical infrastructure are an extremely attractive target for these types of operations. Let's take another case study. Mia Ash, who was a fake profile. Again, behind this fake profile was another state-sponsored threat actor, likely called Cobalt Gypsy. She targeted telecommunications, government, defense, oil, and financial services organizations in Middle East and North Africa. Now, Mia Ash was not the original plan. The original plan was simply to send out a set of phishing emails, the numbers game, massively to a number of individuals. It would eventually deliver a remote access tool, but this didn't work. They sent out the phishing email. It was royally unsuccessful, and they thought, OK, we need a plan B. We need to do something better. What would that be? And it was Mia. It was this sweet persona that you see on your screens right now. Side note, it's not only women targeted men. There are also males targeting women. It just happens to be that the ones that are public right now happen to be women, female profiles targeting men, but it can happen to anybody. It can happen to all types of individuals, no matter what their preferences are. So Mia Ash, again, fake identity using several social media accounts, and she was used to perform reconnaissance to collect


chunk_text:
  Mia Ash, who was a fake profile. Again, behind this fake profile was another state-sponsored threat actor, likely called Cobalt Gypsy. She targeted telecommunications, government, defense, oil, and financial services organizations in Middle East and North Africa. Now, Mia Ash was not the original plan. The original plan was simply to send out a set of phishing emails, the numbers game, massively to a number of individuals. It would eventually deliver a remote access tool, but this didn't work. They sent out the phishing email. It was royally unsuccessful, and they thought, OK, we need a plan B. We need to do something better. What would that be? And it was Mia. It was this sweet persona that you see on your screens right now. Side note, it's not only women targeted men. There are also males targeting women. It just happens to be that the ones that are public right now happen to be women, female profiles targeting men, but it can happen to anybody. It can happen to all types of individuals, no matter what their preferences are. So Mia Ash, again, fake identity using several social media accounts, and she was used to perform reconnaissance to collect information on the targets and to establish a relationship with them based on specific hobbies. Once again, she would start the conversation based on their common interest in photography, and then it would escalate like we talked about. And then it would escalate, like we said before, to other profiles, to different communication methods, and she would build a relationship very casually. And once the work email was provided, she would find a ruse. She would say something like, hey, I really want to deliver my portfolio to this challenge, and I would appreciate nothing more than your opinion. Can you quickly take it? I have like a 10-minute window to submit it. I was so stressed out to send it out, and now I'm running late with my deadline. Yes, but I'm at work. It will only take five minutes. I just want your precious opinion. The target downloaded. It was an extremely successful attack. They downloaded the attachment, and the remote access tool was delivered to their machines. What a mess. And how do we defend against this threat? As a general rule, there are no rules, and no one is exempt. That goes to say that, oh,


chunk_text:
  information on the targets and to establish a relationship with them based on specific hobbies. Once again, she would start the conversation based on their common interest in photography, and then it would escalate like we talked about. And then it would escalate, like we said before, to other profiles, to different communication methods, and she would build a relationship very casually. And once the work email was provided, she would find a ruse. She would say something like, hey, I really want to deliver my portfolio to this challenge, and I would appreciate nothing more than your opinion. Can you quickly take it? I have like a 10-minute window to submit it. I was so stressed out to send it out, and now I'm running late with my deadline. Yes, but I'm at work. It will only take five minutes. I just want your precious opinion. The target downloaded. It was an extremely successful attack. They downloaded the attachment, and the remote access tool was delivered to their machines. What a mess. And how do we defend against this threat? As a general rule, there are no rules, and no one is exempt. That goes to say that, oh, everybody needs to know basic cybersecurity habits, good cybersecurity habits, and apply them. From the services, the call center that has certain access to information, to the high-value targets, to the people higher up in the hierarchy. We talked about elicitation. How does this work? Yeah, we say it's casual conversation, but there is a technique behind it. Elicitation is an effort in which seemingly normal conversation is contrived to extract sensitive information about individuals, their work, and their colleagues. How does it sound like? Three of the most popular methods are flattery, this, oh, you are the only one who can help me with this one thing that I need, and I value your opinion so much. Please help me. Flattery. Second is the familiarity and the tribe instinct. This was another case. Hey, we are both in the same industry, so from one IT pro to another. What do you think about this technology? I don't know. I just cannot bring myself to decide whether I want to buy it for our organization. Have you used it? Was it good? Do you have something else to recommend? I'm just so lost. That's an elicitation technique. And then the


chunk_text:
  everybody needs to know basic cybersecurity habits, good cybersecurity habits, and apply them. From the services, the call center that has certain access to information, to the high-value targets, to the people higher up in the hierarchy. We talked about elicitation. How does this work? Yeah, we say it's casual conversation, but there is a technique behind it. Elicitation is an effort in which seemingly normal conversation is contrived to extract sensitive information about individuals, their work, and their colleagues. How does it sound like? Three of the most popular methods are flattery, this, oh, you are the only one who can help me with this one thing that I need, and I value your opinion so much. Please help me. Flattery. Second is the familiarity and the tribe instinct. This was another case. Hey, we are both in the same industry, so from one IT pro to another. What do you think about this technology? I don't know. I just cannot bring myself to decide whether I want to buy it for our organization. Have you used it? Was it good? Do you have something else to recommend? I'm just so lost. That's an elicitation technique. And then the third one, empathy and the tendency to complain, the tendency to want to share our problems with others, which is perfectly fine. But if they contain sensitive information, trust it to the people that can be trusted with it. So it goes like this. Oh, you had a terrible day at work. I know. I had one too. My boss, I don't know, I just cannot understand the demands of my work, but I'll tell you about it. But first about you, what happened? Oh, yeah. Oh, you have this acquisition, you're stressed. Yeah, we had one too. What's going on? Tell me, maybe I can help. Elicitation technique. It's not unknown in the field of espionage, we are seeing more espionage techniques coming and have adapting to the cyber security industry, to cyber attacks. The Defense Counterintelligence and Security Agency gives guidelines on those, but three main rules, we don't have to overcomplicate things, three main rules to avoid being a victim of elicitation techniques is knowing what information should not be shared, being suspicious of the people who ask or pry around this information. Sometimes when you don't answer the first time around, you will notice that they


chunk_text:
  third one, empathy and the tendency to complain, the tendency to want to share our problems with others, which is perfectly fine. But if they contain sensitive information, trust it to the people that can be trusted with it. So it goes like this. Oh, you had a terrible day at work. I know. I had one too. My boss, I don't know, I just cannot understand the demands of my work, but I'll tell you about it. But first about you, what happened? Oh, yeah. Oh, you have this acquisition, you're stressed. Yeah, we had one too. What's going on? Tell me, maybe I can help. Elicitation technique. It's not unknown in the field of espionage, we are seeing more espionage techniques coming and have adapting to the cyber security industry, to cyber attacks. The Defense Counterintelligence and Security Agency gives guidelines on those, but three main rules, we don't have to overcomplicate things, three main rules to avoid being a victim of elicitation techniques is knowing what information should not be shared, being suspicious of the people who ask or pry around this information. Sometimes when you don't answer the first time around, you will notice that they persist. No, really, tell me. Now, I really need to know. And you will notice that they have a particular interest eventually. And last, simple, do not tell people things they are not authorized to know. Even the Defense Counterintelligence and Security Agency, they say it so simply, don't tell people that they're not authorized to know things that they are not supposed to know. High value targets, the executives, they sometimes need to be handled differently, both because they have an extremely high, they have elevated access to information, systems, everything. So they are lucrative targets, but they also need to be handled differently sometimes. When we work vulnerability profiles on them, and if you need to run a vulnerability profile on them, how do you do it? What do you focus on? Five main areas. What is the criticality of their role? What is their degree of importance? What happens if they get compromised? Do a whole lot of things go wrong after that? This is what criticality points you to. So that you can prioritize a little bit, because we cannot be everywhere for everyone, and we are limited in terms of resources as well. What's their


chunk_text:
  persist. No, really, tell me. Now, I really need to know. And you will notice that they have a particular interest eventually. And last, simple, do not tell people things they are not authorized to know. Even the Defense Counterintelligence and Security Agency, they say it so simply, don't tell people that they're not authorized to know things that they are not supposed to know. High value targets, the executives, they sometimes need to be handled differently, both because they have an extremely high, they have elevated access to information, systems, everything. So they are lucrative targets, but they also need to be handled differently sometimes. When we work vulnerability profiles on them, and if you need to run a vulnerability profile on them, how do you do it? What do you focus on? Five main areas. What is the criticality of their role? What is their degree of importance? What happens if they get compromised? Do a whole lot of things go wrong after that? This is what criticality points you to. So that you can prioritize a little bit, because we cannot be everywhere for everyone, and we are limited in terms of resources as well. What's their level of recognizability? Do they have a public profile? And by the way, by high value targets, I don't only mean executives. These are also the people that work in sensitive projects. Are they recognizable? Would you be able to find information on them online? Would an adversary be able to find out who they are? Who are the key people working in key positions? And what information is out there about them? Accessibility is the ease of approach. So if I know they are critical and I know who they are, can I spot them at the conference? Can I spot them at the gym? Can I approach them online? Do they talk? Do they engage with strangers online? Would I have a good chance with them? And to that plays in their level of vulnerability as well. Do I see clear weaknesses on that individual? Like the ones we talked about before. Do I see something that I could readily explode? Your adversaries will go through this process. And you see they did. And last, the key piece, if they do receive this type of attack, would they be knowledgeable enough to detect it or know how to


chunk_text:
  level of recognizability? Do they have a public profile? And by the way, by high value targets, I don't only mean executives. These are also the people that work in sensitive projects. Are they recognizable? Would you be able to find information on them online? Would an adversary be able to find out who they are? Who are the key people working in key positions? And what information is out there about them? Accessibility is the ease of approach. So if I know they are critical and I know who they are, can I spot them at the conference? Can I spot them at the gym? Can I approach them online? Do they talk? Do they engage with strangers online? Would I have a good chance with them? And to that plays in their level of vulnerability as well. Do I see clear weaknesses on that individual? Like the ones we talked about before. Do I see something that I could readily explode? Your adversaries will go through this process. And you see they did. And last, the key piece, if they do receive this type of attack, would they be knowledgeable enough to detect it or know how to handle it? Or would they get lost or possibly not recognize it? One important thing is that these attacks prey a lot on ignorance, like most social engineering attacks. If you don't know what a threat or a danger looks like, you cannot protect against it. So think, how many of you have educated your boards on these types of threats? Or in cybersecurity in general. I know that some of you probably have to deal with boards and executives that say, oh, no, no, no, no, no. Ignorance is bliss. Knowledge is a liability. I don't want to hear any of this. I don't want to hear about the threats. I would never be a target. Leave me alone. I have other things too. Other more important things to pay attention to, like my profits, please. But there are also the boards that are interested. They want and they need to know about these threats. Or when you are facing resistance, again, don't drop it. We should insist. This is about their safety, their organization's safety. I think we should insist a little bit on getting the message through to them on why cybersecurity matters. Some others will think,


chunk_text:
  handle it? Or would they get lost or possibly not recognize it? One important thing is that these attacks prey a lot on ignorance, like most social engineering attacks. If you don't know what a threat or a danger looks like, you cannot protect against it. So think, how many of you have educated your boards on these types of threats? Or in cybersecurity in general. I know that some of you probably have to deal with boards and executives that say, oh, no, no, no, no, no. Ignorance is bliss. Knowledge is a liability. I don't want to hear any of this. I don't want to hear about the threats. I would never be a target. Leave me alone. I have other things too. Other more important things to pay attention to, like my profits, please. But there are also the boards that are interested. They want and they need to know about these threats. Or when you are facing resistance, again, don't drop it. We should insist. This is about their safety, their organization's safety. I think we should insist a little bit on getting the message through to them on why cybersecurity matters. Some others will think, this is all way too advanced. Our employees fall for the simplest phishing attacks. I cannot bother with targeted email attacks as well. Forget it. No. I think it's too complicated. What am I going to do? Go around and tell people not to talk to strangers? It's not about that. First of all, let's not oversimplify complicated threats. Reports that come out about social engineering, for example, they have, for the sake of word count, they have to say that phishing emails are the top threat. But you see that the way this phishing email is being delivered also matters to its effectiveness. And let's also not oversimplify, no, overcomplicate simple solutions. In the end of the day, they need to know what to protect and where the boundaries are. You don't have to go around and tell them, stop talking to everybody online. But you have to tell them, know what should not be shared and do not share it, for reasons A, B, C, D. And know how to exercise basic cybersecurity habits and stick with them. And the way you deliver this message also matters. I believe the keynote speaker earlier today mentioned a little something


chunk_text:
  this is all way too advanced. Our employees fall for the simplest phishing attacks. I cannot bother with targeted email attacks as well. Forget it. No. I think it's too complicated. What am I going to do? Go around and tell people not to talk to strangers? It's not about that. First of all, let's not oversimplify complicated threats. Reports that come out about social engineering, for example, they have, for the sake of word count, they have to say that phishing emails are the top threat. But you see that the way this phishing email is being delivered also matters to its effectiveness. And let's also not oversimplify, no, overcomplicate simple solutions. In the end of the day, they need to know what to protect and where the boundaries are. You don't have to go around and tell them, stop talking to everybody online. But you have to tell them, know what should not be shared and do not share it, for reasons A, B, C, D. And know how to exercise basic cybersecurity habits and stick with them. And the way you deliver this message also matters. I believe the keynote speaker earlier today mentioned a little something about providing very boring video trainings that people just want to click through and they eventually get totally fed up with hearing about cybersecurity because it's all being a drug, a necessary evil, a necessity. They have to go and click through the slides and click through the videos while they have other things to do. No, you can provide something more engaging for them. And we should do that as an industry. And if your employees are still following for the simple phishing emails and this is still a problem, don't just let it be. We have to do something about it. Attacks are not going to get any simpler. They become more complicated and more advanced and we have to be able to catch up one way or another as an industry. It's not an unusual thing that might not happen. The probabilities are high that you will encounter it. In most case scenarios, what have people that fell victims to cyber attacks, whether this was an elicitation technique, somebody malicious engaging them online and them falling for it, or spear phishing emails, they say, and these are very common quotes, by the way, Oh, yeah, I thought


chunk_text:
  about providing very boring video trainings that people just want to click through and they eventually get totally fed up with hearing about cybersecurity because it's all being a drug, a necessary evil, a necessity. They have to go and click through the slides and click through the videos while they have other things to do. No, you can provide something more engaging for them. And we should do that as an industry. And if your employees are still following for the simple phishing emails and this is still a problem, don't just let it be. We have to do something about it. Attacks are not going to get any simpler. They become more complicated and more advanced and we have to be able to catch up one way or another as an industry. It's not an unusual thing that might not happen. The probabilities are high that you will encounter it. In most case scenarios, what have people that fell victims to cyber attacks, whether this was an elicitation technique, somebody malicious engaging them online and them falling for it, or spear phishing emails, they say, and these are very common quotes, by the way, Oh, yeah, I thought that something was off. I was not really sure how to respond in the spare of the moment. I just went with it. That's because of bad training, usually. Oh, yeah, I spotted it, but then what? I learned about the threats, but how do I handle it once the person is pressuring me? That's bad training. Others say, Oh, yeah, so it happened. I downloaded the file. I knew it was bad, but I didn't report it because I thought I would be implicated and I didn't want to get fired. What a bad message. What a bad security culture. It's such a pity. If your employees think that reporting it will jeopardize their careers instead of saving their organization, that has to do with, again, awareness, but also your cybersecurity culture. Other people say, I was under a lot of time pressure and my manager would not appreciate that verification call. Why does your manager think that it's not important to verify certain requests? You see the quotes and you spot the weaknesses that you need to work on. I don't expect anybody to have the perfect plan and not to have any weaknesses, but these are things


chunk_text:
  that something was off. I was not really sure how to respond in the spare of the moment. I just went with it. That's because of bad training, usually. Oh, yeah, I spotted it, but then what? I learned about the threats, but how do I handle it once the person is pressuring me? That's bad training. Others say, Oh, yeah, so it happened. I downloaded the file. I knew it was bad, but I didn't report it because I thought I would be implicated and I didn't want to get fired. What a bad message. What a bad security culture. It's such a pity. If your employees think that reporting it will jeopardize their careers instead of saving their organization, that has to do with, again, awareness, but also your cybersecurity culture. Other people say, I was under a lot of time pressure and my manager would not appreciate that verification call. Why does your manager think that it's not important to verify certain requests? You see the quotes and you spot the weaknesses that you need to work on. I don't expect anybody to have the perfect plan and not to have any weaknesses, but these are things we need to work on. Security is a process, but we have to do something about this process and not just let things be. And last, Oh, it did not even cross my mind that I could actually be a target. I'm not that important. The result of bad training, the result of a bad cybersecurity culture, or just doing like 15 minutes per year on what social engineering attacks are and how they work in an effective way. If I had only five tips for the employees, they would be, yes, technology is still important. It does matter to minimize employee decision-making and use the principle of privilege when possible, but it's not going to be enough because we see that threat actors target them through private channels. So then on top of that, good quality training that actively engages people, that doesn't have them sit passively behind the screen and just clicking through, clicking through, clicking through, but actively engages them and makes them interested in what's happening because they are personally implicated, that would go a long way. And seriously, if you're going to spend that money on awareness training, make it worth it. Get something that's


chunk_text:
  we need to work on. Security is a process, but we have to do something about this process and not just let things be. And last, Oh, it did not even cross my mind that I could actually be a target. I'm not that important. The result of bad training, the result of a bad cybersecurity culture, or just doing like 15 minutes per year on what social engineering attacks are and how they work in an effective way. If I had only five tips for the employees, they would be, yes, technology is still important. It does matter to minimize employee decision-making and use the principle of privilege when possible, but it's not going to be enough because we see that threat actors target them through private channels. So then on top of that, good quality training that actively engages people, that doesn't have them sit passively behind the screen and just clicking through, clicking through, clicking through, but actively engages them and makes them interested in what's happening because they are personally implicated, that would go a long way. And seriously, if you're going to spend that money on awareness training, make it worth it. Get something that's interactive. In extent, this will help you reinforce a security mindset within your organization. You will have a trainer and advocate coming and building that mindset within your employees and saying, when in doubt, go to this guy right here who's in your security department and can talk to you. These people are not strangers. They can also communicate with you. I hope you do. And ask. And in the end, also on a practical level, it helps to run simulations, to run exercises, and to reinforce good practices for people to know how to detect and respond to an attack. If you want to take it a step further, do conduct a vulnerability assessment. Open source intelligence is central to cybersecurity, both on a corporate level and on an individual level for high-value targets. If you can have a vulnerability assessment done on them internally or externally, whatever you prefer, based on those five factors we saw before, it's worth it. It can go a long way and you can take the results of that assessment, put them in the report, put them in the training that they take, and I guarantee you they will be so much more


chunk_text:
  interactive. In extent, this will help you reinforce a security mindset within your organization. You will have a trainer and advocate coming and building that mindset within your employees and saying, when in doubt, go to this guy right here who's in your security department and can talk to you. These people are not strangers. They can also communicate with you. I hope you do. And ask. And in the end, also on a practical level, it helps to run simulations, to run exercises, and to reinforce good practices for people to know how to detect and respond to an attack. If you want to take it a step further, do conduct a vulnerability assessment. Open source intelligence is central to cybersecurity, both on a corporate level and on an individual level for high-value targets. If you can have a vulnerability assessment done on them internally or externally, whatever you prefer, based on those five factors we saw before, it's worth it. It can go a long way and you can take the results of that assessment, put them in the report, put them in the training that they take, and I guarantee you they will be so much more interested to see that training that has a vulnerability assessment done on them in a diplomatic and non-accusatory manner. They will be so much more interested to hear what's happening than just getting an out-of-the-box, classic, standardized cybersecurity awareness training that has some things that relate to them, some things that don't relate to them, and in the end of the day, I want to do other things. The good news, neuroplasticity. I'm so thankful for this part of my studies. So we learned that our brains are capable of creating new behavioral pathways that can become automatic. So, for everybody that is totally frustrated and defeated with the fact that, oh, we've done so many security trainings and the materials just don't get through, this just tells you you need to find a different way to communicate the material. Neuroplasticity says that you can teach old dogs new tricks, you can create new neural pathways, and if you do it in an engaging way, eventually people will be able to create automatic mental pathways. They see the trigger, they see the red flag, and they automatically think, okay, I've heard about this before, I should be careful, let's stay


chunk_text:
  interested to see that training that has a vulnerability assessment done on them in a diplomatic and non-accusatory manner. They will be so much more interested to hear what's happening than just getting an out-of-the-box, classic, standardized cybersecurity awareness training that has some things that relate to them, some things that don't relate to them, and in the end of the day, I want to do other things. The good news, neuroplasticity. I'm so thankful for this part of my studies. So we learned that our brains are capable of creating new behavioral pathways that can become automatic. So, for everybody that is totally frustrated and defeated with the fact that, oh, we've done so many security trainings and the materials just don't get through, this just tells you you need to find a different way to communicate the material. Neuroplasticity says that you can teach old dogs new tricks, you can create new neural pathways, and if you do it in an engaging way, eventually people will be able to create automatic mental pathways. They see the trigger, they see the red flag, and they automatically think, okay, I've heard about this before, I should be careful, let's stay on the safe side. That's the whole point of neuroplasticity. These things will eventually become automatic and your people won't have to spend mental energy on them. I've seen this happening, thankfully. There is hope. This is a topic that, in general, extends both deep and wide. We only have a few minutes here, but if you are interested, I definitely recommend you read the elicitation guide from the Defense Counterintelligence and Security Agency. They talk about the elicitation techniques. You could lend parts from this guide and put them in your awareness training if you want, or if you're interested in the kill chain and more details about general social engineering attacks, I also wrote a more lengthier article that you can also get some information from. Overall, I hope you take it seriously. I know it's difficult. I know it's a process. Nobody's perfect. It's fine. But don't just let it be and don't give up on your people thinking they are just useless. There are things we can do. Thank you very much for being here. And I think we can take a few questions while we still have five minutes. Yes. Hi. There's one thing I


chunk_text:
  on the safe side. That's the whole point of neuroplasticity. These things will eventually become automatic and your people won't have to spend mental energy on them. I've seen this happening, thankfully. There is hope. This is a topic that, in general, extends both deep and wide. We only have a few minutes here, but if you are interested, I definitely recommend you read the elicitation guide from the Defense Counterintelligence and Security Agency. They talk about the elicitation techniques. You could lend parts from this guide and put them in your awareness training if you want, or if you're interested in the kill chain and more details about general social engineering attacks, I also wrote a more lengthier article that you can also get some information from. Overall, I hope you take it seriously. I know it's difficult. I know it's a process. Nobody's perfect. It's fine. But don't just let it be and don't give up on your people thinking they are just useless. There are things we can do. Thank you very much for being here. And I think we can take a few questions while we still have five minutes. Yes. Hi. There's one thing I was really interested in. Thank you for the interesting talk, by the way. But there's one thing you said that I want to hear if you could explain why this is. You said that we should expect more of these attacks in the future. What are the mechanisms that are driving that? What are the mechanisms of? That are driving an increase. The mechanisms that are driving the increase are the simple reward that they get. The fact that they are successful makes threat actors say that, okay, this is something that works more consistently so I won't be spending time and resources on attacks that have a 50% rate of success when I can just get this type of attack that has a way higher rate of success and I can do more things with it. Plus, we have been observing it. We hear more and more cases. Three or four years ago, we didn't have as many cases as we have today with people being approached through social media and getting pride to complain for whatever reason about their companies. We see a lot more of this. I think they do it because they see it works and


chunk_text:
  was really interested in. Thank you for the interesting talk, by the way. But there's one thing you said that I want to hear if you could explain why this is. You said that we should expect more of these attacks in the future. What are the mechanisms that are driving that? What are the mechanisms of? That are driving an increase. The mechanisms that are driving the increase are the simple reward that they get. The fact that they are successful makes threat actors say that, okay, this is something that works more consistently so I won't be spending time and resources on attacks that have a 50% rate of success when I can just get this type of attack that has a way higher rate of success and I can do more things with it. Plus, we have been observing it. We hear more and more cases. Three or four years ago, we didn't have as many cases as we have today with people being approached through social media and getting pride to complain for whatever reason about their companies. We see a lot more of this. I think they do it because they see it works and they see they can do a lot through it. I got a question. I got the microphone, sorry. I am a pen tester and when I work to assess vulnerability on the system, it's usually not the one who projects the project. But some platform that are used to development, integration and so on. My question is, when you do the vulnerability assessments on human beings, there is not a platform on which you can test whatever you want because you can do some eventually damages including psychological damages if you try to threaten or try to flirt with someone that is married or I don't know. I believe that you draw a line somewhere that real attackers don't. How do you deal with that and where is the line? You most certainly draw a line. You cannot approach it with a pen test point of view exactly because we deal with some ethical lines here. But this is why you draw the risk profile and you explain to the people why this is important for them. They have to give you their approval on running a test and using their social media and they do. Believe me, the ones


chunk_text:
  they see they can do a lot through it. I got a question. I got the microphone, sorry. I am a pen tester and when I work to assess vulnerability on the system, it's usually not the one who projects the project. But some platform that are used to development, integration and so on. My question is, when you do the vulnerability assessments on human beings, there is not a platform on which you can test whatever you want because you can do some eventually damages including psychological damages if you try to threaten or try to flirt with someone that is married or I don't know. I believe that you draw a line somewhere that real attackers don't. How do you deal with that and where is the line? You most certainly draw a line. You cannot approach it with a pen test point of view exactly because we deal with some ethical lines here. But this is why you draw the risk profile and you explain to the people why this is important for them. They have to give you their approval on running a test and using their social media and they do. Believe me, the ones that understand the threat and they know what it can mean for them if they trust the service provider, they are going to say, please. But of course, you ensure confidentiality. Of course, you ensure that you have a trusting relationship and that you treat them with dignity and respect. But it is happening. The vulnerability profile, the risk profile, these things you do not have to engage with the target in a way that involves them psychologically, but you just take out the information you find online from their own digital footprint and you tell them, look, this is one attack vector, my ABC, these vulnerabilities, this is how we have been observing the threat actors exploiting this information. What do you want to do? Do you want to eliminate them? Do you want to also gain the knowledge that you might encounter ABC types of attacks? This is usually how we go about it. They know they will be researched, but not engaged with. No, because you don't ask them to respond to it. You ask them to give you permission to go through their digital footprint and show them what could be used against them. No, I'm


chunk_text:
  that understand the threat and they know what it can mean for them if they trust the service provider, they are going to say, please. But of course, you ensure confidentiality. Of course, you ensure that you have a trusting relationship and that you treat them with dignity and respect. But it is happening. The vulnerability profile, the risk profile, these things you do not have to engage with the target in a way that involves them psychologically, but you just take out the information you find online from their own digital footprint and you tell them, look, this is one attack vector, my ABC, these vulnerabilities, this is how we have been observing the threat actors exploiting this information. What do you want to do? Do you want to eliminate them? Do you want to also gain the knowledge that you might encounter ABC types of attacks? This is usually how we go about it. They know they will be researched, but not engaged with. No, because you don't ask them to respond to it. You ask them to give you permission to go through their digital footprint and show them what could be used against them. No, I'm not going to chat with them. I know that if I chat with them and I use ABC, the trigger points, they are likely to respond and this is how we approach it. But you do not have to flirt with them. Yes. I wondered, while trying to protect your company, for example, we might have a risk maybe to change the mood inside the company because while saying to people, okay, be aware, of the question you are asked, they will change their behavior also and maybe your company might become a company less friendly regarding the outside and also inside. That's a very valid question. What happens when we when we rain threats on our people and tell them, don't engage online with strangers? But this is exactly where the danger lies. You do not want to tell them, remove your social media profiles. Don't talk with anyone online. No, it's what we talked about right here from the Defense, Counterintelligence and Security Agency. Talk with them. Talk with everybody. Have your online profile but know when to draw the boundaries and what boundaries to draw. What does that person that is talking with you, what shouldn't they


chunk_text:
  not going to chat with them. I know that if I chat with them and I use ABC, the trigger points, they are likely to respond and this is how we approach it. But you do not have to flirt with them. Yes. I wondered, while trying to protect your company, for example, we might have a risk maybe to change the mood inside the company because while saying to people, okay, be aware, of the question you are asked, they will change their behavior also and maybe your company might become a company less friendly regarding the outside and also inside. That's a very valid question. What happens when we when we rain threats on our people and tell them, don't engage online with strangers? But this is exactly where the danger lies. You do not want to tell them, remove your social media profiles. Don't talk with anyone online. No, it's what we talked about right here from the Defense, Counterintelligence and Security Agency. Talk with them. Talk with everybody. Have your online profile but know when to draw the boundaries and what boundaries to draw. What does that person that is talking with you, what shouldn't they know about your company and maintain that boundary in a healthy way. That's what it is about. Because of course, many of us need to have, many companies as well, they need to have an online presence. They need to engage with customers online or with partners, business partners. But the boundaries, this is my last point. We talked about not overcomplicating our solutions. In the end, it is about maintaining security best practices. Thank you. Yes, we can have one more. You choose. I'll take one. Thank you very much for an interesting talk. It's good to be back at that slide. Do you have any evidence that that works? Are people able to set boundaries and maintain them once they're approached with the right trigger points? Aren't they facing with professionals who can try out n different trigger points with different online fake personalities until it finally works? Yes, there is evidence that this works because people end up reporting it and say, hey, I've been receiving these communications and I feel extremely uncertain about it. And then they go and ask their cybersecurity department, which comes and asks us sometimes. So we have evidence that it works.


chunk_text:
  know about your company and maintain that boundary in a healthy way. That's what it is about. Because of course, many of us need to have, many companies as well, they need to have an online presence. They need to engage with customers online or with partners, business partners. But the boundaries, this is my last point. We talked about not overcomplicating our solutions. In the end, it is about maintaining security best practices. Thank you. Yes, we can have one more. You choose. I'll take one. Thank you very much for an interesting talk. It's good to be back at that slide. Do you have any evidence that that works? Are people able to set boundaries and maintain them once they're approached with the right trigger points? Aren't they facing with professionals who can try out n different trigger points with different online fake personalities until it finally works? Yes, there is evidence that this works because people end up reporting it and say, hey, I've been receiving these communications and I feel extremely uncertain about it. And then they go and ask their cybersecurity department, which comes and asks us sometimes. So we have evidence that it works. Now, of course, you can have persistent threats that try to find this one angle that will work, but it comes down to how perceptive the target is, how knowledgeable they are in terms of spotting. It is about risk management in there and increasing your defense probabilities against cyber threats. You hope that they will keep recognizing suspicious activity when it happens. Also, sometimes when you have this threat actor trying to pry from every angle, different profiles, these individuals end up realizing that, okay, I must be pretty valuable for them. And now I don't want to have to deal with this anymore and decide to mass block everybody for a bit. So, there is also that happening, but it works. Okay. One thing, it won't work with everybody because people are people, but it's about raising your probability. Yeah. Thank you very much. It was very interesting and thank you for the questions. We'll have 10 minutes break before the next talk, so feel free to rock around if you want.


chunk_text:
  Now, of course, you can have persistent threats that try to find this one angle that will work, but it comes down to how perceptive the target is, how knowledgeable they are in terms of spotting. It is about risk management in there and increasing your defense probabilities against cyber threats. You hope that they will keep recognizing suspicious activity when it happens. Also, sometimes when you have this threat actor trying to pry from every angle, different profiles, these individuals end up realizing that, okay, I must be pretty valuable for them. And now I don't want to have to deal with this anymore and decide to mass block everybody for a bit. So, there is also that happening, but it works. Okay. One thing, it won't work with everybody because people are people, but it's about raising your probability. Yeah. Thank you very much. It was very interesting and thank you for the questions. We'll have 10 minutes break before the next talk, so feel free to rock around if you want.


chunk_text:
  { "webpage_url": "https://www.youtube.com/watch?v=1cNjYx_kSdM", "title": "Turn And Face The Strange: Ch-Ch-Changes In Ransomware Techniques by Lindsay Kaye", "description": "", "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA", "duration": 1947, "channel": "scrt.insomnihack", "uploader": "scrt.insomnihack", "upload_date": "20230411" } This text was transcribed using whisper model: large-v2 All right. Hi, everyone. Thank you so much for coming to my talk today. I'm going to tell you a little bit about some of the ransomware TTP changes that we've observed over the past couple of years. My name is Lindsay Kay. I'm the Senior Director of the Advanced Reversing Malware Operations and Reconnaissance Group at NC Group at Recorded Future. So I run the technical arm of our threat intelligence team and by trade I'm a malware analyst and reverse engineer. So we have to start by the premise that just like every one of us, ransomware groups are also subject to the realities of the economy. And as a result, we see many of them innovate their tools or behavior because they want to remain successful in a very competitive market. It's not that they can just build it and the affiliates will come. But like some other innovations that didn't quite go as planned, sometimes these changes don't work out the way the threat actors intended and sometimes we actually see them backfire. So today I'm going to tell you about some of the innovations that we've observed in ransomware and talk about what made them either highly successful or less so. So over the past couple of years, there are kind of a couple of different categories of ways that we've seen lockers evolve and the ransomware actor TTPs change for a variety of threat actors. So things like new lockers spin up and spin down. We see feature additions to some of the existing ones. There have been new ways of deploying and spreading them. It's not also just C and C++ anymore, which we were used to a couple of years ago. Now we've seen languages like Golang, Rust, and Python as well. We've seen the use of additional extortion methods to really get people to pay. And we've also seen some threat actors target additional types of hardware. Some of them worked actually particularly well. So here's a couple of the categories. So first, the way that people deploy their lockers. So one of the things that we started seeing people move towards is using


chunk_text:
  out the way the threat actors intended and sometimes we actually see them backfire. So today I'm going to tell you about some of the innovations that we've observed in ransomware and talk about what made them either highly successful or less so. So over the past couple of years, there are kind of a couple of different categories of ways that we've seen lockers evolve and the ransomware actor TTPs change for a variety of threat actors. So things like new lockers spin up and spin down. We see feature additions to some of the existing ones. There have been new ways of deploying and spreading them. It's not also just C and C++ anymore, which we were used to a couple of years ago. Now we've seen languages like Golang, Rust, and Python as well. We've seen the use of additional extortion methods to really get people to pay. And we've also seen some threat actors target additional types of hardware. Some of them worked actually particularly well. So here's a couple of the categories. So first, the way that people deploy their lockers. So one of the things that we started seeing people move towards is using things like MSPs and other benign tools to start spreading them. So as you can imagine, rather than using a custom set of tools, now you have stuff that actually should be on the computers and within the organization. And that's a little bit harder to detect than something that's known malicious. Additionally, kind of on the same vein, we've seen them do some more lateral movement using things like SMB shares, CIFS, and NFS. So effectively using the way that the computers operate against them. And then finally, what we've seen is some threat actors like Alpha and some others start building impersonation tokens into the locker to allow them to spread or allow the locker to spread itself. Additionally, the optimization of some of their current offerings. So a lot of people are using intermittent encryption because they want to make lockers faster, faster is better, more damage and more profit. And adding additional functionality to lockers based on affiliate demand and kind of like looking at what other people have. And ultimately, you want to attract people. Additionally, seeing people fill the gaps in the ecosystem. So one kind of really well-known example here would be Blackmatter


chunk_text:
  things like MSPs and other benign tools to start spreading them. So as you can imagine, rather than using a custom set of tools, now you have stuff that actually should be on the computers and within the organization. And that's a little bit harder to detect than something that's known malicious. Additionally, kind of on the same vein, we've seen them do some more lateral movement using things like SMB shares, CIFS, and NFS. So effectively using the way that the computers operate against them. And then finally, what we've seen is some threat actors like Alpha and some others start building impersonation tokens into the locker to allow them to spread or allow the locker to spread itself. Additionally, the optimization of some of their current offerings. So a lot of people are using intermittent encryption because they want to make lockers faster, faster is better, more damage and more profit. And adding additional functionality to lockers based on affiliate demand and kind of like looking at what other people have. And ultimately, you want to attract people. Additionally, seeing people fill the gaps in the ecosystem. So one kind of really well-known example here would be Blackmatter and Conti coming out with a Linux and ESXi locker after Reval and DarkSide disbanded. And there weren't really any of those offerings out there. Additionally, looking at Alpha's addition of the chat access code to prevent chat hijacking, which I'll talk about later. They also have a victim files index site. So being able to search the victim's files and see them more easily makes it easier for other threat actors to kind of look around. And then finally, making their panels more user-friendly. So how can that hurt? So adding things like Bitcoin mixers, letting affiliates put in support tickets if something's broken or the features or things like that, and then helping them moderate their victims. Additionally, really trying to make the victims pay. So we've seen some additional extortion techniques. So things like DDoSing victims who won't pay, calling their board members, their customers, clients, things like that, and contacting the media to really kind of make it way more well-known that something bad has happened. And I know we all think it's kind of amusing, but printing the ransomware notes to actual physical printers has kind of an incentivization purpose as well. So it's much


chunk_text:
  and Conti coming out with a Linux and ESXi locker after Reval and DarkSide disbanded. And there weren't really any of those offerings out there. Additionally, looking at Alpha's addition of the chat access code to prevent chat hijacking, which I'll talk about later. They also have a victim files index site. So being able to search the victim's files and see them more easily makes it easier for other threat actors to kind of look around. And then finally, making their panels more user-friendly. So how can that hurt? So adding things like Bitcoin mixers, letting affiliates put in support tickets if something's broken or the features or things like that, and then helping them moderate their victims. Additionally, really trying to make the victims pay. So we've seen some additional extortion techniques. So things like DDoSing victims who won't pay, calling their board members, their customers, clients, things like that, and contacting the media to really kind of make it way more well-known that something bad has happened. And I know we all think it's kind of amusing, but printing the ransomware notes to actual physical printers has kind of an incentivization purpose as well. So it's much harder to hide a ransomware attack from the employees if the ransom note's coming out of all the printers rather than just appearing on a couple people's screens. So some things actually let something to be desired. So I know as developers, we often say, like, don't roll your own crypto. No, we seriously really don't. DarkSide and Blackmatter both had encryption flaws that made people not have to pay the ransom to decrypt. Very bad for business. We've seen several actors in the past year or so really try to do that false flag attribution thing. So I'll talk more about these, but a couple of groups include LockBit, Zing, Xiao Ransomware, and then a couple other things that came along with that. Sometimes you see some threat actors trying to make their malware harder to reverse engineer, but kind of as an artifact of it, make it more manageable. So I'll talk a little bit about the AlphaMorph Linux variant, LockBit Black, and then everybody else using the leaked Blackmatter code, and then the use of automated obfuscation like Play and Alpha did. Additionally, making your tool so secure that nobody can actually use it. Also not great


chunk_text:
  harder to hide a ransomware attack from the employees if the ransom note's coming out of all the printers rather than just appearing on a couple people's screens. So some things actually let something to be desired. So I know as developers, we often say, like, don't roll your own crypto. No, we seriously really don't. DarkSide and Blackmatter both had encryption flaws that made people not have to pay the ransom to decrypt. Very bad for business. We've seen several actors in the past year or so really try to do that false flag attribution thing. So I'll talk more about these, but a couple of groups include LockBit, Zing, Xiao Ransomware, and then a couple other things that came along with that. Sometimes you see some threat actors trying to make their malware harder to reverse engineer, but kind of as an artifact of it, make it more manageable. So I'll talk a little bit about the AlphaMorph Linux variant, LockBit Black, and then everybody else using the leaked Blackmatter code, and then the use of automated obfuscation like Play and Alpha did. Additionally, making your tool so secure that nobody can actually use it. Also not great for business. So you can see on the right part of the panel to get into the affiliate panel. So it required a Tor private key, which is significantly more challenging to implement than not. So harder to do. And then finally, when you let politics get involved. So Conti sided with Russia in the Russia-Ukraine invasion, and we'll talk about what happened after. So in kind of the spirit of Dua Lipa, I'm going to talk a little bit about the new rules of being a successful ransomware threat actor in this day and age. So first, Play Ransomware. So in case you're not familiar, Play is a relatively new but fairly active ransomware variant that we first observed in June 2022. Like many kind of more traditional ransomware variants, it's written in C++ and was first used in August 2022 against the Argentine Accord Cordoba. And then you can see some of their other victims there. Some of the notable features include, so the minimal ransom note. So if you've ever seen kind of a ransom note before, usually there's a lot of verbiage of who did it, what happens if you don't pay, very detailed instructions of


chunk_text:
  for business. So you can see on the right part of the panel to get into the affiliate panel. So it required a Tor private key, which is significantly more challenging to implement than not. So harder to do. And then finally, when you let politics get involved. So Conti sided with Russia in the Russia-Ukraine invasion, and we'll talk about what happened after. So in kind of the spirit of Dua Lipa, I'm going to talk a little bit about the new rules of being a successful ransomware threat actor in this day and age. So first, Play Ransomware. So in case you're not familiar, Play is a relatively new but fairly active ransomware variant that we first observed in June 2022. Like many kind of more traditional ransomware variants, it's written in C++ and was first used in August 2022 against the Argentine Accord Cordoba. And then you can see some of their other victims there. Some of the notable features include, so the minimal ransom note. So if you've ever seen kind of a ransom note before, usually there's a lot of verbiage of who did it, what happens if you don't pay, very detailed instructions of how to pay. You can see on the bottom, on the right, the Play Ransom Note. So very minimal, just says Play, and gives you an email to contact. Additionally, we'll talk about their addition of return-oriented programming and other added obfuscations and intermittent encryption. Yeah, so I really did say ROP and ransomware. So in case you're not super familiar with how return-oriented programming works, effectively it takes advantage of how the RET instruction works. So you can see on the right, you increment stack pointer, then you do a return. Effectively, what happens is this causes a jump to the real code, which you can see on the bottom. So this is kind of how Play implemented their return-oriented programming, which effectively makes it harder to both statically and dynamically reverse engineer. Not impossible, but that's what it looks like. And then they have a bunch of kind of garbage code bytes. So it makes a little bit harder for Kedra to kind of figure out what's going on. And a little bit of manual fix-up is required. So you can see on the left, before Play added the ROP, what their code looked like. So pretty straightforward,


chunk_text:
  how to pay. You can see on the bottom, on the right, the Play Ransom Note. So very minimal, just says Play, and gives you an email to contact. Additionally, we'll talk about their addition of return-oriented programming and other added obfuscations and intermittent encryption. Yeah, so I really did say ROP and ransomware. So in case you're not super familiar with how return-oriented programming works, effectively it takes advantage of how the RET instruction works. So you can see on the right, you increment stack pointer, then you do a return. Effectively, what happens is this causes a jump to the real code, which you can see on the bottom. So this is kind of how Play implemented their return-oriented programming, which effectively makes it harder to both statically and dynamically reverse engineer. Not impossible, but that's what it looks like. And then they have a bunch of kind of garbage code bytes. So it makes a little bit harder for Kedra to kind of figure out what's going on. And a little bit of manual fix-up is required. So you can see on the left, before Play added the ROP, what their code looked like. So pretty straightforward, pretty easy to understand, but that should give you some idea of what the difference is. So if you're a thread actor, adding obfuscation is great, but definitely consider doing it from the start. So the first Play sample that we looked at was from about mid-June 2022. So it had a couple of things. So string obfuscation. So you can see on the top right, an example of the string obfuscation. Not wildly challenging, but that's kind of the algorithm that they used. They also had an API hashing technique, so making it a little bit more challenging to do some of the static reverse engineering. But ultimately, outside of these two things, pretty easy to reverse engineer and pretty straightforward. So the additional obfuscations first came in in August 2022. So like I mentioned, the ROP, and then they also started doing some garbage code insertion. So you can see an example of the garbage code insertion. So really what this just functions to do is do nothing or nothing of use really, and just make it like you have to look at more stuff. So that's what the automated code insertion looks like. So while ROP is


chunk_text:
  pretty easy to understand, but that should give you some idea of what the difference is. So if you're a thread actor, adding obfuscation is great, but definitely consider doing it from the start. So the first Play sample that we looked at was from about mid-June 2022. So it had a couple of things. So string obfuscation. So you can see on the top right, an example of the string obfuscation. Not wildly challenging, but that's kind of the algorithm that they used. They also had an API hashing technique, so making it a little bit more challenging to do some of the static reverse engineering. But ultimately, outside of these two things, pretty easy to reverse engineer and pretty straightforward. So the additional obfuscations first came in in August 2022. So like I mentioned, the ROP, and then they also started doing some garbage code insertion. So you can see an example of the garbage code insertion. So really what this just functions to do is do nothing or nothing of use really, and just make it like you have to look at more stuff. So that's what the automated code insertion looks like. So while ROP is definitely a positive addition for them to have made, and makes the code effectively harder to reverse engineer, it's notable that the underlying functionality really didn't change. So if you reverse engineer an unobfuscated one, which is pretty easy to find on the internet, then it really kind of gives you an idea of what you're looking for in the second one. It's easy to match up. Additionally, looking at that automated garbage code insertion, it was actually pretty signaturable. So I was able to write a signature looking for how they did that, so to find other copies. So if you're trying to make your malware less signaturable, not really super successful. Okay. So additionally, if you're a threat actor, you really want to kind of give the people what they want. So intermittent encryption is something that Play implements. And what we've seen is that, like some other threat actors, they'll encrypt every other one megabyte of data. So this is something that they introduced in June 2022. So it's been there from the beginning. And the reason you want to be able to do this is because you want to encrypt as much as you can, as


chunk_text:
  definitely a positive addition for them to have made, and makes the code effectively harder to reverse engineer, it's notable that the underlying functionality really didn't change. So if you reverse engineer an unobfuscated one, which is pretty easy to find on the internet, then it really kind of gives you an idea of what you're looking for in the second one. It's easy to match up. Additionally, looking at that automated garbage code insertion, it was actually pretty signaturable. So I was able to write a signature looking for how they did that, so to find other copies. So if you're trying to make your malware less signaturable, not really super successful. Okay. So additionally, if you're a threat actor, you really want to kind of give the people what they want. So intermittent encryption is something that Play implements. And what we've seen is that, like some other threat actors, they'll encrypt every other one megabyte of data. So this is something that they introduced in June 2022. So it's been there from the beginning. And the reason you want to be able to do this is because you want to encrypt as much as you can, as fast as you can. So as you can imagine, if you're conducting a ransomware attack, the more you can encrypt, the quicker you can encrypt before somebody figures out what you're doing and stops you, the better. So more damage, more likely to pay. So doing it this way also makes it less recoverable than just encrypting the first however many bytes. So some threat actors would encrypt the first, let's say, 10 megabytes and then just leave the rest of the file. Great on small files. Not so great on files that are like 5, 6, 7 gigs, because more data to recover. Other threat actor groups are also implementing this. So some very well-known ones like Agenda, Alpha, and Black Bastard, to name a few. And you can see what the intermediate encryption looks like at the file perspective. So speaking of Alpha, they're a rebrand of Black Matter. So back in the day, we had Darkside. They attacked Colonial Pipeline, got a lot of law enforcement attention because that was very bad. So the group ultimately disbanded because there was too much attention on them. Later, they re-emerged as Black Matter, who had some decryption issues of


chunk_text:
  fast as you can. So as you can imagine, if you're conducting a ransomware attack, the more you can encrypt, the quicker you can encrypt before somebody figures out what you're doing and stops you, the better. So more damage, more likely to pay. So doing it this way also makes it less recoverable than just encrypting the first however many bytes. So some threat actors would encrypt the first, let's say, 10 megabytes and then just leave the rest of the file. Great on small files. Not so great on files that are like 5, 6, 7 gigs, because more data to recover. Other threat actor groups are also implementing this. So some very well-known ones like Agenda, Alpha, and Black Bastard, to name a few. And you can see what the intermediate encryption looks like at the file perspective. So speaking of Alpha, they're a rebrand of Black Matter. So back in the day, we had Darkside. They attacked Colonial Pipeline, got a lot of law enforcement attention because that was very bad. So the group ultimately disbanded because there was too much attention on them. Later, they re-emerged as Black Matter, who had some decryption issues of their ransomware. So people weren't having to pay the ransom to get their files decrypted. Not great for business either. So we later saw them pop back up as Alpha. And we first started to see some of their ransomware in December 2021. So they're known for a lot of their attacks on infrastructure. So Colonial Pipeline, as I mentioned, is Darkside, as well as some other ones that you can see listed there. So some of their notable features that I'll talk about is that they were the first big ransomware variant that was written in Rust. They're the first big ransomware variant with an armlocker kind of mainstream. And they have this thing called the Build Time Obfuscation Toolkit, Morph, that I'll talk about as well. Uses chat access tokens and then the Alpha Collections blog. So the searchable victim files index. So access tokens. So another thing that happened when the group was known as Black Matter is researchers happened to find a copy of their ransomware, Virus Totaler, the internet or something. They looked at the victim portal link, first engineered it, clicked on it, and accessed it. So the problem was there was an active


chunk_text:
  their ransomware. So people weren't having to pay the ransom to get their files decrypted. Not great for business either. So we later saw them pop back up as Alpha. And we first started to see some of their ransomware in December 2021. So they're known for a lot of their attacks on infrastructure. So Colonial Pipeline, as I mentioned, is Darkside, as well as some other ones that you can see listed there. So some of their notable features that I'll talk about is that they were the first big ransomware variant that was written in Rust. They're the first big ransomware variant with an armlocker kind of mainstream. And they have this thing called the Build Time Obfuscation Toolkit, Morph, that I'll talk about as well. Uses chat access tokens and then the Alpha Collections blog. So the searchable victim files index. So access tokens. So another thing that happened when the group was known as Black Matter is researchers happened to find a copy of their ransomware, Virus Totaler, the internet or something. They looked at the victim portal link, first engineered it, clicked on it, and accessed it. So the problem was there was an active victim negotiation at that time. And then everybody from the internet also joined in on that negotiation, which was very frustrating, upsetting to the threat actor. So at this point, the victim chat was useless. They couldn't negotiate, figure out who the victim was. So as a result, they had to close it down and then try and figure out who the real victim was. So they required the actual victim to provide domain controller names and domain admin names in order to kind of restart the negotiation. But obviously, this isn't great. So when the group popped back up as Alpha, they implemented something called the access token as a lock parameter. So at build time, when you build your copy as an affiliate, you get an access token. So your particular binary and your access token. And what this does is when you run the ransomware, you have to provide that proper access token to generate the correct victim link. So you can run it with kind of any access token, but you won't get to the right link. So unless you have both pieces, this prevents researchers from being able to find your ransomware on the internet


chunk_text:
  victim negotiation at that time. And then everybody from the internet also joined in on that negotiation, which was very frustrating, upsetting to the threat actor. So at this point, the victim chat was useless. They couldn't negotiate, figure out who the victim was. So as a result, they had to close it down and then try and figure out who the real victim was. So they required the actual victim to provide domain controller names and domain admin names in order to kind of restart the negotiation. But obviously, this isn't great. So when the group popped back up as Alpha, they implemented something called the access token as a lock parameter. So at build time, when you build your copy as an affiliate, you get an access token. So your particular binary and your access token. And what this does is when you run the ransomware, you have to provide that proper access token to generate the correct victim link. So you can run it with kind of any access token, but you won't get to the right link. So unless you have both pieces, this prevents researchers from being able to find your ransomware on the internet and then also do the same thing that happened before. So effectively, now you're creating a more secure line of communication with your victims. You can't just find the victim page through sample detonation. So Rust. So this, again, is the first big ransomware written in Rust. So previously, we generally saw things like CC++. Sometimes you'll see Delphi. Often you'll see Golang lately. Ficker Stealer is written in Rust as well. Pretty popular stealer. But in terms of ransomware, that was kind of really it at the time. So part of the benefit of using Rust is that it's cross-compilable. So you write one set of code, and then you can get out of it at Windows, Linux, and Armlogger, which is pretty good. And as a bonus, what I'm very familiar with is that reverse engineering at the time was significantly more challenging for a couple reasons. So library functions. It's not always apparent that it is a library function. So sometimes they'll look like non-library interesting code. So if you're trying to reverse engineer a very large binary, which generally the Rust ones are, and you're trying to find kind of the interesting stuff to look at,


chunk_text:
  and then also do the same thing that happened before. So effectively, now you're creating a more secure line of communication with your victims. You can't just find the victim page through sample detonation. So Rust. So this, again, is the first big ransomware written in Rust. So previously, we generally saw things like CC++. Sometimes you'll see Delphi. Often you'll see Golang lately. Ficker Stealer is written in Rust as well. Pretty popular stealer. But in terms of ransomware, that was kind of really it at the time. So part of the benefit of using Rust is that it's cross-compilable. So you write one set of code, and then you can get out of it at Windows, Linux, and Armlogger, which is pretty good. And as a bonus, what I'm very familiar with is that reverse engineering at the time was significantly more challenging for a couple reasons. So library functions. It's not always apparent that it is a library function. So sometimes they'll look like non-library interesting code. So if you're trying to reverse engineer a very large binary, which generally the Rust ones are, and you're trying to find kind of the interesting stuff to look at, it's a little more complicated than like CC++, stuff like that. Additionally, you'll see a lot of the runtime code in the binary. So things like error handling. So if you can see in the top image, you see kind of the code, and then you see a lot of that error handling code in that. So what it functions to do is just make a binary kind of bigger, more stuff to look at, and you have to kind of scroll through it and kind of ignore that as you start doing reverse engineering. Additionally, if you're familiar with Golang, like Golang, the strings are not null terminated. So what this does is you can see in the bottom image here, so it runs them all together, requires some kind of preprocessing, like fix up that you have to do, to start figuring out where all the strings go. And kind of on that same vein, right now the fix up tools are significantly more nascent than if Golang. So when Golang started being a big thing, didn't really have a lot of fix up tools. So we're kind of in that stage with Rust. So, yeah, continuing. I


chunk_text:
  it's a little more complicated than like CC++, stuff like that. Additionally, you'll see a lot of the runtime code in the binary. So things like error handling. So if you can see in the top image, you see kind of the code, and then you see a lot of that error handling code in that. So what it functions to do is just make a binary kind of bigger, more stuff to look at, and you have to kind of scroll through it and kind of ignore that as you start doing reverse engineering. Additionally, if you're familiar with Golang, like Golang, the strings are not null terminated. So what this does is you can see in the bottom image here, so it runs them all together, requires some kind of preprocessing, like fix up that you have to do, to start figuring out where all the strings go. And kind of on that same vein, right now the fix up tools are significantly more nascent than if Golang. So when Golang started being a big thing, didn't really have a lot of fix up tools. So we're kind of in that stage with Rust. So, yeah, continuing. I did, in fact, say an arm locker. So the way that the group advertises this is that you can use this to target different NAS devices. So QNAP, Synology, and other ones like that. It's meant to be used in parallel to your Windows and Linux and ESXi lockers. So, obviously, you can lock Windows systems or Linux and ESXi ones, but you can use it in parallel to your lockers. So, obviously, you can lock Windows systems or Linux and ESXi ones where people might host a lot of their infrastructure, things like that. But now you can also go after their backups and uncommon file share types. So really the purpose of this is to increase the ultimate effectiveness of a ransomware attack. So obviously, the more you can encrypt, the less kind of recoverable it is for the company. And previously, if you weren't able to encrypt kind of their backups and uncommon file shares, now you are. So that's kind of one more sort of safety net the company might have had that now don't have anymore. So to date, I haven't really seen it used in the wild at all. That's not to say that


chunk_text:
  did, in fact, say an arm locker. So the way that the group advertises this is that you can use this to target different NAS devices. So QNAP, Synology, and other ones like that. It's meant to be used in parallel to your Windows and Linux and ESXi lockers. So, obviously, you can lock Windows systems or Linux and ESXi ones, but you can use it in parallel to your lockers. So, obviously, you can lock Windows systems or Linux and ESXi ones where people might host a lot of their infrastructure, things like that. But now you can also go after their backups and uncommon file share types. So really the purpose of this is to increase the ultimate effectiveness of a ransomware attack. So obviously, the more you can encrypt, the less kind of recoverable it is for the company. And previously, if you weren't able to encrypt kind of their backups and uncommon file shares, now you are. So that's kind of one more sort of safety net the company might have had that now don't have anymore. So to date, I haven't really seen it used in the wild at all. That's not to say that it won't be, but so far so, that's where we are. And ultimately, though, ARM lockers really aren't super common to see, especially not by, like, big ransomware groups. So Chaos Ransomware and some other groups also have one, but in terms of kind of those big names, this is the first one we've seen. So moving on to AlphaMorph. So AlphaMorph was advertised as an obfuscation toolkit, so both for their Windows and their Linux. So the way that they advertised it is it will help the malware evade AV detection kind of through the automated obfuscation of strings and garbage code addition. So as promised, the Windows version did, in fact, have string obfuscation. So the way that they do it is a very simple one-byte XOR. So randomly chosen single byte and then randomly generated code to de-obfuscate it. So you can see on the left the de-obfuscation function for the strings. Really, the only kind of salient point is the XORing of the value with eight. The rest of it's garbage code. So when you kind of look at AlphaMorph-generated files in general, what you'll see is you'll see a lot of global kind of arithmetic


chunk_text:
  it won't be, but so far so, that's where we are. And ultimately, though, ARM lockers really aren't super common to see, especially not by, like, big ransomware groups. So Chaos Ransomware and some other groups also have one, but in terms of kind of those big names, this is the first one we've seen. So moving on to AlphaMorph. So AlphaMorph was advertised as an obfuscation toolkit, so both for their Windows and their Linux. So the way that they advertised it is it will help the malware evade AV detection kind of through the automated obfuscation of strings and garbage code addition. So as promised, the Windows version did, in fact, have string obfuscation. So the way that they do it is a very simple one-byte XOR. So randomly chosen single byte and then randomly generated code to de-obfuscate it. So you can see on the left the de-obfuscation function for the strings. Really, the only kind of salient point is the XORing of the value with eight. The rest of it's garbage code. So when you kind of look at AlphaMorph-generated files in general, what you'll see is you'll see a lot of global kind of arithmetic operations that have no purpose, and you can kind of see some of them there. So generally what their garbage code insertion looks like. Another thing that's notable about the Windows morph obfuscation is that the binaries were now over four times the size of their unobfuscated versions. So the rest binaries are actually pretty big, right? They're about three megabytes, and the obfuscated versions were about 14. So significantly bigger. And most of the size increase was in the text, data, and relocation section, primarily because of how, I guess, this obfuscation does work. So that's where the biggest increases are. So it's really important as a thread actor though to check your work. So they also offered it for their Linux and ESXi builds. So looking at it, didn't actually see any string obfuscation at all. So that was not as promised. However, if you look at the Linux x64 morph obfuscated samples, now what you see is like, if you're familiar with the concept of name mangling, you start to see instead of kind of the scrub names, you start to see like versions of sort of name mangled function names. So you could see on the


chunk_text:
  operations that have no purpose, and you can kind of see some of them there. So generally what their garbage code insertion looks like. Another thing that's notable about the Windows morph obfuscation is that the binaries were now over four times the size of their unobfuscated versions. So the rest binaries are actually pretty big, right? They're about three megabytes, and the obfuscated versions were about 14. So significantly bigger. And most of the size increase was in the text, data, and relocation section, primarily because of how, I guess, this obfuscation does work. So that's where the biggest increases are. So it's really important as a thread actor though to check your work. So they also offered it for their Linux and ESXi builds. So looking at it, didn't actually see any string obfuscation at all. So that was not as promised. However, if you look at the Linux x64 morph obfuscated samples, now what you see is like, if you're familiar with the concept of name mangling, you start to see instead of kind of the scrub names, you start to see like versions of sort of name mangled function names. So you could see on the left for the unobfuscated Linux versions, functions don't have any names with the word locker in it. Those are all the exported variables, nothing kind of untoward or that really gives you some idea of what this is doing. However, if you look on the right, you can see the obfuscated x64 Linux and ESXi samples. So you start to see some of those function names kind of coming out, which if you do reverse engineering, you're like, yes, now I can start figuring out what's going on. Function names are very helpful, but very rarely seen. So you start to see like some of the locker core kind of concept stuff. And you start to see in the 32-bit samples, the exported variables from the obfuscated ones, you can start to see some of that similar name mangling. So they no longer offer this. I'm not entirely sure why, but so it's not available anymore. But yeah, no, really checking your work is actually super important if you are going to build a locker, especially. So something that we've seen is that fully testing the encryption and decryption, while very critical, there have been several mistakes over the past


chunk_text:
  left for the unobfuscated Linux versions, functions don't have any names with the word locker in it. Those are all the exported variables, nothing kind of untoward or that really gives you some idea of what this is doing. However, if you look on the right, you can see the obfuscated x64 Linux and ESXi samples. So you start to see some of those function names kind of coming out, which if you do reverse engineering, you're like, yes, now I can start figuring out what's going on. Function names are very helpful, but very rarely seen. So you start to see like some of the locker core kind of concept stuff. And you start to see in the 32-bit samples, the exported variables from the obfuscated ones, you can start to see some of that similar name mangling. So they no longer offer this. I'm not entirely sure why, but so it's not available anymore. But yeah, no, really checking your work is actually super important if you are going to build a locker, especially. So something that we've seen is that fully testing the encryption and decryption, while very critical, there have been several mistakes over the past couple of years. So again, this is something to check because that's how you make money, encrypting people's files. So a very kind of recent example, if everybody remembers ESXi args from like a month ago, the first version, what they were doing is they were again, using intermittent encryption. However, they would encrypt one megabyte and then skip X based on some calculation that determined that X is approximately 1% of the file size. So great again, if the file is small, but if you have a 450 gigabyte VM image, let's say, which might be on ESXi, you'd encrypt one megabyte, skip about four and a half gigs and then encrypt one megabyte. So what happened is this made it recovery possible for those very large files because it was so small the amount that they were encrypting at a time. Version two actually fixed this bug. Next, Luna Ransomware. So they had an ESXi locker in about 2022. And generally, if you look at ESXi lockers, what happens is they find all the VMs, they will shut them down, and then they will encrypt them. So what Luna did is they did not do this. They just


chunk_text:
  couple of years. So again, this is something to check because that's how you make money, encrypting people's files. So a very kind of recent example, if everybody remembers ESXi args from like a month ago, the first version, what they were doing is they were again, using intermittent encryption. However, they would encrypt one megabyte and then skip X based on some calculation that determined that X is approximately 1% of the file size. So great again, if the file is small, but if you have a 450 gigabyte VM image, let's say, which might be on ESXi, you'd encrypt one megabyte, skip about four and a half gigs and then encrypt one megabyte. So what happened is this made it recovery possible for those very large files because it was so small the amount that they were encrypting at a time. Version two actually fixed this bug. Next, Luna Ransomware. So they had an ESXi locker in about 2022. And generally, if you look at ESXi lockers, what happens is they find all the VMs, they will shut them down, and then they will encrypt them. So what Luna did is they did not do this. They just encrypted them without shutting them down, which as you're probably familiar with, might mean that when you try to decrypt them, they're now corrupted. Also very bad for business if you're not actually encrypting people's files after you've made them pay and you promised to do so. Next, Blackmatter and DarkSide. I alluded to this before. So because they decided to roll their own crypto, what this meant is that there was a cryptographic flaw that allowed researchers to help decrypt some of their victims without payment. So obviously, super embarrassing. In addition to some of the other stuff that happened to Blackmatter, ultimately led to them rebranding as Alipha. And then finally, Rook Ransomware in about 2019. So they had a buggy decryptor that didn't work on large files. Again, also bad for business. So this is definitely something that, while not like a super big trend, keeps happening. So potentially in the future, as ransomware actors keep writing their lockers, something that we expect to maybe see in the future. So moving on to Lockbit. So they're one of the most active ransomware groups today. So their original version was written in Origin-C and they've been around since


chunk_text:
  encrypted them without shutting them down, which as you're probably familiar with, might mean that when you try to decrypt them, they're now corrupted. Also very bad for business if you're not actually encrypting people's files after you've made them pay and you promised to do so. Next, Blackmatter and DarkSide. I alluded to this before. So because they decided to roll their own crypto, what this meant is that there was a cryptographic flaw that allowed researchers to help decrypt some of their victims without payment. So obviously, super embarrassing. In addition to some of the other stuff that happened to Blackmatter, ultimately led to them rebranding as Alipha. And then finally, Rook Ransomware in about 2019. So they had a buggy decryptor that didn't work on large files. Again, also bad for business. So this is definitely something that, while not like a super big trend, keeps happening. So potentially in the future, as ransomware actors keep writing their lockers, something that we expect to maybe see in the future. So moving on to Lockbit. So they're one of the most active ransomware groups today. So their original version was written in Origin-C and they've been around since September 2019. So here's a couple of their victims, but they've had many over the past 4 years. So some of their notable features are Steelbit, the automated data exfiltration tool. They're recruiting of insiders. So we haven't seen other ransomware groups do this, but they were offering money payment jobs to people who are in organizations to provide initial access to that organization. So if you provide a way in for Lockbit to your organization, they'll pay you. It's not something we've seen other people do. And additionally, I'll talk about what happened when their builder got leaked. So after Blackmatter fired all the developers, after all the decryption issues, and then got the new guy who writes Rust, Lockbit seems to have acquired the code. So this spun up a variant of Lockbit called Lockbit Black. Rumor has it though, after the developer was hired or the code was used, was disgruntled for whatever reason, and then he then leaked some Lockbit Black code. So what this now means, this is available to anybody who wants it. And because it has a customizable configuration, anybody can actually modify it. So now we start seeing some ransomware group spinoffs,


chunk_text:
  September 2019. So here's a couple of their victims, but they've had many over the past 4 years. So some of their notable features are Steelbit, the automated data exfiltration tool. They're recruiting of insiders. So we haven't seen other ransomware groups do this, but they were offering money payment jobs to people who are in organizations to provide initial access to that organization. So if you provide a way in for Lockbit to your organization, they'll pay you. It's not something we've seen other people do. And additionally, I'll talk about what happened when their builder got leaked. So after Blackmatter fired all the developers, after all the decryption issues, and then got the new guy who writes Rust, Lockbit seems to have acquired the code. So this spun up a variant of Lockbit called Lockbit Black. Rumor has it though, after the developer was hired or the code was used, was disgruntled for whatever reason, and then he then leaked some Lockbit Black code. So what this now means, this is available to anybody who wants it. And because it has a customizable configuration, anybody can actually modify it. So now we start seeing some ransomware group spinoffs, such as Bloody Ransomware, who can now use this pretty easily. Kind of in a similar vein, the most recent sort of Lockbit variant that we've seen is called Lockbit Green. So Conti's leaked source code by the Ukrainian researcher now looks like Lockbit acquired it and then built their own variant. So the reason we think that this is now not Conti is there's a new ESXi variant for it. And looking at some of the Tor-based URLs in Lockbit samples, they belong to Lockbit, not Conti. So now there's kind of three major variants, Green, Black, and Original. So looking at Lockbit Black. So I looked substantially at Blackmatter Ransomware. So when Lockbit Black came out, I was very curious. So here are both of the entry functions. So Lockbit Black looked at least from the outset very much like Blackmatter Ransomware. So you can kind of see, pretty similar. The only kind of really big salient difference is the do decrypt in Lockbit at the top, which I'll talk about. But this wasn't all of it. So if you're an aspiring threat actor, totally fine to borrow other people's code and definitely find opportunities for improvement where


chunk_text:
  such as Bloody Ransomware, who can now use this pretty easily. Kind of in a similar vein, the most recent sort of Lockbit variant that we've seen is called Lockbit Green. So Conti's leaked source code by the Ukrainian researcher now looks like Lockbit acquired it and then built their own variant. So the reason we think that this is now not Conti is there's a new ESXi variant for it. And looking at some of the Tor-based URLs in Lockbit samples, they belong to Lockbit, not Conti. So now there's kind of three major variants, Green, Black, and Original. So looking at Lockbit Black. So I looked substantially at Blackmatter Ransomware. So when Lockbit Black came out, I was very curious. So here are both of the entry functions. So Lockbit Black looked at least from the outset very much like Blackmatter Ransomware. So you can kind of see, pretty similar. The only kind of really big salient difference is the do decrypt in Lockbit at the top, which I'll talk about. But this wasn't all of it. So if you're an aspiring threat actor, totally fine to borrow other people's code and definitely find opportunities for improvement where you can. So there are other similarities there too. So kind of outside just that entry function, the high level structure of the code was extremely similar. The API hashing technique that they use, their string hashing for the command line options. So you can see what that looks like. The string hash is on the top. So instead of saying, comparing like an ASCII string to an ASCII string to whatever came in, what they do is they hash the string that they're looking for and hash the input, compare those. So it just makes it a little more challenging to statically reverse engineer because then you have to figure out all your different options there. The configuration file decryption also pretty much the same as some of the newer versions of Blackmatter. And then finally, the anti-debugging techniques and the combination thereof that they used. So one kind of well-known example is the crash if a breakpoint is placed on the thread. So there are some differences as well. So some of the LockBit Black versions require a password to decrypt. So if you don't provide the right password, can't decrypt, won't run. So other groups have done


chunk_text:
  you can. So there are other similarities there too. So kind of outside just that entry function, the high level structure of the code was extremely similar. The API hashing technique that they use, their string hashing for the command line options. So you can see what that looks like. The string hash is on the top. So instead of saying, comparing like an ASCII string to an ASCII string to whatever came in, what they do is they hash the string that they're looking for and hash the input, compare those. So it just makes it a little more challenging to statically reverse engineer because then you have to figure out all your different options there. The configuration file decryption also pretty much the same as some of the newer versions of Blackmatter. And then finally, the anti-debugging techniques and the combination thereof that they used. So one kind of well-known example is the crash if a breakpoint is placed on the thread. So there are some differences as well. So some of the LockBit Black versions require a password to decrypt. So if you don't provide the right password, can't decrypt, won't run. So other groups have done this in the past. Greger, kind of a well-known one, but some of these versions require that. In addition, they started accepting additional command line parameters. So adding additional functionality that you as an affiliate can use to run the ransomware. So a couple of examples are the group policy modification and self-deletion. So you can see on the bottom, the LockBit Black program command line argument parsing. So you can see some of those additional options there. Structure, very, very similar to how Blackmatter did it, but now with these additional options. You can see that string comparison or the hash comparison as well. And then finally, the configuration data flags. So in response to this additional functionality, there were some additional configuration data flags that were required. So those also appeared. So also consider Kemion Improving. So after the release of LockBit Black and I guess LockBit Green, they've been actually pretty consistent. So we don't see as much change over time in kind of that original logger's other groups. So maybe their MO is going to be requiring other kind of leaked code and building variants from that. It's unclear right now. So as I alluded to,


chunk_text:
  this in the past. Greger, kind of a well-known one, but some of these versions require that. In addition, they started accepting additional command line parameters. So adding additional functionality that you as an affiliate can use to run the ransomware. So a couple of examples are the group policy modification and self-deletion. So you can see on the bottom, the LockBit Black program command line argument parsing. So you can see some of those additional options there. Structure, very, very similar to how Blackmatter did it, but now with these additional options. You can see that string comparison or the hash comparison as well. And then finally, the configuration data flags. So in response to this additional functionality, there were some additional configuration data flags that were required. So those also appeared. So also consider Kemion Improving. So after the release of LockBit Black and I guess LockBit Green, they've been actually pretty consistent. So we don't see as much change over time in kind of that original logger's other groups. So maybe their MO is going to be requiring other kind of leaked code and building variants from that. It's unclear right now. So as I alluded to, some of the samples had the requirement of the decrypt function. Some of the newer ones don't. This seems to be like a builder option. So you can choose to include it or not include it. So we'll probably continue to see both. Like I mentioned, Gregor used the password-based decryption of their malware pretty successfully. So it was hard enough to find kind of a Gregor sample that you could reverse engineer because you also have to have the correct password or you can't decrypt it. So if you're trying to prevent people from reverse engineering your actual kind of ransomware, kind of a useful feature. And as a bonus, I mentioned Steelbit. So a lot of ransomware groups, obviously to extort their victims, want to take victim files and exfiltrate them so they can use them in the extortion process. So Lockbit has something called Steelbit. So it just automates the data exfiltration process of the victim files. And then it uploads them to the leak site for the affiliate. Very handy. So I also talked a little bit about something that was false flag. So Lockbit is one of the groups that does this. So when Recorded


chunk_text:
  some of the samples had the requirement of the decrypt function. Some of the newer ones don't. This seems to be like a builder option. So you can choose to include it or not include it. So we'll probably continue to see both. Like I mentioned, Gregor used the password-based decryption of their malware pretty successfully. So it was hard enough to find kind of a Gregor sample that you could reverse engineer because you also have to have the correct password or you can't decrypt it. So if you're trying to prevent people from reverse engineering your actual kind of ransomware, kind of a useful feature. And as a bonus, I mentioned Steelbit. So a lot of ransomware groups, obviously to extort their victims, want to take victim files and exfiltrate them so they can use them in the extortion process. So Lockbit has something called Steelbit. So it just automates the data exfiltration process of the victim files. And then it uploads them to the leak site for the affiliate. Very handy. So I also talked a little bit about something that was false flag. So Lockbit is one of the groups that does this. So when Recorded Future interviewed them, Lockbit advised they definitely live in China. None of their affiliates live in the United States or Russia. So the concerns that we were raising to them about, you know, for people who live in Russia, the U.S. and stuff, definitely did not apply to them. We also see some threat actors try and do or kind of false flag as China-based or China-associated threat actors. You'll see them post some machine-translated Chinese ask about ransomware. So you can see on the bottom here an example of the post. So I don't read Chinese, but I talked to one of my co-workers who does, and he advises it's definitely not correct. So this gives you some idea of kind of what you're looking at for when I'm talking about that. So a forum, Ramp, also welcomes Chinese speakers. So they're trying to attract some Chinese threat actors and ransomware gangs. Not entirely sure why, but that's kind of what it looks like on the bottom left. So sometimes this just doesn't work out. They don't really super false flag very effectively in general. So Yanlu Wang was a ransomware group purporting to be China-associated. But what happened


chunk_text:
  Future interviewed them, Lockbit advised they definitely live in China. None of their affiliates live in the United States or Russia. So the concerns that we were raising to them about, you know, for people who live in Russia, the U.S. and stuff, definitely did not apply to them. We also see some threat actors try and do or kind of false flag as China-based or China-associated threat actors. You'll see them post some machine-translated Chinese ask about ransomware. So you can see on the bottom here an example of the post. So I don't read Chinese, but I talked to one of my co-workers who does, and he advises it's definitely not correct. So this gives you some idea of kind of what you're looking at for when I'm talking about that. So a forum, Ramp, also welcomes Chinese speakers. So they're trying to attract some Chinese threat actors and ransomware gangs. Not entirely sure why, but that's kind of what it looks like on the bottom left. So sometimes this just doesn't work out. They don't really super false flag very effectively in general. So Yanlu Wang was a ransomware group purporting to be China-associated. But what happened is that some of the chats belonging to them, their group, were leaked. So they were not, in fact, Chinese, and all the chats were in Russian. So they were Russian speakers. So kind of one great way to reveal yourself. But we can sometimes also see it in the But we can sometimes also see it in their code. So for example, I looked at something that purported to be Xiao Ransomware. Great. Drops this note. Doesn't explicitly call out being China-associated, but that was some of the forum and branding and stuff like that. But you can kind of see the note there. So looking at where I ran it, looking at the command line output, you can see that it says Revix 1.1. So back in the day, when Revol was still kind of very active in their original form, they had a Linux locker called Revix. So it had the exact same kind of printout. I recognize that was a little confused. So obviously, this is not Xiao. Seems like they just kind of re-skinned the original Revix, suggesting maybe they acquired the code or maybe related actors. So talked a lot about all these changes.


chunk_text:
  is that some of the chats belonging to them, their group, were leaked. So they were not, in fact, Chinese, and all the chats were in Russian. So they were Russian speakers. So kind of one great way to reveal yourself. But we can sometimes also see it in the But we can sometimes also see it in their code. So for example, I looked at something that purported to be Xiao Ransomware. Great. Drops this note. Doesn't explicitly call out being China-associated, but that was some of the forum and branding and stuff like that. But you can kind of see the note there. So looking at where I ran it, looking at the command line output, you can see that it says Revix 1.1. So back in the day, when Revol was still kind of very active in their original form, they had a Linux locker called Revix. So it had the exact same kind of printout. I recognize that was a little confused. So obviously, this is not Xiao. Seems like they just kind of re-skinned the original Revix, suggesting maybe they acquired the code or maybe related actors. So talked a lot about all these changes. And we, as kind of defenders, want to hunt them. So kind of the way that I would advise is face the strange, right? So looking for what's weird or kind of what's unique or kind of interesting and fun about a lot of this stuff is kind of a great way to track them. So as I mentioned, some of the automated obfuscation techniques, they'll often leave artifacts. So like Play and Alpha, maybe they were custom, maybe they weren't. But this automated way of doing it allows you to start creating signatures to look for other versions. Maybe other people are using that same technique to start kind of looking for other variants there as well. While it is better if they're custom, because that kind of is more group-associated, still pretty entertaining to find other people using that same technique. Also looking for inconsistencies in some language or strings. So especially their ransom notes. So Agenda, for example, purported to have a Linux version. Hadn't really seen it published on in the wild extensively. So I wanted to find one. So what we did was we looked in the ransom note. There was kind of some weird


chunk_text:
  And we, as kind of defenders, want to hunt them. So kind of the way that I would advise is face the strange, right? So looking for what's weird or kind of what's unique or kind of interesting and fun about a lot of this stuff is kind of a great way to track them. So as I mentioned, some of the automated obfuscation techniques, they'll often leave artifacts. So like Play and Alpha, maybe they were custom, maybe they weren't. But this automated way of doing it allows you to start creating signatures to look for other versions. Maybe other people are using that same technique to start kind of looking for other variants there as well. While it is better if they're custom, because that kind of is more group-associated, still pretty entertaining to find other people using that same technique. Also looking for inconsistencies in some language or strings. So especially their ransom notes. So Agenda, for example, purported to have a Linux version. Hadn't really seen it published on in the wild extensively. So I wanted to find one. So what we did was we looked in the ransom note. There was kind of some weird verbiage and sort of misspellings. Being able to sort of pivot off that allowed us to find one, which was really cool. Also looking at some of the anti-debugging, anti-analysis, and anti-RE techniques. Not necessarily just kind of in individual, but sometimes the combination thereof. So if they're using enough combination of them and kind of custom ones, especially the string obfuscations generally seem to be pretty unique. That's a good way to start finding other ones. The implementation of the crypto algorithms. So one of the things that Blackmatter and DarkSide did was they had kind of a strange combination of crypto algorithms that were only really seen before. So the one in Blackmatter was only seen necessarily before DarkSide. Kind of a good way to start looking at some of that overlap there. Any other buggy anomalies. So code that should work that doesn't. Code that doesn't really do anything, but looks like it should do something that they just, I guess, left in there and doesn't really have any effect. So kind of some fun things to track there. And being able to stay up on the latest affiliate news. So you can see Alpha's announcement of


chunk_text:
  verbiage and sort of misspellings. Being able to sort of pivot off that allowed us to find one, which was really cool. Also looking at some of the anti-debugging, anti-analysis, and anti-RE techniques. Not necessarily just kind of in individual, but sometimes the combination thereof. So if they're using enough combination of them and kind of custom ones, especially the string obfuscations generally seem to be pretty unique. That's a good way to start finding other ones. The implementation of the crypto algorithms. So one of the things that Blackmatter and DarkSide did was they had kind of a strange combination of crypto algorithms that were only really seen before. So the one in Blackmatter was only seen necessarily before DarkSide. Kind of a good way to start looking at some of that overlap there. Any other buggy anomalies. So code that should work that doesn't. Code that doesn't really do anything, but looks like it should do something that they just, I guess, left in there and doesn't really have any effect. So kind of some fun things to track there. And being able to stay up on the latest affiliate news. So you can see Alpha's announcement of Morph. So you start to get an idea of like, okay, they've come out with this new thing. Let me start looking for it. Let me figure out how to get it and signature it. So to kind of get an idea of kind of what's coming out now. And if you want to start looking for some of the similarities, like I mentioned, a lot of these builders are leaked. Some are improved upon, some are not. So looking for code reuse between families. So if there's a leaked builder and you're trying to look for other groups that may be using this builder, being able to signature for that, start mapping that out that way. And also if you're trying to look for ransomware, maybe some not super huge ones or kind of newer variants, being able to look for some of that ransom note language, it's all pretty common, I would say. So things like what happened, your network and Tor project are a couple examples there. And with that, thank you so much. Any questions? So there's a couple of different ones that they use for initial access. So obviously phishing is super popular. So they


chunk_text:
  Morph. So you start to get an idea of like, okay, they've come out with this new thing. Let me start looking for it. Let me figure out how to get it and signature it. So to kind of get an idea of kind of what's coming out now. And if you want to start looking for some of the similarities, like I mentioned, a lot of these builders are leaked. Some are improved upon, some are not. So looking for code reuse between families. So if there's a leaked builder and you're trying to look for other groups that may be using this builder, being able to signature for that, start mapping that out that way. And also if you're trying to look for ransomware, maybe some not super huge ones or kind of newer variants, being able to look for some of that ransom note language, it's all pretty common, I would say. So things like what happened, your network and Tor project are a couple examples there. And with that, thank you so much. Any questions? So there's a couple of different ones that they use for initial access. So obviously phishing is super popular. So they will also look to do some sort of exploitation of like some of the internet facing services. So with the whole move a couple of years ago to everybody starting to work from home with the pandemic, we saw a lot of people exploiting vulnerabilities for those kind of like perimeter type devices and the remote work tools as well. But yeah, phishing is really popular, I'm going to say. It's very effective. Anybody else? Okay. Well, thank you so much.


chunk_text:
  will also look to do some sort of exploitation of like some of the internet facing services. So with the whole move a couple of years ago to everybody starting to work from home with the pandemic, we saw a lot of people exploiting vulnerabilities for those kind of like perimeter type devices and the remote work tools as well. But yeah, phishing is really popular, I'm going to say. It's very effective. Anybody else? Okay. Well, thank you so much.


chunk_text:
  { "webpage_url": "https://www.youtube.com/watch?v=UIreUeVrczM", "title": "A Ticket Worth Waiting 65 Years For by Charlie Bromberg", "description": "", "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA", "duration": 3099, "channel": "scrt.insomnihack", "uploader": "scrt.insomnihack", "upload_date": "20230411" } This text was transcribed using whisper model: large-v2 Test, test, everyone can hear me? All right. Hello, everyone. Hello, Lausanne. It's been a while now, it's been a year. It's great to see you all in these tough times. And before starting with my talk, I'd like to tell you a little story, the backstory behind it. A few months ago, I was doing a penetration testing at a client's, and I don't know for you all, but I have like a to-do list of maybe 20 or 200 links, blog posts, slides to read, to research. Of course, I never do this because the list is too long, but it's there. I keep it all there. If someone like me is doing some bookmarks on Twitter, you know it's useless, but you still do it anyway, that's me. And I was doing a penetration test, and in my bookmarks, I had two links that I really wanted to research and understand. And those were A Diamond Ticket in the Rough, which was a variation of The Golden Ticket for Kerberos, and the other one was How to Do Resource-Based Constrained Delegation with a Normal User, something written by James Forshaw. And if you don't know him already, he's the kind of guy that writes something you will never understand, even if you read it 20 times. So it was there. So it was just standing there, and during my penetration test, you know, standard thing, you just plug yourself, your domain admin, in two minutes or so. And I had some time, and I wanted to research it, and I had the good opportunity to do it because I could do RBCD, but I didn't control a computer account. And for those of you who manipulate Kerberos on the day-to-day, they know that doing RBCD with a normal user account is something that sometimes could be really useful. So I was just researching it, and then I was reading it, implementing it, and while I was implementing it, I was like, man, there's something to do with, like, we could combine those two ideas of The Diamond Ticket and the normal user RBCD stuff. And that's exactly what I'm going to talk


chunk_text:
  a variation of The Golden Ticket for Kerberos, and the other one was How to Do Resource-Based Constrained Delegation with a Normal User, something written by James Forshaw. And if you don't know him already, he's the kind of guy that writes something you will never understand, even if you read it 20 times. So it was there. So it was just standing there, and during my penetration test, you know, standard thing, you just plug yourself, your domain admin, in two minutes or so. And I had some time, and I wanted to research it, and I had the good opportunity to do it because I could do RBCD, but I didn't control a computer account. And for those of you who manipulate Kerberos on the day-to-day, they know that doing RBCD with a normal user account is something that sometimes could be really useful. So I was just researching it, and then I was reading it, implementing it, and while I was implementing it, I was like, man, there's something to do with, like, we could combine those two ideas of The Diamond Ticket and the normal user RBCD stuff. And that's exactly what I'm going to talk to you about right now. So the title of this conference is A Ticket Worth Waiting 65 Years For. My name is Charlie Bromberg, and I will leave this slide for a few seconds. If you want to access the slide deck, it's right here, shutdown.page.link slash ENS23. I-N-S 23. One, two, three, let's go. So here is the table of contents. The first thing is we'll do some reminders, some refresher course about Active Directory and Kerberos. By a show of hands, who is manipulating Active Directory on a day-to-day basis? Few people. Don't be shy. Someone that knows a little bit about Active Directory by a show of hands? Ah, that's a bit more. All right. And who among you perfectly understands Kerberos? Please shout if you do. All right. So that's what I thought. I didn't shout. The second part, we'll be forging tickets. We'll talk about golden tickets, silver tickets, MS14068. It's the kind of stuff that's so old you'll never find a useful resource on the internet. So I'll talk about it. And then we'll talk about diamond tickets, which is a nice variation of the golden tickets, and sapphire tickets. So just before talking


chunk_text:
  to you about right now. So the title of this conference is A Ticket Worth Waiting 65 Years For. My name is Charlie Bromberg, and I will leave this slide for a few seconds. If you want to access the slide deck, it's right here, shutdown.page.link slash ENS23. I-N-S 23. One, two, three, let's go. So here is the table of contents. The first thing is we'll do some reminders, some refresher course about Active Directory and Kerberos. By a show of hands, who is manipulating Active Directory on a day-to-day basis? Few people. Don't be shy. Someone that knows a little bit about Active Directory by a show of hands? Ah, that's a bit more. All right. And who among you perfectly understands Kerberos? Please shout if you do. All right. So that's what I thought. I didn't shout. The second part, we'll be forging tickets. We'll talk about golden tickets, silver tickets, MS14068. It's the kind of stuff that's so old you'll never find a useful resource on the internet. So I'll talk about it. And then we'll talk about diamond tickets, which is a nice variation of the golden tickets, and sapphire tickets. So just before talking about sapphire tickets, we'll do some requirements, theoretical parts, which are S4U2SELF extension, user-to-user authentication, and then the combination of those two. Just for some timekeeping, by the time I'm finished with S4U2SELF plus U2U, you'll probably be asleep, so I'll just do a reminder to get back on the conference. And at the end, I will wrap things up, and we'll probably have some time for a Q&A. Don't be too excited. The demo gods are never with me, so the demos are prerecorded. It's screenshots, but I did it. It's tested. But sadly, I didn't exchange with Microsoft until 1 a.m. this morning, like Jerkan did. So this is me. Yep. Other colors, but that's all right. My name is Charlie Bromberg. You may also know me on the social networks, or if you don't, that's all right, by the nickname Shutdown. If you reverse it, that's my Twitter handle. My day job is I work at Capgemini as a head of Pentest. I mean, that's a pompous title, but what I do day-to-day is technically lead the change for our penetration testing offerings. So I mean, that's there. If you want to talk about penetration testing, that's


chunk_text:
  about sapphire tickets, we'll do some requirements, theoretical parts, which are S4U2SELF extension, user-to-user authentication, and then the combination of those two. Just for some timekeeping, by the time I'm finished with S4U2SELF plus U2U, you'll probably be asleep, so I'll just do a reminder to get back on the conference. And at the end, I will wrap things up, and we'll probably have some time for a Q&A. Don't be too excited. The demo gods are never with me, so the demos are prerecorded. It's screenshots, but I did it. It's tested. But sadly, I didn't exchange with Microsoft until 1 a.m. this morning, like Jerkan did. So this is me. Yep. Other colors, but that's all right. My name is Charlie Bromberg. You may also know me on the social networks, or if you don't, that's all right, by the nickname Shutdown. If you reverse it, that's my Twitter handle. My day job is I work at Capgemini as a head of Pentest. I mean, that's a pompous title, but what I do day-to-day is technically lead the change for our penetration testing offerings. So I mean, that's there. If you want to talk about penetration testing, that's my stuff. If you want to talk about detection and mitigation, please don't talk to me. My night jobs are listed there. You may know some resources or tools that I have created or contributed to, naming a few of the hacker recipes, which is a set of theoretical and practical guides on hacking, of course, but you'll find some Easter eggs as well. Exegol, which is, well, by a show of hands, who uses Kali Linux? All right. Okay, you can stop using Kali Linux and start using Exegol now. Not wanting to be mean, but I mean, we are all professionals here. And my known locations is here. I live in the south of France, meaning that to come here, I had two choices. Either come by train, which would have been cancelled with the strikes going on, or come by car. So if you see me yawning, that's because I came by car and I'm really tired. So let's get to it now. Active Directory and Kerberos. Let's do some reminders. Active Directory, when we're talking about AD, we usually refer to ADDS, which is Active Directory Domain Services. But it's not limited to this. We have


chunk_text:
  my stuff. If you want to talk about detection and mitigation, please don't talk to me. My night jobs are listed there. You may know some resources or tools that I have created or contributed to, naming a few of the hacker recipes, which is a set of theoretical and practical guides on hacking, of course, but you'll find some Easter eggs as well. Exegol, which is, well, by a show of hands, who uses Kali Linux? All right. Okay, you can stop using Kali Linux and start using Exegol now. Not wanting to be mean, but I mean, we are all professionals here. And my known locations is here. I live in the south of France, meaning that to come here, I had two choices. Either come by train, which would have been cancelled with the strikes going on, or come by car. So if you see me yawning, that's because I came by car and I'm really tired. So let's get to it now. Active Directory and Kerberos. Let's do some reminders. Active Directory, when we're talking about AD, we usually refer to ADDS, which is Active Directory Domain Services. But it's not limited to this. We have ADDS, ADCS, ADFS, ADSS, ADSS, whatever. And those services are usually very connected, and the domain services is usually the core. It allows users, groups, devices, permissions, whatever, to work between themselves. And then you have some things that revolve around it, like certificate services, federation services, site services, and whatever. Active Directory Domain Services allows users and groups and resources to coexist. And in order to do that, in order to allow that, it implements authentication protocols, network authentication protocols. So to name a few, NTLM and Kerberos are the two major ones by a show of hands. Do you know the exact difference between NTLM and Kerberos? Okay, I'll remind it. NTLM works in a three-way handshake manner. The client asks the domain controller for access to a service. It negotiates the authentication. The service sends a challenge. This challenge is hashed and whatever. And this proves that the user has knowledge of its password. And then the service verifies that data with the domain controller. On Kerberos, it works a bit differently. It works with tickets. And the user that wants to access a resource communicates with the KDC, the Key Distribution Center, beforehand. It obtains something


chunk_text:
  ADDS, ADCS, ADFS, ADSS, ADSS, whatever. And those services are usually very connected, and the domain services is usually the core. It allows users, groups, devices, permissions, whatever, to work between themselves. And then you have some things that revolve around it, like certificate services, federation services, site services, and whatever. Active Directory Domain Services allows users and groups and resources to coexist. And in order to do that, in order to allow that, it implements authentication protocols, network authentication protocols. So to name a few, NTLM and Kerberos are the two major ones by a show of hands. Do you know the exact difference between NTLM and Kerberos? Okay, I'll remind it. NTLM works in a three-way handshake manner. The client asks the domain controller for access to a service. It negotiates the authentication. The service sends a challenge. This challenge is hashed and whatever. And this proves that the user has knowledge of its password. And then the service verifies that data with the domain controller. On Kerberos, it works a bit differently. It works with tickets. And the user that wants to access a resource communicates with the KDC, the Key Distribution Center, beforehand. It obtains something called a TGT, which is a ticket granting ticket. And this first ticket allows to obtain service tickets, which are the tickets that must be presented to the services we want to have access to. On NTLM, the core of NTLM, the secrets behind NTLM are NT and LM hashes. This must not be confused with NTLM, NetNTLM. Those are very different things. I'll talk about it more later on. On Kerberos, the secrets Kerberos relies on are four types, DES, RC4, AES-128, and 256. And there's only one common key between NTLM and Kerberos. It's the NT hash, which corresponds to the RC4 key. All right. So here, I'd like to talk to you about something, is the difference on the offensive point of view between NTLM and Kerberos. What you might see here is that for NTLM we have a few attacks, like NTLM relay, NTM capture past the hash. And for Kerberos, you have, like, I don't know how many shenanigans and offensive point of views there. Please don't exit insomniac thinking that Kerberos is more vulnerable than NTLM. NTLM is dark shit. Please disable it, please. What I want to do here is just highlight the


chunk_text:
  called a TGT, which is a ticket granting ticket. And this first ticket allows to obtain service tickets, which are the tickets that must be presented to the services we want to have access to. On NTLM, the core of NTLM, the secrets behind NTLM are NT and LM hashes. This must not be confused with NTLM, NetNTLM. Those are very different things. I'll talk about it more later on. On Kerberos, the secrets Kerberos relies on are four types, DES, RC4, AES-128, and 256. And there's only one common key between NTLM and Kerberos. It's the NT hash, which corresponds to the RC4 key. All right. So here, I'd like to talk to you about something, is the difference on the offensive point of view between NTLM and Kerberos. What you might see here is that for NTLM we have a few attacks, like NTLM relay, NTM capture past the hash. And for Kerberos, you have, like, I don't know how many shenanigans and offensive point of views there. Please don't exit insomniac thinking that Kerberos is more vulnerable than NTLM. NTLM is dark shit. Please disable it, please. What I want to do here is just highlight the fact that Kerberos, having only Kerberos, is not keeping you safe. It's not perfect out of the box. You have to configure it. You have to harden it. And Kerberos is vulnerable to some abuses. So to name a few, pre-authentication brute force, pass the ticket, pass the cache, whatever, pass the certificate, overpass the hash, golden and sable tickets, I'll talk to you about it. You have to pass the host, asterisk host, Kerberos, and whatnot. Those vulnerabilities are listed in a mind map that I listed here. And you probably can't see it, so I invite you to go to the link and see the mind map in a bigger form. Don't mix up terminology between NTLM, NTLM, net NTLM, and whatever. Please, if you think you are not sure about the terms you are using, refer to this mind map. If you are sure you are using the right terminology, refer to this mind map. So now let's talk a bit about Kerberos authentication. It works in three major times, major steps. The first one is the pre-authentication. The first step allows the user that wants to access a resource to obtain the first ticket, the TGT.


chunk_text:
  fact that Kerberos, having only Kerberos, is not keeping you safe. It's not perfect out of the box. You have to configure it. You have to harden it. And Kerberos is vulnerable to some abuses. So to name a few, pre-authentication brute force, pass the ticket, pass the cache, whatever, pass the certificate, overpass the hash, golden and sable tickets, I'll talk to you about it. You have to pass the host, asterisk host, Kerberos, and whatnot. Those vulnerabilities are listed in a mind map that I listed here. And you probably can't see it, so I invite you to go to the link and see the mind map in a bigger form. Don't mix up terminology between NTLM, NTLM, net NTLM, and whatever. Please, if you think you are not sure about the terms you are using, refer to this mind map. If you are sure you are using the right terminology, refer to this mind map. So now let's talk a bit about Kerberos authentication. It works in three major times, major steps. The first one is the pre-authentication. The first step allows the user that wants to access a resource to obtain the first ticket, the TGT. This ticket is linked to this user. It includes everything about the user. And in order to obtain this TGT that later on allows to obtain other tickets, the user must prove that he has knowledge of his password. So this is the pre-authentication step. On a side note, this can be disabled for some users, but I'm not going to go into the details of this. This is called asterisk host. Then once the user has the TGT, he will be able to use it if he has his own session key. The TGT includes something called a PAK, Privileged Attribute Certificate, and in this PAK, you'll find all the information regarding the user. So his identifier, the groups he's a member of, et cetera, et cetera, his various flags and various settings about the user. So when he has this TGT, by presenting this TGT to the key distribution center, usually the domain controller, he'll be able to obtain service tickets. And those service tickets, not to be confused with TGS, which TGS is a service, not a ticket, this ST allows to access services. It allows to authenticate over services. And then the service itself, once receiving


chunk_text:
  This ticket is linked to this user. It includes everything about the user. And in order to obtain this TGT that later on allows to obtain other tickets, the user must prove that he has knowledge of his password. So this is the pre-authentication step. On a side note, this can be disabled for some users, but I'm not going to go into the details of this. This is called asterisk host. Then once the user has the TGT, he will be able to use it if he has his own session key. The TGT includes something called a PAK, Privileged Attribute Certificate, and in this PAK, you'll find all the information regarding the user. So his identifier, the groups he's a member of, et cetera, et cetera, his various flags and various settings about the user. So when he has this TGT, by presenting this TGT to the key distribution center, usually the domain controller, he'll be able to obtain service tickets. And those service tickets, not to be confused with TGS, which TGS is a service, not a ticket, this ST allows to access services. It allows to authenticate over services. And then the service itself, once receiving the ticket and once decrypting it, is able to tell if the user has the right or not to access it. So it's two different steps. The first one, user authenticates to the service, and then the service gives access or not. This is Kerberos. These are Kerberos tickets. What's the difference between TGT and service tickets? Well, the difference is very, it's a little difference. The tickets are the same, they have the same structure, they include the same PAK. The only difference is the service name, the S name. And the ticket, the S name, refers to the target service the ticket is issued for. For TGT, the target service is the KRB-TGT, which is the central authority for Kerberos. And for service tickets, the service name, the target service, well, it refers to the target service. So, for example, here on the service tickets, I gave the example of CIFS server.domain.local, which is the target service. Another difference here is the PAK. In the TGT, the privileged attribute certificate is protected by the KRB-TGT long-term key, which is the password variation, the password derivation. And on service tickets, the PAK is protected with the target service long-term


chunk_text:
  the ticket and once decrypting it, is able to tell if the user has the right or not to access it. So it's two different steps. The first one, user authenticates to the service, and then the service gives access or not. This is Kerberos. These are Kerberos tickets. What's the difference between TGT and service tickets? Well, the difference is very, it's a little difference. The tickets are the same, they have the same structure, they include the same PAK. The only difference is the service name, the S name. And the ticket, the S name, refers to the target service the ticket is issued for. For TGT, the target service is the KRB-TGT, which is the central authority for Kerberos. And for service tickets, the service name, the target service, well, it refers to the target service. So, for example, here on the service tickets, I gave the example of CIFS server.domain.local, which is the target service. Another difference here is the PAK. In the TGT, the privileged attribute certificate is protected by the KRB-TGT long-term key, which is the password variation, the password derivation. And on service tickets, the PAK is protected with the target service long-term key, which if you understood the difference between TGT and ST, it's exactly the same thing. On TGT, the target service is the KRB-TGT, so the PAK is protected with its long-term key. So, that's the difference between TGTs and service tickets. It's minimal. All right. Now that you have perfectly understood the differences between NTLM and Kerberos and how Kerberos works in Active Directory domain services, perfectly understood the differences between TGTs and service tickets, we can move on to forging those tickets. Shortly put, if we are able to forge tickets, valid tickets, we should be able to access services or act on behalf of someone else. So, the first step here is we'll talk about silver tickets. By show of hands, who knows what a silver ticket is already? All right. Some people already. So, I'll still explain it. What we need to know when we build silver tickets is the target service long-term key. When we build a silver ticket, we actually build a service ticket, an ST. To remind this, it's very easy. Silver tickets, acronym ST, service ticket ST, you know. So, what we need to know is the target service long-term key. We


chunk_text:
  key, which if you understood the difference between TGT and ST, it's exactly the same thing. On TGT, the target service is the KRB-TGT, so the PAK is protected with its long-term key. So, that's the difference between TGTs and service tickets. It's minimal. All right. Now that you have perfectly understood the differences between NTLM and Kerberos and how Kerberos works in Active Directory domain services, perfectly understood the differences between TGTs and service tickets, we can move on to forging those tickets. Shortly put, if we are able to forge tickets, valid tickets, we should be able to access services or act on behalf of someone else. So, the first step here is we'll talk about silver tickets. By show of hands, who knows what a silver ticket is already? All right. Some people already. So, I'll still explain it. What we need to know when we build silver tickets is the target service long-term key. When we build a silver ticket, we actually build a service ticket, an ST. To remind this, it's very easy. Silver tickets, acronym ST, service ticket ST, you know. So, what we need to know is the target service long-term key. We also need to know the domain SID, the username, the user RID, whatever we want to put in the privilege attribute certificate in the pack. So, for instance, if we want to act as the domain admin, we have to find the domain admin's username, its RID, all his attributes, and put them all in the pack. And we'll be able to forge the pack since we know the secret key that should be used to encrypt it, which is the target service long-term key. I included some notes here. When we forge a silver ticket, some detection notes, we have no communication at all with the KDC. So, there's that. It's a nice touch. So, for detection software, it's a bit harder to detect maybe. But again, I'm not a detection expert, so please don't ask me questions about it. And then another note is that silver ticket in some cases can be used when doing some lateral movement or privilege escalation, whereas golden ticket is usually referred to a persistence technique. Why? It's because the silver ticket allows access to service, and if we know this service's long-term key, which is a key that's easier to obtain, we'll


chunk_text:
  also need to know the domain SID, the username, the user RID, whatever we want to put in the privilege attribute certificate in the pack. So, for instance, if we want to act as the domain admin, we have to find the domain admin's username, its RID, all his attributes, and put them all in the pack. And we'll be able to forge the pack since we know the secret key that should be used to encrypt it, which is the target service long-term key. I included some notes here. When we forge a silver ticket, some detection notes, we have no communication at all with the KDC. So, there's that. It's a nice touch. So, for detection software, it's a bit harder to detect maybe. But again, I'm not a detection expert, so please don't ask me questions about it. And then another note is that silver ticket in some cases can be used when doing some lateral movement or privilege escalation, whereas golden ticket is usually referred to a persistence technique. Why? It's because the silver ticket allows access to service, and if we know this service's long-term key, which is a key that's easier to obtain, we'll be able to access that service as an admin, for example. So, on the diagram, you'll see exactly what I explained here. The first step is the attacker forges his silver ticket, makes an access request by giving his silver ticket to the target service, and then the target service decrypts the pack with his own long-term key, sees that the pack reflects the values of the domain admin, and the domain admin usually has administrator access to the service, so we're good to go. Here is the demo. So, I included some screenshots, and everything I'm going to show you is with Linux or at least with Python with impact. If you want me to show you some examples of how we use Ruby, well, I won't, so please don't talk to me about using Windows. I don't use Windows. I break it. So the first step is we have to obtain the SID, which is the unique security identifier of the domain. You'll see it here. It's S1521 blah, blah, blah. This SID, once we know it, and once we know the target service SPN, which is the value that refers to the target service, and we know


chunk_text:
  be able to access that service as an admin, for example. So, on the diagram, you'll see exactly what I explained here. The first step is the attacker forges his silver ticket, makes an access request by giving his silver ticket to the target service, and then the target service decrypts the pack with his own long-term key, sees that the pack reflects the values of the domain admin, and the domain admin usually has administrator access to the service, so we're good to go. Here is the demo. So, I included some screenshots, and everything I'm going to show you is with Linux or at least with Python with impact. If you want me to show you some examples of how we use Ruby, well, I won't, so please don't talk to me about using Windows. I don't use Windows. I break it. So the first step is we have to obtain the SID, which is the unique security identifier of the domain. You'll see it here. It's S1521 blah, blah, blah. This SID, once we know it, and once we know the target service SPN, which is the value that refers to the target service, and we know the target service long-term key, we can mix that up in the ticketer command line here, and we'll generate a ticket. So it's something called somerandomuser.ccache. Do we want to analyze that ticket? Yes. We want to understand how it's structured. So here's the first step. I'm using describeTicket, which is another script of impactKit. I'm not sure it's been merged already. Not sure. But, I mean, it's there somewhere on the internet, and by giving the target service long-term key, we'll be able to decrypt ourself the pack, the ticket, and see the values that – see that we indeed have forged a valid silver ticket. We can see here that the service name refers to host slash sv1.domain.local, which is our target service. And if we go into the pack, we can see that the user error ID is 500, which usually refers to the domain admin, the built-in domain admin. We can see the group ID, group error IDs. We can see, for example, that his member of the domain admins, Shama admins – well, this is a domain admin. So with this pack, with this forged pack and this forged ticket, we should be able to


chunk_text:
  the target service long-term key, we can mix that up in the ticketer command line here, and we'll generate a ticket. So it's something called somerandomuser.ccache. Do we want to analyze that ticket? Yes. We want to understand how it's structured. So here's the first step. I'm using describeTicket, which is another script of impactKit. I'm not sure it's been merged already. Not sure. But, I mean, it's there somewhere on the internet, and by giving the target service long-term key, we'll be able to decrypt ourself the pack, the ticket, and see the values that – see that we indeed have forged a valid silver ticket. We can see here that the service name refers to host slash sv1.domain.local, which is our target service. And if we go into the pack, we can see that the user error ID is 500, which usually refers to the domain admin, the built-in domain admin. We can see the group ID, group error IDs. We can see, for example, that his member of the domain admins, Shama admins – well, this is a domain admin. So with this pack, with this forged pack and this forged ticket, we should be able to access the service. That's what I'm showing you here. In the bottom part of the screenshot, you can see that I'm using SecretsDump to do a credential dumping, remote credential dumping on sv1. It works. Everything in green are the credentials. And on the upper part of the screenshot, I tried to do the same thing with another target service, which was the domain controller. It didn't work, because if I want to target another service, I'll have to forge another service ticket. So that's the silver ticket. Let's now talk about the golden ticket. The golden ticket is very similar, but instead of forging a ticket for a specific service, we forge a ticket for the KBGT, we forge a TGT, and this allows us to ask for any service ticket. So it's very similar. What we need to know is still the target service's long-term key, and here the target service is KBGT, so we need to know his LT key. What we build here is the same thing. We build a forged pack and a forged ticket, and in the diagram on the right, you can see that the first step is the attacker builds, forges his


chunk_text:
  access the service. That's what I'm showing you here. In the bottom part of the screenshot, you can see that I'm using SecretsDump to do a credential dumping, remote credential dumping on sv1. It works. Everything in green are the credentials. And on the upper part of the screenshot, I tried to do the same thing with another target service, which was the domain controller. It didn't work, because if I want to target another service, I'll have to forge another service ticket. So that's the silver ticket. Let's now talk about the golden ticket. The golden ticket is very similar, but instead of forging a ticket for a specific service, we forge a ticket for the KBGT, we forge a TGT, and this allows us to ask for any service ticket. So it's very similar. What we need to know is still the target service's long-term key, and here the target service is KBGT, so we need to know his LT key. What we build here is the same thing. We build a forged pack and a forged ticket, and in the diagram on the right, you can see that the first step is the attacker builds, forges his TGT, his golden ticket, uses this TGT, his forged TGT, to obtain a service ticket for a target service, and then use that service ticket to access said service. Some notes here. As of November 2021, Microsoft updated some things, and now in the ticket, we have to give a valid username. Right before, and here in those screenshots, I'm using some random user, which doesn't exist in my Active Directory setup, but as of November 2021, for updated domain controllers, you'll have to use a valid username. The problem with golden ticket, it's been here for a while, people know about it, they know how to detect it, I mean, most of them, so high detection probabilities, and you have a high probability also of messing up the pack. Since you forged everything, you forged the ticket, you forged the pack, well, if there's a mismatch somewhere, ticket duration, expiration, whatever, the flags, well, you'll be detected. So that's the issue with golden ticket, and that's the reason behind the diamond ticket ID, which is an improvement over the golden ticket. This issue is mitigated with something called golden copy, which is a utility that relies on Neo4j databases


chunk_text:
  TGT, his golden ticket, uses this TGT, his forged TGT, to obtain a service ticket for a target service, and then use that service ticket to access said service. Some notes here. As of November 2021, Microsoft updated some things, and now in the ticket, we have to give a valid username. Right before, and here in those screenshots, I'm using some random user, which doesn't exist in my Active Directory setup, but as of November 2021, for updated domain controllers, you'll have to use a valid username. The problem with golden ticket, it's been here for a while, people know about it, they know how to detect it, I mean, most of them, so high detection probabilities, and you have a high probability also of messing up the pack. Since you forged everything, you forged the ticket, you forged the pack, well, if there's a mismatch somewhere, ticket duration, expiration, whatever, the flags, well, you'll be detected. So that's the issue with golden ticket, and that's the reason behind the diamond ticket ID, which is an improvement over the golden ticket. This issue is mitigated with something called golden copy, which is a utility that relies on Neo4j databases for Bloodhound, and it retrieves all the information about the target user to impersonate, and prepares a ticketer command so that you don't mess up your pack. But still, you'll have default values put by some scripts, and you'll have a high probability of messing up things. Some screenshots, same thing, first step, we get the SID of the domain, second step, we build, we forge the golden ticket. Now, we don't need the target SPN anymore, since we are not building a service ticket, we are building a TGT, and if we analyze that ticket, we can see that the service name here is krbtgt slash domain.local, which means we are working here with a TGT. In the pack, you'll see the exact same thing as before, we are indeed acting as the domain admin. If we use it, now it's the little difference, we can still do some remote credential dumping on SVO1, but we have also the ability to do this with the domain controller. Since we are acting as a domain admin with HastyTGT, we are able to obtain any service ticket we want. Now let's talk a bit about MS14068. By a show of hands,


chunk_text:
  for Bloodhound, and it retrieves all the information about the target user to impersonate, and prepares a ticketer command so that you don't mess up your pack. But still, you'll have default values put by some scripts, and you'll have a high probability of messing up things. Some screenshots, same thing, first step, we get the SID of the domain, second step, we build, we forge the golden ticket. Now, we don't need the target SPN anymore, since we are not building a service ticket, we are building a TGT, and if we analyze that ticket, we can see that the service name here is krbtgt slash domain.local, which means we are working here with a TGT. In the pack, you'll see the exact same thing as before, we are indeed acting as the domain admin. If we use it, now it's the little difference, we can still do some remote credential dumping on SVO1, but we have also the ability to do this with the domain controller. Since we are acting as a domain admin with HastyTGT, we are able to obtain any service ticket we want. Now let's talk a bit about MS14068. By a show of hands, who has heard about this vulnerability? Who wants to explain it here? No one knows how it works, it's very complicated, and the main reason behind it is that the resources that exist on the internet, there are a few of them. Not now, since a few years ago, or months ago, I'm not sure, Hack the Box, which is a learning platform, introduced a machine that was vulnerable to this, so now you are able to find some write-ups about it, but it's still not as documented as other more recent attacks. On a side note, this is a vulnerability, this is not an abuse. What this means is that on updated, on patched machines, this will not work, it's not an abuse, a logical abuse, it's a vulnerability, meaning it was patched. In Microsoft patterns, this was not a feature. So it referred to CVE-2014-63-24, and I'll not go into the details about the crypto behind it because, no, no, please, don't ask questions about crypto. What we need to know here are domain SIDs or credentials, SIDs, et cetera. The main difference with golden tickets, silver tickets, et cetera, is that we need valid credentials in the


chunk_text:
  who has heard about this vulnerability? Who wants to explain it here? No one knows how it works, it's very complicated, and the main reason behind it is that the resources that exist on the internet, there are a few of them. Not now, since a few years ago, or months ago, I'm not sure, Hack the Box, which is a learning platform, introduced a machine that was vulnerable to this, so now you are able to find some write-ups about it, but it's still not as documented as other more recent attacks. On a side note, this is a vulnerability, this is not an abuse. What this means is that on updated, on patched machines, this will not work, it's not an abuse, a logical abuse, it's a vulnerability, meaning it was patched. In Microsoft patterns, this was not a feature. So it referred to CVE-2014-63-24, and I'll not go into the details about the crypto behind it because, no, no, please, don't ask questions about crypto. What we need to know here are domain SIDs or credentials, SIDs, et cetera. The main difference with golden tickets, silver tickets, et cetera, is that we need valid credentials in the domain. That's it. And we need to have a vulnerable KDC, of course, something that wasn't patched. What we do here, we'll rely on the diagram on the right, I'm not sure if you'll be able to see it, so I'll just do some audio description. The first step is we want to obtain a TGT for a standard user. That's the first step. So let's say the standard user is called Bob. Bob obtains his own TGT. Then Bob, side note, the TGT must be requested without a pack, that's it. Then the attacker proceeds to forging a pack, just like the golden tickets attack. And then he'll be able to put that pack, that forged pack, into the valid TGT for Bob, which means that TGT will be valid, it will be signed, everything will be fine, but it will include a pack that makes him act as a domain admin. So we'll have a superpower TGT. Then just like the golden tickets, no, not just like the golden tickets, sorry, once the TGT, the MS14068 ticket is forged, we will proceed to ask for a TGT, but not with a standard TGT request, we'll do this with


chunk_text:
  domain. That's it. And we need to have a vulnerable KDC, of course, something that wasn't patched. What we do here, we'll rely on the diagram on the right, I'm not sure if you'll be able to see it, so I'll just do some audio description. The first step is we want to obtain a TGT for a standard user. That's the first step. So let's say the standard user is called Bob. Bob obtains his own TGT. Then Bob, side note, the TGT must be requested without a pack, that's it. Then the attacker proceeds to forging a pack, just like the golden tickets attack. And then he'll be able to put that pack, that forged pack, into the valid TGT for Bob, which means that TGT will be valid, it will be signed, everything will be fine, but it will include a pack that makes him act as a domain admin. So we'll have a superpower TGT. Then just like the golden tickets, no, not just like the golden tickets, sorry, once the TGT, the MS14068 ticket is forged, we will proceed to ask for a TGT, but not with a standard TGT request, we'll do this with a service ticket request. That's a bit different, but I mean, now you know it. Once we have the TGT issued by the service ticket request, we'll be able to ask for other service tickets, that's it. If you want to go into more details about it, I wrote some things in the hacker.recipes. Let's see how it works. First step, I'm using RPC client to find the unprivileged user SID. My unprivileged user is James, and his SID is here. It ends with 1103. Once we have this SID, we use MS14068.py script, which is from the PyKEK repo, if I remember correctly. And by using James' credentials, his username and his password, as well as his SID, we'll talk with the domain controller, do the steps detailed before in the diagram, and obtain something here, which is a ticket for James. We can see here that the username is James. But if we inspect the pack, we can see that now James is a member of many overpowered groups. So we'll be able to act as the domain admin, but we're James. But I mean, MS14068, that's it. If we use the ticket, we are, just like all


chunk_text:
  a service ticket request. That's a bit different, but I mean, now you know it. Once we have the TGT issued by the service ticket request, we'll be able to ask for other service tickets, that's it. If you want to go into more details about it, I wrote some things in the hacker.recipes. Let's see how it works. First step, I'm using RPC client to find the unprivileged user SID. My unprivileged user is James, and his SID is here. It ends with 1103. Once we have this SID, we use MS14068.py script, which is from the PyKEK repo, if I remember correctly. And by using James' credentials, his username and his password, as well as his SID, we'll talk with the domain controller, do the steps detailed before in the diagram, and obtain something here, which is a ticket for James. We can see here that the username is James. But if we inspect the pack, we can see that now James is a member of many overpowered groups. So we'll be able to act as the domain admin, but we're James. But I mean, MS14068, that's it. If we use the ticket, we are, just like all the tickets, able to dump things from the domain controller. This is an example on the Hack the Box machine, which is called Mentis. So if you want to do this at home, you have the ability to do so by firing up the Mentis machine on Hack the Box. Now let's talk about diamond tickets. We talked about silver, golden, and the MS14068 vulnerability. What is the gold ticket? Show of hands, who has heard or seen the blog posts of Andy Schwarz and Charlie Clark about the diamond ticket in the rough? Okay, some people. Who have read it? Yep. Who understood it? Yeah, of course. Of course. Dirk-Jan, you're not, no, you're not in the equation. All right, let's talk about diamond tickets. So what we need to know, the requirements behind the diamond ticket are very similar to the golden tickets. The only addition here is we have to know active credentials. The main difference between golden tickets and diamond tickets is we are forging something on the fly. Instead of forging the ticket, forging the TGT, forging the pack, et cetera, we are using a valid ticket. We are just replacing on the fly the


chunk_text:
  the tickets, able to dump things from the domain controller. This is an example on the Hack the Box machine, which is called Mentis. So if you want to do this at home, you have the ability to do so by firing up the Mentis machine on Hack the Box. Now let's talk about diamond tickets. We talked about silver, golden, and the MS14068 vulnerability. What is the gold ticket? Show of hands, who has heard or seen the blog posts of Andy Schwarz and Charlie Clark about the diamond ticket in the rough? Okay, some people. Who have read it? Yep. Who understood it? Yeah, of course. Of course. Dirk-Jan, you're not, no, you're not in the equation. All right, let's talk about diamond tickets. So what we need to know, the requirements behind the diamond ticket are very similar to the golden tickets. The only addition here is we have to know active credentials. The main difference between golden tickets and diamond tickets is we are forging something on the fly. Instead of forging the ticket, forging the TGT, forging the pack, et cetera, we are using a valid ticket. We are just replacing on the fly the right values so that we are not messing up like I said before, the pack values, the ticket values, et cetera. So here in the diagram on the right, we are asking for an unprivileged user ticket, still Bob. Once we obtain the TGT for Bob, we intercept it locally. We just mess around, forge a golden ticket-like pack, and include it in the ticket. And for some more advanced implementations of this technique, we are not replacing fully the pack. We are just replacing, decrypting the pack, and replacing the right values inside of it. So that's it. That's how diamond ticket works. And once this is done, you have something very similar to a golden ticket, but better. Some notes here. The theory behind the diamond ticket is that the pack is modified, not fully replaced. The thing is, in real life, in packet implementation, the pack is fully forged. So this is an issue because you still have some probability of messing up things in the pack. So, if someone here does some Python, GPT-4, whatever, please improve this script. I don't have the time nor courage to do so. So the conclusion of the diamond ticket


chunk_text:
  right values so that we are not messing up like I said before, the pack values, the ticket values, et cetera. So here in the diagram on the right, we are asking for an unprivileged user ticket, still Bob. Once we obtain the TGT for Bob, we intercept it locally. We just mess around, forge a golden ticket-like pack, and include it in the ticket. And for some more advanced implementations of this technique, we are not replacing fully the pack. We are just replacing, decrypting the pack, and replacing the right values inside of it. So that's it. That's how diamond ticket works. And once this is done, you have something very similar to a golden ticket, but better. Some notes here. The theory behind the diamond ticket is that the pack is modified, not fully replaced. The thing is, in real life, in packet implementation, the pack is fully forged. So this is an issue because you still have some probability of messing up things in the pack. So, if someone here does some Python, GPT-4, whatever, please improve this script. I don't have the time nor courage to do so. So the conclusion of the diamond ticket technique is that Ticket Mucho Bueno, which means like, unlike the golden ticket, the probability of messing up things in the pack is a bit lower. However, you're doing active things on the network, so there's that. If you are inspecting Windows events on the domain controller, whatever, and things go up very quickly, I mean, that's some detection possibility right here. Here's how it works. In order to forge the ticket, you still do the same thing. Use Ticketer. Ticketer does this. As I said, it's not perfect, but it does this. You just have to add the dash request flag, which indicates that you are using active credentials in the domain, and you'll be doing some diamond ticket here. And then in the second highlight, you'll see the credentials I'm using. And once this is done, you are with your new diamond ticket. We can see here, the service name still indicates Carbee TGT, so we are working with a TGT. And if we inspect the pack, we'll see, just like the golden ticket, a fully forged pack. And that's the issue here. Rubius, I think, doesn't do this and replaces the right values inside the pack. And


chunk_text:
  technique is that Ticket Mucho Bueno, which means like, unlike the golden ticket, the probability of messing up things in the pack is a bit lower. However, you're doing active things on the network, so there's that. If you are inspecting Windows events on the domain controller, whatever, and things go up very quickly, I mean, that's some detection possibility right here. Here's how it works. In order to forge the ticket, you still do the same thing. Use Ticketer. Ticketer does this. As I said, it's not perfect, but it does this. You just have to add the dash request flag, which indicates that you are using active credentials in the domain, and you'll be doing some diamond ticket here. And then in the second highlight, you'll see the credentials I'm using. And once this is done, you are with your new diamond ticket. We can see here, the service name still indicates Carbee TGT, so we are working with a TGT. And if we inspect the pack, we'll see, just like the golden ticket, a fully forged pack. And that's the issue here. Rubius, I think, doesn't do this and replaces the right values inside the pack. And Packet just gives a new pack. Fully forged. Same thing as the golden ticket. We are working with an OP TGT. We can do anything we want, as long as the domain admin has the rights. Here is the implementation limit, so now there's no excuse for you to do this. Line 323 in Ticketer, you'll find that whether we are working with the request flag or not, the pack is fully forged with the createBasicPack function. This is the issue. We should have something like, if we are not using dash request, we are forging something from the ground up, and if we are working with the dash request, we are just modifying the right values. That's it. However, Ticketer is not exactly coded for that at the moment. All right, now that we have understood the diamond ticket technique, shortly put, the diamond ticket just does a golden ticket on the fly with a valid ticket, replacing the right values at the right time, at the right place. Let's talk a bit about more Kerberos shenanigans. That's where you have the ability to sleep and to rest, because I don't expect to have an understanding of what I'm


chunk_text:
  Packet just gives a new pack. Fully forged. Same thing as the golden ticket. We are working with an OP TGT. We can do anything we want, as long as the domain admin has the rights. Here is the implementation limit, so now there's no excuse for you to do this. Line 323 in Ticketer, you'll find that whether we are working with the request flag or not, the pack is fully forged with the createBasicPack function. This is the issue. We should have something like, if we are not using dash request, we are forging something from the ground up, and if we are working with the dash request, we are just modifying the right values. That's it. However, Ticketer is not exactly coded for that at the moment. All right, now that we have understood the diamond ticket technique, shortly put, the diamond ticket just does a golden ticket on the fly with a valid ticket, replacing the right values at the right time, at the right place. Let's talk a bit about more Kerberos shenanigans. That's where you have the ability to sleep and to rest, because I don't expect to have an understanding of what I'm going to explain. This is very difficult, and I'm not sure I understand it perfectly as of today. So please look elsewhere, go into track two and come back later on. Don't ask questions about it. That's it. First thing, we are talking about service for user extensions. These extensions are the inner mechanisms behind Kerberos delegations, constraint Kerberos delegations. That's it. When we are doing constraint Kerberos delegation, KCD or RBCD, what we are doing is S4U2SELF and or S4U2PROXY. If you want to understand it more, I did a talk last year about exactly that, about Kerberos delegations, so you'll find more information on the replay, and you'll also find some information on Elad Shamir's awesome article called Wagging the Dog, which was published right back in 2019, and he explains it very well. What we have to keep in mind here is that S4U2SELF, S4U2PROXY are extensions allowing to obtain a ticket on behalf of someone else. That's something a bit different. What we saw earlier on the TGT, the service ticket, the golden ticket, whatever, is that we were obtaining something for ourself, or with forged values. With delegation, this is a feature. We have the


chunk_text:
  going to explain. This is very difficult, and I'm not sure I understand it perfectly as of today. So please look elsewhere, go into track two and come back later on. Don't ask questions about it. That's it. First thing, we are talking about service for user extensions. These extensions are the inner mechanisms behind Kerberos delegations, constraint Kerberos delegations. That's it. When we are doing constraint Kerberos delegation, KCD or RBCD, what we are doing is S4U2SELF and or S4U2PROXY. If you want to understand it more, I did a talk last year about exactly that, about Kerberos delegations, so you'll find more information on the replay, and you'll also find some information on Elad Shamir's awesome article called Wagging the Dog, which was published right back in 2019, and he explains it very well. What we have to keep in mind here is that S4U2SELF, S4U2PROXY are extensions allowing to obtain a ticket on behalf of someone else. That's something a bit different. What we saw earlier on the TGT, the service ticket, the golden ticket, whatever, is that we were obtaining something for ourself, or with forged values. With delegation, this is a feature. We have the ability to obtain tickets on behalf of someone else, to act on behalf of someone else. Of course, there are securities in place to make sure that there's not any rando that can generate a ticket for domain admin and whatever, but there's that. There's the feature. Now, for the difference between S4U2SELF and S4U2PROXY, well, S4U2SELF allows to obtain a delegation ticket for oneself, so you have a service ticket impersonating, let's say, domain admin, but this service ticket can be used on yourself. That's it. And S4U2PROXY allows it for another service, so you are requesting a service ticket on behalf of another user targeting another service. And why those two exist? Well, it's usually to allow some security, to split the steps of the constraint delegations, to make sure that you have the right, you are configured for delegation, you obtain a ticket for yourself on behalf of someone else, use it for S4U2PROXY, et cetera, et cetera. But I won't go into much more details about these. What you have to keep in mind here is S4U2SELF. S4U2SELF allows to obtain a service ticket for yourself on behalf of another principal, of another user. One condition


chunk_text:
  ability to obtain tickets on behalf of someone else, to act on behalf of someone else. Of course, there are securities in place to make sure that there's not any rando that can generate a ticket for domain admin and whatever, but there's that. There's the feature. Now, for the difference between S4U2SELF and S4U2PROXY, well, S4U2SELF allows to obtain a delegation ticket for oneself, so you have a service ticket impersonating, let's say, domain admin, but this service ticket can be used on yourself. That's it. And S4U2PROXY allows it for another service, so you are requesting a service ticket on behalf of another user targeting another service. And why those two exist? Well, it's usually to allow some security, to split the steps of the constraint delegations, to make sure that you have the right, you are configured for delegation, you obtain a ticket for yourself on behalf of someone else, use it for S4U2PROXY, et cetera, et cetera. But I won't go into much more details about these. What you have to keep in mind here is S4U2SELF. S4U2SELF allows to obtain a service ticket for yourself on behalf of another principal, of another user. One condition is that if you want to do this, you must have an SPN. You must be configured as a service account. Now let's put this on the side and talk about user-to-user authentication. This has nothing to do with delegation. No Kerberos delegation at all in user-to-user authentication. What U2U does is that it allows to obtain a service ticket for a service that is not a service, that is a user. So instead of, it's like you obtain a user ticket. You obtain a service ticket for a user. And this allows usually for smaller infrastructures that don't want to boot up a service account for a service. They just want to rely on user accounts. Well, it allows user one to access user two's services. And in order to do that, U2U. How it works, Bob wants to access Alice. In order to do that, Bob asks Alice for her TGT. Alice gives the TGT to Bob. Bob cannot act as Alice because he needs the session key to use the TGT and Alice doesn't give the session key along the TGT. And once Bob has the TGT, Bob can do a U2U request, request a service ticket


chunk_text:
  is that if you want to do this, you must have an SPN. You must be configured as a service account. Now let's put this on the side and talk about user-to-user authentication. This has nothing to do with delegation. No Kerberos delegation at all in user-to-user authentication. What U2U does is that it allows to obtain a service ticket for a service that is not a service, that is a user. So instead of, it's like you obtain a user ticket. You obtain a service ticket for a user. And this allows usually for smaller infrastructures that don't want to boot up a service account for a service. They just want to rely on user accounts. Well, it allows user one to access user two's services. And in order to do that, U2U. How it works, Bob wants to access Alice. In order to do that, Bob asks Alice for her TGT. Alice gives the TGT to Bob. Bob cannot act as Alice because he needs the session key to use the TGT and Alice doesn't give the session key along the TGT. And once Bob has the TGT, Bob can do a U2U request, request a service ticket for Alice by supplying Alice's TGT in the request, proving that he has indeed the right to act on Alice. And that's it. Now Bob has a service ticket to Alice and Bob and Alice are two users. So now let's see the combination of S4U2SELF and U2U. S4U2SELF plus U2U allows a user, let's say Bob, to obtain a service ticket on another user for another user, let's say Alice, on behalf of a third user, let's say the domain admin. And there's no SPN needed in this technique. This allows for a few things. And on the offensive perspective, this allows for three attacks known as SPN-less RBCD, which was published by James Foreshaw a few months ago, last year. It allows also for unpack-the-hash, which is related to PK init attacks, to certificate attacks. And also allows for the Sapphire Ticket technique, which is the latest variation improvement of the Golden Ticket technique. The diagram here, what we do as the attacker is one, TGT request, we obtain a TGT for ourself. Once we have this TGT, we include it in the request later on, and we build the service ticket request. Error term, what I said


chunk_text:
  for Alice by supplying Alice's TGT in the request, proving that he has indeed the right to act on Alice. And that's it. Now Bob has a service ticket to Alice and Bob and Alice are two users. So now let's see the combination of S4U2SELF and U2U. S4U2SELF plus U2U allows a user, let's say Bob, to obtain a service ticket on another user for another user, let's say Alice, on behalf of a third user, let's say the domain admin. And there's no SPN needed in this technique. This allows for a few things. And on the offensive perspective, this allows for three attacks known as SPN-less RBCD, which was published by James Foreshaw a few months ago, last year. It allows also for unpack-the-hash, which is related to PK init attacks, to certificate attacks. And also allows for the Sapphire Ticket technique, which is the latest variation improvement of the Golden Ticket technique. The diagram here, what we do as the attacker is one, TGT request, we obtain a TGT for ourself. Once we have this TGT, we include it in the request later on, and we build the service ticket request. Error term, what I said before was a bit wrong. We are not, when we are combining S4U2SELF plus U2U, we are not obtaining a service ticket for another user. We are obtaining a service ticket for ourself on behalf of another user. So in the request here, in the service ticket request combining S4U2SELF and U2U, the client's name, the name of the user that wants access is attacker. The name of the user we want to have access to is attacker, since we are doing S4U2SELF. PA for user, it refers to the user we want to impersonate, act on behalf of, which is here the domain admin. And additional tickets here for the U2U, we need to include the attacker TGT, since the attacker is the target of our service request. This is done, S4U2SELF plus U2U, we have to combine multiple flags and so on. Once we have this, well, you can see here in the S4U2SELF plus U2U service ticket answer, we have something very special. It's the domain admins pack with all the right values in it. And this is what we'll use for the Sapphire ticket. Sapphire ticket coming right here. We are doing the same thing as


chunk_text:
  before was a bit wrong. We are not, when we are combining S4U2SELF plus U2U, we are not obtaining a service ticket for another user. We are obtaining a service ticket for ourself on behalf of another user. So in the request here, in the service ticket request combining S4U2SELF and U2U, the client's name, the name of the user that wants access is attacker. The name of the user we want to have access to is attacker, since we are doing S4U2SELF. PA for user, it refers to the user we want to impersonate, act on behalf of, which is here the domain admin. And additional tickets here for the U2U, we need to include the attacker TGT, since the attacker is the target of our service request. This is done, S4U2SELF plus U2U, we have to combine multiple flags and so on. Once we have this, well, you can see here in the S4U2SELF plus U2U service ticket answer, we have something very special. It's the domain admins pack with all the right values in it. And this is what we'll use for the Sapphire ticket. Sapphire ticket coming right here. We are doing the same thing as the diamond ticket. We are modifying things on the fly with a valid TGT, with a valid ticket. But instead of forging values and creating a mismatch, we are replacing the valid pack with another valid pack, but of a powered user, of a powerful user. So what this does is like, instead of having a pack indicating that Bob is a member of the domain admins group, which is false, we have a pack indicating that domain admin is a member of the domain admins group, which is right. It's legit. And what we have there is a valid, a legit TGT, and a legit pack, legit everything. So ticket mucho bueno, pack mucho bueno, perfect. Unlike the golden ticket, the ticket is perfect. And unlike the diamond ticket, the pack is perfect, and we have no mismatch whatsoever between the UAC, the flags, the groups, the RIDs, the username, and whatever. So the Sapphire ticket allows to produce something that's very similar to the legitimate domain admins TGT. But in order to do that, we have the same requirements as the diamond ticket technique. We need golden tickets requirement, which is the KRB TGT, if we want to


chunk_text:
  the diamond ticket. We are modifying things on the fly with a valid TGT, with a valid ticket. But instead of forging values and creating a mismatch, we are replacing the valid pack with another valid pack, but of a powered user, of a powerful user. So what this does is like, instead of having a pack indicating that Bob is a member of the domain admins group, which is false, we have a pack indicating that domain admin is a member of the domain admins group, which is right. It's legit. And what we have there is a valid, a legit TGT, and a legit pack, legit everything. So ticket mucho bueno, pack mucho bueno, perfect. Unlike the golden ticket, the ticket is perfect. And unlike the diamond ticket, the pack is perfect, and we have no mismatch whatsoever between the UAC, the flags, the groups, the RIDs, the username, and whatever. So the Sapphire ticket allows to produce something that's very similar to the legitimate domain admins TGT. But in order to do that, we have the same requirements as the diamond ticket technique. We need golden tickets requirement, which is the KRB TGT, if we want to forge a TGT, and active credentials, since we are doing things on the fly. And detection will be like, eh. Let's do this in practice. First step, we have to use Ticketer. Same thing. We fire up, look up SID to obtain the right SIDs, et cetera. And then we just include valid credentials here. And we just add the only difference here between diamond and Sapphire tickets is the flag impersonate. And here, I'm indicating to Ticketer that I want to impersonate domain admin. What this does is, first step, request s4yourself plus v2u, as I explained before, to obtain domain admin spec. The combination of those two shenanigans just allow for one simple thing, obtain domain admin spec. And once we have this spec, we just push it in the valid ticket of user 2. So here, in the second step, decrypting ticket, extracting pack, clearing signatures, whatever. We are putting the new pack in the legit ticket. And we have legit ticket, legit pack, legit all. We are all happy. If we describe it, we can see that the KRB TGT here is the target service, indicating that we are working with a TGT. The target domain


chunk_text:
  forge a TGT, and active credentials, since we are doing things on the fly. And detection will be like, eh. Let's do this in practice. First step, we have to use Ticketer. Same thing. We fire up, look up SID to obtain the right SIDs, et cetera. And then we just include valid credentials here. And we just add the only difference here between diamond and Sapphire tickets is the flag impersonate. And here, I'm indicating to Ticketer that I want to impersonate domain admin. What this does is, first step, request s4yourself plus v2u, as I explained before, to obtain domain admin spec. The combination of those two shenanigans just allow for one simple thing, obtain domain admin spec. And once we have this spec, we just push it in the valid ticket of user 2. So here, in the second step, decrypting ticket, extracting pack, clearing signatures, whatever. We are putting the new pack in the legit ticket. And we have legit ticket, legit pack, legit all. We are all happy. If we describe it, we can see that the KRB TGT here is the target service, indicating that we are working with a TGT. The target domain is domain.local. So we are working with a TGT on domain.local's domain as domain admin. So everything is nice. And here, we have everything is legit. We have the user flags here. We have the right groups. We have the right RID. We have the right user account control, UAC. We have the right extra SID, resource group domain SID, blah, blah, blah. Everything is perfect. We have the perfect ticket, perfect pack. And detection is like, blah. And this is how it's used. Same thing as the golden ticket. It can be used to dump whatever, as long as the rights, the domain user you're impersonating has rights. Well, you'll have those. Here is a small limitation of the implementation. First thing first, I implemented this in Ticketer. And well, I'm not a developer. I write shit. This is the proof. There's one limitation with Ticketer today, which is that Ticketer extracts all the pack structures and rebuilds it from scratch. What this means is that if there are some structures in the pack that impact doesn't support, the ticket will be not full. Some structures will be skipped. So same thing here. I don't have nor the time


chunk_text:
  is domain.local. So we are working with a TGT on domain.local's domain as domain admin. So everything is nice. And here, we have everything is legit. We have the user flags here. We have the right groups. We have the right RID. We have the right user account control, UAC. We have the right extra SID, resource group domain SID, blah, blah, blah. Everything is perfect. We have the perfect ticket, perfect pack. And detection is like, blah. And this is how it's used. Same thing as the golden ticket. It can be used to dump whatever, as long as the rights, the domain user you're impersonating has rights. Well, you'll have those. Here is a small limitation of the implementation. First thing first, I implemented this in Ticketer. And well, I'm not a developer. I write shit. This is the proof. There's one limitation with Ticketer today, which is that Ticketer extracts all the pack structures and rebuilds it from scratch. What this means is that if there are some structures in the pack that impact doesn't support, the ticket will be not full. Some structures will be skipped. So same thing here. I don't have nor the time nor the courage to tackle this. If you want to implement something perfect, well, you have my blessing. So now let's wrap things up. 43 minutes, perfect. If you want to go further for Sapphire ticket limitations, well, there's the first thing. It requires active credentials. So it's not the perfect persistence technique, because you cannot extract things and get back to the domain one year later. And if everything has changed, well, you will not be able to do the Sapphire ticket technique because you need active credentials. We know Active Directory to be a bit vulnerable to many things if it's not configured properly. So obtaining valid username and password on the domain is not the hardest thing, but you still need it. Also it produces a bit more network traffic. If you have some S4Yourself, U2U, Service Ticket Request, TTT Request, blah, blah, blah, there's a lot of traffic. So for detection software around here, here's a possibility. You can look at the various network traffic. Some solutions to the problems I raised is, first, Rubius has something, I saw it while preparing this talk tonight, which was the slash LDAP and slash printCMD flags, which allow


chunk_text:
  nor the courage to tackle this. If you want to implement something perfect, well, you have my blessing. So now let's wrap things up. 43 minutes, perfect. If you want to go further for Sapphire ticket limitations, well, there's the first thing. It requires active credentials. So it's not the perfect persistence technique, because you cannot extract things and get back to the domain one year later. And if everything has changed, well, you will not be able to do the Sapphire ticket technique because you need active credentials. We know Active Directory to be a bit vulnerable to many things if it's not configured properly. So obtaining valid username and password on the domain is not the hardest thing, but you still need it. Also it produces a bit more network traffic. If you have some S4Yourself, U2U, Service Ticket Request, TTT Request, blah, blah, blah, there's a lot of traffic. So for detection software around here, here's a possibility. You can look at the various network traffic. Some solutions to the problems I raised is, first, Rubius has something, I saw it while preparing this talk tonight, which was the slash LDAP and slash printCMD flags, which allow to obtain the right values without S4Yourself and U2U, but instead relying on LDAP queries. This is a bit similar to the golden copy alternative I showed you earlier, which then doesn't rely on Neo4j databases, but then does dynamically queries LDAP to find the right information, the groups the target user is a member of, et cetera, et cetera, to build a nearly perfect ticket. So there's that. Second thing, I don't like surprise questions, so this is probably the only technical thing I'll be able to answer. Why call it Sapphire? Why is the title to this con, wait 65 years, blah, blah, blah? Well, it's a gemstone, sorry, for those of you who don't know Jubilees, well, there's a list, Wikipedia. We already have the silver, golden, diamond ticket, I found it logic to call the next variation Sapphire. If someone here finds the idea, the perfect idea for the platinum ticket, again, you have my blessing. Please don't implement things like I do with many holes in it. Forcing questions number two, again, mitigation, detection, I'm not an expert. So, I don't do that personally, but here are some paths you can explore. The first thing


chunk_text:
  to obtain the right values without S4Yourself and U2U, but instead relying on LDAP queries. This is a bit similar to the golden copy alternative I showed you earlier, which then doesn't rely on Neo4j databases, but then does dynamically queries LDAP to find the right information, the groups the target user is a member of, et cetera, et cetera, to build a nearly perfect ticket. So there's that. Second thing, I don't like surprise questions, so this is probably the only technical thing I'll be able to answer. Why call it Sapphire? Why is the title to this con, wait 65 years, blah, blah, blah? Well, it's a gemstone, sorry, for those of you who don't know Jubilees, well, there's a list, Wikipedia. We already have the silver, golden, diamond ticket, I found it logic to call the next variation Sapphire. If someone here finds the idea, the perfect idea for the platinum ticket, again, you have my blessing. Please don't implement things like I do with many holes in it. Forcing questions number two, again, mitigation, detection, I'm not an expert. So, I don't do that personally, but here are some paths you can explore. The first thing is, there's two categories if you want to detect or mitigate. The first thing is analyze the forged ticket itself. If it has the wrong username, as I said earlier for patched domain controllers as of November 2021 updates, a username in the ticket that doesn't exist in Active Directory domain, well, it will be rejected. If the pack fields are malformed, blank, missing, whatever, well, you can detect it. So, this concerns silver and golden, however, for diamond and Sapphire tickets, using these techniques, you are safe, because the values in the pack are usually good values, they're not malformed. And if you have a pack mismatch, there's another detection here. So, for example, let's say that the pack says that we are working with Bob, but on the other hand, it says that Bob is a member of the domain admin's group, well, there's that. Bob is not a domain admin, but he's a member of the domain admin's group, there's an issue. Well, Sapphire technique goes through that, there's no problem. Another way of detecting those is detection around the ticket, not the ticket itself. So, look for KRBTT theft, suspicious tools and techniques, suspicious behavior, the


chunk_text:
  is, there's two categories if you want to detect or mitigate. The first thing is analyze the forged ticket itself. If it has the wrong username, as I said earlier for patched domain controllers as of November 2021 updates, a username in the ticket that doesn't exist in Active Directory domain, well, it will be rejected. If the pack fields are malformed, blank, missing, whatever, well, you can detect it. So, this concerns silver and golden, however, for diamond and Sapphire tickets, using these techniques, you are safe, because the values in the pack are usually good values, they're not malformed. And if you have a pack mismatch, there's another detection here. So, for example, let's say that the pack says that we are working with Bob, but on the other hand, it says that Bob is a member of the domain admin's group, well, there's that. Bob is not a domain admin, but he's a member of the domain admin's group, there's an issue. Well, Sapphire technique goes through that, there's no problem. Another way of detecting those is detection around the ticket, not the ticket itself. So, look for KRBTT theft, suspicious tools and techniques, suspicious behavior, the usual stuff. But you can also look at log-on hours, so if there's SRSF plus U2U plus TGT plus service ticket request at 2 a.m. in the morning, there's probably something wrong. Some acknowledgements, I really want to thank many people for issuing their research behind this technique, which is not very difficult, in fact, I just assembled some pieces I found somewhere else. So, first thing first, I want to thank Charlie Clark and Andrew Schwartz for writing a diamond ticket in the rough, which explains in details the diamond ticket technique. I also want to notify that Alberto Solino found the Sapphire ticket technique back in 2016. I didn't know of it, but while preparing the slides, I noticed in the ticketer.py script, there was a comment in the to-do list saying, when a request is specified, we could ask for a user-to-user ticket and also populate the received pack. He had the idea for the Sapphire ticket back in 2016, it was never implemented. That's it. So I found something that someone found before, and that's okay, it just hurts, but that's okay. I also want to thank Elad Shamir's awesome article for wagging the dog, there's


chunk_text:
  usual stuff. But you can also look at log-on hours, so if there's SRSF plus U2U plus TGT plus service ticket request at 2 a.m. in the morning, there's probably something wrong. Some acknowledgements, I really want to thank many people for issuing their research behind this technique, which is not very difficult, in fact, I just assembled some pieces I found somewhere else. So, first thing first, I want to thank Charlie Clark and Andrew Schwartz for writing a diamond ticket in the rough, which explains in details the diamond ticket technique. I also want to notify that Alberto Solino found the Sapphire ticket technique back in 2016. I didn't know of it, but while preparing the slides, I noticed in the ticketer.py script, there was a comment in the to-do list saying, when a request is specified, we could ask for a user-to-user ticket and also populate the received pack. He had the idea for the Sapphire ticket back in 2016, it was never implemented. That's it. So I found something that someone found before, and that's okay, it just hurts, but that's okay. I also want to thank Elad Shamir's awesome article for wagging the dog, there's that, used it for preparing Kerberos delegation talk. I also want to thank James Forshaw for writing an excellent article about how to do RBCD with a normal user account. It explains some things about SRE to self and you to you. I also want to thank a good friend of mine, which was and still is an inspiration, both on the technical side and human side of things, which is Romain Pixis. But you'll also find some technical information that he wrote, very relevant stuff, on his blog post, on his blog hackanddo.com. That's it. You have some sources and links in the slides, some glossary, some tooling. On a side note, again, Exegol, HackerSCPs, yep. And that's it. Q&A time. Anyone has questions? You can wake up now. All right. So if you have any questions, please raise your hand so either me or my colleague can bring you the microphone. You can still try to ask questions about mitigation and detection, I'm just not giving any guarantees. That's it. No questions? Wow, that was very clear. You understood everything perfectly. Hello. For you, what is better when we attack cross-domain, parent and shield domain, trust bidirectional? What


chunk_text:
  that, used it for preparing Kerberos delegation talk. I also want to thank James Forshaw for writing an excellent article about how to do RBCD with a normal user account. It explains some things about SRE to self and you to you. I also want to thank a good friend of mine, which was and still is an inspiration, both on the technical side and human side of things, which is Romain Pixis. But you'll also find some technical information that he wrote, very relevant stuff, on his blog post, on his blog hackanddo.com. That's it. You have some sources and links in the slides, some glossary, some tooling. On a side note, again, Exegol, HackerSCPs, yep. And that's it. Q&A time. Anyone has questions? You can wake up now. All right. So if you have any questions, please raise your hand so either me or my colleague can bring you the microphone. You can still try to ask questions about mitigation and detection, I'm just not giving any guarantees. That's it. No questions? Wow, that was very clear. You understood everything perfectly. Hello. For you, what is better when we attack cross-domain, parent and shield domain, trust bidirectional? What is the better golden ticket or surfer ticket? Well, it depends. Those four tickets, silver, golden, blah, blah, blah. Let's just put silver aside. As you said, parent, child, domain, trust, so you're in the same forest. Just a reminder, Microsoft states that the security boundary is the forest, so everything inside the forest, you could usually escalate and stuff. But then it depends. Because surfer ticket, you need active credentials, you need to have the right tooling, you need to understand the technique, the S for yourself, U2U, blah, blah, blah. And if things go south, usually does, and you have to debug things live. And if you don't understand the technique behind it, you'll not be able to make it work. So my advice is, it depends. If you find the KRBGT and you're doing a penetration test without stealth at mind, you're not doing a red team or whatever, doesn't matter. Don't do a golden ticket. That's it. It's easier. It's very well implemented. That's it. If you want to be stealthy, safari ticket, all the way, that's it. The thing is, for safari ticket, you'll probably need to have active credentials. Well, it depends. It depends


chunk_text:
  is the better golden ticket or surfer ticket? Well, it depends. Those four tickets, silver, golden, blah, blah, blah. Let's just put silver aside. As you said, parent, child, domain, trust, so you're in the same forest. Just a reminder, Microsoft states that the security boundary is the forest, so everything inside the forest, you could usually escalate and stuff. But then it depends. Because surfer ticket, you need active credentials, you need to have the right tooling, you need to understand the technique, the S for yourself, U2U, blah, blah, blah. And if things go south, usually does, and you have to debug things live. And if you don't understand the technique behind it, you'll not be able to make it work. So my advice is, it depends. If you find the KRBGT and you're doing a penetration test without stealth at mind, you're not doing a red team or whatever, doesn't matter. Don't do a golden ticket. That's it. It's easier. It's very well implemented. That's it. If you want to be stealthy, safari ticket, all the way, that's it. The thing is, for safari ticket, you'll probably need to have active credentials. Well, it depends. It depends on the implementation of the two domains you're working with. So the answer, I'm sorry, is it depends. Okay, thanks. For stealth purposes, no golden ticket, no golden ticket. That's it. All right. Any other question? Okay, so I think we can call it a wrap. So we have lunch downstairs if you want, and you can go right away because it's already opened. Thank you everyone. Thank you very much. Thank you, Charlie.


chunk_text:
  on the implementation of the two domains you're working with. So the answer, I'm sorry, is it depends. Okay, thanks. For stealth purposes, no golden ticket, no golden ticket. That's it. All right. Any other question? Okay, so I think we can call it a wrap. So we have lunch downstairs if you want, and you can go right away because it's already opened. Thank you everyone. Thank you very much. Thank you, Charlie.


chunk_text:
  { "webpage_url": "https://www.youtube.com/watch?v=x-FD8YbygYU", "title": "Hacking Harms! Measuring The Impact And Harm From Cyberattacks by Emma Raffray", "description": "", "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA", "duration": 2482, "channel": "scrt.insomnihack", "uploader": "scrt.insomnihack", "upload_date": "20230411" } This text was transcribed using whisper model: large-v2 Good morning. It's a real pleasure to be amongst you today. So my name is Charlotte Lindsay and I'm the Chief Public Policy Officer at the Cyber Peace Institute. And hi everyone. My name's Emma Raffray. I'm the Chief Research and Analysis Officer also at the Institute. It's my first time at Insomniac, so be kind to us today. So the aim of today, we're really going to talk about the harms and impact methodology that the Institute has been developing. To do that, we'll take you briefly through who the Institute is, just as an indicator. How many people in the room have heard of or know of the work of the Cyber Peace Institute? Okay. And so I will give a very brief introduction for those who have not heard of the Institute before. And then we will walk you through some of the approaches that are used to, currently used to measure harms and impacts and why that's important. And we will take some examples from the health attacks on healthcare sector, attacks currently in Ukraine, and then where we're taking this methodology and its importance going forward. So with that, I will just kick off on the Cyber Peace Institute. So the Cyber Peace Institute is a non-governmental organization based in Geneva, which is independent and neutral. And its work is very much to try to build stability in cyberspace and greater accountability towards, against threat actors and to support really vulnerable communities who are affected by cyber incidences. It's only three years old, the Institute, and we have a real multidisciplinary expertise. And that really looks at an evidence and data-driven approach to try to understand how we can assist particularly vulnerable communities. And in that, we have a Cyber Peace Builders Program, which is supporting humanitarian and non-governmental organizations to build up their cyber security resilience. We also assisted healthcare, and also we look at particularly vulnerable communities linked to, for example, critical infrastructure. So that also helps us to gain primary evidence about how cyber incidences, cyber threats are affecting particularly vulnerable communities. And then we analyze that as, also along with open source intelligence that


chunk_text:
  we will take some examples from the health attacks on healthcare sector, attacks currently in Ukraine, and then where we're taking this methodology and its importance going forward. So with that, I will just kick off on the Cyber Peace Institute. So the Cyber Peace Institute is a non-governmental organization based in Geneva, which is independent and neutral. And its work is very much to try to build stability in cyberspace and greater accountability towards, against threat actors and to support really vulnerable communities who are affected by cyber incidences. It's only three years old, the Institute, and we have a real multidisciplinary expertise. And that really looks at an evidence and data-driven approach to try to understand how we can assist particularly vulnerable communities. And in that, we have a Cyber Peace Builders Program, which is supporting humanitarian and non-governmental organizations to build up their cyber security resilience. We also assisted healthcare, and also we look at particularly vulnerable communities linked to, for example, critical infrastructure. So that also helps us to gain primary evidence about how cyber incidences, cyber threats are affecting particularly vulnerable communities. And then we analyze that as, also along with open source intelligence that we can, we gather and aggregate from a broad variety of actors and means of collecting data that we can really then look at analyzing, along with that primary evidence, how cyber threat landscape is affecting particularly vulnerable communities. And then we use those insights to inform policy and legal discussions that are happening, for example, at the United Nations to build a more stronger normative framework for the use of ICTs or against cyber criminality. So there are several ongoing processes at the UN and in other forums, like the OSCE and others that are developing norms to strengthen the protections of, against the cyber criminality or the protections of the use of ICTs. So we work in this holistic way to really try to use this evidence to have an advocacy and policy-based approach to try to effect change. Why are we interested in harm? I think the critical aspect around that is that the current focus around harm primarily is linked to the operational or financial downtime and impact of a cyber attack and all the public reporting obligations that are required in certain sectors or in certain countries and that differs across sector and differs across


chunk_text:
  we can, we gather and aggregate from a broad variety of actors and means of collecting data that we can really then look at analyzing, along with that primary evidence, how cyber threat landscape is affecting particularly vulnerable communities. And then we use those insights to inform policy and legal discussions that are happening, for example, at the United Nations to build a more stronger normative framework for the use of ICTs or against cyber criminality. So there are several ongoing processes at the UN and in other forums, like the OSCE and others that are developing norms to strengthen the protections of, against the cyber criminality or the protections of the use of ICTs. So we work in this holistic way to really try to use this evidence to have an advocacy and policy-based approach to try to effect change. Why are we interested in harm? I think the critical aspect around that is that the current focus around harm primarily is linked to the operational or financial downtime and impact of a cyber attack and all the public reporting obligations that are required in certain sectors or in certain countries and that differs across sector and differs across country. And so it really is focused on what's the time to restore, what are the financial costs or penalties, what's the number of records that are breached, what is the personal identifiable information which has been accessed. What is not really the focus currently is what's the harm that is actually caused to people. And because there's really no standard methodology in place, that makes it very hard to understand those harms. And without a lack of real metrics, tools and frameworks to understand and track that harm over time, it's very difficult to then work at how we can build stronger normative and policy-making processes reflecting that harm, how we can better support the victims of cyber incidences and how we can learn for that in terms of building greater resilience. So that's what drove us to look at why measuring harm is important so that we can then use that in that cycle that I mentioned in the slide previously around assisting those communities, mechanising the attack through a more methodological process and then using that to inform diplomatic processes at state level. Thanks Charlotte. So trying to put a bit of an analogy into place and


chunk_text:
  country. And so it really is focused on what's the time to restore, what are the financial costs or penalties, what's the number of records that are breached, what is the personal identifiable information which has been accessed. What is not really the focus currently is what's the harm that is actually caused to people. And because there's really no standard methodology in place, that makes it very hard to understand those harms. And without a lack of real metrics, tools and frameworks to understand and track that harm over time, it's very difficult to then work at how we can build stronger normative and policy-making processes reflecting that harm, how we can better support the victims of cyber incidences and how we can learn for that in terms of building greater resilience. So that's what drove us to look at why measuring harm is important so that we can then use that in that cycle that I mentioned in the slide previously around assisting those communities, mechanising the attack through a more methodological process and then using that to inform diplomatic processes at state level. Thanks Charlotte. So trying to put a bit of an analogy into place and how to actually differentiate a little bit what we mean by the terms impact and the terms harm. And I want here to use the notion of a car accident. We all know what a car accident is. It's an impact between two vehicles. A car accident can have different impacts. It can have an operational disruption. It can increase traffic at a particular time of day. It can lead to delays in you getting to work. It can lead to disruptions to services that have to intervene to be able to resolve the accident. So it's got financial costs and costs that really are impacting potentially both persons, both drivers of the car in terms of the insurance that they have to pay and things of this nature. Then we look at the physical damage to the vehicles. What has actually happened in terms of actual damage to the windscreen or to the wheels? And then we have such things as geotemporal factors. How long did the accident cause a disruption? How big of an area did that accident actually lead to further disruptions? If we then look at the harm components of that car accident, we come at


chunk_text:
  how to actually differentiate a little bit what we mean by the terms impact and the terms harm. And I want here to use the notion of a car accident. We all know what a car accident is. It's an impact between two vehicles. A car accident can have different impacts. It can have an operational disruption. It can increase traffic at a particular time of day. It can lead to delays in you getting to work. It can lead to disruptions to services that have to intervene to be able to resolve the accident. So it's got financial costs and costs that really are impacting potentially both persons, both drivers of the car in terms of the insurance that they have to pay and things of this nature. Then we look at the physical damage to the vehicles. What has actually happened in terms of actual damage to the windscreen or to the wheels? And then we have such things as geotemporal factors. How long did the accident cause a disruption? How big of an area did that accident actually lead to further disruptions? If we then look at the harm components of that car accident, we come at it from a human-centric approach and we're looking at what was the physical harm that was caused to either the drivers or the passengers in the car or the bystanders who might have actually witnessed that accident. What does that mean in terms of potential psychological impact to the driver who might not be able to drive that car then for a subsequent lengthy period of time? We look at the community and societal impact. How an entire family has passed away as a result of an accident and how that impacts the community. We look at the reputational damage that could come from that. If the vehicle was a company truck, for example, an Amazon vehicle that is then involved in an accident, what might be the result from that? And then we look at the environmental impact. Was there an oil spill on the road? How did that impact the environment around it? If we take that example and we sort of pivot that onto a cyber attack, we can see similar divisions. So if we take an example of an attack on a hospital, what is the operational disruption to that hospital's ability to deliver services? Have


chunk_text:
  it from a human-centric approach and we're looking at what was the physical harm that was caused to either the drivers or the passengers in the car or the bystanders who might have actually witnessed that accident. What does that mean in terms of potential psychological impact to the driver who might not be able to drive that car then for a subsequent lengthy period of time? We look at the community and societal impact. How an entire family has passed away as a result of an accident and how that impacts the community. We look at the reputational damage that could come from that. If the vehicle was a company truck, for example, an Amazon vehicle that is then involved in an accident, what might be the result from that? And then we look at the environmental impact. Was there an oil spill on the road? How did that impact the environment around it? If we take that example and we sort of pivot that onto a cyber attack, we can see similar divisions. So if we take an example of an attack on a hospital, what is the operational disruption to that hospital's ability to deliver services? Have the computer systems gone offline? Has the website gone offline? Is it impeding the automatic opening of doors, for example? What is the financial cost to that hospital to actually recover from the cyber attack or to actually respond to the cyber attack in the first place? What is the physical damage that has occurred in terms of physical damage to the actual infrastructure, the technical infrastructure that was in place? And then how long did that attack go on for? How long were operations disrupted? Did it affect one hospital? Did it affect 50 different hospitals against 50 different states, for example, in the US because they're part of a wider network? And then we look at the harm and we look again from a human angle, from the people's angle. And here it's not just the patients who are affected. It is the healthcare professionals who are operating within that hospital who are having to react in circumstances where they don't have access to patient data, where they don't have access to computers, where they don't have access to imagery, for example. And what are the physical or psychological effects of that particular cyber attack and the delays


chunk_text:
  the computer systems gone offline? Has the website gone offline? Is it impeding the automatic opening of doors, for example? What is the financial cost to that hospital to actually recover from the cyber attack or to actually respond to the cyber attack in the first place? What is the physical damage that has occurred in terms of physical damage to the actual infrastructure, the technical infrastructure that was in place? And then how long did that attack go on for? How long were operations disrupted? Did it affect one hospital? Did it affect 50 different hospitals against 50 different states, for example, in the US because they're part of a wider network? And then we look at the harm and we look again from a human angle, from the people's angle. And here it's not just the patients who are affected. It is the healthcare professionals who are operating within that hospital who are having to react in circumstances where they don't have access to patient data, where they don't have access to computers, where they don't have access to imagery, for example. And what are the physical or psychological effects of that particular cyber attack and the delays that it's caused in terms of access to patient care? And then there's the community and societal implications surrounding that. Has the hospital had to divert patients to another hospital? So it's causing a knock-on effect within a geographical perimeter of a city, for example. What is the reputational impact when critical data is leaked from a hospital and patient records are made available online? And what is the environmental impact? If we take something perhaps a bit easier to imagine here, is a cyber attack on a water facility and contamination resulting from that? What broader implications does that have? So taking in mind this kind of notion of impact and harm, we then started to look at what actually exists today. What is some of the literature, some of the studies and some of the work that is being done by different actors, multi-stakeholder actors, looking at impact and harm? So we've got a report that was published by the ICRC, for example, that really looked at the effects of cyber operations in times of armed conflict. So it's a very specific use case relating to cyber operations. And they're really looking at an assessment of how traditional


chunk_text:
  that it's caused in terms of access to patient care? And then there's the community and societal implications surrounding that. Has the hospital had to divert patients to another hospital? So it's causing a knock-on effect within a geographical perimeter of a city, for example. What is the reputational impact when critical data is leaked from a hospital and patient records are made available online? And what is the environmental impact? If we take something perhaps a bit easier to imagine here, is a cyber attack on a water facility and contamination resulting from that? What broader implications does that have? So taking in mind this kind of notion of impact and harm, we then started to look at what actually exists today. What is some of the literature, some of the studies and some of the work that is being done by different actors, multi-stakeholder actors, looking at impact and harm? So we've got a report that was published by the ICRC, for example, that really looked at the effects of cyber operations in times of armed conflict. So it's a very specific use case relating to cyber operations. And they're really looking at an assessment of how traditional notions of impact actually rely on a risk assessment. And they look at a comparison of the likelihood of an attack taking place and the severity of those events. So in terms of severity, they're looking at the type of effects of an attack. They're looking at the scale in terms of the people that are affected or the number of computers that might have been affected, as well as the duration. But then they actually look at the likelihood and what is the probability that a certain cyber operation actually causes the effects that they're assessing in the severity component. And not just looking at the likelihood of that happening to an intended target, but it could also be an impact that is happening incidentally or accidentally in the context of a cyber incident. What else exists today? There's a number of different companies, notably in the private sector, that are looking really at the business impact. And these are coming from the likes of Deloitte, but there's also insurance companies that have been doing a lot of work on this, that are actually looking at the business impact. So what is the impact, for example, of a technical


chunk_text:
  notions of impact actually rely on a risk assessment. And they look at a comparison of the likelihood of an attack taking place and the severity of those events. So in terms of severity, they're looking at the type of effects of an attack. They're looking at the scale in terms of the people that are affected or the number of computers that might have been affected, as well as the duration. But then they actually look at the likelihood and what is the probability that a certain cyber operation actually causes the effects that they're assessing in the severity component. And not just looking at the likelihood of that happening to an intended target, but it could also be an impact that is happening incidentally or accidentally in the context of a cyber incident. What else exists today? There's a number of different companies, notably in the private sector, that are looking really at the business impact. And these are coming from the likes of Deloitte, but there's also insurance companies that have been doing a lot of work on this, that are actually looking at the business impact. So what is the impact, for example, of a technical investigation that results following a cyber attack? How does it affect public relations for the company? How are my insurance premiums going to change next year as a result of the fact that I've been a victim of a cyber attack and I've had to claim on that insurance? Have I lost any intellectual property when the cyber attack has taken place? But what we see in these kinds of report is a significant lack of acknowledgement that actually the cyber attack, beyond the organisational impact, is actually the impact that that has had on people, be it, for example, their own employees or be it their customers who might have suffered as a result. Then we looked at a report published by Unidea, which is actually a bit broader than looking at the impact and harm of cyber attacks, but it actually looks at a taxonomy of malicious cyber incidents. But there's a couple of components of that taxonomy that are actually really interesting. When you look at the victim profile, where they talk about whether a victim is intended, whether it's instrumental or collateral, they also break down the victim into different components. The victim can be an


chunk_text:
  investigation that results following a cyber attack? How does it affect public relations for the company? How are my insurance premiums going to change next year as a result of the fact that I've been a victim of a cyber attack and I've had to claim on that insurance? Have I lost any intellectual property when the cyber attack has taken place? But what we see in these kinds of report is a significant lack of acknowledgement that actually the cyber attack, beyond the organisational impact, is actually the impact that that has had on people, be it, for example, their own employees or be it their customers who might have suffered as a result. Then we looked at a report published by Unidea, which is actually a bit broader than looking at the impact and harm of cyber attacks, but it actually looks at a taxonomy of malicious cyber incidents. But there's a couple of components of that taxonomy that are actually really interesting. When you look at the victim profile, where they talk about whether a victim is intended, whether it's instrumental or collateral, they also break down the victim into different components. The victim can be an organisation, but it can also be an individual within that organisation or in and of its own right. If we think about, for example, an individual whose phone has been targeted by spyware, that individual themselves is actually a victim of a cyber attack. They also break it down into what is critical infrastructure as a victim, what is a country as a victim, and we'll address this where we go on to the topic of Ukraine later on in the presentation. And then it looks also at international systems in place. But it also breaks down things such as targeted assets. And on the other spectrum, in terms of the output, what happens post-cyber attack? And they break it down into the effects, which is what we're calling impact on our side, but it also looks at the harm, where it's broken it down into physical, psychological, economic harms. But it also looks at gains, which is a really interesting aspect of it, which is looking what has the threat actor actually gained from committing that cyber attack? And for us, it's asking questions of can that actually be transformed into some kind of measures of impact as well?


chunk_text:
  organisation, but it can also be an individual within that organisation or in and of its own right. If we think about, for example, an individual whose phone has been targeted by spyware, that individual themselves is actually a victim of a cyber attack. They also break it down into what is critical infrastructure as a victim, what is a country as a victim, and we'll address this where we go on to the topic of Ukraine later on in the presentation. And then it looks also at international systems in place. But it also breaks down things such as targeted assets. And on the other spectrum, in terms of the output, what happens post-cyber attack? And they break it down into the effects, which is what we're calling impact on our side, but it also looks at the harm, where it's broken it down into physical, psychological, economic harms. But it also looks at gains, which is a really interesting aspect of it, which is looking what has the threat actor actually gained from committing that cyber attack? And for us, it's asking questions of can that actually be transformed into some kind of measures of impact as well? If the objective of the threat actor is of a particular nature, and he manages to gain something from the cyber attack, what does that mean in terms of assessing whether there's been a particular impact or harm? But then the academic world, who've been doing quite a bit of digging into this, and they've actually started to propose some taxonomies or classifications of harms. And this particular study here breaks it down into physical, psychological, emotional, economic, political, governmental, reputational, and cultural components. And these come together, and they're actually reused quite regularly now by different stakeholders across different sectors in terms of actually used as classification of harms. But there's some open questions here. Can we talk about community and societal harm? Is that something different from the classifications that have been put in here? Can we talk about the disproportionality of harms, for example, when we're talking about particular communities targeted through cyber attacks? If we're looking at gender-based targeting, for example, how is that taken into consideration in the existing frameworks that have been put forward? What about environmental? That doesn't seem to quite feature there yet. Is it coming under economic? Is it coming under


chunk_text:
  If the objective of the threat actor is of a particular nature, and he manages to gain something from the cyber attack, what does that mean in terms of assessing whether there's been a particular impact or harm? But then the academic world, who've been doing quite a bit of digging into this, and they've actually started to propose some taxonomies or classifications of harms. And this particular study here breaks it down into physical, psychological, emotional, economic, political, governmental, reputational, and cultural components. And these come together, and they're actually reused quite regularly now by different stakeholders across different sectors in terms of actually used as classification of harms. But there's some open questions here. Can we talk about community and societal harm? Is that something different from the classifications that have been put in here? Can we talk about the disproportionality of harms, for example, when we're talking about particular communities targeted through cyber attacks? If we're looking at gender-based targeting, for example, how is that taken into consideration in the existing frameworks that have been put forward? What about environmental? That doesn't seem to quite feature there yet. Is it coming under economic? Is it coming under cultural, perhaps? And then there's some fundamental questions. How do we actually access and collect data to be able to understand this harm? It's difficult. And that data is not so easy to collect, and we're going to go through that in a minute. So the healthcare sector. So we touched on an example earlier, and the particular visuals here are on the two sides, if we imagine the car accident. We've got on the left the hospital fighting the cyber threat actors. It is the operational disruption. What is being done to actually contain that incident, to actually try to minimise the impact of that incident over time? And then on the right-hand side, we see what's happening to the patients and to the healthcare professionals who are operating with systems that are being disrupted or data being exfiltrated related to sensitive patient information. So since June 2020, at the Cyber Peace Institute, we've been collecting and documenting cyber attacks against organisations in the healthcare sector across the world. And we're doing this through open source data collection, and we've been focusing predominantly on disruptive cyber attacks, so notably ransomware. And we've documented up until September last year, 501


chunk_text:
  cultural, perhaps? And then there's some fundamental questions. How do we actually access and collect data to be able to understand this harm? It's difficult. And that data is not so easy to collect, and we're going to go through that in a minute. So the healthcare sector. So we touched on an example earlier, and the particular visuals here are on the two sides, if we imagine the car accident. We've got on the left the hospital fighting the cyber threat actors. It is the operational disruption. What is being done to actually contain that incident, to actually try to minimise the impact of that incident over time? And then on the right-hand side, we see what's happening to the patients and to the healthcare professionals who are operating with systems that are being disrupted or data being exfiltrated related to sensitive patient information. So since June 2020, at the Cyber Peace Institute, we've been collecting and documenting cyber attacks against organisations in the healthcare sector across the world. And we're doing this through open source data collection, and we've been focusing predominantly on disruptive cyber attacks, so notably ransomware. And we've documented up until September last year, 501 incidents, specifically disruptive attacks against the healthcare sector. That's across 43 different countries. It's an average of 4.1 attacks a week, and that is barely scratching the surface. This is what we publicly know about. So what we decided to do when we were collecting this data is how do we actually start to define indicators to actually measure the harm and impact that these cyber attacks are having? And we're looking at global numbers, such as 21 million records breached. We're looking at 1,400 days of disruption in total, and again, this is just what is actually known in terms of those incidents. So what were we able to actually capture from our datasets? We were able to capture from what is known. So there's a big question mark at the bottom of this slide, it is what about the unknowns? And there are a large proportion of the incidents that we've documented for which there's no publicly available information on the impact and harm that they cause. But on average, 163,000 records are breached during a cyber incident on the healthcare sector. In 13% of cases, incidents resulted in patients being redirected from the facility that they were


chunk_text:
  incidents, specifically disruptive attacks against the healthcare sector. That's across 43 different countries. It's an average of 4.1 attacks a week, and that is barely scratching the surface. This is what we publicly know about. So what we decided to do when we were collecting this data is how do we actually start to define indicators to actually measure the harm and impact that these cyber attacks are having? And we're looking at global numbers, such as 21 million records breached. We're looking at 1,400 days of disruption in total, and again, this is just what is actually known in terms of those incidents. So what were we able to actually capture from our datasets? We were able to capture from what is known. So there's a big question mark at the bottom of this slide, it is what about the unknowns? And there are a large proportion of the incidents that we've documented for which there's no publicly available information on the impact and harm that they cause. But on average, 163,000 records are breached during a cyber incident on the healthcare sector. In 13% of cases, incidents resulted in patients being redirected from the facility that they were in. And in 15%, incidents resulted in cancelled appointments. This is significant when we think about the number of people that would have been using those services and those resources during the time of the cyber attack. And then we look at the organizational side, 19 days on average of operational impact on that hospital or that healthcare organization's capacity to deliver its services. 52% of incidents led to healthcare systems going offline, which means limiting access to certain types of information, certain types of tools during a cyber incident. And in 70% of those cases, we're talking about disruptive incidents here, in 70% of those cases, data was exposed or leaked. What can we draw from qualitative information? So there we were looking at the quantitative aspects. What can we numerically calculate? What is the qualitative data saying? So I'm not going to necessarily read through all of this, but I wanted to pick up some key words in the slide here. This is a real case example of a cyber attack against a hospital in France in August of last year. Medical images devices went down. Public admissions were inaccessible. 700,000 people used that particular hospital. They were


chunk_text:
  in. And in 15%, incidents resulted in cancelled appointments. This is significant when we think about the number of people that would have been using those services and those resources during the time of the cyber attack. And then we look at the organizational side, 19 days on average of operational impact on that hospital or that healthcare organization's capacity to deliver its services. 52% of incidents led to healthcare systems going offline, which means limiting access to certain types of information, certain types of tools during a cyber incident. And in 70% of those cases, we're talking about disruptive incidents here, in 70% of those cases, data was exposed or leaked. What can we draw from qualitative information? So there we were looking at the quantitative aspects. What can we numerically calculate? What is the qualitative data saying? So I'm not going to necessarily read through all of this, but I wanted to pick up some key words in the slide here. This is a real case example of a cyber attack against a hospital in France in August of last year. Medical images devices went down. Public admissions were inaccessible. 700,000 people used that particular hospital. They were unable to register new patients. There was redirection to nearby hospitals. There were precautionary measures that were taken to transfer infants in intensive care. Precautionary measures. They didn't even know if the cyber attack would impact the ability for that child to receive care, but they had to take the precautions to do so. How do we start to measure these things? Emergency care intake was decreased by more than half and certain patients couldn't be operated on. There were 11 gigabytes of confidential data that made it online that included scans, lab results and social security numbers. Let's have a think for a moment what that actually means. That's one of those 501 incidents in our database. Who in this room has actually heard of Vastamo? That's not very many. I'm hoping by the end of today you're going to remember them. They're a psychotherapy clinic that's based in Finland and they were targeted in a system breach back in November 2018, which was followed up by another one in 2019. The attackers came back only in September 2020, contacting Vastamo, requesting 40 bitcoins to be able to protect that data so it doesn't get leaked online. They refused.


chunk_text:
  unable to register new patients. There was redirection to nearby hospitals. There were precautionary measures that were taken to transfer infants in intensive care. Precautionary measures. They didn't even know if the cyber attack would impact the ability for that child to receive care, but they had to take the precautions to do so. How do we start to measure these things? Emergency care intake was decreased by more than half and certain patients couldn't be operated on. There were 11 gigabytes of confidential data that made it online that included scans, lab results and social security numbers. Let's have a think for a moment what that actually means. That's one of those 501 incidents in our database. Who in this room has actually heard of Vastamo? That's not very many. I'm hoping by the end of today you're going to remember them. They're a psychotherapy clinic that's based in Finland and they were targeted in a system breach back in November 2018, which was followed up by another one in 2019. The attackers came back only in September 2020, contacting Vastamo, requesting 40 bitcoins to be able to protect that data so it doesn't get leaked online. They refused. And what happened subsequently was the actual targeting of specific patients who were requested to pay 500 euros for their data not to feature online. This resulted in Vastamo actually having to declare bankruptcy in February 2021. Staff and patients had to be transferred to new services. They were fined post-bankruptcy by the Finnish Data Protection Authority for violation of GDPR. And then there was a suspect that was named in October 2022 and they were arrested in February 2023. That arrest is extremely rare in terms of cyber investigations. The accountability aspect, which Charlotte will touch upon later, is actually extremely rare that a cyber incident actually results in somebody being arrested. But this case had a significant impact on the Finnish healthcare sector, on the Finnish government, who had to revisit a whole number of different aspects of the way that they were protecting patient data. All the way to going through to new systems to actually allow for their citizens to actually have new identity numbers in the aftermath of a significant attack. So we've taken these kind of case studies as part of building a methodology where we actually break it down, break down the incidents


chunk_text:
  And what happened subsequently was the actual targeting of specific patients who were requested to pay 500 euros for their data not to feature online. This resulted in Vastamo actually having to declare bankruptcy in February 2021. Staff and patients had to be transferred to new services. They were fined post-bankruptcy by the Finnish Data Protection Authority for violation of GDPR. And then there was a suspect that was named in October 2022 and they were arrested in February 2023. That arrest is extremely rare in terms of cyber investigations. The accountability aspect, which Charlotte will touch upon later, is actually extremely rare that a cyber incident actually results in somebody being arrested. But this case had a significant impact on the Finnish healthcare sector, on the Finnish government, who had to revisit a whole number of different aspects of the way that they were protecting patient data. All the way to going through to new systems to actually allow for their citizens to actually have new identity numbers in the aftermath of a significant attack. So we've taken these kind of case studies as part of building a methodology where we actually break it down, break down the incidents into different categories, such as geographical, societal, operational, human and legal impacts of cyber attacks. I won't go through the details just for the sake of time. So our methodology then is taking up the notion of identifying indicators of harm based on the quantitative and qualitative data collection that we're doing. And we break this down into different columns or categories of harm that could be applicable to any cyber attack, no matter what sector, what domain, what type of cyber attack it is, to indicators that are sector specific. So for example, the healthcare sector, and then indicators that are attack specific, such as the notion of ransomware, a ransom paid is only going to be applicable in the context of a ransomware attack. And what we're then doing is identifying different weightings of indicators based on those notions of harm that we've identified. So we're looking here at raw numeric values that we could use as part of a future formula. We then also use categorical indicators. So here we mean we're transforming what would be potentially a yes or no answer to a question or a category, for example, whether an incident is actually confirmed or


chunk_text:
  into different categories, such as geographical, societal, operational, human and legal impacts of cyber attacks. I won't go through the details just for the sake of time. So our methodology then is taking up the notion of identifying indicators of harm based on the quantitative and qualitative data collection that we're doing. And we break this down into different columns or categories of harm that could be applicable to any cyber attack, no matter what sector, what domain, what type of cyber attack it is, to indicators that are sector specific. So for example, the healthcare sector, and then indicators that are attack specific, such as the notion of ransomware, a ransom paid is only going to be applicable in the context of a ransomware attack. And what we're then doing is identifying different weightings of indicators based on those notions of harm that we've identified. So we're looking here at raw numeric values that we could use as part of a future formula. We then also use categorical indicators. So here we mean we're transforming what would be potentially a yes or no answer to a question or a category, for example, whether an incident is actually confirmed or possible, what weight does that particular category or value then hold, converting that into a numerical value. And the next step, and this is where the methodology is work in progress and where we want to engage the community, is to actually figure out how do we mathematically combine these different indicators together to be able to compare incidents, one against the other, in terms of the impact and harm that they've had. There's also complexities with regards to this, and we mentioned this earlier, is how do we actually access the data? And if we're looking at certain things like the geographical impact of a cyber attack, the likelihood of us being able to acquire that data is actually very high. But then if we're looking at things like psychological harm, it's actually quite low. How do we go about actually collecting the psychological harm that's resulted from a cyber attack? So these are just some of the complexities and things that we're thinking about. I'll whiz through the work that we're doing on Ukraine. So since the beginning of last year, so in the month leading up to the invasion, we started to document cyber attacks and operations


chunk_text:
  possible, what weight does that particular category or value then hold, converting that into a numerical value. And the next step, and this is where the methodology is work in progress and where we want to engage the community, is to actually figure out how do we mathematically combine these different indicators together to be able to compare incidents, one against the other, in terms of the impact and harm that they've had. There's also complexities with regards to this, and we mentioned this earlier, is how do we actually access the data? And if we're looking at certain things like the geographical impact of a cyber attack, the likelihood of us being able to acquire that data is actually very high. But then if we're looking at things like psychological harm, it's actually quite low. How do we go about actually collecting the psychological harm that's resulted from a cyber attack? So these are just some of the complexities and things that we're thinking about. I'll whiz through the work that we're doing on Ukraine. So since the beginning of last year, so in the month leading up to the invasion, we started to document cyber attacks and operations in the context of the armed conflict. And to date, we've documented 1,330 cyber attacks that have happened either against organizations in Ukraine, organizations in the Russian Federation, or organizations outside of the two belligerent countries that are taking place in the context of the war. And so here we're back to some quantitative numbers. We're looking at roughly 21 attacks a week, 87 different threat actors, 23 sectors impacted, in 45 countries. But what we're starting to look at is how does the aggregation of these different cyber attacks together actually cause harm in itself? What is happening in terms of the persistent need for organizations to defend themselves? And the fact that they are operating in an environment where they actually have to expect to be attacked, and how is that impacting their ability to operate in terms of persistent defense? We've looked at also some of the qualitative aspects of what it means when organizations are targeted within certain sectors. So the energy sector, for example, what is happening when the electricity goes down? What is happening in the financial sector when we have cash machines that are not available for people to be able to withdraw


chunk_text:
  in the context of the armed conflict. And to date, we've documented 1,330 cyber attacks that have happened either against organizations in Ukraine, organizations in the Russian Federation, or organizations outside of the two belligerent countries that are taking place in the context of the war. And so here we're back to some quantitative numbers. We're looking at roughly 21 attacks a week, 87 different threat actors, 23 sectors impacted, in 45 countries. But what we're starting to look at is how does the aggregation of these different cyber attacks together actually cause harm in itself? What is happening in terms of the persistent need for organizations to defend themselves? And the fact that they are operating in an environment where they actually have to expect to be attacked, and how is that impacting their ability to operate in terms of persistent defense? We've looked at also some of the qualitative aspects of what it means when organizations are targeted within certain sectors. So the energy sector, for example, what is happening when the electricity goes down? What is happening in the financial sector when we have cash machines that are not available for people to be able to withdraw their money? What is happening in the context of the media? And when we talk about the media, we're really talking about the impacting of informational space and how the information narrative is actually being skewed in the context of the conflict. And then transportation, what is happening when certain transportation networks can't operate or when customers can't buy their tickets to be able to take the transport networks? So I've covered all of this, so I will move on. So why is, if we look at something like the context of Ukraine or the healthcare or the humanitarian sector, why is it important to measure these harms? And what we see is that it is partly about busting preconceptions. If you look at something like the war in Ukraine, people will say that war is happening between Ukraine and Russia, but we've monitored attacks happening in 45 other countries, and those attacks are countries that are not necessarily involved in the conflict, but they may have made a statement, for example, that they have stated that they believe that the sanctions should apply to Russia for its illegal annexation or occupation of Ukraine. And then immediately you see cyber


chunk_text:
  their money? What is happening in the context of the media? And when we talk about the media, we're really talking about the impacting of informational space and how the information narrative is actually being skewed in the context of the conflict. And then transportation, what is happening when certain transportation networks can't operate or when customers can't buy their tickets to be able to take the transport networks? So I've covered all of this, so I will move on. So why is, if we look at something like the context of Ukraine or the healthcare or the humanitarian sector, why is it important to measure these harms? And what we see is that it is partly about busting preconceptions. If you look at something like the war in Ukraine, people will say that war is happening between Ukraine and Russia, but we've monitored attacks happening in 45 other countries, and those attacks are countries that are not necessarily involved in the conflict, but they may have made a statement, for example, that they have stated that they believe that the sanctions should apply to Russia for its illegal annexation or occupation of Ukraine. And then immediately you see cyber attacks starting to happen. So even if you are not involved in that conflict as a belligerent country or as an organization that is involved in any way, shape or form, you're still becoming vulnerable. So it is important to bust some of those preconceptions about who's affected, but also how things are affected. It's not just about financial shutdown. It's not just about operational downtime. It is also important to use that in normative discussions. So there are ongoing at the moment UN negotiations around cybercrime for a new convention, and the Open Ended Working Group, which sits in New York, to discuss the use of ICTs, where there have been discussions ongoing for many years to develop normative framework, the norms that should ensure the appropriate use of technology or the appropriate responsibilities in relation to cybercrime. What we find in those discussions have started to have been really looking at actually undermining some of the existing protections that are there because of the negotiation stance of certain countries who are actually informing those processes and saying, well, look, it's not an attack in Ukraine unless there's actually been any harm. And because it's only a temporary shutdown


chunk_text:
  attacks starting to happen. So even if you are not involved in that conflict as a belligerent country or as an organization that is involved in any way, shape or form, you're still becoming vulnerable. So it is important to bust some of those preconceptions about who's affected, but also how things are affected. It's not just about financial shutdown. It's not just about operational downtime. It is also important to use that in normative discussions. So there are ongoing at the moment UN negotiations around cybercrime for a new convention, and the Open Ended Working Group, which sits in New York, to discuss the use of ICTs, where there have been discussions ongoing for many years to develop normative framework, the norms that should ensure the appropriate use of technology or the appropriate responsibilities in relation to cybercrime. What we find in those discussions have started to have been really looking at actually undermining some of the existing protections that are there because of the negotiation stance of certain countries who are actually informing those processes and saying, well, look, it's not an attack in Ukraine unless there's actually been any harm. And because it's only a temporary shutdown of a system, there's no harm, ergo, it's not an attack. But if you're only measuring harm in a very limited way, then there is a risk that those normative discussions end up developing policies and norms that we should be following, which actually do not reflect at all the operating environment with which we're in. It's also how do we look at reducing impact and increase accountability, because for victims of cyber attacks, how do they go about understanding how they've been affected, communicating how they've been affected, knowing what redress that they may have, whether that's at an individual level or a state level for, for example, criminal prosecutions that might come. And we see a lot of the threat actors today, for example, in Ukraine, there's been a lot of self-attribution. If you see that on the slide that Emma showed before, many, more than 80 threat actors, many of which have self-attributed and said, we have carried out the attack. So if we can manage, measure the harm that's been linked to that, and then look at the impact really of, of that cyber attack, that could lead to a prosecution, either domestically in the country


chunk_text:
  of a system, there's no harm, ergo, it's not an attack. But if you're only measuring harm in a very limited way, then there is a risk that those normative discussions end up developing policies and norms that we should be following, which actually do not reflect at all the operating environment with which we're in. It's also how do we look at reducing impact and increase accountability, because for victims of cyber attacks, how do they go about understanding how they've been affected, communicating how they've been affected, knowing what redress that they may have, whether that's at an individual level or a state level for, for example, criminal prosecutions that might come. And we see a lot of the threat actors today, for example, in Ukraine, there's been a lot of self-attribution. If you see that on the slide that Emma showed before, many, more than 80 threat actors, many of which have self-attributed and said, we have carried out the attack. So if we can manage, measure the harm that's been linked to that, and then look at the impact really of, of that cyber attack, that could lead to a prosecution, either domestically in the country where the attack has happened to also at an international level. So those things are going to be very important to understand and actually be able to frame what those harms mean. Increasing public awareness is critical because we've, we hear a lot about, it's not just when it's if a cyber attack happens, but people don't necessarily understand what that will mean for them. And so if we can raise the public awareness about all of the things that we were just discussing earlier, then it will really help to, to bust some of those myths and actually have a greater recognition of what harms and impacts are. We're also moving into an environment where cyber risks are increasing and there is a permissiveness around accountability for those attacks that are happening. It's allowing perpetrators of those violations to continue to not be brought to justice or, or to, to create an environment where attackers feel they won't be held accountable. If we can frame better the harms and impacts, it is clear that these are not victimless crimes. They're not computer crimes. They're not crimes that happen just about technology. They are affecting people. I think that is


chunk_text:
  where the attack has happened to also at an international level. So those things are going to be very important to understand and actually be able to frame what those harms mean. Increasing public awareness is critical because we've, we hear a lot about, it's not just when it's if a cyber attack happens, but people don't necessarily understand what that will mean for them. And so if we can raise the public awareness about all of the things that we were just discussing earlier, then it will really help to, to bust some of those myths and actually have a greater recognition of what harms and impacts are. We're also moving into an environment where cyber risks are increasing and there is a permissiveness around accountability for those attacks that are happening. It's allowing perpetrators of those violations to continue to not be brought to justice or, or to, to create an environment where attackers feel they won't be held accountable. If we can frame better the harms and impacts, it is clear that these are not victimless crimes. They're not computer crimes. They're not crimes that happen just about technology. They are affecting people. I think that is very, very important, particularly for decision makers who are framing policies and laws today and in the future. And it will help to contribute to improve stability in cyberspace because there's a growing distrust in the use of, of technology, the fear that our phones spy on us or that we shouldn't go online or because of, of, of the risks to us or that certain technology is a worry. And so, or countries worrying about back doors to use certain technology. So understanding harms and impacts and being able to use that to frame the, the, um, the public awareness, the policy decisions, and hopefully greater accountability can all lead to improved stability in cyberspace. And then there are some wider, broader implications that we have to look at. So I mentioned, you know, there is a very lack of accountability. There is this changing normative environment. The regulatory environment is changing quite quickly, dependent on, uh, different regions or different countries, but where you do have to report like for, uh, on GDPR for data breaches, where there are high fines, um, for those organizations that haven't reported breaches or on attacks on the healthcare sector, for example,


chunk_text:
  very, very important, particularly for decision makers who are framing policies and laws today and in the future. And it will help to contribute to improve stability in cyberspace because there's a growing distrust in the use of, of technology, the fear that our phones spy on us or that we shouldn't go online or because of, of, of the risks to us or that certain technology is a worry. And so, or countries worrying about back doors to use certain technology. So understanding harms and impacts and being able to use that to frame the, the, um, the public awareness, the policy decisions, and hopefully greater accountability can all lead to improved stability in cyberspace. And then there are some wider, broader implications that we have to look at. So I mentioned, you know, there is a very lack of accountability. There is this changing normative environment. The regulatory environment is changing quite quickly, dependent on, uh, different regions or different countries, but where you do have to report like for, uh, on GDPR for data breaches, where there are high fines, um, for those organizations that haven't reported breaches or on attacks on the healthcare sector, for example, in, in the U S where you have to, to report on those above a certain threshold, all of the implications of those, um, that more, um, tied to regulations and then compliance with those regulations will need also an increased awareness of what the harm is. Um, we know the risk of attack is high. Can we reduce the impact if we understand more what the impact is? Um, and then there's also the wider sort of sense of, of, of trusting technology. If you look at the, the fear or the, the awareness around cryptocurrency and the perception that that's the, the, the currency of choice, if you're going to carry out a ransomware, you know, that also great builds, um, or prejudices certain technology. And that's also a risk for, for society and risk for, for technology. And then look at the enormous costs that organizations and individuals are having to, to, to deploy in order to try prevent cyber incidences, defend against them and respond in terms of their own capabilities inside to build a more resilient organization. Uh, all of those are the broader implications of, of the recognition of the harms and impacts, which


chunk_text:
  in, in the U S where you have to, to report on those above a certain threshold, all of the implications of those, um, that more, um, tied to regulations and then compliance with those regulations will need also an increased awareness of what the harm is. Um, we know the risk of attack is high. Can we reduce the impact if we understand more what the impact is? Um, and then there's also the wider sort of sense of, of, of trusting technology. If you look at the, the fear or the, the awareness around cryptocurrency and the perception that that's the, the, the currency of choice, if you're going to carry out a ransomware, you know, that also great builds, um, or prejudices certain technology. And that's also a risk for, for society and risk for, for technology. And then look at the enormous costs that organizations and individuals are having to, to, to deploy in order to try prevent cyber incidences, defend against them and respond in terms of their own capabilities inside to build a more resilient organization. Uh, all of those are the broader implications of, of the recognition of the harms and impacts, which go far beyond those, which are just the risks to the organization of its financial, or operational shutdown. To conclude, therefore, we've been working on this methodology. We are now engaging with the wider community, cybersecurity experts, governments, international organizations, the private sector, other civil society organizations, academia, insurance, to really look, take the methodology that we've been working on, take the questions that are still there, and then work with this, with the community to really try to, to look at how we can reinforce this methodology, how we can build on this methodology, how we can strengthen it around the data collection around the identification of indicators, measuring over time or measuring different types of, of attacks with a view of then looking at, well, so how would we be able to make this methodology something that does become a reference point? So over the next months, we, we are engaging with different actors across different sectors, and we're very interested to have any feedback that you may have on, on this work. And with that, we will then also obviously clearly be making this methodology public later in the year. So thank you very much for, for


chunk_text:
  go far beyond those, which are just the risks to the organization of its financial, or operational shutdown. To conclude, therefore, we've been working on this methodology. We are now engaging with the wider community, cybersecurity experts, governments, international organizations, the private sector, other civil society organizations, academia, insurance, to really look, take the methodology that we've been working on, take the questions that are still there, and then work with this, with the community to really try to, to look at how we can reinforce this methodology, how we can build on this methodology, how we can strengthen it around the data collection around the identification of indicators, measuring over time or measuring different types of, of attacks with a view of then looking at, well, so how would we be able to make this methodology something that does become a reference point? So over the next months, we, we are engaging with different actors across different sectors, and we're very interested to have any feedback that you may have on, on this work. And with that, we will then also obviously clearly be making this methodology public later in the year. So thank you very much for, for your attention, and we're open for any questions. Thank you. Please raise your hand for questions. Hi, thank you. I am a big fan of trying to understand impact and harm. Sorry, those terms are a little bit close to one another, right? So I might not use them the same way that you do. At the same time, I'm trying to figure out who's the primary audience of this message? Are you trying to convince policyholders to, to implement this framework? Are you trying to convince industry? Are you trying to come up with a new vocabulary for NGOs to use? Can you help me understand where this fits in? Certainly, the big gap today is that we all talk about these things in very different ways. And I think that's a challenge, particularly when we're trying to inform both victims of those attacks, which is primarily for us, the humanitarian sector, health sector, critical infrastructure sector, but also states that are making decisions about this and are influencing, or the only ones who can really take positions at, in these fora, about what these harms and impacts are, because that will help inform those policy decisions. So definitely


chunk_text:
  your attention, and we're open for any questions. Thank you. Please raise your hand for questions. Hi, thank you. I am a big fan of trying to understand impact and harm. Sorry, those terms are a little bit close to one another, right? So I might not use them the same way that you do. At the same time, I'm trying to figure out who's the primary audience of this message? Are you trying to convince policyholders to, to implement this framework? Are you trying to convince industry? Are you trying to come up with a new vocabulary for NGOs to use? Can you help me understand where this fits in? Certainly, the big gap today is that we all talk about these things in very different ways. And I think that's a challenge, particularly when we're trying to inform both victims of those attacks, which is primarily for us, the humanitarian sector, health sector, critical infrastructure sector, but also states that are making decisions about this and are influencing, or the only ones who can really take positions at, in these fora, about what these harms and impacts are, because that will help inform those policy decisions. So definitely at a state level, it's very important. And we see, and the feedback we get is there's a big gap for them in this regard, and they would like contributions that can come. But civil society organisations, like we can't, and shouldn't be doing this alone. We should be engaging with all the different actors that can help inform that, but also can build on work that's already been done. So I think our appeal is really to have a wider sense of engagement from different actors, so that it can then be used as a methodology, which is going to help particularly in decision making and for stability. And just to touch also on the notion of the NGOs and the non-profit organisations that we're supporting as part of our assistance services at the Cyber Peace Institute. It's actually, there is still a lack of awareness of what a cyber security incident can actually do to your operational activities. This is happening every day, and it seems to be, let's react post a major incident. So to be able to actually measure that impact and harm in a way that is more tangible, and the idea is to raise


chunk_text:
  at a state level, it's very important. And we see, and the feedback we get is there's a big gap for them in this regard, and they would like contributions that can come. But civil society organisations, like we can't, and shouldn't be doing this alone. We should be engaging with all the different actors that can help inform that, but also can build on work that's already been done. So I think our appeal is really to have a wider sense of engagement from different actors, so that it can then be used as a methodology, which is going to help particularly in decision making and for stability. And just to touch also on the notion of the NGOs and the non-profit organisations that we're supporting as part of our assistance services at the Cyber Peace Institute. It's actually, there is still a lack of awareness of what a cyber security incident can actually do to your operational activities. This is happening every day, and it seems to be, let's react post a major incident. So to be able to actually measure that impact and harm in a way that is more tangible, and the idea is to raise that awareness to get people to think about how they actually increase their cyber security resilience, and to be able to reduce the impact of a cyber attack. We can't prevent every cyber attack from taking place, but we can certainly raise the awareness for the need for them to actually act before it's too late. And to build on that, I think one of the organisations we've helped, quite a number of organisations that have been going through cyber attacks. Interestingly, they came back and said, even after the attack was over, and they had, whether it was a fraud, or whether it was a breach into their systems, and interference and disruption of their systems, they came back and said the psychological impact has gone on far, far longer than the actual recovery, and that that was completely underestimated. And they needed to also use that sort of information to help inform and support the staff as they were going forward, not just then to have processes in place to build a better resilience to that, but also looking and saying, wow, how do we overcome that? How do we manage that? And a lot of the leadership


chunk_text:
  that awareness to get people to think about how they actually increase their cyber security resilience, and to be able to reduce the impact of a cyber attack. We can't prevent every cyber attack from taking place, but we can certainly raise the awareness for the need for them to actually act before it's too late. And to build on that, I think one of the organisations we've helped, quite a number of organisations that have been going through cyber attacks. Interestingly, they came back and said, even after the attack was over, and they had, whether it was a fraud, or whether it was a breach into their systems, and interference and disruption of their systems, they came back and said the psychological impact has gone on far, far longer than the actual recovery, and that that was completely underestimated. And they needed to also use that sort of information to help inform and support the staff as they were going forward, not just then to have processes in place to build a better resilience to that, but also looking and saying, wow, how do we overcome that? How do we manage that? And a lot of the leadership of those organisations, which are often being targeted, say, we are not armed to be able to do that at all. So I think on many different levels, we can play this. But I think for the organisations themselves also to realise it's normal to have an enormous psychological impact of an attack, that would be part of it. And that is an impact or harm that's really important. Thank you. Hi, thanks for the talk. So I fully agree with the message that you're trying to convey about the importance of measuring harm. Though in my experience, every time I try to propose like a policy change, the people in charge ask for sort of a real measurable number. Like you seem to agree with this. Do you have any sort of advice or a preferred framework to attach a number to, you know, the predicted harm caused? Thank you. For prediction or for... The predicted caused harm. So I think we go down to the slides that potentially whizzed through a little bit quickly, is the notion that what is a measure? And that measure can be a numerical measure, a quantitative value, like it can be a


chunk_text:
  of those organisations, which are often being targeted, say, we are not armed to be able to do that at all. So I think on many different levels, we can play this. But I think for the organisations themselves also to realise it's normal to have an enormous psychological impact of an attack, that would be part of it. And that is an impact or harm that's really important. Thank you. Hi, thanks for the talk. So I fully agree with the message that you're trying to convey about the importance of measuring harm. Though in my experience, every time I try to propose like a policy change, the people in charge ask for sort of a real measurable number. Like you seem to agree with this. Do you have any sort of advice or a preferred framework to attach a number to, you know, the predicted harm caused? Thank you. For prediction or for... The predicted caused harm. So I think we go down to the slides that potentially whizzed through a little bit quickly, is the notion that what is a measure? And that measure can be a numerical measure, a quantitative value, like it can be a qualitative one. And sometimes the message that is clearest to get through is what qualitative information is actually telling us. And it's converting that qualitative information into something that people relate to. And so the way that we are really constructing this from our perspective is to say we need to pull on many things. We need to pull on the fact that there's a financial cost to an organisation. Yes, that's going to make the CEO wake up. But there are going to be other components where we're going to be able to say to an organisation, if there is a cyber attack that's happened on a hospital, and you have five doctors that are going to be unavailable for the next four weeks, because they are so traumatised by what has happened and the fact that they haven't been able to deal with emergency care patients, that is something that should speak to many people. And I think actually by using the business impact, so the part that I was talking about, really the organisational impact of harm, we're so removing it from the human impact that actually it's difficult for us as humans, as individuals, as people


chunk_text:
  qualitative one. And sometimes the message that is clearest to get through is what qualitative information is actually telling us. And it's converting that qualitative information into something that people relate to. And so the way that we are really constructing this from our perspective is to say we need to pull on many things. We need to pull on the fact that there's a financial cost to an organisation. Yes, that's going to make the CEO wake up. But there are going to be other components where we're going to be able to say to an organisation, if there is a cyber attack that's happened on a hospital, and you have five doctors that are going to be unavailable for the next four weeks, because they are so traumatised by what has happened and the fact that they haven't been able to deal with emergency care patients, that is something that should speak to many people. And I think actually by using the business impact, so the part that I was talking about, really the organisational impact of harm, we're so removing it from the human impact that actually it's difficult for us as humans, as individuals, as people to relate to. So I don't know if that answers your question specifically or if Charlotte, you want to... Yeah, and I think we looked at the healthcare sector, for example, and we brought, we ran a process of multi-stakeholder engagement where we put in the room cyber security experts, we put in those responsible for hospitals, the administration, finance, we put governments, we put civil society, international organisations. And what was very interesting was to see, hey, they're all speaking very different languages. There's very little engagement in those that we were, that we brought together with actually those who were making decisions about budgets on security or because they were very much reading the notion of risk very differently and also the potential impact. So by putting different stakeholders together, it is a way to help build some sort of methodology that can inform and speak a language that could combine or unite going forward because so far it's very siloed. And I think these coming up within a methodology that can help break down those silos or where at least they're speaking some sort of common language or that they can understand, that everybody can adhere to,


chunk_text:
  to relate to. So I don't know if that answers your question specifically or if Charlotte, you want to... Yeah, and I think we looked at the healthcare sector, for example, and we brought, we ran a process of multi-stakeholder engagement where we put in the room cyber security experts, we put in those responsible for hospitals, the administration, finance, we put governments, we put civil society, international organisations. And what was very interesting was to see, hey, they're all speaking very different languages. There's very little engagement in those that we were, that we brought together with actually those who were making decisions about budgets on security or because they were very much reading the notion of risk very differently and also the potential impact. So by putting different stakeholders together, it is a way to help build some sort of methodology that can inform and speak a language that could combine or unite going forward because so far it's very siloed. And I think these coming up within a methodology that can help break down those silos or where at least they're speaking some sort of common language or that they can understand, that everybody can adhere to, I think will help as we move forward. Thank you. Any other questions? Thank you very much for your talk, for your insights. Thank you.


chunk_text:
  I think will help as we move forward. Thank you. Any other questions? Thank you very much for your talk, for your insights. Thank you.


chunk_text:
  { "webpage_url": "https://www.youtube.com/watch?v=vTnEehai3lE", "title": "Modern Adventures With Legacy Protocols by Yannay Livneh", "description": "", "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA", "duration": 2132, "channel": "scrt.insomnihack", "uploader": "scrt.insomnihack", "upload_date": "20230411" } This text was transcribed using whisper model: large-v2 Okay, hello, I'm Yanai, and in this talk, welcome to my talk, Modern Adventures with Legacy Protocols. In this talk, I'm going to discuss the research I was doing since 2018, more or less, in which I got the capability and I'll tell you how to do IP spoofing by yourself, which is quite cool. For this research, I received the Pony Award in less bracket for the most under-hyped research, and if you want to know what the hype was not about, just stick with me. So let's get this out of the way, I'm Yanai, I'm a security researcher, I'm doing some low-level embedded stuff, browsers, whatever, and this talk is not affiliated with my employer because my employer has nothing to do with it, I did it in my spare time. Okay, what are we gonna, how this talk is gonna be, we'll have some background motivation, what is IP, what is IP spoofing, why you want to do IP spoofing, and then I'll talk about my research, how I've done it, the struggles, what worked, what didn't work, and then there will be a short demo that I hope will work, and then I'll discuss the findings, I'll talk to you a bit about the disclosure procedure, so if you're interested in how disclosure works and what to expect that might interest you, spoiler, it wasn't fun, and last I'll talk a bit about future research that can be done using this research, so without further ado, what is IP, a quick reminder, IP is how we send packets on the internet, and every packet that goes on the internet has two bits of information in it, a source and a destination, the destination is what we use to basically send the packet to wherever we want it to be, so this is the destination address, and the source address, well, it should be the address from which the packet originates, so when we're sending a packet we should write our own address, but of course the flaw is that basically nobody is verifying that the source IP is the right IP, so if my address is 1234, I can put 5555 there,


chunk_text:
  talk about my research, how I've done it, the struggles, what worked, what didn't work, and then there will be a short demo that I hope will work, and then I'll discuss the findings, I'll talk to you a bit about the disclosure procedure, so if you're interested in how disclosure works and what to expect that might interest you, spoiler, it wasn't fun, and last I'll talk a bit about future research that can be done using this research, so without further ado, what is IP, a quick reminder, IP is how we send packets on the internet, and every packet that goes on the internet has two bits of information in it, a source and a destination, the destination is what we use to basically send the packet to wherever we want it to be, so this is the destination address, and the source address, well, it should be the address from which the packet originates, so when we're sending a packet we should write our own address, but of course the flaw is that basically nobody is verifying that the source IP is the right IP, so if my address is 1234, I can put 5555 there, and the problem that can arise from this is that if a service receives a packet and the source address is from the real Slim Shady, and the real Slim Shady is asking you to do something, and you believe it's the real Slim Shady because it has the address of the real Slim Shady, then you will do whatever Slim Shady is asking from you to do, and this is kind of authentication bypass. Another problem that can occur is that maybe you're an unsuspecting server on the internet, and all of the sudden someone is sending you a packet with a spoofed source address, and you're receiving this packet, and you say, hey, that's not for me, I'm not doing whatever you're asking, and you're sending a reply, and you're replying to the source address. Now if the source address is spoofed to be somebody else, you'll just send the packet to some other unsuspecting server, and if too many servers are doing this at once, basically you can execute a denial of service attack. Okay, so these are the two things that IP spoofing can cause, can lead to, and let's see some examples for that. So


chunk_text:
  and the problem that can arise from this is that if a service receives a packet and the source address is from the real Slim Shady, and the real Slim Shady is asking you to do something, and you believe it's the real Slim Shady because it has the address of the real Slim Shady, then you will do whatever Slim Shady is asking from you to do, and this is kind of authentication bypass. Another problem that can occur is that maybe you're an unsuspecting server on the internet, and all of the sudden someone is sending you a packet with a spoofed source address, and you're receiving this packet, and you say, hey, that's not for me, I'm not doing whatever you're asking, and you're sending a reply, and you're replying to the source address. Now if the source address is spoofed to be somebody else, you'll just send the packet to some other unsuspecting server, and if too many servers are doing this at once, basically you can execute a denial of service attack. Okay, so these are the two things that IP spoofing can cause, can lead to, and let's see some examples for that. So these are research I was doing in less than 10 years or so, so this one is the more recent one. I researched this OBD tracker, so this is a device that's used by fleet managers to know where their cars are at any given moment of time, because they have many cars, they have many drivers, they want to know where the cars are and some basic information about the car, so they can buy this device, put it in every car they have, and now they can have the location, the GPS location of every car they have. The problem with this embedded device is that, one of the problems actually, is that it's used to receive commands from a pre-configured management server, and the only authentication they have for the commands that come from the server was the IP address of the pre-configured management server. And it was done, the commands were sent over UDP of course, because why not, and there was no authentication, and you can send any command. The command I choose to send is firmware upgrade of course, so I could do IP spoofing and send a firmware upgrade command and upgrade the


chunk_text:
  these are research I was doing in less than 10 years or so, so this one is the more recent one. I researched this OBD tracker, so this is a device that's used by fleet managers to know where their cars are at any given moment of time, because they have many cars, they have many drivers, they want to know where the cars are and some basic information about the car, so they can buy this device, put it in every car they have, and now they can have the location, the GPS location of every car they have. The problem with this embedded device is that, one of the problems actually, is that it's used to receive commands from a pre-configured management server, and the only authentication they have for the commands that come from the server was the IP address of the pre-configured management server. And it was done, the commands were sent over UDP of course, because why not, and there was no authentication, and you can send any command. The command I choose to send is firmware upgrade of course, so I could do IP spoofing and send a firmware upgrade command and upgrade the firmware of this device, and this let me send any message I want to the CAN network in the car. This network is the network with which you're sending commands to every computer of the car, so the engine, the lights, the windchills, whatever, so basically you can just completely take over the car. These vulnerabilities were disclosed a few years ago, so they're fine. The second motivation is a bit more complicated, but I was part of a red team, we're just trying to do some pentesting on this web server, and my teammates got a local file read, something called LFI, and the title is quite small, I don't know why, but okay, and we could read the code from this server, and the server was doing something a bit weird, so I'm very sorry there is a PHP code in here, this is the last time you'll see PHP code in this talk, but for you who have the luck not to know PHP, what the server was doing, it was making an HTTP request to some third-party server, let's say foo.xyz, and the server was replying with a JSON, and the way this web server thought


chunk_text:
  firmware of this device, and this let me send any message I want to the CAN network in the car. This network is the network with which you're sending commands to every computer of the car, so the engine, the lights, the windchills, whatever, so basically you can just completely take over the car. These vulnerabilities were disclosed a few years ago, so they're fine. The second motivation is a bit more complicated, but I was part of a red team, we're just trying to do some pentesting on this web server, and my teammates got a local file read, something called LFI, and the title is quite small, I don't know why, but okay, and we could read the code from this server, and the server was doing something a bit weird, so I'm very sorry there is a PHP code in here, this is the last time you'll see PHP code in this talk, but for you who have the luck not to know PHP, what the server was doing, it was making an HTTP request to some third-party server, let's say foo.xyz, and the server was replying with a JSON, and the way this web server thought would be smart to parse the reply was to write the reply to a file and then evaluate it as PHP, and this is a very bad decision. Yeah, I can see on your faces, you know it's a bad decision, because now, yes, now if an attacker like myself can control the JSON, basically I can execute any PHP code that I want. Right, cool, so basically we read the code, we see that the target was fetching and evaluating the JSON, and then we can use the local file read again to read the proc file system, which gave us the addresses of the connection between the two servers. If you don't know about TCP injection, that's a bit hard to explain, but I'll do it in a second. I want to send data inside a TCP connection, I have to know five things, the source address, the destination address, the source port, and the destination port of the connection, and something called a sequence number, and if I know all these things, I can send any data I want, if I have IP spoofing capabilities, and to get all these things, I can read the proc file


chunk_text:
  would be smart to parse the reply was to write the reply to a file and then evaluate it as PHP, and this is a very bad decision. Yeah, I can see on your faces, you know it's a bad decision, because now, yes, now if an attacker like myself can control the JSON, basically I can execute any PHP code that I want. Right, cool, so basically we read the code, we see that the target was fetching and evaluating the JSON, and then we can use the local file read again to read the proc file system, which gave us the addresses of the connection between the two servers. If you don't know about TCP injection, that's a bit hard to explain, but I'll do it in a second. I want to send data inside a TCP connection, I have to know five things, the source address, the destination address, the source port, and the destination port of the connection, and something called a sequence number, and if I know all these things, I can send any data I want, if I have IP spoofing capabilities, and to get all these things, I can read the proc file system, so this gives me the addresses and the ports, and to infer the sequence number, we used a very old bug in the Linux kernel that didn't have a CVE, it was fixed in 2012, but the fix was not very widely deployed at the time, because it didn't have a CVE. It's by this really, really cool researcher that I don't know how to pronounce his name, but he's very cool, and check out his other work, I'm sorry, and we use all that, and we use our IP spoofing capability with the TCP injection, we injected a PHP code instead of the JSON, and we basically got an RCE on the target. So these are two examples in which IP spoofing can be very, very helpful, and were helpful to me. So I'm not that smart, I did not invent IP spoofing or TCP injection, that's as old as IP, I think, and for this reason, about 20 years ago or so, the Internet Engineering Task Force came with this guideline that said that internet service providers should filter, should put firewall rules that will prevent this attack. So these are quads from the BCP38, from this


chunk_text:
  system, so this gives me the addresses and the ports, and to infer the sequence number, we used a very old bug in the Linux kernel that didn't have a CVE, it was fixed in 2012, but the fix was not very widely deployed at the time, because it didn't have a CVE. It's by this really, really cool researcher that I don't know how to pronounce his name, but he's very cool, and check out his other work, I'm sorry, and we use all that, and we use our IP spoofing capability with the TCP injection, we injected a PHP code instead of the JSON, and we basically got an RCE on the target. So these are two examples in which IP spoofing can be very, very helpful, and were helpful to me. So I'm not that smart, I did not invent IP spoofing or TCP injection, that's as old as IP, I think, and for this reason, about 20 years ago or so, the Internet Engineering Task Force came with this guideline that said that internet service providers should filter, should put firewall rules that will prevent this attack. So these are quads from the BCP38, from this guideline, and they want to defeat IP source address spoofing, and they're telling the internet service providers, please block IP packets entering the internet which have source IP addresses, which are forged IP addresses, that were not assigned to the device which is sending them. Because you're the ISP, you're the one assigning the IP addresses to everyone connected by you. So you know what is the correct IP address, and if you see a device that's sending a packet with an IP address which is not the one that you assigned, please drop them. And basically everyone implemented this guideline. I'm from Israel, and Israel, all the ISP implemented it, I couldn't find an ISP that does not do IP ingress filtering, all the cloud providers implemented it, Google, AWS, I didn't check Azure, but you can, I believe they do it. And this is a bit annoying, and you're probably asking yourself, well, but you just said you did IP spoofing in the last 10 years, and the answer is complicated. So in the first one, I was lying, I didn't actually do IP spoofing, I reported a vulnerability that could arise if IP spoofing is possible. And


chunk_text:
  guideline, and they want to defeat IP source address spoofing, and they're telling the internet service providers, please block IP packets entering the internet which have source IP addresses, which are forged IP addresses, that were not assigned to the device which is sending them. Because you're the ISP, you're the one assigning the IP addresses to everyone connected by you. So you know what is the correct IP address, and if you see a device that's sending a packet with an IP address which is not the one that you assigned, please drop them. And basically everyone implemented this guideline. I'm from Israel, and Israel, all the ISP implemented it, I couldn't find an ISP that does not do IP ingress filtering, all the cloud providers implemented it, Google, AWS, I didn't check Azure, but you can, I believe they do it. And this is a bit annoying, and you're probably asking yourself, well, but you just said you did IP spoofing in the last 10 years, and the answer is complicated. So in the first one, I was lying, I didn't actually do IP spoofing, I reported a vulnerability that could arise if IP spoofing is possible. And the second one, well, so, oh yeah, there is this, I forgot this, that you shouldn't think about mitigations too highly, but let's go on. So in the second one, the servers that I injected the JSON or the PHP code didn't talk in IPv4, they were talking in IPv6, which is the latter version of the internet protocol. And the thing now is that I did not have an IPv6 connection, I only had IPv4 connection. So what did I do? I went on Google and wrote, how can I send IPv6 packets if I only have IPv4 connection? And the internet was very helpful, and it gave me this IPv6 over IPv4 tunneling server that, after a short registration, would let me send any IPv6 packet that I wanted, including the one that I wanted to spoof, right, because I was spoofing IP packets. And in retrospect, I realized that there was no filtering, so this IPv6 tunneling broker did not filter my packets. And that led me to the very nice conclusion. By the way, if you like these things, I have another Twitter account in which we post or used to post this kind of inspirational


chunk_text:
  the second one, well, so, oh yeah, there is this, I forgot this, that you shouldn't think about mitigations too highly, but let's go on. So in the second one, the servers that I injected the JSON or the PHP code didn't talk in IPv4, they were talking in IPv6, which is the latter version of the internet protocol. And the thing now is that I did not have an IPv6 connection, I only had IPv4 connection. So what did I do? I went on Google and wrote, how can I send IPv6 packets if I only have IPv4 connection? And the internet was very helpful, and it gave me this IPv6 over IPv4 tunneling server that, after a short registration, would let me send any IPv6 packet that I wanted, including the one that I wanted to spoof, right, because I was spoofing IP packets. And in retrospect, I realized that there was no filtering, so this IPv6 tunneling broker did not filter my packets. And that led me to the very nice conclusion. By the way, if you like these things, I have another Twitter account in which we post or used to post this kind of inspirational plots for exploiters, so I'll put the link in the end. But this led me to realize that sometimes it's not about what you're actually trying to do, but sometimes it's about the way, right, sometimes it's the things you collect along the way. And maybe there is a similar protocol, or maybe there are more brokers on the internet, like the one that was doing this IPv6 brokering, that would actually let me do IPv4 brokering without filtering. So I was checking out if there is an IPv4 over IPv4, and lo and behold, there is an IPv4 over IPv4 protocol. It's actually one of the oldest protocols over AP that existed. You can check out all the existing protocols in slash etc slash protocols on your Linux machine if you have one. Maybe not all of them, but most of them. And this IPv4 over IPv4 was the first ever tunneling protocol. It was like a very, very, very primitive VPN, and it has no authentication. It's really impossible to set up because, well, I failed to set it up when I wanted to do some testing. And this should be extinct because today we have much better


chunk_text:
  plots for exploiters, so I'll put the link in the end. But this led me to realize that sometimes it's not about what you're actually trying to do, but sometimes it's about the way, right, sometimes it's the things you collect along the way. And maybe there is a similar protocol, or maybe there are more brokers on the internet, like the one that was doing this IPv6 brokering, that would actually let me do IPv4 brokering without filtering. So I was checking out if there is an IPv4 over IPv4, and lo and behold, there is an IPv4 over IPv4 protocol. It's actually one of the oldest protocols over AP that existed. You can check out all the existing protocols in slash etc slash protocols on your Linux machine if you have one. Maybe not all of them, but most of them. And this IPv4 over IPv4 was the first ever tunneling protocol. It was like a very, very, very primitive VPN, and it has no authentication. It's really impossible to set up because, well, I failed to set it up when I wanted to do some testing. And this should be extinct because today we have much better alternatives. We have, I don't know, WireGuard for VPNs, right? We don't need IPv4 over IPv4. But I decided to research this. So how do you start such a research? Well, first thing you do is how do you send a simple IP packet, right? So this is a scapy package for Python that lets you send some IP packets very easily. So if you've seen this first example, I just defined an IP packet. I say the destination is where I want to send my packet, 999 is the address I want to send the packet to. Then I stack some data over it using the slash, like the protocol stacking operator, and then I send it. And if I want to do IP spoofing, right? So let's say 1234 is like a broker that would do IP over IP for me. Then I can send a packet. And you see the first packet is the same, but this time I'm writing that the source address is the broker's address. And the second packet is the one carrying the former packet. And this one would be sent to the broker. And the destination address is the IPIP service. And


chunk_text:
  alternatives. We have, I don't know, WireGuard for VPNs, right? We don't need IPv4 over IPv4. But I decided to research this. So how do you start such a research? Well, first thing you do is how do you send a simple IP packet, right? So this is a scapy package for Python that lets you send some IP packets very easily. So if you've seen this first example, I just defined an IP packet. I say the destination is where I want to send my packet, 999 is the address I want to send the packet to. Then I stack some data over it using the slash, like the protocol stacking operator, and then I send it. And if I want to do IP spoofing, right? So let's say 1234 is like a broker that would do IP over IP for me. Then I can send a packet. And you see the first packet is the same, but this time I'm writing that the source address is the broker's address. And the second packet is the one carrying the former packet. And this one would be sent to the broker. And the destination address is the IPIP service. And just sending these to one on top of the other would do the trick. I'll show you this soon in the demo. But this would fail, right? Because now I am filtered by my ISP, by my cloud provider, by someone. But we can do this. And we can just scan, look for brokers that exist in the wild. And two questions come to mind. Which addresses should we scan? Where should we look for such brokers? And how do we know that we actually found a broker, right? How can we tell that? And the answers are quite straightforward. So we should scan the entire internet. There are like 4 billion addresses. That's not so much. At least in IPv4, it's not so much. And the success indication is also quite easy. I mean, the server can just reply with the... We can just ask the server, the broker, to send the packet back to us. This is how we will know that actually the server is doing what we asked it to do. Okay, cool. So I wrote this, basically, probe module in a project called ZMap. ZMap is a very nice project for scanning the internet, if


chunk_text:
  just sending these to one on top of the other would do the trick. I'll show you this soon in the demo. But this would fail, right? Because now I am filtered by my ISP, by my cloud provider, by someone. But we can do this. And we can just scan, look for brokers that exist in the wild. And two questions come to mind. Which addresses should we scan? Where should we look for such brokers? And how do we know that we actually found a broker, right? How can we tell that? And the answers are quite straightforward. So we should scan the entire internet. There are like 4 billion addresses. That's not so much. At least in IPv4, it's not so much. And the success indication is also quite easy. I mean, the server can just reply with the... We can just ask the server, the broker, to send the packet back to us. This is how we will know that actually the server is doing what we asked it to do. Okay, cool. So I wrote this, basically, probe module in a project called ZMap. ZMap is a very nice project for scanning the internet, if you want to scan for some vulnerabilities or stuff. And I wrote this probe module. And if you have a nice direct access to the internet, I mean, you shouldn't do it from a private network like here, but maybe from, I don't know, Google Virtual... Like a GCP, Google Cloud Virtual Machine can work well. And you have a reasonable bandwidth, then you can just scan the internet in a few days. And yeah, so I first started with my first setup. And I have a very old router at home, or I used to have until two years ago, that was from 2010. And it runs OpenWRT. So I just compiled ZMap with my custom module to this OpenWRT. My ISP was not complaining. It's very relaxed. I don't think anyone is monitoring IP layer. So I think the only monitoring there is on the internet is in the fourth layer. So TCP, or UDP, or I don't know, SETP. And when I was scanning the internet in this layer, in layer four, I got many complaints. But if you're scanning the internet for a layer free, that's awesome. Nobody cares. Okay, so go ahead and do it.


chunk_text:
  you want to scan for some vulnerabilities or stuff. And I wrote this probe module. And if you have a nice direct access to the internet, I mean, you shouldn't do it from a private network like here, but maybe from, I don't know, Google Virtual... Like a GCP, Google Cloud Virtual Machine can work well. And you have a reasonable bandwidth, then you can just scan the internet in a few days. And yeah, so I first started with my first setup. And I have a very old router at home, or I used to have until two years ago, that was from 2010. And it runs OpenWRT. So I just compiled ZMap with my custom module to this OpenWRT. My ISP was not complaining. It's very relaxed. I don't think anyone is monitoring IP layer. So I think the only monitoring there is on the internet is in the fourth layer. So TCP, or UDP, or I don't know, SETP. And when I was scanning the internet in this layer, in layer four, I got many complaints. But if you're scanning the internet for a layer free, that's awesome. Nobody cares. Okay, so go ahead and do it. And yeah, but there is just one minor problem that my girlfriend was pissed because I was choking the internet. And I cannot deprive her from Netflix for five days. So this didn't fly. So I came up with a better setup. And this was Google Cloud, right? Why is the title so small? Well, anyway, so Google Cloud, basically, you do get an IP address, but you get an internal IP address. And there is a small problem with that. ZBup doesn't really like to scan from internal addresses because you're trying to do when you're trying to reach external addresses. So it's a small complication. I won't go much into details. But the thing is, you can bypass this complication by spoofing your own external address. So I think what happens, I didn't verify it, but you have two parts there. You have the network address translation that translates your internal IP address that you get in the Google network or in your private virtual network within Google Cloud. And then there is the external IP address, your ephemeral address. And there is the address translator that translates from the internal address to the external address. And after


chunk_text:
  And yeah, but there is just one minor problem that my girlfriend was pissed because I was choking the internet. And I cannot deprive her from Netflix for five days. So this didn't fly. So I came up with a better setup. And this was Google Cloud, right? Why is the title so small? Well, anyway, so Google Cloud, basically, you do get an IP address, but you get an internal IP address. And there is a small problem with that. ZBup doesn't really like to scan from internal addresses because you're trying to do when you're trying to reach external addresses. So it's a small complication. I won't go much into details. But the thing is, you can bypass this complication by spoofing your own external address. So I think what happens, I didn't verify it, but you have two parts there. You have the network address translation that translates your internal IP address that you get in the Google network or in your private virtual network within Google Cloud. And then there is the external IP address, your ephemeral address. And there is the address translator that translates from the internal address to the external address. And after that, I think there is the firewall that actually drops packets if you're trying to spoof packets. And if you're spoofing your own external address, there is no problem because the first part, the address translator will not translate anything because the source IP is an external IP. And the second part, the firewall will not drop the packet because it originates from your own IP address, which you're allowed to send packets from. So that's cool. And basically, I started scanning the internet and I failed completely because, well, I just didn't get any results. And that sucked. But I asked a friend, I asked POCGFO, the guys there, if they want me to write a paper about failed attempts. And they said, yeah, sure. Just make sure everything works as you want and just do the paper properly. And I said, yeah, sure. So I asked a friend to go over it. And he said, have you ever tried to set up a real target that is actually vulnerable and see if you find it? And I said, well, no, I'm a hacker. I'm not doing tests. And he said, well, you should be doing tests. So he


chunk_text:
  that, I think there is the firewall that actually drops packets if you're trying to spoof packets. And if you're spoofing your own external address, there is no problem because the first part, the address translator will not translate anything because the source IP is an external IP. And the second part, the firewall will not drop the packet because it originates from your own IP address, which you're allowed to send packets from. So that's cool. And basically, I started scanning the internet and I failed completely because, well, I just didn't get any results. And that sucked. But I asked a friend, I asked POCGFO, the guys there, if they want me to write a paper about failed attempts. And they said, yeah, sure. Just make sure everything works as you want and just do the paper properly. And I said, yeah, sure. So I asked a friend to go over it. And he said, have you ever tried to set up a real target that is actually vulnerable and see if you find it? And I said, well, no, I'm a hacker. I'm not doing tests. And he said, well, you should be doing tests. So he put up this kind of server. And lo and behold, he didn't find it because I had a horrible bug. So I said, I fixed the bug with the help of this friend. And then I got tons of results. So maybe another lesson is just, even if you're a hacker and you think highly of your code, don't. I'm a terrible code writer. So you should always test your code. And well, before we talk about the findings, let's do a short demo. And I'll show you how this looks like. So pray to the demo code. And okay, we have this. We have this. Okay. This is my, this would be my victim. This is my Google, my VM in Google Cloud. And you can see this is the, it's address. And now let's do some TCP dump. And we're listening on port 5353. And here we're going to send a normal packet, no spoofing, nothing complicated, just a normal packet. Okay. So don't look at my code. Great. That's my password. And we're sending this packet and you can see this packet has arrived safely. That's great. Now let's do some IP spoofing. Okay. So you don't


chunk_text:
  put up this kind of server. And lo and behold, he didn't find it because I had a horrible bug. So I said, I fixed the bug with the help of this friend. And then I got tons of results. So maybe another lesson is just, even if you're a hacker and you think highly of your code, don't. I'm a terrible code writer. So you should always test your code. And well, before we talk about the findings, let's do a short demo. And I'll show you how this looks like. So pray to the demo code. And okay, we have this. We have this. Okay. This is my, this would be my victim. This is my Google, my VM in Google Cloud. And you can see this is the, it's address. And now let's do some TCP dump. And we're listening on port 5353. And here we're going to send a normal packet, no spoofing, nothing complicated, just a normal packet. Okay. So don't look at my code. Great. That's my password. And we're sending this packet and you can see this packet has arrived safely. That's great. Now let's do some IP spoofing. Okay. So you don't see, but I'm going to send a spoof packet and you can see that they stacked Wait, this is not spoofing. Where is spoofing? Sorry. I'm sorry for that. So let's say that I'm spoofing. Oh, wait, it is spoofing. What am I doing? Sorry. It is spoofing. You see the source address is 1234, right? So I'm just trying to spoof source address 1234, which is not my address. Let's send it. And you see that nothing happened as expected because Google just dropped it. Okay. Now we're going to do something nice. We're going to scan the internet from this machine. Okay. So I'm running my own custom ZMap and all these parameters are tuning to make the scan go fast on this specific machine. But you can see that it is running. And if we're checking the results, you can see it's actually finding some IPs. Great. So now let's take all these IPs. All right. And let's put them in this script. That is actually, okay. What this script does is that it's going to use every one of the IPs we just found in the search and ask them to do and send them an


chunk_text:
  see, but I'm going to send a spoof packet and you can see that they stacked Wait, this is not spoofing. Where is spoofing? Sorry. I'm sorry for that. So let's say that I'm spoofing. Oh, wait, it is spoofing. What am I doing? Sorry. It is spoofing. You see the source address is 1234, right? So I'm just trying to spoof source address 1234, which is not my address. Let's send it. And you see that nothing happened as expected because Google just dropped it. Okay. Now we're going to do something nice. We're going to scan the internet from this machine. Okay. So I'm running my own custom ZMap and all these parameters are tuning to make the scan go fast on this specific machine. But you can see that it is running. And if we're checking the results, you can see it's actually finding some IPs. Great. So now let's take all these IPs. All right. And let's put them in this script. That is actually, okay. What this script does is that it's going to use every one of the IPs we just found in the search and ask them to do and send them an IPIP packet that is the spoof packet over IPIP. Okay. So let's do it. And well, we're kind of lucky because as you can see, the 1234 is the source address, which is not our source address. So that was the demo. It works. By the way, this is... Yeah. Sorry. Yeah. So this was in the... Oh, great. This was in the conference network. So yeah. It works from here. You can do it from here. Okay. So findings. So there were about 150,000 hosts that support this protocol. That's nice. That's a lot. I don't think any of them will shut down soon. And most of them can do IP spoofing, as I just showed. So not all of them are vulnerable to IP spoofing. Some of them has filtering, but some of them don't. And I don't really know why. And I can only guess, but my guess is that most of them are kind of deep internet devices that don't have firewall. They're just passing packets around from here to there, and they don't have, or they're their own ISP, or they don't have an ISP. But probably people that understand internet better than I am


chunk_text:
  IPIP packet that is the spoof packet over IPIP. Okay. So let's do it. And well, we're kind of lucky because as you can see, the 1234 is the source address, which is not our source address. So that was the demo. It works. By the way, this is... Yeah. Sorry. Yeah. So this was in the... Oh, great. This was in the conference network. So yeah. It works from here. You can do it from here. Okay. So findings. So there were about 150,000 hosts that support this protocol. That's nice. That's a lot. I don't think any of them will shut down soon. And most of them can do IP spoofing, as I just showed. So not all of them are vulnerable to IP spoofing. Some of them has filtering, but some of them don't. And I don't really know why. And I can only guess, but my guess is that most of them are kind of deep internet devices that don't have firewall. They're just passing packets around from here to there, and they don't have, or they're their own ISP, or they don't have an ISP. But probably people that understand internet better than I am can tell you a bit more about it. Another cool thing we can do, except IP spoofing, which is cool on its own, is spoof private networks. So some of the ranges of addresses of IP are reserved for private networks. So within your Wi-Fi or cafe or something, you'll get addresses that are 192 or 172 or something like this. They are private networks. And maybe you and I will have the same private address on our private networks. And we cannot reach each other over the internet, because the internet should not forward packets that have their source IP being a private address and not internet address. These packets are called Martian packets, because they should not travel the internet. I don't know who came up with the name Martian. But with some of these vulnerable machines, they actually forward internal IP addresses or private IP addresses. I even saw some of them forwarding the 127. So this is localhost. So you can actually spoof localhost. Yeah, that's cool, right? I agree. I couldn't get the packet back to me, because my ISP was actually filtering Martian packets. But what I did, I was forwarding a packet from


chunk_text:
  can tell you a bit more about it. Another cool thing we can do, except IP spoofing, which is cool on its own, is spoof private networks. So some of the ranges of addresses of IP are reserved for private networks. So within your Wi-Fi or cafe or something, you'll get addresses that are 192 or 172 or something like this. They are private networks. And maybe you and I will have the same private address on our private networks. And we cannot reach each other over the internet, because the internet should not forward packets that have their source IP being a private address and not internet address. These packets are called Martian packets, because they should not travel the internet. I don't know who came up with the name Martian. But with some of these vulnerable machines, they actually forward internal IP addresses or private IP addresses. I even saw some of them forwarding the 127. So this is localhost. So you can actually spoof localhost. Yeah, that's cool, right? I agree. I couldn't get the packet back to me, because my ISP was actually filtering Martian packets. But what I did, I was forwarding a packet from a vulnerable IP over IP to a vulnerable machine back to me. And the link in between had a spoofed Martian packet. So this is how I knew they're actually forwarding this stuff. This is the code you can see on your right. Another thing is that sometimes people actually trust their internal private addresses. They don't trust the internet. But 127 is your localhost. So usually you don't authenticate localhost. So there are some attacks that you can actually carry out if you can spoof internal IP addresses. So that's cool. Last thing that was quite cool is that I accidentally found a packet of death. So what happened is that I reported a vulnerability to Cisco. They said they don't have, they don't know of any open IP over IP devices they have. And I said, okay. And then I was talking again to the guys at POC GTFO and told them, hey, I would like to submit a paper, this time a paper that actually does something that works. And as the name implies, POC GTFO requires a POC. So I thought, what would be the coolest POC that they can come up with? And I thought,


chunk_text:
  a vulnerable IP over IP to a vulnerable machine back to me. And the link in between had a spoofed Martian packet. So this is how I knew they're actually forwarding this stuff. This is the code you can see on your right. Another thing is that sometimes people actually trust their internal private addresses. They don't trust the internet. But 127 is your localhost. So usually you don't authenticate localhost. So there are some attacks that you can actually carry out if you can spoof internal IP addresses. So that's cool. Last thing that was quite cool is that I accidentally found a packet of death. So what happened is that I reported a vulnerability to Cisco. They said they don't have, they don't know of any open IP over IP devices they have. And I said, okay. And then I was talking again to the guys at POC GTFO and told them, hey, I would like to submit a paper, this time a paper that actually does something that works. And as the name implies, POC GTFO requires a POC. So I thought, what would be the coolest POC that they can come up with? And I thought, well, I can do IP over IP. Why not over IP over IP and do it recursively? And in this way, I can actually travel the internet more than 255 times, which is for a normal packet. Yeah. For a normal packet, this is the maximum time to leave, right? If a packet travels the internet more than 255 hops, it should be dropped. But if you're having an IP over IP, every layer has its own time to leave. So I actually build this more than 350 layers of pass the parcels game of the internet. And it's cool. And you can do it too. If you want, I'll give you the code that does it. It's a bit, it's not polished, so I didn't feel right to publish it. But if you want, I'll just send it to you, just mail me. And then I got this nice email from the guys at Cisco saying, you know, we do actually have vulnerability and it's not the IP IP thing is that you're crashing our devices. So please stop doing your tests or something. Yeah. I said, I'm sorry. And I stopped, but it was quite funny. So that


chunk_text:
  well, I can do IP over IP. Why not over IP over IP and do it recursively? And in this way, I can actually travel the internet more than 255 times, which is for a normal packet. Yeah. For a normal packet, this is the maximum time to leave, right? If a packet travels the internet more than 255 hops, it should be dropped. But if you're having an IP over IP, every layer has its own time to leave. So I actually build this more than 350 layers of pass the parcels game of the internet. And it's cool. And you can do it too. If you want, I'll give you the code that does it. It's a bit, it's not polished, so I didn't feel right to publish it. But if you want, I'll just send it to you, just mail me. And then I got this nice email from the guys at Cisco saying, you know, we do actually have vulnerability and it's not the IP IP thing is that you're crashing our devices. So please stop doing your tests or something. Yeah. I said, I'm sorry. And I stopped, but it was quite funny. So that were the findings. And now we're going to talk about the disclosure. This is the part you all came here for, right? Yeah. Great. Okay. So disclosure of this kind of vulnerability or it's a misconfiguration. I don't know how you would call it, but it's, it's kind of a hell because all you have to go by is the IP address. And as we know, IP address does not mean, you know, who the owner is or what the device or operating system is. Right. It can be the DMZ. It can be something that only forwards packets to somewhere. And if you're trying to fingerprint it, you're actually fingerprint the machine behind it to which it forwards packets. But the IP of IP happens in layer three, it happens in the kernel. So you don't really know what you're fingerprinting exactly. There was one fax. I didn't put it up just for the joke that there is some Samsung printer that was later bought, but by HP and some university connected it to the internet. And it was actually vulnerable to this. So it exists. And also scanning the entire internet takes time and it's expensive and whatever.


chunk_text:
  were the findings. And now we're going to talk about the disclosure. This is the part you all came here for, right? Yeah. Great. Okay. So disclosure of this kind of vulnerability or it's a misconfiguration. I don't know how you would call it, but it's, it's kind of a hell because all you have to go by is the IP address. And as we know, IP address does not mean, you know, who the owner is or what the device or operating system is. Right. It can be the DMZ. It can be something that only forwards packets to somewhere. And if you're trying to fingerprint it, you're actually fingerprint the machine behind it to which it forwards packets. But the IP of IP happens in layer three, it happens in the kernel. So you don't really know what you're fingerprinting exactly. There was one fax. I didn't put it up just for the joke that there is some Samsung printer that was later bought, but by HP and some university connected it to the internet. And it was actually vulnerable to this. So it exists. And also scanning the entire internet takes time and it's expensive and whatever. So this two guys really helped me, Larry Keshlar, that was working in Akamai security. I reached out and asked for help for someone that, you know, some of the internet stakeholders. So Akamai is an internet stakeholder, I think. And they helped me to scan the entire internet. So the list of 150,000 IP addresses came from Akamai. And they also got me in contact with CIRCC. So this guy Vijay from CIRCC helped me to disclose the vulnerabilities to various companies. And let's talk about how that went. So I started with Diggy because they're the biggest, they have the biggest share of vulnerable machines that they found and could identify. They, I think, about had 10,000 or so machines. They're doing some kind of seller ISP or something like that. Maybe it's not 10,000, maybe it's 1,000. I don't know. I'm messing up the numbers, but they had the biggest share. Okay. And they were very professional in, you know, letting me test the vulnerability on a default configuration and talk to me, but they didn't tell me how the vulnerability came to be. I mean, I guess they ripped off some open source code from somewhere,


chunk_text:
  So this two guys really helped me, Larry Keshlar, that was working in Akamai security. I reached out and asked for help for someone that, you know, some of the internet stakeholders. So Akamai is an internet stakeholder, I think. And they helped me to scan the entire internet. So the list of 150,000 IP addresses came from Akamai. And they also got me in contact with CIRCC. So this guy Vijay from CIRCC helped me to disclose the vulnerabilities to various companies. And let's talk about how that went. So I started with Diggy because they're the biggest, they have the biggest share of vulnerable machines that they found and could identify. They, I think, about had 10,000 or so machines. They're doing some kind of seller ISP or something like that. Maybe it's not 10,000, maybe it's 1,000. I don't know. I'm messing up the numbers, but they had the biggest share. Okay. And they were very professional in, you know, letting me test the vulnerability on a default configuration and talk to me, but they didn't tell me how the vulnerability came to be. I mean, I guess they ripped off some open source code from somewhere, but they didn't tell me from where, maybe some BSD or something. And they promised a bounty, but they had run into some legalese issues and I never heard from them again. So, and they were the best by the way. So next came up Cisco. So I already told you what went down with them. So first they denied they have vulnerability. Of course, they don't have vulnerability. Okay, great. I mean, I only have an IP, so I can't be really sure it's a Cisco device. Right. So I said, okay, whatever. And then when their machine started crashing, they came back and say, you know, we do have a vulnerability. That's cool. But, and then I found out that Cisco does not have a bounty program at all. So that was weird. And I'm not going to make assumptions about Cisco's code quality given this lack of bounty program, but that was it. HP were the worst. They failed to communicate over PGP. They asked me to, they told me that I should ask them for their private PGP key over mail, which kind of defeats the purpose. Exactly, exactly my response. Exactly. Thank you very much.


chunk_text:
  but they didn't tell me from where, maybe some BSD or something. And they promised a bounty, but they had run into some legalese issues and I never heard from them again. So, and they were the best by the way. So next came up Cisco. So I already told you what went down with them. So first they denied they have vulnerability. Of course, they don't have vulnerability. Okay, great. I mean, I only have an IP, so I can't be really sure it's a Cisco device. Right. So I said, okay, whatever. And then when their machine started crashing, they came back and say, you know, we do have a vulnerability. That's cool. But, and then I found out that Cisco does not have a bounty program at all. So that was weird. And I'm not going to make assumptions about Cisco's code quality given this lack of bounty program, but that was it. HP were the worst. They failed to communicate over PGP. They asked me to, they told me that I should ask them for their private PGP key over mail, which kind of defeats the purpose. Exactly, exactly my response. Exactly. Thank you very much. And also they don't have, I think, a bounty program. So that was HP. If there is anyone from HP here in the crowd, I'm sorry, but you should, you should get this work. I want to say something. I think the security teams in all these companies are really good and professional. And I think it's a management problem. So if there is someone from the management that can actually fix that, I mean, they should, but I'm preaching the choir, right? Okay. So last thing was a hacker one. They're actually running bounty programs. I thought that would go much better. Right. And they do have a bounty program called the internet bounty program. And this program was designed for this kind of bugs that affect the entire internet as a whole. And I think this, it kind of applies in my case. So I send them a report after submitting and disclosing and everything. And for a year, nobody read my report. So this didn't work at all. And after a year, they shut down the program. They gave me a few hundred dollars, which was the lowest amount they would pay for a valid submission. And


chunk_text:
  And also they don't have, I think, a bounty program. So that was HP. If there is anyone from HP here in the crowd, I'm sorry, but you should, you should get this work. I want to say something. I think the security teams in all these companies are really good and professional. And I think it's a management problem. So if there is someone from the management that can actually fix that, I mean, they should, but I'm preaching the choir, right? Okay. So last thing was a hacker one. They're actually running bounty programs. I thought that would go much better. Right. And they do have a bounty program called the internet bounty program. And this program was designed for this kind of bugs that affect the entire internet as a whole. And I think this, it kind of applies in my case. So I send them a report after submitting and disclosing and everything. And for a year, nobody read my report. So this didn't work at all. And after a year, they shut down the program. They gave me a few hundred dollars, which was the lowest amount they would pay for a valid submission. And that, that was about it. So my set conclusion from the disclosure procedure process is that it's, it's, it sucks. I mean, if you want to disclose vulnerabilities because you're a good guy or because you want to talk about it afterwards, like I do now or whatever, that's cool. But if you're expecting some bounty or any recognition of any sort, well, good luck with that. Don't, don't base your, your income on bounties. That's a bad idea. Okay. So the last part, what kind of, what the future holds. So I said that I was doing it in my free time and you can do too. I would be happy to share other stuff with you. And the things I would like to do or see other people do with this research is actually set up a full TCP connection into an internal network. So the thing is that I don't know exactly what are these vulnerable machines are. It's really hard to fingerprint them. So if you do know, and you know, there is an internal network behind them, maybe you can try and do some full TCP handshake, like kind of blind TCP handshake, because they're


chunk_text:
  that, that was about it. So my set conclusion from the disclosure procedure process is that it's, it's, it sucks. I mean, if you want to disclose vulnerabilities because you're a good guy or because you want to talk about it afterwards, like I do now or whatever, that's cool. But if you're expecting some bounty or any recognition of any sort, well, good luck with that. Don't, don't base your, your income on bounties. That's a bad idea. Okay. So the last part, what kind of, what the future holds. So I said that I was doing it in my free time and you can do too. I would be happy to share other stuff with you. And the things I would like to do or see other people do with this research is actually set up a full TCP connection into an internal network. So the thing is that I don't know exactly what are these vulnerable machines are. It's really hard to fingerprint them. So if you do know, and you know, there is an internal network behind them, maybe you can try and do some full TCP handshake, like kind of blind TCP handshake, because they're not getting the responses. Right. But if you can make that happen and actually connect to internal services, that would be awesome. Like an awesome POC. And as I mean, this entire thing, this IP spoofing is a stepping stone, right? It's not, it's not the goal itself. It's something that gives you capabilities that would eventually lead you to a successful attack. So on its own, it's not really helpful. And actually setting up or succeeding in setting up a full TCP connection would be another step in the way. And the next thing that could be really nice is actually use the Martian packet spoofing to do some stuff like with the localhost spoofing. That could be really nice. I think the last one that was doing it was a guy, Stefan Woodger, that published a blog post in Project Zero, and he was spoofing IPv6 localhosts back in 2015. And he got, he owned NTPD. So, and ever since I didn't see anyone that was doing it. So now it's possible again, maybe not on your local network, but maybe on the internet. So if you can find some service that is vulnerable to this kind of


chunk_text:
  not getting the responses. Right. But if you can make that happen and actually connect to internal services, that would be awesome. Like an awesome POC. And as I mean, this entire thing, this IP spoofing is a stepping stone, right? It's not, it's not the goal itself. It's something that gives you capabilities that would eventually lead you to a successful attack. So on its own, it's not really helpful. And actually setting up or succeeding in setting up a full TCP connection would be another step in the way. And the next thing that could be really nice is actually use the Martian packet spoofing to do some stuff like with the localhost spoofing. That could be really nice. I think the last one that was doing it was a guy, Stefan Woodger, that published a blog post in Project Zero, and he was spoofing IPv6 localhosts back in 2015. And he got, he owned NTPD. So, and ever since I didn't see anyone that was doing it. So now it's possible again, maybe not on your local network, but maybe on the internet. So if you can find some service that is vulnerable to this kind of thing, that would be cool. Scanning more protocols that can also work very well. I started playing with JRE. There are very promising results over there, and it's not too hard to write a ZMAP module for it. So it remains as an exercise to the audience. And yeah, you can also try to do the 6 over 4 and 4 over 6. 6 over 4 could be easy because you can actually scan the entire IPv4 range. Again, 6 over 4, 4 over 6 can be tricky because scanning the entire IPv6 address range can be a bit too much. But if you know how to do it, that could be very cool. And the last thing is that I never got a hold of a Cisco device that was vulnerable to this packet of death, but basically it's a packet that crashes the kernel from the internet without authentication. So if you do have this kind of device and you want to play with it, and maybe find an RCE into the kernel, unauthenticated, that would be really, really awesome. But I couldn't get my hands on any of these devices. So that's left to everyone who wants


chunk_text:
  thing, that would be cool. Scanning more protocols that can also work very well. I started playing with JRE. There are very promising results over there, and it's not too hard to write a ZMAP module for it. So it remains as an exercise to the audience. And yeah, you can also try to do the 6 over 4 and 4 over 6. 6 over 4 could be easy because you can actually scan the entire IPv4 range. Again, 6 over 4, 4 over 6 can be tricky because scanning the entire IPv6 address range can be a bit too much. But if you know how to do it, that could be very cool. And the last thing is that I never got a hold of a Cisco device that was vulnerable to this packet of death, but basically it's a packet that crashes the kernel from the internet without authentication. So if you do have this kind of device and you want to play with it, and maybe find an RCE into the kernel, unauthenticated, that would be really, really awesome. But I couldn't get my hands on any of these devices. So that's left to everyone who wants to try. Yeah, so that's everything I have. If you have any questions, I'm here now and also in the conference. And if you want to follow me, get the ZMAP module and all that. So this is what I think. And if you want to see more memes like this, you should check out this exploitation on Twitter. So yeah, thank you very much. Yes? Okay, you mentioned you used 1.3.4. I mean, have you tried with example IP networks? Do there are some RCEs that specify IP networks that normally use documentation? No. Which it could have used as well? I mean, I could have used... I did try 8.8.8.8, and it works if you're not spoofing into Google Cloud. Because this is what I did yesterday when I recorded a demo to make sure it works, and it didn't work for an hour, and I didn't understand why. And then I realized I'm trying to spoof 8.8.8.8, which is a Google address inside Google Cloud, and they dropped it. But I didn't try the example IPs. But I did try 100.100, for example, that Tailscale is using. And if you read Tailscale documentation, they tell you that


chunk_text:
  to try. Yeah, so that's everything I have. If you have any questions, I'm here now and also in the conference. And if you want to follow me, get the ZMAP module and all that. So this is what I think. And if you want to see more memes like this, you should check out this exploitation on Twitter. So yeah, thank you very much. Yes? Okay, you mentioned you used 1.3.4. I mean, have you tried with example IP networks? Do there are some RCEs that specify IP networks that normally use documentation? No. Which it could have used as well? I mean, I could have used... I did try 8.8.8.8, and it works if you're not spoofing into Google Cloud. Because this is what I did yesterday when I recorded a demo to make sure it works, and it didn't work for an hour, and I didn't understand why. And then I realized I'm trying to spoof 8.8.8.8, which is a Google address inside Google Cloud, and they dropped it. But I didn't try the example IPs. But I did try 100.100, for example, that Tailscale is using. And if you read Tailscale documentation, they tell you that if you're listening to the Tailscale interface, you should trust incoming packets' source IP because they're validating them. But the fine print is that you should only trust it if it comes from the Tailscale interface. If you're binding to the entire machine, then you may get packets not from the Tailscale network. So this stuff can actually do damage. Yeah. Yes? I'm answering because I think from the SMB archive that you gave me, you just didn't know the source IPs in the design of the 100k from the reality. Yeah, yeah. That's what happens with Google. Yeah, exactly. There's also egress filtering, which is the opposite. That ISPs and cloud providers should not accept packets that should have originated from the internal network if it comes from the external network. As well, they should also not accept Martian packets. But not all providers implement this. Does it also include the nearest BGP networks that it is connected to or not? Do you know that? I didn't check, but go ahead and let me know. Anyone else? Yeah. No, I never managed to do it. I only found those on the internet and they worked. The way I did


chunk_text:
  if you're listening to the Tailscale interface, you should trust incoming packets' source IP because they're validating them. But the fine print is that you should only trust it if it comes from the Tailscale interface. If you're binding to the entire machine, then you may get packets not from the Tailscale network. So this stuff can actually do damage. Yeah. Yes? I'm answering because I think from the SMB archive that you gave me, you just didn't know the source IPs in the design of the 100k from the reality. Yeah, yeah. That's what happens with Google. Yeah, exactly. There's also egress filtering, which is the opposite. That ISPs and cloud providers should not accept packets that should have originated from the internal network if it comes from the external network. As well, they should also not accept Martian packets. But not all providers implement this. Does it also include the nearest BGP networks that it is connected to or not? Do you know that? I didn't check, but go ahead and let me know. Anyone else? Yeah. No, I never managed to do it. I only found those on the internet and they worked. The way I did the testing, I wrote it in basically Scapey. I wrote a Scapey server that would accept any packet, decapsulate it, and send it back. But they could not do it the way you should be doing it with some IP routing stuff of the Linux machine. It's just impossible. I don't know how you guys do it. I mean, not you guys, but they guys. Yes, again. I can also give a hint. If you're trying to report a vulnerability like that and you don't know, you only have an IP address, you can geo-IP it into a country and send it to a national search in the country and hope for the best. It doesn't work usually, but it's better than nothing. Yeah, I tried it with some Chinese vendors and I didn't get a response. Yeah. Okay, yeah, I think that's about it. I'm still here for questions afterwards if you want me. Thank you.


chunk_text:
  the testing, I wrote it in basically Scapey. I wrote a Scapey server that would accept any packet, decapsulate it, and send it back. But they could not do it the way you should be doing it with some IP routing stuff of the Linux machine. It's just impossible. I don't know how you guys do it. I mean, not you guys, but they guys. Yes, again. I can also give a hint. If you're trying to report a vulnerability like that and you don't know, you only have an IP address, you can geo-IP it into a country and send it to a national search in the country and hope for the best. It doesn't work usually, but it's better than nothing. Yeah, I tried it with some Chinese vendors and I didn't get a response. Yeah. Okay, yeah, I think that's about it. I'm still here for questions afterwards if you want me. Thank you.


chunk_text:
  { "webpage_url": "https://www.youtube.com/watch?v=1yIj0h8R9eE", "title": "Pentesting By The Numbers: What Data Analysis Tells About What We Do by Charl Van Der Walt", "description": "", "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA", "duration": 3279, "channel": "scrt.insomnihack", "uploader": "scrt.insomnihack", "upload_date": "20230413" } This text was transcribed using whisper model: large-v2 Good afternoon, everybody, and thank you very much for taking the time to attend my talk. I've titled my presentation, This is Not a Game, and it's about what data tells us about whether or not we're doing our jobs. And by we, in this case, I mean security consultants, penetration testers, vulnerability management specialists. I'm focused on that part of the security problem. I've been thinking about this presentation for a long time, and I'm not actually 100% sure what I want to say, which is a problem since I'm standing up here already. But I thought I'll start with a story that I always like to tell, and it always makes me feel comfortable, and I think it sets a sort of a context. It's a story that comes from Africa. I'm a South African, born and raised. I still live there now. And we're a land of big game. We have lions, elephants, rhinos. We can see them all the time. It's a wonderful part of the experience of living there. And there's a story that goes that in the morning in Africa, when the sun rises, the lioness wakes up, and she knows that she has to run faster than the slowest antelope in order to have a meal and survive. An antelope like the springbok and that thing. So the lion knows she has to run faster than the slowest antelope. The antelope wakes up, and she knows that she has to run faster than the fastest lion in order not to be eaten and to survive. And so the story goes that in Africa, when we wake up, everybody starts running. And I find this a very useful analogy for security. It's what we do. We wake up, and we start running. We're running away from threats. We're running towards compliance. We're running to patch vulnerabilities. In fact, there's a corollary to that story about the cameraman who's photographing the lion in the bush of Africa. And he sees these two cameramen. They see the lion approaching them in a very dangerous way, and they realize they're in trouble. So the one


chunk_text:
  can see them all the time. It's a wonderful part of the experience of living there. And there's a story that goes that in the morning in Africa, when the sun rises, the lioness wakes up, and she knows that she has to run faster than the slowest antelope in order to have a meal and survive. An antelope like the springbok and that thing. So the lion knows she has to run faster than the slowest antelope. The antelope wakes up, and she knows that she has to run faster than the fastest lion in order not to be eaten and to survive. And so the story goes that in Africa, when we wake up, everybody starts running. And I find this a very useful analogy for security. It's what we do. We wake up, and we start running. We're running away from threats. We're running towards compliance. We're running to patch vulnerabilities. In fact, there's a corollary to that story about the cameraman who's photographing the lion in the bush of Africa. And he sees these two cameramen. They see the lion approaching them in a very dangerous way, and they realize they're in trouble. So the one cameraman reaches down, and he takes off his bush boots, and he starts putting on some running shoes. And his colleague says to him, but listen, what are you doing? You can't run away from a lion. It's too fast. And the cameraman says to his friend, no, I don't have to run away from the lion. I only have to run away from you, because the lion's going to eat the slowest runner. And so we have this idea, I believe, in security, that we're sort of running towards something, some level of compliance, some level of benchmarking, some level of best practice. And if we can do it better than the threat actor, or better than our compatriots, then somehow we outrun the threat. The problem is that I don't think it actually works like that. I think it's much more complex. It's much more like running with the bulls in Pamplona. There's not one lion that we have to outstrip, or one other runner that we have to go faster than. And if we look at some of the numbers around something simple like vulnerability management, we very quickly see how overwhelming that problem is. CVEs alone,


chunk_text:
  cameraman reaches down, and he takes off his bush boots, and he starts putting on some running shoes. And his colleague says to him, but listen, what are you doing? You can't run away from a lion. It's too fast. And the cameraman says to his friend, no, I don't have to run away from the lion. I only have to run away from you, because the lion's going to eat the slowest runner. And so we have this idea, I believe, in security, that we're sort of running towards something, some level of compliance, some level of benchmarking, some level of best practice. And if we can do it better than the threat actor, or better than our compatriots, then somehow we outrun the threat. The problem is that I don't think it actually works like that. I think it's much more complex. It's much more like running with the bulls in Pamplona. There's not one lion that we have to outstrip, or one other runner that we have to go faster than. And if we look at some of the numbers around something simple like vulnerability management, we very quickly see how overwhelming that problem is. CVEs alone, around 18,000 new CVEs per year. Our data suggests that on average across all the hosts that we do vulnerability assessment on, there's about 19 unique findings. That's excluding the informationals and all the rubbish. 19 actionable things. The data suggests that firms are only patching between 5 and 10, 20% of known vulnerabilities. And that number gets worse the bigger your organization gets. So you would think big organizations with more maturity are better at managing their vulnerabilities, but in fact the opposite seems to be true. The number of vulnerabilities per host seems to go up. And we believe that only around 5%, between 2 and 7% of those 18,000 vulnerabilities will ever be exploited in the wild. So we can't chase down all these vulnerabilities, just like we can't run away from all the bulls in Pamplona. And the question then is, how do we choose which of these vulnerabilities we're going to chase? How do we put our time and effort into running away from the right thing? And I think, and I've used these two icons which you'll see coming up again and again, the vulnerability scanning, vulnerability assessment functions, and the penetration testing functions,


chunk_text:
  around 18,000 new CVEs per year. Our data suggests that on average across all the hosts that we do vulnerability assessment on, there's about 19 unique findings. That's excluding the informationals and all the rubbish. 19 actionable things. The data suggests that firms are only patching between 5 and 10, 20% of known vulnerabilities. And that number gets worse the bigger your organization gets. So you would think big organizations with more maturity are better at managing their vulnerabilities, but in fact the opposite seems to be true. The number of vulnerabilities per host seems to go up. And we believe that only around 5%, between 2 and 7% of those 18,000 vulnerabilities will ever be exploited in the wild. So we can't chase down all these vulnerabilities, just like we can't run away from all the bulls in Pamplona. And the question then is, how do we choose which of these vulnerabilities we're going to chase? How do we put our time and effort into running away from the right thing? And I think, and I've used these two icons which you'll see coming up again and again, the vulnerability scanning, vulnerability assessment functions, and the penetration testing functions, red teaming functions, have in their mission the responsibility to inform the business and inform IT, which of these things should we be running away from, right? But that's not actually a very simple thing to decide. And then I had this experience last year when I was looking at some of the data that we produce. I'm from Orange Cyber Defense, I'll tell you about myself in a moment. But I looked at three different data sets. The first was I looked at something called Bullwatch. It's a security advisory service that we publish. We have very clever people working 24-7, and they send out these notices to our clients to say, this is what you should be running away from today. And of course, the big thing we were running away from last year was log4j, right? Everyone's running away from log4j. In fact, we mentioned it in eight different advisories, right? We spoke about it a lot. Then I looked to see what are we actually seeing when we scan our customer estates. And in fact, we do see log4j, but we only saw it on six hosts. Incidentally, out of 41,000, right? So it is a


chunk_text:
  red teaming functions, have in their mission the responsibility to inform the business and inform IT, which of these things should we be running away from, right? But that's not actually a very simple thing to decide. And then I had this experience last year when I was looking at some of the data that we produce. I'm from Orange Cyber Defense, I'll tell you about myself in a moment. But I looked at three different data sets. The first was I looked at something called Bullwatch. It's a security advisory service that we publish. We have very clever people working 24-7, and they send out these notices to our clients to say, this is what you should be running away from today. And of course, the big thing we were running away from last year was log4j, right? Everyone's running away from log4j. In fact, we mentioned it in eight different advisories, right? We spoke about it a lot. Then I looked to see what are we actually seeing when we scan our customer estates. And in fact, we do see log4j, but we only saw it on six hosts. Incidentally, out of 41,000, right? So it is a big problem, but it actually has a small reach. Then I looked to see what our penetration testers are actually exploiting in the wild. Not in the wild, penetration testers. And actually, we only exploited that vulnerability once. And it made me very curious about this idea of what we're being told we should run away from compared to what we're really advising, sorry, what we really should be running away from, you know, where the line really is, compared to what we're telling our clients they should be concerned about, particularly through these scanning and penetration testing services. And that reminded me, oops, this doesn't actually work. That reminded me of a presentation from 2011, 44Con in London, by a guy called Harun Mir. Some of you may know him as an old friend of mine. We love each other very much. We also argue very much. And Harun did this presentation saying, penetration testing is considered harmful. We're actually doing ourselves a disservice. I recommend that you have a look at it. It's a very interesting topic, and I wish I could comment more. I disagreed with him, of course, on a lot of things. I was a


