# Media

url: https://www.youtube.com/watch?v=vBpUaIPUOHY
title: How To Crack Seven Billion Passwords? - Jeroen Van Beek
type: video
author: OrangeCon
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=vBpUaIPUOHY",
    "title": "How To Crack Seven Billion Passwords? - Jeroen Van Beek",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1863,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Thank you. My name is Jeroen van Beek. This is a summary of my professional history. Not  that important right now. This is Taylor Swift. She was recently in the news, linked to an  IT security incident. What happened? Someone else? No one? There's a hint on the screen.  Taylor Swift ticketing is handled by Ticketmaster. Ticketmaster is a huge company. Ticketmaster  uses a number of IT providers. One of them is Snowflake. And Snowflake got hacked. There  are some reports out there covering the incident response from Maniant. And there are a couple  of interesting findings. One of them is that there was no mandatory multi-factor authentication  for administrators. And at least about 80% of the accounts leveraged by the attackers  were already known. And were already exposed before the breach. So it's a classic example  of credential stuffing. And not taking even basic measures. And as a result of that, with  a username and a password, you could breach the account data of over half a billion of  people. So this is a really huge leak. It's not only Ticketmaster. There are over a hundred  other companies affected. But probably the threat actors will continue exploiting those  in the coming couple of weeks or months. Another one. Uber. There are a lot of incidents  with Uber involved. This one is about a settlement for $148 million. And it was IT security related  as well. Anyone? What happened? No one? Uber uses GitHub for source code storage. Again,  there was no mandatory multi-factor authentication. In this case for the developers. And the developer  reused their passwords. So they used the password for other services as well. And one of those  other services, or at least one of those other services, got hacked as well. The password  of the developer was cracked. The threat actor figured out that it also worked on Uber's  GitHub and got access to their Uber GitHub. And looked into the source code. One of the  things he or she found were storage credentials from AWS S3 bucket. And with that, they could  recover almost 60 million Uber user account details and 600,000 driver data files. Bonus.  Uber did not report this and paid the hackers $100,000 to keep quiet.  Again, classic example of credential stuffing. You only need to use a name and a password  and the impact is enormous. So you might ask yourself, are account takeovers the new zero  days? If I look back in my experience as over 20 years professional pen tester, it all started  mainly with exploiting operating system issues. So the Windows and Solaris flaws. Later on,  there were software flaws, backup agents, databases, those type of things. Followed  by application code flaws like SQL injection. But nowadays, if the basics are covered by  a company, typically in my experience, the easiest way in is account takeover. I'm not  the only one saying this. For example, Verizon publishes an interesting report on a yearly  basis and they say credential abuse is the big thing to focus on.  One of the reasons, I think they say this, is that we see a trend. And the trend is that  there's a huge increase in the amount of available breach data and there's a huge decrease in  the cost and the complexity for an attacker. So a smart teenager can do this and can do  this successfully. So what do cyber criminals do? The most important part is the input.  So they got breach data from websites and from hacked computers. On the other end, we  got the output and that's money. So with extortion or ransomware or stealing money directly,  the criminals will get your money. Well, what do we do at Scattered Secrets? We provide  some services in two categories. One is we provide companies with the breached credentials  of their company, the domains that the company owns. And the other ones is we add an extra  password control. Probably we all know those controls. So you check for a password that's  8 long, 10 long. And some complexity is applied to the passwords, uppercase, lowercase, letters,  numbers, et cetera. We provide an additional check and that is the password reused. And  if it is reused, you should not use it. Well, if you want to run a service like that, you  need a large quality data data set. And the question might be how to get it. Well, first  of all, you need raw data, a lot of raw data. That might sound difficult, but actually it's  really, really easy. Perhaps some people are familiar with this website, Breach Forums.  There are a couple of them, or actually quite a lot of them. It's not dark web. It's not  expensive. You can download a lot of data. This is sorted by the number of accounts.  You see 800 million accounts. You can download it in most cases for free. If you're in a  hurry, if you pay one or two euros per data set, you're good. So it's really cheap and  really easy to get a lot of data. Nowadays, the more interesting channels are file sharing  services and Telegram, especially the Telegram channels. There's a lot of data over there.  If you got the raw data, you need to extract credentials. So in our case, we extract the  emails and the password hashes. And if you did that, you're at step three. That's the  most interesting one. You can do some analysis and cracking, actually enriching the data  and getting valuable information out of the raw data. But what kind of data will you see  if you collect and extract data from data breaches? First of all, started in the early  60s, we had plain passwords in the first time sharing machines. We understand now that that's  not a good idea because if someone breaches your password file, all passwords are breached  instantly. But plain storage is still used nowadays. So I think on average, we still  see one or two raw files containing plain password storage. Don't ask me why, but it's  still used. There are a couple of simple fixes or not fixes. One was obfuscation. The second  one was the introduction of Descript back in 1974, which improved the situation.  Other types of hashes you see are basic hashes. So for example, the MD and SHA family, MD4,  MD5, SHA1, SHA2. They were introduced in the early 90s, but there are some issues. One  of the issues is that the same password will result in the same hash. So you can create  a big lookup table. So if you can get your hands on a hash, you can just look up what  the password is. And then the second thing is dedicated password cracking was introduced.  It sounds pretty normal now, but at some point in time, there were no dedicated password  crackers. Familiar ones for some people are Crack and Jack, 1991-93. One that's probably  still very familiar for most people is John the Ripper, introduced in 1996 and still actively  is supported nowadays. Well, what was the fix? The fix was salting. So you're not storing  the hash, but you're storing the salt and salted hash. And the result is if you got,  for example, a thousand times more hashes, it takes a thousand times more computing power  to achieve the same result. So that might sound good. But it's not that good. Again,  some issues. It introduces herd immunity only. So if you got a thousand or ten thousand or  a million accounts, it works. But it doesn't help against targeted attacks. So if you want  to crack a single salted account, it's just as fast as it previously was. So it's good  for protecting your whole population, but it's not that good for protecting one or two  admin accounts. Then we got Moore's Law. Moore's Law, there are different interpretations.  But in this case, I mean that back in the days, the CPU power doubled about every two  years because we were cracking on CPUs back in the days. And the algorithms are unchanged.  So after two years, twice as much computing power. After four years, four times as much  computing power. But the algorithms are unchanged. So the security level of the algorithm goes  down over time. So it becomes easier to crack passwords. Again, there was a fix. In this  case, key stretching. That's what I call it. And what it basically means is that you run  multiple rounds of an algorithm. The most well-known one still used today in some cases  is MD5 script. Might sound familiar to at least some of you. Introduced in 1994. And  what they do, they just run 1,000 MD5s, which is about 1,000 times slower. Later versions  include SHA family of script. So we got still, we see SHA 512 script a lot in operating system  security, etc. This worked pretty well for a long time. But again, there were some new  issues introduced. Especially the general purpose programming platforms for general  processing units for GPUs, video cards. So the video cards were out there already for  a long time. But with the introduction of the platforms with CLI code, it was, you were  able to unleash the power, the raw computing power of a GPU. That meant back in the days  that the speed up was about 50 to 100 times for most algorithms. So that's a lot. Like  two orders of magnitude if you're lucky. Then Moore's law, of course, still works and  also works for GPUs. So we got the same issue all over again. The algorithms are unchanged.  So it becomes easier to crack passwords that are protected with key stretching over time.  The new fix, and actually the first really good fix, we saw that in 1999 with introduction  of bcrypt. And unlike the previous algorithms that are general purpose hashing algorithms,  bcrypt is the first well-known password hashing algorithm. So it's designed with a couple  of design criteria. One is to be configurable. So you can configure the number of iterations.  And another very important one is that there are some hardware limitations built in. So  it's slow on specific hardware. Back in the days, 25 years ago, GPUs were not a thing  for password cracking. But even today in 2024, bcrypt is a really crappy algorithm to crack  on your GPU because it takes more memory than is available, fast memory on your GPU. So  with a very good design, it's still GPU resistant 25 years later. So this was a very, very big  step back in the days. And bcrypt, obviously, if you're a developer, is still a well-known  algorithm and is used a lot. Again, history repeated itself. New technology  was used for password cracking, in this case FPGAs. So there's a limitation for cracking,  for example, bcrypt, but you can overcome the limitation to make a hardware device that's  specifically tailored for cracking, in this case, bcrypt hashes. Support is pretty new.  It was introduced in John the Ripper in 2019 for a very specific type of FPGA and for a  limited number of algorithms. When it was introduced, the speed-up was again 50 to 100  times based on the hardware you were using. So that's, again, a lot. Furthermore, Moore's  Law is still working for this technology and for earlier technology, and especially for  GPUs, this is pretty interesting because cracking speed for GPUs is now low, for example, for  bcrypt, or relatively low, but we're at the point that the tech will overcome the hardware  limitations. So somewhere in the near future, probably the hardware limitations will not  work for the latest generation of GPUs, and you can crack at full speed.  The latest fix, current fix, is the introduction of fully configurable algorithms, sCrypt and  Argon2. If you're a developer, that's one of the two you want to use. And besides the  configurable number of iterations, there's also configurable resource usage. So let's  say a new tech platform pops up tomorrow with specific characteristics, you change the parameters  of your sCrypt or Argon2 algorithm to be just a little bit more, drastically slowing down  the cracking power of the new platform. So this is good, and this will probably be there  for the next couple of decades at least.  Besides that, you need effective and efficient cracking. Password cracking is an exponential  problem, and to give you an idea about what it looks like, if you want to brute force  10 million hashes, and you've got basic hashes like MD5 or SHA-1, SHA-2, you can crack about  brute force 8 to 9 length. So that's pretty good. Probably you will find most or at least  a lot of passwords. If it's salted, so still old stuff, but salted for 10 million hashes,  you can only crack brute force length of 5, which is not a lot. So 1, 2, 3, 4, 5, 6, if  you try to crack it brute force, you won't find it. If it's keystretch as well, you can  only brute force 3 to 4, and if it's a good algorithm, so bcrypt or later, then it's 1  to 2. So that means that's about 100 to 10,000 passwords. So if you want to try the password  top 100, it will take you months or years. So it's pretty good protection if you want  to attack the herd. You might think, well, I buy some extra computing power and I'm good.  Well, that's not the way it works for an exponential problem. If you want n extra length, you need  100 times to the power of n more computing power. So if you want to increase this number  from 5 to 6, you need 100 times more computers. If you want to increase it from 5 to 7, you  need 10,000 more computers. So that's not working. It's not a practical solution. So  you need to think different, and thinking different means, in our case, using tricks,  using the best platforms for a very specific job, and perform data analysis to increase  your cracking efficiency over time. This is an example of a trick. This is a trick on  the data from Ashley Madison. It's a US-based dating company that was breached a number  of years ago, and they upgraded from MD5 to bcrypt with the work factor 12. So that's  from extremely fast for an attacker to extremely slow. What you can do, if you're lucky, the  application code is also leaked. That was the case here. And the database still uses  some algorithms based on MD5, so for upgrade parts and also for reset procedures. If you  lost your password, that was not a bcrypt password, or at least not the token that was  used, but it was still MD5-based. So what you can do is you crack the legacy fast hashes  first with 8-character brute force, for example, and you use the results as a dictionary to  crack the slow results, and that's, of course, a dictionary with a very high hit rate, a  hit rate near 100%. What's the result? Great success. The attack speeds up with about 100  billion times. So that's testing 100 passwords in months. That was the case. If you didn't  use this trick, if you're using this trick, you can try to brute force passwords up to  8 or 9 characters. So buying hardware doesn't work. Using smart tricks does. Then you should  choose the best cracking platform. Typically, that's a GPU, but if you've got a huge dataset  or if you're using very complex rules, GPUs haven't got enough memory, so the attacks  cannot run in a single run. It takes way more time, and in that case, it might be beneficial  to use a CPU. If this is the case, you can simply calculate this in your spreadsheet  program, but if this is the case, use high core count CPUs with AVX-12, extend the factor  extensions, and you're pretty good. If you've got hashes with hardware-specific slowdowns,  use FPGAs, but there's an issue. You cannot buy them. There are no off-the-shelf FPGAs  crackers, and the amount of hardware models that support it is very limited, but it is  the fastest way. You get more speed for less power, which is good. So that's what we did.  This is one example. This is the actual advertisement picture from eBay from the first batch we  bought. So I don't know why he's got a hat and sunglasses, but that's the way the guy  used the devices for Bitcoin mining, because they were very popular for Bitcoin mining  at the time, and what we do, we build them in rack mount services with proper cooling,  proper power supplies, et cetera, so they can run 24-7 at the max speed to crack a lot  of unique content. So what are the results and observations? We recovered over 7 billion  email and password pairs, so in my opinion, that's quite a lot. Typically, we see one  or two million new passwords a day come in. There's a lot of fake password news out there  and disinformation. I've got some examples later. And within a typical organization,  if you've got more than, let's say, 1,000 accounts, you're in, and so if you're the  attacker, I'm a pentester, professional pentester as well, if you've got more than 1,000 accounts,  there's always at least one person that's reusing passwords and allows you to get in  and get some foothold and getting the party started. At scale, so at scale, I mean millions  of accounts, for example, clients with millions of customer accounts, we can typically breach  about in between 5% and 15% of the accounts that are enrolled. So again, that's up to  you, but in my opinion, that's quite a lot. Very interesting, typically, a typical company  doesn't have effective protection against credential stuffing at all. Then, all passwords  together. So I guess most people are familiar with the LinkedIn breach from 2012. Typically,  people say, ah, but it's very old. It's not relevant anymore, and old data, old passwords.  True, but we still recover new passwords in 2024 from the LinkedIn breach. Not a lot,  but still tens of thousands each month. And typically, those are not the password 01s  and the welcome 01s, but those are the really complex passwords. And the complex of the  database, the higher the chance that it's still used by people nowadays still in 2024.  More examples included later as well. Then the grass is greener on the other side,  so if you got even basic measures in place, that will help. So cyber criminals, they typically  perform some test runs, and if it doesn't look that good, if they cannot breach any  code, well, go to your competitor and try to credential stuff your competitor. Well,  that's good. Mission accomplished. So even basic measures will help you.  An interesting one we saw at the pen test of the client, a good password policy can  actually work counterproductive. So this client used 12-character, 12-length password policy  with all kinds of fancy things you don't see at most organizations. Credential stuffing  was successful, and the client was surprised. So they asked us, hey, can you show what data  did you use, and why did it work? Because we got a really good password policy.  Well, in the end, it's very simple. The number of candidates that were leaked goes down,  because you already know for sure that 1, 2, 3, 4, 5, 6 will not work. It's not long  enough. So the number goes down, but the quality of the candidates that are remaining goes  drastically up. So you end up with a more efficient and more stealthier attack. So this  is a bit counterintuitive, but this is the way it seems to work in real life.  Now, some fake news. Who's a hookers.nl user? We see one. If you're not familiar, for our  other folks that are not familiar with hookers.nl, it's a website where you can review sex workers.  So if you're a regular customer, then you can say, hey, well, this lady or this guy  is really good, or don't go there. They got hacked, and a lot of people were worried.  So there was a statement from the operators from the website, and they said, well, no  passwords stolen. There were no passwords stolen, so nothing's going on.  We already had the data for quite some time, so we saw that it was not true, and we were  actually doing some burning tests for some new hardware, and in a long weekend, we cracked  57% of the passwords. So I think it's good not to trust a victim. Typically, victims,  they might have a different agenda, which is the case in many documented cases we've  seen before. Then, typically, there's no basic protection.  So if you're hacked because of missing basic cyber hygiene, you can just say, well, it  was a very sophisticated attack. We've never seen this before, or it was a state-sponsored  threat actor. Typically, no critical questions are asked, and not even by the media, and  typically, it's not true. So in reality, if you've got a school kid  with five euros or five dollars, they can buy billions of accounts on the forum, or  they can get it for free on the Telegram channels, and if they've got a gaming PC, they can launch  a successful attack. So if you're familiar with PC gaming, and  you know Call of Duty, for example, and the rule of thumb is if you can run Call of Duty,  you can brute force an eight-position hash within a day. So that's the amount of computing  power that's available to school kids nowadays. Then, what we see, that incident response  sometimes at clients, is that sometimes the guys get caught, and they are actually teenagers  doing this. After the Snowflake breach, and the fact that  the Taylor Swift tickets, we looked up our data on Snowflake, this is part of it, and  you need to trust me if I tell you that redacting the data took more time than looking the data  up. It's a lot. So this is the dashboard for Snowflake users.  So these are actual enrolled production environments that are used by Snowflake users within the  second column, the username, and the third column, their passwords.  I'm always surprised, so I got a little quiz question. I'm always surprised by the eagle  eye view of some of the attendees. What do you see? Do you see something out of the ordinary  in the password column? Sorry? Yeah? But that's not what I'm looking for?  Very good. So one of the passwords, and this was actually  internal Snowflake accounts, so this was operated by Snowflake themselves, Snowflake 23, explanation  mark. So not even the basic password controls were in place at the time of that company.  And this was data we had six or nine months before the actual breach.  Then the last item, all passwords matter. We were contacted by a tech journalist who  wrote a book about passwords, and he was promoting his book at Ava Yenix talk show, and he contacted  us. He said, hey, can you crack some passwords from Ava? That would be fun.  Sure, so that's what we did. So we cracked 2012 Dropbox password, so again, very old  password, same age as the LinkedIn breach. And it was still used by Ava for all her passwords  for all important services. So it was a live show, and actually the journalist  had to help her change all her passwords before going live, because they were afraid that  otherwise things went wrong. So probably you guys, you changed your passwords,  you got quality passwords, et cetera, but most normal people, they reuse passwords.  That's the way it works in real life. All passwords can also help you to follow  a person over time, because historical passwords can help you to unravel the mechanism that  a lot of people are using for creating passwords. So if you got 10, and they use some kind of  mechanism that you can understand, then probably you can guess number 11 and number 12.  So that's a very useful resource for guessing future passwords.  The other thing is that you can find personal accounts based on professional accounts and  the other way around. So if the password is quite unique, that allows you to search on  a password and find other email addresses. Well, it's always fun to do that with politicians,  at least that's what I think. Most politicians use really crappy passwords,  like most other people, but some of them use high quality passwords, that high quality,  that they're unique worldwide. So we only see that password 10 times in 7 billion passwords  that we've breached. Using this, you can identify their personal accounts.  So let's say this is John Doe at this official government agency. You also find John Dee  at Gmail, Jay Doe at Hotmail, and some burner addresses. The interesting thing is you can  use those addresses again to look if they were used in other data breaches and see what  the folks were doing with their personal accounts. Well, one of them was a member of the House  of Parliament, or an ex-member of the House of Parliament. And another quiz question,  what did we find? Really close, really close.  Which obviously makes it possible for damaging the reputation, that's one, but might also  be used, for example, for blackmailing. So it's very easy to make a mistake. The internet  will never forget. And if you get more and more data, and more and more computing power,  it's really difficult to stay on the radar. That's it for now. I don't know if we've got  time for questions, but for sure you can check if your accounts were breached at our website.  We've got free community accounts. And if you've got questions later on, please find  me somewhere at orange.com. Or have we got time for one question? I don't know.  Yeah, I think we have time for one question.  What are the legal implications of keeping the found password data online, and doing  the hashing stuff?  Well, I'm not a legal guy, but obviously we consulted some pro-legal guys, and they tell  us that it shouldn't be a problem, because there are some exceptions in GDPR. And one  of the exceptions is protecting your, I don't know what the exact words are, but protecting  computer networks and automated systems. That's one. The other thing, if you look at the cyber  crime laws, they say it's an issue if you publish non-public data. But this is debatable.  But this is my statement. This is public data.  Well, and with that, I would like to ask you all for a huge round of applause for Jeroen  van Beek.


url: https://www.youtube.com/watch?v=Ev3GeR-oRNk
title: Graph API Mastery: Logs To Real World Attacks - Shiva P & Parthiban R
type: video
author: OrangeCon
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=Ev3GeR-oRNk",
    "title": "Graph API Mastery: Logs To Real World Attacks - Shiva P & Parthiban R",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1796,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Thanks everyone for willing to spend the next 30 minutes with us on our talk.  Today we wanted to talk to you about a newly introduced log source from Microsoft, which  is Microsoft Graph API Activity Logs.  The goal of the presentation is to make sure that you get familiarized with the log source  and then so that you can go on and perform threat hunting using the Graph API Activity  Logs.  So there's a little bit about us.  So I'm Parthivan.  I've been in the security for over 10 years now, currently working as a Senior Intelligence  Analyst at Atlassian.  I previously worked with my friend Shiva for the past at Symantec and Microsoft as an anomaly.  And outside of work, food is something that I really enjoy and my friends.  And yeah, hi, I'm Shiva.  So I also have like around 10 years of experience in security.  Right now I work for Dart and I'm a Senior Security Researcher, previously worked in  Symantec and Anaplan as well.  And I've been around multiple different security roles.  And yeah, outside of cybersecurity, it's more of gaming.  Cool.  So in today's agenda, I wanted to go through a little bit of fundamentals about what is  a Microsoft Graph API and how to get these logs as it's brand new.  And I wanted to go over through a couple of key fields which you can make use of during  your threat hunting or investigation and also how you can effectively utilize Graph API  logs with other data sources.  And then we'll also go through a couple of KQL functions that you might be, you might  find it useful during investigation.  And then my friend Shiva will walk you through a couple of real world attack scenarios that  he worked during his time at Dart.  And then he'll finish off the session with how to perform baselining and auditing in  Graph API logs.  So what is a Graph API?  Graph API is not something brand new.  It's been around for a while now, but the logging is something that was enabled recently.  So using Graph API, one can interact with a wide variety of M365 services, which means  you can use a single endpoint to access applications such as OneNote, OneDrive, Calendar.  There are so many endless applications that you can do.  A simple example would be you can use the API to get the latest emails from your Outlook  or you can also use it to list all your files in OneDrive.  So due to the extensive features and ease of use, in the wrong hands, it can be abused  by threat actors to perform malicious activities.  So as a defender, we should be in a position to detect and respond to threats that are  happening using Graph API.  So this screenshot is just a simple example of what you can do with the Graph API.  This is a web application from Microsoft.  You can just go to akms.ge that will take you to this page.  You can try to explore what different endpoints that you can query and what type of data that  it will get back to you.  So if you look on the left side, you can see you can get the user profile.  Similarly you can also get, if you have enough permissions, you can also get information  about other users that can be used for enumeration.  Similarly you can also get your emails, like I mentioned, your items from your OneDrive.  You can schedule calendar appointments, et cetera, lots of applications.  Before we move on to how to get these logs, I want to give you another couple of basics  on how authentication and permission schemes work in Graph API.  In order to access the Graph API, one needs to have an application that needs to be registered  in your Azure portal, and that's one of the fundamentals.  And then the authentication is done using OAuth protocol, which means you need to be  having a client ID and access token to access the API.  So once you have these two done, the next step is to assign permissions to your applications.  So in the Graph API world, there are two permission schemes.  The first one is delegated access.  In this delegated access mode, the user needs to be present and signed in.  So let's say if the user is trying to access the latest emails from there using an application,  there will be a sign-in pop-up that will ask them to sign in to access the resource.  And in terms of app-only access, it will basically act as its own.  So you can consider it as a bot that performs activity in the backend using the permissions  that are assigned at the time of creation.  So this diagram will summarize how the two different permission schemes work.  So in terms of delegated access, when someone is trying to access the resource, the resource,  let's say in this case, similarly, we can have OneDrive.  So the OneDrive resource will ask a couple of questions to the application.  The first one is, is the user authorized to perform this activity?  If it's yes, then the next question would be, is the app authorized to perform this  activity on behalf of the user?  So if both conditions met, then the application will be able to access the contents from the  OneDrive.  In terms of app-only access, the only question that will be asked by the resource is, is  the app authorized to perform this activity?  Then if the admin has given consent to this application, then the app can access the resource.  Now we'll move on to how to get these logs.  Firstly, the Graph API activity logs are not collected by default.  So you need to enable them, so your administrator need to enable them to collect these logs.  The second point here is, the logs are only available to EntroID P1 or P2 license holders.  Any other license, you wouldn't be able to get access to these logs.  And another important thing here is, before you start collecting these logs, you need  to perform a cost estimation of how much this is going to cost you, because if you have  a larger cloud presence and having lots and lots of assets, then you'd be racking up  so much bill.  So please be mindful about before enabling these logs.  And to collect these logs, you can simply go to the Azure portal and then go to EntroID.  And under the EntroID, you will have the diagnostic settings, and like the one in the screenshot  right side, you can see under the diagnostic settings, there will be a number of different  log sources.  Under that, you can enable the Graph API activity logs.  And then once you enable it, you can either send it, you can send it to your preferred  data lake, or you can send it to, in this case, we are sending the logs to Log Analytics  in Azure.  And now, once you have these logs, the next step is to understand what fields are present  in the logs.  Here are some of the key fields that are present in the API logs.  The first important field is the application ID.  So this is a unique identifier used for applications, so this is going to act as a central pivot  point during your investigation.  And then the IP address is your source IP address.  And then the request method is another important field here, because that's how you will know  what type of activity is happening.  So for example, if it's a GET request, the app is trying to get data from there, so you  can assume it as in some sort of enumeration activity in terms of malicious stuff.  So let's say the app can list all the items from your OneDrive, so that's an enumeration.  So in terms of post activity, that's basically your app is trying to interact with the resource,  so you can consider it as something like an app is trying to send an email.  So in this case, your data will be sent to the resource, so it's a post request.  And similarly, the response status code is important, so that's how you will be able  to differentiate whether this particular activity was successful or not.  If it's 200 series, then it's a successful activity, and if it's 400, then there's some  sort of error happening.  And finally, the request URI, another important field, because that's how you will be able  to know which endpoint the app is trying to hit.  So let's say if the endpoint is trying to query items from OneDrive, then you would  be able to see the corresponding endpoint in the request URI.  So that's how you'll be able to perform investigation on what activities are happening.  And we'll also walk you through a couple of useful tips.  So on its own, Graph API logs, it's useful, but when you combine it with other data sources,  you will have more context, so that will be super helpful during investigation.  So the first one is, there is a user ID field in Graph API, but that's just a unique identifier  that won't give you any extra context.  So if you join it with the identity info table, you can get other context around email  address, names, SPNs, etc.  So those will be super helpful.  And similarly, you can also combine it with the Active Directory RISC user, that will  provide further context around what type of RISC is associated with the user ID.  That might help you to type of RISC, like logging in from a different location, suddenly  those sort of extra information you'll be able to find.  There's another table called Cloud App Event Logs that can be used when you're, let's say,  you're trying to investigate an activity where the user is trying to download a list of files,  but in the Graph API logs, you'll only see the file identifier, but you won't be able  to see what's the file name.  So if you combine it with the Cloud App Event Logs, you'll be able to get that as well.  So that's super helpful.  And a couple of useful KQL functions.  The first one is parse URL.  So if you parse the request URI, the field that we just talked about, the function will  parse the URL into multiple fields.  So it will split the URL into domain, subdomain, ports, and it also has the ability to extract  the parameters that you're passing in the API.  So that will be super helpful to differentiate what type of activities are happening.  And finally, the Geo IP information.  So it's self-explanatory.  If you parse the source IP address information in there, that will help you to get context  around geolocation information, such as city, country information, like that.  Now I'm going to pass the mic to my friend Shiva, who's going to walk you through real-world  attack scenarios.  Yep.  Thanks, Parthiban.  So before we jump into the real-world attack scenario, I just wanted to tell you that all  of these scenarios that we're going to see here, it's basically derived from the engagements  that we've had in Dart.  Dart basically provides instant response as a service to multiple external customers.  With that being said, though, all the screenshots that you're going to see here, it's completely  a recreated attack from our own test environment, so which means you will not see any sort of  customer data anywhere in any of the screenshots.  So with the disclaimer out, let's jump in.  Basically, we've split the attack scenarios into miter matrix so that it's pretty clear  for you to understand what's really happening here.  And yeah, also the queries here, it's basically an excerpt from the actual queries.  We wanted to sort of save the real estate of these slides.  So if you want basically the queries, we've added a QR code at the very end of the slide,  so feel free to use that, and you'll be directed to an article which has all the queries that  is presented here.  Yep, so this is one of the most seen tactics.  We've observed it in all of our, of course, all of the IR engagements.  So actors love gathering data.  They love elevating privileges.  They love trying to figure out where they are and where they want to go.  So one of the things that we did here is that, to get this query, is basically we took a  look into all of the engagements that we've been on.  We've isolated all sort of reconnaissance that's happened using Graph API.  We pulled all the APIs, which is related to reconnaissance, and along with that, we also  took a look into all the different tools that is available in the market.  Shout out to Graphrunner and Azure Hound.  They use Graph API to do a lot of reconnaissance.  So we used all of these to basically come up with a list of, a dynamic list basically,  to add all the API endpoints.  And basically using that, we've also added a response, I wish I had a laser, but we also  added a response status code here, which is equal to 200, which means it's a successful  response.  And along with that, what we did was we grouped the whole thing into a time bin of two minutes,  and we are then looking for sort of a burst activity, which means if there's going to  be reconnaissance, it's going to be happening in a short span of time.  So it is going to be like 100 seconds for this query alone.  And finally, what we did was we are counting three or more unique calls, and total call  of around 40 or more, or if the total calls is more than 100, then this is going to create  a hit.  And again, this is more of completely based on the test scenarios that we did based on  our tenants, which means you will have to adjust your filter attributes for your own  tenants for your environment.  And of course, since Microsoft Graph API is constantly evolving, you might need to add  other endpoints or calls that is made to the dynamic list.  Oh, there's another scenario where we notice a service principle of an application that  was compromised.  So basically, this application had this role management or read, write, dot directory role.  So what this role basically does is it gives this application an ability to assign any  sort of role to any sort of user.  That is exactly what it does.  And in this scenario, or in the attack that we noticed as part of the Dart engagement,  basically, the actor provided multiple different users with multiple different roles to of  course, proceed with their action on objectives.  And we recreated, of course, this scenario.  You will see on the right, there is like multiple screenshots.  The first screenshot, you see the account name hacker, they have not assigned any sort  of roles there.  And post which, what we did was we abused this Graph API application, and we provided  global administrator, which is on the second screenshot.  And this is basically how the logs would look like.  You would see IP, I mean, what is important here is the IP address, the request URI, the  response status codes, and user agent and app IDs.  So using this log and all other logs that we found in the research, we were able to  come up with something of a simple query, where you look into the, where it figures  this request, the request made is equal to post, and for the response code is 204, you  would find a hit.  One of the things that you have to note here is that, the role.  If you see the role there, it doesn't really scream to an investigator that it is a global  administrator role.  That is like one of the biggest cons, I would say, of Graph API logs, Graph activity logs.  It doesn't give you all the information right to an investigator.  And just like how Parthaman illustrated in the previous slides, you'll have to correlate  this log with other logs, such as in this case, it's going to be audit logs, to understand  what sort of role this is, and what sort of, what the user was basically assigned, what  sort of role was assigned to the specific user.  This was another interesting attempt.  So this was an internal lateral movement.  And what basically happened here is, the actor compromised a user token through a phishing  attempt and used it with a delegated permission app.  So what basically happens here is, the actor basically sends a phishing email, the user  clicks it, they give their credentials out, and the user is presented with a consent screen.  The consent basically asks for simple access, such as sending an email out.  And as soon as the user clicks yes, which an user will do, the app receives this token,  the actor uses this token to interact with the Graph API, and sends multiple different  emails to, yeah, multiple different phishing emails internally to the user.  And what we've done is, the first query basically finds all sort of slash send mail, which is  the request URI there.  It is one of the API functions which is used to send an email out.  And similarly, the second query is pretty interesting.  It establishes a baseline of all the apps using this function.  So this gives you a complete eagle eye view of what is exactly happening in your environment,  especially with the slash send mail.  And this is another similar to the previous slide.  So we have seen multiple engagements where actors access mailboxes either by abusing  Graph API's delegated or application permission.  So let's jump into a test scenario.  The threat actor abuses an app with an application permission mail.read.all.  And what this does is, the mail.read.all, it basically gives an application the ability  to read all sort of emails across the entire organization.  So if the actor has access to this app and its token and this specific permission in  the app, they would be able to read the CEO's email or any sort of emails and any sort of  user in your organization.  So what we did was, again, another query here.  It basically creates a stat of all the applications used for reading emails.  And it also provides you a time frame of sorts between a specific time to a specific  time when this was read.  And it gives you all the targets or basically all the mailboxes that were touched, which  means all sort of emails that were read from different people's mailboxes.  And of course, account.  So what happens here is that you'll get a clear picture as to different email inboxes  that were touched and by different app IDs.  So this gives you clarity about different applications which is using this sort of feature  from Graph API.  And yeah, as an investigator, your first thing is to baseline and understand if this is something  that's supposed to happen.  If it does, then all good.  If it does not, then yeah, you'll have to, of course, spin up an incident.  Okay, this is another place where we noticed another incident where we noticed compromised  identities accessing files on SharePoint and OneDrive via Graph API.  So the permissions used here are files read write and sites read write.  And yeah, what I mean, the query, what it does is it's like a pretty simple one.  It's a great starting point for investigating Graph API calls related to download activities.  So if you take a look into the below image, you will see that this is the log that would  be a resultant of such a read or such a download of a file from any sort of users.  One of the pain points again of this log is that the one where I have marked it in red,  that is the item ID.  Basically, that is the item ID resolves to a file name.  You do not see that here in the graph.  It doesn't tell you which specific file was downloaded.  So which means you'll have to correlate this with over here, it is going to be Cloud App  Events to really understand what sort of file was touched and what was downloaded.  I think that was pretty much the end of real life incidents.  There were like multiple complex incidents, of course, we have seen as a part of experience  and that.  But of course, the focus here is to show you guys how powerful Graph API can basically  be and to stress how important it is for you to collect these logs.  So what we recommend here is to audit regularly all the intra-applications that use Graph  API.  This sort of reveals you all the excessive permissions or unexpected accesses that happen.  And of course, when you see something of this sort, it could possibly mean that a service  principle has been compromised.  And of course, another thing is basically when you create auditing or baselining, it  creates a safe list of applications that is being used in your environment.  So with this list, you can continuously monitor to detect the new application that pops up  in your environment.  And what we have done here in this query is that we have created a data table and we have  sort of listed all sort of permissions and the privileges that comes along with it.  And the reason why we feel that it could be a sensitive one.  And we used all of this to basically quantify this with an app ID and their respective permissions.  So this gives you sort of an eagle eye view of all the different app IDs that is being  used and all sensitive roles that is being used for those specific app IDs.  And then with this, if you sort of negate all the first party applications, what happens  is you'll get a clear clarity about all different applications which is being used in your environment.  So from there on, what you're going to do is trying to understand if those app IDs first  is supposed to have these sort of roles.  If it is, all good.  If it is not supposed to have it, then of course another investigation needs to be spinned  up.  After which, you constantly keep on monitoring such app IDs coming up with new permissions.  And each time there's going to be a new permission, it's something that you have to jump on and  understand if it is supposed to be there and if it is supposed to have those sort of roles.  Okay, quick recap.  So we saw what a graph API is.  It is basically a service that connects multiple M365 applications.  So we saw how to obtain these logs.  One thing that you have to remind is that it's going to be super expensive, especially  if you have a massive foothold in cloud.  So please make sure to estimate the cost before you start collecting it.  So we went over multiple key fields.  We looked into a few correlatable tables such as cloud app events, audit logs, and then  AAD risk users.  And then we also looked into a few useful functions which is used during investigations.  And then we went over multiple real world attack scenarios and of course a few test  scenarios to illustrate all of these to understand better.  And we looked into how baselining these applications based on permissions and privileges help us.  So if you did stick until now and felt that these graph API logs could be interesting,  something that your organization doesn't collect or maybe they collect it and are not really  using it, we would also highly recommend you to go over different contributions and articles  from other researchers as well.  These are pretty cool ones.  There is one from Cloud Brothers where they have amazing advanced queries in it.  Well, this is it.  Thank you for having us.  And if you folks have any questions about graph API or if you want to know how cool  it is to work in a creation or Dart, feel free to come say hi.  We'll be around here in this room.  And I'm leaving you guys a QR code to scan that will take you to the article and the  respective queries that we were speaking about.  And yeah, of course, a shout out to DebugPrivilege, of course, he helped us mentor this whole  thing.  Thank you.  Are there any questions in the audience?  No further questions?  Ah, there we are.  Hi, guys.  Thanks.  I see this most likely a potential tool very attractive for hackers to sneak into organization,  read as much as they can, reconnaissance collection and so on.  So I believe that we have to see who has access to Microsoft Graph API to be able to protect  that account even more to avoid this from happening.  Have you ever seen an attack in which the hacker is exploiting the knowledge that he  fetches from there so far?  Because it's quite a new product, but I believe it's very attractive.  So all of the scenarios that we spoke about, all of those were real life incidents.  So everywhere we were able to see an actor performing one of these attacks that we spoke  about.  It was all from different engagements for different customers.  But basically the point here is that they did access Graph API to do everything that  I just said.  Yep.  There's one there.  Thank you for the talk.  At the end, or towards the end, you mentioned baselining applications to know what permissions  they normally use and if there are any new applications in the environment.  Has there been any thought to productizing that in something that's easier for customers  to consume?  Because, I mean, what you described here, you have to enable the logging, watch out  for any additional costs that might incur, tune the query for your environment to know  what applications or what permissions you're using.  Given that this is such a useful tool for an organizational administrator, has there  been any thought to just making this easier for someone to see what applications are in  my environment, what permissions are they using, what's changed recently?  So right now, there are a few audit logs that appears on the cloud app and a few other  defender products where you can actually see what sort of applications are existing on  your environment and with high privileges and basically stuff like that.  Of course, for that, you'll have to know really which one, where to go look for it, which  report to go click and really analyze it.  And this is more of a shortcut, especially for a security investigator, where you can  really run a query and then understand, okay, these are the applications, this is what I  have to concentrate on, this is where I have to go look at it, and these are the applications  that I know that is existing in my environment with the highest privilege, something that  I have to keep an eye on, and anything beyond this, anything suddenly pops up beyond what  I already know, that is something that I might have to investigate on.  So this is sort of like, let us say, a quick fix, especially for someone who has access  to log analytics and who constantly bugs on these sort of things.  Thank you.  Yep.  Thank you very much.  Sorry, on top of what my friend said, to make your life a bit easier, there is a webpage  in Microsoft Documents where they will list all of their first party applications.  So basically, the reason why we didn't include that is because you can't simply whitelist  all of the first party applications, because there is a way people can use those applications  to perform malicious activities.  One of the examples is like, so you can use a device auth token, so which means that can  be used for phishing, and that would be a first party Microsoft application.  So if we whitelist everything, then we might be missing that activity.  So like Shiva mentioned, it has to be manual baselining activity, just once, and then you  can, once you finish it, then it might be a bit easier for you to perform investigation.  Yeah.  Thank you.  Thank you.  Any other questions?  All right, then I would like to thank you very much.


url: https://www.youtube.com/watch?v=gkxOmbT2Jls
title: Louis Barrett - Small Language Models for Application Security - Beyond ChatGPT
type: video
author: LASCON
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=gkxOmbT2Jls",
    "title": "Louis Barrett - Small Language Models for Application Security - Beyond ChatGPT",
    "description": "Small language models such as LLaMa and Alpaca will revolutionize the way applications are designed and secured. This talk will provide an overview of how to use small, open source language models to enhance application security workflows and help us shift even further left.\n\n\nhttps://lascon2023.sched.com/event/1RE5A/small-language-models-for-application-security-beyond-chatgpt",
    "channel_url": "https://www.youtube.com/channel/UCDHsOiMPS-SLppAOAJRD37Q",
    "duration": 3634,
    "channel": "LASCON",
    "uploader": "LASCON",
    "upload_date": "20231118"
  }

  This text was transcribed using whisper model: large-v2

   You  You  You  Afternoon last con welcome to small language models for application security beyond chat GPT  My name is Louie Barrett  I'll be your guide today through the journey on  the future of application security  I'm a full stack security researcher with a passion for building security tools and  Solutions that increase the efficiency and happiness of my teams. I  currently lead product security at scale AI where we focus on implementing security solutions for the MLOps lifecycle and  ultimately improving the security of AI backed products  Prior to this I led detection engineering and instant response teams at both segment Twilio and these roles  I gained my first experience implementing machine learning algorithms and  approaches to detect and prioritize security threats  ever since then I've been experimenting with solutions at the intersection of artificial intelligence and security and  The goal of this presentation today is to enable security teams to unlock cutting-edge capabilities and apply them to security challenges  To accomplish this we'll cover some basics of language models their recent history and current capabilities  Next we'll look at some of the common application design patterns  Emerging our LLMs and categorize them to better understand how language models are built  Next we'll look at what models under 30 billion parameters can do for us  These are small language models and take a look at some common language of model apps  break down their functional composition and  Then we'll show you how these can map to app sec responsibilities  Finally I'll share a couple demos and lessons learned around these use cases if time remains I'll take some questions  Before I get started a quick poll  Who here is responsible for threat modeling security reviews or addressing vulnerabilities?  Awesome that makes things easy who here has heard of a large language models  Okay, how about small language models?  That's what I thought have any of you used open AI prior to chat GPT?  Interesting and how many of you are familiar with hugging face?  cool and  Finally who has attempted to deploy your own language models internally?  Interesting okay cool great. Thanks for that  So for anyone who wasn't familiar  Large language models are more commonly large language models are powerful AI algorithms that can analyze text and language as name implies  These models are trained on massive a massive corpus of data and tasks allowing to produce  incredible results when applied to challenges typically  handled by humans  Over the past three years or so and more recently the last 12 months  Development of an evolution of these models has basically exploded  It's what we're kind of terming the AI summer  Prior to 2020 practical and production use of artificial intelligence within security teams  Was basically science fiction  for all but the most well-funded organizations  And even then those who did have access to artificial intelligence often find it unwieldy and challenging to deploy  The language models of this era often required an absurd amount of computing resources  Performing the simplest natural language processing tasks and to make things even more challenging  Deploying them generally required a data science background. I don't know about you guys  But I don't have that background and I'm not a big math guy  So that was really a challenging period for me getting into this stuff  And leads to say the security solutions that are built on top of these models at the time were far from reliable  And that's all that's like partially because the people who are building them don't understand our use cases and also partially because  They're just so large and unwieldy in the first place  But in June of 2020 this all really changed  With the release of open the AIS chat GPT and while we had transformer architecture models before this point  It wasn't until the public and other engineers really got  Aware of this technology that it really started to boom because we started applying our own AI  For those weren't aware GPT-3 is a decoder only transformer model of deep neural networks  Which uses attention in place of previous recurrence like older generation models did and this allows the model to selectively  Focus on segments of its input and predict, which is the most relevant to the actual user  Development this new transformer model jump-started the development of similar models using the architecture and  The midst of a global pandemic where many of us are trapped inside and the unexpected availability of GPUs  do their major cryptocurrency platform or  Moving away from GPU based mining see theory emerge the next three years would see hundreds of models being developed which brings us to 2023  This year has been especially interesting to the release of open the eyes GPT-4 and chat GPT-4  This year has been especially interesting to the release of open the eyes GPT-4 and chat GPT  As well as the beginning of the open-source revolution led by the accidental leaking of llamas, I'm sorry met as llama model  Since then hundreds of models based on this transformer architecture and met as llama have been released  allowing researchers and organizations the ability experience artificial intelligence for themselves  and even more recently  Mosaic ML and Mistral AI  Respectively released the first open-source models which could be used commercially. This is a game-changer  You can now take these models train them a little bit and actually sell them back to your customers for your security company. For example  these new open-source models have been found to perform comparably to the original GPT-3 and  considering GPT-3 took millions of dollars to train and occupied 800 gigabytes of memory and  utilizes  264 billion parameters. A model of only 7 billion parameters performing nearly equally is nothing short of an engineering miracle  In the next few slides I'll go over what these models are able to do for us and get to some of the common types  of language model apps  So what can language models do for us?  Language models of today depending on how they were trained  are able to perform a number of different types of tasks  You can see the different types listed here  But first up is text generation, which we're I think all familiar with at this point  It represents the model's ability to use internal neural networks to generate coherent human language  Next we have text summarization  Where models are able to ingest large corpuses of text extract key points and during a more concise result  So compressing some text down to the more concise version of itself  Question answering where the model is able to predict  I'm sorry  we're able to provide answers to questions asked based on the data in central network and occasionally user input and  finally  classification  Models are able to determine if the provided data by the user falls in the one category or the other  Say for example, is this Twitter post offensive right things like this  By combining the language model capabilities on the previous slide with traditional software engineering principles a number of design patterns have emerged  These design patterns typically take the form of  A play adapting AI to human roles in some capacity and some popular examples include  Conversation apps such as chat bots and personal assistants the most popular of which you know is arguably chat GPT  Next we have our writing apps  Next we have our writing apps  Leveraging the journey of a summer of capabilities of the models along end-users to prove create creative writing and professional content  One such example is copy the AI where you can make business copy email copy marketing copy using these methods  and  Lately, we're seeing the development of a new pattern where you have these process magic and analysis support applications  And all those applications are amazing they have one thing in common in my opinion that essentially is an Achilles heel  Nearly all of them rely on commercial large language models  And while this seems like an advantage at first  There are numerous issues related data privacy data sovereignty and information security  when chat GPT  So when GPT 3 and later chat GPT became popular many organizations quickly had their data leaked almost overnight  due to overeager employees  using the models  but that being said let's dive into understanding how these applications are composed by using the LMAP maturity scale and  Hopefully should allow us to build safer more private alternatives to some of these application design patterns  And ultimately leverage them for sensitive use cases such as security  So the LMAP rating scale is  a  Scale we use internally to basically evaluate how complex an application is  And what we should look at in terms of either securing it or deploying it  The scale is currently broken down into five levels  level one being basic  Which is basically a one-to-one interaction with the model you have a basically no short term memory  so the model doesn't remember the last interaction you had with it is basically prompt in response out and  The entire context past the model is used for that one-to-one interaction  At level two  Models gain extended context and we see the chat design parents are emerging  You have this limited short-term memory which allows the model to remember its last few interactions up to a point  This is usually based on the maximum context window available to the model  Additionally allows the model to remain grounded because you have some previous context in your discussion  So it's less likely to hallucinate if you're nudging it along. We'll touch on this a bit more later and  the actors in these LMAP systems tend to be now a human user a  System user or a system prompt to give it some guidance and of course language models internal neural network  The data sources in this case are the user input  Of course the models internal neural networks training data and the act interactions topology  And the act interaction style becomes a multi-turn so you're going back and forth with the model until it's able to give you the type  of response you need  And as mentioned before chat is the most common example of this chat design pattern  At level three things get really interesting and this is where I see a lot of the current design trending to within LMAPs  where we're now using indexes to do a pattern called rag or retrieval augmented generation and  It allows the language model to no longer have to rely on the data. It was trained on  Do the addition of retrieval indexes in the form of vector databases or traditional search clusters?  Models are able to augment their capabilities immensely and almost completely eliminate hallucinations  so you can imagine passing in a complete corpus of  What the model should use as rules and will always reference those rules and it's like ladder generations  So  This leads to models having responses that are more truthful more correct and ideally safer for an end-user to actually interact with  And due to our retrieval works  It's a multi-phase process  You can't pass an entire database worth of content to a model did this limited input window  Basically chunk in the smaller pieces and that's what kicks this multi-phase type of interaction in the model behind the scenes  Even though this is typically invisible to the end-user  Now I mentioned there are five levels to this right and so far we've touched on three and  I'd like to mention that  For the most part a lot of organizations right now are just scratching the surface of level three  You don't really see it well commercialized and level four is almost unheard of in production  But I want to just touch on one notable example of a level three application that we've developed at scale  It's a retrieval platform called Donovan that allows you to basically connect either  Things like confluence Google Drive your Google Docs  Whatever you want to your model as a retrieval index such you can ask questions in that corpus  We use this a lot internally on the security team to drop in all of our policy documentation  Give this to our like sales people such that they want to come to security and ask questions  It's all already in the docs and the model is basically following our best practices  But that being said let's actually take a look at what level three  Entails because things get really interesting at this tier because it's really experimental and since there aren't too many commercial products  It kind of diverges in two directions. Whereas the previous levels have been  directly iterative  So it's again I mentioned it's split into two levels we have a little 4a and a little 4b  Level 4a brings about language model based agents, which we're just starting to scratch the surface on  Most of these aren't in a true production  Environment right now and as models can interact on their own to some degree and solve problems for their user  So this introduces the addition of a goals manager or goal framework behind the scenes and that basically breaks your single query down into either  steps or  Instructions for the model that generates sub prompts that either the core model or additional sub models follow  So the actors in the system become the human user our existing system prompts for guidance, which were basically always there  from level three and up  Our goals manager or goals framework and obviously the language models internal neural network  As with the previous level we also have retrieval indexes here  So not only is the model able to go out or the application able to go out and act on behalf of the user  It's also able to reference content that users provided ahead of time  As guidance or a guidebook, right?  and  As with the previous level the interaction style is multi-turn and multi-phase so you can chat back and forth this type of a model  and you can also have it occur in phases because we're using retrieval and also the goal framework stepping through a list of  Goals until it reaches the end, right? So that becomes multi-phase  And  We've recently seen the emergence of a little 4a and chat GPT, but it's not as direct as people would really think  They add the recent feature called search with Bing. It's very experimental. Lots could go wrong there. I'll touch on that later in the talk  but the models  Systematically does Bing searches until it finds the answer to the thing you were looking for and behind the scenes  it's treating Bing as a retrieval index and  Treating your prompt as the source for that original goal breakdown and when it finally breaks things out to goals  It's taking all those goals and searching them on Bing and then summarizing everything and bringing it back to the end-user  So right now, I think chat GPT is the only  Commercially or public accessible platform that I've seen do this at least a little bit  But we're definitely gonna see more of this as time progresses  But with that said let's jump into a little 4b since again, I mentioned things are kind of diverging a bit here  Level 4b introduces multi-model consensus where you have multiple models kind of acting at together  Here you need an extensive short-term memory because the number of interactions you have even in a single conversation  Can be pretty extensive  Requires a large input size so models that support more than the standard  2,000 tokens and just to kind of break down what tokens are for language models  One token is about three quarters of a word, right?  So you can imagine you can get pages and pages of data into these things if you have a large input window  We have a new item getting added to our data sources in the form of an orchestrator  the goal of this orchestrator is to basically give work to all the sub models in this system and  Tell them how to actually operate and once this orchestrator has  Gotten the results back from all the sub models it rolls those results back up. It says hey user. Here's your answer  So you can imagine this being used if you arrange models into teams or virtual teams  We have one being the manager one being the engineer potentially and one being the designer, right?  And they all have different goals. They relate to the larger project  You can kick a prompt off this model such that it  Rolls up what the entire project plan would look like because the sub models have their own individual goals being kicked off by the orchestrator  Chat GPT actually does this behind the scenes and this is for GPT-4 specifically  Lots of people think GPT-4 is a single model  But it's actually many models behind the scenes or like, you know, three models in a trench coat essentially is what you're really getting  Level five again, this is like unheard of this doesn't really exist in a commercial sense yet  But models get long-term memory and start acting true cohort systems  So taking that concept from level 4b where you have small pods of actors and scaling that out, right?  so horizontally scaling that concept the input size has to be  Immense because you're basically taking a huge chunk of data and dividing that across a number of different models  We have our orchestrator from the previous level  Along with internal indexes and we have this multi-turn multi-phase interaction  But the difference here is now you have pods of models able to communicate with each other  So you have an orchestrator in each pod that talks to another pod says, hey, did you finish?  You know either  Summarizing or whatever the goal of that other pod was and then there's a grand orchestra that rolls everything back up to the top  so you get the ability to basically  coordinate models at a high level, but the  resource usage and  Requirements of the system like this typically make it something that's out of the realm of consumer usage and I'll kind of leave that there  All right  That  All right, so those of you are following along  Congrats, we've reached a practical portion of the talk and I'll try to slow down if I'm going too fast, please. Let me know  we'll get into real-world use cases for the model capabilities and  design parents that  And map the design parents to this middle zero world cases  Using the rating skill we covered earlier  So  I just want to share this quote from William Gibson real quick because I think it really touches on  How things are currently moving in the AI space and that's the future is already here. It's just not very evenly distributed and  The goal of this talk is to more evenly distribute that future and allow us to greatly improve application security, right?  So to me application security has always been about securing the software development lifecycle  So, let's see how we can apply some of the concepts I discussed earlier to the actual software development lifecycle  So AppSec teams typically have a challenge of juggling security design reviews, threat modeling, code reviews, and vulnerability management  Each of these responsibilities requires us to read lengthy documentation, draw conclusions, follow up with developers, and  provide recommendations and  So for those who've been paying attention you'll notice these responsibilities basically map fairly well with the task of abilities of language models  which are a summarization, closed QA, classification, and instruction following and  The natural alignment between our responsibilities and the capabilities of these models is why I first began this research  In the following slides, we'll see how we can leverage the capabilities of these models mainly small language models  To improve the speed and accuracy of our security team  But please keep in mind that the goal is not to fully automate your jobs  That simply cannot be a thing at this point  But rather to assist you in completing them and reduce the time you spend doing, you know, painstaking tasks  So everything I'll describe going forward requires some level of human interaction  or human-in-the-loop somewhere in the process and that's both to avoid the  LM top ten vulnerability number nine, which is over reliance on the models output  Because we do have to review and make sure these things are correct. Otherwise  Terrible things can happen. You don't want dev shipping something that's vulnerable that you had the model sign off on without any kind of review  Cool, so let's touch on how we can use models for security design review  Typically, hopefully you guys can see this, a development team provides some initial documentation  Such as a software design document or product requirement document  The team then reviews the document signs off with a rating of pass, fail, or review  A pass allows developers to continue to the next iteration of the design  Until a significant change occurs  However in scenarios where they need to or doesn't satisfy design requirements  We fail or say it's a review and then security team follows up and says developer change thing go back to review  The review process ideally shouldn't take up much time, but when you consider how outnumbered most security teams are  These reviews can quickly pile up and clog up the works  Considering these challenges  Let's think about what security design review really is and how we can plug in a language model and make the process more scalable  So whenever I'm thinking about should I use, whether or not I should use a language model  I'm asked, you can ask yourself this, who is prompting me and  Should they be prompting a model instead, right?  And we've applied it, if we apply this mapping back to the sequence diagram  We should be able to see how a language model can help here  In this case the model is able to take over reviewing the user submitted documents by reading this and summarizing the content  Following the instructions provided in a review standard and answering a few basic questions defined in the same review  It then provides a roll-up of the results to members of the security team for review  And although we only eliminated one step from this workflow  Those of you do lots of code review will understand this is the most time-consuming step  Design documents may be many pages long  highly complex  contain references to systems or concept that more junior engineers might not be able to understand  And generally coupled with the volume of reviews that come in it can make design review like a pretty heavy task for any security team  And if you're trying to shift left  It becomes almost impossible given the scale of it, right?  And this is a relatively simple LM app the use case  We're able to quickly analyze documents notify the developers of gaps  And we're able to do a lot of other things in the same way  So we're able to do a lot of things in the same way  We're able to quickly analyze documents notify the developers of gaps and ideally while reducing the burden on your security team  So this is a really simple example, but I want you to keep these  Benefits in mind as we move on to the next example, which is basically a larger version of a security design review  the threat modeling session  Threat modeling can be considered more advanced form of design review like I mentioned  This is typically a collaborative process between developers members of the security team and occasionally other stakeholders  The threat models can be conducted synchronously or asynchronously with teams providing guidelines and documentation ahead of time or bringing them to the meeting  But regardless of the approach there is a heavy analysis burden placed in this  Documents when they're provided  Fine okay, awesome. So additional design documents when provided by this these development teams  They they might contain  Content of the Siri team like I mentioned before wasn't familiar with and we kind of have to go through those and reason with them  Is this system in line with our design standards, right?  and do the complexity of the process and the number of people involved it typically requires a significant investment both from development teams themselves and  our security team  Dev teams are often on tight schedules. They want to face them as quickly as possible  but security teams want things to ideally be secure. We're security teams and  Address all the vulnerabilities up front that way they don't reach production  the disconnect typically results in either short light threat models that leave gaps or  lengthy threat models that block the pace of development  So  I can write balance between speed and quality requires parties involved to be on the same page and  Collectively understand the risks within this threat model  Do the differences in levels and point of view this this process like design reviews?  I just touched on could be extremely difficult to scale  But let's look at from a high-level perspective for how we can actually apply some of the concepts we saw earlier to the threat modeling process  So  The existing process requires quite a bit of back-and-forth interaction between development teams and security and a solid understanding of the implications of both  design and mitigation decisions  This can be especially difficult in resource constrained  organizations, I don't know about you guys, but  we don't have a one-to-one relationship between our engineers and our security team members and  Look, you know, it's a situation where you can be swamped even if you are proficient in threat modeling and design review  But luckily we produce a number of interactions required by injecting a language model into the process  This way we can use the same task capabilities from the previous designers review example to delegate work to a language model  The model analyze provide documentation as before  Read our threat modeling guidelines, and you'll hear me mention guidelines a lot here  If you produce a good documentation internally today, you can easily benefit from using language models  So that's another reason to like have your junior folks produce documentation because you can feed that back into a model  It makes everyone's life easier on the line, right?  But yeah, I mentioned that it goes to the guidelines  It will highlight the risks in the proposed system and come up with some mitigations before submitting them to the security team for review  And in this example, the model actually takes care of most of the heavy lifting  I'm reducing the burden of your security team by order of magnitude  But to take things a step further we can automate the process a bit more  By providing the model  Guidelines this is like a retrieval type of setup  The model will use this documentation to follow your best practices and rely on less indirect feedback from your security team  So you're going from a few interactions with your security in the model to one or two  While still remaining accurate  Summarize the use case here  We can reduce number of interactions between teams automate the majority of document diagram analysis. That's a big one for some people  Just a note on diagram analysis  If you currently do threat models with just like images of your system  You might want to stop doing that  use mermaid JS markdown to describe your document because then the model can treat your design as text and still understand the flow of  Design making it a lot easier to actually slot these things in so again  I'll harp on this a lot  But good data in gives you good results out and if you don't do that data work up front  You're gonna have a world of hurt, right?  All right  So we've got some mitigations our model here, but let's touch on another aspect of  AppSec responsibility the dreaded code review. I have to do a number of these per week and  Honestly, this is the whole reason I put this together  We you know  We have developers who won't see you for weeks and then all of a sudden you have a PR with thousands of file changes, right?  It's on a code review  Like I mentioned this one isn't too crazy, but  You know merge after Wednesday. We get this on a Tuesday or something and  24 files have changed  758 lines of code have been added. I don't know about you, but I'm not gonna read that dude. I'm just gonna be like hey  Looks good to me stamp it let the phone  Management team deal with it. Let the security operations team deal with it, but obviously not the best way to actually design software, right?  Yeah  Just like previous examples look at the existing way we do code review and then see how we can slide a model to help us out  So today  Yeah, we're gonna assume where the developer first creates a new branch repository this isn't always the case  They could also take over for another developer which introduces other issues  But next they commit some code possibly hundreds of times and eventually open the pull request  Either as a draft or when that's ready for review  Some CI checks occur stack analysis workflows running against the PR the dev team notifies some reviewers  usually within their own team and  Sometimes include the security team  and  I just want to know the development teams might have a good idea of when to include security and a lot of that's actually our  Fault because when we put security checks directly in repos they assume that hey security checks ran on my my code  I shouldn't need security to come review it  But as we all know  Security checks on your repo aren't enough. We actually give through manual code review  But let's continue the assumption that they did ask us to review and by this point  We're often taken by surprise feels kind of like a pop. It's like hey surprise. You have a huge PR to review  Do you know what to do here right like if you've been seeing this code base a lot of us within security aren't actually  Developers and that disconnect is like one of the issues that causes friction during code review or missed items  I'm needless to say the huge number of changes can put a massive strain on the team  So let's look at how we can do code review in an AI assisted way  You'll notice from the flows here without going to too much detail  So I'm sure you can't see the actual wording  The majority of the interactions now occurring between the developer and the language model at a high level and security is almost  uninvolved at this point, right and  You know do the fact that these recent language models are excellent both generating and evaluating code coupled with the basic capabilities of generation summarization  Is now possible to improve the speed and accuracy of code review by providing a model context from development process such as commit messages  File diffs a PR description. So again another reason to have good data  Force your devs to put descriptions on PRS  So a model can read the description and you don't have to go back and say what does this PR actually do?  We can potentially  Reduce the evaluation time to seconds instead of minutes or days and actually keep pace with developers which makes them happier  It makes us happier  In the new AI assisted version of code review  Like I mentioned the language model took care of most of the work going back and forth reading all the docs  commenting on things  And also keeping track of the commit messages diffs and more  All right  So the more context you have in your PRS the higher quality of data is get the better result at the other end  Just to summarize rapidly analyze massive amounts of code they were designed to do this they were trained to do this  Preside provided consistent view quality like if you have a junior engineer review a PR you have a senior engineer  You typically have different results  so this gives you a consistent baseline that you can also use to improve the quality of your more junior engineers and  Hold your more senior engineers accountable since we all slip every now and then  the other nice thing here is you can scale to handle the load of developers just  spitting out PRS right like we've all been at the end of the year whenever we have to launch new software and  You know teams are asking for reviews. We don't want to block their actual development process. We never want to be blockers and security  We'll get that bad reputation. So this allows us to scale the process without compromising on quality  And you know up until now  I haven't touched on any of the nuance of actually building LM apps  But the shed a little bit more light on this  I'll break down the code review app a little further and provide a recipe for building a similar solution  The next few slides will cover our builder requirements which model to use for certain tasks  Prerequisites and a recipe for applying the design to your own environment  So first let's start with design requirements  We want this to integrate into existing development workflows  We don't want to take developers out of what they're used to doing and make them do something completely different, right?  They're either not gonna do it or not gonna enjoy  We also want to make sure that produces a result at least as quickly as a human reviewer if the process takes longer  Why are we doing it? Right? So a lot of people will slot in language models and  Not really understand why they're sliding them in other to other than just use AI for the sake of AI  We don't want to do that here. We want to make sure we're getting an actual benefit out of this integration  Additionally, we want to maintain data privacy and security by using open source models  Such that we're not leaking our code to third-party model providers such as open AI and others and  We want to also obviously for security team's sake be able to audit the decisions made by our models  So keeping some log of the interaction that occurred between the model and the connected systems as well as looking at  For example, if we have a review that came through the human go back and that result or is it unchecked, right?  So we know where the fault is  So all of these requirements are actually sourced from both development team and the security team like kind of actively in  In the ecosystem right now  You can kind of tell which items are developers first versus ones are security  But we need both that we need all of these requirements to actually make it a workable solution  So next let's get to level mapping our code review application to see exactly what we did  So next let's get to level mapping our code review application to see exactly what we need to put together for it to work  For  Due to the fact that it takes in, you know file diffs commit messages and status checks. We actually need extensive short-term memory  The extensive short-term memory and large input size are needed for within our application to deal again with the diffs  But this necessitates also an internal index to store  The diffs from these files the commit messages and everything else in one record  So when we pull it into our model, it's able to reason over the entire PR and have to do several retrievals behind the scenes  Right, but that's only possible when you have a large enough context window to actually take in all that content  Additionally the fact that the PR commits can occur asynchronously they don't all happen at once it can be over many days  Um, but the order doesn't matter we need to treat these as a event stream or conversation  So that maps very well to the original level two design where we have a chat type application  But in this case the chat isn't user facing. It's system facing  basically the the chat is between the model and your  github or github or  Gitlab or whatever, right? So that event stream becomes your chat  Building on top of that and given the requirements  Um, we basically need a level three model at a level three app at minimum because we have a retrieval section we need to  do and we also need a section for  Interacting the model back and forth and maintaining that that session stream that conversation stream  In this case, you can consider the session id  The repo and the PR number so this is how you're going to break up  What conversation is occurring and be able to manage a number of these at once, right?  So we can scale with that  Um  Next one again to how we choose a model  um  Since we know our high level requirements and that require a sizable input window  And we're dealing primarily with code. I had basically two options for language models to use for this  Mosaic mls mpt7b with an 8k context  Or hugging faces zephyr 7b, which is based on the recently released mistral 7b model  I just want to note like i've had to rewrite this talk like 13 times do the pace of changes  In the ai industry, but this is currently my top two for actually deploying this stuff internally  So our chosen model should be somewhat obvious I hope  Was mpt7b  And this was released back in march and the mistral model was released this month  but what I found through testing was that the mosaic model was  Generally better all around and excelled at code even though it was only okay at retrieval tasks the 8k context window made it  Amazing for giving it a prompt tuned  Instructions in this case prompt tuning is in between  Your prompt engineering and your classic fine-tuning where you have to fully retrain the model instead you give it all the instructions you can  Using up a good portion of that 8k context to say do this thing  That way you don't have to go back and retrain the model and that allows you to  dynamically update how your models behave without spending hundreds of thousands of dollars retraining or you know hours and hours and  Getting the resources to do this  I just want to note that in terms of model sizing  to train a model that takes up 13 gigs of video memory usually requires an order of magnitude higher than that and  I don't know about you, but I can't find a video card that has 140 gigabytes of memory  at least not in my budget, right so  Using ones with large context despite their small size can give you a nice middle ground to actually achieve a good results  All right, so before I actually hop over to the recipe here or the ingredients I should say  One more thing I want to mention about  These two models. These are the ones that are commercially available for people to use outside of just hobby type usage  So if you want to build a product about you actually can question  A great question, how do I measure them?  So there are benchmarks have been released  But a lot of these benchmarks are subjective because they weren't based on security use cases  They're based on general language use cases. So I measure these through actually using them over the past say like nine or ten months  internally, right and  so how often do they give us the result that we didn't want in a review versus the one that actually our security team would  Have used and we take those examples back out and put into that large system prompt  Like I mentioned such a nudge in the right direction. Thanks for the question  But yeah moving on to the ingredients the other parts of the system  We will need other than the model since you consider the model the core, but we're gonna build a level three application around it  the ingredients are again our small language model a server to host this a  CI webhook host this can be serverless anyone who's done any kind of GitHub actions or CI automation should be familiar with that  So I won't really dive in there I'm an orchestration host it's like a workflow manager such as  AWS step functions and 8n or temporal a  Retrieval index host you can go a couple different directions here  Either using a vector database, which is a bit more complex or  Elasticsearch, which I really like to use in this case. It's simple to deploy and performs amazingly well when paired with the model  but here you can also use things like  Big query and other available databases in its place  next we have  Our system prompts templates that we use to do basic code review filed it for a file diff guidelines and status check guidelines  So the rules we give models when interacting with certain parts of our actual system  Next we have our model configuration, so how do you want to set this model up to actually work within your application?  Like I mentioned before the  NPT 7 model is an 8k context  But I don't always use all 8k of that context and the reason is when you set it that high  The model has to always consider that volume of information and actually performance more slowly  So the smaller you can get that context window set you'll have  faster tokens per second or faster response rate back from the model I  Typically allocate the token capacity in like a 4 to 2 ratio  So like half of the total context is for system prompts a quarter of that is for the user input  And then the last quarter is for some  Usage specific additional context so if you're doing a filed if you might say this is a file diff  And you know we have this criteria kind of going along with it  We're in the main system context you have you are a bot that does  Threat modeling or code review or whatever else like the cornerstone being that  the  the half of the total context  Next I want to touch on temperature. This is a setting within these models that basically adjusts. How variable the output will be and  Ideally should be set as low as possible for production use cases because you don't want it going off and like writing you poetry, right?  You want this thing to be as on the rails as possible if we're going to use it in production  So set temp to 0.1. This works really well the NPT 7 model  not as well with certain others because they do have a  Finer grade of what that temperature looks like  Time okay  All right, so they get the best results of the model we chose we need to design our inference system to actually can handle these requirements, right?  The NPT 7 models and 7 billion parameters in general consume 13 gigabytes on disk  13 gigabytes of system memory and up to 20 gigabytes of GPU memory inference time and  Do the way these models are loaded first being copied it to disk and then to system memory and then into GPU memory  It's actually necessary to have a server that has more  System memory that does GPU memory  This is like a major pitfall of a lot of these designs people try to roll this out  Because most of the cloud offerings don't give you that split because they were focused on a previous generation of machine learning  where you didn't need this massive amount of system memory to do that initial load, right and  just for some additional guidance here like reference a  30 billion parameter model takes up 60 gigs a 70 billion parameter model takes up 140 gigs and  That's just on disk and in memory when they're loaded when they're running they take up about a third more than that  Right. So again, one of the reasons I trended towards smaller language models  There literally aren't systems that we can use to actually run them. Otherwise, right once you go above say 30 billion parameters  Okay, so I think I want to touch on here is the retrieval index system this is elastic search you typically have these in clusters  Here you don't need too much too many resources because you're really just dealing with text  It's not like a logging or scene platform where you have gigs and gigs of text  But you still need enough headroom such that's performant and here I use basically a smallest offering for cores 8 gigabytes and 40 gigs  of storage per node because actually we don't need to retain any of the file diffs or PR context for a long period of time  They life cycle out  Cool so gave some core components of the actual design. We have our interface layer, which is a Gradio  This is an experiment interface  Now owned by the team at hug base and basically allows you to wrap any language model in  Three line in three lines of code and actually serve that as both a web app with a GUI and an API  Which is really convenient  Next we have some core libraries. You're gonna want to be familiar with  PyTorch being the most  Necessary here. I just want to mention that there are two current branches of PyTorch version 1 and version 2  Version 2 it has been heavily optimized, but most projects are pinned at version 1  Leveraging version 2 typically gives you a 33% speed up  Without using any more memory or anything like that and also allows you to in certain circumstances  directly load  Models from disk into GPU memory bypassing the system memory, right?  but this is only true when you couple it with safe tensors, which are an optimized version of the  Models  Core files like they're exported different formats such. There's no executable code  No risk of having malware run in your models actual  File and just keeping in mind that these models are actually pickled Python code so you can have  Model malware. It's a thing  You save tensors  Next here is hugging face transformers a few of you are familiar with this  It's probably de facto great thing with my  natural language processing and  Also, it can give you you know a model interface in three lines of code really really easy implement  Finalist one touches some general system things  Python projects have been around forever. We a lot of people use virtual environments. I really like how compostable poetry makes design these projects  I mean you get to include every system libraries  Pin versions on model specific things and basically have something that's repeatable as you can run the container or as a  Microservice if you want to go that route  As the operating system that actually runs the app. I recommend lambda stack  They basically roll in all of your dependencies around and video libraries  Drivers everything into one clean nice package and it keeps itself updated over time  so you don't to go back and say oh my pytorch implementation broke because my  Driver version is now different than the version required by the actual library, right?  So highly recommend that if you don't want headaches  Yeah, let's all go on to the recipe real quick here make sure I'm leaving enough time for questions  Yes, we install a lambda sack starting a poetry Python project  We create inference pipeline using hugging face again. This is three lines of code like literally three lines of code  We add llama index which I haven't really touched on just yet that allows you to chunk  Documents into sizable pieces that model can digest and this is what powers a retrieval system  Next we wrap the model in a radio interface to easily provide an API and a web GUI for either administrative purposes or  You know troubleshooting  But just a note on radio since this is something that's used pretty much ubiquitously  And it does offer the predict an API endpoints a GUI and the API are in the same route  So I really recommend putting a reverse proxy in front of that to only serve one or the other  Otherwise, you can get devs basically playing with your models back end and you don't typically want that  Finally we deploy a webhook your classic CI webhook to call this radio API when the new PR is ready  Yeah, so again, like I mentioned this is a pretty simple API  Yeah, so again, like I mentioned things have been changing pretty rapidly so next week I'll be providing a  One code sample of this actual app, but more detailed descriptions around the actually building this recipe out and share the repo  But that being said  Let's dive into a little demo, right? Actually first here. Let me show you guys this diagram. Hopefully this loads  Come on  Will it load?  Yes, okay. So here's our new flow with everything kind of built in  They're level 3 app. So I'll start I'll start from where the CI webhook kicks off so you guys can see the flow of that  But the security webhook upside the CI webhook receives a call from the PR  the code review begins based on the  branch and the repo name  Again repo name branch name  Confirms it back to the app and then the app is what actually goes and retrieves any supporting documentation  from in this case elasticsearch  And at the same time sends over one of our system prompts  With the criteria and guidelines as the the head of that actual prompt and says hey go review this PR  the search is executed based on the PR number since we're actually taking in some of the  Details around the PR. So our file diffs, commit messages, etc in our retrieval index  These diffs are chunked. So the results are chunked back to the LLM app using LLAMA index  and checked against neural network and  Then that's returned back to the actual application as a short summary and verdict which then bumps it back to our security team for review  So pretty straightforward like I mentioned  I'll share a repo with the actual code for this as well as like a proper architecture diagram. It's a little easier to read  And let me switch over here to show you guys the actual  Front-end or administrative interface of this app. I'm kind of using that retrieval pattern  Okay  Same diagram there. So this is not an interactive example. It shows my prompt here  I  always want to tell it the source of the data because a lot of the times when that you look at the training data that  Went to these models. They're structured like this. So if you're ever curious how to use a model properly  Actually go read it's either the training code or see the data sets  it was trained on because the examples are really guide the types of prompts you should make and use with this model and  Additionally you can also know terms you shouldn't use in your prompts that would throw the model off base  So I was looking at the tokens file for the model to see exactly  What things are stop tokens special keywords, etc that you should avoid and those tend to come up in code naturally  So it's something you want to know ahead of time  So here we ask it to provide a separate of the actions taking this pull request and review for security concerns  We have some guidelines the security team is only concerned with changes that impact authentication authorization or data security  and then the output format should be a short summary with verdict pass fail a review which would get sent to your security team and  As you see the data source here is one of my repos  You can basically put that in on this interface and should go to the repo and actually pull back some context  So I'm talking about a high level. I think I have time to show you the  Semi interactive or that actually yeah, this is a real PR now internally that we had to review something goes across  The public repo, so it's totally fine to show you guys this this is open source  But there are some security concerns here and the model will go through and actually use this PR  Review if you look at how long this is actually taking I don't know about you, but it's faster than I am  I've been doing this a while  We'll actually go through and do the review summarize everything in the PR and give your result back  So like I mentioned radio has a GUI and an API  I'm showing you the GUI here to basically illustrate this  But this would happen behind the scenes between the web the user and like the post back to your security team wherever they are with  A slack or you know directly on the PR or wherever else  Cool and that brings me to questions happy to show you guys an interactive live demo  But I think I'll take a few questions since time is now  running short  Awesome  You in the back there  I  Love how this is always the first question over there's like AI generated content. This is dolly free in this case. Yeah other questions  Okay, so there are two ways to approach this right  Your spend on open AI per year is one thing to look at  I've seen people spend hundreds of thousand dollars a month to to run models or an inference through open AI, right?  Cost is a big one  so if you're when I mentioned the difference between  The previous generation of cloud-based AI systems and the current jet and the current generation  You find that you're unable to get enough system memory to satisfy your needs with the GPU memory  Almost ever without paying about at minimum like 700 bucks a month, right something crazy  But you spend  1,500 or 2,000 once and you have a system that can do inference for you at this scale  For the rest of the your ownership of that device and since these models are open-source  You can cache them modify them. You don't lose access to that. You also don't have open AI changing the model underneath your feet  without you knowing right and  It's probably too late to say it's at this point, but the views expressed here are not from any current previous or you know  Future employer and they're also not the views of chat GPT, right?  Yes, so I'll share that  Basically next week because again like things change so quickly that I cannot share the raw code right now  There are like curse comments in that code, right?  So some clean needs to happen, but this will all be shared detail. You plan to open source. Oh this absolutely  Yeah, this is open. This is open sourceable. There's nothing here that isn't  Something you can pick up and do today  Like I mentioned three lines of code will get you to the point where you can do inference against these models  The total retrieval system was about 100 lines of code  And that's funny because I gave it  Variance in terms of where I could pull context from like you probably saw on the slide before can read Google Wikipedia  Gets pouring data from anywhere. I better understand something that your internal team might not well understand, right?  Do you have any estimates on the time save versus the cost of actually running it?  Rough estimates since we're pretty small team  I would say that this is just being optimistic that I've saved about 80% of the time I would spend on design reviews or threat  Models just through using this and getting that time back allows me to do research  It's know my development teams better and also like improve the quality of these types of services  Because I get the time to actually interact with human beings since the models are doing a lot of that heavy lifting  You have to productize  I definitely can't do that. But thank you  What's that  Hardware costs so as far as hardware costs, I recommend checking out lambda lambda labs  to get some guidance on what  Baseline hardware to build something like this looks like since this is always going to change due to GPU prices and you know  Price is going up and down new boards being released, etc  but I think like going through lambda labs looking at their desktop offering is a good way to kind of price out what the  different system might look like and  Keeping in mind the requirements grade that I mentioned before  But you know, I think I kind of went overboard when I built mine  So I don't recommend getting like 256 gigs of system memory and 12 terabytes of storage or anything like that  but you can probably get away with spending about three grand on something like this using a consumer grade GPU like a  RTX 3090 or something like this  Any more questions?  So  It's  Realistically to build everything it took like a weekend, but to actually like build out the project  It was many many months of iteration, right?  so  using all the different models that have come out seeing where they fail see if it makes more sense to spend the time to  Truly fine-tune it or whether or not I can convince a model to behave a certain way by editing the conversation  I had with it, which is prompt tuning in this case and nudge in the right direction  Thank you  Any other questions?  Can you share all the models that you tried rather than just the top two?  yeah, so there are about seven that I looked at and  for the most part the gap between one and two and the rest was so  Vast that I really only recommend using these two for open-source use cases like even with the base llama models or the base  MPT model, I don't sorry like base Mistral model  their lack of basic fine-tuning makes them very hard to use that thing in a lot of work and  Especially when you have a limited context window as many of these models do  You're not able to actually even prompt to them in the right direction  So that MPT 7 with 8k context is unique in that sense  It's a small model that can take in a massive amount of input such that you can guide it in the right direction  So these models were hosted on a physical machine, right?  Because I kind of mentioned using a cloud offerings  It tends to be pretty crazy, but you can obviously offload data storage to things like s3 and stream in  The actual model files yourself and run them that way as opposed to storing them on a drive locally, and that's any other questions  Yeah, so I mentioned workflow engines earlier, but I didn't really touch on their usage here  But that's what the workflow engines come in every single step of that workflow  Basically has an audit output as well as a lever that a dev can pull an engineer my team can pull to basically say  Do one thing either the same or different and kind of make some adjustments  Sometimes in real time like if you see that this is a file diff heavy  PR versus a comment heavy PR  You can actually switch the model downstream and say I actually want to use  the Zephyr model from Hugging Face instead of the MPT model such that it handles a certain condition better and  For future work  I'll probably use some of these models in  Parallel or in tandem because they're small enough to actually be run on some of these larger GPUs and have multiple models on the same  GPU without any performance loss  How small? Okay, so I think anything below 30 billion parameters is considered small  But at some point basically next year anything we thought was large today will eventually be small anyway  So long-term they're all gonna be small language models. I think assigning size to any kind of technology  Is usually hubris as we tend to like go through Moore's law, right?  But yeah, 7 billion parameters where I consider like small there is something like a million parameters  But yeah, 7 billion parameters where I consider like small there are smaller ones, but they don't perform nearly as well  There are things like mini LM and those are like 100 megs of disk space  But they really don't do the job well enough to actually be used in production  You can see me later. Thank you  You


url: https://www.youtube.com/watch?v=612Pi_yk3s8
title: (KEYNOTE) Crazy Incentives And How They Drive Security Into No Man's Land by Dr. Christian Folini
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=612Pi_yk3s8",
    "title": "(KEYNOTE) Crazy Incentives And How They Drive Security Into No Man's Land by Dr. Christian Folini",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 3549,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Thank you very much, Alain.  It's nice to be back, actually.  Welcome, Lausanne.  Good.  I'm going to talk about crazy incentives and how they drive security in no man's land.  What do I mean by that?  I mean, incentives are very often misaligned with security.  So we start working away, we struggle, we invest time and resources,  and instead of going forward, we're going backwards or in the wrong direction.  So despite hard work, we're not getting security in return.  And when I started to think about this concept,  I realized very often it's incentives that drive us in the wrong direction.  We're not aware of the incentives of people working with us.  We're not aware of the incentives of vendors selling us their products.  We're not even aware of our own incentives.  So what I'm going to do is walk you through a couple of examples.  Let's dive right in.  This is from a video stream from Naomi Wu, a real sexy cyborg on Twitter.  I think she walked around in Gansu or Shanghai in January or February and posted the video.  And people went crazy immediately because what is happening here?  What do you see?  You see mostly young women flocking to an undercrossing to do streaming.  At first, this looks like a sweatshop.  However, they're all volunteers.  They want to do this.  They want to be there.  They want to stream there.  Why is that?  It's not the beauty of the scenery.  It's also not the good company.  What is happening is they have incentives to gain the location feature of their streaming software.  They want to stream from a certain location, from a good neighborhood,  instead of being outside town where nobody would follow them.  They want to stream from exactly this position.  That's why in the night, in the evening, they flock together in an undercrossing.  They have an incentive to gain the location feature,  and the result is your PM being puzzled, going crazy over the video.  But this exploded so quickly.  What we see here is incentives at play that have very funny results.  As I said, I'm Christian Folini.  I'm a Swiss security engineer.  I have a background in medieval history.  This is what I did before I turned to security.  This is where I get my helmets from.  I'm a co-leader of the OWASP ModSecurity Coralset, a web application firewall project.  I'm going to talk about that as well.  I happen to be the program chair of the partnering conference Swiss Cyberstorm happening in October.  You see you have a great company conference at the end of the winter,  and you have another great conference in Bern in October.  Please join us in Bern on October for Swiss Cyberstorm.  Apparently, I'm a wearer of many helmets.  I'm also working in e-voting security.  I talked about that at a previous keynote.  Now I'm going to talk about incentives.  I'm taking this off because it's a bit heavy in the end.  Incentives.  First, what is an incentive?  I turned to Wikipedia.  What else would I do?  Wikipedia tells me, in general, incentives are anything that persuades a person to alter their behavior.  I guess we can agree on that.  If we continue with the definition a bit, we get to higher incentives amount to greater levels of effort,  and therefore higher levels of performance.  Streaming in the Undercrossing, you get this.  You make an effort to drive there, maybe to freeze in the winter for higher levels of performance.  That's the view count.  Performance already points to economics.  Incentives is an economic term.  It's definitely not a cybersecurity term.  This is not a term that our industry coined.  Incentives is an economic.  It's a business term.  This already shows you we have different incentives here.  We have economic incentives, and we want to have security incentives.  The two are absolutely not aligned with one another.  Obviously, if they're misaligned, higher performance means better sales for the company selling you the snake oil.  These are stupid tasks that we execute, and they result in higher level of friction.  More work for us, but not security as a result.  Ultimately, we just heat the climate by running more jobs on our computer without much results in terms of security.  Think antivirus running on a Windows desktop.  I'm not even saying that this is not necessary.  It's a lot of investment of electricity and CPU cycles for relatively little gain just to keep things up.  Optimal incentives mean that we get a maximum of security for a minimal investment of resources.  This is what we actually would like to get.  Ideally, we don't have friction.  That means we have incentives pointing over there.  We follow these incentives, and we get the same amount of security that we expected.  If you follow bad incentives that lead you in a different direction,  and you're a security engineer working in a blue team, so in defense setup,  then you're not doing your job properly.  Maybe without even being aware, you just follow incentives.  You're not aware that the incentives are actually leading you away from security.  If you implement the wrong incentives that fail to support the security of your users,  then shame on you because you're placing incentives so people are getting bad security  instead of what you're supposed to give them as a defense engineer.  Then shame on you.  Twitter announced a month ago that they would stop doing text message two-factor authentication for non-paying users.  Whoever tried to convince their mother-in-law like I did or somebody else to enable two-factor authentication  will realize that text message two-factor authentication is a weak form of two-factor authentication,  but at least it is a little bit of security.  So they have a relatively small, often people have relatively small security interest,  small incentive for security, but text message you can kind of convince them if you make an effort  and they get a bit of security out of this.  And Twitter or Elon scrambling for money is now stopping that.  What Elon is actually doing, he's doing A-B testing on the strength of the security desire of his users.  He presents them with a choice.  If you want security, you pay me.  And if you want to save money, then you lose security.  Or you upgrade to the Google Authenticator or other Authenticator apps.  And that is simply too complicated for a lot of people.  And I didn't manage to explain this to my mother-in-law.  So Elon absolutely made a choice by placing incentives in front of his users,  asking them to choose security or money.  This was enacted this week, so we don't have the number.  Actually, I'm also not sure we're getting to get the numbers.  However, it's perfectly clear that if you want to save money, you're going to drop security.  And if you want the security, that means more money for Twitter,  but I think it's more likely we're getting less security for users.  Shame on you, Elon. Shame on you.  Some of the examples I'm going to present here will not be quite obvious.  And I think that is a problem.  The Elon Musk and Twitter example is very obvious where the incentives are.  Here, it's not so clear.  And I have rounded up a couple of examples where we really need to think very hard.  Where are the incentives, actually?  How are we driven by them? How are users driven by these examples?  This is a Nessus report.  I have a bit of a knack for Nessus reports, and it's not a good one.  It's small print. Don't try to read this.  But it says critical security vulnerability is 44. Substantial.  High security vulnerability is 309.  So 309 high security vulnerabilities.  I think that has a strong impact.  I mean, if you read a report like that, that's a strong message.  And the incentive that you're feeling, or I'm feeling, is let's jump to action.  This is actionable.  Every critical security vulnerability here is meant to be fixed, isn't it?  I mean, you want to patch this. You want to get secure.  You want to invest a lot of time and resources,  namely, if audit is around the corner.  This happened to a friend of mine. That's how I returned on Nessus reports last week.  He was handed a 229 Nessus report by a customer.  The customer didn't care about security for several years.  Now, audit was coming back, and he, as a security consultant, received the 220 pages Nessus report.  Please fix this for us. You have four weeks.  Now, if you jump to action and start on page number one,  or after the executive summary on page number two, you're doing a bad job here, unfortunately.  Second screenshot is actually from the report my friend received.  Nessus proposes to ensure that the proxy modules are disabled on a given server.  The problem is that server was a proxy server.  So Nessus effectively tried to convince my friend,  please disable the central functionality of that server so you're secure.  I mean, this is a classic false positive. This is stupid advice.  Nessus has been around for more or less 20 years.  Proxy technology on web servers has been around for 25 years at least.  And Nessus is still not in a position to find out whether a server is a proxy server or not.  I tell you, I'm working on a proxy server. It's a one-liner. It's so easy.  If it has a back-end configured, chances are it's a proxy server.  And Nessus is not able to do it.  What is nice about Nessus is it tells you how it found out the proxy modules are enabled.  This is the second slide here. There is a command.  If you look at the command, it looks really sophisticated.  Wow, AWK and stuff. Wow, grep. That's really nice.  It's the wrong config file.  Nessus takes the default config file.  Chances are the server is running a different config file.  Nessus is too stupid to identify the real config file.  People pay money for this shit. I'm surprised.  What are the incentives here?  The incentives tell you, work through the spreadsheet.  Check off the findings and you gain in security.  This is what Nessus promises to you.  But the result is actually time wasted fighting symptoms instead of fixing the core problem.  What is the core problem here?  We have hundreds of security vulnerabilities.  We have bad policies and bad processes.  That's the core problem here.  And the individual high security finding, the server that is not patched, is only a symptom of that.  So you can run after all these symptoms, try to fix them, but you're not adding anything.  Because two weeks afterwards, you'll have new security vulnerabilities.  The processes are completely wrong and Nessus is contributing to the problem.  Nessus is not providing you with a solution.  And I'm not saying there is no job for Nessus in this game.  I think if you have a perfect setup and everything is fine,  then Nessus can come in and reassure you, yes, good job, tap on the shoulder.  Nicely done.  Nicely done.  The problem is, of course, if Nessus has to disable the proxy server, then it's no good.  So too many false positives and too much friction working through false positives.  Not good.  Next idea or example.  This is a random headline I found on the internet.  And it says that over 14 million cyber attacks are blocked daily, says a report.  If you read the small print, it actually says 14 million attacks on 1200 websites  amongst 12 billion requests on a single day by super strong sensors by some random security company.  These are not attacks, gentlemen.  These are bullets.  What is an attack and what is a bullet?  This is an industry that is not quite sure what an attack actually means.  But that is an individual HTTP request here.  So 14 million requests were intercepted.  But that's not an attack.  That's like going to war and counting bullets.  That's no point.  That is irrelevant information.  They make a headline out of this because they profit from inflating the numbers.  I mean, they place an incentive when you get action, get to work now, buy our stuff,  and it goes, wow, 14 million attacks daily detected by us.  We come to you and detect all these attacks hitting you.  But it's actually quite irrelevant.  I would be interested how many of these requests were actually dedicated attacks  by persistent threat attacking these 1200 websites.  But that information is not in the article.  And I'm pretty sure the product is not able to give me that information.  Who has an interest in inflate numbers?  Who is typically inflating numbers?  Spam detection software.  Very high number.  The more spam you detect, the better.  Bigger licenses, you can say.  There are license models around.  For every spam message detected, you get more.  So you have an interest to get more spam somehow to make money.  Firewall administrators tend to block a lot of IP packages raising the number of attacks.  It's only an IP package.  And then web application firewall operators, people like me somehow,  we have a tendency to inflate the numbers because every request that we're blocking is an attack.  And it's perhaps only a bullet.  Good.  Even bigger numbers.  Here is a report I found online.  It came out in February, I believe.  Yes, the end of February.  A site called Textury.  And they would talk about 300,000 new pieces of malware are created daily.  Yeah, this is what happens when you create them in an automatic manner.  I mean, you run and it generates malware for you.  That doesn't mean that it's going to be deployed.  This is the business these criminals are doing.  So let's take a step back and remember that security resources are always limited.  Every dollar and every hour spent on nonsense is a dollar without a return on investment.  It's friction.  It's heating up the climate, if you want.  So if you buy a license for some commercial software based on a shitty report with inflated numbers,  you're actively burning dollars in a dumpster fire.  Don't fall for such a trap.  And shame on you if you create such reports with inflated numbers consciously or in a careless way  because you think every IP package blocked is actually an attack.  So we have an incentive to gain more budget through inflated numbers.  And the result is company resources misassigned.  They flow to the highest number.  Or management stops trusting the reports.  You tell me which one is worse of the two options.  So we're getting close to dashboards now.  These inflated numbers.  Dashboards have a tendency to show you inflated numbers as well.  In fact, I've been suffering from examining too many dashboards.  Why is that?  I'm working on a dashboard myself.  I've been working on a dashboard all through 2022.  And why is that?  Because I've yet to see a decent dashboard.  I've been in this industry like 20 years or so, doing a lot of web application, firewall, web service, security engineering.  And I've never seen a good dashboard.  Here are two examples.  The top right is the infamous Norse dashboard.  That came out like 2016 or so.  It is animated.  So what you see here is IP addresses sending IP packages across the globe.  And then they hit data centers and they explode.  And it's really cool.  It's nice ice candy.  And then lots of lists.  And it's all animated.  And it grabs your attention.  And you get the feeling this is actionable for you.  This is something where you have to do something about this.  But that's not the case.  It's only show.  It's only eye candy.  Consequently, Norse died a year or two afterwards.  Nice video, but that's not security.  What you're getting here.  The lower left corner is from the Kibana documentation.  This is an example dashboard that Kibana is proposing to you.  That you should implement.  This is how you could set up Kibana to look nicely.  It doesn't have a lot of data.  I mean, it's documentation.  But you get the idea already.  I mean, the numbers are too small.  But there seem to be sparklines on top.  Then we have bars on the left.  The two very monolithic blocks.  That's actually bar charts.  And on top right and the lower right corner.  We have two donuts or modern variants of pie charts.  So the green areas on the left.  I mean, what is the information?  I mean, there's no information.  It's just a block of color.  Doesn't tell us anything.  But do the pie charts.  I'm explaining you the center lower.  The lower one here.  The very colorful donut.  It maps colors to numbers that don't tell me anything.  You cannot read the numbers.  But khaki color means 200002147.  And then the blue is 200002476.  That is the information value in this.  And this is in the documentation.  This is what Kibana is proposing for you to do.  Now, what is the idea behind a dashboard?  Why do you want to have a dashboard?  I mean, it's nice.  You can show it to management.  You can show it to your friends.  And look at all the nice numbers.  And what our servers are doing.  And all the attacks that we're getting.  Look at all these bullets flying in our direction.  The promise of the dashboard is actionable.  Actionability tells you, hey, this is the information where you get to work.  And then you improve security.  And A, I don't understand what this is telling me.  And B, there is nothing I can do based on these color blocks or on the pie charts.  I think pie charts are a really bad way usually of displaying information.  I'm in a hate relationship with pie charts.  I give you a next example.  Yeah, let's dive into this.  What is the promise?  No, I have to repeat this.  The point is that dashboards tend to give you not actionable information, but ready information.  Actionable information would be something you need to do something.  We have an imminent problem.  Focus on this problem and you improve security.  That is most of the time not what the dashboard is displaying you.  Certainly not these dashboards here.  What they're instead doing is displaying you ready information.  Information they have at their fingertips that they can easily display to you to distract you actually.  The result is distraction.  The incentive is they do you a nice dashboard and the result is you're distracted.  While you're looking at the dashboard, the attackers continue to attack you.  And you're not even seeing it because of wrong information.  Something that people in web application firewall dashboards typically show is the total number of attacks,  the total number of bullets if you want, hitting the application.  That is completely irrelevant.  Who cares?  If you have a roof on your house, do you care how many raindrops it stopped?  Are you interested in the number of raindrops stopped per roof tile?  Do you want to see the metrics of the average raindrop count stopped per hour grouped by month?  Who cares about this bullshit?  It's completely irrelevant.  Next one.  This is an element of a typical web application firewall dashboard.  It's the rule alert.  Web application firewalls work with rules.  They identify malicious requests and then they block them and then they do dashboards.  This is important.  This is what I did.  This is where you put your attention.  Obviously, the top line here must be the most important information.  The top line says we have 1,259 alerts on the rule host header is a numeric IP address.  That is where they focus your head on.  This is where dashboard proposes, incentivizes you to put your brain share.  Look at this.  This is important.  Now, as it happens, who triggers that rule?  It's misconfigured local answers using the HTTP host header.  They use it with an IP address when the RFC actually says it has to be a fully qualified domain name.  It's sloppiness.  It's misconfiguration.  If you don't like this, configure the load plans correctly.  And if you don't, nothing bad happens.  Uptime agents, same behavior, and then people scanning the internet trigger this rule.  Yes, it's an alert, but who cares?  That's not danger.  Somebody doing a cheap scan of the internet is no threat to you.  If that person is a threat to you, then you have far bigger problems.  The threat to you are those people who know how to set a host header correctly,  so they don't trigger this rule.  So what this dashboard element shows us has a lot to do with survivor bias.  Wrong incentives.  You probably know this graphic.  It's quite famous in the IT security industry.  It's a graphic of the Second World War.  This is a bomber, an Allied bomber.  And for every bomber returning from a bombing mission in Germany,  they will count the bullets and put them on the graph.  So every red dot is a bullet in a bomber who survived a bombing mission over Germany, perhaps.  If you jump to conclusions quickly, you would go,  let's improve the armor on the bomber where we have the red dots.  Isn't that natural?  I mean, this is where they have been hit.  We need to improve the bomber in these regions.  And that's completely wrong.  The point is, the bombers are already surviving hits in that area.  The problem is the bomber hit by bullets that didn't return.  And chances are, these are the bullets that hit the white areas.  Those bombers didn't return.  So what you need to do is improve the armor in the area,  but there are no red dots here.  So it's the other way around.  By focusing on the wrong information, you're following the wrong incentives.  And that's exactly the problem with dashboards.  It's survivorship bias.  It tells you what happened already, the stuff that you blocked.  It's the rain that has been stopped by the roof.  The one thing I'm interested in my roof is, where are the leaks?  I'm not interested in the rain that it stops.  I'm interested in the rain that it didn't stop, that is ruining my house.  That is the problem.  So there are two pieces of information that are really interesting here.  A, only requests that target existing service endpoints are relevant.  People scanning the internet are scanning everybody.  They're not scanning your endpoints.  What is going to happen with these requests?  They're getting a 404 most of the time.  They're not hitting your application anyway, so why do you care?  It's completely irrelevant.  They're triggering these rules on the dashboard,  but they wouldn't mean no harm to you.  They're no problem.  And B, the real danger are requests by IP addresses that have triggered alerts,  but they continue to improve their attack, and then they bypass the rule set.  On subsequent requests, they're no longer being blocked,  and then they start to hit relevant endpoints.  These are the dangerous requests.  This will be actionable.  Hey, look, this is somebody who ran into the firewall.  We blocked him on the first two, four, six attempts,  but then he got his act together and suddenly he hit the backend application.  Now we need to do something about it.  That is a real attacker.  That is a persistent attacker,  and I failed to see a dashboard ever to give me this information,  and that will be actionable and really important.  So the incentives are look at the seemingly interesting numbers  and maybe shiver in front of all the attacks on your screen,  and the result is while you look at irrelevant track record,  the attackers bypass the web application firewall, leaving no trace.  Good.  Let's talk about bug bounty hunter.  I think it's time to talk about bug bounty hunters.  Do we have bug bounty hunters in the room?  Don't be shy.  We don't have bug bounty.  Oh, there is one at the very end.  Hello, Ale.  Okay, let's laugh a bit about Ale.  Are pen testers in the room?  Yeah, there are far more pen testers.  That's one of the problems.  Far more pen testers than bug bounty hunters.  We get to you, pen testers, immediately after the bug bounty hunters.  Is that a deal?  Good.  So bug bounty hunters have been around for a couple of years.  Please appreciate the hoodie photo found.  It's one of the photos that have not been used in any sales presentations before.  I even paid money for that photo.  I like it so much.  It's so cool.  So bug bounty has been around for a couple of years, at least in Switzerland.  And we see tendencies now in the market.  There was a promise around bug bounty hunting.  I'm very much in favor of bug bounty hunting as well.  I promoted that a lot.  And now we're seeing maybe we don't really get what we expected from this new technique.  Maybe something else is happening.  Maybe it's still a net positive.  But there are definitely incentives at play here that are not in favor of security.  And you see where I'm taking this already.  The question is, are bug bounty hunters interested in security?  We said probably yes.  Yeah, that's why they work in security.  And that's certainly one of the incentives of how they start to bug bounty hunt in the first place.  And the question more to the point, are bug bounty hunters interested in securities of the companies that they are probing?  Of the programs that they're working for?  Now, ideally, yes.  However, in reality, I think the bounties are spoiling bug bounty hunters real quickly.  It's like nice people entering an investment bank.  Money spoils them really quickly.  I think after a couple of months or years, they're more interested in personal fame.  That's how red teamers work anyway.  They want to be the greatest hackers in the world.  I mean, I think that's natural for a red teamer.  So they're interested in personal fame.  Personal fame is directly tied to monetary incentives in bug bounty hunters.  Higher bounties means you're cooler than the other guy.  So it's five digits bounties that they're after.  And how do you get five digits bounties?  It's about automation of the bug discovery and optimizing.  Ultimately, it's specialization.  The bug bounty hunter has a strong incentive to specialize in certain area.  As I came to see, I have a limited vision on this.  I think it's cross-site scripting.  A lot of bug bounty hunters are specializing in cross-site scripting  because it's relatively easy to automate and it promises big payouts.  It's a growing industry, namely in Switzerland.  More and more programs pop up.  It's like mushrooms in autumn.  More and more programs.  Relatively few bug bounty hunters around.  It seems only Ale in the room is a bug bounty hunter.  So there is a high demand for bug bounty hunters by so many programs  and relatively little bug bounty hunters.  As a bug bounty program, you struggle to get them onto your program.  And then these guys are specializing in a niche or in a certain area.  And that means you get spotty coverage.  And the promise of the bug bounty was you have thousands of hackers  probing your servers and they'll have no stone unturned  and ultimately they will discover every weakness.  But what you're getting now is five professionals hitting you  with all cross-site scripting around  and the rest of your application is probably not covered properly.  Let's turn to penetration testers.  As I said, I've been in this industry for quite a long time  and I've never seen, correct me if I'm wrong,  open for feedback, but I've never seen a penetration tester kill a project.  No.  They always write nice reports.  They always have critical vulnerability findings.  But whenever I read these reports, I mean, I like these people.  I like them.  I'm really a fan of penetration test reports because it's so interesting.  I learn so much.  I can improve my setup and so on.  But I always get the feeling it's very well balanced.  The executive summary very often goes,  you've done good work so far.  However, we realize that there are still a couple of weaknesses in your application.  However, if you continue the good work, then you can make this work.  I mean, you can do this.  It's challenging, but you can do this  and then we'll come back and do a retest of your application.  So I think the backbone at the penetration tester  has a very strong incentive in a follow-up contract.  And the result is that the penetration tester will not turn every stone.  A, the penetration test is scoped anyway.  So there is a contract, but there's a post to look at.  But it's not very holistic.  It would be too expensive anyway.  And the result, based on this incentive for the next contract to be nice,  to write a nice executive management summary,  is a nice contract and a nice report  that guarantees a follow-up contract.  Penetration testers tend to call this a partnership, a long-term partnership.  But I think a long-term partnership is a nice word for follow-up contract.  Let's continue to do business because I tap your shoulder  and you give me money for it.  It doesn't mean it's not security,  but it means you'll get a limited view of the security of your online service.  The penetration tester does not have an interest to rip you apart  by telling you about things you've never heard of  and they're completely undermining the security of your setup.  You better stop working today and drop that project.  It's not how this works.  The result is again spotty coverage in the reports.  So no matter what you seem to be doing,  neither penetration tester nor bug bounty hunters  give you a comprehensive coverage of your online service and their security.  In fact, nobody can give you a substantial assessment  of the services or the security of your services.  The incentives are simply playing against you and your requirements  and only time will tell whether you're secure or not.  Good.  Let's look at the Anthem breach.  Probably don't remember that was in 2015.  That was the big E-Health patient data breach.  The incentives here in play are business.  They build bigger and bigger and larger baskets  and then they put all the eggs in the same.  The incentive being centralized, digitalized, consolidate  to get better revenue, higher margins.  However, the result is, of course, a cluster risk.  And when the database is exploited,  you lose all the eggs or all the patient data, obviously.  If you look through the newspaper article,  this one is from Wall Street Journal,  the affected products, let me quote them,  are called Anthem Blue Cross, Anthem Blue Cross and Blue Shield,  Blue Cross and Blue Shield of Georgia,  Empire Blue Cross and Blue Shield, Amerigroup, Caremore, Unicare.  These are all different brands on the markets  and they all came back to the same database that was hacked.  The incentives of business work contrary to security,  very directly here.  Now, a funny rumor is that Anthem actually had a cyber insurance  with a coverage of 100 million  and they used all that money for the notification process.  So, really bad for Anthem.  Good. Crisis communication.  The incentives are twofold.  This example came up on Monday.  Swiss pen testing company Pentagrid revealed  that Wizeka credit card company of Switzerland  had a weakness on the server.  You could look up credit card statements of companies  without being the owner of this data.  This is Heidi News talking about it.  It was popularized by the Republic,  a Swiss-German online magazine on Monday.  And for the company Wizeka, they did not communicate this.  Certainly not with the end users.  However, they also informed the banks  that are connected to this user really, really late.  So, in crisis communication, namely in IT security,  I think there are two contradicting incentives at play.  One is be proactive, be transparent about your problems,  talk about it, put everything on the table  so people can make up their mind,  and don't downplay anything.  However, the second incentive would be  is a completely different strategy.  Be secretive, be reactive, don't talk about it  and don't admit anything that they cannot prove to you.  The promise of the second scenario is  nobody will find out and no problem.  Unless, of course, newspapers start to talk about it  and then everybody will tell you,  hey, you should have been transparent from the beginning.  However, I see in Switzerland the tendency  to go with the second option so far.  And they knew media will get this pentagram  announced we're going to publish this  and they had to expect me to jump on this.  They still choose not a problem, no problem at all.  And by the way, no customer data was ever revealed  outside of a single funny user in the canton of Schwyz.  And nobody knows why that record has been leaked.  Good.  Ransomware, closely related to that.  Ransomware is all the rage.  This here is the first cryptolocker from 1989.  It's the HDOS Trojan.  Very interesting.  You had to send a check to Panama  to get the decryption key.  That business model didn't work so nicely.  In the meantime, they've replaced Panama with Bitcoins.  And that seems to work a lot nicer.  I think ransomware is interesting from various perspectives.  But one thing that I think is very interesting  is the question, do you pay or are you not paying?  Paying means the pain goes away immediately.  Downtime is over.  You can continue with your work.  Unfortunately, the result is criminals get money in their hands  and they get stronger over time.  I'm seeing them getting more and more leverage.  Ultimately, I think it will be no question  whether you pay or not.  I think the longer this goes, criminal will force you to pay  and you cannot afford to not pay in the end  over legal threats or going out of business immediately.  This question whether to pay or not becomes even more interesting  if you look at cyber insurance.  There is relatively little news about this,  but I found this Reuters article where it says  insurers say some attackers may even check  whether potential victims have policies  that would make them more likely to pay out.  If you manage to get a cyber insurance policy  covering ransomware,  that means the moment ransomware hits you,  the cyber insurance takes over.  From a criminal perspective, that is really attractive  because they get to talk to the professionals.  They get to talk to people to know how to transfer bitcoins,  the cyber insurance company.  They also don't have to do presentations  where they present their business model  and the service offerings to the victim.  From an attacker perspective,  it's very interesting to attack somebody  who knows what the shot is,  somebody with a cyber insurance.  From the perspective of the victim,  the thing gets more complicated.  That means the cyber insurance promises coverage  for your loss, for your damage,  but somehow there seems to be incentives around  that means you're probably more likely to be attacked  by having the cyber insurance,  certainly if you announce it,  or there have been cyber insurances that have been hacked  so the customer database was stolen  and there were data where they had  where subsequent attacks resulted  from the loss of the customer database.  Good.  We started 10 minutes late.  Still have time.  I'm getting to my last example now.  It also happens to be the biggest one.  Good.  This is coming back to web application firewalls.  This is like the only topic I really know anything about.  The rest here was all somehow things that sprung to my mind.  But web application firewalls,  I've been working with for many, many years.  And what is a web application firewall for repetition?  It is something you place in front of your bank,  of your online shop that does a first line of defense.  It inspects the HTTP traffic  and if it encounters something suspicious, malicious traffic,  it blocks it and stops the attack  from hitting the backend application.  It's like the first line of defense,  an additional layer of security in front of your application.  If done right, that contributes to security.  If done wrong, it's a lot of pain  without a return on investment.  My business case is making sure  you do have a return on investment.  Good.  There is a market of maybe 100 commercial offerings around globally,  including content delivery networks and online cloud services.  And there is a single open source offering,  the OOS ModSecurity Coral set,  the project I happen to run in my spare time,  co-run in my spare time.  So as a commercial vendor, you have two options.  100 commercial vendors around.  They had to ask themselves the question,  do we want to create a rule set on our own?  Do we want to build something to detect all kinds of attacks  and sell this to our customers?  Or do we integrate the single open source offering into our solution?  Two thirds of the market went with the second option.  One third of the market continues to develop their own rule set.  Now, this is a matrix based on a blog post by Tuomas Makkonen.  It's two or three years old.  And he would look at commercial cloud web application firewalls offerings.  And then vertically, he would fire attacks against them.  He would test their performance, their security performance.  And then in the columns, you have the different commercial offering.  First line, we're only looking at the first line.  Remote command execution.  Remote command execution is very bad.  If you happen to execute this and it works,  then you have a root shell on the server.  That is not nice.  You want to defend against remote command execution.  Mind you, having the WAF ignore a remote command execution  doesn't mean you have a root shell immediately.  It just means that the first line of defense failed.  You still need a weakness in your application.  So even if it's very red here, that doesn't mean you're immediately exploited.  It just means that the promise of security was not delivered.  You purchased a commercial solution and it didn't work.  First column is AWS WAF.  That's what you get very cheaply from AWS.  It has a performance of 4% of the attacks in the remote command execution category are blocked.  96% of the attacks will bypass the AWS WAF at least two years ago.  Next column is AWS Fortinet rule set.  So AWS, you can have commercial additional rule set.  The Fortinet one is two and a half times better than the default one.  Now we're up to 10%.  So only 90% bypass the WAF.  And then comes the third column.  That's a stark contrast.  Now we're over at the competition at Azure.  And in the second line, you have in brackets the core rule set.  That is my project.  Azure is based on core rule set.  They didn't develop their own rules.  Primarily, they use the open source solution and they get a green column.  Now they're up to 71.  They're seven times stronger than Fortinet by using the open source solution.  Next one is Barracuda.  That's a company that's doing their own rules.  Again, and then Alibaba.  I don't know what they're doing exactly.  But the fact that they have two green items means probably they're also based on CRS.  Somebody told me they are, but I've never seen a hard date on this.  Then you have Google Cloud Armor, 73%.  And in the final column, CloudFlare WAF, also based on CRS.  Everything green, with the exception of the Alibaba cloud, is known to be CRS  and documented as being based on CRS.  I don't know exactly what CloudFlare used to be doing two years ago  in the remote command execution category.  I think they disabled rules.  And I also know for a fact they're improved in the meantime.  So now that might be green in the meantime.  But they disabled rules.  So the open source offering gave them detection capability and they disabled it.  And that leads us to the question, why would they disable it?  And why would the commercial offerings  or the commercial offerings being based on in-house rule set  perform so much worse than the ones that use the open source offering?  Why is the open source offering stronger than something commercial?  Good. Let's look at a story that might explain this.  Once upon a time, there was a boy.  You probably know this story.  The boy was a shepherd.  Actually, he also had a ram in his shepherd in his herd for diversity reasons.  And he would take the sheep to the forest.  You know where I'm taking this.  In the forest, there was a wolf.  Very bad.  So the boy screamed, raised the alarm, called the hunters  with the idea the hunters will come, hunt down the wolf  and make mincemeat out of the wolf.  And it would be a big party in the village and everything was nice  and the herd had no problem in the future.  However, the problem is there was a false alarm.  The boy called the hunters, but there was no wolf.  Same happened the next day.  Same happened the day afterwards.  False alarms, no wolf.  The hunters gave up on the boy.  And when the real wolf struck,  the real wolf struck,  I want to show you this one.  This happens.  Good.  Coming back.  I think the story is very sad.  It's also very bad.  I think the way we're traditionally telling this story  is we're telling it the wrong way.  If you're a boy with sheep in a forest, it's really hard.  There is a lot of missing information.  The forest is dark.  It's very dense.  And the wolf is very cunning.  So you don't know.  You hear something.  Maybe you see something.  You don't know what is happening exactly.  And you fear for your sheep.  So you call the hunters,  despite not knowing for a fact.  You're not really sure.  And you don't want to wait until the wolf has one sheep between his jaws.  You want to be early.  That's why you raise the alarm.  I think the boy has very bad press in this story.  But in fact, I think the boy is in a very bad position.  And truth be told, this is my story.  As an open source developers, we're the boy.  We're raising the alarm too early.  We're provoking false positives.  And this is the cost of doing business.  Why are we doing this?  Because the incentives are aligned for us to produce false positives.  Honestly, if I produce a false positive, that's really bad.  I'm sorry for the users.  I'm sorry for the customers.  Maybe somebody was checking out an online shop and then a false positive happened.  Business didn't happen.  Company didn't sell something.  They lost money, consequently.  And they complain to me and say, look, I'm really sorry for you.  But you need to handle this.  And you have to work around this.  Here is the documentation.  Help yourself.  This is what I'm telling.  Ultimately, I'm not affected.  Or if I'm affected, it's very, very indirectly for my business.  However, for a commercial company, situation looks very much different.  For a commercial company, if somebody is not able to do business despite the product,  they will get a call immediately.  Hey, look, our CEO failed to log in to our platform today.  And he was really pissed.  And you guys need to get your act together.  Because if you don't, we're stopping to pay you for the sheep.  No, we stop to pay your license.  Every false positive is a direct threat on the business model of a commercial WAF vendor.  It's very, very bad to have a false positive for a WAF vendor.  How about false negatives?  For me, I come to a security conference.  We're going to do a coffee break afterwards.  I want people to walk up to me and tap my shoulder and say,  Hey, I tried to get past your CRS rules last week.  Oh, boy, it was tough.  I was working as a penetration tester.  They had disabled the WAF.  It was so strong.  Good job.  That's what I'm into this game.  This is what I want to hear.  The last thing I want to hear, people walking up to me,  Ha, I run a penetration test and the WAF is bullshit.  That's a joke what you're doing.  All the hours you spend in your spare time was no match for my attack skills.  That's the last thing I want to hear.  I want to make a very, very strong WAF that is not allowing for any false negatives.  These are my incentives.  That's how the open source WAF tries to be as strong as possible.  And the commercial WAF tries to get out of the way of customers.  They have a very strong incentive to avoid false positive and maybe a sack false negative.  We can, in the coffee break, explore the false negative situation in a commercial setup.  I think it's even more pervert than this, but I don't want to dive into that in the presentation too long.  So time to wrap this up or time to come back to here.  Now we have an explanation while the ones using commercial rules perform much weaker than the ones using open source rule set.  And then in the case of Cloudflare, they looked at this and realized,  Hey, this is causing too much business problems.  So let's take out a few rules of the strong open source offering.  Incentives are at play here.  And we need to look at the incentives to realize where do we get the strong product that delivers security?  And where do we get something that is a nice checkbox security?  Interesting enough, that is a graphic you don't see in the Gartner report or the Forrester WAF quadrant.  The last thing they're looking at is WAF performance.  Good. Time to wrap this up.  I see two levels of bad incentives.  An overly relaxed attitude, ignorance, negligence, carelessness leads to bad incentives for users.  They trick them into weak decisions that ultimately undermine security.  Think bad dashboards.  Eating your brain shares. Nonsense.  Because the guy developing the dashboard didn't think from your eyes, from an operating perspective,  what is actually important? What is actionable? What information is useful?  It was just carelessness.  On the second level, however, people are deliberately following or setting crazy incentives for immediate gain.  Financial benefit through bad incentives.  They're consciously prioritizing financial benefit over security of users and their data.  I see WAF vendors at play here and Elon Musk.  Shame on him.  So what do we do about this?  I think it's our job, it's your job, to raise the alarm when you see incentives that are not aligned with security.  In the projects that you're working on, you see people at the table who seem to have different incentives than the security goal that you actually have in mind.  You need to step back and think about incentives when you make your business decisions or technical decisions.  What are my incentives? What are the vendors' incentives?  What is the consultant's incentive?  What are the incentives of my boss, of the CISO, the security officer?  Everybody at the table.  And if the incentives and security don't align, then you need to cry wolf early enough.  Thank you very much.  So we started a bit later than expected, but it's almost coffee break.  Can we take one or two questions? Ale?  One question.  Of course.  Of course.  There is one question at the end, at the back.  Yeah, I've actually got a comment, not really a question, because you showed us the WAF comparison stuff.  Yes.  I personally don't really believe about WAFs, but yeah.  So we are seeing this comparison between WAFs.  The problem is I look at the blog post from the guy who posted it, and there is no reproducibility in it.  Yes.  So if we are doing such research, please, well, post your scripts that you are doing the research with and getting the results out of.  Because otherwise, how can we really know whether this thing that we are seeing here is actually, you know, good or not?  Like, if you look at the examples they used in this research, they, for example, sent to some, like, an application hosted on AWS, beyond one of the WAFs there, some payload that is, you know, a command injection payload for, like, PHP applications.  But what if your app is not really PHP?  Then they marked it as, you know, false positive or whatever.  Like, you're not detecting this.  And is that, you know, good?  Probably not.  And if you would, like, post or, like, publish your research, like, how did you do this?  Then people can also, you know, improve.  Yeah.  Point taken.  I mean, Tuomas Markon should have published the test scripts he used for this.  He didn't.  The reason I'm using this is because he's third party.  I can reproduce this.  I'm getting more or less the same results for these tests.  But I'm obviously biased.  Nobody would trust my numbers.  So at least he's third party.  Actually, if you reproduce this, you can also...  No, I'm biased.  I mean, I'm the wrong person to do that research.  You should do the research and publish your results.  I mean, nobody will trust my results anyway because I have skin in the game.  Obviously, I'm the wrong person.  But somebody should do this properly.  He just happens to be the only guy who did a comparison.  And I think, I mean, Gartner and Forrester should do that research.  I mean, that's what they're selling anyway.  The last thing is a comparison of the performance of the products that Gartner and Forrester are covering.  They're looking at nice dashboards and stuff and machine learning, artificial intelligence.  But ability to detect an eschol injection is no criteria for them.  I think they should do that research.  Thanks.  Any other questions or remarks?  Yeah, there is one.  Thank you.  I mean, if I'm not getting any bad feedback for this presentation, then I will be disappointed.  I wasn't aggressive enough.  I got this feeling after this presentation that we cannot trust commercial vendors somehow.  Because I'm also working as a security engineer and we constantly check for new vendors.  Starting from WAF to static code analysis, dynamic code analysis.  And, you know, there are different vendors and they try to sell you like, oh, how great we are.  But here we see that it's always the money is a huge incentive.  And how or what would be the good way to differentiate, to really understand.  Are they really interested in giving us a good security product?  But rather than just keeping us, you know, on a three-year deal and then after that and so forth.  Yeah, honestly, I think I have very strong negative opinions on that.  As you've heard, I'm an open source enthusiast.  And I'm always in favor of make up your mind yourself, get knowledge.  And then you look at the product, evaluate them.  But maybe not everybody can do that.  And maybe it's not as negative as that.  But I think what is definitely worthwhile is looking at incentives.  Just take a step back and take a couple of minutes.  Why are they doing this like that?  Why is a spam detection software selling me a license on the number of spam detected?  Why is a log platform selling a license based on the lines of logs that they're logging?  So their incentive is obviously to log more.  But is that security?  I think that when you look at these deals and offerings, try to understand their incentives.  And then you see, hey, look, no, they have the right thing in mind.  And we know this company for a couple of years.  It's a good partnership.  Yes, we do follow up contracts, but we really benefit from this.  Or do you see, hey, they just want to sell a license, shiny leaflet.  And yeah, I'm probably not the best partner to talk about these questions because I have a very negative view on that.  But ultimately, I'm only a security consultant myself.  So I have my own incentives to pay my bills.  Other questions?  Is there a demand for coffee in the room?  Oh, yeah, please.  I have another comment.  So regarding pen testing stuff and the incentive of cash and not giving you a negative feedback because we want to work with you or something like that.  An interesting aspect of that is that when you have an adversarial pen test or an audit or something like that.  So you as a company pay another company to audit not your software, but another software.  And that's a really nice situation to be in, doing such an audit.  But that's not an option.  Yeah, and I haven't been in that situation.  But true, then suddenly the incentives shift.  I think that's an interesting proposal.  Good.  So let's go for the coffee then.  Thank you for your attention.


url: https://www.youtube.com/watch?v=x609c-MUZ_g
title: Breaking And Fixing Azure AD Device Identity Security by Dirk-jan Mollema
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=x609c-MUZ_g",
    "title": "Breaking And Fixing Azure AD Device Identity Security by Dirk-jan Mollema",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCGdJZb8OWZPrRK8PuEeoZuA",
    "duration": 3255,
    "channel": "scrt.insomnihack",
    "uploader": "scrt.insomnihack",
    "upload_date": "20230411"
  }

  This text was transcribed using whisper model: large-v2

   Good morning, everyone. Happy to see so many of you here. I'm glad to be here. Before we  start, a little intro about me. So, my name is Dirk Jemollema. I am from the Netherlands.  I've basically been in security for about almost seven years now. And last year, I started  my own company where I do a mix of research, consultancy, and also giving training since  this year. I've given talks at various conferences, like at DEF CON, et cetera. And most of my  research I actually do by writing tools. So, I try to figure out how protocols work, how  things all work together. Then I write a tool about it. And I've written several tools on  Active Directory and also more on Azure Active Directory the last few years. I have a blog.  I have a Twitter account. So, if you want to follow my work, then you can do that there.  And so, what we're going to be talking about today is about Azure AD device identities.  And it's structured a bit like first explaining what device identities are and why they are  important. Then on the technicalities, like how does a device get an identity? How does  that flow work? And then we get into all the tokens. So, we'll start talking about primary  refresh tokens, how these are protected on modern Windows versions, and all the issues  that I found in the implementation, and also how Microsoft resolved these issues. And also  some scenarios that I found that could be a different option that you have to abuse  this. So, just before we start, a little bit on terminology. So, this talk is really about  Azure Active Directory. So, it's not about Azure as a cloud infrastructure provider.  It's not about virtual machines, et cetera. But it's really about the Azure AD identity  platform. And the identity platform is for Microsoft 365, also Azure Resource Manager,  or basically any other app you want to integrate with it. So, this is kind of the follow-up  from on-prem Active Directory, but it's really the identity part and not about cloud resources.  So, all of this is quite important in the whole zero trust architecture, even though  it's a bit of a buzzword. If you look at the architectural overview of this, you see that  there's some components involved. And of course, on the left top, you see user identities,  because this is a very identity-focused security platform. So, user identity is very important  with multi-factor authentication and other verification means. But you also see device  identities. So, device identities is what we'll be talking about today, and also how they tie  in with this whole security policy enforcement and the whole zero trust strategy, basically.  So, a device gets an identity when it's either registered or joined to Azure Active Directory.  And that can be a large range of devices. So, there's different scenarios,  some different differences here. But basically, you could have a mobile operating system  or a desktop operating system that is basically registered or joined to Azure Active Directory.  And then the device identity exists as an object in Azure Active Directory.  And optionally, you can manage this device by using Intune, which is Microsoft's mobile  device management solution. Or you can also use some third-party MDM if you want.  Now, in Azure AD Security, you have various options to really secure your infrastructure.  And if you're looking at the strictest way that you really want to enforce people in your  organization to only sign in from trusted devices, then you'll be joining your device  to Azure Active Directory. You make sure that it's managed by an MDM such as Intune. And Intune  applies all kinds of policies to devices. So, it manages the settings on the devices,  all the configuration of the devices. And by applying the policies and checking if the  settings are all correct, the device becomes compliant. And then people use conditional  access policies to basically restrict access to resources such as SharePoint to only corporate  compliant devices. Of course, in this part, then it's also important to ensure that any  device that people use is also really a corporate device. So, we're also looking at that they lock  down basically the environment by enforcing that you can only enroll devices that are trusted. So,  they were purchased by the company itself and not just any device that you bought somewhere on eBay,  for example. So, in Intune, you can set this as enrollment restrictions. And in the scenario  that we're researching here, Intune has been configured to block any devices that were not  part of the organization. So, to give an overview of the research scenario using Windows 10 here.  So, Windows 10 or 11. So, modern operating systems. Also, in the setup, we'll be using Autopilot,  which is basically a way to ensure that devices are pre-registered already when you purchase them.  So, you basically purchase the devices and they automatically become registered in your tenant.  And then you know that the device that you purchased is the actual device that's accessing  the resource, basically. We're locking down personal devices. So, Intune doesn't allow us  to just register or join any device. And we require device compliancy with conditional access.  And also, we have a protection of hardware protection of secrets by using a trusted  platform module. So, it's basically the most lockdown scenario that you can have.  So, when I started this, I had a couple of research questions. And first of all, so how are devices  actually joined to Azure AD? And how are the secrets that are involved actually protected by  hardware? And of course, if we know how it works, then we can also look at if it's possible to  extract these secrets anyway, even though they should be hardware protected. And if it's possible  to bypass the device compliancy requirement, because of course, as an attacker, that's quite  interesting to know. So, let's start by looking at the device join flow.  And basically, the device join flow, if you have a device that was pre-registered using autopilot,  then you'll typically set it up by when you install Windows, basically. So, it'll ask you  for your corporate credentials, and then it will attempt to join it to Azure AD. You can also do  this after the device was already set up. But basically, the flow is similar, just a different  way to initiate it. So, on this screen, you would sign in with your account. You would do  multi-factor authentication to validate that it's really your account. And then in the background,  it initiates basically a technical flow. So, the device will generate two public-private key pairs.  The first one is the device key, and the second one is the transport key. And these are asymmetric  cryptographic keys. And a lot of the communication in the protocol, as we'll see later, is based on  these cryptographic keys. And the public keys in this instance are sent to Azure AD. And of course,  the private part of the key that remains on the device itself. So, Azure AD can basically validate  that the device processes the private key by checking it with the public key that's registered.  So, when the device registers itself or joins itself, it sends this request. It's just a  HTTP post with some JSON in it. So, it's not super complex in this case.  And just focusing a bit on the components, the first one we see is an authorization header. So,  this is the header that actually contains the access token for the device registration service.  So, first, the user requests a token by signing in. And then it sends this request to the device  registration service to actually register the device. So, it authenticates the user doing  the registration. It sends a certificate signing request. So, basically, the device is asking Azure  AD, okay, I have these keys. Can you please issue me a certificate that I can use to identify my  device later on? It also sends a transport key. And so, this is the public part of the transport  key. And that's basically a key that's used to provide additional encryption of any communication  between Azure AD and the device. It also sends some properties. So, it will say this is the OS  version. This is the device type. So, obviously, this will be different depending on the operating  system. And it also shows the host name of the device. Those aren't actually validated. So,  if you're doing this yourself, you can put here whatever you want. It's just the registration  that counts, basically. The join type is in this case zero. So, zero means Azure AD join.  There's different values if you're doing an Azure AD join, an Azure AD registration,  or a hybrid join, for example. So, these are all different numbers. And lastly, there's this  device ticket. And basically, we'll get into that later. But it's not strictly  required. So, if you're registering a new device, you can also leave this out.  Now, it sends this post request. And then it gets a response from Azure AD.  Once again, it's relatively simple. It's just an object containing basically the certificate  on the top. So, this is the signed certificate by Azure AD that the device can use to authenticate  itself. And on the bottom, you also see some membership changes. So, for those who are familiar  with Windows and how it structures local groups, this is the security identifier of the local  administrators group. And basically, this is saying, okay, you're now joined to Azure AD. So,  these users should be local administrators on the device. And it's doing that by passing some  security identifiers in there that the device will put in the local administrator group so that  Azure AD accounts that have an administrative role can basically manage the device.  So, after the device is joined, we can see the status of the device so that you can do with the  dsregcmd commandlet. And that basically will show that the device is Azure AD joined. It will also  show the device ID. So, that's in the middle here. It will show the thumbprint of the certificate.  And also, something that's interesting is that it says the key provider. So, that's where the  private key basically is stored of the device certificate. It is the Microsoft Platform  CryptoProvider. And it also says TPM protected, yes. So, this basically means if it shows the  Platform CryptoProvider is that Windows is using the additional security of a trusted platform  module to protect this private key. And it's not stored in software somewhere that's  attackers could extract it. So, the idea of a trusted platform module is that it's basically  the trusted platform module itself. It has some private cryptographic keys. And if you generate  keys inside a TPM, so if you generate private keys there, the key never leaves the TPM except  in an encrypted format. So, the idea is that even if you like as an attacker has control over the  whole operating system, because the private keys are actually stored in the TPM or they're at least  tied to the TPM, then you cannot steal these keys. And basically, if the operating system wants to  use the keys, it asks the TPM, hey, I want to perform this key operation. So, for example,  it wants to perform some encryption or decryption or signing, it asks the TPM to do that for it.  And the TPM basically gives back the result to the operating system. So, then even if the  operating system itself is compromised, you wouldn't be able to extract these keys because  they're TPM protected. And Azure AD uses this quite extensively to protect sensitive key material.  So, after the device join, then the user can sign into the device. And basically, it signs in using  their Azure AD username and password. And then the Cloud AP module in LSS, which is the module  responsible for doing the authentication towards Azure AD, issues a primary refresh token. And a  primary refresh token is a specific credential that the device can then use for a single sign-on.  So, let's have a look at the flow there. So, the primary refresh token flow starts off by  requesting a challenge. So, this is quite common in many of these operations. So, to prevent  replay attacks, they always ask for a challenge or a nonce. And the nonce is basically this  encrypted string that isn't truly a nonce because you can use it multiple times, but it does expire  after five minutes. So, if you do a cryptographic operation with this nonce, then five minutes later,  you wouldn't be able to do it anymore because the nonce basically expired. So, it first asks for a  nonce, and then it sends some signed data to the server. So, here we see something that looks a lot  like a JSON Web Token, and it is a JSON Web Token. So, basically, it's sending a request to Azure AD  saying, okay, I want to perform this action, and it's sending that as like a signed request. So,  this token is actually signed with the device certificate so that Azure AD can basically  authenticate that it's a real device doing the request. And if we look at the data content,  because we can just decode it as it's a normal JSON Web Token, we can see that there's first the  request nonce. So, it took the request nonce that it received from Azure AD, and it put that in that  signed data content. And it also puts the ground type as password with the plain username and  password in there. So, basically, when you authenticate on the Windows login screen  on an Azure AD joint device, it just hands over that username and password to Azure AD  via this basically signed JSON Web Token.  All right. So, the reply from Azure AD, if the password is correct, of course, will be this  primary refresh token assurance. So, it says refresh token, but this is actually the primary  refresh token that you get. Now, a primary refresh token, the token itself is not super  secret because it's sent during various requests. But the thing that makes the primary refresh  token very sensitive is especially this session key. So, you always need this cryptographic  session key to prove that you actually possess this primary refresh token. So, the session key  here is sent in an encrypted format, encrypted with the transport key, so that only the device  itself can decrypt this key and then basically obtain the plain text transport key. We also see  that it expires in two weeks. It's actually not true. So, primary refresh tokens are valid for 90  days, but it still says two weeks, and Windows also thinks two weeks, but they're, in fact,  valid for 90 days. Now, this storage key or this session key at the bottom, that's the interesting  part because you need this to actually use the primary refresh token, which makes it very  similar to like a Kerberos ticket granting ticket because then you also need the session key to  use it. And how this all works with the TPM is also quite interesting. So, the TPM basically  is quite a small chip, so you cannot store 100 keys in there, but the TPM has basically a root  storage key that's stored in hardware, and then any additional keys such as storage keys that  you can use to store encrypted data, they can be stored on disk, but they're always stored in an  encrypted format. So, the transport key that the device generates is actually a storage key in TPM  terms, and when Azure AD issues a session key, it will encrypt it with the public part of the  transport key. So, basically, that means that you can only decrypt this key in the TPM, and you  cannot use it in the OS, so the OS never gets access to the plaintext session key, but it can  only be used by loading this transport key, which is a storage key in the TPM, and then asking the  TPM to do certain operations with the session key. So, that's basically how it's tied to the TPM  over these different requests. So, just to summarize this, there's the private key of the  device certificate, there's the transport key, and the session key, and these are all tied to the TPM,  and the operating system can use those keys, but it shouldn't have access to the plaintext key  material. And the operating system then gets this primary refresh token, and that can be used  to perform single sign-on to Azure AD resources. So, just looking at how this PRT is  used, and what we can do with this from the endpoint, so there's basically quite some attacks  that you can do if you are on a system as an attacker that has a primary refresh token. So, similar  to how single sign-on works in on-prem AD cases, as a regular user, any process can  basically request data for single sign-on purposes. So, it can just say, hey, I want to sign into this  app, please give me some single sign-on data. So, a regular user can request to use this primary  refresh token by asking LSS nicely, basically. Of course, if you're an administrator, or if you're  a system on the device, then you can also dump the LSS memory, and you can also steal the primary  refresh token in the session key, but not if it's protected by TPM. So, if there's no TPM,  then all the things will be stored in software, basically, and you can dump the plain key,  but if it's stored in a TPM, then you cannot. Even if there is a TPM, then as administrator,  of course, you can still interact with the PRT and the session key, and you can just ask  the TPM to basically perform the cryptographic operations for you. So, we'll look at that in a bit  as well. There's basically two ways that Windows uses PRTs, maybe more, but there's two ways that  I'm aware of. So, for native apps, they'll actually ask the web account manager, which is a token  broker component, so that handles all the authentication for the apps, and the apps don't  need to worry about it. And this token broker basically passes the request onto LSS, and LSS  then will ask for tokens using the primary refresh token. There's also a way to do single sign-on  in the browser. So, then the browser will basically ask LSS for a specific header that it can use when  authenticating, which is kind of like a PRT cookie. So, it will ask LSS for that cookie, and  it will inject that in any authentication flow, so that Azure AD can see, okay, this is a device  that has a PRT, so I can use this for single sign-on. So, as attackers, there's multiple ways  that we can actually do this. So, there's some links here about two different approaches, one  by me, one by another researcher, about how you can request this single sign-on data if you are  running on the operating system as a normal user, and then you can steal this single sign-on data to  perform the sign-on somewhere else. So, that's as a limited user. And as an admin, I work together  with Benjamin Delphi basically to create an update for Mimikatz that can do this. So, here you see  that Mimikatz can dump the CloudAP module in LSS and basically extract the primary refresh token  from there. So, imagine that we are dumping such a primary refresh token, so now how does  the authentication actually look with a primary refresh token? And so, I already mentioned shortly  the PRT cookie, so that's what browsers use to do single sign-on to Azure AD with a PRT,  and that's basically a JSON web token, so it will contain a header, a body with some claims,  and a signature to prove that it's authentic basically. And in the header, we see first  there's a CTX, so that's basically a cryptographic nonce that it uses. There's also the refresh  token itself, so this is the primary refresh token that it's using to authenticate, and then there's  also the request nonce. So, once again, this flow uses this request nonce to prevent basically this  from being replayed after the nonce has expired. And then, of course, we also have the signature,  so it basically uses the session key to calculate a signature, and that's used to sign this JSON  web token, and Azure AD can then validate that it was all done correctly. So, the technical parts  of this signing flow, so this is the simplified version if it's imagined that it's a software-only  key. So, the OS basically generates some random bytes. This is called the context, and it uses  this for the cryptographic operations, and it puts these random bytes in a key derivation function  together with the session key to calculate a derived key, and this derived key, so this will be  a different key for each random context that's generated, is actually used together with the  primary refresh token with the nonce from Azure AD to create this PRT cookie signature.  So, it basically calculates a new key for every request. So, this is the simplified version.  Now, if there is a TPM involved, then the flow looks slightly more complicated. So, basically,  because the session key is not in the operating system, but it's in the TPM, and only the TPM  can basically perform crypto operations with it, then the operating system will generate these  random bytes, then it will ask the TPM to do the key derivation, and then the operating system gets  this derived key, and that it can combine with the primary refresh token with the nonce to create  this PRT cookie. Now, there is a bit of an issue with this. So, if you look carefully, you see  that the only thing that goes to the TPM is basically these random bytes, so the cryptographic  context. So, if you are an attacker with access to the LSAT process, then you can basically perform  like a lot of pre-calculation attacks. So, if I just give a lot of random bytes to the TPM,  it will generate a lot of derived keys for me, and because these derived keys do not expire,  they don't have an expiry, they're just based on random bytes, basically, then if I have access to  the operating system, I can just pre-calculate this and then use these keys whenever I want  without even needing the session key. So, there's quite a flaw in this, and you can use Mimikatz to  do this. So, if you load the session key, basically, so in this case, it's protected by the  TPM, Mimikatz will generate a context for you, so these random bytes, and then it will give you a  derived key, and that derived key is actually used to calculate the signature. So, if we use  some tools that are part of my RoadTools framework, we can basically authenticate  by using this, creating a PRT cookie ourselves, and then providing the PRT context and the  derived key that belongs to it, and then basically generate our own cookies at runtime,  and basically, whenever we want, we can authenticate using the single sign-on data  without actually needing access to the TPM. So, the TLDR of this, of course, if there is  no TPM at all, then you can just steal the primary refresh token, including the session key as an  attacker. If there is a TPM, then you could still acquire combinations of contexts and derived keys  that could allow you to use the PRT without actually having access to that device.  If you want a longer version of this, it's in my blog here. So, there was quite a flaw with this,  of course, and Microsoft responded to that by basically changing the behavior of this.  So, they made some changes in the whole PRT signing flow. They also changed the storage  mechanism, which broke the CloudAP functionality in Mimikatz for a while. Nowadays, it's working  again, so you can dump the PRT again in Mimikatz, but you cannot do the new version of the key  derivation function. So, if you find blogs about this that are explaining how to do this,  then some of them may be outdated and not work anymore. And basically, in the updated PRT  structure, we see this added field, which says KDF version 2. So, that uses a new  key derivation function to basically calculate these derived keys.  And if we look in the documentation, then they basically changed it so that they don't just put  like these random bytes called the context to derive the signing key, but they actually  use a sha256 hash of that context plus the body of the JSON web token to calculate this derived  key. This is documented. I actually only found out it was documented after I reverse engineered it  all, so I could have saved myself some issues here by reading the documentation. But basically,  if we update this graph, then now it first takes the nonce from Azure AD, so that's something that  expires after a few minutes. It combines that with the primary refresh token, and it uses that  to create the JSON web token body. Then it combines that with these random bytes, and then it takes  the sha256 hash of this whole thing, and that's called the KDF context. And the KDF context is  actually used in the key derivation with the TPM to get this derived key. So, you see that because  it now includes this nonce, which is time bound, so it only works for a few minutes, then you can  no longer do this pre-calculation and pre-calculate these derived keys to use at later points,  because you will always need to have a recent nonce, and the nonces are controlled by Microsoft,  so you cannot create those yourself, basically. So, this was patched with this CVE number,  and basically the new method prevents you from pre-calculating these derived keys by putting  the nonce as part of the key derivation function. And they also prevented you from downgrading the  key derivation function, so I assume it's stored somewhere in the PRT, which key derivation  function was used when issuing it, so that you cannot simply remove the header and then use  the old calculation. So, this is fixed quite well. So, some other scenarios, like there's more stuff  we can do. So, of course, there's some downsides to what we've discussed previously. First, you  need to be admin on the device, you need to dump LSAS, and dumping LSAS is something that a lot  of EDRs are very interested in, so it's quite noisy if you're doing it as an attacker. If it's  stored in the TPM, if it's modern security protected, then you can no longer steal it,  you can also no longer pre-calculate these things. And of course, if the device is disabled, then any  primary refresh tokens from that device are also disabled. So, I wanted to come up with a new way  to do this. And basically, it combines some knowledge of the two previous parts. So, I looked  at, because we know how the device registration flow works, we can basically emulate that ourselves,  and we know how to get our own primary refresh token, and we know how to get access tokens for  the user by using single sign-on. So, I thought, okay, so if I can get a single sign-on token from  the user session, can I also get a single sign-on token for the device registration service?  And it turned out that's possible. So, you can first initialize this single sign-on flow,  and that's basically done with a small tool that's called rowtoken. So, you give it the  nonce from Azure AD, and then it will calculate this XMS refresh token credential, which is the  signed primary refresh token that browsers use. And then you can get a token for the device  registration service with rowtx, which is a tool I wrote to exchange tokens, basically.  So, you see it asks a token for the DRS. So, DRS stands for device registration service. So, it  asks a token for the device registration service, and it uses this PRT cookie to authenticate the  request. And this will give you an access token that can be used to register devices.  And then you can register the device. So, this is an older proof of concept that I  wrote. Nowadays, this is all in rowtx. But basically, this performs the device registration  flow, and you see the result here that contains the certificate of the device and also the SIDs.  And basically, this gives us a device certificate with private keys that we  control because we generated them on the fly. And this certificate can be used to, like,  pretend that we are a real device towards Azure AD. Now, once we have this, we can get a primary  refresh token. And for that, because it emulates the flow on the sign-in screen, we only basically  need the password. So, we send the user's password to Azure AD, and we get back a primary refresh  token. We authenticate the request by using the device, and then we get back a primary refresh  token and the session key that also belongs to the primary refresh token. So, this is no longer  protected by any DPMs, but we now have this on disk, basically. So, we can use this PRT and  this session key to sign in. So, this is just to get an access token. There's also features in  RoadTX that allow you to use this in an interactive flow in a browser. But basically, we authenticate  with this PRT. And if we look at the token, then we see that we got an access token, which not  only contains the password claim, but also the MFA claim. So, that's quite an interesting scenario  because we never did any MFA for this user, but just because we registered, basically, the device  with a token that already included an MFA claim, because the token originated from a device on  which MFA was done, then the tokens we get after with our registered PRT also contain an MFA claim.  So, this is basically a way to extract these tokens and to steal tokens with an MFA claim  without ever doing MFA for the user. So, to summarize this, we can request single sign-on  tokens from a user session without any admin privileges. These access tokens contain an MFA  claim. If you use this to register a device, then any PRTs you request with that device that belong  to the same user also inherit this MFA claim. And you only need the passwords to get a PRT.  If you have ADFS, you could probably also do this only using single sign-on, but that's not something  I've researched. So, basically, this is a free MFA upgrade from your token because we only use  the password to actually get the PRT. So, this also has some upsides and downsides.  So, because we registered a new device, it's basically a separate device. It's not a real  device. But if the old device is disabled, then the PRT from our new device will still work.  Of course, the downside is that this requires permissions to register devices or join devices,  which is not always allowed. You can lock that down in Azure AD. And this also doesn't mean that  the device will be allowed to enroll in Intune because we registered a new device, which is not  known as a corporate device. And if we need to access anything that's protected by conditional  access to only allow compliant devices, then basically it won't work. So, this doesn't cover  our full scenario goals. So, for the last step, looking at bypassing Intune restrictions.  And basically, this is another dive in how these Intune things work. So, something to consider is  when you enroll a device in MDM, that's actually a different process from registering the device  itself. So, if you look at this from a user perspective, they only enter their credentials  once and then the device will first register itself and then enroll itself in MDM. But that's  not how it works under the hood. So, it's two different registration requests. And even if you  block non-corporate devices in Intune, you could still register or join the device in Azure AD  because this is something that's separately controlled. If you do this in Windows,  then if Windows sees an error, so if it sees it's not allowed to enroll the device in Intune,  it'll automatically roll back the Azure AD registration as well. But if you do it yourself,  you can just do those separately and you can still register or join a device even if you're not  allowed to enroll it in Intune. Of course, this doesn't really gain you anything because the goal  of conditional access... The goal of this was to bypass conditional access policy to require a  compliant device state. You only get that by enrolling it in Intune. So, by just joining  the device, we cannot meet this compliancy. So, some more digging into this. So, there's a few  interesting parts here. So, if you're using Autopilot, basically the devices are already  registered in your tenant based on their hardware properties. And if you wipe those devices and  register them again, then it will reuse like the same device ID in Azure AD. So, my question was  so how does Azure AD actually know that this is the same device? Like if I wipe this laptop  and I register it again, it will use the same device. It will override the same device and  it will know that this was like a pre-registered device. So, that's the part that comes into play  is this registration request again and especially this part on the bottom.  So, this is actually a device ticket that proves to Azure AD which device it is.  So, of course, I was wondering, okay, how is this structured and where does it get that? So,  how does it do that? And also, like if you reuse the same parameter, it will always override the  device. So, this is apparently something that is really tied to the device and it knows the device  hardware based on this ticket. It does seem to expire after a certain period of time. So, it's  not something that's like fixed or something. So, it is some device tickets for your device,  but it's not related to Azure AD basically. So, we did some reversing of this which was quite  annoying because the registration flow is a web-based app. It uses the WinRT framework and  it also calls WinRT APIs which means that it's doing some inter-process communication. So,  it actually spawns a different process to do the registration than the one that  does the app. But eventually, there will be a DLL host that actually spawns with the DLL in there  that contains the registration logic. So, once I found that out, I just looked into reversing this  and I basically found this string. So, it's probably a bit small to read, but you can see  that it instantiates a class of the Windows security authentication online ID, online ID  service tickets request. I was like, okay, what is this? I've never heard of this, but it's  documented. So, the online ID service ticket request basically to sign in a user or device  to the live endpoint. So, that's also what you use for Microsoft accounts. So, apparently,  your device has its own Microsoft account that it uses separately from any Azure AD  or Intune registrations and it uses these APIs to ask tickets for that account.  So, your device has its own Microsoft account. This is also what it uses for licensing checks  and such. And when device-specific authentication is needed, so when it does the device identity  authentication, then it uses these tickets to prove its identity. These tickets are cached  in the registry, actually in the current user registry hive. So, any tickets that were used  in your user session, you can query from here. They are DPAPI protected, but the protection is  tied to the machine. So, any user on the machine can decrypt them. And basically, you can just  enumerate these using PowerShell. So, by enumerating these keys and then basically decrypting them,  we find this token. So, here we see also the token scope is the enterprise registration  with Windows.net. So, it's a device ticket for the device registration.  Now, of course, these cache tickets are nice, but like I said, they expire after a certain time. So,  if the device registration was done a long time ago, then these cache tickets are useless.  So, I did some more reversing and found the exact WinRT API calls that were needed.  So, there's this endpoint involved that it asks the ticket for, and there's the app GUID that's  used for registration. And basically, when you know all these parameters, you can write a very  simple .NET program, which basically creates such an online ID system authenticator request.  And it asks a ticket for the enterprise registration of Windows.net. It sets the  app ID to the same ID that Windows uses, basically. And then it requests this ticket  from the system, and it prints it to the console. So, if we compile this and we do this, then  basically we get this device ticket that contains the device identity. And with this ticket,  if we actually do the registration again, but now provide this device ticket, then we will  actually override the old device. So, if you use the Rotex device module and you specify the  device ticket that we obtained from the Windows host, basically, then it will override this old  device. And now we have a device that we control, which has the same ID, but we have the keys  actually stored on disk instead of them being TPM protected. So, you also see that, like here,  a registered device, and you see the device ID is the same device ID than what Windows reports  on the old device. So, you can just request a device ticket from a low-privileged session,  and then override the old device. And the nice part is that the device basically retains the  original properties. So, before they basically changed this, then it used to be that even if  you overrode the device, it was still considered compliant. And any sign-ins you did using this  stolen device identity would also be considered compliant. So, you could steal that, and  basically, the original device was no longer working properly, but you have the device as  an attacker, and the Azure AD still considers any tokens issued to that device compliant.  So, just to summarize this, any user that had a session on this device could request this device  ticket, which could be used to override the device. If it was pre-registered using autopilots,  then it will do this hardware matching and actually override the device based on the ticket.  It overrides the device in Azure AD using, of course, our own cryptographic keys. So, if we  request any tickets after that, then we can just decrypt the session key using our own transport  key instead of it being tied to a TPM. So, in this case, you don't need to steal any PRTs from  LSS. You don't need to worry about TPMs, and actually, you don't need any administrative  privileges at all because you can just request this from a normal user session.  Some bonus features. So, you could use any identity to override the device. It didn't  necessarily have to be the original user that was using the device. The device ticket also  stays valid after wiping the device. So, if I steal the device ticket, I wipe the device  because it was compromised, for example, then I could still use that device ticket somewhere else.  And if you use a new account to override 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 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 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 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 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.


url: https://www.youtube.com/watch?v=SfBj0xnd_XI
title: Targeted Social Engineering Attacks: Weaponizing Psychology by Christina Lekati
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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.  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.


url: https://www.youtube.com/watch?v=1cNjYx_kSdM
title: Turn And Face The Strange: Ch-Ch-Changes In Ransomware Techniques by Lindsay Kaye
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "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 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 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 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 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 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 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 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 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 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 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 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,  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 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 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 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.


url: https://www.youtube.com/watch?v=UIreUeVrczM
title: A Ticket Worth Waiting 65 Years For by Charlie Bromberg
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "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 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 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 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.  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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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.


url: https://www.youtube.com/watch?v=x-FD8YbygYU
title: Hacking Harms! Measuring The Impact And Harm From Cyberattacks by Emma Raffray
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "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 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 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 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 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 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 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 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.  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 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 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 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 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 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 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 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 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.


url: https://www.youtube.com/watch?v=vTnEehai3lE
title: Modern Adventures With Legacy Protocols by Yannay Livneh
type: video
author: scrt.insomnihack
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "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, 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 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 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 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 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 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 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 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 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, 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. 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. 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 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 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 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.


