# Media

url: https://www.youtube.com/watch?v=hJD18w7UFoQ
title: How to Play Offlane like an IMMORTAL - Advanced Offlane Guide Dota 2
type: video
author: BalloonDota
ingestion_date: 2024-09-12
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=hJD18w7UFoQ",
    "title": "How to Play Offlane like an IMMORTAL - Advanced Offlane Guide Dota 2",
    "description": "Immortal Dota 2 coach teaching you how to master the Offlane role and climb in your brackets easily using a student's progress that climbed from 2k to 3k MMR quickly by understanding fundamental concepts taught by the coach to him to perform like a 6k MMR Offlaner consistently as an example.\n\nEnjoy learning about Offlane from this video, thank you!\n\n-------------------------------------------------------------------------------\nBALLOONDOTA COACHING RATES \n-------------------------------------------------------------------------------\n(Short term coaching)\n50$ for 1 hour\n120$ for 3 hours (25% discount, 40$/hr)\n\n(Long term coaching) \n(recommended for cheaper rates)\n350$ for 10 hours (30% discount, 35$/hr)\n650$ for 20 hours (35% discount, 32.5$/hr)\n850$ for 30 hours (45% discount, 28$/hr)\n\n-------------------------------------------------------------------------------\nDOTA COACHING BY BALLOONDOTA\n-------------------------------------------------------------------------------\nFiverr coaching link: https://www.fiverr.com/yongy146/help-you-improve-in-dota-2-with-7400-mmr-coaching\nDiscord: BaLLooN#5243 \nDiscord Server: https://discord.com/invite/w4PWyXDV4n\nPaypal: siahcheonyisiahcheonyi@gmail.com\nPatreon: patreon.com/BalloonDota\n-------------------------------------------------------------------------------\n\n00:00 - Introduction\n00:42 - Starting Items\n1:01 - Bounty Rune Contest\n1:20 - Laning Phase \n2:34 - Laning Phase Power Spike\n3:29 - Lost Lane (Recover)\n3:57 - Cleanup Kills\n4:25 - Early Game Phase\n5:05 - Principles of DOTA\n6:19 - Early Game Phase Power Spike\n7:08 - Mid Game Phase\n7:35 - Closure of Games\n\n-------------------------------------------------------------------------------\n\nCinematic Rock Hip-Hop by Infraction - No Copyright Music\nMusic Link: https://www.youtube.com/watch?v=iuJKYervYPs\n\nAdventures by A Himitsu  https://soundcloud.com/a-himitsu\nCreative Commons \u2014 Attribution 3.0 Unported\u2014 CC BY 3.0 \nFree Download / Stream: http://bit.ly/2Pj0MtT\nMusic released by Argofox https://www.youtube.com/watch?v=8BXNwnxaVQE&t=0s\nMusic promoted by Audio Library https://www.youtube.com/watch?v=MkNeIUgNPQ8\n\nArtist: tubebackr & MusicbyAden\nTrack: LOGISTICS\n@tubebackr music \n@MusicbyAden\nCreative Commons License. Attribution-NoDerivs 3.0 Unported (CC BY-ND 3.0)\nMusic Link: https://www.youtube.com/watch?v=SJVh_7lDf6w\n\nMusic from #Uppbeat (free for Creators!):\nhttps://uppbeat.io/t/fass/furious\nLicense code: JNBUADJFRTJIFFRA",
    "channel_url": "https://www.youtube.com/channel/UCYldE7tGQHjNwIVHQ7bDNoA",
    "duration": 526,
    "channel": "BalloonDota",
    "uploader": "BalloonDota",
    "upload_date": "20240503"
  }

  This text was transcribed using whisper model: large-v2

   If you struggle to carry games from the offlane position, then this video is for you.  In this video, I'll be teaching you to go from scores like this, to consistently hitting  scores like this.  Note that this progress is from my 2k MMR student that has climbed to 3k MMR quickly  by following the tips in this offlane guide.  If you also want to learn how to carry your games and think like the 1% offlaner, keep  watching.  But before that, I would like to quickly introduce to you Dota 2 Pro Tracker, the top  Dota 2 website to get your resources from about up-to-date meta builds and hero picks.  If you are not already using Dota 2 Pro Tracker to learn more about the game, be sure to check  it out.  With that said, let's get back to the video.  First, let's take a look into the starting items.  There are generally 2 alternative builds, which are the Stats build and the Magic Stick  build.  The Magic Stick build should be prioritised if playing into heroes that spam spells in  lane with short to average cooldowns, such as Phantom Assassin and Leech.  Otherwise, go with the Stats build.  Next, you will be going to your lane and prepare by the river for the Bounty Rune contest.  Note that what you do here is dependent on your teammates.  If your teammates decide to invade and contest for runes, then you will follow.  Otherwise, either ignore the Bounty Rune if it is dangerous, or pick it up and go back  to block the lane creeps in your lane.  Once the lane begins, the moment you have enough to afford a Bracer and Tango which  is 300 gold, ship that out first as your first 2 items if you are going with the Stats  build.  Alternatively, on the Magic Stick build, send out the 1 upgrade and the Tango once you can  afford it.  The extra Tango sent from the first courier usage is a safety net just in case you run  out of Tangos fast in lane and need to wait for the courier to come again later on with  low health in lane.  Now, the laning phase for an offlaner revolves heavily around keeping the lane frozen near  your tower by good creep aggroing fundamentals and sustain.  You will be constantly holding the lane close to your tower and punishing the enemy hero  with your support anytime you see favorable trades.  Favorable trades are defined as 2v1 fights early on with good positioning, higher health  and level advantage.  Of course, you need to communicate with your position 4 support through pings, text or  voice whenever a good trade is identified.  This is paired with constant sustaining through regen consumables and building up items over  time.  You will basically be repeating this process of holding the lane near the tower, punishing  enemy heroes and recovering with sustain until the point where you will become strong enough  to kill the enemy safelaner and support under their tower.  Once you identify that you are able to do that, you will then start pushing the lane  into the enemy heroes to attempt to kick them out of lane and break their safelane tower  as early as possible.  This will usually happen within the 5-10 minutes mark of the game where you will hit a power  spike on your hero such as the level 6 for ultimate upgrades or key items that allow  you to tank and dive towers.  Example of key items are such as Vanguard on tanky strength heroes or Veil of Discord  as an alternative on certain heroes like Death Prophet and Sand King for extra stats and  kill potential.  Another opening towards ending the laning phase for the offlaner are ganks from your  teammates to help set up the push in your lane.  In cases where you feel like you need extra assistance to pressure the enemy's safelane  tower and kick them out of lane, be sure to communicate to your teammates about this.  You need to let your teammates know that you have hit your power spike for them to start  moving towards your lane through gates or teleports.  On the other hand, if you happen to lose your lane and are unable to push into the enemy  safelane and break their tower pre-10 minutes, then just retreat to the jungle camps around  the lane such as to the big camps or ancients if you are a hero like Tidehunter or Axe that  can do ancients early on.  Also, constantly pull the big camp at your lane for the lane to push back to your side  to get safe farm.  Keep sticking to the recovery route of farming in a losing lane until you are able to push  forwards into their tower again.  While farming, ensure that you are looking around the map for potential cleanup kills  and good fights to take.  Hey guys, before we continue with this video, I'd like to just take a quick moment to ask  that you like, comment, share and subscribe to my videos and YouTube channel.  Your support will really help me grow my channel.  Also, you can check out my favour page on Patreon if you are interested to work with  me to improve your gameplay.  Thank you!  Majority of the time, you should be able to successfully break the enemy's safelane tower.  Once this happens, you will then transition into the early game phase where heavy emphasis  is placed on the concept of area control.  This part of the game is where 90% or I would dare say 99% of offlaners, especially those  in the lower ranks of below 5k MMR, always get wrong about.  They will always think that once they have successfully taken one tier 1 tower down,  it's time to focus on pushing another lane to move onto the next tier 1 tower and the  next tower after that.  I am here to clarify that this is a misconception because it defeats the core principle of what  makes up Dota, which is map control, pressure, lead in terms of XP and net worth, understanding  power spikes and overall information of teammates and enemies around the map.  In order to positively impact these core principles, you will need to constantly keep the enemy  safelane pushed in by killing the lane creeps.  This is followed by planting wards all over the lane and enemy jungle in order to take  away their resources and make plays happen where you have vision while still being safe  all the time.  Think of your job as someone that is there to bully the enemy safelaner and constantly  starve them of their own resources, which are their own jungle camps, and also mess  with them if you are able to when the lane pushes back into them.  You will be basically doing this over and over again by exhausting all resources in  your area of control until a good fight happens nearby where you can connect to, such as through  the enemy jungle into the mid lane, or a potential play or clean up happens at another lane where  you will teleport to.  Once you have executed a clean up or a good play, immediately look towards returning to  the enemy safelane again to keep the pressure up and not let the enemy safelaner come back  into the game.  In cases where you have another core holding the enemy safelane, then you can pick another  lane that is open and hold that lane to keep it pushed in instead.  Repeat this movement and farming pattern until you hit a key item timing that gives your  hero a big power spike, such as a blink dagger or a black king bar, normally within the first  15-20 minutes of the game.  That is when you will start playing more around the team whenever your team groups up to make  plays happen around the map.  However, do not forgo the concept of keeping lanes pushed.  Ideally you would still want to keep the lanes pushed into the enemy's side before grouping  up in order to make the enemies react to your actions by showing themselves to defend lanes.  This is another common mistake whereby offlaners tend to give up the control they had set up  early on by running all around the map looking for kills, but in turn giving up the pressure  of pushing lanes and worst of all, dying in fights and falling off.  As a result, they start throwing away the lead they had created early on and the game  now becomes harder to recover from.  So once you have your items, your actions will keep revolving around keeping the enemy  lanes pushed in and grouping with the team because now it is no longer about getting  farm and speeding up item timings, but rather about starting fights and contributing much  more to overall map pressure and presence.  Do not go back to your own jungle camps and play backwards if your teammates are already  playing forwards.  This will just result in you playing as an AFK farming player rather than someone that  contributes when strong.  Alright, so you need to keep repeating the pattern of grouping to team, pushing lanes  in, repeatedly moving forwards with your team where a successful fight or high ground push  is attempted to close the game.  In summary, the offlaner's heaviest emphasis lies on playing the lane well and occupying  the enemy's safe lane and jungle after the laning phase ends.  You would then need to hold your fort and stand your ground until you hit your item  timing that gives your hero a huge power spike, which will enable you to contribute  much more to fights.  If you can nail the laning phase and early game phase down consistently, I am confident  that you will find yourself climbing the ranks really really quickly on the offlane role.  I hope this video has been helpful for you offlaners and also to those of you that are  looking into understanding the offlane role more.  Thank you for watching, see you guys in the next one.


url: https://www.youtube.com/watch?v=erzkTPc9SYI
title: Closing Ceremony - Fish_ and Cherry & Stef
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=erzkTPc9SYI",
    "title": "Closing Ceremony - Fish_ and Cherry & Stef",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1137,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   What a day, what a day, what a day, what a day.  Did you guys have a little bit of fun today or what?  It has been quite a year.  What a year, what a year, what a year and about a year ago the three of us, we came  actually with an idea, you know, we need to continue and do something nice on the community.  You can put the slide on, by the way, because it's about, it's not that long ago.  A year went by and now we are over here together with approximately 300 persons who are having  the passion to talk about the subject we are talking about.  We didn't just start at that, you know, I still remember when Sherry invited us to Amsterdam  and she said, hey, come on, let's have a beer and we walked around, it was quite warm, it  was good weather, we had some alcohol free beers because I don't drink much alcohol anymore  and we started actually brainstorming on your balcony and thinking about, hey, what can  we do because we lost something that year but it actually was something we started actually  at that moment and it didn't take about an hour and we came up with the idea.  First we were thinking about the other one conference, it was a little bit lookalike  but yeah, it wasn't our thing.  So and then we came up, what do we want to be?  And we said, you know, we want to be Dutch in a way, mainly because we are Dutch and  what's the most Dutch thing we can recognize and we celebrate every year?  Well, cheese or whatever, yeah, yeah, yeah, but it's the color of orange, yeah.  So it didn't take very long before we find out we wanted to do something with orange  and so it was actually the name of Orange Corn Born.  Next we had the idea to do this, yeah, let's do a conference in March.  We were talking about, I think it was June or something like that, you know, nine months  will be enough, you can make a baby in the time, yeah, why you can't make a conference  in about nine months.  Finally we decided actually somewhere, I think January to move it over to somewhere nine  months later because you can make a baby in nine months.  From the beginning, when we were sitting at this balcony, actually something happened  you don't have often, who is having a partner over here, yeah, and who does feel very connected  in a way that you think that if you're going home that, you know, your partner made food  or something like for you, it's good, it's a really good feeling.  Well, if you want to make a baby, like Orange Corn, you don't need two persons, you actually  need three persons and when Stef made actually the batch to, when Stef made actually the  batch of the opening, he made one batch with three names on it, Fizz, Cherry and Stef and  actually this says something for me because this said we were a team actually from the  beginning to make this orange baby the baby we have right now.  So enough babies right now and enough past, but me personally I'm very proud on what we  gained and we learned a lot, we can say that, and we had some good stuff going on but we  also had some oopsies.  Want to talk about the oopsies?  Yeah, let's do it.  This one I'm going to give to Stef.  One of the oopsies wasn't really ours per se, but we decided on this CFP platform called  Pretalks, which is an open source project by a German developer who at a very affordable  rate offers people a platform to run a CFP.  Usually when you're running a security conference you have a certain type of person who are  submitting talks or workshops in this case and at some point I got a message from somebody  who gave the CTF hacking workshop like, I might have found an issue here.  And the funny part is he obviously responsibly disclosed it to the developer, but we looked  at it a little bit and the stored content scripting that he found would have allowed  him to submit a talk and have me automatically accept it, which was not the way it should  be going on the CFP.  We had much more oopsies.  Two weeks ago I spoke to Meervaard and Meervaard is a fantastic place I have to say.  We have found a real good home for our baby, sorry.  But after the holiday I had a call, hey listen, are you sitting down?  So I sit down, yeah.  We had a fire at this place.  So it was like my heart rate went to 180 or something like that and I was like what happened,  what happened?  Yeah, yeah, we had a fire at the entrance and we can't put up your banner.  That was luckily, I was really happy and they expected a little bit that we're going  to be angry or something like that, so they were really happy how we responded because  we found a really good partner in Meervaard over here and I think it's a really nice place  we were able to win down.  Luckily the fire was quite small, it's at the entrance and yeah, we were missing the  banner so we just ordered some beach flags.  You can still see the scarred parts.  If you go outside and you look on the right side of the entrance, there's a little bit  of scarred wood there.  The other one is for you because everybody's a cherry.  So this is an interesting one.  I would like you all to take a look at your badge.  Take a very good look at your badge and see if you can spot, yeah, there's two stickers  and underneath those stickers on all of your badges is my name, Charita van den Bent.  Unfortunately, the printer decided that my name was very pretty and they wanted to print  the example badge on all of your badges.  So now you're all also cherries.  Oh, you can take this one too.  Oh yeah, I can take this one too.  Also if you take another look at your badge, you will find this nice QR code here.  I thought it was a very good idea to put a QR code there that linked to the schedules.  You would always have the schedule within reach.  Well, I used a very nice company that allowed me to put on a tiny logo which said schedule  and I tested it.  I scanned it with my own phone and it worked just fine.  Yesterday someone came to me and was like, hey, you already gave me my volunteer badge,  but did you test the QR code on it?  And apparently at that point my 14 day free trial had run out.  So I thought, okay, well this is going to be an easy fix, right?  I just have to pay money to get this sorted.  So I looked at it and said, okay, $4.50 a month.  Okay, like $4.50 is not much, right?  You can only sign up annually.  So we now have an annual subscription to a QR.  So if you want any QR codes, come to us.  This one's for Steph.  Yeah, let's do that.  One other thing happened.  At some point the wrong version of a GitHub was pushed to our website, which happened  while the main web developer was actually on holiday in the UK.  And we noticed that we published all the trainings which we hadn't fully agreed upon yet with  the trainers.  We scrambled, manually removed what we thought was all the links to all the trainings that  were not published yet.  And then somebody on Twitter sent us a message like, hey, just so you know, if you go to  the OSINT training, the links are still there.  So we had our first responsible disclosure as well.  Yeah, and this one particularly is special for me, actually it's special for Steph.  It's a funny thing because actually Steph hate the color orange.  And that's good.  That's fine.  We all have the possibility to not like a color or whatever.  And today Steph came to me and he said, you know, I'm only going to wear the shirt during  the closing and the opening.  I said, yeah, of course, you know, it's your color and it's nice to set the tone on the  beginning.  And then during the day something happened.  Steph was wearing the orange shirt because it was that easy to find us.  So we came up with the idea also that it was easy to find him.  So thank you very much, Steph, actually for wearing something you don't like.  Thank you very much.  Maybe you guys haven't heard it yet, but we as OrangeCon, we are a foundation.  We are Stichting Ocon.  And the main reason why we made it a foundation is because we think it's very important for  everybody to have some openness also on what we do and what is our purpose, et cetera.  So that's the reason why we didn't have an entity like a BeVe or whatever, but it's mainly  a reason that we founded the Stichting.  And we also have some very strict rules what we want to gain with that.  And one of the most important things is knowledge sharing for the Dutch community by the Dutch  community, for example.  And it also means that we want to be open on a lot of things.  We want to create a transparency report, for example, and to tell you, you know, what is  the cost of a conference like this?  Well, I can tell you the total average cost we are spending in the past days and today  is about 95,000 euros ex-tax.  That was quite a number, because, yeah, we grew to, sorry?  I hope I can get it off the VAT or something like that.  The revenue of the conference is about 110K if we have everything.  So we're making a small plus.  And I think this small plus is very well, because in the beginning of when we founded  Orangecon, we started with zero euros on the bank.  It was even worse.  The Rabobank even already took our money before we even had access to the conference.  They're asking the monthly subscription costs.  So I said, you know, I don't have access and I'm already in the minus.  What the fuck?  But that doesn't matter.  The main thing is that we wanted to say that we are, yeah, we're making about 10K or something  like that, but we need this money also already for next year, because we decided not to make  it a one-off.  We decided to make it for next year.  The total entities is approximately 300.  I say approximately because, yeah, can you count the speakers and the crew or whatever?  It's the maximum we can gain at this room.  What will happen in the future, we'll talk about that later.  Very important.  Maybe you can take this one, Sherry.  So as Buddy mentioned, Orangecon is our baby.  And a baby, you don't raise a baby just with the parents.  As every parent will know, it takes a village.  So we would like to ask you, our village, to help us raise our baby.  Please give us all the feedback that you can.  Good feedback, bad feedback.  We prefer constructive feedback, but you do you.  You can just email us at feedback at orangecon.nl.  If you would like to remain anonymous, just create an anonymous email address.  I'm sure all of you know how it works.  Then we're coming to the big thank you list.  And I'm not going to mention them all, but there are some very important things we do.  It wasn't possible to organize this con with, for example, our sponsors.  The tactics behind our sponsors.  Also in the transparency, we're going to tell you a little bit about how we are using the  sponsorship.  We built the conference in a bare-bone construction, which means that we were able to pay the bill  with the tickets of the training and your tickets.  All the sponsors made it, for example, possible that we would have a nice giveaway to our  speakers, for example.  The sponsors made it possible that we had something at the first coffee break, for example.  And the sponsors made it possible to do some extra things around it.  So the tactics behind it was, you know, the sponsor made OrangeCon even more shiny than  we were able to do it only if we did it bare-bone.  So I think this is really nice that we have our sponsors.  Thanks, sponsors.  We are making this a community conference with the community.  And there are just a few logos on, but a lot of other communities did help us out.  And I think they also need a very big applause, because a lot of people from these communities  are walking around.  Thank you, community guys.  And we also have a giveaway.  I don't know.  Who did the giveaway?  And I want to ask one of the Tanium guys to come over here.  Yeah, yeah.  Oh, he's here.  Because this is the big box, and you might be able to hand it over to.  It's the D&D version of LEGO.  I loved it.  At first, I was actually doubted to say, you know, the box didn't arrive.  It did arrive.  Yeah, yeah.  Thank you very much.  And we have a kind of funny thing going on, because we needed to do a lucky draw.  But we had quite some people actually signing up.  So we're going to do a lucky draw.  And I already asked Inge to come up with a number below 29.  And what's the number?  Because you're the notary right now.  27.  That sounds very good.  So I'm going to show the slides with all the names on.  And we're going to take a look at number 27, which is somebody from Ajin, Stanislav.  And I'm not going to pronounce your last name, but I will probably say it wrong.  Yeah.  Stanislav, is he around?  Come over here and get your prize.  Have a lot of fun with it.  Yeah, thanks everybody for attending today.  We're here actually not just to sponsor, but also to be part of a community.  And that's really been a great day for us to see you guys.  But also to thank the organization OrangeCon.  And we hope to be here next year again.  And for myself, I see quite some familiar faces from the community.  And I hope to see you guys soon again.  And that's actually it.  I didn't copy anything.  So as you guys said, we're going to invest in the future.  And if you guys are interested, the foundation is a little bit making profit on t-shirts  and the merch, et cetera.  We sent up a merch shop because we didn't want to handle cash over here.  And it's much easier to have it at your doorsteps around.  It's a printing on the month server.  So if you'd like something to order, you will probably help us at least to  organize the next conference again.  So if you are interested in the shirt, please take a look on it.  So yeah, let's talk about the future.  And it's already there.  So now we have to do it.  Well, you want to talk about the future?  OK.  OK.  Well, let's talk a little bit about the future.  When we started this, as I said, we don't want to do this as a one-off.  We want to continue this.  And we have the 5th of September today.  And we came up actually Thursday is a very nice day.  But Friday should be better.  But they were already booked on Friday.  So yeah.  So we decided actually to go to 5th of September 2025.  There is still a lot of discussion if we're going to make it one or two days or make more  or less trains.  It is going to be set probably after a month of rest.  Then we're going to fill in the gaps and the blanks and see what's going to happen there.  So put it in your agenda.  5th of September 2025.  Yeah, this one is especially you.  So I would take a small moment to thank our fantastic crew who all of us who are all  volunteers who volunteered their time, not just today, not just the past few days, but  also in the weeks before to help us build this event.  Orangecon would simply not exist if not for them.  So thank you very much.  So, okay.  Thanks.  Who wants a beer?  Thank you all.  See you next year.


url: https://www.youtube.com/watch?v=rPZx1zbKJnI
title: TROOPERS24: 10 Years of Windows Privilege Escalation with "Potatoes"
type: video
author: TROOPERS IT Security Conference
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=rPZx1zbKJnI",
    "title": "TROOPERS24: 10 Years of Windows Privilege Escalation with \"Potatoes\"",
    "description": "Talk by Andrea Pierini - June 26th, 2024 at TROOPERS24 IT security conference in Heidelberg, Germany hosted by @ERNW_ITSec\n\n#TROOPERS24 #ITsecurity \nhttps://troopers.de/troopers24/talks/cyzbj3/\n\nMore impressions:\nhttps://twitter.com/WEareTROOPERS\nhttps://twitter.com/ERNW_ITSec\nhttps://infosec.exchange/@WEareTROOPERS\nhttps://infosec.exchange/@ERNW https://ernw.de",
    "channel_url": "https://www.youtube.com/channel/UCPY5aUREHmbDO4PtR6AYLfQ",
    "duration": 3272,
    "channel": "TROOPERS IT Security Conference",
    "uploader": "TROOPERS IT Security Conference",
    "upload_date": "20240902"
  }

  This text was transcribed using whisper model: large-v2

   Hello, and first of all, thank you for joining my talk, which will be about the wonderful  world of the Windows privilege escalations using potatoes.  First of all, you see two names here, myself and Antonio, my friend and partner in crime,  because most of the researches that I will discuss today, we did them together.  And part of this talk was presented by him last November in Seoul.  But I have some news, so it's not the same talk.  Oh, why doesn't it work?  It worked.  Oh, good, yeah.  Two words about me.  I am Andrea Pirini.  I am Italian, but I think that's an easy guess just listening to my bad English.  I work for Semperis in the bridge preparedness and incident response team as a senior security  consultant, senior because I'm old, because I'm not that expert.  But OK, keep on.  During my spare time when I'm not cycling or doing other fun stuff, I like diving into  the world of the mysterious world of offensive security.  And, of course, I am a potato lover.  These are my handles.  If you want to get in contact with me or read my blog post, here you have it.  Why this talk?  In very, very short, we wanted to share our journey in trying to find new potatoes technique.  This is what we did.  And we spent a lot of time, endless times, endless nights.  And we used crazy ideas to find always new vulnerabilities in order to exploit what we  call the potato technique.  So this talk will not go too much in the details, because one, it is boring, and two, it will  take too much time.  So I will keep it, I hope, interesting and just more simple explanations and not going  too much deep in the technical details.  The agenda, after a brief introduction on what is considered by Microsoft a privileged  escalation, so what is a security boundary violation and not, we will delve into the  RPC Decom trigger, which is the trigger which permitted us to find a lot of vulnerabilities  via the potato techniques.  And after this, we will analyze how it was possible to break the boundaries, the safety  boundaries and the security boundaries, local and then also from remote.  You see here three asterisks.  These are the new findings.  This is a total new entry.  So I will, the first time, talk about this in this session.  So I hope you will enjoy it.  And then, obviously, at the end, the conclusions.  So let's start with what is a privileged escalation.  Well, I can say what is not a privileged escalation from Microsoft's point of view.  It's not a privileged escalation from admin to kernel or user account control bypass.  And it is not a privileged escalation when you abuse a service account or you bypass  the Windows service account hardening.  This is considered a safety boundary and it is not considered a security violation.  Alias, the behavior is by default or the behavior is as expected.  And then sometimes they silently fix, but it's up to them.  What is a security boundary violation?  Of course, from standard user to admin and the various sandboxes bypasses.  So this is my personal consideration.  I still don't understand the bounty politics of Microsoft.  But probably I'm an old-seasoned legacy on-prem guy.  So it's difficult for me to understand this decision.  I don't know what you think about it.  But yeah, that's my personal opinion.  And I wanted to share it with you.  Okay, where it all began.  It began 10 years ago.  Therefore, 10 years of potatoes exportations with James Forshaw.  You will hear his name several times because he did a lot of fantastic researches.  And which helped us very much in our researches too.  So we hear his name very, very often.  And it started with the local NTLM reflection attack reported in 2014 and fixed in 2015.  This was the very, very first, let's say, potato technique.  Because then the name potato came after.  But this is the very, very first potato technique.  So how does this work?  I try to keep it very, very simple.  So we have a malicious COM object.  Okay, I have the screen here. Perfect.  We have this malicious COM object, COM client, which tries to trigger a privileged COM server service.  And how does it trigger?  Using a special call, a DCOM call.  It's COGET instance from my storage, blah, blah, blah.  With a class ID.  By triggering this COM server service, what happens is that the client crafts a controlled Marshall object.  Standard REF Marshall object.  And this object contains some important information.  The auxit resolver address he should connect to.  The auxit resolver port.  And this can be controlled by the malicious user.  And this is very, very important.  Because auxit resolution is needed for locating, for the COM server, to locating the binding information on where to contact the COM server.  So think about it as a DNS for DCOM.  And the other funny thing is that this call is authenticated.  So when we trigger this COM server, what happens is that the privileged COM server will perform a resolve auxit 2 call.  And it is an authenticated call.  So we, as a malicious user, can intercept the authentication.  And then use it.  But we can go further.  We can also send to the privileged COM server service a string binding containing the information about a fake RPC server under our control.  And the COM server, which happily contacts us via the IRAM unknown interface, unknown 2 interface call, will contact us.  And again, it is an authenticated call.  So at the end, we have the possibility to intercept this authentication.  And then, depending on the context, we can reflect or relay this authentication.  And this is the whole magic.  So it's not black magic, but it's a behavior by default.  But as usual, there are a lot of behaviors by default which are most of the time ignored.  And then when someone discovers it, they can order it.  But this can also be abused.  And this is the case.  So we have what I call profit 1 and profit 2.  Remember these two?  We have two authentications we can intercept and manipulate.  The second one was implemented by us, starting with the raw potato tool, I think three or four years ago.  And this is the first time we implemented a raw oxide resolver so that we could also abuse this second authentication.  So let's start from the very beginning, from service to system.  So a safety boundary violation.  When I say service, I mean abusing the impersonation privileges.  Because normally, services have at least impersonation privilege.  So it's a matter of abusing this privilege.  I think that you know this tool?  Yes? No?  Ah, good. Okay.  This was the very first implementation.  It was done in 2016.  And it was the first tool which triggered the DECOM server.  And it was somehow limited because it used only the bits CLSID and used a fixed port, which was 666.  And basically what it did is triggered authentication, intercepted authentication, negotiated a system token,  and then impersonated the system token.  So once you have impersonation privileges, you impersonate the system token and your system.  And this implementation worked only with Meterpreter, so it was somehow limited.  And then came our juicy potato.  Juicy potato, you know it, yeah?  Ah, cool.  This was coded by me and my friend Giuseppe in 2018, so many years ago.  And it was what you call the sugared version of raw potato because it permits you.  We found a lot of other interesting CLSID to abuse.  It is possible to specify a port instead of a fixed one.  And also, it is standalone.  So it uses create process as user or create process with logon token to use the token  and then launch a process under the system identity.  And it was heavily used because it was very simple to use.  And once you compromise the system or an IAS account, an MS SQL service account,  it was very easy to perform a safety boundary violation.  This was, let's say, fixed.  We're starting from Windows Server 2019.  And with this version, it was no more possible to specify a custom port.  And then this fix was backported in 2022, also in Windows 2016.  So juicy potato stopped working.  How was this performed without going too much in details?  Simply by escaping the custom port.  Not exactly escaping the custom port.  Escaping the brackets around the custom port.  So once they had escaped, the exploit breaks and it doesn't work anymore.  And so goodbye, definitely, to juicy potato.  But obviously, meantime, we had other ideas.  So we started with raw potato.  In raw potato, instead of using the local port, and we can no more specify a local port,  we used a redirector on a Linux machine, the socket redirector,  which then redirects the calls from port 135 to a custom port  on a service running on our machine.  And this service is the fake auxit resolver.  What does raw potato do?  First of all, it uses name pipe instead of TCP IP.  And it creates a custom fake port mapper endpoint.  This is very important.  The port mapper endpoint is the equivalent, again, of the DNS for RPC.  And the trick was, because we cannot create another mapper endpoint,  because it already exists in the name pipes.  But the trick was to escape somehow the checks,  so that it is possible to create a port mapper under another, let's say, subdirectory.  But because there is a bug, and there is still a bug,  in converting the slash chart, as you can see.  So if I specify localhost slash pipe slash blah blah blah,  it converts it in a real name pipe path.  So once we have the name pipe, it is very easy to impersonate the caller,  which is in this case system.  Once we have impersonated the caller,  we are network service in this case,  because the process is the RPSS service.  Network service is not that interesting,  but in this process, the RPSS service,  we have the authentication ID of the RPSS,  which permits us to access a lot of juicy tokens,  system code tokens, and whatever.  So with a simple token kidnapping,  once we have access to the process,  we kidnap the token of the system user,  and then we authenticate,  and then we use this token for creating new processes.  This is a simple screenshot on how RockPotato works.  Classic web shell with a CMD.  I am the default IIS user,  which has impersonation privileges.  I launch my tool, and I get back a system shell.  So again, a safety boundary violation.  With this idea in mind,  so intercepting the second authentication and abusing profit too,  we also rewrote part of Juicy Potato  so that it is possible to intercept the second authentication,  and in the meantime, using a trick from James Forshaw,  we could also get rid of the socket redirector,  because we are no more interested in the first authentication,  but in the second authentication,  which is returned via the string bindings  by our fake auxit resolver.  So we are able to intercept this authentication,  but sadly, in this case,  we don't have that much CLS ID to abuse,  because most of them return you an identification token,  which is really useless.  Then there was the PrintNotify service,  which was the perfect candidate,  because it returned an impersonation token,  but then it was a problem,  because it needed the interactive seed.  So we used a trick to recover the interactive seed,  and we were able to perform the full escalation.  After some months, Microsoft fixed the possibility to use this trick,  but luckily, starting from Windows 11 and Windows Server 2022,  we have this other service, the MCP management service,  which has its own CLS ID,  and which permits you, again,  to get an authentication from the system  with the impersonation token.  So it's okay.  So basically, what we did,  I called it a juicy potato NG,  so we gave a second chance to a juicy potato.  And this still works,  but again, we are always talking about safety boundary violations.  So in this screenshot, you can see very, very easy  to, once you have an impersonation privilege  or an assigned primary token privilege,  escalate to system,  just launch the tool, and you're done.  Obviously, there are a lot of other contributors  with a lot of other cool potato techniques.  Here are some of them.  Always safety boundary violations,  and there are also other new ones,  so it's up to you.  But there are a lot of other possibilities  to abuse these potato techniques,  so I only describe the one we found in this case.  So let's get it a little bit more interesting.  With rock potato, with the technique of rock potato,  so we thought,  but is it possible to perform a real privilege escalation?  Because we have all the elements.  We have to understand how we can abuse the authentication,  and if you can get another type of authentication.  And here comes remote potato zero,  which is the first security boundary violations.  In this case, we are relaying the NTLM authentication.  It's a local exploit,  but the relay is performed on a remote server,  and what does the remote potato do?  It abuses some com servers,  which impersonates the logged-in user,  and this is interesting,  because the idea is intercept the authentication  of the user connected on another session,  and relay the authentication to an external server.  So imagine that if you have an admin or whatever user  which other privileges connected,  I can trigger his authentication  and forward the authentication via NTLM  to a target server,  where I want to access resources on behalf of this user.  We had the problem because by default signing was enabled,  so this limits somehow,  but with another trick,  we were able to downgrade to RPC-level connect,  which means then signing is no more enabled,  via the Resolve Auxit 2 call.  So the main scenario is obviously  when you have a privileged user  in a multi-user environment,  imagine a remote desktop,  a privileged user,  I trigger his authentication,  and I relate to LDAP.  Imagine a domain admin.  I know that domain admin should never log on on non-tier 0,  but who knows, maybe it could be possible.  So you can relate,  and at this point,  you relay the authentication,  and depending on the user you are relaying,  you can take over the domain.  So in this screenshot,  it's just an example.  We have a standard user,  a domain admin user,  which is connected on another session.  I launch the Remote Potatoes 0 tool,  specifying the session,  and then I forward.  I am able to intercept the NTLMv2 hashes.  I forward the NTLMv2 hashes to an external relay,  for example, NTLM relay,  and then I can do whatever I want.  What we did in Remote Potatoes  is also to perform before a local relay  from DCOM to HTTP  so that it is more easy to interface  with external relay tools,  just like, for example, NTLM relay.  We obviously reported this to Microsoft  before publishing it,  because for us, it's a security boundary violation.  And what Microsoft said,  after a long debate,  a long analysis, and so on,  that server must defend themselves  against relay attacks.  And for this occasion,  we created a special T-shirt for this.  Sadly, I forgot it,  because I wanted to show you this T-shirt,  but I left it at home.  But 18 months later,  kind of unintended fix,  broke Remote Potatoes  because it was no more possible  to control the signing.  So it is always signed,  so the relay versus LDAP, for example,  won't work anymore.  But it still works  where SMB signing is not required.  For example, SMB, HTTP,  SMB signing is not required,  but normally the default is on domain controller, yes,  but on file server and so on,  we leave the default, which is not signed.  So you can do, a malicious actor  can do a lot of nasty things,  still can do a lot of nasty things  with Remote Potatoes 0.  So move on, on Local Potato.  This is a curious story,  because it's kind of,  I wouldn't call it a bug,  but again, it's by design.  In the local and telemetry authentication,  so we are again speaking about local,  local and telemetry authentication is a particular authentication,  it's a loopback local authentication,  there is a reserved field,  which is called reserved field,  that is very interesting,  and thanks to our friend Ilad Shamir,  which gave us this hint,  we tried to understand if it is possible  somehow to abuse this field,  because we had in mind a kind of swapping,  and this is what we did.  So in the local authentication,  the reserved field references the LSAS context,  where the user should,  where the authentication should occur,  associate and occur.  So the idea is,  why not triggering the authentication  of a privileged user,  of a system account,  swap the context with a user under our control,  and then authenticate to another server,  to another service running on the same machine,  because it's always a local privilege escalation,  and that was what we had in mind.  First of all, we trigger a system authentication,  and we know how to do it.  We want to target, for example, the local SMB server,  and perform an arbitrary file write with system privileges,  which is really the key to the kingdom.  We had to overcome some anti-reflection mechanisms,  so we have to specify an SPN,  and once everything is set up,  we intercept this authentication,  we magically swap them,  and then what would happen?  That we are able to authenticate as a system  to the SMB server,  and then once you have an arbitrary file write,  it's up to you to understand how you could abuse it.  For example, we hijacked the printconfig.dll  in the printer service,  and we were able to use our malicious DLL  to get a shell, for example, as a system.  So how does this work?  We have, first of all, our privileged client,  and we trigger the authentication of our privileged client,  and we associate it with context, let's say A.  Then we have also a client process under our control,  which tries to authenticate  versus the server service,  for example, the SMB server,  and our client gets back the context B.  Then we swap the context,  so that the privileged client  will associate with context B,  and our client contacts with context A.  And at the end, if everything works fine,  the privileged client will authenticate  against the server service, SMB in this case,  and the client process  will authenticate against our server service.  Okay, I have also a video demonstrating this.  You see, I have here a standard user  without particular privileges,  and my goal is to overwrite the printconfig.dll.  Okay, I get no output here.  Something strange happening.  No.  Okay, let's do it another way.  Okay.  Okay.  It's not easy now, but...  Ah, sorry.  Okay, we skip the video for now, and then we'll see.  So, extend this display.  Okay.  Hmm.  It's frozen.  Sorry, but...  It's more than the demo effect.  It's always Windows, no problem.  Okay.  Okay.  Something is not working because...  I still...  Okay.  Okay, without showing the video, but here you get it.  I am able, with our local potato exploit,  to overwrite the DLL,  then I instantiate the object,  and I get back a system shell  because in my DLL I put the instruction  for returning a shell.  That's all.  That's clearly...  No problem.  That's clearly a privilege escalation, obviously.  And...  If I can get out of this video.  And clearly Microsoft fixed it with this CVE.  And what Microsoft did is that...  This is the reverse engineering of the fix  which was done in this DLL.  If the caller is from an unverified source,  and this flag is set by the TComp client,  and if the SPN set is set,  the SPN is deleted,  so the anti-reflection mechanism won't work,  because I have no SPN,  and the exploit breaks.  So, but...  It still works against HTTP.  WebDAV, it's a very, very edge case,  but it still works.  Or, versus custom authentication,  which uses the security provider.  And Microsoft did not want to fix the second one,  because we reported already the second one.  They said, no, but this is too complicated,  so it's an edge case,  so you have to protect your endpoint,  you have to use extended protection,  blah, blah, blah, blah, blah, blah,  and it is not fixed.  So, if you go on my blog post,  I think I published also the...  No, the latest local potato source code  is also for HTTP,  so you can try it at home,  and see that it still works.  Then comes fake potato.  Fake potato is the one with the asterisk,  because it was discovered by me  three months ago, let's say so,  and it's a local privilege escalation,  still waiting for Microsoft fix,  so, unfortunately, I cannot spoil that much.  It's not exactly a potato technique,  so it's something a little bit different,  and it's cool, because it's logic pack,  I think it was there from Windows 2000,  so it's something that,  I don't know why it was never found,  and because it requires an unexpected prerequisite,  but which is not that strange,  so, and when I discover this,  no, it's not possible,  it's something that fucked up on my machine,  and Microsoft confirmed that  it is a security boundary violation,  so it has to be fixed.  I have a video, I don't know,  I pray the God,  but before showing you the video,  I obviously asked to Microsoft,  and they told me,  okay, send us the video,  in order to avoid the usual drama,  so send us the video,  and we will tell you if it's okay or not,  and you can see the mail,  they told me,  okay, you can show the video,  but do not spoil other things,  so I will only show you the video,  and I won't talk.  Will it work now?  That's a good question.  Okay.  Oh, okay, okay, great.  Oh, okay.  In the first,  I have an administrator connected on a session,  another session,  I have another user, standard user, okay,  you see two sessions,  now I launch my fake potato tool  against the admin session,  and let's see what's happened.  Oops, desktop changed.  But, okay.  Let's get more serious, okay?  So, I relaunch the tool with another mode, okay?  And let's see what happens.  I get back a shell of the administrator.  This is clearly a privilege escalation.  But, don't ask me anything, please.  Okay?  So, now the last one,  which is the security boundary evaluation from remote.  So, the idea behind is very simple.  Instead of triggering a local com server,  why not triggering a remote com server?  This would be a great remote local privilege escalation.  Okay?  In fact,  obviously an external auxiliary server is required in this case  for the first authentication.  It's very, very simple because  with just a few changes on the code  by specifying the remote server and optional credentials,  I should trigger the authentication of a remote server  because it's in the library.  I can specify all the local or the remote server.  So, that would be great because  once I have captured the authentication NTLM Kerberos,  I could then relay it.  And this is also a great opportunity for Kerberos  because I forgot to tell you that  it is possible to relay Kerberos authentication  under certain conditions.  If you have the control of the service principal name,  you can perform a Kerberos relay.  And this is the perfect scenario because  I am able in my fake OXID resolver to specify the SPN  and so I can relay also the Kerberos authentication.  But there is a great but.  Non-admin users generally cannot instantiate remote objects.  So, to instantiate, to create a COGET instance on the remote,  you need domain admin or local admin rights.  So, any chance?  So, I started looking at the DCOM configurations and so on  in order to find vulnerable DCOM server.  And the first one I found,  I called it ADCS Squares Potato,  which is related to the certification service.  So, on the server where the ADCS services are installed,  there is this group, the Certificate DCOM Access Group,  which contains the authenticated users, everyone.  This is needed because users or computers  should be able to request and enroll certificates via DCOM.  So, this is clearly something by default.  So, users can activate these applications from remote.  As you can see, the Certificate DCOM services  have local and remote activation.  The certification service DCOM application  impersonates the system account.  So, via the network, it's the computer account  and is activable by everyone, every authenticated user.  So, what is the idea behind? Very, very simple again.  It's just activating this object via the potato technique  that requires the authentication of the server  and we will relay this authentication.  So, what can we do when we have the authentication  of the certificate server?  I think we can do a lot of cool things  because this is a Tier 0 computer account.  This one was discovered also before me, some time before,  by another Chinese researcher.  Unfortunately, I'm horrible in spelling,  so I just say Chinese researchers.  It was partially fixed with this CDA.  As you can see, again, the concept is always the same.  I have a standard user.  I request the authentication.  The first IP is the IP address of the certification service.  And then I have my redirector  where also NTLM relay is running.  I pass my credentials and as you can see,  everything was fine.  This is the dump of the NTLM messages  and at the end, I get the authentication  of the certificate server.  So, what can I do now? Relay it.  We have a problem because signing is now enabled,  so we cannot relay versus LDAP or whatever.  And we could relay against the HTTP Web Enroll Service  because we then request a certificate of the ADCS server.  And as you can imagine, if I have the client,  the certificate for authenticating as the certificate server service,  I'm done because I can perform code execution  on the certificate server machine,  back up the public and the private key,  forge fake certificates for whatever user I want,  and take over the domain.  But unfortunately, you cannot relay back NTLM authentication.  So, I cannot relay back the authentication  to the certificate server itself.  So, yeah, it's really limited.  But wait, there is a great opportunity with Kéberos  because with Kéberos, you can relay back the HTTP.  So, the server can relay back the authentication to itself  via the network if I use HTTP.  And this is interesting because if I don't have  extended protection enabled or I do not require SSL,  I can request a certificate.  And this is the screenshot with my modified version  of the great Kéberos relay tool  where I target the Web Enrollment Service.  My DECOM host is, again, the ADCS web server.  So, I trigger the authentication, relay it back,  request a certificate, and obtain the certificate  for client authentication of the certificate server.  And I'm done.  So, yeah.  And therefore, we should always use extended protection,  blah, blah, blah, because this still works.  So, you know if you don't use these countermeasures,  you are at your own risk.  But I didn't stop here because digging further into the DECOM,  I found these two groups.  I call them the forgotten groups,  and this leads me to remote silver potato.  We have these two groups which are built in,  I say not so well-known groups,  which are the distributed com users group  and the performance com users groups.  From Microsoft description, we understand  that they can somehow interact with the DECOM server,  and that is interesting.  So, members of these two groups can launch  and activate DECOM services from local and remote.  So, not only activate, because activate means  that the service needs to be running,  and launch means that I can start the service from remote.  So, the performance local users group  and distributed com users group can do these things.  This is cool.  Now we have to find a service which can be launched,  activated by these users,  and which has an authentication which could be useful for us.  And I found this object, the SPPUI object interactive class.  It's related to the Windows license service,  which is the perfect candidate  because it runs as an interactive user,  and it can be activated and launched by everyone.  That does not mean that it's by everyone,  because then you have the limits by the DECOM  and the members of the DECOM performance local users group.  So, this is a very, very interesting scenario.  So, by triggering this service,  we should get back the authentication  of the interactive user connected on some session.  If you are a member of this group,  it's not correct to call them domain,  but on the domain controllers built-in group,  you can imagine that this could be very, very dangerous  because normally, on a domain controller,  the domain admin logs in.  So, if you could trigger the authentication of the domain admin,  well, that's interesting.  So, how does this work?  We have an attacker,  which is a member of the DECOM users or performance log users group,  and then we have a V Team connected on a domain controller.  So, again, with the potato technique,  I trigger the authentication with the CLS ID of the SPP UI service,  which triggers the V Team connected on a session  to authenticate to my endpoint.  Because, as we saw,  we will perform an authenticated resolve-auxit call.  We are able to intercept this authentication,  in this case from the domain admin,  and use it.  We can also return a string binding,  which contains the port and an optional SPN  of our fake RPC server,  and we have another authenticated call,  and we have the second profit.  So, I did this, I tested this,  and for the first one, it's okay.  I was able to perform an NTLM relay attack  with an impersonation level,  which is what we need.  In the second one, sadly,  you have an identification level,  which is really useless,  because signing is enabled,  so you can't even relay versus LDAP.  I obviously reported this to Microsoft before,  and initially they said it was a critical finding,  but then after some time,  they assessed it as a moderate risk,  and that does not need an immediate servicing.  So, I can talk about this, okay?  Okay, I have the video.  Finger crossed.  It works, great.  So, I have my user,  standard user,  and a member of this, let's say,  domain, distributed com users group.  On the other,  then I am here in the worst scenario,  because I have NTLM V1 enabled.  So, in NTLM relay,  I will remove the message integrity check  and disable signing, okay?  I launch my tool,  where I specify the domain controller address,  again, my redirector and the host  where NTLM relay is running,  and the session, okay?  Once I launch it,  as you can see at the end,  I am able to get authentication administrator.  I will forward that indication to NTLM relay,  which will forward it to LDAP,  which will create a user account  with DC sync rights.  So, from a standard user,  I took over the domain.  That's something that...  I don't know why they did...  They said, no, no, it's not that...  Because in my job,  because this is a hobby,  in my job, I do active directory assessment,  and I found it at least two or three times  that this group was populated by non-tier zero users.  So, therefore,  we should consider these two groups  absolutely tier zero,  until Microsoft decides to fix something.  This works also on a local group,  on a local server,  but obviously a domain controller  is much more interesting, okay?  So, the next step was Kerberos.  Okay, NTLM, I can't relay NTLM.  Why not relaying in Kerberos?  Well, here we have two problems.  The first one is that  original Kerberos relay tool,  which is a great tool,  only intercepts the first authentication,  the second authentication.  And the second prerequisite  for performing Kerberos relay  is that you have to control the SPN.  So, for the first problem,  I recorded Kerberos relay.  It was really a long, tedious, and boring task  because I had to implement a raw socket server,  intercept the authentication,  extract the Kerberos,  and then move back and forth  between DCOM and SMB.  It was really...  I was giving up several times,  but at the end,  I was able to get it working.  And then we have the second one, SPN.  Sadly, in the first authentication,  when we return the string bindings,  even if you return an SPN,  the SPN will always be rpcss  slash the server  where our socket redirector is listening  because it's from where it's coming from.  So, no chance.  Then again,  thanks to a trick from James Forshaw,  we can bypass these SPN limitations  by adding a forged DNS name.  Because the Kerberos security provider extension  supports a special format for the SPN,  which includes the target info.  So, the syntax is the following.  Service class slash server,  which is the classic SPN,  plus the base64 encoded target information.  And Kerberos will ask for a service ticket  service server class,  server class server.  And the auxet resolver will try to contact  a server, which is server  plus the base64 address.  And the shortest base64 target info address  is this one,  which corresponds to a completely empty target information.  But the security provider will happily accept it.  So, what I did is  add the DNS record  with this strange name,  because normally standard domain users  can perform secure DNS updates.  And then relay the application request ticket  to a target server  on behalf of the user,  in this case the domain admin.  Again, this is the scenario.  User, member of these groups.  Victim, connected domain controller.  And the target server, where I want to access resources  on behalf of the victim.  So, what happens?  Again, I perform,  I trigger the authentication  and then in the  socket address I specify  this name, because I created this DNS name.  The victim will ask for a service ticket  RPSS slash target.  It will try to authenticate against me  with this application request ticket.  The attacker will simply forward this ticket  to the destination server.  And relay is successful.  So, just to demonstrate to you  that it does not only work on PowerPoint,  I have another demo.  Okay.  Oh, it works, great.  So, I create IDCS,  dash MyLab is my IDCS server, okay?  And this is the...  Okay, sorry.  Okay.  Okay.  So, with the Invoke DNS update tool  I create this DNS record.  Okay, now I have it.  I capture the traffic just to show you that  it is what was expected.  I launch my Silver Potato tool  targeting...  In this case, I want to target the SMB server  of the IDCS server.  Okay?  With this strange redirect host.  And as you can see, I want to dump  the local sum account database  and I was able to dump the admin hash.  Okay?  And as you can see, the SPN is the one we expected.  And...  This is all the traffic  for the remote registry access,  dumping the sum database, etc.  Once you have, again,  the hash of the local administrator,  you can log on, okay?  Again, perform a backup of the private key.  Elevate to system, perform the backup  of private key, etc.  And you're done.  So, you have, again, another possibility.  So...  We are at the conclusion.  Okay, perfect.  What can I say?  First of all, that with Potatoes,  we break safety and security boundaries.  Okay?  Most MS fixes were already partial  or even not implemented  because it's by default.  Future NTLM disablement  will stop some relay attacks,  but remember that if you have control over SPN,  you can relay cables.  The question is,  will Potatoes be still alive and kicking?  Who knows?  Maybe we should find a Potato in the cloud,  but it's not for me.  So...  Second conclusion for the defenders.  So, because many of these attack paths  at the end lead to relaying the authentication.  So, Microsoft always tells us  you have to disable NTLM  because it's dangerous, etc., etc., etc.  But, as we can see,  Kerberos can be relayed too.  So, the only way is to protect our endpoints.  So, I hope you enjoyed my talk.  Sadly, I had some problems, but...  And...  Thank you!  Thank you very, very much  for this interesting talk.  And I guess there will be questions in the...  Yeah, back there.  Some of the...  Thank you.  So, some of the attacks  which you were talking about  were using the web dev  or web client service.  And, of course, one of the countermeasures  would be to disable this service.  Have you seen any dependencies on this service?  Like, what could go wrong if you disable it?  Okay, probably...  The only attack I performed  via local potato expat, via web dev,  was with local potato to demonstrate that  via HTTP, it was not fixed.  Obviously, it's an edge case.  Via HTTP.  So, I configured a web dev server  in order to have an arbitrary write  via web dev HTTP.  So, this is...  The other attacks have nothing to do with web dev.  It's versus SMB or whatever.  Or versus the web enrollment service.  This is just to show that  there is still a possibility.  Imagine that you have a web application  but you need to have local access  and then you are able to authenticate  on this web application a system account.  So, depending on how it is configured,  you could do nasty things.  But it's really an edge case.  Okay, thanks.  But still, have you seen any dependencies  on the web dev service, web dev client?  Like any Windows component  or third-party application actually  using it, requiring it?  No.  To be honest, no.  Thanks.  But maybe it's just limited to my experience.  Thanks for a great talk.  Are there any other questions?  Okay, then.  Thank you again.  Or it was too complicated or it was really easy.  So, no questions.  I go for the second one.  Thank you.


url: https://www.youtube.com/watch?v=yKY7Bvpb45M
title: Orange Is The New Black - Fish_, Cherry & Stef
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=yKY7Bvpb45M",
    "title": "Orange Is The New Black - Fish_, Cherry & Stef",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 115,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Whoa. I hadn't expected this one. About a year ago, the three of us, we thought, you  know, let's do something for the community and start a conference. We did it before,  and we thought, you know, let's do it again. And the main reason why we did it is, well,  you know all the reasons, there wasn't anything anymore, so we thought, let's kick it off  again. It took a little bit of time to get everything running, I have to say. So we were  a little bit cautious on the amount. So we thought about, let's aim on about 120 people,  let's make it a little bit smaller in intonim, and then we turned up with 300 people. Woo!  And the main important part is actually this is not possible only because we started and  we were crazy enough to put hours in it. It's possible because you guys are trusting  us to put up a nice conference. And so I want to thank you already in advance that you are  able to make this possible. We're not going to make it very long for now because we're  doing a closing with much more numbers and details, etc. But there are a few things we  want to say. First of all, I think we got an awesome program, and Stef has a few words  for the speakers. Thank you. Just a few words to everybody who is giving a talk or giving  a workshop and also all the volunteers. Thank you very much for joining us for the first  conference. I'll keep it very, very brief because we all know who we are waiting for.  Let's give it up for Wyn Schwartzout!


url: https://www.youtube.com/watch?v=kLwndegwRyo
title: Cybersecurity’s New Imperative: Metawar Defending The Cognitive Infrastructure - Winn Schwartau
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=kLwndegwRyo",
    "title": "Cybersecurity\u2019s New Imperative: Metawar Defending The Cognitive Infrastructure - Winn Schwartau",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 2965,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   That's the shortest introduction I've ever received in my life.  No, I'm done, that's it.  Barry brought me here to screw with your heads a little bit, and cybersecurity's changing  for you, it's changing for all of us.  This is the new attack surface that you're going to have to be dealing with in the coming  years.  This is what is happening around the planet, and I call it meta-war.  Meta-war is messing with reality.  It's reality distortion, changing perceptions, rebuilding your perceptions in such a way  that we kind of call it social engineering a little bit, but when you have social engineering  occurring on global stages using techniques and technologies that actually go back over  100 years, the ramifications are much more profound than they ever have because we're  talking about your identity, who you really are, who we really are, and it's the metaverse.  We hear lots of things about the metaverse.  We hear Neil Stevenson, all in, all immersive.  We have the holodeck in Star Trek world.  We got Ready Player One, some versions of Roblox perhaps.  We got the three-body problem.  All of them distort reality, and when we apply that kind of thinking to what we currently  have on the internet, version 2.0, 3.0, whichever one you want to talk about, that is the metaverse.  The metaverse is not about the technology of immersion.  The metaverse is something much more profound and ultimately much simpler.  So let me ask you, first of all, to close your eyes, please.  Now imagine it's a dark night in Greece, 800 BC, beautiful warm evening.  You can see the Milky Way constellation because there's no light pollution, and a bunch of  gentlemen are sitting around a fire, and Homer, Homer of Greek fame, is telling us the story  of the tales of brave Ulysses and Troy and the Iliad, and people are listening, engaged  in what he is saying.  Is that the metaverse?  I argue yes, because it's immersion.  Momentarily, you are immersed, even in those few words.  Some of you went there, actually, and momentarily saw what I was talking about.  When you read a book, you are immersed in it until you get pulled out of that reality.  You don't know that you are actually in an alternate reality until you're pulled out  of it.  A great story, great book, a good TV show, only reason you know you're not immersed in  the TV show is when it clicks down to SD, when something goes wrong and we're pulled  out of it.  The metaverse is all about storytelling, the narrative inside of your head, and how long  you actually become part of it and believe, absolutely believe, that it's real.  Then along came radio in the 1920s, and people like this, they would look at the speaker  and be immersed in the story being told by the radio plays, as they used to be called.  That was entertainment.  Along came 1938 in the US, Orson Welles gave a radio play called War of the Worlds.  It was so immersive, so believable, that thousands of Americans took their guns, we have a few  guns over there, and decided to shoot the aliens out of the sky because they believed  the narrative that was being told.  Then along comes TV a few years later, more immersion, and more immersion until where  we are today with the VR helmets and all of the bits and pieces to try to give us immersive  experiences.  It's all about the narrative, it's all about the storytelling, and ultimately this is the  goal that a lot of people think is cool.  Let's get completely all holodeck on ourselves, and that's called the meta point.  The fundamental belief is what the metaverse thesis is all about, it's what do you believe,  and it's all based upon storytelling, whether it's political, it's religious, it is entertainment,  it doesn't matter, or you're immersed in a video game.  It doesn't matter because you've got storytelling that has to be believable, and when it's believable,  it means that we have so much information coming into our systems, into our brains,  that we can't tell the difference, and it can be just momentarily, or it can be for  extended periods of time when you're watching a movie, and you just, you take one breath  in an hour and a half watching a movie, you have been immersed in it, and that's too much  information which becomes part of the manipulation that we see the politicians, religious leaders,  and some of the mythomaniacs, some of the crazies out there try to tell us stories that  have no basis in consensual reality, or consensual hallucination of what we think is reality,  and that manipulation works because it's about reward, and the reward, we see it with 10-year-old  kids, and that reward is digital addiction to the like button that triggers a chemical  response inside the brain that is pure addiction.  The same chemicals are released that the ones that people that take opioids are, the same  sort of feel-goods, and once we have the reward, we create the addiction, and that addiction  then creates compliance because we want more and more and more of the same based upon the  belief systems that the earlier portions of the storytelling are giving us, and this  is the cycle of meta-war, regardless of the intent, doesn't matter, and it's all about  creating realities.  We have two realities, we have our consensual reality, this is a screen, this is a floor,  there's a curtain, we sort of agree about that, but the subjective reality inside your  head is something entirely different.  How do you communicate, how do you tell somebody what you're feeling?  How do you communicate to somebody what's inside of your head when there is no reference  point for the subjectivity of what you're experiencing?  Regardless of whether you can communicate it or not, the influencers, the politicians,  all of the people that are trying to make you believe something that may or may not  be real, we call it fake news, disinformation, what have you, that's what creates a subjective  reality that is dissociated from our consensual hallucination of what we believe, and how  much of it is bullshit?  That's for each one of us to determine.  Our reality, when we look at it from cyber security terms, is built with 11.1 megabits  per second of input to our brain.  Think about that for a second.  That's a shitty MP3 file.  But our reality is created with that.  Everything you see around you, everything that you're hearing, everything that you're  feeling and if you're sitting next to somebody, perhaps smelling, is with 11 megabits per  second of info.  That's it.  That's an amazing amount of computation that's going on inside of our ears, inside of our  eyes.  Our eyes receive with 576 million receptors.  We see this and it's compressed to under 10 megabits just for the visual component.  How is this possible?  How can we influence this?  How can the good guys use it?  How can the bad guys use it to change and alter our perceptions of reality by messing  around with our senses?  Because that's what makes reality.  We have our vestibular system, which is our balance.  It's another sense that we often don't think about too much, proprioception.  All that means is how do I relate to the physical world around me?  How do I fit into it?  Am I going to bump into somebody?  And then interoception, our body has its own set of senses as well that tie to our external  senses, the internal senses, external senses, and every one of them is manipulable, can  be orchestrated by content.  It's all about the narrative.  And then in order to make things even more believable, we add feedback.  And that feedback will go just to gaming, the haptic feedback.  You're sitting in your racing car thing, you got the monitors sitting there, and your seat  is bumping around and you're driving your car.  How real is it?  What does your brain think versus what your consensual hallucination says?  Somebody that's watching you is seeing the physical manifestation of it.  You are experiencing something completely different based upon sensory inputs.  And again, it's only 11 megabits, that's it.  How easy is it for us to do this, for us to alter reality?  And this is about the feedback mechanisms.  Has anybody read the Apple patent on their new earbuds that are coming out?  The patent came out last year.  Anybody read it?  38 biosensors are going to be put into your ears.  What are they going to do with those biosensors?  They're going to know your brain waves, your emotional states, blood sugar, response, emotional  response.  And what are they going to do with that information?  That becomes part of the feedback loop to create a more immersive experience.  Is that good?  Is that bad?  Or is it a capability that we're going to have to deal with as cybersecurity professionals  because the techniques are so similar to what we are used to?  We are used to feedback mechanisms and looping around and the OODA loops in order just to  make our world work in the pure cyber world.  But now we add the human component to it.  And when we add the human component into this, we have active metacontent orchestration.  That means how can I use today's technology to mess with your entire sense of reality  so that you no longer can have a basis of deciding what is true, what is not true?  What are you really experiencing?  Are you schizophrenic?  How do you tell the difference?  And this is what gaming does.  This is what advertising does.  This is what all communications do that try to engage with the customer.  That customer doesn't have to be about money.  The customer is the recipient of Homer's story in Greece or reading a book after Gutenberg  started printing.  Very, very simple, simple ways of influencing the brain.  And when we have the feedback loops completely put in with the face tracking, the eye tracking,  the biosensing, what does that mean?  It means that that loop knows how we react to every single bit of input.  11 megabits per second coming into our sensory inputs triggers a response.  And what are we doing with that response?  We're telling big tech exactly how we respond to any given stimulus.  That's what advertisers count on.  They want you addicted to their products by being addicted to the message, by being addicted  to the narrative, the story that they're telling you, regardless of whether it's true or not,  makes no difference.  This is the world that we're building right now.  And this is the world that cybersecurity, our field is going to be dealing with more  and more and more.  It's way beyond pure social engineering because we can now, with existing technology, create  these emotions inside of anybody who's participating in any sort of immersive experience.  Obviously, the more tech, the more immersive, the more susceptible your brain may be to  external influence, you'll get more influenced by it.  Some people get influenced by one TikTok video and their life changes.  Some people go back to the same TikTok feeds and have to watch 100 of them every day in  order to get their fix, to create one of these emotions.  That's the full emotional gamut of human beings.  With active content orchestration, we know how to create these.  Is that a good thing?  Is that a bad thing?  And what can we or should the cybersecurity community do?  We can read minds today.  On the left is a picture that was shown to a subject in a test lab.  On the right is what the brain scans showed he was thinking about.  This is real.  Do we want it?  Do we want to be able to be able to read minds with this level of technology, this level  of detail, and build it into how we perceive reality?  Then, because of the feedback loops, we're going to tell Facebook, we're going to tell  Google, we're going to tell big tech exactly what we're thinking.  Do we want that?  And is that a good thing or a bad thing?  And how can we control this?  Should we control it or should we just let big tech do this?  This is the new attack surface, and the attack surface is your eyes, your ears, your sense  of smell, all of the senses.  When you have, I have vertigo.  When I get too close to the edge of something, I get really quite dizzy, but I can also have  it induced by watching a movie.  A helicopter flies over the edge of the Grand Canyon.  I tip over on my couch because of vertigo.  Can I simulate it?  Can I create these types of emotions, these visceral, physical responses?  Can I create them using technology, using immersive?  Of course I can.  Should we be able to do this as part of what we're going to have to be deciding from policy  makers across the planet?  Because when we look at our technical versions of what we've been doing for 35 years, and  we map it against the mind, the approach is very, very similar.  When we deal with DDoS, for example, technically we understand that it's a flood of information.  But how many of you have ever been overloaded with information at the end of the day and  go, fuck it.  I'm just going home.  I'm not going to deal with it anymore.  What about 10-year-olds?  Are they mentally equipped to be able to recognize their own DDoS, their mental DDoS?  Probably not.  That's a maturity thing, and I only heard half of you recognize it, so I'm worried about  some of you as well.  We have all of the parallels from what we have been doing, from the field that we know,  that need to be applied to the mind, need to be applied to reality distortion, because  reality distortion is not only full immersion.  Reality distortion creates—who won the election in the United States in 2016, the Americans  or the Russians?  Reality distortion because of the sheer number of people who bought into a narrative that  was addictive because it made them feel good about themselves and had no basis in consensual  reality agreement.  We were not humans.  We're not built to survive technology.  Our primary goal as human beings or as dogs or as plants is only one thing—survive.  That's all that we are designed to do, regardless of whether you think that there's a higher  power that created us or the aliens created us or whatever it is.  Our primary goal is to survive, and that's it.  But we were designed to survive bears.  We were designed to not drink dirty water.  We were designed to survive nature, not false narratives, not technology.  And we see the manifestations of all of this technology around us that we're not really  sure how to deal with, and in many cases, we choose to ignore it.  In the simplest terms, we have in our brains two systems.  It's much more complex than that, but easily to look at is system one.  It's our gut reaction.  And in America, I call, I go up to my friend Hans, and I go, hi, you're an asshole.  And in America, his gut reaction is to pull out a gun and shoot me.  That's system one.  It's that gut reaction, that visceral kind of, and we all have it all the time.  And when somebody says, oh, no, that's not, well, maybe I should think about it a little.  That system one is what keeps us alive.  When you're walking down the street and you hear the horn from a car, your brain is automatically  determining its distance because of that crazy computer, analog computer we have in our heads.  Do you have a visceral reaction to jump back?  Maybe, maybe not.  If the car is honking at you from only 20 meters, you're going to react differently  because you're going to suspect more of a threat to your existential being.  It's more of a threat to your life.  System two is when we actually think.  Critical thinking, cogitation, discussion, debate, actually engaging our conscious minds.  System one is unconscious, if you want to use Freudian terminology, William James terminology  from the 19th century.  System two is where we actually think about things, but here is the problem.  In this incredible computer that we have in our skull, system one processes roughly  400 billion bits per second.  That's a lot of numbers.  Our conscious brain processes approximately four kilobits, a hundred million times less.  I just ask you to think for yourself right now, who's really in charge?  Is system one in charge of you or is system two in charge of you?  What can an adversary, what can the bad guys do with this knowledge and with the capabilities  of active meta-content orchestration in order to distort your reality?  Talk to system one.  Talk to system one.  You ever know anybody, and certainly this is true in the US, who listens to the same  god-awful radio station talk show host day after day after day after day and what happens?  Even though you're not paying attention, it's in the background, what's happening?  System one is being primed with a belief system automatically.  It's being primed for you to believe and accept what is being impinged upon your subconscious.  Our subconscious creates our behavior, creates that gut reaction.  System two is supposed to save our asses, doesn't work all the time, especially when  system one becomes so much believing in whatever the narrative is coming from the talk show  host, coming from the politician, coming from a religious, spiritual faith, doesn't matter.  Enough input of repetition over and over, talking to system one, makes it part of your  innate belief system, true or not true.  In order for us to survive, we have some built-in mechanisms and the ones on the left, we're  familiar with those, flight, fight, freeze, happened to me, I was in Japan, I went to  one of those VR things and all immersed in the suit and what have you and they put it  on and they give me a long 20-minute lecture on how this whole thing works, right?  In Japanese.  So I go in and it's this huge warehouse space and it's black, all the walls, floors are  black and there's white lines just like the holodeck on Star Trek and I knew, even though  I don't speak a word of Japanese other than sushi and sake, was 10, 9 and suddenly the  world changed, my belief system completely changed.  I was now standing three stories up on a wobbly scaffolding.  Every part of my being believed it.  My system two is saying, no, this isn't real.  My system one is going, yes, it is.  And I absolutely, completely froze.  So I wasted $50 by not playing and shooting too many aliens because I was scared out of  my mind.  That is complete immersion.  That changes everything, even though I consciously knew it wasn't real.  Every part of my being said something completely different.  This is how we react to things automatically.  This is all that we have in our reaction systems which makes the meta-content orchestrators,  the bad guys, makes it really easy for them to be able to focus on any of these because  our relationship with technology is not natural.  We were not designed to do this.  Some people love tech, hate tech, we all have been through the love-hate relationships with  it.  Who has never cursed technology?  Hans, come on.  Everything always works for you, right?  Okay, Hans, you can talk to him.  Never has anything gone wrong.  This is our relationship with tech.  And this is what we expect from tech.  This is sort of what we've been told over the years, whether it was early Microsoft  days, early DOS days, DEC, IBM, it doesn't matter.  We're told the same thing over and over again by big tech.  And it's always, the next generation will even be better.  The next generation will be more immersive.  Do we want that?  Do we need that?  And is it a good thing or a bad thing to have?  These are the disconnects.  These are the attack vectors that are being used and will continue to be used by whoever  is playing, whoever wants to convince you of something.  Is it the advertiser who says that you need a better baby food formula for your kid or  you're a bad parent?  Or you have to drive a certain kind of car because it is the best because of these reasons  that are trying to convince you.  It's all about believability.  And the advertisers over the years, they know how to do this.  They've been messing with our minds for a long damn time.  Now we're adding the technology with different motivations.  These are the fundamental issues that we've got that are really messing with us.  And we hear constantly about disinformation.  And yeah, disinformation is a big problem, absolutely.  But there's something certainly a lot more fundamental than disinformation that's causing  the schisms that we are seeing in society today.  That was a five megabyte hard drive in 1956.  Anybody still have one in their garage?  God knows how much power that took.  What we're dealing with is too much information.  We all go through this, especially geeks.  We go, that's enough.  I can't take it anymore.  I've got to shut it off and that's it.  Can't do it.  And then you freeze because we're used to receiving information so constantly.  Too much information.  We don't know how to filter it.  How do we digest zettabytes of information?  And the information age, I argue, roughly mid-1950s when we started producing massive  amounts of information that are constantly coming at us.  Who taught us how to filter it?  Who has taught us what information is valuable, not valuable, a pain, disinformation?  It's all because of too much information.  And when we look at the total amount of information that we are being subjected to daily, our  capacity, if we are awake and alert 24 hours a day, our capacity is 74 gigabytes of data  streaming at 11 megabits.  That's it.  Anything beyond that, we go into overload.  Or we fall into disbelief systems or a false narrative.  Or we begin believing in many ways like a schizophrenic.  We see something and we make something up out of it, pareidolia is what it's called.  And that's what happens with information overload.  How many of us have actually been to school and they taught us, here is how to filter  information so you don't get overloaded?  How many of us have been teaching our kids this?  You had one.  Okay.  You got one hand out of 7,000 people.  Okay.  Teaching kids too much information, how do you filter it?  How do we get through the noise?  Something that we don't do terribly well.  And when we look at the experiments that are being done, what is causing this disinformation,  this stuff all around the planet, all the lies that are being told in order to create  social movements, political movements, whatever they happen to be.  The studies have been done.  The trigger of disinformation is too much information because we don't know how to filter  it.  We don't know how to filter it at all.  We're not taught that way.  We're said more and more.  In order to be smart and successful, you have to have more information.  That's almost the exact opposite because we're dealing with too much information.  We can't filter it out.  And what is important information?  What really matters to our survival?  It's a new problem.  When we look at some of the studies that have been done out there and they look at, this  is out of Cambridge, who is more susceptible to disinformation in the United States?  It turns out to be those of the conservative political bent.  By a factor of 250%, they believe bullshit easier than progressive, liberal, whatever  term you want to use.  And what does that mean?  That means that they are targetable.  They can be influenced so much more easily because of their preexisting mental system  one reactions.  The studies and the science is very solid on all of this.  So cybersecurity people, we can help with all of this, of course.  We need to learn how to coexist with technology as a species, otherwise we're going to lose.  Because he who controls, they who control the technology control the narrative.  The narrative for you, the narrative for society, the narrative for any culture or country or  organization.  They control that narrative.  And when they control that narrative, they're using what?  They're using algorithms.  How many of you live algorithm free?  I got one person up there who is about to commit suicide.  Think about living algorithm free.  Who's making the decisions for what you receive in information?  It's part of that feedback loop because while they may not be sensing your particular brain  waves right at the moment, or you may not have the apple buds that are sensing exactly  your emotional and chemical composition moment by moment, but they do know how to influence  through repetition.  They do know how to influence through marketing, and they know how to do it for politics.  We've seen it.  And the work comes from some Russians, and I'll show you how that all ties together.  Technology is not only addictive, but it's a stressor.  How many of you check your battery more than twice a day?  Those without...  Okay, you're all raising your hands.  Yeah, because we're worried.  It's a stress.  It's an anxiety.  All of these things are about anxiety and addiction.  Up on the left, how many of you ever done that?  The rest of you are lying, okay.  We've all done this.  One way or another, this is about our addiction to the technology that is created by too much  information and the control that the algorithms have over our behavior.  And this is the way it is today without even looking down the line with future technologies.  Now we're going to add AI to it because AI fixes everything.  Well, we built AI in our own image.  We don't like what we see, do we?  We have a problem with the way AI...  Otherwise, the global debates over it, should we allow it?  Should we ban it?  How do we control it?  Well, we don't know that answer, but we do know that it's all about bias.  We do know it's a black box.  We know what we can see going in.  We can see what's coming out, and we have no idea how it is being done.  Just like a human being.  We have an input, we have an output, and we are a black box.  Come up with some answer.  I'll say something.  You'll give me an input.  I'll say something.  You give the same input to Hans here, and he'll give you something completely different.  Piece of Hans bullshit.  We made it to look like us, and we're not happy with this at all because we don't understand  how it works.  When is AI good?  It's good for translating.  Sometimes I use it when I travel, and I know I did try to marry some guy's dog somewhere,  and that didn't exactly go well with the translator.  But when close is good enough.  When you have authority.  When you have human interaction to be able to finally make a decision, hopefully bringing  in system two thinking, because everybody else is writing and saying, no, AI is going  to take care of everything.  I went to the CES, and my wife bought an AI-controlled vacuum cleaner.  I'm still not completely convinced because the vacuum cleaner is losing the war with  my cats.  And what happens when AI gets angry?  I didn't like that question when I'm going to fuck with you now.  How do we know?  How would we ever know if AI is angry, has an emotion?  Is there a Turing test for any of this shit?  No.  Do we need one?  Yeah.  We need some sort of discussion over being able to recognize tipping points, just like  we do in cybersecurity.  It's the same thing, except with a different technology, and the technology is in our minds.  And today we talk about privacy, PII, personally identifiable information, and it's bad.  And that's why we've got GDPR over here.  We've got shitty-ass laws in the US that don't do anything, all to protect privacy.  But what if PII suddenly had no value anymore because with the feedback loops and the sensors  and the body tracking and eye tracking and emotion tracking technologies, I then have  personally identifiable behavior, PIB.  And we're already getting there.  We're already seeing it.  People know how to induce that you to press the like button, the buy button, the review  me button.  We are programmed to do this because they know how to trigger our behavior because they're  monitoring our behavior.  Is this a good thing?  Is this a bad thing?  And how do we control this from a policy standpoint at the national level and at the enterprise  level?  These same issues occur not only for us personally, but these are issues for the enterprise because  they're security issues, except there's a different processor involved.  It's a warm, wet, hunk of wet meat versus the silicon.  How do we make these all work with each other?  The addictive process is a loop, just like any other OODA loop.  And how do we stop it?  Well, when it comes to physical addiction, they say, cut the loop, stop the process.  That's what they claim.  But that requires an awful lot of human endurance to be able to go through that.  However, we do have the technical ability to cut some loops, don't we?  What if there were no more like buttons that created digital opioids?  Is that a good thing?  Or do we just cut that loop for kids because it's messing with their brain's development?  Cut the loop.  Do you want to be influenced by which algorithm to tell you what to buy?  Or should that loop be cut?  Should we have the choice to live an algorithm-free life?  Which algorithms do I want part of my decision-making process?  Which algorithms do I not want?  Why don't we have the choice?  We don't have the choice because Silicon Valley's mantra is, if your product, your idea, your  service is not addictive, it will not get invested in.  That's the world we're living in.  If it's not addictive, it's not worth playing.  How do we defend the cognitive immune system?  We have an immune system.  Humans are pretty good bullshit detectors if they're given an opportunity to do it.  But an awful lot of people are living in a pure system one world where their bullshit  detectors part of system two do not come into play.  How do we get the immune system, mental immune system strengthened?  How do we build in critical thinking?  And then an idea that has been ignored is called critical ignoring.  Critical ignoring.  Instead of being bombarded with all of this information all the time, shouldn't the first  question be, do I even give a shit?  Do I care?  If you ask that question first, your information overload, what's coming into your system one  and system two processing will absolutely decrease.  And it is the same thing we do with cybersecurity.  When cybersecurity, if we see an event, we go into a pause mode.  We go into a further analytic mode.  We engage deeper analytic servers.  Maybe bring in the sims.  What's really going on here?  The brain works exactly the same way.  If we know how to turn on that pause button, and it's all about creating a momentary delay.  Just like your parents said is when you were a kid, you get wrong.  Take a breath.  Count to 10.  Think about it.  Or as women say about men, give them a couple days, they'll come around.  It's about that pause to engage system two thinking so that our automatic system one  stuff is not doing all the reacting like we do in the U.S.  I have a neighbor, when there's a black guy who does delivery pizza, she makes sure to  answer the door with a gun.  System one lives well and strong near where I am.  And it's all about engaging system two.  How do we get it to become engaged?  And it's not just system one or system two.  It's a constant analog flowing continuum.  It's a process that we have to become accustomed to.  And it's exactly what we do in cybersecurity.  How much time and effort goes into primary analysis and detection reaction?  How much goes into deeper analytics?  We go two layers, three layers, doesn't matter.  But the process is exactly the same.  And we got to just hit pause in the brain.  And the techniques to do it are pretty well established and they go back 60 years.  And it was anti-propaganda, mind control from the 1960s, Professor McGuire.  And then for some reason it was ignored.  It was ignored until early 2010s.  And some guys in Cambridge said, we wonder how we could get people to think better.  How do we engage system two?  And they found out that playing a game does it.  And for those of you who are interested, take a look at Bad News.  It's a game.  Cranky Uncle.  Harmony Square.  These are all disinformation games built for that reason, to try to get people to not believe  so much bullshit.  And the term that they have developed for this is called pre-bunking.  And pre-bunking basically means, hey, I'm about to tell you a couple of lies in the  next 10 minutes.  What have I just done?  I've primed them that I'm going to lie.  Then I tell them some stuff.  His bullshit detector has increased, because I pre-warned him.  These games used at enterprise level and at the individual level absolutely build up your  cognitive immune system.  They strengthen it.  And the numbers exist.  The curves exist.  And you have to do it periodically, like any good vaccine.  It's a mental vaccine.  And all we're doing is creating another OODA loop in order to get us to think better.  There's a ton of these games out there that get into the critical thinking, critical ignoring.  But you have to have had first to get people to care, get people to give a shit, to be  able to want to learn how to engage system two.  There's cyber ranges that are being built right now for mental immune system strengthening,  where you have battles, information battles, true information warfare in the way that the  Russians think about it.  And that's, do I give a shit, is the first thing that you have to ask when you're being  bombarded with headlines coming streaming at you.  And you do it naturally.  You're scrolling through all the crap that comes into your inbox.  You go, no, no, no, no, no, until you see something.  So you're already doing it to an extent.  How do we get the whole planet to actually engage in critical ignoring, avoiding the  rabbit hole, and avoiding too much information?  The Russians defined it.  If you've never read the work of Yuri Bezmenov, I suggest you do.  He was a Russian propagandist for the KGB in the 1960s.  And everything that he has said, back with a book called A Love Letter to America, published  in 1984, describes exactly where we are today.  Exactly where we are.  So then I started looking at, what are we doing about it?  So any idea how many of this, anybody have an idea on the answer to this question?  Shout it out.  Not all at once, please.  Zero?  What'd you say?  200.  200.  That's the answer.  Somewhere in there.  Between Project Horizon, DACAS in the UK, the EU and UK spend about 5 billion euros  a year working on cognitive strengthening.  US, how much?  90.  You're fucking right it is.  Not funny.  Not funny, because you see what's going on in the US right now.  Over here, there's a whole lot of it.  A tremendous amount of awareness that is being put into defending entire populations.  Finland, Sweden have some amazing programs going on.  UK has got some ones that are coming out of the military.  EU is still trying to figure out, what do we do?  How do we implement it?  But they're getting there.  And then the United States, we're defenseless.  Right now, the US is defenseless against cognitive attacks.  And because of certain political forces in the US, virtually every one of the private  and public cognitive defense efforts were shut down by threats.  That's scary.  That really depressed the hell out of me when I discovered that.  We need hackers.  We need the cybersecurity community.  Because the technology of silicon, the technology, the system of our brain,  they're really the same.  Just different approaches, different tweaks.  But the models, the systems behind them, the detection, the reaction mechanisms  are all things that we're completely familiar with that have not been applied to us.  We have the maps.  We understand the basics of the models.  Now, how do we implement it?  How do we get multidisciplinary groups, led by hackers,  led by the cybersecurity community, in order to create an ability for us  to survive technology?  How do we learn to coexist peacefully with technology?  Otherwise, we're just going to give up control completely.  I hopefully have completely depressed you this morning.  But it's up to you.  It's up to cybersecurity.  The misinformation groups, the psychologists, the neuroscientists,  all the people I've spoken to, they've all said to me,  cybersecurity guys, please come help.  Cybersecurity people are problem solvers.  It doesn't matter what the problem is.  We enjoy the shit out of solving problems.  Well, dudes, we got some problems.  And I invite you to become part of the solution.  Hopefully I haven't depressed you too much.  Thank you so much.  Thank you.


url: https://www.youtube.com/watch?v=KOqfjjzCLQE
title: Low Energy To High Energy: Hacking Nearby EV-Chargers Over Bluetooth - Daan Keuper
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=KOqfjjzCLQE",
    "title": "Low Energy To High Energy: Hacking Nearby EV-Chargers Over Bluetooth - Daan Keuper",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1360,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Welcome to our talk. We are Thijs Alkmaar and Daan Keuper, and together with our colleague  Khaled Nassar, we are the research department of Computest. Computest is a security company  from the Netherlands. We're an office in Zoetermeer. They do security services like pen testing,  incident response, we've managed SOC, red teaming. But we are the research department,  which means that we don't do work for customers, but we do research for public benefit, research  projects that help society, make it a bit safer, but also being able to talk about the  research that we do. And one of the activities that we like to do is Pwn2Own. This is a hacking  competition. In case you're not familiar with it yet, it's very different from a CTF. So  the idea behind Pwn2Own is that it's a competition for finding actual zero-day vulnerabilities  in existing software. So it's organized by a company called CDI. And a few months before  the actual event, they set out a few targets. They tell you, you're going to get this reward  if you manage to hack it. And then teams start working on them, typically at least for a  few months or a few weeks. And then at the event, they just go there, they run their  exploits to demonstrate that it works. And then you get a reward. So the reward depends  on whether there are other teams targeting the same thing as well. Typically the first  team that successfully demonstrates a vulnerability gets a full reward, but any later teams get  a lower reward. And if you have the same vulnerability as another team, your reward is even lower  again because they don't want people to share their vulnerabilities.  So we participated in Pwn2Own now three times. So the first time was in 2021 with Zoom, which  was very important at that time. And then a year later, we looked at industrial control  systems, like the fuel systems used in factories. And earlier this year, in January, there was  a new addition, one focused on automotive, where we also participated. It has various  targets, like it had a Tesla with different subcomponents of the Tesla. There were automotive  operating systems, infotainment systems, and the targets that we had the most success with,  that were EV chargers. And for three different EV chargers, we had  exploits, which means that we could take them over, get full control over the device, just  with an arbitrary code. And for all three of them, we had a way to do this just by being  in Bluetooth range. So we didn't need to be on the same network. We didn't need to have  like a password or whatever for the device. We just stand somewhere near it, connect to  it, and yeah, we can take it over. So we did that with three different devices. This is  a Juicebox 40, the Autel Maxi Charger, and the ChargePoint Home Flex. And all of them  have similar functionality, like these are home chargers. So this is something you get  installed at home, but typically you need an electrician to install this, but they're  not superchargers. They don't go for the very high energy. And they have similar functionality,  like they have an app, you can do scheduled charging, you can see how much energy has  been used already, that sort of thing. And all of them were like typically IoT level  of security. Clearly not much thought has been put into the development of this firmware.  So this was for two of them, anybody in Bluetooth range could just connect to them. There was  no authentication on that part at all. And for the third one, there was some authentication,  but it had a backdoor in it. So anybody who had that backdoor token could just connect  to it. Now, sadly, we don't have that much time today, so we cannot really talk about  all three of them. We're going to focus on the ChargePoint Home Flex. But if you want  to know more about the other chargers and how we perform research, or if you want to  do something like this yourself, we have full write-ups for all three of them. I think we  posted the latest one today on our website. So yeah, we're trying to help other people  do research like this, maybe on the same target or similar targets. So that's why we also  publish full write-ups on what we did and how we approach our research.  So the ChargePoint Home Flex, this one is a bit different from the other two because  this one runs Linux. But we did first need to extract the firmware from this charger.  This is our setup for doing that. This charger, it would boot Linux and it would boot automatically,  so we couldn't tell it to change how it was booting. We could connect over Telnet, but  there was a password, a root password, that we didn't have. But luckily, JTAG was enabled  on this device, which typically is disabled in production devices. But luckily for us,  this was not disabled here. So during boot, we could pause the boot loader, tell it to  not automatically boot its configuration that was saved, but then just make it wait a bit  so we can change the boot configuration, add a new user so we can log into it. And then  we had access to the device while it was running. And why did we need to do it? Well, we didn't  have the firmware for this device. So we don't really know how this kind of thing updates  itself. We know nothing. So we need to know what code is running on there. So we needed  to extract that first. So by just following these steps, getting access via the hardware,  we were able to just copy all of the files once we had access.  Now one thing that differed from the other two chargers from this one is that there was  prior research for this charger. Kaspersky in 2018 looked at the same charger and they  wrote a full report on this with how they researched it, what kind of things they found  and made all of this public. And back then they found that there was a stack buffer overflow  when you set the Wi-Fi password. So typically how these chargers work is you connect over  Bluetooth to the charger. The first time you set it up, you give it your Wi-Fi password  or the password for your Wi-Fi network and the name, and then it connects to that. And  then you don't need to use Bluetooth anymore. So it was one packet that you needed to send  and there was a buffer overflow in that. So of course, this was six years ago. You don't  expect new vulnerabilities there. Well, not in the service itself. So the way  that this works is you send first a password that goes to a binary called onboardee. And  there's some inter-process communication happening to a binary called WLAN app, which handles  all of the setup for the Wi-Fi password. And typically how these devices work with  Wi-Fi is that they don't use a password itself, but they derive a key from the password immediately.  But they didn't want to implement this. They saw there's a command for that. So they just  copy all of the data into a shell command and execute it without any verification or  escaping or whatever. So yeah, this is a straightforward example  of a command injection. You just put a double quote in there and then some semicolon or  whatever, and then you can run extra commands. So this charger, I think we, no, this one  we ordered end of October. So all of these chargers were American models. So we had to  order them on Amazon and it took weeks for them to ship to us. We ordered this one end  of October, but then Amazon lost our package. They told me it was probably delivered. They  really said probably, but it hadn't shown up. So we had to reorder it at like December  1st, I think. So it was like almost Christmas when this thing came in and yeah, it was getting  near the competition. So we really had only a few days to work on this charger. And Dan  and Gert were doing all of the JTAG stuff with the U-Boot and whatever. And then within  a day they had this and they had this command injection. And I was like, I don't believe  you guys. You're saying this is way too easy. No way that this actually works here. But  yeah, it did work. And as I mentioned before the competition, you get a lower reward if  other teams have the same vulnerability. And we hoped sort of that there might not be that  many entrants for this competition, but that turned out to be completely wrong because  there were seven entries for this charger and we were seventh out of the seven. And  then like we saw the attempts on the first day and we don't really know what vulnerabilities  they are using, of course, because they are still zero days. So they need to keep that  quiet. We saw on the schedule that the first team succeeded, but then all of the following  teams all collided. So this made it very likely to us, if you look at like the prior research  from Kaspersky, that everybody just had looked at the same parts and everybody had the same  bugs. So we were there in Tokyo and we're, yeah, a bit annoyed because, yeah, we just  know that we're going to do up on this. So then we sort of started to look at it a bit  further and I'm going to hand it over to Dan for this part.  Yes. So we had around 12 hours remaining before entry was due. So it was around 9 PM in the  evening and we're like, okay, fuck it. We're just going to try to find something new. We  have nothing better to do. We went clubbing three nights in a row. So we thought, okay,  this night we're going to just spend all night, see if we can find a better vulnerability  to avoid a bug collision. So this all was made possible because our hotel had a beer  vending machine, which kept us awake all night. So at least I was a little bit sleep deprived.  We were jet lagged. So we couldn't sleep the nights prior. We went clubbing a couple  of times. So we hadn't slept in a couple of nights. But due to this vending machine, we  pulled an all nighter trying to find a different vulnerability that might not collide during  the competition. So we didn't actually have the charger with us because we thought that  might pose problems with customs if you bring a charger through customs. Turns out that's  not true because we got a new charger from the competition leader for further research.  So we took that back in my backpack and no problems at customs whatsoever. No questions  asked. So apparently you can just bring your EV charger across the border. So we didn't  actually have the charger with us. We did have one in the office where we could remotely  log into. So every Bluetooth vector was now out of the question because we didn't have  the charger to actually test any vulnerabilities we might find in the Bluetooth packet handling.  So we were bound to network attacks. So this is the services that the charger is actually  running. It has a Telnet daemon running at all times. But since we didn't know the root  passwords, we deemed it uninteresting. It had an outgoing WebSocket connection to the  ChargePoint cloud. And we looked at this prior, but it seems to validate the certificates.  So we also deemed that uninteresting. And it had an outgoing SSH connection that would  actually fail because the service it was trying to connect to no longer existed. But the service  was a bit strange. It would connect to some cloud service and it would use that to reverse  proxy the Telnet port to the charger. I'm guessing this is some kind of maintenance  daemon. Like this way ChargePoint will always have Telnet access to every charger to do  emergency maintenance or support. But yeah, since we already had access to the Telnet  port, if you were on the same network, we also deemed that SSH connection not that  interesting from an attacker point of view. So we decided to go back to that WebSocket  connection for a little bit to see if certificates validation was indeed correctly implemented  or maybe they use an outdated version of some SSL library that would contain vulnerabilities  or maybe we could make it drop back to an HTTP connection or something.  So this is the configuration file. Here you see the URL that it would connect to during normal  operation. And it would indeed see that it has the verify hostname setting set to one,  which we assumed would make it set to true and would indeed verify the hostname.  We looked at the binary a bit more and we learned that it used curl for all the WebSocket  communication and that this setting was actually setting the SSL verify host option in curl.  So looking a bit more closely at these values, well, actually there are three values. You have  zero, which means don't do any verification. And you have two, which means do certificate  validation. And there you have one. And one is a bit of a foot gun. It's some sort of debug value  that was also promptly removed from curl because nobody understood this correctly, of course.  Luckily, ChargePoint didn't update their curl library in quite some time.  So it was earlier than version 7.28. And what version one means, it will check if  the certificate is signed by a valid CA, but it wouldn't check the domain name. That's basically  what it said. But a valid certificate or signed by a valid CA in this  situation means that it needs to be signed by a certificate from ChargePoint. But luckily,  the device had just a certificate for us because it also used client-side authentication. So we  could just extract. And it was signed by the same root key. So we could just extract that certificate  and use that to man-in-the-middle the WebSocket connection.  So at this time, it was around midnight. Beer started kicking in. We're slightly  past our Balmer peak at this point. And we were researching this from a hotel in Tokyo  with a drum and bass from a crappy laptop speaker. And the charger was, of course,  in our office in the Netherlands. But, yeah, it was near 5 p.m., so the office would close.  So we were like, okay. At this point, we also learned that we were running the incorrect firmware  on our charger. So we already knew, like, okay, if we crash this thing, we have no way to log  back into it or do any further research. So whatever vulnerability we find, it needs to be  easily exploitable. Because if it crashes, we're done. We also learned, because we have the old  firmware, that most offsets are most likely wrong. So any memory corruption where you need offsets  also will most likely not work. So we thought, okay, we really need a simple  vulnerability here. Like something like an arbitrary file write or just a system command  injection would all do the job. So we spent the entire night trying to find a message that would  lead to arbitrary code execution. This is the format of the messages that go over that bus.  We spent all night. It was quite messy, because the whole IPC layer made it very difficult to see  where each message would go to. But in the end, we found a message that we could send, where it  would extract something from the payload it would receive from the cloud, and it would directly slap  it into a system command. I have no idea what the normal uses of this command is, but we had  straight up command execution. So we wrote the report, went on the metro without any sleep to the  venue, and luckily it worked. We were the seventh team, but we found a new vulnerability that it  didn't juke. So we're very glad we managed to pull this off.  So I'm also seeing that we're nearing the break, but I want to go back for one second to that  SSH connection, because we also looked a little bit deeper into that silly SSH connection,  and this is the init script that actually spawns that shell service, SSH service.  It has several hosts that it can connect to, based on in which year the device was produced. It had  one for 2016, 2017. Of course, we're now in 2024, and it didn't have any hosts for that year.  So it would just fall back to the normal URL, the default value.  But that host was no longer online. So we tried, hey, can we maybe with our charger log into any  of the other hosts, like the older versions? And it turned out we could. Our SSH key would work  on one of those older systems. They call it the mothership.  So this is basically what it does. Based on your serial number, it would claim a port,  and it would open a reverse proxy to your local Telnet daemon. And we could log in. We tried,  of course, if we could get a shell, but that didn't work. So they had thought about this a  little bit. But then we thought, okay, if we can do reverse proxies, we can also do  forward proxies. So can we maybe connect to other chargers via this host? So we tried some other  stuff to see if we could get that to work. And indeed, we could connect to other Telnet  services of other chargers. But of course, we didn't have the root password, so  yeah, that wasn't very useful. So then we thought, okay, can we maybe connect them to  other hosts outside of charge points? Like an open proxy sort of thing. That also works. If  you can make one tunnel, you can probably make more tunnels. So, okay, cool finding. Open proxy,  maybe not very useful, but okay. Until we learned that this service is hosted on AWS. We're like,  oh, and we connect to the meta service of AWS. Well, it turns out we can.  So we extracted all kinds of access keys that this specific instance had. We're like, okay,  I hope this instance doesn't have much access to some of the charge point resources. So we thought,  okay, let's list S3 buckets. Oh, wow. They had 142 S3 buckets. We had read primitives on all of  them, it seems. Some have very interesting name with prods, but also PAI, data lake, payment  details, et cetera. Yeah, we stopped our research here because this was outside of the scope of the  competition. But, yeah, it was interesting because two weeks ago or so, there were some  questions in Parliament about some research that you could control, like, 4 million solar panels,  and that could have a very negative impact on the electricity grid if you can control  so much solar panels at once. But if you think about it, this problem is, of course,  much bigger than only solar panels. There are much more devices that either consume a lot of power  or produce a lot of power that are all connected to some cloud of some manufacturer  that didn't really take security into account. So with that in mind, I would say if you want to  know more about our research, please go to our website. You can find all three write-ups of all  three chargers. If you're interested in participating in Pwn2Own, there's one coming up  in October. There are some crappy IP cameras as targets, so I'm sure you're going to have fun.  And if there are any more questions, I'm willing to answer some questions. Thank you.  I had to grab that first. Are there any questions from the audience?  Nobody? Everybody wants to go for a break?  Can we then please have another big round of applause for...


url: https://www.youtube.com/watch?v=Rv0otVFKrkk
title: Making Penetration Testing Auditable - Brenno De Winter
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=Rv0otVFKrkk",
    "title": "Making Penetration Testing Auditable - Brenno De Winter",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1818,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Welcome, Noé.  Indeed, my talk today is about making penetration testing auditable again.  For the people that know me, of course, there are a lot of cats in my presentation.  You might think that doesn't serve a purpose, but you might be wrong there.  Okay, I'm Brenno de Winter.  I'm currently part of the CISO team of the Ministry of Health, Welfare, and something  else, and today we're going to talk about penetration testing, and let's have a quick  look towards what the legislator is requiring from us.  One of the big things that is happening this month is that this too will come into effect,  into full effect.  Also in the Netherlands, I know that a lot of people out here that think that it doesn't  start.  Well, it does start.  We don't have a Dutch law yet, that's a different story, but we're also getting the Cyber Resilience  Act when you are developing software, and these laws basically are shouting for assurance.  On the normative side, we have got frameworks for the non-Dutchies, the ISO 200007123.  For the ones that are working within the Dutch government, we've got the Baseline Informatiebeveiliging  Overheid, which is basically the 27001 and 2, and in healthcare we've got the 7510, which  is more or less the same, only the focus is a little bit different.  If we use software, or if we make software, and we fuck it up big time, and people are  involved, the GDPR kicks into effect, and the GDPR has an article, article 82, that  basically says like, if you fuck up, you pay for the damage.  So introducing software has liabilities, and those liabilities you want to mitigate.  If you look specifically at the NIS2, I'm not going through all the laws, don't worry,  but if you're looking at the NIS2, you have to show more clarity.  At this point basically said like, okay, I've got this piece of paper, it has the word pen  test on it, I give it to an auditor, and that's basically end of the story.  Now the law says that you have to deliver underlying evidence.  So the pen test itself might not be enough anymore.  And the question is, is a pen test basically showing that things are fine, or is it a proof  that the director of the organization is in control?  Well, maybe neither at this moment.  Maybe a pen test doesn't answer that question.  If you look at a couple of companies in the Netherlands, and I did my best, or Dieppel  did his best to translate it to proper English, then you see all sorts of statements that  basically if you take them together, oh, why is this still in Dutch?  I did make a mistake here apparently, but basically every company is saying something  else.  Showing the severity of IT problems, making infrastructure proof of sound, show the state  of security, show vulnerabilities.  None of these companies is saying, give assurance that the basics are in place.  And that's a big thing.  I think I started, I started, no, I don't know why it's all in Dutch all of a sudden,  because I did translate them all over the last three days.  What we see happening is that with the pen test, a lot of companies are claiming that  they do magic.  I really have had them sitting down and say, we can't tell what we did because it's magic.  What we did is a company secret.  What we do with the pen test is not something you can use against us.  It's similar to buying a house in the Netherlands.  You've got these companies that will help you and they will come to your house and they  will say and have a look at your house and say like, okay, this is structurally proper  built.  I bought a house in Amstelveen and the guy said, well, the roof, you know, you might  in the next five years have to replace like 10 or 12 tiles, but that's just about it.  Four months later, I could replace my entire roof and there's nothing you can say about  that.  So the customer, and this is always a problem in communication, the customer has a total  different expectation and they're filled with techno-optimism.  Customers have been looking at my website, so it must be good.  They couldn't penetrate it, so it must be perfect.  Well, we did a pen test, so everything must be okay.  And we're jumping around that everything is okay.  So we've got the company on one hand saying, basically what we offer is your insight in  your problems and the customer perceiving it as being assurance.  The reality is that we are non-compliant, not pen tested, and unknown risk accepted.  Because if you don't know what your risks are, you accept risks that you don't realize.  Six months later, let's say, you know, you're a city, you did a pen test on the infrastructure.  After six months, all of a sudden, your entire city is hacked.  All your data is ransomwared.  And that's basically the end of the story.  And again, you can shout as much.  We did an infrastructure pen test and there were no significant findings.  But at the end of the day, your data is gone.  This incident, and a couple of people will know which incident I'm talking about, was  for me a life-changing event.  It was the first time that I realized that the board of directors, or the major, did  everything right from her perspective.  But on the other hand, she still loosed out.  Hold that thought.  For the next couple of years, there will be a lot new laws that will be introduced.  I can summarize all European laws that are coming our way very simple.  Europe is saying, fuck you to magic.  Europe is saying, make proper risk assessments and deal with the risks.  All the laws that you will see passing will have these elements in it.  I see people make pictures, but the slides will be available in full English ultimately.  And if you join the group, you're part of making them and then there are your slides  as well.  So compliance shouldn't be looking somebody in the eyes and saying, okay, it must be good  because the eyes are so blue.  And this is what we're used to this.  We've got SOC 1 and SOC 2, type 1 and type 2, design and existence or operational effectiveness.  We're used to this insecurity.  So it's nothing really new and it shouldn't be.  So we should help the auditor.  We've got hackers to look.  That means that we've got no established level of knowledge.  We can't use that.  We take inspiration for standards.  That means we do non-standardized tests.  What we do is magic.  No, what you do is dark magic.  What a pen test is, well, that's what we do.  So we don't have a framework.  That's strange because we do have a framework.  The broader question is, what do we do with an audit?  Is that testing a claim?  Is it looking back?  Is it looking forward?  Is it I'm convinced that it will be okay someday?  What do we want to steer towards?  If I have two cars, one is 23 years old, one is 21 years old and every year they get a  test and they get basic tests.  The brakes, the lights, the tires, that type of stuff.  What they don't do is electrical.  So it might be you get into your car after a positive test and the car burst into flames.  But probably what will happen is that I will go back to the garage and say like, what the  F did you do?  Why didn't you warn me of this?  Even though it isn't one of the formal tests.  And I hear a lot that in pen testing you can't do standardized tests.  That's funny because there are total books written about how to do that.  And OWASP has a couple of very cool testing guides that basically describe exactly what  you should do.  And I always hear like, yeah, but there's always a test that doesn't apply to this subject  or to this scope.  Well, okay, let's take that test out then.  But in general, it's like testing your basics.  What is being tested to my car is reproducible.  It's reproducible in a way that as soon as the garage is finished and they say like,  okay, I certify this car, they've got a certain chance that the government will step in and  say like, okay, we'll redo your test.  And they could lose their license over it.  So they do it properly.  For pen test, this is basically some basic surgery and you fixed it.  Cut out the magic, provide more certainty and deliver the evidence.  That would basically turn everything around.  So this is what we did.  And we are quite a growing group.  I'll talk about that later.  Here's the new problem.  Because of all the magic, there is no definition of a pen test.  I've had Victor de Paus, who has been in IT law for 43 years.  He went through all Dutch law, all the European laws, and there's a lot in cyber security  defined in law, but the word pen test is not one of them.  And this is part of the issue.  So we came with quite a group with a definition.  You might debate about it, but at least we've got the definition now.  And if you think this can be better, come and help please.  Same thing, okay, let's dark magic.  If you're a hacker, if you know stuff, you probably can prove that you know stuff.  So there are certain exams you can take.  By the way, we didn't make this up.  There is this Dutch schedule called CCV, they've got this wonderful schedule.  They had education criteria.  We copied that.  Because why find out to will yourself and somebody else did already good job.  So you have to have certain amount of skills and you need to be able to prove it.  Well, the cool thing about skills is nowadays you can check them online.  Get back to that later.  The other thing is if you've got the testing guide, I've got controls.  Basically I can do a claim towards security and then the test will prove if it's correct  or not.  So I've got design, existence and operating effectiveness.  And if these words do not say anything, then you're probably not an auditor.  If you're an auditor, you think like happy.  So what we did, we found a minimum set of testing guides, benchmarks, shit you could  use that is already there and you should use actually.  And we put that into a bunch of controls that basically say like this is what you've got  to do.  This is how you can validate it as an auditor.  This is the value of this criteria.  This is what you're missing out on if you don't use it.  And the last one is if you want to do procurement, this is how to do procurement.  And one of the things that is different to a lot of companies right now is if you get  a report and you do it according to this scheme, then you are allowed to deliver the report  to other parties to prove that you did your work wrong.  So right, sorry, or wrong.  But I meant right, of course.  Now you can still say like, OK, but I don't want to share my pen test.  Well, that's, I understand that, we'll deal with that in a second.  So now in the whole scheme, bigger scheme of things, you know, you've got your vulnerability  scans, your penetration tests.  Now that we've got a firm basis, basically the next thing you can do is red teaming.  And if you do red teaming without a basic pen test, I've done that a couple of times,  you're throwing stuff over.  It's funny when you do it, but it's not funny if you're on the receiving side.  You've got your code review, your regular security assessments and your audits.  So I'm not claiming it's replacing everything.  It's just the technical audit side that you've got your basics in place.  After penetration testing, you can hand the penetration test with all the evidence to  an auditor and they can write a report based on that test.  So if you don't want to share your pen test because you think it's too sensitive or discloses  too much, then at least an auditor can say like, okay, this guy did a proper job or this  girl did a proper job.  And you can send that around.  In the Netherlands, we've got a couple of interesting things.  One is that we've got cities and they have to go through an ANSIA audit.  That is basically an audit that security is more or less okay.  For that audit, they have to do pen tests.  So what we see happen is 346 times the same pen test on the same software being executed  because you need to be compliant.  This would solve that.  The second thing is that I see pen tests being ordered on software that has already been  pen tested internally because if somebody externally does it, then it's more assurance.  Now, if you want assurance, go to an auditor.  That's the logic place to go.  And don't be scared.  We are left out on work.  For the people here that know Stephen Covey, I believe in the abundance of work available  in the IT security industry.  And I don't think in scarcity.  So long story short, we finally get time to test shit that we should have tested years  ago.  We call it the methodology for information security research with audit value.  In Dutch, that is the Methodeek voor Informatiebeveiligingsonderzoek met Auditwaarde.  And you abbreviate it as MEOW.  And this is the logo.  And this is my cat, Otis.  Yeah, Otis is R and sweet.  So I already said you get a set of controls.  You get official procedural report by an auditor.  We deliver a model pen test report so that if you're all alone and you are a pen tester,  you're not on your own.  We give you all the legal information and we'll make an advisory guide which will be  available on October 18th as a book for everybody who wants it.  And last but not least, we have also things included.  You see pieces of a pen test report.  We also thought about how to make things hoof-de-proof.  For instance, if an administrator goes like, no, you're not allowed to get shell on a system.  It's no longer the pen tester's problem, we'll make it a manager's problem.  I basically say like, we tried to test it but we weren't granted access.  So basically, we don't know what the status is and it gets a red color.  And here's something very interesting.  Managers hate red.  Even though managers are mostly red in behavior, they hate the red color for some reason.  So we'll make it a damn issue.  So we thought about a lot of things, probably we forgot a lot of things, that makes it easier  for you to execute your work.  It is now more measurable because you know what test you are doing.  You know, I recently spoke to a company said like, we do a 50,000 euro pen test.  And when the money is gone, then we stop.  If I were a company and I would hear this, my hourly rate would cyclically go like really  up.  Because that's less work, more money.  And then we say like, next year we'll look at different things.  That's measurable now.  So hopefully we are looking all at the same.  And we have got clarity on what we do, what it means.  It's verifiable.  And hopefully we stop doing the same tests more than once on the exact same software.  And that all together helps you to be fact-based in control, hopefully.  And we're doing this, I'm doing this, we are doing this at the Ministry of Health.  But throughout the year I found a lot of friends that started to help out and look with us.  And also a part of the procurement and buying power that we have together.  Because I've seen in the corona times when you do things together or in bigger numbers,  you know, companies are more inclined to help out to do it in the same way.  And this is not a complete list because there are a lot of organizations that say like,  okay, I can't be on the slide, but I'm still pretty proud that I've got a whole bunch of  friends that are at least helping.  And not the least of that are Davey Day Academy, OWASP, because it's their standards I try  to abuse the most, because they are public.  And that makes it easier.  That is basically what I had to share, so I would like to open the floor for questions  if there's any time left.  I've got no clue how much time I spent.  There is definitely time left for some questions.  So are there any questions from the audience?  Give me one second.  Yes, I could try.  No, no, we start sweet, and then if it's a wrong question, then we hit you in the face.  Talk in the microphone so that everybody can hear.  Is there an on-off button on it?  Yeah, then you're going to do sports.  So the thing I'm pretty familiar with when working in security, right, is when you're  measuring the, what you call, how bad a vulnerability is, right, you talk about the CVSS vectors  in this framework that you're mentioning, and I was interested in knowing how it correlates.  For example, how do you compare CVSS version 2 and 1 or 3, for example?  Because you can't really convert between them because it's not really defined.  Yeah, we've defined CVSS version 4 because that also gives you context information as  well, so that in the measurement of how severe it is, it's a very good question for the ones  who don't know what the common vulnerability scoring system is.  When you do a pen test and you have findings, we, from a technical perspective, tend to  say like, okay, this is the end of the world, always.  So for me, every finding is critical.  Now we've got the scoring system to say like, okay, we give you a number between zero and  ten, ten being like critical and zero being like purely informational, and we're using  indeed the common vulnerability scoring system.  The last version, 4.0, also gives a lot of context information.  For instance, if you've got a computer that is never attached to the internet, the same  finding might get a lower number than, of course, a public-facing thing.  So we use 4.0.  Is that enough answer to your question?  Yeah, I like it.  First of all, thanks for putting in the effort into making pen testing more measurable.  What does MEOW fix that is not fixed by either Certified Secure or OWASP ASVS?  Oh, yeah, that's a cool one.  OWASP ASVS is a standard.  Can you give me a second?  Then I'll pull up a slide where it is exactly saying what ASVS is.  And that is this slide.  If you look at ASVS, it is for culture building, process maturing, and it is used for putting  down requirements.  When you do validation, you've got different guides.  So the use of the ASVS is a different use.  And this is a good question because there's something else.  I see a lot of pen tests that talk about the OWASP top 10.  We are not educating because that is purely meant for educating.  It is not meant to test, for instance.  It's basically a popularity contest with the top 10, yeah.  So we've had a look at it on the ASVS because that's what I thought as well in the beginning.  But then I got a firm lesson from OWASP, like, stop doing that.  But shouldn't you always verify against your requirements?  It depends on what you are verifying.  It's a good question because I'm just writing a book called The Validation Crisis.  Because this is a big thing, yes, you should, but for the testing guides, the technical  testing guides, OWASP did something else.  And that's all, of course, interconnected.  So yeah, this is why we end up with different testing books.  But we were at the same page as you were in the beginning.  Yeah, and that was kind of a shock to me because that was in my head for years.  Will be the last question, I think.  All right, thanks.  So you rightfully point out that we should stop testing the exact same software for the  same issues.  Of course, there is no such thing as the exact same software.  Small modifications are being made all the time.  So do you have thoughts on that?  And most particularly, whose responsibility will it be to identify when a component has  to be retested?  The pen testers or the organizations?  You said you were asking multiple questions at once.  Who's responsible?  And for all the CISOs in this room, listen very carefully, management, especially in  the law, management, administration is responsible for security.  It's not a CISO job.  It's a CISO job to facilitate the process, to watch if things are going right.  But it's a management job.  So management should decide if they're working on software all the time.


url: https://www.youtube.com/watch?v=MxDq552Di3Y
title: The Registry Rundown - Cedric Van Bockhaven & Max Grim
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=MxDq552Di3Y",
    "title": "The Registry Rundown - Cedric Van Bockhaven & Max Grim",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1823,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Welcome to our talk, the Registry Rundown. My name is Cedric van Bockhaven. I'm a Red  Teamer and Offensive Developer at Outflank, just like my colleague Max. In general, we  just spend our days hacking away at things. We're both very technical people, and also  at home with home automations and stuff like that, like my partner says. But he usually  thinks I break stuff rather than also repairing them. So, Max, you want to introduce yourself?  Yeah. So, my microphone is not working, or is it? Oh, great. Lovely. So, I'm Max. I'm  also a Red Teamer and Offensive Developer at Outflank. Nowadays, we're part of Fortra.  And I have more of a software engineering background. So, before I went into cybersecurity,  I worked more on building websites, building applications for companies, and I took that  experience into the offensive world. And in my free time, I also like to do some hardware  hacking. I build some conference badges and also do some home automation.  Yeah. So, actually, for me, the first conference I ever went to was Hack in the Box. So, it's  actually great to see now Orangecom being organized also by a lot of the same people  that we knew from back then. And this research was also developed actually at a conference.  So, two years ago, we were at Brucon, and we were just having a moment of, well, just  sitting down and started to play with some scripts. And then we found some interesting  stuff in the Windows Registry. So, that's what we're going to talk to you about today.  So, a lot of people know that using the registry as an administrator, you can connect to a  remote system and just operate registry. But today, we'll see that also as a non-administrator,  you can do some quite interesting things with the registry.  So, our agenda for today is going over some quick history, then look at how the registry  can be managed remotely, and then also look at some vulnerabilities and exploitation primitives  that might be useful in security work. Starting with some history. So, the registry  dates back from a long, long time ago. Basically, around the time I was born. So, back in Windows  3.1, the registry was first created for storing com-based components, configuration data.  And then also, a lot of information was still being stored in .ini files. So, if you had  a program installed, then that program would store its settings also in .ini files. Nowadays,  or around Windows 95 and NT, what they started doing is moving that information to the registry.  So, if you open Registry Editor, what you'll see is a hierarchical view of typically these  hives. HKEY-LOCAL-MACHINE, HKEY-USERS, and so on. Thank you. And you also have a number of other  hives that you don't typically see in the registry, but they are present. So, you can  interact with them if you know how to. And those are the ones that are grayed out on this slide.  There are two hives that are particularly interesting for us, which is, first of all,  the HKEY-LOCAL-MACHINE hive, which stores all sorts of computer-specific settings,  configuration data. So, think about local policies, group policies that are being applied  on the computer level. So, not on the user level, but the computer level. In contrast to HKEY-USERS,  which contains then, of course, the user-specific information. Under HKEY-USERS, what you'll  typically see is a number of subkeys denoted by S15 and so on. So, S1521 is a domain identifier  or a local computer identifier. So, for every user on the system, you'll see a subkey here  and storing the information of the individual user. What's interesting here is that there are  a number of keys. You see it with the blocked icon that we cannot access. So, as a non-administrator,  typically you cannot access information of another user. However, if you're an administrator,  you should be able to. But what you also see is that there is one hive that we can access,  S1518, or the default hive. You can access that also without administrator permissions  on the local system and the remote system and see what's in there. So, S1518 is actually the  key related to the local system user. So, containing system configuration information  and also stored for, for example, if you're on the logon screen, like NumLog settings,  for example, that's what you typically will find in there. And there's a number of other  ones, S1519 for local service, S1520 for network service, and so on. So, just used for storing user  data. Then we have a number of other hives, like HKEYCLASSESROOT, HKEYCURRENTUSER, and these are  a bit more interesting in the sense that they're not actually real hives, rather they are sort of  symbolic links or virtual mappings to the real data. So, only HKEYLOCALMACHINE and HKEYUSER  are actually this backed. And if we look at HKEYUSER, HKEYCURRENTUSER, then this is actually  containing, again, the information of a specific user. In this case, the user that is logged in.  So, our own information. And, yeah, typically if you open an application under your own user,  then that application might store its configuration data there. Settings are stored here,  but also COM classes. We'll get back to that in a second. Then we have HKEYCR, or HKEYCLASSESROOT,  and this is where we'll find all sorts of information related to mappings of extensions,  like what program should open a DOC file or what program should open an EXE file,  and we'll also find COM class registrations here. Now, HKEYCR is special in the sense that  when you open HKEYCLASSESROOT, it will show you information for your own user,  overlaid on top of the information that is normally being used for the local system.  So, it's a special overlaid hive. What is COM then? I already mentioned COM classes a few times.  So, COM is used on a system as a framework for applications to communicate with one another,  actually components on the system can interact with one another, so it can be used between  processes, but even also over the network if we're talking about distributed COM or DCOM.  Maybe you've used this in Microsoft Word, for example. You can do really crazy stuff,  like embedding an Excel document in your Word document in a PowerPoint document,  which is also known as OLE, Object Linking and Embedding, which leans on component-object model.  What you can do is, for example, create an object of the InternetExplorer.application class  and then navigate to a specific URL, and that works then via COM.  With this class, InternetExplorer.application, there's an associated CLS ID,  and that information is stored in the registry under the HKEYCR hive,  and then it will tell, under specific registry key, local server 32,  which application to actually instantiate to run and interact with on a COM level.  All sorts of applications will register these COM classes, so you can then use those COM classes to  interact with them, also a source of many vulnerabilities. If you weren't in this talk  today, you would be in Tam Gommers' talk, who's also talking about COM and UAC bypasses.  HKEYCLASS is rude, for example, if you install Java, they install, I don't know,  500 of these registry keys looking like a cafe. I don't know why, but I thought it was funny.  Max, remote.  As attackers, we want to interface with this registry, for example, to do reconnaissance,  to do lateral movement, or maybe even some relaying attacks,  and there's at least two ways that we know of on how to remotely interact with this registry.  The first method is via the remote registry protocol, or MSRRP. This is handled by the  remote registry service, and by default on servers, this is marked as auto start,  and unfortunately on clients, it's disabled. So this protocol, we mostly focus on servers.  So, auto start means that it's not running by default, but we can trigger to run it.  So we can access a named pipe, and then it will start up, and then we can start interacting with  it, and then after a while, it will shut down by itself again. So how do we do this? If the  service is not started, we can retrieve the winreg file from the IPC dollar share on the remote  system, and this will trigger the service to start, and then we can start interacting with it.  And then we can start interacting with it, and we do this with RPC calls, which are  transported over an SMB named pipe, and this named pipe is pipe backslash winreg.  And the nice thing about this protocol is that you don't need to be a local administrator on  the remote machine. So essentially, any domain user in your domain can go to a server and talk  to the remote registry over it. You can actually do this in regedit. In regedit, there's a context  menu where you connect to a remote server, or you can use other tools such as reg.py,  which is part of the Python impact toolkit. And this is actually a nicely documented protocol  by Microsoft. There's this huge PDF that you can download with all the different opnims,  all the different RPC functions that you can call, and then you can do stuff like deleting  keys, enumerating keys, opening them, saving to them, whatever you want. Now I mentioned that  there's a second one, and this one works via WMI. So WMI uses DCOM to communicate, and this in turn  again goes over RPC, but this is like more the traditional RPC that uses a dynamic and random  high TCP port. And if you want to interface with WMI, you need to go to the correct namespace,  which in this case is root simv2, and then within there, there's a class, the std regprof class,  and this class will have all these methods as well where you can open a key, read from it,  save to it, whatever you want, basically. And there's advantages and disadvantages to this  way of communicating. So the advantage is that it's both enabled on clients and on servers  by default, but you need to be a local admin on the remote machine to be able to talk to it.  And you can use PowerShell with GetWMIProject to talk to it. You can also use WMI Explorer,  which is a nice toolkit where you can see all the namespaces, select the right class,  and then it shows you all the parameters that you need. And there wasn't a tool available  for Impacted yet, so we wrote a little extension for Impacted that communicates with the registry  over WMI, and here you can see as well, if you use a regular user, you won't be able to access  it. You get an access denied, but with an admin user, you can just list the keys and work your  way up from there. So now that we know how to interact with it, let's see how we can actually,  as attackers, abuse this. And there's already, of course, some common attack factors out there.  You can do some credential dumping, so you can dump the SAM security and system hives  remotely via secret dump.py. This works via the remote registry. You can also use Mimikatz to do  that, or you can configure persistency to add something to the run key on the remote system.  You can do com hijacks, which is probably what time is talking about right now,  and many, many more things that you can do. But there's actually quite some interesting  reconnaissance that you can do as an attacker as well. So if we look at what kind of permissions  we have remotely, it's that we cannot read HKLM if we are a domain user and access it remotely.  You need to be a local admin for that, even if you use the remote registry protocol.  And if you're a local admin, the HKLM hive has some interesting information. You can read about  which EDR software is installed, the AV inclusions that are configured, local or group policies,  like Cedric mentioned. So it is quite an interesting source of information. So if you are  admin in an operation, this is a good start for reconnaissance. But here we are more interested  in what can you access as a domain user. So as I said, you cannot read HKLM, but you can read  HKU and HKCR, so the user hive and the class's root hive. If you are logging in,  under HKU you always have access to the dot default, the S1518. And if the user remotely  is logged in interactively on that computer and you, from a remote part, log into the remote  registry, you can actually also go into the SID of that particular user and view all the settings  that are mounted under that key. And then there is the HKCU, which is not the user, but current  user. And this is nothing more than a SIM link. So when the user is not logged in on the remote  machine, it will link to dot default. And if it is logged in, it will actually map back to that  user SID that you can also see in HKU. And this dot default that you can always access already  has quite some interesting information for you as an attacker that you can use in a reconnaissance  phase. But first, let's look at the HKU itself. So here you can see at the bottom that I'm using  Rec.py again. I'm a regular user and I'm querying the user hive. And here I can see that these user  SIDs are actually mounted. So from this information, I can already know that these users are logged in  on the remote system interactively. And that I can use in my red team to potentially go to there and  then dump their credentials. So this is a nice way to map which users are already logged in  currently on the machine. But this is not necessarily new. This is also how the POS logged on tool,  which is part of sysinternals, works and how Bloodhound collects some of this information.  But here you can see that if the user is logged in, it will actually be mounted and you can read  from it if you have the right permissions. And if the user is not logged in, the whole hive will not  be loaded. But what we found is that in the dot default key that everybody can access, there's  actually also a log of users that historically ever at some time logged in. So if the user once  logged into this machine, there will be a record there with the UTC timestamp of the first login.  It will not show you if it's currently logged in, but at least you get a sense of what users  did ever logged into this machine before. Now, I told you that you cannot access the HKLM  as a local admin. But of course, Microsoft wouldn't be Microsoft if there aren't exceptions.  So there's actually two keys that configure these exceptions. It's the allowed exact paths and the  allowed paths. And the difference between the two is that with the allowed paths, you can actually  also enumerate the subkeys. And this is what I extracted from a Windows server. And I highlighted  some parts that I'm going to show you later. But if the path is configured in this key,  you can actually also as a regular domain user access these. So let's give an example of that.  Here I'm querying HKLM software, Microsoft Windows NT current version as a regular user.  And I get all sorts of information about the system. What kind of architecture is it running?  Which server version is it? And if it's not a volume license key, even the license key is already  there. And you can just access that remotely as a user. But this gives you a sense of, okay,  is this a somewhat older system or not? And what kind of ETW rules would that have by default,  etc. There used to be a vulnerability in this, which is fixed in October 2022. And we actually  sort of found this vulnerability at the same time. It's just that the other person was a  bit faster with reporting it than we were. But if you had an exact registry path handle,  you were actually allowed to also enumerate the descendant subkeys of the allowed exact paths.  This was reported and fixed, so it doesn't work anymore. But  let's see. Some more examples. So here as a regular user, I'm also  querying HKLM and I can see what services are installed. And in this case, I can see that  CrowdStrike is there because it's configured as an event log surface. So now I know that,  okay, maybe I shouldn't send an EXE to that computer, but use a more sophisticated payload.  Huh? Oh, yes. We still want the system to keep working afterwards.  You can enumerate printer drivers that are installed remotely. And then if it's an older  system, maybe use PrintNightmare or some other exploit that revolves around drivers. Maybe  there's a vulnerable driver on the remote system that involves turning on the RGBs on your memory  stick and that has a vulnerability. And at least now we know what drivers are there that we can  potentially use at a later stage. And querying all these registry keys is generally not considered  as malicious, so you will not run into any detections unless there's very specific  trapdoors in there, so to say. So this is a nice way to do some remote reconnaissance.  And I'll give one last example. This is the classes root, which you can fully enumerate  as a domain user. And here you can see things like, okay, the open with list, like what kind  of files have been opened in the past and how are they configured. And in this case, we know,  okay, there's at least Word and Excel on there, so maybe we can do something with that.  And now we go into a few vulnerabilities that we found. We found two vulnerabilities that are  around information disclosure. We reported them to Microsoft. They came back to us that they said  they were not critical, not high impact, but they still sent them to their respective teams to be  fixed. The first one is that as a regular domain user, it's not possible to read HKLM keys, right,  without these exceptions that I just mentioned. But if you use the remote registry protocol,  the RPC responses that you have on specific calls actually leak some information. In this case,  it leaks information about the existence of the HKLM key. So what we do, we first open a handle  to a specific subkey in HKLM that we want to check out, and we set the sum desire to key set value,  and I'll show you in a bit why we do that. This should result in access denied because we do this  as a regular domain user. And then we try to delete this key. And once we delete this key,  there's actually a leak in the information in the response code that will tell us if the key exists  or not. So I have it visually here. First, we open the key, and here we should get an access  denied because we're a regular domain user, right? And if we do not get an access denied,  we should actually abort because then otherwise it would mean that the next step we're going to  delete the key, we're actually going to delete the key on the remote system, and generally you  don't want to do that on a production system. So this is like a safety check in there.  Then we try to delete the key, and then we can see what our status is, and there's basically two.  You can get an error file not found, and that means that the key doesn't exist,  or you get an access denied, and then you know, oh, the key actually did exist.  I just don't have access to delete it. And we made a little script that feeds a file,  gets fed in with all the different keys, and now you can enumerate and see what kind of software  is installed there. So you can give it a predefined list of some EDRs and some other software,  and then we can remotely see if it exists or not. There's a second one, and this basically  allows you to check if a random file exists on the remote file system or not. So here again,  we open the key first, but we now use HQ, and HQ every domain user can do,  and then we try to save this key remotely on the file system on a specific path,  and this response code actually reveals if the file exists or not. So again, visually,  we open the key. We're allowed because it's HQ. We try to save it, and the return status tells us  either the directory does not exist or the directory exists, and this you can then also  use to see if certain files or programs are installed on the remote system, which is a nice  reconnaissance thing to do. One more thing from my side before I hand it over back to Cedric.  In the past few years, we actually abused ADCS quite a lot, and for those who don't know what  ADCS is, ADCS is a role that you can install on your domain controller, and it's basically  Microsoft's PKI implementation that hands out certificates based on templates. So it can be  a certificate for Kerberos authentication or for authenticating to your Wi-Fi or whatever you want  with that certificate, and it turns out that these templates are generally quite easy to misconfigure,  and in certain combinations, we as attackers can abuse those to get domain admin, basically,  and normally, we would query these certificate templates via Certify or Certify, and they use  COM or RPC or LDAP to query towards the domain controller like, hey, can you give me all the  certificate templates that are configured in this environment, but since this has been abused so  much, there's actually quite a lot of detections around this as well, but it turns out that by  default, every domain joint computer that is part of the domain where the ADCS is configured will  have a local cache of all the certificate templates in its registry in the default key,  which every domain user in the network can query, which is great for us because we wrote a little  tool which we call regcertify, and here I use regedit, but you can also do this remotely.  You export this whole subtree, and then we feed it into our tool called regcertify, and then you get  an overview of the certificate template, and I'll explain why this is vulnerable.  Every user, you can see a tree that every user is allowed to use this certificate template to  request a certificate. You can use it for client authentication, so it means you can use it for  Kerberos, and the one that enrolls the certificate, so us, the domain user, can  define for who the certificate is, so we can fill in, we are domain admin Pietje, we want this for  Kerberos, we are domain user, we can request it, and then within two steps, we are domain admin.  Really nice way to use in a red team, and really nice to get the certificate templates this way.  Yeah, so a lot of reconnaissance possibilities, and again, I want to stress that you can do a  lot of this without administrator permission, so accessing this sort of information is normally  not possible without having administrator rights, so we'll see in the next few slides also how we  can abuse that for malicious purposes. Starting with relaying, so there is a registry RRP  interface you can use, base right safe key, to trigger a course authentication on the remote  site, so for people familiar with Petit Potem and similar course authentications, this is a  variation on that, just need to call it with a few specific parameters, and then it will tell you  error privilege not held, and in the meantime, you receive the hash of the remote computer,  which you can then use to forward it, for example, to ADCS, and obtain a certificate  for that computer system. Next to saying error privilege not held, it will actually create a  file on the remote system, where you pointed it to, and create it, but it won't have any content  unless you are an administrator, so one funny thing you can do with that is, for example,  you can course a domain controller and have a file put there in the temp folder,  making it look like the system is being cryptolockered, if you want to cause mayhem,  but yeah, I think the most interesting one for us is lateral movement, so as a non-administrator  user with the remote registry, you can laterally move, which is normally not possible due to remote  UAC controls. So first, let's have a look at how this works as an administrator. Normally, if you  want to execute code as an administrator, what you would do via the registry is perform some sort of a  COM hijack, so modify a CLS ID under the HKEY local machine, and then find a way for that COM  object to be triggered. This does not always work, because you need trusted installer permissions in  a lot of cases, but for some reason, if you create software Microsoft app model lookaside,  if you create that key, the registry will also look in this other location to see if there's  an entry under it. We don't know why, but it does not require trusted installer permissions, so  just if you do this remotely, you will be allowed to, and then you can perform a COM hijack. So in  this case, you still need to find a suitable COM object to hijack, and then wait until it is  instantiated, or you need to find a way to trigger it. Another option for triggering it is finding a  service that also instantiates a COM object, and then triggering that service remotely.  Coincidentally, it happens to be the case that using RPC calls, you can trigger about 50 services  remotely to start, including services on a domain controller. So we have a small demo of that here.  So you can send an RPC ping to those services, and then  one second later, it says triggered, and then the service actually started on domain controller.  You can do this with a lot of services, and a lot of those services also instantiate their own  COM objects, which you can hijack, and then obtain remote code execution.  Then, as a not administrator, what we can do is modify information under HKCU remotely. We've  already seen that in Max's slides, and we can do the same trick. So perform a COM hijack under the  current user, and if that user then opens the application that uses the COM object, it will  trigger, and you get code execution. Because also for classes stored under the htclass root, HKCU  takes precedence, so this is the way we can do a COM hijack. But which COM object are you going to  target? You could target Microsoft Word, for example. So if the user opens Microsoft Word,  it triggers. But if you want to have a little bit more control over when it happens, if you want to  have a good target, one thing to do is, for example, find handles to keys with modify access.  So this is a screenshot of System Informer showing which registry keys are currently opened,  and which have notify access, which means that if something happens to the key,  the application that uses the handle will do something with it.  So what we see here is that searchhost.exe, for example, the one highlighted, has notify permissions.  So if you modify that key specifically, it will trigger something in searchhost.exe.  So what we did is basically the same thing. We modified a key under this path,  just inserted some garbage, and then we didn't know exactly how to change it, so we just let  the process crash, which starts verfol.exe, which is the error reporting service,  which has its own COM object, so we can perform a COM hijack on that application instead.  Small demo of that. It's set, and then once we switch back to the computer view,  we now have a calculator running. One last thing, then, is we noticed the same thing with Citrix.  Citrix has an interesting setup where a lot of cases, they allow all domain users to RDP  to a system, but then perform access control once you are logged in. So really, after you've already  gotten permission to log in, they perform access control. So this is what you see when you log in  via RDP, saying you don't have access. But this is actually running under the context of the user  that is already logged in. So what we can do is perform a COM hijack via the registry remotely,  and just click OK on the screen, and then we get access.  We also reported this to Citrix. They thought it was not a vulnerability,  but you may convince us otherwise. So yeah, in summary, a few ways to use the registry remotely  for reconnaissance, relaying, and lateral movement purposes. If you want to know more,  there's some great research being done recently by Google Project Zero, Yoru, who has gone from  Windows registry in literally 1992 up until now. I don't know how he found out the details. He must  have got some contacts within Microsoft. Really good resource, as well as Pavel Yusifovich blog  posts. Thanks a lot for listening to us.


url: https://www.youtube.com/watch?v=y-zb450CSks
title: Securing OT, Too Hard Or Not For Me? - Erwin Paternotte
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=y-zb450CSks",
    "title": "Securing OT, Too Hard Or Not For Me? - Erwin Paternotte",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 2112,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Yeah, thanks for joining for my talk.  This is maybe not the most advanced OT talk you will see or hear about, but it's also  meant for people who maybe not know so much about OT, and actually an ex-colleague of  mine just walked in and said, well, I don't know that much about OT, so this is the talk  for you.  A little bit about my background.  I recently joined as a CTI specialist at the NCC.  Before that, I did penetration testing, ethical hacking for about 20 years at different companies,  and during that time, I also got the chance to actually test some OT systems myself.  So I'm actually combining both threat intelligence and my hands-on experience here in this talk,  and hopefully will give you some insight, because why do I want to do this presentation?  Well, I know what systems, OT systems look from the inside.  I know what vulnerabilities are there, but I also see the outside world where there's  a lot of focus on the latest zero days or the latest APTs hacking into these systems,  and I think there's a big disconnect between these two, and because there's so much focus  on the high-end attacks, I think a lot of people just give up and say, well, I'm not  going to fix it.  It's not worth doing it.  I'm just going to do nothing, and because there's nothing that can be done, everything  can be hacked.  We all heard it before, and I hope I can change that a bit, because I think there's still  a lot that can be done, a lot that can be improved to actually make those systems a  little bit more secure.  I'm not sure who has previous experience with OT.  Raise hands.  Well, about half of it.  Okay.  Half of it may sound familiar to you already, but why is it different?  Because it is different in some way, but it's not different in some other ways.  What is different is that it's a lot of legacy, because these systems typically run for 30  years or 30 years plus, so you get a lot of old systems that were designed in a different  time.  They were also designed with safety in mind, and that means physical safety, and not with  security in mind.  There are fail-safes, but they're aimed at some incident happening and not somebody deliberately  changing your process or meddling with your process.  Availability is most important in these systems.  Things have to run.  There's not so much confidentiality.  Integrity comes second, but it is actually reversed from an IT environment, and incidents  may have physical impact.  If things go wrong, in some systems, you have the safety instrumentation systems that  actually will kick in, but still, things can actually explode in some cases, so that makes  it interesting as well, but first, a look at threat actors, and I see this part.  People typically skip in OT environments, and they think about attackers physically  coming onto your premise or into your factory, plugging in a USB device and hacking your  systems that way, but there's actually a lot of different ways that can be done and easier  ways as well, and I actually start with ransomware first, and not many people realize that ransomware  is actually a big problem in these environments as well because it is untargeted, so that  also means that everybody can become a victim, also OT environments, and they're not specifically  targeting the OT process itself, but they're actually focusing on the IT systems because  that's what they know and understand.  They just run their playbook and run their scripts as they normally would.  However, there's a lot of connections still between IT and OT.  If you first start talking to people who run OT systems, they say, oh, it's not connected,  and when you start asking questions, you say, oh, but how do you actually get your  antivirus updates if you are running antivirus at all?  How do you actually manage your system?  And then increasingly, you see more and more connections, so it's a myth that they're still  air-gapped, although they were designed that way, it's not the case anymore, and actually,  there's an increasing number of incidents, and I made the following slide.  This is from Dragos, which is an American company who tracks threat actors, both nation-states  but also ransomware nowadays, and these are just the incidents from Q2 this year, so you  see it's quite a lot, and you see the different ransomware groups, and each dot is one victim,  so you can also see who's most popular, and it's actually increasing compared to Q1 as  well, and that also has to do with the actions, the legal actions that were taken before,  like some of the takedowns that were done by law enforcement, but it's actually increasing  again, and you also see new groups, actually, they have never seen before, and of course,  those are still on the right side there, they're not doing that many attacks yet, but there's  actually an increase, and they also see government-affiliated groups now adopting ransomware attacks.  They actually reused existing samples that are available, modified a bit, and actually  also sort of hiked their tracks that way to make it seem like it's ransomware, but it  may be not, or they're just trying to disrupt processes, and again, they're not targeting  OT systems directly, but they're targeting maybe your active directory, which is mostly  shared between IT and OT, or it's not shared, but there is a trust between them.  Typically, a two-way trust, so basically, if effectively, for a ransomware actor who  is domain admin in your IT environment, he can do whatever also to your OT systems, and  then we're talking, of course, about the Windows systems, more and more in the higher layers  of your OT network, but that happens to be the HMIs that actually are a human-machine  interface.  That's what your operators look at.  It's the SCADA systems that actually measure a lot of things on a bit higher level, like  what's the production, et cetera.  I don't know many operators who would happily run the environment if these systems are not  available.  I mean, the process itself might still run, but you don't have visibility anymore, and  typically, that still means you actually go into controlled shutdown, or it could be as  benign as your ERP system, which is actually, within your IT environment, is not available  anymore, so you cannot produce or you cannot ship anymore.  Your label printers are not working.  Actually, the scales in your factory to weight what you've produced are out of order, so  you still have to shut down, and actually, these numbers are quite high, and if you want  to look at the full analysis, there's actually the link.  I will, of course, also provide slides later, and then you can have a look, but it's actually,  yeah, most people overlook this actor in relation to OT networks, and then there is this group,  the hacktivism group, and that's a difficult group to look at because it's really a mix  from local environment groups to more organized groups, and we'll talk about these a little  bit more in the next slide, and in essence, it's still untargeted.  They're more device-oriented.  They know how to hack into a certain device, and they're not targeting you specifically,  but you just happen to have the device to know how to exploit, and like I said, there  are diverse groups, but in the recent years, we see more and more that there are actually  also connections and ties between these and APTs.  They're sort of doing the dirty work, and I'll show you a bit more about that, and mostly  they're targeting internet-connected OT devices, and that may sound strange.  How do these devices end up on the internet?  But there are actually quite a few, and technically, hacks have actually a low complexity.  It's not hard to do.  It's sometimes even devising banners on systems or clicking around in an HMI interface.  They still have consequences, and there has been physical impact, but yeah, and it's quite  a problem, actually, this group.  Because if you look at the census query I've done yesterday evening, these are all the  systems, and I'll just look at the numbers all the way on the left.  You can actually see the number of systems that are identified by census as being ICS  or SCADA-related.  They have a couple of labels, and they're all over the world, but actually, the Netherlands  is, well, what is it?  I haven't counted exactly, but you can see it over there.  Over 1,500 systems connected to the internet.  Why are these systems there?  Who put them on these networks?  And I looked a little bit into it.  You actually see a lot of systems that are connected to the IP ranges of mobile internet  providers, so the KPNs, the Vodafone, Seagulls, et cetera, and why is that?  Well, you have suppliers who may think it's a good idea to actually use a 4G router to  connect these devices to the internet because they need to manage it.  So there's still a lot of these devices around, and there's also different groups looking  at these.  So you have CAR, or Cyber Army of Russia Reborn.  That is actually nowadays linked to Sandworm, so it's linked to an APT, and they look at  the internet and what they can find, and the still of this HMI is actually from a video  they put online where they are actually clicking on all buttons they can find and changing  values.  I really got the idea they have no clue what they're doing, and still they managed to  overflow the water tank you see over there.  And it's also hard to actually verify if these claims are true or not or if they're just  fabricating information, but in this case, it was eventually confirmed that indeed they  managed to overflow the water tank.  And if I look at what they're doing in that video, I really look at like, do you actually  understand at all what you're doing, or is it just sheer luck you actually managed to  overflow the water tank?  But still, they are causing issues.  Another group is Cyber Adventures linked to Iran that actually are targeting Unitronics  PLCs for the very reason that those are Israeli PLCs.  So, if you happen to have these devices connected to the internet, hopefully not, they will  deface them.  So, it's completely unrelated to your OT environment or your business.  And then we have another group, which is quite hard to, I don't know, suspect or something  like that, that's actually targeting Ukrainian telcos with wiperware.  And that's what you also see.  It's also where there's geopolitical tension, you see that there's actually these groups  that pop up and may actually attack you.  Spionage, more targeted, mostly targeted at critical infrastructure, because they want  to have information about these environments.  It's mostly about two things, gathering information about your OT environment, which is typically  saved within your IT environment.  So, they use either vulnerabilities or spear phishing to get a foothold, steal all the  information they want, try to maintain that foothold, also the prepositioning to come  back at a later time.  One example of this is actually Fault Typhoon, who was in news before as well, but they have  done a second attack where they actually target US critical infrastructure.  So far, they have not reached the OT environment, but you see them targeting critical infrastructure.  They actually use an unknown Fortinet exploit.  In the past, I have also exploited ZeroDash, and they have done a second attack where they  do have ZeroDash.  But once they are inside the network, so they start at the edge device, which is typically  not very well monitored.  But once they are within the network, you see the typical red teaming activity, living  off the land.  Yeah, quite detectable, I would say.  But they try to maintain access for a long time, and I think it's because they want to  preposition and come back at a later time.  And that's actually what you see in the next group.  So Sabotage, that's extremely targeted.  And basically, you see it mostly being done by the Spinoz groups, or they might have a  subgroup.  So they first steal the information.  They kind of work on some piece of malware, maybe specifically to that environment, and  they come back at a later time.  They already have the access to the IT environment.  They still need to find their way into the OT environment.  And from my own experience testing these environments, I know that's not that difficult.  So once they're already prepositioned, they might come back.  And the reason we don't see these kind of events that much is also it has political  consequences, because these are state-sponsored actors, and you're targeting other countries.  So what they mostly do till now is that they actually run those activism groups as a sort  of front to do the, at least, you know, try to poke the bear a bit to see how people respond,  and then don't do the full attack shit, although there have been some cases.  And I actually put them in a timeline, and I'm really glad this screen is quite big,  because I've struggled quite a bit to make this timeline, because some of the malware  is a bit smaller, but I hope it's still readable.  But till now, there are only nine pieces of malware that are known to specifically target  ICS systems and protocols, and that's over a time span of 14 years.  So just to give you an idea that, yes, if you get targeted by these malware samples,  and you have an actor using it in your network, the consequences can be high.  But what is the chance, actually?  And if you're not critical infrastructure, maybe this is not your biggest concern.  Compared to the numbers of one quarter of the cybercrime and the ransomware, you actually see  there's a huge difference.  And still, I see a lot of focus on this one.  I actually quite recently was at an event, and I won't give any more details what it  was exactly, but there somebody said, yeah, nature states, we can do nothing about it.  And first question, of course, is nature states really your biggest concern?  And second is, well, can you do something about it?  I think there's still things you can do.  Because if we look at the common vulnerabilities and weaknesses we see within these environments,  it's not that shocking, actually.  But first, a bit about security testing.  So right now, I'm working as a CTI specialist, but I used to test these networks for a living.  Not full time.  But I spent quite some time developing, actually, a way to securely test these systems.  Because one thing you might know, if you run an OT environment, typically you don't want  somebody as one of the pen testers running around without any idea what he's testing,  because he will actually take down your systems.  Because they're less resistant to security testing.  Why?  Well, they haven't been exposed to security testing that much.  Sometimes they run on limited resources, specifically the more low level device like  the PLCs, you can easily overflow them just by running mapp with the wrong parameters.  It's that easy.  And you could still say, well, availability is most important.  So that's an interesting contradiction.  But yeah, you don't want to do that in production.  Also, there are almost no test environments.  There's no spare parts.  There's no redundancy.  There's sometimes some redundancy within the process.  But for instance, if a PLC breaks and they need to replace it, they need to go to their supplier.  They don't have one in stock.  They don't have a test environment.  So how do you actually test your updates for your PLCs?  Or maybe you just don't update them.  Maybe that's easier in these cases.  And that's why an OT security assessment, as I designed it, is actually a combination  of an architectural and configuration review combined with some light security testing.  Because it's too dangerous to do it in production.  And if you want to have an idea, this is actually from Control Things IO.  They provide this PDF, which has a great overview what scans are somewhat safe to run  and what scans are highly dangerous to run in these environments.  I would recommend to have a look at this presentation.  Because you will be surprised that even a simple fingerprint from EMAP  might already crash your device.  So you really have to know what you're doing.  And during the assessments, what we've done is that we actually used also the same monitoring  appliances they use for monitoring these networks.  So one thing we would do is actually connect our own system to the network, actually have  a trunk port into the network.  So you could actually hop between VLANs.  Scan when in local VLANs, not through firewalls.  And yeah, be very careful what you do.  And then you find a lot of things.  There's actually a lot of things wrong.  It already starts with when you start requesting your information to actually do this properly.  Because you do this in a white box fashion.  You want as much information as possible.  But you already notice that when you start asking about network drawings and assets overviews,  that they're not there.  Either you don't have a network drawing or you have a network drawing that's outdated.  Or you have a network drawing that's outdated.  I've had network drawings that were literally the place where the 19-inch rack and where  the servers were or where the physical network connections were, but no logical layer two,  layer three network design.  Or it was really fragmented and the vendor only or supplier only drawn their own part  of the network.  But there was no overview.  And that's really shocking to me.  Because these environments are pretty static.  They don't change that.  But of course, there is some upgrades.  There are vendors coming in and out.  But compared to an IT environment, it's really static.  And still, they don't have an asset overview.  So how can you secure if you don't know what you have?  And then, of course, there's the firewall network switch configurations.  As you may know, there is a firewall between IT and OT.  And sometimes two even, back to back, different vendors, things like that.  But does it really matter if you have one or two if they're really badly configured?  Because that is what I've seen in practice.  I went through all those firewall rules.  And there's a lot of any-any's.  There's a lot of like testing rules and I'll fix to be later, to be fixed later.  And nobody dares to touch them anymore.  Because they don't have a clue on the protocol level how these networks work.  So yeah, in a network where you want to have high availability,  or availability is most important, you don't touch it as long as it works.  And then you accumulate over the years a very large rule base.  But after about 50 rules, you can basically say,  OK, this is sort of like an any-any-any rule.  So it's not that useful anymore.  Another thing is remote access.  Because you have a large dependency on suppliers coming in or doing remote maintenance.  And you actually are really dependent on them.  Because typically the asset owner don't know anymore how to run these networks themselves.  So if the vendor demands they want to have remote access, they get remote access.  And how do they get remote access?  Well, quite literally VPNing somewhere in the network.  Literally directly into your OT network.  Or they nowadays have these boxes that make reverse connection to a sort of cloud.  So then you don't have to configure a firewall anymore.  You can actually connect that way.  But you still see that these networks are managed  by suppliers that connect on the network level.  So basically, if they run the wrong command or they are infected with malware,  it might actually spread into your OT network.  So that's quite dangerous as well.  I haven't discussed the network switches that much.  I forgot those.  What you typically see with the network switches is that they are shared between IT and OT.  So they do use different VLANs.  But I had situations where actually the management interface  with a very weak password was exposed to the IT side.  So I once actually phoned a customer and said,  OK, now connect to this IP address, log in with this password.  And you're actually on the switch.  And you're actually on the switch.  And I said, well, now you can also see your OT networks.  You might be able to reconfigure it if you have the experience and the knowledge.  And of course, this is a little bit more advanced tech.  But we also see some actors actually hacking into  firewalls and VPN devices.  I'm sure they might be able to configure a Cisco switch.  And the same thing is true for virtualization.  Also, virtualization solutions, they are used quite heavily now  in OT environments as well for the Windows systems or the higher layer systems.  But again, it's shared between IT and OT.  And one step further, it's also integrated with their active directory.  So now you have an actor, even ransomware actor,  that is domain admin in your IT environment.  Guess what?  He also controls your complete OT environment.  Because if he does a simple shutdown, well, good luck.  So there are these things that you see over and over again.  And then we talk a little bit more about the network design.  And who is familiar with the Purdue model here?  Ooh, not that many people.  Okay.  The Purdue model is a model that is more like a layered model,  how you can actually organize your IT and OT networks.  So it starts at the top, level five,  which is actually your internet DMZ, as you would have in your IT environment.  Then the enterprise zone, level four, is your internal network, your IT environment.  And then you have a firewall between IT and OT, which I mentioned previously.  There's not one version of the Purdue model.  That's a bit unfortunate because there are versions  with or without level three and a half, which is the DMZ.  Sometimes it's called level three, and then there's still DMZ.  But yeah, there are some different versions.  But actually, as you have a DMZ between the internet and your internal network,  you would also have a DMZ between your internal network and the OT network.  What I see mostly is that that firewall is there, but there is no DMZ.  So through that firewall, we allow direct connections between IT and OT,  sometimes both ways.  And over here, a little bit less easy to see, but here between level three and two,  you also see firewalls.  And you have these zones, which actually could be different factories.  So those are also separated.  What I typically see is that there might be a firewall between IT and OT,  but the rest of the network is almost flat, or there's some VLANs,  but there's never a firewall in between anymore.  So between level three and two, I don't see that being used at all.  And I've also had a situation where I looked at network designs  and looked at what it looked in practice.  And I also found loopholes around firewalls,  like extra connections they forgot to remove and all sorts of things.  So people really don't seem to understand how to use this model in the correct way  and how to architecture your network using this design.  And why is this so important?  Well, as you may know, some of the OT protocols that are being used are by design insecure.  They don't use encryption.  They use either no authentication or weak authentication.  So having a layered network design is actually a very important defense mechanism.  And if you don't have that, well, there's not that much  that can protect you in some cases.  And also, if you want to do this right, basically,  you want to have no direct connections between IT and OT or the internet.  And you might think, internet?  I have actually seen situations where maintenance was allowed directly in from the vendor,  all the way straight to your devices,  sometimes even into the lower levels, like level 2 or even level 1.  So yeah, that's not the way to do it.  You actually have a DMZ.  You should also have intermediate systems in there.  And typically, you also want to pull the data from the systems in your planned DMZ.  So the systems in your OT environment should actually connect towards level 3.5  and get the information and not vice versa.  So you don't want to have incoming connections from level 3.5  downwards towards your process.  One thing I forgot to mention is this is basically as close to the process you can get.  So this is actually your sensors, your activators,  your field devices that actually control and measure your process.  Level 3 is where you find the Windows systems, the Windows-based systems.  So there, your Active Directory could live, your engineering workstation,  which is also very important because that is the system where you have the software  installed to actually program your PLCs.  So where will attackers go?  If they are really targeting your environment, they will go to your engineering workstation  or they might hit your domain controller, which is also there,  depending on if it's a separate domain or not.  And then, of course, like I mentioned, we have these Windows systems  and we have the Active Directory being shared or trusted,  but we also have the systems itself.  And there are a lot of vulnerabilities because these systems are either not  patched or not regularly patched.  And that's a difficult thing because, yeah, sometimes processes run 24-7.  So there are not that many Windows to patch.  However, I've seen systems that have not been patched for 10 years.  And I'm quite sure that in most processes, there is somewhere a maintenance window.  And also, because some of the software running on these systems is  very dependent on the configuration of the system,  you cannot patch these systems yourself because the supplier will demand  how the system should be configured.  And most of the times, it's not very secure.  And I think this is also an area where a lot of cooperation is needed  with your suppliers to also stimulate them a bit  to come up with more secure configurations,  actually build like a golden image, which is securely configured  because we do use virtualization a lot.  So that actually means you can build secure templates  in cooperation with your supplier and use those.  And also, the hardening of the systems.  Typically, if you look at these systems,  every piece of software that they might need for support and everything else is stalled.  And it ranges from old flash versions to the full office suite,  all sorts of software which they may not need.  So removing all that extra software actually limits your attack service a lot.  And then if we look at the lower level devices, it's even easier.  If you want to hack those, the first thing you do is look up the manual of these devices.  In there, you will find the default password.  9 out of 10 these work.  And not always do you see those network  or those management interfaces exposed to the rest of the network.  I mean, it might be the local network segment, you only can access these.  But I've seen also situations due to misconfiguration,  you could actually access these from the IT environment.  And once you log in, it's as simple as doing a shutdown or reset the configuration  and just reconfigure the IP address.  Remember, availability gone.  And then we, of course, have also vulnerabilities in these devices.  And patching is, like I mentioned, is always difficult.  But again, once you know about these vulnerabilities,  if you don't have the layered network design in place,  you don't have another option to patch, I think,  because you don't have any protections.  Because if, for instance, there is a vulnerability in a specific ICS protocol,  which is only exposed in the local network segment and not accessible from remote,  you could say, okay, I have this protection in place, I can patch at a later time.  But if you don't have that network design and everything is open,  you will have to patch or not and hope for the best.  And then there's this interesting thing about the management protocols.  So typically, PLCs or whatever devices, they might have management software.  And this is something you typically do in a test environment.  So sometimes you have a specific device you can test within a test environment.  What I 9 out of 10 do first is get the management software.  Why? Because they have all these mechanisms to actually log in without authentication.  And you will find the weirdest serial protocols  stacked on top of UDP packets on a random high port you never heard about.  And you can actually access these devices without any vulnerabilities.  And remember that if we do talk a bit about APTs, that there is,  there are quite some resources on that end as well.  What do you think what they will do? Of course, they will read the manual.  They will look at existing vulnerabilities.  And they will also look at those management protocols.  And this is also if we see as well.  So I go back a bit because I forgot to mention something on this slide.  If we look at some of the more recent malware,  you actually see they abuse the legitimate ICS protocols to actually just control systems.  So for instance, we start with the latest one, Frosty Goop.  That was actually just a piece of software that had a Modbus library implemented  that could talk to a certain PLC.  And just by knowing what registries and values to read or write,  you could actually shut down these systems.  And that were actually, yeah, were actually a management system for buildings.  So building management systems in Ukraine, and they actually shut those down.  So my conclusions, there's still a lot of room for improving security  for the environment, at least in my experience.  And I have to say that that depends a bit on what industry you're in.  Because some industries like oil and gas, and maybe the electricity companies  may have a higher security standard.  But still, I've seen a lot of things go wrong.  And actually, threat intel may help you to focus your efforts  and actually determine what your risk is.  And it's not hard, but it does require effort.  Yeah, I think I mentioned most things already.  So a couple of quick wins.  Also start with an asset inventory,  work together with your vendor, and improve your network architecture.  And now, if you still worry about nation states,  and I put in some memes there.  The guy over there is Rob Joyce.  He used to be the Director of Tailored Access Operations from the NSA.  He actually did a brilliant presentation already in 2016,  where he explains how nation states attack and what they actually do.  And they say, well, they adapt to the target.  They won't use zero days if they don't need to.  They will invest the time and money to really know your systems.  And actually, the security measures I just mentioned,  if you take these, like network segmentation,  you make their life hard as well.  And if you don't believe me, watch his presentation.  That's it.


url: https://www.youtube.com/watch?v=p-KPJjTOum4
title: Protecting Organizations Against AITM: Lessons Learned - Rik Van Duijn & Wesley
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=p-KPJjTOum4",
    "title": "Protecting Organizations Against AITM: Lessons Learned - Rik Van Duijn & Wesley",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1777,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Well, let's get started.  Today we would like to share some security research we did on ATM, phishing attacks.  The problem, how big it is, prevention, detection, just things we found out since January we  started with this security research.  So who are we?  My name is Westin Eylek.  My colleague is Rik van Duin.  We are both co-founders of Zolder, a cybersecurity company.  And we have mainly experience in pen testing over 10 years.  So we've seen a lot of companies checking out the vulnerabilities they have and advising  them on solving those issues.  But since the start of Zolder, we also started creating more defensive solutions such as  our app called Attic, which we use to protect Microsoft 365 environments.  And that's also why we did security research on this part.  So our goal with Attic is to protect a lot of companies on a big scale.  So just the basic stuff, not a nation state attack, but just the confirmation of your  MFA, monitoring with Azure Sentinel.  We want to protect a lot of companies once and have a big impact like that.  Well, the problem we've seen is that we've seen a big increase of MFA ATM attacks.  And the issue is here that they are bypassing the MFA on your Microsoft 365 account.  And the interesting part is that we as a cybersecurity community pushed a lot of companies to use  MFA because that would solve any phishing attacks.  But now the cybercriminals are moving to ATM, which allows them to bypass MFA.  For example, the push notification on your phone or a text message is pretty easy to  bypass using ATM.  Just some history.  Well, in the early days, it was pretty simple, just phishing username, password.  You could just spray a lot of emails, spray a lot of text messages, and you could sleep  and then just wait until the results came in.  So at that time, phishing was pretty easy because you only needed the username and the  password.  Well, that's why a lot of companies introduced things like MFA, a second factor, which makes  it harder for you to break into the accounts.  Well, a next step we've seen is, for example, uAdmin, which was used by a lot of Dutch cybercriminals  to do the Marktplaatsfraude or WhatsApp fraude.  This was the next step.  For example, they were trying to phish the ING bank, which also used some second factors,  and they were luring the victim into the phish, for example, on the left page.  And when the victim fills in the username and password, the victim will wait and the  real criminal will log in at ING with your credentials and just give the response back  to you as a victim.  So this was a manual way of bypassing the extra steps, the multi-factor authentication.  This is, by the way, still being used by the Dutch criminals because this phishing panel  is sold all on Telegram, shared for 50 euro or something.  So this is still used and doesn't require a lot of technical knowledge, and it's still  effective.  But in 2017, 2018, this tool was released, Evil Jinx.  I remember it.  We were pen testing, so we, of course, dived into the tool.  But still, at that time, it was quite small.  It wasn't really becoming big at once.  But at this time, we've seen a big grow in the usage of this tool, but also the usage  of the technique that this tool is using.  So this is a tool that performs ATM attacks, and you have, of course, many more.  But this one is open source and available to everyone.  So we asked ourselves the question, why now?  So we've seen a huge increase in attacks against Microsoft 365.  We've seen a huge increase in similar phishing attacks against other services like Booking.com.  But the technique and the tools have been available since 2017, and we've been using  them a bit, and it's been used in pen testing services.  And for us, the main thing is there are SaaS services that provide the tooling, that provide  modification, if you require it.  You pay each week or each month, and you get a nice phishing panel.  Another reason is obviously more and more MFA, which is great.  It forces these types of attackers to change their tactics, which at least costs some effort.  But since it's all SaaS-ified now, yeah, that introduces quite a problem.  And more importantly, it just works on large scale.  So where initially we could phish 1,000 or 10,000 users and just go to sleep, wake up,  and get like username, password, and then later you could use that, then you go to like  the banking-style fraud where you're manually like a mule, copy and pasting everything.  And now you can go back to sleep again.  Well, not entirely.  You still need to act like semi-quick, but it allows you to do things at scale, which  is always interesting and important for criminals.  And it's what they do.  The attacks we see are like, yeah, not to be unfriendly towards those types of people,  but most of the problem creators are not the people that are really skilled.  They learn a trick, and they just keep doing it until it doesn't work anymore.  And with these SaaS-ified services, this creates that problem.  The current threats, of course.  So, current threats.  My slides.  Well, as I've said before, there's been a huge increase in, especially Microsoft 365  AATM attacks, phishing at a large scale, allowing backfraud to be more successful.  Microsoft announced like a 111% increase in token replay.  Well, that's both reverse proxy attacks and just malware stealing tokens from the browser  or your system.  But yeah, it's been growing and growing.  And you can see that.  So, if you like urlscan.io, which is if you hobby around with like, it's a showdown safari,  but for phishing sites.  And it allows you to search for like favicon hashes or like a specific CSS file or a specific  URL.  And it will increase.  You can just see like minutes ago, new M365 phishing pages pop up.  I've mentioned booking.com already.  And that problem initially was mostly stealer malware getting onto the system of the hotel  owner.  And now you see that they've switched tactics because like malware and antivirus is like  pretty annoying.  Especially if it's like somebody else hosting everything for you, it's pretty great.  And if you start looking into like phishing pages for booking.com hotel operators, it's  just funny how much.  And it's always something like complaint issue, whatever the fuck, or add-in D or BNB confirmation.  And all of these point to something like this, which is enter like a login page, not for  the end user, but for the hotel owner.  And this is the first step in a whole like supply chain thing, where if you have access  to the hotels, you can have access to the, like all the bookings and that allows you  to do stuff like this.  So this is something my colleague, Eric, he had a hotel booked in, I think it's Paris,  where he was, he got like a notification via the system telling him that his booking wasn't  completely correct.  And then linking him to this page.  And the funny thing is like the price is correct, they have all the information, they have your  booking number.  So this supply chain allows attackers to do like the best type of phishing, which is lots  and lots of pre-information allowing you to fall for this.  And it's funny because they're actually abusing the internal booking.com like messaging.  So it would be just interesting to have like a live feed of all the messages going from  into hotel owners and users, because I feel you might find lots and lots of the same messages  there.  But this problem, where Microsoft has been actively trying to fight this, booking seems  to have a bigger issue.  Mostly because if you look at the Microsoft pages, there's lots of like bot filtering  tricks and lots of like, the attackers are doing some effort to not get detected.  And the booking.com are like YOLO.  Look for the favicon hash and you'll find anything everywhere.  So it seems that booking could learn from Microsoft in this regard.  I'm still curious if it's a specific group who is using this attack.  I feel it's many.  Like there's one, somebody figured this out and then it spread.  Like anything with this type is like back to the farmer, just like plow on, do the same  thing over and over again.  And then, well, in the end, you always have to fill out your credit card information.  So that's where everything ends up.  Cool.  Yeah, we would like to explain something about the implementation, because we created a detection  system, which we'll explain later on.  But that also gave us some insights into implementations that are going around.  And this is specific to Microsoft 365.  Well, of course, you have Evil Jinx, the tool that's, it's used a lot because it's available  on GitHub.  The only problem is if you now spin Evil Jinx instance on a VPS, it's immediately spotted  and flagged.  So you have to do some tricks to fix that.  But that's also why cyber criminals are using, well, other solutions such as the SaaS solutions.  Another interesting implementation is the VNC in the browsers, already there for a long  time as well.  And I just think it's an interesting implementation because they are just streaming a VNC session  in a browser, which looks like a real, that you're visiting a real website.  So I just think that's an interesting approach to implement it.  They have Evil Puppet, which is another implementation also available on GitHub, not really maintained,  but it's, that's an implementation.  With Evil Jinx, you need specific visual aids.  For example, you have a Microsoft visual aid, a Google visual aid, which just modifies  a little bit for the specific target, and the Evil Puppet is an attempt to just make  it generic for all targets.  So that's an interesting approach as well.  The last two we've seen using our detection system.  For example, we've seen an implementation using a PHP, which is the fourth one.  We saw some interesting references to a really lame and old web shell.  So he was using the proxy functionality from a web shell.  They are using an AATM framework, which was quite interesting because you can see what  the code exactly is doing and stuff like that.  And the last one we also investigated, which was also interesting because they are using  Cloudflare workers, which is serverless computing on Cloudflare.  You just have to upload some code and that code is executed by Cloudflare.  So they will fix the web server.  They will, well, fix all the servers and stuff like that.  We've seen using our detection system that there are quite a lot of AATM phishing websites  hosted on domains ending with workers.dev, but that was the trigger like, okay, well,  how are they doing this?  How are they phishing you using Cloudflare?  Well, we didn't have the code because we didn't have access to the Cloudflare account of the  attacker, but the option we had was like, okay, let's just build this ourselves in Cloudflare  and see how hard it is.  And in the end, it was quite pretty simple.  And here you can see the implementation live.  It's about 150 lines of code.  We also published this on GitHub, so you can just upload the code to Cloudflare and you  can perform this attack yourself.  And it's just forwarding all the requests to Microsoft, and then it will send the username  and password to Teams and of course the cookies, which you can use to log in as the victim.  You can see if you take the cookies, put them in your browser, and you're simply logged  in as the victim.  That shows how easy it is.  And it took like a few hours, so it's pretty easy as well to build.  The code is on GitHub, on the link we've shared.  Yeah, we've become part of the problem now.  I don't know.  Don't start the OST debate.  Also we've seen some halt implementations.  So they are not really forwarding all the requests that Microsoft is sending and receiving.  But they, for example, only load the background image or the logo of the company.  So they don't really care about the rest of the layout.  The CSS that is able in Microsoft.  So well, I will come later back on this because this has some trouble with our detections.  And this is really, well, they use a lot of CAPTCHAs to protect our phishing websites,  and it is also really effective.  For example, this is Cloudflare turnstile, which is pretty cool.  You don't have to click anything.  It's a CAPTCHA which just loads for a while.  It's verifying and it just takes a few seconds and it will pass through if you are a human  and it will block you if you're a bot.  So we see a lot of criminals using this to hide their, for example, Evil Jinx instance.  And it's really effective as well.  It's so prevalent that we ended up deciding that if a new domain pops up from our detection  and we then try to visit it, we get the turnstile.  It's probably phishing.  So we're just using this as an indicator now instead of the actual site.  Yeah, something about the actors.  As I've said before, there's a SaaS type service and there's more and more actors out there.  These are some of the ones we've come into.  But the interesting thing now is that initially you had like a very limited set of SaaS providers  and they were like, it's a monthly or weekly pay type deal.  And there's no like growing of it because the thing with the SaaS service is like it runs somewhere else.  You can't like steal it.  You can't keep it.  So after two weeks, you have to like repay.  So it's a great model for them.  But also it contains the problem a bit.  So what I'm now seeing is on the different forums, there's more and more providers saying like,  hey, we can build you a reverse proxy for any website you like.  And you get the code, which means if the Dutch like bank phishing scene says anything about what's going to happen here,  it's that the moment you receive like the phishingpanel.zip for like 50 bucks,  you open it, you control H and replace everything with like myleadpanel.  And then you start selling that for like 50 bucks to recoup any of the costs you had for buying it.  And that's the same thing that's going to be happening here.  This is one of the providers.  It's Evil Proxy.  And the funny thing here was that they're also like doing like a weekly type deal.  So you can see it.  And in the...  Do I have lasers?  No, I have like switch screen.  Almost broke it.  So on the left, you can see like 10, 20 or 31 days and then the price and then whatever you want to phish.  And the interesting thing in that one is that it's also targeting like PyP, npm.js and RubyGems,  which would be pretty awesome to do like supply chain attacks on whatever you might like.  But here it's still you have to like talk to someone and then get someone to deploy something.  Like yesterday, I found this one, which feels more and more skinny to me, which is always fun.  It's PhishXProxy.  And this one gives you like a whole manual and you get an app.  So meaning that this is something you could like probably open and reverse.  And then it's your app and you call it, I don't know, PhishRickProxy.  It's 20 bucks cheaper.  And then the race to the bottom starts.  And then in the end, people start giving it out for free.  Problem grows, problem grows.  The funny thing with PhishXProxy was that they had like a Telegram bot that allows you to do the payment,  do the setup.  And it helps you through the process, like deposit the Bitcoin here, do the thing, all that.  And then there's Tycoon, one of the bigger ones, to be honest.  In the right, you can see my elitist of speak.  And, well, we just wanted to know like how much and where do you, where's the money going, please.  And then something, nothing happened, but we did get access to a panel.  And the funny thing with Tycoon, the funny thing with Tycoon is that if you have an organization  that uses, doesn't use Linux on like endpoints or on desktops, it's pretty easy to detect  because all their login happens from Linux systems.  So if you just look at the sign-in logs and you filter out Android, it's not very hard to detect.  But the thing is, you just don't send the money, but send the money and then you get this.  And there's nothing you really have to do in order to actually get access.  We looked at some of the, so we wondered like how much money are they making?  And for Tycoon specifically, we've been able to like, it depends on the day, obviously,  but it's like 660K in a year and a bit.  So it's not bad.  I mean, it's definitely not ransomware money.  But at the same time, I feel it's quite a lot risk, risk less, more risk-free.  It's more risk-free.  And I mean, you don't have to do much.  I mean, it's a SaaS service.  It's just like, press the button, it works.  And then you get 660K.  Interesting.  One of the addresses is like a USDT address.  And you can see that all the money is going to Binance in the end.  So he's sending all his money to Binance.  And I'm not a forensic person or related to the cops, but I feel that's pretty easy to  figure out who this is.  As long as he's not using like, I don't know, somebody that's giving him their Binance account.  But as far as I know, your customer is still in effect.  And it's pretty decently able to, you could be able to figure this out.  Cool.  Yeah, of course, the most important prevention and detection.  Well, let's get started with prevention.  Well, it is, compared to others, it is fairly easy on Microsoft 365.  But the downside is that it requires some licenses, the P1 and P2 from AAD.  And there are two main options.  You can enforce phishing-resistant MFA.  So POS keys and YubiKeys, for example.  The downside is, it is not really user-friendly yet.  I don't think you can get a company with 1000 people, all use YubiKeys.  And that's going to work well.  Another option is device compliance.  But this may have, well, you may have the same issue.  It may be hard to implement as well, because you're going to block devices  that may be on the network right now.  But at least you have options.  And there are many sites which you don't have.  At the moment, lots of companies are moving to POS keys.  But then if your account has a POS key,  and the tooling strips out any reference to POS keys  before sending it back to the user, you never get the POS key offering.  And then it allows you to still log in with username and password and MFA.  So you still end up being kind of vulnerable,  or you need to train people, which is hard.  Yeah, it's just hard.  So let's just explain how the proxy works.  I should definitely put this slide way in the front.  Yeah, I made this image because of the ATM worker that I created on Cloudflare.  So this explains how that was implemented.  And it's a pretty simple concept, because the victim visits the ATM worker,  so the fake fixie site.  The ATM worker forwards the request directly to Microsoft.  Then the response is as well sent to the ATM worker.  And at that point, I'm replacing just a few links in the response.  So the MicrosoftOnline.com links have to be replaced  with the URL of your phishing website.  And well, that pretty is what you have to do.  And of course, you have to capture the username, password,  and the cookies from the responses that are being transferred.  And then you can post to Teams.  So the only thing you have to do is forward all requests,  do a little bit of stupid replacements, just very simple replacements,  and grab the information out of it that you want.  And that's all you have to do to create an ATM framework for Microsoft.  So this is a pretty simple concept.  I thought before I started with building this,  I thought it was way, way harder.  Yeah, you ended up copying somebody else's Python script  and then just editing it to do this, right?  Yeah, somebody already published a Cloudflare worker  that was a reverse proxy, so I modified that one, of course.  Because it was Node.js, I don't...  Oh no, I don't know Node.js either.  Well, that was important because of this,  because we were already detecting website clones  and phishing attacks on regular websites.  And how we are doing is that we are placing a pixel in a real website.  And whenever this pixel is being loaded from another website,  we can alert a website owner that the website is copied manually  or that there may be a reverse proxy in place.  And then our colleague Eric came up with the idea,  can we also use the same technique to protect Microsoft 365,  well, tenants?  And he came up with the Microsoft Custom Branding CSS.  And when he came up with the idea, we were like,  hey, if that's gonna work, that's really interesting  because then we can protect Microsoft tenants  and detect at least the phishing attempts.  So we tried this by just adding a custom CSS  to a Microsoft login page,  pointing to the DidSomeoneCloneMe backend,  which allows you to detect the phishing attacks.  And well, it triggered a phishing attempt.  So here you can see that the reverse proxy was hosted on login.atm.tag  and that it detected the phishing attempt.  So that was pretty cool  because we could use this technique to protect our customers.  So we did.  And in the first month, we were able to, well, connect 100 tenants.  So we installed the CSS on direct tenants  and we get all the detections that occurred.  And well, to be honest, before I started with this,  I didn't expect a lot of detection  because I still thought ATM was for the specific people  that used it and attacked it.  And it was not really being used on scale.  But in the first month, we had about 162 detections  on the 100 different tenants.  So within a month, I think that's quite a lot.  And in nine months, we have about 1300 detections.  And of course, the detections differ per company.  For example, we have a company with about 50,000 employees  and you can see that there are way more detections.  Some tenants do not have any detection  because they are just really, really small.  So well, here we realized that it was quite a big problem going on.  And even, that's why I explained the whole implementation,  we do not detect all phishing attempts  because some phishing framers do strip the CSS, of course.  So this is just a tip.  So, well, now we get a lot of alerts  from all the tenants that are protected.  You can also see that from that data,  you can see that the phishing attempts  are also performed across tenants.  So here you see some things from the database.  You can see that different protected tenants  are receiving the same phishing website, phishing attempts.  So you can just see that they are spraying the AATM  across different organization on a big scale  and just, well, try to hit everything.  Before creating this software,  we didn't know if this is going to be very effective  because, of course, there's also always a chance for false positives.  But this was quite, well, nice  because we didn't have a lot of false positives.  We just have to filter out a couple of domains  and after that, the detection is very reliable.  I will skip this one.  Ah, cool.  Well, no, I want to go back.  I want to tell this.  So it's pretty interesting.  I just find this funny.  Initially, we were like, oh, there's so many hits, so many hits.  And then we figured out that all these ranges  are like Microsoft ranges  and this is sandboxes hitting you  and not the actual end user getting phished.  But if you send alerts out based on this,  you're like, you're dying.  Your whole company is under attack.  Everybody's going to die  and there's actually nothing happening.  And it's funny to see like Microsoft trying to do a thing too.  So for the future,  we've seen a huge increase in the offering of the,  like offering of customization phishlets,  just complete solutions.  On the right, you can see like a live.com,  just not even targeting companies anymore,  but just targeting like end users.  So you see that the value of the whole thing is going down  because it's a live.com account is way less valuable,  depending on the user,  than like the more like Microsoft accounts,  booking.com, hotel owner sites.  And then at the same time, because it costs money there,  you can see like people asking for generic reverse proxy options.  And the next thing, at least in the Netherlands,  is going to be bank phishing,  where the whole process of asking for sending money  or adding an account or adding your bank account to the phone,  that's going to be automated via ITM.  And that's going to allow them to work more efficiently  because currently they're literally screenshotting the QR code  and sending it to the user, which is stupid.  So that's definitely going to happen.  And in conclusion, it's going to be shit for a while,  which is always good to have like an uplifting thing.  We're going to see a large increase still,  not just against targeted against companies,  but targeting like regular users.  Companies will need to like switch how they work with this.  Passkeys are very good,  but they're not the user experiences.  And if you don't enforce your passkeys,  once you've configured them,  it will definitely leave you vulnerable.  We're definitely out of time.  Thank you so much for listening.  And if you want like the free ITM for Microsoft 365,  you can use our free option to detect this type of attack.  So thank you very much.  Thank you.


url: https://www.youtube.com/watch?v=zPbH-xJ_RpM
title: Offensive Development In Modern Languages - Cas Van Cooten
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=zPbH-xJ_RpM",
    "title": "Offensive Development In Modern Languages - Cas Van Cooten",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1857,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Thank you, good afternoon, good to see you all here.  My name is Cas van Kooten and today we're going to talk about languages, programming  languages of course, but I wanted to start with a little bridge to languages in the classical  sense of the word, because languages to me are really fascinating.  Everyone or mostly everyone knows at least one language, most people know two, especially  here in the Netherlands I think a lot of people know three, four, five or more languages,  and the interesting thing is that languages are all related, like, right, they're like  families in a big tree, you can see some languages are closer together, some are further apart,  but that means that the more languages that you learn, the more parallels that you see  between these languages, and that the easier it gets to learn new languages, the more that  you know, and this is also true for programming languages, so a lot of people think that learning  a new programming language is really hard, which it can be, it's not always easy, but  actually every programming language is essentially doing the same thing, right, you're trying  to achieve something programmatically, there's these constructs like logic statements, if  else, whatever, there's loops in there, and this is kind of generic for every language,  so the more programming languages that you learn, the easier it gets, and that's also  a little bit of a flash forward to my call to action today, which is learn as many languages  as you can, I'm a big fan of modern languages, can also be ancient boomer languages like  C, that's up to you, but yeah, that will be my key message today. Of course, we're  not only going to talk about languages, we're going to put it into a perspective a little  bit of offensive development, so I tailored it a little bit to my world view, which is  distinctly red, also useful of course for anyone that wants to automate more in their  life, including blue teamers. A little bit about me, I'll skip through this a little  bit, because we have a lot to discuss, but my name is Cas van Kooten, I'm a red teamer  at a big bank you may know here in the Netherlands, I call myself a malware linguist, because  I really enjoy, as you may guess by now, learning new, especially modern languages like Go,  Rust, Nim, and trying to apply that to the field of offensive security. So that's also  what we're going to talk about today, you can find me on Twitter as well with some shitty  memes mostly, but sometimes there's some knowledge sharing there as well, and I post some stuff  on GitHub if you want some examples. So, let's take a step back to offensive development  to start with. I think this situation, if you're in offensive operations, is all too  familiar by now, I think over the last couple of years, probably five or more by now, we've  seen this kind of race between red and blue, right, and this is not new, this has always  been there, but especially in the area of OST, offensive security tooling, or open source  tooling, depending on what your definition is, this is very relevant, because there's  great tools that get published all the time, you can grab them off of GitHub and run them  on your client's network, and you will have a bad day, because, of course, the blue team  is not sitting still, right, they are also looking at these great tools and making sure  they are fingerprinted. So, to use these tools in practice, you need something of a development  capability. So, the kind of least you can do is modify it, but there's other options  as well. Essentially, there's three, and this comes down a little bit to a business decision,  because as a red team, as an offensive team, you get the choice here, how much do you want  to do, or how much do you want to pay, essentially. So, the first option is to purchase your offensive  tooling, I think more and more we are seeing offensive security companies step up and offer  tooling that you can use, which is kind of evasive by design, so you're kind of paying  money to get tooling that works in practice, right, you don't have to change it anymore,  there's commercial C2 frameworks, you have old toolkits like Outflank is offering now,  for example, and, yes, you get all these options that you can essentially procure, so you don't  need to do it yourself. A very valid option, you can also choose to adapt the tooling,  that's essentially what I just mentioned, you have open source tools, right, they work  well, but they are fingerprinted, so if you modify them to get rid of the fingerprints,  you can use them again. The downside of that is that it's, well, there's still some behaviour  in there that you may not completely understand, because it's not your tool, right, the upside  is that it saves you a lot of time, development time, essentially. And the last option is  actually what we're going to focus on today, which is to develop your own tools. Developing  your own tools is my personal favourite, because it's a lot of fun, first of all, but also  it gives you 100% complete control of what you're building, right, that makes sense,  but from an offensive perspective, that also means you have full control over the IOCs,  the indicators that you're leaving in a client network, you have full control of what you're  actually building. Of course, the downside, again, is that it takes the most time, but  yeah, given the fact that it's a lot of fun, in my experience, I would definitely recommend  going there. So, when I say offensive development, or development in the context of offensive  security, a lot of people immediately assume that I'm talking about malware development,  but in my view, those two are a little bit different. I would actually say that malware  development is a subset of offensive development. For the reasons that you see here, of course,  offensive development encompasses everything that's used to support an offensive operations,  right, and malware development I would define as everything that runs on your target system.  Of course, the latter, malware development, is quite a different ballgame, because there  you're dealing with these defences, you're dealing with EDR, you're dealing with network  protocols, all these kinds of things. So, developing for on-target operations is quite  challenging, but there's more to it. So, if you look at some of the examples here, you  can see that a lot of supporting tooling, even like the knowledge management or the  scripts that you use to automate your offensive operations, these are all part of offensive  development. So, I wanted to mention that just to set the scene a little bit for what  we're going to discuss later. And one other thing that I wanted to mention before we actually  get to the programming languages is the development part of offensive development, because we  hackers are very known to kind of sitting like a monkey behind a keyboard and putting  out some code that's like POC code, right? A lot of GitHub tools that you see actually  have a disclaimer that says, this is a POC, I wrote this in one night, I was drunk, whatever,  don't run this in production, and then everyone takes it and runs it in production, right?  So of course, working code is better than perfect code, but I would argue for a little  bit more of a developer mindset in the field of offensive development or any development  that we're doing in the context of security. Because bad code, bad code or maybe a code  that you wrote very quickly or whatever, has a real impact. First of all, it can bother  other people, right? If you're, for example, publishing your code on GitHub or you're collaborating  on it with colleagues, and you have like one big chunk of code in one file that's not annotated,  there's no comments, the variables are named very specifically or you have like I, J, X,  Y, Z, then everyone reading this is like, oh, what's this? And maybe if it's open source,  people decide not to maintain or not to contribute to your project, because it's not readable,  right? This is very easy to avoid. It just takes a little bit of a mindset while you're  programming. Stability is another concern. This is usually for malware or like POCs,  this is not a big problem, but when you're writing on target implants, for example, C2  implants that need to run for weeks or months, maybe years on end, you really don't want  a memory leak in there or some oversight that causes it to crash at a random time during  the year. So, that's a real concern as well. And finally, of course, we are security professionals.  Bad code also impacts security. Now, a small disclaimer here. I don't want to shit too  much on Paul, who is the maintainer of Havoc, because that's actually an excellent project.  This is just the last example I could find of vulnerabilities being in security tools.  The source security tools in this example, but it also happened to Cobalt Strike, for  example. It's funny that we are security professionals, right? But the moment we start coding, sometimes  we kind of forget the principles that we teach to others all the time. Of course, you know  all the web vulnerability stuff, but there's much more to it. And I think proper dev practice  also means that when we are developing something, we should be really conscious about what we're  doing, who's going to be able to communicate with it, will someone be able to intercept  that traffic and abuse it, stuff like this. The good news is that it's not really hard  to adopt this developer mindset, as I call it. It takes some maybe getting used to, some  switching, but it's actually, yeah, it's just a couple of principles that can really help  you get a long way. There's a couple of principles like, of course, commenting your code, structuring  it well, depending on which language you are using, and trying to minimize the repetition  of code. Just a couple of principles can already help you really elevate your POCs to the next  level. There's a couple of books as well. I particularly enjoyed this one, which are  interesting to read as a security professional, because they kind of take a step back and  go through these concepts that can really help you put the developer in offensive development.  And I also found that AI, so Copilot or whatever AI assistant you are using, can actually help  a lot here. There's a couple of prompts or a couple of keywords like idiomatic code,  that if you ask it that, it will come back and kind of get all the knowledge that it  took from the Stack Overflow geeks and dump it on you, which is actually really good when  you're learning a new language, right? Because you may be used to some low-level language  and suddenly you're programming something in Python and all these idioms, so the practices  in that specific language are very different than you're used to. So having AI kind of  look over your shoulder, be very pedantic about the style that you use, the structuring  of your code can help a lot. So let's actually get into the programming languages then. Also  there, when choosing a language for your offensive project, I think we can just look at what  normal developers are doing, right? On the right here, you see the Stack Overflow developer  survey, which is like a yearly thing that they do where they ask which programming languages  do you currently use, which is like the blue lines here, and which ones would you like  to use in the coming year, which is the red lines over there. It's quite interesting to  look at, honestly. They have a lot more questions as well, so I would recommend looking at that  survey online if you have the chance. But there's a couple of trends that you see, for  example, Rust, of course, being hyped as always. Python is the number one that's, I think,  for many years now. And that's very relevant for us security professionals to know as well,  especially when you're writing on target malware. We've seen this with Nim, for example.  If no one is using the language legitimately and suddenly this suspicious binary pops up  that's written in Nim and it's doing some weird allocations, then antivirus is just  like, get out of here, because that's not going to happen, right? So the prevalence  of a language actually helps in evasion. But, of course, every language has kind of intrinsic  design principles and elements that also make it relevant to choose as an offensive practitioner.  A couple of considerations. I think one of the main considerations for offensive development  is whether the language is interpreted or compiled. So interpreted means that there's  like an interpreter that you need on the system already to read the code line by line and  execute it. Python, I think, is the most famous example here. The downside is that the portability  of the language really dives, because you need to have that interpreter on the system  to do anything. The upside is if the interpreter is on the system already, it's great. If you're  doing off target operations, this is great, because the interpreter can really help you  get started quickly and, yeah, hit the ground running, so to say. Compiled, on the other  hand, means that when you're done coding, you compile an artifact, so like an executable  for Windows, for example, elf binary for Linux, whatever, and you can take that, drop  it anywhere where it's compiled for, and just run it. This is usually what you would do  for like actual malware development. You would choose a compiled language, because you're  not dependent on that runtime, right? Very important as well is is the language high  level or low level? Now, this is a bit vague, maybe hard to define, but in general, a language  kind of intrinsically gives you some level of abstraction, right? I think Python probably  is the most famous example of a very high level language, meaning that there's a lot  of abstractions in Python that make the code very readable. Sometimes Python almost reads  like natural English, but the abstractions mean that you're typing that and you're not  exactly sure what's happening under the hood, right? The opposite of that is low level,  where you're essentially giving the computer literal instructions in almost in computer  language. This is what happens in C, right, or even assembler, where really, like, you  have to think about what's the computer doing, and it's not abstracting anything for you.  It's literally doing what you're saying, which brings a lot of risks as well, like safety  in C is a big topic now that Rust jumped into, but, yes, it's a consideration depending on  your product that matters. Performance. In my experience, performance is a little bit  less important for most security tooling. Usually, unless you're writing, like, a highly  concurrent port scanner, for example, we really don't care that much about performance, where  normal developers would care a lot more, but still, if you're writing a project that does  care about performance, of course, you need to factor that in, because some languages  are less performant than others, and it can also really differ per use case as well.  Portability. Already mentioned compiled languages, where you just get a binary and can drop it  somewhere. I also consider cross compilation to be a part of this, where you can sit on  Linux, compile something for Windows or for MacOS, and I think especially modern languages  are very good at this, where, for example, in Golang, you write your code, if you don't  use any OS-specific libraries, then you can just compile it for whatever, right? Nim also  did this. I think they natively offered support for what was it, the Nintendo Switch or something  like that, so modern languages are good at this, but, of course, you need to keep it  in mind and consider if it's even relevant for your project. Then the prevalence. I think  I already discussed this at the start of this slide. Prevalence essentially means how  much is a language used? The more it's used, the more it will blend in. Simple as that.  And, finally, I also put developer experience here, which is an often overlooked fact, because  people are saying, oh, Rust is the new fastest language, or, no, everyone is using C, you  should use C, but when I code in C, personally, I become very unhappy, so that's essentially  what developer experience means, right? Is there a good community? Is the compiler helping  you fix your errors? Again, AI is now a part of this as well, so, essentially, how do you  feel when coding in a certain language? This is arguably maybe the most important option  when choosing a language. Maybe it doesn't really matter to you, that's also fine, but  it's something to consider before choosing a language, for sure. Typing is also part  of a language. For those who don't know, typing essentially means that you're telling a language  what type you want a certain variable to be. That's sometimes it's optional, like in Python,  you are allowed to define types. It's not always very strict. Some languages are very  pedantic about this. I think it's nice, because exactly this happens, right, where you're  coding something, and you do something weird, where suddenly a string enters the production  line of integers, and then, in the former case, your IDE or your text editor can already  tell you, hey, there's something weird going on here, right, and sometimes people just  code something, and it's like, oh, I guess we're doing strings now, and when you run  that on a target, it will do silly things, right, so typing is also something to take  into account. So how do you actually choose a language? Well, definitely do not use this  decision tree, but it's like an example of your, yeah, like a mind map that you could  use to choose a language, right? You have all these properties that I just mentioned.  You can essentially just Google them for new languages, like, okay, how performant does  O, and you will get a lot of people saying, oh, Rust is better, and you look into Rust,  and then you get people saying C is better, so you get into this rabbit hole, but in the  end, you could almost make like an Excel sheet, map all the properties, find the ones that  matter to you, and Bob's your uncle, that's the language you will use. Of course, there's  a strong level of preference there as well, but in very high terms, I think the kind of  lower level-ish languages would be used a lot for malware development, right? Especially if  you need all the control you can get, then this is the classical choice. I think this is the  less classical choice for real malware development, but again, if you're writing something that  doesn't need to run on a victim system, or it's not necessarily malware, then I think  something like Go or even Python are excellent choices. So let's give a couple of examples  of languages. I only have half an hour today, so I picked two. You can already guess that  the first one is Rust, right, because I did want to address some of the hype, what's true  and what's not true about the hype. So Rust is a very interesting language, right? It's  kind of jumping in the successor spot of C, even though C is still around a lot. Rust  is trying to be safe C, right? So it's giving you all these tools, a very strong  and strict compiler that's helping you write low-level code that's also safe. Now, the safety  doesn't always matter that much for us malware developers, and that has some implications on  the code that we write, because we will need to use a lot of unsafe clauses, but I think for  anything else, it's really interesting, because that part about stability of security,  Rust kind of solves intrinsically. It doesn't solve everything, don't get me wrong. It solves  a lot of commonly made errors. It solves by using this mechanism that we call the borrow checker.  The borrow checker is essentially just a tool that checks who is the owner of certain data at  a certain time. That's like the easiest way to summarize it. Definitely won't get into all the  rules of the borrow checker here, but what it means is essentially at compile time, or if you're  using linters or whatever, then even before, it will look at who's the owner of certain variables  and if it's not moving in a way that it shouldn't be. So it's not being accessed by another function  that's not the owner of it. There's no race conditions about the data. All kinds of stuff  like this are being checked by this borrow checker. We will have an example about what this  looks like. Important to mention is that there's no garbage collection, so other languages like  Go, for example, they have a garbage collector, so that's like a part of the runtime that comes  in once in a while, checks is this variable still used, no, cleans it up, but that borrow checker  has a performance impact, so it's actually bad for real-time or embedded applications.  Rust does not have that, so that's an advantage performance-wise. Another advantage is that it  gives you really verbose errors, like if you did something stupid, it will literally say you did  something stupid here in this line at this character and fix it in this way. So a lot of  those issues are usually fixable very easily, and it's very well adopted. There's a  mature ecosystem. It's used a lot now. Here's some examples to get you started. The slides,  by the way, with links are on my GitHub if you want to click the links instead of taking pictures.  So that's something you could do. One thing that I really liked about Rust is the fact that  there's quite a mature linter, which we call Clippy. So Clippy has a pedantic mode where it  gets really uptight about everything that you're doing. I found that really nice when first  developing Rust because it also checks are you writing well-structured code, are you writing  idiomatic code, stuff like this. It really helps you pick up the language. So if you give Rust a  spin, I would advise to use Clippy. If you're up for it, put it in pedantic mode. There's also  easier going modes, but it really helps write the code. So here's an example. We will go through it  part by part. In this example, we are not only using the standard library. This example is  actually some code that shows a message box with okay or cancel a couple of times, so really,  really basic. So we use the Win32 library. That's actually a Microsoft-built library because, of  course, they're also using Rust in Windows now. So that's quite mature. There's two variants.  There's one that's literally just the API wrappers, or there's a more Rustified version, which is  this variant. Then we enter the main loop, and there's a couple of interesting things happening  here. So first off, you see the kind of error handling that Rust has. Rust has a very specific  error handling mechanism where you usually return a result. A result can either be okay or error,  and then at the end of the function, you return the okay. If it's not okay, you return the error.  This doesn't look like much, but it actually allows a lot of subfunctions to look at this  result of another function and verify if it did what you wanted. If you're returning a result,  you can also return upstream errors in this way by using the question mark operator.  So it doesn't always have to be super verbose. It is sometimes, because Rust is just a verbose  language. And another interesting point is that everything in Rust is immutable by default. So if  you want a mutable variable, a variable that you need to edit, you actually have to specify that  it's mutable. Again, it doesn't seem like much, but this has huge implications in the logic that  Rust uses to check if you're not making a mistake. Then we go to the actual Windows API call.  Again, we see the error handling. This time we have a result that contains an option.  So an option is either something, some value or none. Again, having this type just gives you the  option to verify whether you actually got a result. It's a bit more sturdy than just using  the none in value in Python, for example, in terms of typing. And then you see here you have all the  okay results with a value or you return the error and that error would be handled by the question  mark by the caller. Here's the dreaded unsafe block. I wanted to show that unsafe is not  necessarily bad, right? Because Rust often gets ridiculed a bit in the malware development space  where the unsafe is just one big unsafe block. But if you use it properly, it's just a contract  that says, okay, here I'm becoming responsible for the potential unsafety of whatever I'm calling  within. That's just what Rust is telling you to do because in this block, the compiler cannot  guarantee safety anymore, so you need to think about, okay, is this the white variant? I need to  give it a white string, right? Stuff like this you need to think about so it actually makes it  quite explicit. And then you have a standard match clause which returns the result.  The other example that I wanted to give is Go. Sorry, guys, I'm running a little bit over time  here, but I'll take a couple minutes more. Go, I think, is very interesting because it's both  really useful on the target system as compiled binaries, .exes, for example, as well as on the  server. Go is very performant. It has a very good concurrency mechanism that we'll have a quick look  at in a bit. It has a really good standard library. There's packages for everything that you can  imagine. And the syntax is actually really simple. So I would argue that Go is almost as easy to  learn as Python, and it gives you these advantages of a really portable and performant compiled  language, right, because Python clearly has some performance issues, and that's where Go is really  valuable. So another example here which we'll go through quickly, we see some packages being  imported. You see the formatting and networking, synchronization. This is all standard library,  so despite the fact that it has import, it means just that it's importing it from the standard  library, so you don't need to install anything to use this. And then this code is essentially a  very concurrent port scanner in just I think it's like 30 lines of code. So what we're doing here  is just, well, preparing the port scan, right? We're not doing any argument parsing or stuff  like that, but the key call here is actually the Go keyword, because with the Go keyword,  that means you're starting a Go routine, and Go routine is Go's implementation of concurrency.  Essentially this call means that we're calling this function, which is this one, we'll take a  look at that in just a minute, and it's starting it concurrently. So it's just starting a background  job essentially, and continuing with the rest of the loop. So what we're doing here is starting  1024 instances of this scan port function. Now to manage that concurrency, we're using something  that's called a wait group. Essentially it's just a counter that says, okay, we go up to 1024 in  this case, and then whenever every instance is done, we decrement one, and this wait call is  just blocking until all the processes are done. So the actual scanner implementation is also really  simple. One thing that I wanted to highlight is the defer call, which is quite nice. It means  call this whenever the scope ends, so either when the function exits, we call it, or when an  unexpected error occurs. So just a really clean way to do your cleanup, stuff like that, and also  the cleanup in case of errors, which is not usually the case. And then you have the error handling,  which can be quite verbose in Go. Usually you would see something like this, but the inverse,  so if the error is not nil, then we do some error management. Other than that, this just scans a  single port, so the result again in 30 lines is a MMOP for poor people. So that's actually  all I had to say today. Again, the call to action would be, please look into every language  you can get your hands on, play with it, adhere a little bit as best as you can to good developer  practice, build your own tools, and yeah, remember that new languages are not as hard  to pick up as the first language that you ever picked up. Thank you very much.


url: https://www.youtube.com/watch?v=T92verdYJAQ
title: Attacking Primary Refresh Tokens Using Their MacOS Implementation - Dirk-Jan Mollema & Olaf Hartong
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=T92verdYJAQ",
    "title": "Attacking Primary Refresh Tokens Using Their MacOS Implementation - Dirk-Jan Mollema & Olaf Hartong",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 2360,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Welcome to our story.  So we spent quite some time on building slides, fortunately we're not the only ones having  cool slides, so that's cool.  So we have a couple of topics to talk about.  So first of all, we're going to explain a little bit what primary refresh tokens are  and how they are used.  We're going to explain a little bit more about the new protocol versions that we found during  our research that may be different than the Microsoft website.  So yes, they're not even documented.  Then we're going to highlight the secure enclave a little bit, which is basically the TPM implementation  on macOS.  We're not going to drop zero days.  At least, we didn't even think we had a zero day up until we submitted it to Microsoft  and then they wanted to have a phone call.  So it turns out it was, in their opinion, a critical one, so we can't demo and explain  everything.  We're going to show you some stuff that still works and is interesting, but not everything  until it's patched, which is probably somewhere next year, maybe.  And that's primarily because it involves all operating systems and implementations there,  so that's complicating it a little bit for them.  So I'm Olaf.  Of course, I like Warm Hugs, thanks to Disney, and I'm a security researcher and detection  engineer at Falcon Force, and I'm on Twitter, and I'm joined with Dirk-Jan.  Hi, I'm Dirk-Jan.  I have my own company called Outsider Security.  I've been doing that for two and a half years.  I like to research weird protocols, well, not so weird protocols, maybe all of the things  are standardized.  I like diving into basically all the modern Microsoft products, been researching Anthra  since four or five years, when it was still called the good old Azure AD.  I also have a Twitter account.  If you want to keep up with the new research that I'm publishing there, you're more than  welcome to.  So actually, our story started quite a while ago, because we were talking about primary  freeze tokens, and Olaf was like, well, you're talking about Windows, but I also have a Mac  here, and I don't know how it works over there.  I was like, well, I don't know how Mac works, so maybe we can do it together, and Olaf knows  how Mac works, and I know a thing or two about tokens, and we did that, like, in the end  of 2022.  We found some interesting protocol versions.  We worked on implementing them, and then we were kind of laying it, or we left it around  for a while.  Basically, we're both quite busy.  We don't see each other every week, so we decided to submit it for a conference, and  at that point, the talk was accepted, so we were like, well, now we kind of need to finalize  it, make these slides and stuff.  So then we basically wrapped up the research in April or May of this year, and then we  found out that actually Microsoft released a completely new version, like, two weeks  before we looked at it again, so we could kind of go back to square one and look at  the new protocol version, which was entirely different from anything we've seen before.  So this is also where we found out the new version, coded it, reported it to Microsoft,  and also added the support for the tools for it, and now we can talk about most of it,  but again, some of the stuff is still being worked at by Microsoft, and we wrapped this  up in this nice little storybook.  Yeah, so of course, every story needs some characters, right?  So we have our quick fish Quinn, who's implementing codes, that may be us, or that may be Microsoft,  that's not that relevant now.  Then we have our main character, probably, who is the pathfinder that actually wants  to navigate and try to find all the nice paths that we can actually utilize.  Then we have Sir Block a lot, he wants to build dams because he wants to protect everything  or keep stuff from leaking, and then we have our kingfisher, who actually loves fishing,  of course.  So from there, we started a lot of research.  There is some prior research that we encountered, sort of after we found our own stuff and started  Googling, if other people did, Thomas Nauenheim from Gluconia, he is also quite a really good  researcher.  He found some stuff, how to replace some of the PRTs that he found on his Mac, and he  wrote that up, so it's definitely worth looking at this blog.  Just to get everybody in the same mindset, we want to kind of highlight the basics of  the PRTs.  We're not going to explain everything because we don't want to fry your brain too much,  but essentially how tokens and authentication works on unmanaged Windows hosts, that's quite  important.  So we have our user, and our user wants Teams access, right?  So he signs into Teams, Teams will actually request tokens from EnterID, which will be  an access token and a refresh token, and then uses that refresh token against Entra  again to get access tokens to the Teams backend, and maybe other access tokens to Exchange  and SharePoint.  And it's important to note the difference where a refresh token can request an access  token, and an access token is only for one specific use.  Yes, so this is on unmanaged hosts, and these are basically the standard OAuth protocols.  However, if you are on a managed Windows device, then the flow gets a little bit more complicated,  because we don't want to sign users into each app individually, have each app manage their  own tokens, have everything asynchronously sign out, all that kind of things.  So on Windows, the user doesn't sign into apps, they actually sign into the device.  And that means that when they sign in, LSAS will take those credentials, and LSAS is going  to request our primary refresh token, and the primary refresh token is a single sign-on  token.  So once that is in our session, it will be valid to sign in to basically anything that's  also running on our device.  So if the user starts Teams, and Teams in this case is acting as a OAuth client, Teams  will actually ask the broker for some tokens.  So in this case, Teams is not directly authenticating to Entra, it's actually asking the broker  to do that on Windows or on other operating systems, because they also work with a token  broker.  And the token broker is asking LSAS, hey, can I use this PRT?  LSAS is going to do some cryptography, and it's going to actually send the correct PRT,  basically assertion, so something that's signed by LSAS.  That's being used to talk to Entra, Entra gives out the tokens, the broker gives the  tokens to Teams, and that is how Teams basically can access all of its services that it needs  to do.  So instead of Teams doing the refresh token dance directly, it's asking LSAS to use the  PRT, and in that way, it can do the same thing as any other app can do in our session.  So just some facts about these primary refresh tokens.  We're going to cover this in the whole talk, so this is kind of important.  So primary refresh tokens are single sign-on tokens.  So once you have one of these, you can sign in to anything that your account can also  sign in.  It can be a native app, it can be like a CLI, basically it is a true single sign-on token.  The primary refresh token is also the mechanism in which a user identity is linked to a device  identity.  So if you are familiar with how Microsoft 365 works, very often you see conditional  access policies that require a certain device state, like the device being compliant or  hybrid joint, and that is also done through the same primary refresh token mechanism.  So the primary refresh token is tied to a user and also tied to a device.  Now a primary refresh token is obviously very powerful, so that's why it needs a session  key to operate.  So that's like a cryptographic key that proves that we are authorized to use this primary  refresh token, and the session keys, because they are so sensitive, they will be protected  by a trusted platform module on Windows, secure enclave on macOS, as we'll see in a little  bit, and it also binds the PRT to a device.  So even if your system, on a modern Windows device, you'll not be able to steal these  kind of tokens.  So because PRTs are single sign-on tokens, they fit kind of in this token hierarchy.  So at the top we have a primary refresh token, of which we only have like one or two, and  with primary refresh tokens we can request regular refresh tokens or access tokens.  Refresh tokens are there per app, and access tokens are there per service that each app  is accessing, so we have more access tokens than refresh tokens, and we have more refresh  tokens than primary refresh tokens.  So there's also a few protocol versions.  On Windows, basically what we have is PRT version 2, and Windows is of course the platform  that is fully controlled by Microsoft, so they can make it in any way they want.  But on other operating systems, they don't have all the same controls.  They sometimes have to rely a bit on what the operating system offers.  So especially on macOS, they had to kind of roll with whatever implementation Apple  was doing and not have their own full control.  So to accommodate that, they made a PRT version 3, and they also introduced a new PRT version  that's actually not tied to a device.  So how does the device actually get a PRT in the first place?  And this is all, again, going to be related to a lot of crypto, so whenever a device is  registered in Entra, it's going to generate a private key.  It's going to generate a public key based on that private key, and those are RSA keys.  With these keys, it's going to do the device registration, which means that the device  will get a certificate, and it's also getting a transport key for extra security during  the transport.  This is very similar on macOS, so the biggest difference is that on Windows, it's going  to send this as a bcrypt RSA blob, which is like a Windows internal structure, and  on macOS, it's actually using this JSON web key standard, which means that the RSA key  is presented as a JSON structure.  And the specifications for this are written by somebody who used to work at Microsoft  called Michael Jones.  We'll see his name a few more times because he's involved a lot in all of these OAuth  or all the other specifications surrounding this.  So how does a PRT work on Windows schematically?  So whatever we do, we start with some kind of authentication material.  It can be a password, it can be something like a FIDO key, and with that, we authenticate  to our Windows device, and at this point, our Windows device will send a signed payload  to Entra.  So it's signed with the private key of the device.  We prove that it's actually this device that is issuing this PRT request.  The device then receives a primary refresh token and a transport key encrypted session  key.  So the session key is not in plain text, it's actually encrypted with the transport key,  which also ties it to our 3PM, so it's actually tied to the hardware of the device.  Once we have this session key, then we can start using the primary refresh token.  So we sign a payload with the session key, we send that to Entra, then Entra is going  to give us a token for a specific app, for example, for Teams.  But again, this is going to be encrypted, and it's going to use the session key to decrypt  that payload.  It's going to be encrypted with a standard called JWE, or JSON Web Encryption.  So it's related to the JSON Web Token standard, but it's actually encrypted.  So that's how it works on Windows.  On macOS, however, it's quite a bit more complicated.  And you see in this slide, on the top right, there is this little sunny symbol.  And this you'll see on a few more slides, and it essentially means that this is one  of the key slides of this talk.  So there's quite a few complex things here in the presentation, but if you need to remember  a few slides, it must be these slides.  So pay attention there, the rest you can sort of sleep or read them afterwards.  And basically on macOS, the procedure looks as follows.  So we still log in, so we use our credentials to authenticate.  And in this case, it's not going to directly send that to Entra, but it's actually following  the authorization code flow, which is standard OAuth flow.  This case is using that for this specific client, and it's actually sending an on-the-fly  generated transport key to Entra.  So there's no device yet at this point.  We haven't registered our device yet.  Which means that the primary refresh token that we receive is not going to be bound to  a device.  After that, it's actually going to register the device, so now we have a device.  Then it's sending the first PRT, plus a payload that is signed with the private key of our  device.  So we prove now that this was requested by a real device, we send that to Entra.  Then we get back a new PRT, and this is called a device-bound PRT, because it's linked to  our device.  Plus, again, a session key that is encrypted with our transport key.  And with that, we can again request tokens.  So you see that there's essentially two different primary refresh tokens involved.  There is this first primary refresh token that's actually not linked to a device, because  the device registration happens afterwards.  And there's a second primary refresh token that is actually device-bound, and it is linked  to our macOS device specifically.  And this is all possible with the PRT protocol version 3.  Yeah, so the biggest difference here, and I think my mic is at some point joining, is  two implementations that we actually looked at.  So this is back in 2022, when version 4 wasn't a thing yet.  Basically, we started with Edge.  So Edge on Mac allows you to sign in and then join the tenant that you're a part of, only  for Edge.  And then you have SSO within Edge for all the things that you want to access, right?  So that's where the device-less PRT first came on our radar.  The second version is if you want to be a little bit more in control of your Mac users  and manage them, actually, you can use Intune.  There's other products, of course.  And for this, Microsoft built their own SSO extension that you need to install.  And this will actually generate that device-bound PRT that you saw in the previous slides.  So if we would go back, so that left bit, the PRT plus the transport key only, that's  basically the device-less version, which will be used by Edge.  The bottom one over here will be used by Intune.  So there are two different PRTs.  Sometimes they might still live on the same system.  So that's something, if you're a techer, that could be interesting to look at, because they  are differently protected.  In our discussions with Microsoft, we also learned that there are other platforms doing  similar stuff, like Android, iOS, all kinds of other obscure OSes, maybe, as well.  But we didn't really look at it, because we were already distracted enough by this.  So on Edge, if you start logging on as a user in Edge, so not via the browsing methodology,  but for the application itself, you would see a similar flow, as you would see from  a lot of other OAuth flows.  But you also get a PRT back.  So basically, how that works, as Stirkjohn explained earlier, is you log on, you get  an authorization code, which you receive from that flow.  It will on-the-fly generate that RSA key, and it will receive a primary refresh token  back from the Entra portal with the session key, right?  And from there, it will actually start using that, which is RSA encrypted, and you get  like all these tokens back.  And then from there, it will actually start, you can actually start utilizing this.  So yeah, as I just mentioned, the PRT v3 flow for this is fairly similar to how it works  on Windows, with probably the biggest distinction where macOS for the PRT v3 flow, it will store  it in the keychain together with the session key, as I'll show you in a second, whereas  on Windows, it will be used with the DPM if you have one.  But the response is equally encrypted, and it has a session key to actually allow you  to prove that you have access to it.  And this is just a screenshot of how it looks.  On the keychain, as I mentioned, it's stored in your local keychain.  If you have an iCloud-enabled account, it will be in your iCloud, which has additional  risks, of course, if you can imagine if you get phished on that.  And basically, it is protected, so you can show password, and then you get a password  prompt.  So you still need to have the user password if you are attacking this user.  But usually you can phish for that, right?  And then you get this JSON blob that you see in there.  And if you would look at that, you would see the secret, which is your PRT, and then the  session key, where you can basically start using this, so you can start replaying this.  I forgot to click.  Of course, you can build road tools and road DX, so we can also use this to actually get  our tokens this way.  And of course, this is very sensitive, so it's a very hard thing to do.  This is probably the biggest OST that we're going to release for you today.  Everybody can copy-paste, of course.  So in Windows, it's tied to all kinds of hardware capabilities.  On macOS, it's just like in the key chain, it just says session key.  You copy-paste it out on any device that you want, and then it also works there.  So you can just copy-paste the single sign-on out to wherever you want.  That's the v3 implementation.  So we figured this out, and we thought, like, okay, this is how it works.  This is where it ends.  And then we were just doing it again to see if we could still reproduce it, just to make  sure that Microsoft didn't change the implementation.  And they did change the implementation.  We suddenly saw like pre-RT protocol version 4, and we're like, what is this?  Why is this there?  So it turns out to be the new platform SSO, and I think you're actually going to talk  about the platform SSO here.  Yeah, so this is a fairly recent thing.  It was in preview for a while.  I think they released it maybe three, four months ago, where Intune now has the capability  to use the platform SSO module, which is actually leveraging the Apple native SSO extension  that runs from the operating system.  So this is not Microsoft developed.  They're just piggybacking off actual Mac OS implementation.  And the cool thing here is this is actually really nice.  So they're leveraging this basically through Intune.  You can say, okay, I want to use this or that.  So you could use the old plugin, or you can now also use the platform extension.  And here, it would be actually a similar implementation as Windows has, where they're also utilizing  the Mac version of a TPM chip.  And that has quite a lot of benefits, and in our research, it kind of looked like that  even the Mac implementation looks safer than the Windows one, which is kind of ironic.  So in Apple terms, the secure enclave is what would be a TPM.  The implementation is similar, slightly different.  And because they control the full ecosystem from hardware to software, they have some  benefits there where they don't have to make it that compatible with all kinds of CPU vendors.  So if you were really into this stuff, I don't understand the half of it, but there is a  really good support article on the Apple website that explains in detail how this chip works  and how you can interoperate with it.  And it's just quite a nifty implementation.  So basically, on the Intune site, you can build your own onboarding profiles.  And here, you can actually select that use secure enclave key.  And that is the new feature that they added.  You can enable or disable the shared device key.  Please disable that, because it's not the best thing to enable.  Then it gets uploaded to your iCloud, and it actually lowers the security barrier, and  the rest is just padding that you have to assign it.  And then once you enroll your Mac into Intune, which is just a company portal like you would  on Windows, it's happy.  It shows all kinds of stuff.  And then after that, actually, the important stuff begins.  Because now the platform SSO module from Apple kicks in.  So first, you have to register your device in Intune.  And then it goes into the second phase, where you have to re-authenticate with your local  admin account.  And of course, you can automate this as well if you want to have a better user experience.  And it actually starts probing you as well for a passkey.  And the passkey, again, is tied to the secure enclave.  So it's a device-bound flow that you're following.  And basically, you're allowing the company portal to utilize that to get into the nicer  bits of crypto.  All right.  So the device registration, if you have a secure enclave, it's going to look slightly  different than if you don't.  So it is, again, going to be an API request.  So if you have watched some of my previous talk on device registration, it's going to  look very similar.  We're just going to send a token to Entram.  And in the request, we see the certificate signing request and also the transport key  being uploaded.  But the biggest difference is that this implementation actually uses elliptic curve keys.  So they're no longer RSA keys, but they're now elliptic curve keys.  Same goes for the transport key.  So it's being uploaded as a JSON web key blob.  So we just see the key, the public values of the key.  And of course, the private part of the key remains on the device here, in this case,  in the secure enclave.  And then we get back a certificate.  And in the certificate, we also see that it's done with elliptic curve keys, so with  a very specific curve.  So if we look at PRT3 versus PRT4, then we see that PRT3 uses RSA keys.  However, the PRT4 used the secure enclave-based keys.  And I guess that it was not Microsoft's decision to use elliptic curve, but it was Apple's  decision because they want to use this with their secure enclave.  And secure enclave uses ECC keys basically natively.  So it was probably Apple kind of nudging them or maybe forcing them to actually go this  way with the PRT4.  And it also means that the PRT4 is slightly different.  So the starting point to get a PRT4 is, again, going to be this device-less PRT.  So it still does the device-less PRT first.  Maybe there is a flow to do it differently, to start with a PRT4 PRT.  But we only saw the upgrade happening from PRT3 to PRT4.  We didn't look at how the other authentication flows work with the passkey yet.  So there's probably more to explore here.  And again, you also see the sun in the corner.  So this is, again, one of these important slides.  And what it's going to do, it's going to send this PRT3 kind of primary refresh token.  Actually, it used the primary refresh token to get the regular refresh token that's valid  to request a PRT.  And it's going to sign that with the device key.  So it's using the elliptic curve digital signature algorithm.  And it's also going to use a standard called elliptic curve Diffie-Hellman with inferior  session keys, I believe.  So actually, it's not going to use session keys in this case.  But for every request, it's going to do a Diffie-Hellman key exchange and create a temporary  key.  So when it receives the primary refresh token back, there's no session key involved here.  But the response is actually going to be encrypted with the negotiated session key or temporary  session key using the ECDH key exchange.  And if we want to use it, then we actually have to, again, sign our request with the  private key of the device.  So that's different also from the PRT3 and the PRT2 flow, because these are not signed  by the device.  But in this case, we do sign it with the device private key.  Again, we do this Diffie-Hellman key exchange to negotiate a key with Entra.  And the response will get us our tokens.  And the tokens will, again, be encrypted.  So we need to decrypt this.  And everything that is part of this old decryption, either in this step or in this step, has to  go via the secure enclave.  Because secure enclave is the one that actually holds the private keys.  So the steps are actually very similar, both of the steps.  It's the device signing the request.  And it's the response that is actually encrypted using elliptic curve keys.  So how does this look on the wire?  We see, again, a request.  So it's the PRT version 4.  And the request actually contains a JSON web token.  And this JSON web token is generated by the device.  So in the header, we'll see the certificate from the device.  So it's, again, the certificate that was issued to our device when we did the registration.  And again, the biggest difference here is that the algorithm changes to elliptic curve  instead of RSA signatures.  And then when we request a token, or we receive the token back, then we see this encrypted  blob.  So this looks like a JSON web token.  But again, this is not a JSON web token.  This is JSON web encryption, or JWE.  And in the header, we see all these weird fields.  I'm not a cryptography expert.  But basically, these are the initialization factors for the elliptic curve Diffie-Hellman.  And with all of this data, then you can basically negotiate a key.  So I didn't come up with all of this.  This is from a RFC.  So it's about key agreement with elliptic curve Diffie-Hellman, and ferial static, or  ECDES.  And then they use the CONCAT KDF to basically generate a derived key.  And the derived key is actually used as a encryption key.  And guess who wrote this document?  Michael Jones.  Good memory.  Very good.  Or maybe you knew it already.  So essentially, that is how PRTv4 works.  Yeah, and it was kind of funny, since he wrote most of the tools for PRTv3, and he started  to build like a v4 version, started digging into the RFCs, and was, well, complaining  a bit on how complicated it was.  And then he built his first POC, and he ran it, and it's like, it worked.  It's like completely dumbfounded that it's actually working, but it was cool to observe.  Yeah, so the biggest surprise during this whole research is that we could reproduce  it in like a Friday morning for some reason.  So the RFCs were quite all right, and the documentation from Apple was also quite nice,  giving examples.  And like, if you calculate the derived key, this is what the results should be.  So it allowed us to create a proof of concept pretty quickly.  Yeah, for the people that ever developed for Mac OS, generally, their development documentation  is pretty terrible.  This bit was amazingly documented, really good, or at least compared to the rest, right?  So...  It had just the important part that we needed.  Exactly.  Yeah.  Let's not talk about the quality of the rest.  The rest of it was kind of meh.  Still the PRT is saved in the keychain, as with everything, or mostly everything on Apple,  if it's implemented well.  But there's one big distinction.  So we can still look at it.  If we fill in our password, we can see that the secret at least is there.  There is some more protection on it.  So they try to constrain access to it with entitlements and access controls.  So technically only the Microsoft identity SSO extension should be able to read this  value unless you're like a local user and you overwrite that.  So it's already slightly more protected on the keychain side.  If you look what's in there, that's basically this blob.  So we do see that secret.  But the biggest thing that's now missing is the session key, since this is handled by  the secure enclave.  So as an attacker, I can copy this, but I can't do anything with it because I don't  have the rest of the material to actually finish the authentication that you need to  do with that whole flow from the device code side.  So this is a small screenshot from the Microsoft website.  And as we started with, it always needs a device ID and a session key, which turns out  not to be accurate because we don't have a session key for the device-less version.  Or we do have a session key for the device-less version, but no device ID.  And then for PRT4, it's the other way around where the session key is derived from that  Diffie-Hellman exchange.  So we created this small table, and again, a sun, because if you're looking at these  kinds of things on the wire, or if you're analyzing it, it could be useful to sort of  remember where it's coming from and what is actually the difference.  The validity is the same.  So also on the Microsoft website, it says the validity is 14 days, which is a blatant  lie.  They all work for 90 days, and that's going to be the same and will be the same probably  forever.  Right.  So, we do have one demo that actually we were allowed to show you, and that's Dirk-Jans.  Yes.  So, one of the interesting things is that the device-less PRT, it started with a normal  device code authentication flow, and a normal device authentication flow is just a standard  OAuth flow.  So there's no magic involved in there.  It's just like filling in specific parameters.  You don't need to have a device.  You don't need to have advanced crypto.  So that means that we can actually also phish users to follow that flow using attacker-in-the-middle  phishing, for example, with Evil Jinx, and then actually use that to request a device-less  primary phish token.  So we ask users to sign in once, and normally you would get some cookies from that.  The problem with cookies is that Microsoft is very keen at revoking those, and they're  kind of a bit of like a black box because you don't know when your cookie is going to  be valid, what the constraints are.  However, we can also phish for device-less PRTs, and device-less PRTs, they're way more  robust because Microsoft isn't just going to revoke them.  They're valid for 90 days, and we can renew them, and we can extend their validity, and  we can even upgrade them to full primary phish tokens if we want.  So a little demo.  And here I've set up a local Evil Jinx instance, and I'm just going to do it locally so I don't  actually own this Microsoft Xero online domain, even though it would be a nice name.  So this is our victim.  He's going to visit our webpage, and I changed this phishlet to ask for a specific token.  So we're going to enter our username, enter the password.  We're also prompting the victim for MFA because then we will phish the MFA, and it also means  that we have a token with MFA rights.  And then here what we do is we pick up this code.  So this is the authorization code, and the authorization code is normally exchanged by  like a native app for a token.  And most phishing sites, they will actually automatically exchange it or pick up the cookies  or something like that.  But here we want to have this code because, first of all, this code can only be exchanged  once.  So if it's already exchanged, then we can't use it anymore.  But this allows us to request a device-less PRT.  So from here on, we move it to the Linux machine with rote-tx, and that requests a device-less  PRT.  And with this device-less PRT, we can request arbitrary tokens for anything.  So this would work in like native app scenarios with browser scenarios as well.  I could just pop up a browser and single sign on to anything, and this will keep working  for like 90 days.  If we want to add a device claim, because why not, then we can also register a device  using this same device as PRT, because it's used as an input in the whole device registration  flow.  So the legit systems also use this device as PRT as a start of the flow.  So if you want, we can also register a device, first of all, with this PRT, so that we do  with the PRT off module.  We specify the version 3, because we are using this new protocol.  You can actually also leave that out, because the v2 works with the same PRTs.  It's a different crypto involved, but it doesn't matter which protocol you use, v2 and v3 there.  The things are exchangeable, basically.  We ask a token for the device registration service scope, and then after that, we register  our fake device.  And this device is obviously not going to have a TPM.  We're going to do the new registration flow.  So actually, this is going to register a fake macOS device.  It's going to pretend we have a secure enclave.  So it's going to generate no RSA keys in this case, but elliptic curve keys.  And then once we have this device, then we can upgrade this PRT to a PRTV4 device bound  PRT.  So this will bind it to our new device.  And we see that the session key here is empty, because this is PRTV4.  So then we don't have a session key anymore, but we have a PRT that is bound to our device,  and that we need to use these elliptic curve keys to actually use the PRTs.  So the final step, we use it with the PRTOff module, and we specify the version 4.  So in this case, I'm asking for a token for graph.microsoft.com from my favorite application,  Microsoft Teams.  And then it will give us a token.  And we'll see with this token, it's like on behalf of Teams.  So with this, we will be able to extract any data from Teams.  This is how it works with the native flow.  There's also, of course, PRTV4 single sign-on tokens for the web-based flow.  Those also work slightly differently than like the normal PRT authentication on a website.  So I didn't have time to implement that yet, but it's possible, because we have like a  full primary token bound to a specific device.  Now, there's also some things that we can use on Windows with this.  So there is some protocol magic that allows us to do some things we're not supposed to.  But again, we were going to do this talk, and Microsoft asked us to like, hey, can you  give us a heads up what you're actually going to discuss?  We didn't think it was a big thing.  They wanted to fix it nonetheless, so we agreed not to talk about it until it's fixed.  And I don't know when they're going to fix it exactly.  I know they're working on it, but basically, we're not going to be able to show you all  the other stuff.  But this works.  This is just following the protocols.  You can fish people, and instead of fishing for cookies, which is boring, everyone already  does that.  You can fish for primary fish tokens, way more fun.  A little bit about defenses, to wrap it up.  Yeah, of course, like any responsible person dropping bad stuff, we also want to help you  defend against it.  Sad news is you can't fully.  Like also Rick's talk is probably going to suck for a while, and then we're going to  be better.  But Microsoft offers some options.  Some require licenses, some not so much.  You can restrict it quite a bit with conditional access policies, depending on what you require  on it.  Quite complicated to do really, really well, and there will at some point maybe be a loophole.  So you can supplement that with require only compliant devices, which is something you  can check against.  Bit stronger, still something that we probably will be able to fake as an attacker.  Another thing you could do if you have that luxury is restrict your device registration  to the maximum of one or two.  The way it works, if you use Intune, you enroll your own device, right?  So you need to be able to at least register one device.  But a lot of companies also allow you to log on with your phone.  Maybe you have an iPad, right?  So then you already are free.  So there are some gaps there as well.  You can also, what you can also do is limit the token lifetime on non-corporate, bring  your own non-managed devices.  So at least the scope and the impact might be slightly less.  So if we get a PRT then, and we can use it, then at least we can use it for a shorter  amount of time.  So still not perfect.  And of course, you can still build detections where a user is registering a new device from  an already registered device, which is not really what you would expect in a normal  onboarding flow.  So all of them, not great.  Microsoft is actually working on patching the vulnerable flows that we weren't allowed  to talk about.  And also they're exploring mechanisms to disallow the reuse or certain of those tokens for revised  registration, which will probably be the biggest blocking point, because then you can't do  all the stuff that we showed you earlier.  Of course, there's a lot of other things to explore.  So Mr. Jones wrote quite some other RSCs that we probably can still dig into and sometimes  be frustrated about.  And I already see somebody very waiting for us.  So that will be the end.  And we would like to thank you for your attention.  Questions is probably, is that still possible?


url: https://www.youtube.com/watch?v=bAHqEefF7Ok
title: Confusion Attacks: Exploiting Hidden Semantic Ambiguity In Apache HTTP Server! - Orange Tsai
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=bAHqEefF7Ok",
    "title": "Confusion Attacks: Exploiting Hidden Semantic Ambiguity In Apache HTTP Server! - Orange Tsai",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 2617,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Hi, this is Orange, it's my pleasure to become a speaker at OrangeCon, and you know how this  means a lot to me, yes.  So today I will present the Confucius attack, and let's get started with today's presentation.  First I want to ask, is there anyone here who hasn't heard of the Pudge HTTP server  before?  If so, please raise your hand.  Okay, well, I believe I can skip the introduction.  And I want to ask an additional question.  How many people here are under 30 years old?  Wow, there are so many young generations.  Okay, a Pudge is an open source project that is nearly 30 years old.  So I guess it might be older than some of you here.  And because it has existed since the early days of the internet, it has accumulated a  lot of technical depth.  And another key point is that a Pudge enables CGI by default, which greatly increases the  potential attack surface.  And lastly, a Pudge is the only web server that can perfectly integrate with PHP.  Since a Pudge and PHP were born almost in the same year, a Pudge was the first choice  to use PHP in the early days.  A Pudge also met several customizations for PHP, which led to several ways to configure  PHP.  For example, just for the fast CGI protocol, there are over six different modules to choose  from.  Especially, each module has different directives.  All of these make it complex to set up a PHP environment.  And furthermore, some directives not only look very similar, but also have identical  usage and effects, which can cause confusion easily.  If a website admin didn't understand the intention behind each directive, it's easy to make mistakes  and create security risks.  For example, when the website admin wants to set up PHP on his server, he might come  across two common directives, addHandler and addType.  And which one do you think is correct?  Actually, both are correct.  This method can properly get the PHP running.  So does this mean both configurations are all good?  Firstly, being correct does not mean being secure.  And under certain conditions, addType has been proven to be vulnerable.  And allowing attackers to disclose the PHP source code remotely.  And we will discuss the reason later.  And the last thing I want to mention about Apache, and I believe it's also the most important  one, is from my years working in offensive security, I have observed that websites who  use Apache tend to have more massive environments.  Also I can't think of any reason to use Apache other than for CGI.  In practice, many servers are still running Apache and hosting a lot of third-party web  services like Tomcat or Nginx locally.  Also, they tend to use rewrite lua to organize the request.  And usually the file system on the server is also a mess, with a lot of strange files  sitting under the web root.  So today our talk's mission is to break this type of the Apache HTTP server.  You will learn how to identify such vulnerable servers and break them just like a piece  of cake today.  Okay, before we dive into the topic, let me introduce myself first.  And you have already known I'm Orange, and currently I'm the principal security researcher  at DevCore.  I have spoken at several top-hacking conferences, and my research has got a number of honors,  such as the Top 10 Web Hacking Techniques, Pong to Pong Champion, and Ponging Award.  So why we focus on Apache?  At the beginning of this year, I started to explore some open-source projects with widespread  internet impacts, such as the Apache and the Nginx.  I have even delved into some RFCs to deepen my understanding.  And upon a close review of the Apache source code, I smelled something bad in its coding style.  Primarily, Apache relied on hundreds of small modules working together to handle a client's  HTTP request.  The source code includes 136 modules, and about half of them are either enabled by default  or commonly used by website admins.  And what's even more surprising is that these modules also share and maintain a very large  structure while working together.  The slide shows what the structure looks like, including all the elements involved in handling  an HTTP request.  In Apache, all modules rely on this massive structure for synchronization, communication,  and even data exchange.  And step into the internal, an HTTP request will pass through several phases, and the  modules act like players in a game of catch, passing the structure from one to another.  And when a module's turn, it focuses on completing its own task.  And once done, it passes the structure to the next.  This type of collaboration is not new from a software engineering perspective.  Each module simply focuses on its own task.  And as long as everyone finishes their work, then the client can enjoy the service provided  by Apache.  And this approach might work well with a few modules.  However, since any module can modify any value in this structure, when there are over 100  modules today, without any good standard or guidelines, can they still work together?  Thus, our research was born.  So our research focused on the relationships and interactions between these modules.  Each module might be implemented by different people, and subjected to years of iterations  and code refactors.  Do they really still know what they are doing?  Even if they understand what they are doing, what about the implementation detail of others?  They need to collaborate together.  And however, if a module accidentally modifies a structure felt it considered unimportant,  but it's crucial for another module, it could affect the later decisions.  And furthermore, if there's any misunderstanding between any field within this large structure,  it can create security risks as well.  So from this starting point, we have developed three different types of attacks.  As all of them are more or less related to the misuse of the structure, we have named  this attack service ConfusionAttack.  And the following are the attacks we have developed.  As this is a completely new attack service, the first person to dive into, of course,  can find the most bugs easily.  So this ConfusionAttack made me the person who is currently holding the most vulnerability  from the Apache HTTP server.  Additionally, because these vulnerabilities are based on legacy architectural issues,  so most of the patches are not backward compatible.  So updating Apache to the latest version might break old configurations.  Therefore, for many production servers, simply applying the update to the latest version  is not a good idea.  Okay, let's dive into our main topic.  First, I would like to discuss the attack called FileNameConfusion.  This attack occurs when different modules handle the file name using different standards.  Literally, the field FileName should represent a file system path.  But however, in Apache, some modules treat it as a URL.  If we think of HTTP context, some modules consider the field as a file system,  but some others are not.  The inconsistency between these modules will create vulnerabilities.  The first module consider the file name as a URL is RewriteModule.  This module allows website admin to redirect a request to any file or URL.  I believe this is by design to enhance user experience.  However, this convenience feature also introduced certain issues.  For example, the RewriteModule will treat the substitution result as a URL in all cases.  For example, if the website admin sets the following rule to target the username  right after the path slash user to open the corresponding profile in the file system.  So when you access the slash user slash orange,  the module will open and output the file content of slash var user orange profile.  However, what if you add one more question mark today?  %3f is the URL encoded format for the question mark.  During the name translation phase, the RewriteModule will first process the rule  and generate the corresponding destination target, just like this path.  After the generation, even if the destination is the file system path,  the RewriteModule will treat all the result as a URL and separate the query part by the question mark.  So there's a path truncation here, and this is our first primitive.  You can use a question mark to truncate the path and to access unintended files.  For here, we use this truncation to access the secret, which is normally inaccessible.  Although it might seem a minor issue for now,  please remember it because it will be used heavily in our later attacks.  Okay, next, who else considers the file name as a URL?  The proxy module, too.  At first glance, this seems makes sense because the purpose of the proxy is to redirect the request  to other URLs. So when we consider this behavior on its own, it doesn't appear to be a problem.  However, if your server relies on the file-based access control, it can be risky.  For example, this is a common password-protected configuration using the file directive  to prevent unauthorized users from accessing admin.php.  This type of authentication can be bypassed by default when the target is running under the phpfpn.  Imagine when you visit a URL like this today, admin.php, %3f, and ooo.php.  First, during the HTTP lifecycle of the access control phase, the authentication module will  compare your requested file name with the protected file admin.php. At this point, your file name is  admin.php?oo.php, which is totally different. So at this time, Apache didn't think you need authentication.  However, to support various protocols like HTTP or FTP, the proxy module will rewrite the file name  into the following URL and sends it to the backend php service.  Since the backend receives the file name in a strange format, the php also  implements some workarounds to adapt this behavior. php normalizes this unusual file name first  and spreads it by the question mark to get the original original file name for execution.  So the original authentication required admin can be bypassed with just a single question mark.  Of course, it's not just admin.php. There are more risky configurations that can be found  on GitHub, such as the only local accessible php info and admin, which is blocked by default.  Through the inconsistency between the authentication module and proxy module,  all of this can be bypassed by just a single question mark. Okay, this is our first confusion attack.  The next attack we are diving into is the confusion based on the document loot.  Let's consider this common Apache rewrite rule for a moment. When you visit the URL  slash html slash about, what file do you think Apache will actually open?  It's either about dot html under the loot folder or the file from the document loot  at slash var slash triple w and slash html. Which one do you think the Apache will open?  If you think Apache will open the slash about dot html, please raise your hand.  And if you think Apache will open the bottom one, please raise your hand.  Oh, more people think it's just the bottom one. Okay, actually,  Apache answers both. Magic, right? Yeah, this is also our second confusion.  For any given rewrite rule, Apache always tries to open both the past version with and without  the document loot. This allows us to intentionally access the files outside the web loot, especially  the loot directory. You might be wondering, hey, does this mean we can access the slash etc slash  passwd? The answer is yes, but not entirely.  Technically, the server indeed accesses the password file, but the Apache HTTP server's  built-in access control blocks our access. You can see the default configuration is denied all.  However, the built-in access control by default allows the access to the folder slash user slash  share. And thanks for this configuration, we now have a limited arbitrary file access on Apache HTTP server.  For example, we can access the documentations on the slash user slash share to learn how to use SSH.  However, from the real-world case, such as the rule in the slide, the extension like .html  is still the restrictions that keep us from being truly free.  So you might ask, can we access the file outside the .html extension?  I'm not sure if you remember the primitive of the press truncation from the file name confusion earlier.  We can combine them together using a question mark to truncate the extension.  So theoretically, as long as the target prefix of a rewrite rule is controllable,  we can access nearly the entire slash user slash share.  This is a blast. Even the tutorial from the official Apache website has problematic examples.  And okay, we now know the loot codes. And what can we do with these attacks?  First, we can disclose arbitrary server-side source code.  Since Apache decides whether to ask you the script or not based on the current virtual host or directory,  so access the full path through a virtual host that doesn't support PHP allows us to easily  expose its source code.  And since we have broken the trust of the only accessing the document loop,  the entire slash user slash share has now become our platform.  So the next step is to find out what files under this folder we can exploit.  We can leverage existing tutorial examples, unit tests, or even packages from programming language  to become our gadgets.  So the first gadget we are going to demonstrate is leveraging the library office,  which is installed on Ubuntu desktop by default.  We can leverage the language switch feature in the help files to achieve accesses.  Or we can disclose sensitive information. For example, if you install the WebSocket D,  the daemon will, by default, include an example PHP script called dumpenv.php.  You can directly access the file to leak sensitive environment variables.  And additionally, if the target has the service like nginx or jt installed,  the default web loops are also located under the slash user slash share.  So you can download sensitive application data, such as the web.xml.  Here we demonstrate how to ask you the PHP info to leak sensitive information by DeviCale package.  Even some PHP or font end packages, their tutorials or debug content,  even some PHP or font end packages, their tutorials or debug console can be leveraged as well,  such as the jQuery, magpie, or the jpgraph.  For example, we use the tutorial from the jQuery feed to read arbitrary file content.  Okay, by now, you can see the possibilities of this primitive.  You can see the possibilities of this primitive are huge.  Local gadgets are endless, and all that remains is to find more powerful gadgets  or more universal gadgets. But you might be curious and asking about  can we jump out of the slash user slash share?  Of course we can. And that brings out our third primitive.  To draw back from the slash user slash share, a patch by default follows the symbolic links.  So we can leverage this feature to draw back from user share.  So any package that has a symbolic link in its installation folder can become a stepping stone  to access more gadgets for further exploitations.  Here are some useful symbolic links we have discovered so far.  You can read the CACTI logs under slash var slash log,  read the SORA configuration under slash etc, and even access the Redmine files.  And here we will demonstrate a remote code execution trend on Redmine  through a double hop jump. There's an instance folder that can jump to slash var slash lib  under Redmine. And within that folder, the config directory can also jump to the slash etc  slash Redmine, which contains a lot of Redmine's database configuration and its secret key.  So by using an insecure rewrite rule,  we can access the secret key used by Redmine through a double hop jump.  And since Redmine is a Ruby on Rails application, the content of the secret key is actually the key  for signing and encrypting. So the next step should be obvious.  Embedding a malicious object into the cookies, signing and encrypting with the non-key,  and then get code execution through the server-side deserialization.  Okay, that's our second confusion attack.  The last attack I'm going to introduce is the confusion based on the handler.  This is also an attack that leverages a piece of technical depth in Apache server's legacy architecture.  Back to our initial question.  Why can both directives, one for aiding a handler and one for aiding a type, can run PHP properly?  This is actually due to a legacy conversion in Apache, or you could say it's part of its  technical depth. Before Apache enters the main handler for processing the HTTP,  if the handler field is empty, Apache will take the value in the field of content type as its handler.  So our third handler confusion is preying around this behavior.  In Apache, sometimes the content type can be transformed into the handler.  Yes, it can be transformed into the handler.  So what can we do? Let's show you something fun first.  Imagine that your server is running PHP using the add-type directive and you access the file  config.php. Since the file extension is .php, during the type checker, during the first type  During the type checker, during the first type checker, the patch will assign the corresponding  value to the content type field based on your configuration. And PHP will know,  oh, it is his responsibility to handle this request.  The normal process works well. However, before entering the main handler fast,  the legacy conversion, we mentioned earlier, will convert the content type into the handler.  So this explains why both add-type and add-handler are effective.  But what if any module accidentally overrides the content type before reaching the run handler phase?  For example, you can trigger a filter error in the most security module.  If the most security finds an error, the module will think, oh, it has made some mistakes  and want to send out some error message. And since the error message is in HTML,  it sets the current content type to HTML2.  So the config, which was supposed to be askew as PHP, is treated as a plain HTML now,  exposing all the sensitive content to outside.  So this is also our first primitive for handler confusion.  By abusing the old handler confusion mechanism, we can disclose any PHP source code  by overriding the content type.  Theoretically, all directives based on content type are affected by this issue.  But if we think deeper, the nature of this issue is actually  that there are no clear guidelines for the use of the field content type.  It can be set by a config directive during the request or use the content type header  in the server response. A patch cannot distinguish which one it is  while using the field. So ideally, if we can control the content type,  we can invoke arbitrary handler. So can we really do that?  It's very promising. However, there's still one last piece of the puzzle.  The situation is not as simple as it seems. And in practice, all the code paths  that can modify the content type are old after the legacy transformation.  So even we can modify the content type through the server response, it turns out to be useless.  So what can we do next?  Don't worry. We turn to the RFC to servers. The RFC 3875 is the specification for CGI.  And the section 6.2.2 introduced the local redirect response.  The local redirect response works like this. If the CGI returns the status of 200  and includes a location header, instead of handling it as a client-side redirect by the browser,  the CGI treats this location target as a server-side redirect.  And a patch implementation of this server-side redirect will open a new HTTP life cycle  and copy the original field of the content type to this new structure.  So, for example, if you can control the response header through CGI,  that means you can control the content type field.  And when the patch sees the status is 200, it performs the server-side redirect  and starts a new round of HTTP processing.  And in this new round, the content type header returned by the earlier CGI is pressed into the  structure. And after the legacy content type handler conversion, the content type we provided  becomes the handler and allows us to invoke arbitrary handler.  So, this is our second primitive. It's the ability to code arbitrary handler.  And basically, the entire CGI family follows this feature. So, including but not limited  to the WSGI, FastCGI, or UWSGI. As for how to trigger this server-side redirect,  here we provide two scenarios. One is the CRF injection, and the other is the SSRF  that can fully control the response header. And we will use the CRF injection as the example  below. In the normal case, this type of vulnerability will be treated as an  XSS because you can inject HTML into the content. However,  if you override the content type with a name called the server status,  then you can lack sensitive information that should only be accessible from the local host.  You can also easily transform an image into your PHP backdoor by setting the content type  to PHP. You can even achieve SSRF through the proxy module.  And this SSRF allows you to control request headers and can read all the response.  And super thanks to the convenience brought by the proxy module,  the most awesome thing about this SSRF is that it can also access the local Unix domain sockets.  So, lastly, let's demonstrate how to turn this SSRF into a RCE.  Here, we used a common trick in CTF. The official PHP docker image, by default,  comes with peer, a PHP extension manager. And the peer CMD is the entry point used to manage  manage the package. So, we can leverage this SSRF to ask you the peer CMD to do further  exploitations. For example, we exploit a command injection in the run test command.  And we can get a reverse shell easily to ask you arbitrary commands.  So, please do not report a header-based CRF injection as an XSS again. It's really a waste.  Because today, you have learned a new way to exploit. This type of bug has the potential  to become RCE. Here, my presentation is almost coming to the end. And before closing,  I want to say maintaining open source is really challenging. Especially keeping a project for  30 years. You have to make it convenient for end users and compatible with all versions.  The entire development process is built upon a pile of legacy code and technical depth.  So, if there are any Apache developers in the audience today, I want to say thank you for all  of your hard work. And before we finish, let's have a few takeaways. So, first, the question mark  is a powerful tool that allows you to truncate arbitrary paths. You can bypass SS control  and authentication easily by playing the inconsistency between the modules.  And next, the rewrite rule contains the hidden trap that allows access to the system loop.  And lastly, by controlling the response header, you can invoke arbitrary internal handler  through the legacy conversion mechanism. Also, there are some future works. For example,  for example, different distributions have different configurations. So,  exploring such as the FreeBSD or even on-premise applications could reveal more load-by-default  SCL and reveal more local gadgets and symbolic links. And finally, due to the time constraint,  I'm not able to introduce some real-world cases. But you can imagine there must be countless  rewrite rules to figure out. There are a lot of SCLs to be bypassed and a lot of hidden CGI's  out there. Applying all the techniques we discussed today to bug bounty hunting is now your mission.  Okay, this is the end of my presentation. If you have any questions,  here's my contact information. And thank you for being here again. Thanks.


url: https://www.youtube.com/watch?v=8FAqOkgte8o
type: video
author: OrangeCon
ingestion_date: 2024-09-13
transcription_model: large-v2
vector_embedding: pending
chunking_status: completed
title:
  Securing Devices Or Profit? Examining The Device Security Of A Network Appliance Vendor - Hal Martin

content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=8FAqOkgte8o",
    "title": "Securing Devices Or Profit? Examining The Device Security Of A Network Appliance Vendor - Hal Martin",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1671,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you  you


url: https://www.youtube.com/watch?v=481SI_HWlLs
title: From COM Object Fundamentals To UAC Bypasses - Tijme Gommers
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=481SI_HWlLs",
    "title": "From COM Object Fundamentals To UAC Bypasses - Tijme Gommers",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1521,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Welcome, everyone, to this talk titled Elevate Your Knowledge from COM Object Fundamentals  to UAC Bypasses. Whoa. A UAC popup. Let me quickly click that away. Because I would first  like to introduce myself. My name is Thijm Gommers. I perform offensive cybersecurity  operations, research and innovation at the ABN Amro Bank. Actually recently joined the  bank previously. I had actually the same role at Northwave Cybersecurity, which is a cybersecurity  firm in the Netherlands. And as a side quest in life, I perform digital forensics at Hunted,  which is a Dutch television show. So you might sometimes see me on NPO3 somewhere in a corner  hacking into a mobile phone. And I'm the author of some exploits and some malware,  which I published on my GitHub profile. My username is my first name. So you can find it  there. It's actually the case for all my social media profiles. So if you have any questions  afterwards after this presentation, feel free to send me a message. Because I'll probably talk for  30 minutes straight. So today I'm going to teach you three things. First, tokens and privileges in  the Windows operating system. And especially when you log into your system. Afterwards,  secondly, user account control and how that interconnects with those tokens and privileges  when you log in. And thirdly, which seems not related, the component object model in Windows,  which will be a high overcross course, because it's pretty, it can get pretty complicated.  And hopefully at the end, we'll be able to combine the three into a demo, which shows how  we can actually bypass UAC. And hopefully by then you also know how that technically works on the  water. So let's get into those tokens and privileges. Let's say you boot your Windows  computer or you connect to it remotely. You press control alt delete. What happens then is that  a process called WinLogon, which runs a system, will actually spawn a new process called Logon UI.  And this is the UI that you see when you log in. That we see right there as well.  And you enter your credentials. And you press enter to try to authenticate. What then happens  is that Logon UI will actually forward those credentials to WinLogon again, the WinLogon  process. And on its turn, that process will forward the credentials to LSAS, which is the  local security authority subsystem service. Which is a fancy name for basically the process  that manages authentication and authorization within Windows. Now when your credentials are  correct, LSAS will actually create a token for you, which is your own personal token that is  linked to your account. And this token will be returned back to WinLogon. And what WinLogon  will do with it, it will spawn a new process called UserInit using your token. So UserInit  is the first process that spawns in your Windows computer using your privileges. And UserInit does  a bunch of things. But the most important one is starting explorer.exe, which we all know.  And then your actual Windows desktop environment is visible to you.  Now, what does such a token actually look like? It's a struct of data, and I'm not going to go  into depth of all the attributes that it has, because there are a lot of them. But I'm going  to cover some important ones. One which you all know is the SID, Security Identifier, which is a  unique ID for your user in the Windows operating system, and maybe even in the domain you are in.  It also contains group security IDs, so the SIDs of the groups that you are a part of,  you are a member of. For example, the built-in users group or the built-in administrators group.  And at the bottom, you can also see it contains something with medium, mandatory label,  medium mandatory level, sometimes called integrity level or integrity label or mandatory level.  It's all the name for the same thing. And in this case, it's medium, and I'll cover it later on in  the presentation. Now, it contains a lot of more stuff, but I think for this presentation,  there's one more important thing in that token, and that's the list of privileges that are assigned  to you. For example, the SE shutdown privileges for you to be able to shut down your computer.  For example, the SE shutdown privileges for you to be able to shut down your computer.  All those privileges that you have in the list that are assigned to you have certain attributes.  So, for example, a privilege can be enabled for you to use right now, or it can be disabled,  but present, which means you can enable it without any further privileges required,  and you can use it. Or it could be, for example, that it's not present at all,  and then you cannot use those privileges at all in your token.  And there are many more privileges. Another example is the SE load driver  privilege, for example, to load a kernel driver in memory.  So, if you log in to your Windows computer and you launch the CMD shell as a standard user,  so not as a local admin, and you run a UMI, you'll see which kind of privileges are assigned to you.  And we can see that right here. We've got five privileges assigned,  some of them are disabled, and some of them are enabled.  And we can see that we are running in medium integrity.  Now, you would say that if you log in as local administrator instead of as a standard user,  you would get more privileges. But that is actually not the case.  You would get the same amount of privileges and the same integrity label,  and that is because of something called UAC, user account control,  which was introduced in Windows Vista. So, if you try to do this on Windows XP  and log in as a local administrator, you would see that you would actually get all the privileges  that you would want. And you would say that you would be running in high integrity,  but that was not a thing in Windows XP because UAC wasn't introduced yet.  So, let's briefly take a look at what user account control actually is and how it affects  your tokens from Windows Vista onwards. So, the login as a local administrator on  Windows Vista onwards is somewhat the same as a standard user login. It became similar.  The only exception or difference is that instead of returning one token,  LSS will return two tokens on login. One token is a filtered token with only five privileges  that we saw earlier, running in medium integrity. And the other one is an elevated token with all  the privileges that you need for a local admin, running in high integrity. And WinLogon will  spawn user init and explorer.exe using the filtered token. But of course, as an administrator,  you can perform actions with your elevated token in high integrity mode. And this is how that looks  like. You log into your PC, you see Explorer running. It runs in medium integrity with the  filtered token. You right-click your CMD, run as admin. You can send the UAC pop-up,  and there you go. You're running in high integrity with all the privileges you need.  Now, what exactly is that integrity mode? This was a little bit more complicated than  that. What exactly is that integrity mode? This was also introduced with UAC,  and it's pretty important, actually. Almost all objects in Windows have an integrity mode.  And with an object, you can think about a process or a file or maybe a directory.  So, for example, the CRoot directory has an integrity mode of high.  There are a lot of available integrity levels, but the most common ones we're going to cover  right now are medium and high. And the rule of thumb is, to modify or interact with such an  object, you need to have the same integrity level or higher. And this is also why, with your standard  local admin login, you cannot just drop a file in the CRoot, because you would need to confirm  the UAC pop-up there, because it runs in high integrity, that folder. And I'm going to give  another example, which was pretty wild to me, when I found out. So, let's say we run a shell  in medium integrity. We are logged in as a local admin. And we create a file called file.txt,  and we list the ACLs on the file, the access control list. We can see that we are the owner,  and we have full control over the file, so we can do anything we want with it.  Let's now say we spawn a new CMD shell in high integrity mode,  and we adjust the integrity mode of file.txt. So, we set it using ICALCLS. I spelled that correctly,  but it doesn't matter. And we use set integrity level high. That works, and we can now revert  back to the medium integrity shell, and we can list the ACLs again. We can see that we  still have full control over the file, but there's now a high integrity label involved.  When we now try to write to that file, we actually get an access denied, although we  have that full control. So, now you may understand that from an attacker point of view,  you would actually want to bypass UAC, because you probably want to write, for example,  to the C drive or C Windows folder, or maybe you want to load a kernel driver,  you need the privileges in the elevated token, or maybe you want to impersonate another user  which you need those privileges for. So, how do we bypass UAC? Why don't we just use the  CMSTP Lua and CM Lua COM object and COM interface? Why not? So, let's, to explain how that works,  let's first take a look at the component object model briefly, and see how that works  and looks like. COM is actually a client server model, which allows you to perform  interprocess communications. So, it's much like an HTTP API. You've got your client,  which talks to a server, the API, and you offload work to the server.  One COM that works the same, but it's mostly on the same machine. So, you've got your client,  which could be your program or your exploit or your client.exe, which invokes a COM object,  the server, which could be a DLL hosted on the machine.  That is on the same machine. It can also happen in a network on different machines. This is called  DACOM, distributed COM. When you communicate with the server, it goes over the network.  What we see at the bottom here is somewhat of the flow of how that looks like when you  want to communicate with a COM object. And a COM object is basically just a class that you can  program yourself with attributes and functions, and you can initiate that class. And you can do  the same with a COM object. So, in your client, you would ask Windows to initiate a certain COM  object for you, and you do that via a GUID that is assigned to that COM object, which is a unique  ID for the COM object. And if you are authorized to do so, Windows will initiate that COM object  for you, and you will get a reference back. And using that reference, you can call functions in  the COM object. And all that interaction afterwards happens via RPC. This is also  why DACOM works over the network, also via RPC. And one of the advantages of COM objects is that  the objects themselves are hot swappable, and I'll give an example of that as well.  Let's first take a look at a library or code that is non-hot swappable. Let's say we want to provide  users on systems with a file system library that has a function to move a file. And we see that  library on the top right here. Some pseudocode. It copies the file, and then it deletes the source.  It's ugly, but it works. And we can compile it to this file system library dot object,  and we can then ship that code to customers or clients or whatever. And they can write a program  that uses that function, and they then compile it and statically link it with our  file system library, and that would work. But now let's say that, unfortunately, we forgot  the delete file line. Then we would have to recompile our library, which would work,  but then we'd also have to reship it. And the clients all need to be recompiled with  the new implementation and be statically linked to it, which is really inefficient.  So you cannot swap the file system library without recompiling or changing anything  in the client. And this is something that COM fixes. So here's the same example, but in COM.  We've got the same function, but in this case, we would register it as a COM object in Windows,  which you can do using the Windows API. You just need to pass a GUID of your COM object,  which you would like to use. And then every client that has that COM object on his computer  can initiate the COM object via Windows COM using that GUID. And there's no further reference  to during compilation time to that COM object at all. So it all happens on runtime.  The object is initiated, and you can then use the move file operation on the object.  And now let's say you forgot the delete file line here. It doesn't matter. You just recompile the  COM object and re-register it. And for the movefile.exe, the client, you don't have to  do anything else. It just works, because it all happens during the runtime.  Now, COM is a binary interface standard, which also means that different types of programming  languages can communicate with each other this way. So your COM component can, for example,  be written in Golang, while the client may be written in Java. And usually, you cannot include  a Golang library in your Java application unless you do some porting. With COM, that's possible,  because the communication is a binary interface standard, and it happens on runtime.  So this was some pseudocode, by the way. If you want to actually copy a file, for example,  you would have to program yourself all this code. So it gets kind of messy, and it's a lot of  overhead, which is why I don't like programming in COM myself. But it works, and it has some  positive sides to it. So if you want to know in Windows which COM objects you can actually use,  which are available to you, you can look in the registry.  You can look in HKEYCLASSESROOT slash CLASSID, or CLSID, which will list all the COM objects  available to you. You can see all the GUIDs right here, and on the right, you see the DOLs that are  linked to it, where the COM objects are actually located. And we've also got a subkey called  interface, and these contain all the interfaces which you can use to talk to the COM objects.  So they contain the function definitions, for example, to actually move the file.  Now, there's some fun stuff in COM. It works pretty closely together with UAC,  pretty nicely together with UAC. There's a registry key in Windows, which you can see  right here, which you can look up on your Windows machine, called COM auto-approval list.  And this allows you to auto-elevate certain COM objects or certain functionality in COM objects  to use your elevated token instead of the filtered token. There's only one constraint,  and that is that the calling function, your client, must be a valid binary from Microsoft.  And as a hacker, you don't have one, of course.  So the thing is, the check that they perform to see if a binary is from Microsoft is weak.  What they do is the COM object actually uses the process status API, PSAPI, to verify the  calling process. And PSAPI uses the process environment block of a certain process to  check the image path name of the process. Now, in processes in Windows, the process  environment block is a piece of memory that you can modify yourself in your own process.  And you can say in your own process that you want to get the process environment block  in the struct. You want to have the process parameters. You want to reference the image  path name. And you can just change it to explorer.exe. And this is exactly the check  that the COM objects do, see if explorer.exe is invoking the COM object, for example.  And this would allow you to actually copy a file in an elevated way with your elevated token.  So you can copy a file to the C root drive without consenting to the UAC pop-up.  Now, that is nice, of course. We can copy a file to the C root drive. But is that really,  really bad or not? And maybe there are other COM objects that we can abuse in a more fancy way.  And I think Logbit used this COM object a few years ago. It's called the CMSTP  Lua COM object that they found in the COM auto approval list.  CMSTP Lua stands for Connection Manager Surface Transport Profile. And this is actually a DLL that  manages your VPN connections, for example, in your Windows operating system. The Lua that's behind it  stands for Limited User Account Control, which is now known as... stands for Limited User Account,  which is now known as User Account Control. So it confirms that we can also elevate this  COM object. The thing is that copy file would be a documented COM object or a documented function  in a COM object. But CMSTP Lua and CM Lua are not documented in Windows. So you cannot find out,  or you can find out, but you cannot find out via documentation what functions you can call  in an elevated way. So how would that work? Well, luckily, Microsoft ships  debug symbols for every DLL in the Windows operating system. So you can just put your  DLL in a disassembler of choice, in this case, Binary Ninja. And you can search for the interface  name, in this case, CM Lua. And what you'll see on the left is all the functions of the interface  that we can call on the COM object. And one of the interesting ones is shell exec.  And we see the implementation on the right. What we see is that it accepts some arguments,  and those arguments are passed to a Windows API function called shell execute extensive w,  which is basically a function that allows you to execute a CMD command,  for example, or start a process with arguments. And so can we. So I developed a client.exe for  this COM object, which firstly defines the interface of the COM object. We need to do  that manually because it's not defined anywhere else. It contains the shell execute function,  which we want to execute. And afterwards, I can use it to initiate the COM object.  And we've got a function of that right here. So this is the GUID of the interface. This is  the GUID of the COM object. And we instruct Windows COM to initiate the object for us  in an auto-elevated way, which we see right here. Now, this would only work if we are explorer.exe.  So before we run this, we actually need to spoof our process environment block  to include that we are explorer.exe. And then we can invoke the initiated COM object.  And then we can run the shell exec function on it with something like cmd.exe slash k slash  wemi slash priv to see what kind of privileges that we have. I compiled this. I'll also publish  it after this talk. I'll show QR code, which you can use to download the source code. And it also  includes all kinds of smaller programs to communicate with COM objects so you can try it  out yourself. I compiled it for you so you can just run it straight away. And I'll demo that right now.  So let's start our Windows VM. Let's run a wemi slash priv to list the current privileges.  We are logged in as an administrator, but we are running with a filter token. You can see that  because we only have five privileges and our integrity level is currently medium.  Now we run the compiled UAC bypass with cmd.exe and we can see that a new cmdl shell executes.  And in this cmd shell, we can run wemi slash priv again. And hopefully we'll see all the  privileges, but some of them are disabled, which is not a bad thing because we can enable them.  And if we look at the integrity level we are in right now,  we can see that we are running in high integrity mode.  And I also created a program for you, which I also published to enable all the privileges  in this current process. We are running that right now. Hopefully that's successful.  And we list our privileges again. And then we'll see that all privileges are now enabled.  And we've successfully bypassed UAC without any pop-ups shown to the user. So thank you very much.  If you want to have the source code, scan the QR code, the presentation is also included.  And also if you want to ask me any questions, feel free to ask them on social media or maybe there  is some time for questions.  Well, thank you very much. Are there any questions in the audience?  Hi, thanks for the talk. Did you report this to Microsoft and did you get any response?  Did you get any response? I did not report it to Microsoft,  so I didn't get any response. It is actually a technique that was used by LockBit,  I think about a year ago or two years ago. And I'm not sure if they will fix it.  I wonder if they actually see it as a boundary of privilege escalation in that way.  So no, I did not report it. So it's free for you to use right now.  Thank you very much. Any other questions?  So thank you very much for the presentation. I'm wondering if you're aware about any  antivirus software that can detect this behavior of accessing these common objects,  because it looks like this type of privilege escalation or UARC bypass can be detected by  the sandbox of antivirus by simply monitoring all the methods that are being called on the  common object model. So you want to know if there's a way to detect it?  Yeah, I'm wondering if you're aware about any software that can detect it right now.  I think I'm not sure if Windows Defender for Endpoint will detect it, but I think  a lot of security operations centers have rules for these kinds of UARC bypasses.  For example, the Windows APIs that are being called can be hooked, so one knows that a common  object is being initiated, and I think most of the common objects that are vulnerable to this UARC  bypass are also known. So there are some GitHub repositories which list them all,  so you can definitely write a detection rule to detect all of these UARC bypasses.  I'm not sure which products do that by default.  Well, thank you very much. I'm afraid that's all about the time we have for this session.  I would like to thank you very much for your elevating talk, and we have a challenge going  for you. Thank you very much. My pleasure. Round of applause, please.


url: https://www.youtube.com/watch?v=39N9qJk55Ac
title: Exploiting The Core: A Deep Dive Into Kernel Driver Vulnerability Hunting - Jan-Jaap Korpershoek
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=39N9qJk55Ac",
    "title": "Exploiting The Core: A Deep Dive Into Kernel Driver Vulnerability Hunting - Jan-Jaap Korpershoek",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1958,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   Yes, my name is Jan-Jaap Koopenshoek, I'm a Red Teamer and Reverse Engineer for Northway  Cybersecurity and in this talk I want to give you a primer into Kernel Driver Vulnerability  Research, specifically for Windows Kernel Drivers.  And my aim with this presentation is to give you the knowledge and the tools that you need  to start your own research in this area.  To do that, I have different topics I want to discuss.  First I'll give a bit of context about offensive use of Kernel Drivers.  Then I'll discuss our own research at Northwave and give some overview of that.  And then we'll do a deep dive into the technical details, first about how drivers work and  how they are used.  And then I will show you some common vulnerabilities that you might be able to find in Kernel Drivers  if you start your own research.  And we'll end with some automated tools and a conclusion.  Imagine that this castle is your computer's security.  So you can see it has very steep walls.  It maybe has watchers on the walls.  And this will pretty much keep an attacker out, or so you think.  Because if the whole system is actually built on a core that is instable or insecure, an  attacker that has access to the core can bypass any security measures and topple the whole  system.  And this image also lets me show you a bit about the difference between user mode and  kernel mode.  In user mode, we have our normal user.  We even have our admin user.  We even have an elevated admin user, as Taima talked about in the previous talk.  And then we have one level lower, the actual kernel.  And on this level, all security measures are basically off.  And you can bypass a lot of the security measures that are normally existing.  We have also seen the power of kernel drivers recently in the news.  A small bug in one security product caused a lot of computers and systems over the whole  world to topple and stop working.  And this shows you a bit about what an attacker can do with access to kernel driver vulnerabilities.  And indeed, we see that attackers are also actively abusing kernel drivers in their attacks.  Here we see a news article about a North Korean APT, and they use kernel drivers to gain more  privileges on systems.  And also a financially motivated attacker that is described here, they also use these  kinds of techniques to help their hacking attempts.  And also from the offensive security side, the ethical hackers, there are a lot of tools  that use kernel drivers.  This is an example by Outflank, a tool that can dump LSS credentials through a kernel  driver, thereby bypassing some security measures in user space.  There's also Backstab, Blackout.  These tools have the same goal of disabling antivirus by using a vulnerable kernel driver.  And there's also an initiative by security researchers called LOL Drivers.  And it contains a list of a lot of known drivers that are vulnerable in this way and can be  used for malicious purposes.  And in a recent research published by Kaspersky, we also see that the bring your own vulnerable  driver attacks are really gaining popularity over the last years.  So yeah, that really shows you how important this is.  And that is a nice bridge into our own research in this area.  So let's first start with introducing the team.  I did not do this research on my own.  I did it together with Alex, our reverse engineer at Northwave.  Also Thijm Gommers, the previous speaker when he still worked at Northwave.  He also worked on this project.  And finally me.  So some statistics about our research.  We created a database of around 5,000 drivers.  And we filtered them to see which drivers have good potential for analysis.  I'll get to that later.  And in these drivers that we manually analyzed of about 80, we found 35 vulnerabilities in  24 drivers.  So that gives you a bit of an indication in how large of a percentage of drivers are actually  vulnerable.  If you do a bit of filtering, you can actually get almost, well, we got almost 30% vulnerable  drivers.  Of these, 12 could be used for privilege escalation and 4 could disable the EDR in a similar way  to Backstab and the other project.  So some highlights of our research.  We found a vulnerability in Ivanti Pulse Secure.  Well, this is a very well-known product.  And we found a way to do privilege escalation in the VPN client.  This is also posted on our blog.  Another one that we recently found is in Macrium.  This is enterprise backup software.  And we also found a way to do privilege escalation based on a vulnerability in a driver of this  software.  And a final highlight is LogMeIn.  You might all know this from Hamachi, which used to be popular back in the day for gaming.  But it's also used in enterprises.  And here we also found a privilege escalation in the remote desktop software, and specifically  the kernel driver used there.  So some highlights of what we can achieve.  Now let's dive into getting you the tools to do similar research and get your own vulnerabilities.  So the first step to do research is to actually gather the drivers.  So how do you do that?  There are several sources that you can consider.  Most obvious choice is the Microsoft Update Catalog.  This is where Windows downloads drivers from.  If you couple a certain device and it doesn't know the driver, it gets it from this catalog.  And it's pretty easy to scrape this and extract all kinds of drivers from it.  A drawback that we found for this is that because Microsoft has quite some strict policies  for accepting drivers, there is some security screening on the drivers in this catalog.  So we found that the percentage of vulnerable drivers in this catalog was lower than what  we found in different ways.  So what you could also consider is going to vendor websites themselves.  This is just an example of a vendor, but there are many vendors.  You could scrape their pages and gather drivers in that way.  But that's obviously a lot of work.  Another source is Driver Identifier or the like.  There's a ton of driver updater software in existence and you could reverse engineer how  they get their drivers and try to pull the drivers out of their database.  And finally, there's also VirusTotal.  This service is usually used to upload malware, but a lot of people upload also legitimate  software there and it is cached for anyone with a license to download it.  And we also downloaded a lot of drivers from VirusTotal for our research.  So that's also a source that I can recommend.  So once you have all these drivers, you need to do some filtering because there will be  duplicates, there will be different versions of the same driver, and in newer versions  a vulnerability might already be fixed, so it's really not worth looking into the older  drivers at this point.  So you want to keep only the most recent version.  You can filter drivers by signature because some vendors are known to pay close attention  to their security, for example Microsoft themselves, antivirus vendors.  So if you want to find easy vulnerabilities, you might want to exclude those drivers.  You want to find drivers that need no special permission because if you need to have special  permission to interact with the device, it's going to be more difficult to perform research  on it.  And finally, you can also do some automated analysis.  At the end of the presentation I'll get to some tools that you can use for this, but  if automated tools find bugs in the code or interesting points to look at, this can be  a good starting point to start your manual research.  So once we have a list of our drivers, the next step is to actually load them onto a  test system.  So to do this, we need to know about different types of drivers.  So there are plug-and-play drivers and there are the legacy drivers.  Plug-and-play basically works like this.  You connect a device to your computer and the computer then loads the specific driver  needed for that device.  This means that if you want to analyze a driver, you need to actually plug in the right device  or find a way to spoof that device.  So that's a bit more tricky than looking at legacy drivers, which can manually be loaded  or are just loaded at the system boot.  So for your first research, I would recommend looking at the legacy drivers because that  is just easier and quicker.  And specifically, I would recommend looking at device drivers.  There are many different types of drivers with different ways to communicate with them.  There's file system drivers, there's network drivers, but the device drivers are the most  easy to interact with.  There's just a simple system call that you can use to interact with it and there's many  exploitation examples for these types of drivers.  So this is really easy to get started for your own research.  So how do we actually load the drivers then?  Well, there's a very easy example.  You can just download software from the vendor and run the vendors installer to get the software.  But not always do you have the vendors installer.  So sometimes it can also be really easy to just use the service management tool from  Windows to load the driver onto your system.  I have put the commands here for future reference.  So once the driver is loaded, we need to actually analyze the driver.  So here I will dive into a bit of the technical details.  I will first show you how a driver looks from a development perspective.  So in the C source code, and then I will dive into how this looks in assembly from a reverse  engineering perspective.  So a driver starts with the driver entry function.  As you may know, other software usually start from a main function.  Well driver entry is basically the main function for the driver.  And it has a couple of tasks, but the most important ones are creating a driver device.  At least that is for device drivers.  Well here it creates the device and this is actually the object that can later be used  to interact with the driver.  And after the object is created, it creates several handlers for different events that  can happen with the driver.  So we see here create, read, write and device control.  Create is called when the user actually tries to communicate with the device.  Then read and write can be called when the user is reading from the driver device or  writing to the driver device, because it is basically a file to Windows.  And the final one is the most interesting to us, which is the device IO control handler.  And this actually handles the explicit communication from the user with the driver.  And here we see the device IO control handler.  It always has a specific format, so if you do your vulnerability research, you will definitely  encounter this function.  And here we see a bit of the steps.  So firstly we see at the top, it gets the device IO control and this contains a code  that is basically an index for the type of action that the driver needs to perform.  So the user gives this ID and the driver does a lookup and performs the right action.  And then there's the system buffer.  And this is a buffer that the user gives to the driver with some data.  It can be arbitrary data.  And it's good to know that it consists of an input buffer and an output buffer from  the user perspective.  But in the kernel, this is merged into a single buffer.  So there are also some vulnerabilities that are due to this fact, or at least do have  to do with this fact.  Now here we see a switch case statement for looking up the IO control code and performing  the right action.  And important for vulnerability research is knowing where the user input is.  And in this case, it is the system buffer, the sizes of the system buffer, and also the  IO control code.  So we will see later how this can affect vulnerabilities.  So that's how the driver looks.  The next step is actually interacting with it.  So you have the driver loaded on your system and then you want to know what is the device  call that I want to interact with.  There are two ways to find out.  You can look in the driver itself, look for the strings, and usually there are some strings  that immediately pop out and show you the device object.  Another way is to use WinObject.  It's a sysinternals tool and it also lists all the devices available on the system.  And usually you can find by the name that a certain one is the one you need to use.  And once you know that, you can actually interact with it.  It's two calls.  The first one is create file, which is the call to open a specific file.  And since the device object is also a file on Windows, you can just open it in that way.  And then you can interact with it using device IO control system call.  And here we also see the user data being passed, first the device IO control code, then the  data and the sizes.  I skipped some details here to keep it clear for brevity, but the Microsoft documentation  is pretty clear on how to use this.  You might encounter some access controls.  The first access control is defined through SDDL, the security descriptor definition language.  I always forget that acronym.  But it controls which kind of users can actually interact with the driver.  So if you want to start your own research, it's easiest to look for drivers without an  SDDL or a very permissive SDDL that permits any user to communicate with the driver.  Another access control is in the create function.  Remember that we had that handler for the create event.  In that handler, the driver can also implement all kinds of checks.  Is the process that is interacting what I expect?  Is there a signature on the process?  Is the right user connecting?  So you also want to find a driver that doesn't do any checks in the create function.  So let's move into the reverse engineering part.  As you might know, usually you don't have the source code.  So you will have to look at the assembly and open it in the disassembler and try to find  out what you need to look at.  Here I will show the C code and the assembly side by side to give you a view of how this  looks like from a reverse engineering perspective.  Here we have again the driver anti-function and I'll step through it with you.  Here we see that it initializes a couple of strings.  On the right, you can also see that you see the same strings in our disassembler.  This shows you already the devices that are created.  These are also the devices you can look up to communicate.  Then it actually creates the device with these two system calls.  Then it moves on to initialization of the handler functions.  On the right in the assembly, the function names don't make any sense.  It's just the offsets.  If you look at the offsets into the array, you can actually see 70, 80, and E0.  This actually gives you an indication of which handler it is.  First there is a fallback handler for all the events that are not implemented.  Here we see that create, close, and device control are created.  These are directly mapped to 70, 80, and E0.  If we see something is written at offset E0, we always know that that function is our  device I-O control handler.  Here I have given the functions clearer names.  If we look more closely at the device I-O control handler, we see it first gets some  data from the user input, the IRP, the request packet, the I-O request packet.  It gets the I-O control code at offset 18.  It gets the input and output buffer length.  It's a bit optimized on the right, but you can at least see that one of the lengths is obtained.  It also obtains the system buffer.  That one is most interesting for us because it contains all the user inputs.  Here we see a lot of branching statements on the right.  This usually indicates a switch case statement.  We see that it checks the I-O control code and performs the right action.  Now that we have a bit of an overview of how drivers work, it's time to go into the actual vulnerabilities.  The first one that is interesting is the dangerous legitimate functionality, as I like to call it.  This is very similar to Dynamite.  As you know, Dynamite was developed to blow up mountains and create pathways that trains  could pass through or other things, but it can actually be used in wrong ways.  Just the same it is with drivers.  A well-known example is Dell.  They had a driver that allowed an administrator to read and write to arbitrary locations in  kernel memory.  This is very easy for debugging purposes, but in production this can be very dangerous  and gives us a read-write primitive that we can use to do all kinds of privilege escalation.  Here you see the user inputs on the left and also user inputs on the right.  The left one is for the read, I believe, and the right one is for the write.  In the end, it all comes down to a memmove call.  Understanding these kinds of vulnerabilities is just looking for the memmoves and seeing  if there's any user input in there, and then it's definitely an interesting point.  Another dangerous legitimate functionality is terminating a process.  This is a vulnerability that we found in our research.  Here we see that a value is read from the system buffer and it's given as the first  argument to a function that I have given a recognizable name already.  If we go down into the function, I'll spare you the details, but in the end it does open  process and terminate process on the process ID given by the user.  You can already imagine that this can be very nice to disable EDR, for example.  A third example is physical memory mapping.  Here we found, I believe it was Tijmer that found this one, a driver that does mmMapIO  space and it maps some physical memory into a user-writable location.  Users can actually read and write to arbitrary locations in physical memory.  Here is again the user input and it's stored in the physical address parameter for mmMapIO  space.  This is again an example of a dangerous legitimate functionality.  The next type is the very well-known buffer overflow.  Yes, it also happens in drivers and it's very interesting to exploit this.  I have a couple of examples.  The first one is in the Macrium backup software and here we see that the user input determines  the size of a buffer that is allocated here and later this buffer, you can see the same  offset 2C0, is used on the bottom and it's used as the buffer for reading a file input  into it.  There is a length given into the buffer, but it's actually unrelated to the length that  the user gives in earlier.  So this is an example of where the user can just determine the size of the buffer and  overrun it.  Another overflow that we found is a registry key.  Here we see that a location is allocated with a thousand hexadecimal bytes and you would  think okay that's pretty long, but registry keys can actually also get pretty long.  There's 255 characters per segment and you can have an arbitrary number of segments in  the registry, so it's definitely possible to overrun this buffer.  We can see that it's stored in RBX, then on the right RBX is stored in RCX and here is  actually our user input.  And here we see that the user input is copied into the buffer, thereby overrunning the buffer  and giving us a heap overflow that can be exploited for all kinds of things.  The next example is a data leak.  Kernel memory contains a lot of sensitive data that is explicitly not available for  user memory.  If you can leak arbitrary data from the kernel, this can definitely contain interesting things  that you can abuse in all kinds of ways.  Here we see that this is where the input and output buffer come into play, because if we  provide here a very small input buffer and a very large output buffer, the kernel will  integrate that in a single large buffer that is completely uninitialized.  Here we see that from that buffer it copies 100 hexadecimal bytes and then it writes it  back to the same location again.  But this means that the user can actually read from the output buffer the uninitialized  data that was in the kernel input buffer, so this leaks about 100 hexadecimal bytes  of kernel memory to the user.  The next vulnerability is kernel handle leaks.  I have found a nice analogy in practice in this image on the left.  This is a burglar that puts a device through your door and pulls on the handle to actually  open the door.  This handle is not supposed to be reachable from the outside.  In a similar way, the kernel handle should not be reachable from user mode, but you actually  need to specify this.  A lot of developers forget to specify this flag.  Then the handle from the kernel is in the user handle table, so if you enumerate that  handle table, you can actually find the handle that you can use for writing to a process,  killing a process, etc.  An example of this.  Here we see an open process call and there are some attributes given to it, but the attributes  are set to r15 and r15 is 0, xor with itself.  In this case, we see that the attributes are 0, so no flags have been given, also not the  kernel flag.  In this case, we can actually open an arbitrary process from the kernel and use the handle  from user mode.  Another example is method direct and here the analogy is the Turkish ice cream man.  You have probably seen the videos where the ice cream man seems to give an ice cream,  but just as the user takes the cone, he pulls the ice cream away again.  In a similar way, this is exploited in the kernel.  With a certain communication method, user writes and kernel reads can happen concurrently.  You can see where this is going.  If the driver is not checking it correctly, the driver can do some kind of a check.  In between, the user changes the data, the check passes, and the drive actually reads  incorrect data.  If you ever see method indirect or method out direct, this is definitely something to  look at, because the driver needs to really closely handle the interaction with the user.  They need to do some kind of locking to make sure operations are atomic.  How does this look?  This is encoded in the identifier, the device IO control code.  You can decode it with, for example, this online decoder and it shows you the communication  method.  If you decode these values, you can find these kinds of interesting things to look at.  These are the vulnerability types that I wanted to discuss with you.  Let's move on to the automated tools.  The first one that is well known in this area is Popcorn.  This tool is used to find the first vulnerability type that I discussed, the dangerous legitimate  functionality.  Not only that, but it tries to find specific functions that are used in the driver.  This can help you.  If you know that a dangerous function is used, you can then look if user input ends up in  there.  That makes a very interesting case for possible vulnerabilities.  A more recent tool that was released is by the VMware Threat Analysis Unit.  They aim to improve over the design of Popcorn and some other tools.  They use IDA.  They scripted some IDA scripts to perform the same kind of actions, but in a faster  and more fault-tolerant way.  Let's move to the conclusion.  Kernel drive vulnerabilities have impact.  We have discussed how it is actually used in practice by a lot of threat actors.  It gives a lot of powerful tools to an attacker.  That makes research also very important for us as security researchers, red team operators.  There are many vulnerabilities to be found.  Our research has shown that with some analysis we could find almost 30% of the drivers that  we looked at to be vulnerable.  You can contribute.  I hope with this presentation you have a bit of the knowledge, a bit of the background  and some tools that can get you started with this kind of research.  Thank you for your attention.  Thank you very much.  Are there any questions in the audience?  You said when creating your database you would only use the latest version of the driver  because vulnerabilities could be fixed, but if you bring your own vulnerable driver would  it be useful to bring an older version as well?  I heard myself saying it and I thought this might come up, but indeed for bringing your  own vulnerable drivers also old vulnerabilities are really interesting, but the thing with  old vulnerabilities is usually that they are already publicly known, so it's really not  worth putting your research time into it if you can also find it with a Google search.  So that's the reason that I would suggest excluding those kinds of drivers.  Okay, thank you.  And EDR will permit it most of the times.  And one of the first slides, it said 08, was it a hex address or was it a handle to…  One of the first slides, let me see.  It was about user input, sending it to the kernel.  This one?  0x8.  No?  Yeah.  The case…  Is it a memory address?  Which?  Oh, this one.  Yeah.  Oh yeah, that's the device IO control code and it has a specific format that can also  be parsed by that online parser that I showed later and it encodes all kinds of attributes  about how the interaction goes, but in the end it's just an identifier that the driver  uses to perform a certain action.  Because in kernel you also have ASLR, I think.  Yeah, there's also kernel ASLR and all kinds of protection measures.  Okay, thank you, Claire.  One last question, maybe, from the audience?  No?  All right, then we're almost ready for our lunch, but first I would like to thank you  for your talk and I would like to present you with a challenge coin.  Yes, thank you.  Thank you very much.  Round of applause, please.


url: https://www.youtube.com/watch?v=9S7gEz12nWs
title: An Angel, Python, Root And Config Walked Into A Bar... - Timothy Hjort
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=9S7gEz12nWs",
    "title": "An Angel, Python, Root And Config Walked Into A Bar... - Timothy Hjort",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1421,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   First talk after lunch, please take it away.  Hello everyone. You probably read the title. An angel, Python, root and config walked into  a bar. My name is Timothy Hjort and you guys are probably wondering why did they do that  and who let this guy up here? That's not probably not a good idea. So, welcome to my talk.  So, my name is Timothy Hjort, as I mentioned. I work with vulnerability research at Outpost  24, a Swedish cybersecurity company. My work is primarily focused around automating vulnerability  detection for already known vulnerabilities. I have a master of science and engineering  computer security, missing one physics course, but almost. I think hardware is cool. That's  how I got started in this field. I like software architecture, especially the consequences  around them, like what happens if you have a poor design in your software architecture.  And I love cheap hardware. So, our focus is going to be the consequences of subpar patching  and poor software design, as you might have surmised from my previous sentences. We're  going to be looking at a device from a company called Zyxel. It's a NAS 326. Or we could  also be honest and say that I'm going to be standing here and brag. So, we will be  talking a little bit about how the design of this thing caused quite a few issues, right?  So, earlier this year, I released a blog with the help of my company about five different  zero days on that device. And it's contained, for example, an unauthenticated Python code  injection, a remote code execution through a config upload, and a pseudo-like privilege  escalation, and some other information. And most importantly, a backdoor called NSA Rescue  Angel, the angel part of our joke. So, we'll begin by how this process actually started,  because it might be a bit interesting. So, at some point in time, I was tasked with finding  an already known vulnerability that IBM had found called ZVE-2023-27992. It's a Python  code injection. And I worked on it before they published their awesome blog that's describing  how they did it. So, I worked on it, and my work involved unpacking firmware, decompiling  binaries in Python bytecode, and digging through it. And at some point, we did also purchase  the device that was involved here, so we could start testing on it. And back then,  I didn't really find any interesting. I found the thing I was looking for, but nothing else.  But we had a student evening at some point, where students from a local school or university  or whatever it's called in English, they were coming to our company, and they were going  to get to see, like, what are we doing? And I was tasked with representing my department  and showed them a typical case of what we do. And I thought that this IBM thing was  very typical, because it involved a lot of research, decompiling, and magic. Magic. It  made me look cool-ish. So, I got back to it, and like, revisited my work to prepare the  presentation slides. And when I was doing that, I was being a little bit, like, slacking  on the job and started digging around into some unrelated files on it. And I stumbled  upon an interesting binary with the SUID bit set. Now, this is local on my machine, but  on the actual device, it's owned by root. So, I looked at this interesting name, Remote  Help CDI, that's cool. And I looked inside it. Specifically, I unpacked all the strings  I could find in it. And I found some funny strings. So, OpenBackdoor.sh and NSA Rescue  Angel. And my thought here, preparing this student presentation thing, was, well, that's  suspicious. So, we did the presentation, yada yada, things were successful, and I asked  my boss, like, hey, can I continue poking into this device? Because, well, it was end  of life at the point, but I still wanted to dig into it, because this looked very interesting.  And I happened to know that Zyxel had a couple of similar vulnerabilities with remote code  execution that did get a lot of media coverage. So, yeah. I got permission, and that's why  I'm here. So, you can probably guess that. So, we will talk a bit about how this thing  works. Specifically, we will focus, first of all, how does this NAS, like a web server  specifically, how does it handle our requests? Because this is, well, it's the software design,  right? It's the cause of our issues. So, I made a pretty image with a terrible color  scheme, I'm sorry. So, we got a client, they speak to an Apache server, and all of the  requests will be going through an authentication module, and after that, they will be passed  on to a handler, which is either a Python server or some CGI binaries. We will dig into  them a little bit later on. So, we know this file, remote help CGI, it's got some funny  content, right? It's got these funny strings. So, let's focus on it first, because it sounds  delicious. So, what does it do? I'm trying to avoid boring you guys with code, so I will  more explain about how it works, instead of showing you code and letting you read it,  because this is a presentation. So, it takes strings that are the names for a list of callbacks,  and if the string happens to match something in that list, it will take the callback and  execute it. And it's got two interesting callbacks related to those strings that we saw, right?  It's got the backdoor callback, and we can maybe guess what that thing's doing. But sadly,  it's calling a SH file to do its task, and that one did not exist in the latest version  at the time. So, I ignored it. This was a previous vulnerability patch in 2020, we will  discuss it a little bit later. But it did have one called sshd-tdc, which was new. And  it was doing basically the same thing as the old SSH script, where it starts the SSH server  if it's not enabled already, it's going to map port 22 to the internet using UPnP, that's  where you disable UPnP on your home router, and it's also going to generate a password  for that account, because we cannot give it the password ourself, and it's going to do  this based on the Ethernet0 MAC address, and it will append tdp to that output, it's  calculated, and then it enables the user, which by the way has root privileges, so it's  pretty bad stuff. Awesome. It's my fault. This looks super cool. But it's authenticated,  so that's kind of suck, because on this device, well, if you already have an account, you  basically already compromised it anyways, so meh. But this device is kind of cheap,  in my opinion. It's not a Cisco super expensive thing, so I know that developers tend to like  being wet. Write everything twice, and so I thought that hey, let's look into historical  vulnerabilities, they might be relevant into what I should start focusing on. And yeah,  I looked at the changelogs, and I'm so happy that this looks sort of readable. There's  a lot of mentions about authentication bypasses, pre-authentication command injections, and  other command injections. The list is long, I couldn't fit all of them into this presentation  slide, so whatever. We can probably find one more, was my thought at this point. So, let's  look at the authentication mechanism. IBM also describes this on that blog that they  had. I do recommend reading it. I do also recommend reading my blog, obviously. It's  better, but I'm biased. So, the authentication mechanism has one task, right? It's going  to take a request, and it's going to categorize it into two groups. Either a request is authenticated,  or it's not. It's kind of simple. The thing is doing that right, if it's an authenticated  request and you have a cookie, we're happy. And if it's authenticated and you don't have  a cookie, you're denied, and it's going to blast your request to hell and send you back  to the login screen. The quirk here is in how this thing is checking the whitelist,  and this is related to why they keep having these stupid authentication bypasses. It's  looking for substrings. So, it's assuming everything is authenticated by default, and  then it has a whitelist, and that's good practice, right? But, for example, we happen to have  this icon in our web browser that's giving this, like, you know when you get into a website  and it's going to show this icon for the website up in the corner, the favicon.ico file. That's  one of the stuff you don't want authentication for, and so it's in the whitelist, and so  what's going to happen now, right, is if this favicon.ico file is unauthenticated, i.e.  the request is valid without a cookie, we're happy. If foo slash bar is authenticated,  it's going to be invalid alone, but if we happen to add favicon.ico in the end, or in  the middle, or in the beginning, it's going to be unauthenticated. Hooray! Great software  design. So, and here's an interesting part, right? It's an Apache web server, and it has  a lot of request handlers, like scripts and CGI binaries and whatever, and the server  and also then the authentication module is not aware about what path is actually valid  the moment it gets handed off to a handler. So what it means is if you have a path to  a handler and appends something to the end, the authentication module doesn't know what's  going on. So this means that all of the handlers, like all of the endpoints that's in a handler,  it's got to then know its own path, right, because someone's requesting it, and it means  then that it's got to be able to make sure that nobody is appending favicon.ico at the  end. And it's also got to know then, does it require authentication? And if it does  require authentication, it's got to remember how do I validate this cookie, and it's also  got to remember to validate the cookie. I think we're starting to see why there's a  lot of authentication bypasses here. So in my opinion, the authentication module is useless.  Like, it doesn't really do anything. We can't trust it. We get a request that's been through  it, it's authenticated, but we can still not trust it, so it's not good.  Hello? There we go. Real quick, this is how the request for the backdoor exploit looks  like. I won't be deep diving into how all of these pieces, where they come from, whatever,  read the blog. It's good, but still, I'm biased. There is an issue, as I mentioned, with the  backdoor exploit, right? We need a password. We can't give it a password, and we do not  receive it in response. So, how do we get it? I mentioned, right, it's calculated based  on the Ethernet0 MAC address, and appending T-D-T on it. So, we as an attacker need to  either know the MAC address of this thing, or we need to have access to a shell. So,  I targeted a command injection, because I thought it was cooler, and also I happened  to stumble upon it. And the Python code injection, right, the part in the Sherry Pi server, it's  Python 2.7, so version ancient. And looking at the control flow of how it's doing, this  is, it's great design. The endpoints is terminated, like what we're calling, by calling eval on  the user input. So, this is a great design for us. So, if we request something like foobar  baz, it's, specifically what it's going to do is it's going to take two first parts,  shove it into an eval import controllers.foo, and call eval controller.foo.bar, and then  pass it some arguments. This is the main control flow for all of our requests. It's all of  our Python requests that are going to go through. So, and this is important here, that baz is  not getting included into the execution. So, what IBM did back in their blog was that they  appended this favicon.ico thing at the end of the path, because they targeted these endpoints,  right. They didn't manage to abuse the eval, but they did find one of the controllers that  called system, and they inserted backticks because they forgot to filter the user input,  and it exploded. So, they patched this by restricting request path to only contain,  like, the each section in the request path. So, it can only contain A to Z and underscores.  So, dots are no longer allowed, so favicon.ico doesn't work anymore. They also restricted  the path on these endpoints to a maximum of two directories. So, if we append, like, something  at the end, well, it's not going to be valid anymore. So, the problem is to begin with  this whitelist thing, right. If we don't have anything valid in the whitelist, we're still  not going to be happy. So, lucky me that they had something in the whitelist that did not  contain the band characters, but we could still not append it to the endpoint on this  path because, as mentioned, they restricted the number of paths in it, or directories.  So, how do we find an authentication bypass to this Python thing now, right? There is  a limit to how to length. I present to you a new endpoint that they added in a patch.  And this endpoint, we won't be reading the code, so don't look at it too much, it's ugly.  It's doing this right. They didn't learn. They forgot to restrict the number of directories  permitted in the path. In fact, it's not even looking at the path except for, it's  banning, it's not allowing the band characters, but as long as there's no band characters  in the path, we're happy. It's running eval again. And the interesting part now is that  the request body is what's getting called the eval, and the request body does not have  the limitations of A to Z and underscores. We can put magic characters in it, with some  limitations, we're not allowed to use dollar signs and backticks and whatever, because  they patched IBM stuff. But the interesting part about here, right, you guys can't really,  oh, you can see my mouse, perfect. The args argument here is the body that I'm sending  them, and it's a string at this point. They are passing it in by value to this %s in the  arguments part here. And that means it's not going to say args, it's going to be the content  of args. And that's good fun. This is important, right, because if we say A equals a string  2 plus 2, eval print A is going to print 2 plus 2, because it's a string, right? But  if we do the content, it's going to be 4. And that's what we're abusing. So we exported  it, and essentially built a big-ass request. Once again, read the blog for the super, super  details on how this thing works. But essentially, I tracked down an endpoint or a controller  that does not validate the cookie, because as I mentioned, all endpoints need to validate  the cookie themselves, and they happen to forget it here. So then I escaped the function  call, and I added my own stuff to it. And I called a utility, executed a utility called  makekey, which is what they use in the backdoor to calculate that password that you're appending.  So, and this code injection happened to be reflected, so I get the output back to me  as long as the handler doesn't crash. So, yeah. And a funny thing about it, then, is  that they did not ban things like double ticks and parentheses and underscores, and I don't  remember all of them, like commas, I think. So we can base 64 payload and set an eval  around it, and set the eval inside the eval, so we can eval our eval and get requests back.  Joe dog. But sadly, and this is why I'm still targeting this despite it being backdoor,  right? Because this is nobody, so we don't really have any privileges as this user, but  we're allowed to execute the makekey utility. So it's a little bit sad. But at this point,  right, we had everything we needed for the backdoor, so I was happy here. But then I  also happened to stumble upon a couple of bonus things here, like a local privilege  escalation that I mentioned. I was thinking like, oh, if only we had something like sudo,  but without password. Well, lucky me, they happened to have that, because this web server  needs to do some admin stuff, and obviously we had sudo without passwords. But it needs  an absolute path to whatever it's executing, so slash bin sh, and now we have a sudo shell.  Whoops. So how do we get here, right? It's a quick recap, in case people aren't following  exactly. They have a broken authentication module looking for substrings. That means  we cannot trust it anymore, so all of the endpoints after it has to do the validation  themselves, everyone has to remember to do this. They fixed the off-bypass that IBM found  in the cherry pie server by limiting the path and by banning certain characters, and  the next time that they added an endpoint, they re-implemented it, forgot to limit the  path restrictions, and they forgot to put the double quotes around the args variable,  so suddenly they did not reference it by name and it's by value instead, and now, whoops,  we have another vulnerability, so it's very easy for them to re-implement the vulnerability  in this device, and if you're reading through the changelogs, this is very, very noticeable.  They keep patching the same thing all over again. So looking at the stuff of interest  that we've discussed here, they patched a backdoor back in 2020, that's the open backdoor.sh  file we talked about. Then they patched IBM's command injection in 2023, and sometime in  between, they re-implemented the backdoor and added a new command injection, and doing  this cheap, I call it cheap code, it's not really well thought out, maybe the argument  is it's a lack of skill or maybe it's to save money and time because they don't want to  waste time on this stupid device, right? But in the end, having to keep patching the same  thing all over again, that costs a lot of money and a lot of time and a lot of effort  and it's super annoying. The patching of the stuff I found was that they killed that  new endpoint entirely, not sure why, and the backdoor function is still present on this  device, but they're making it exit early, so it's present-ish. I re-decompiled it and  dug through it, I think what they're doing is calling exit zero at the beginning of the  function, so that's good fun. So yeah, some key takeaways from this presentation, if I  wasn't clear enough about this, is that my thought and what I wanted to talk about and  bring up to attention here in this presentation is that quick patches is not exactly a good  way to do things, right? Because it's going to waste more time in the end having to re-do  it all over again, but because I've been bashing Zyxel all over, like every time in this  presentation now, they were really good to work with. Like I contacted them, told them  everything and they were like, oh shit, fixed it, even though the device has been end of  life for like half a year, so they did good. So that's good, and that's much better compared  to some other vendors I'm dealing with right now. So yeah, an angel, Python root and config  walked into a bar, if you want an easy CVS, revisit them. Their patches is probably a  good joke. That's it.  Thank you very much for your talk. Are there any questions in the audience?  Hi, thank you for the talk. I was wondering, I have two small questions. One...  Please hold the mic closer to mouth.  Oh, the code for the servers, I'm guessing they were open source, right?  Yeah.  And the patches for them.  You mean the server that you're using?  Yeah, because I saw you showed some code of the servers, and like for example, the way  you saw the new endpoints. Are these your own code or you...  No, they are delivering Python bytecode, so it's not really text, but Python is really  nice that you can just reverse bytecode back, even to get the comments back.  Oh, I see. And another small question, I was wondering, the name you found, NSA Rescue  Angel, do you actually think they belong to NSA?  Nah.  Because, yeah, I wouldn't think they would put the same name in the...  Yeah.  They wouldn't self-niche on them.  So NSA Rescue Angel would be too obvious, and I don't expect NSA to maybe be that obvious  to begin with.  But what I think is that, I think this is like a support account.  It's for when granny has any internet problems and they need to fix it.  I think that's the reason why they have this.  I see, I see. Thank you very much.  Yeah.  There was a guy behind him that had a question as well.  Thank you for the talk.  You mentioned that this device was end of life, but is it possible that this applies  to currently shipping devices as well?  Did you look into that?  It's been on my to-do list.  So this does affect at least one more device that they themselves have confirmed.  I don't remember the exact model name, NAS356 or whatever.  But I would expect them to be reusing this code a little bit everywhere.  Because last time something big like this happened, it did affect a lot of devices.  So I'm personally planning on expanding my network stack by buying a Zyxel switch and  maybe accidentally killing it.  So it's on my backbone to do.  Thank you.  Any other questions?  Yes.  Hi, thanks.  So you stated that the password for the National Support Agency account, you can compute it  based on the MAC address.  Have you investigated the entropy of MAC addresses in these things?  Because maybe there's only like 100,000.  Yeah.  I looked into the MAC address.  They are assigning them themselves.  And I looked into what ranges of MAC addresses they have.  And I don't remember the number off the top of my head.  But yeah, it's brute forcible.  So that's why I mentioned there was two ways of doing calculator and find it out.  Sure.  Thanks.  Any other questions?  Yes.  Thanks for the talk.  Is the authentication module wrote by themselves or the open source solution?  The authentication module, they coded it themselves, I think.  Because the more exact name would be like zymodoff.  So I'm assuming it's Zyxel.  So they wrote everything by themselves.  Yeah.  Cool.  Thank you.  Any other questions?  No?  Okay.  Well, then I'd like to thank you very much for your talk.  Yeah.  And thank you for listening.  Thanks very much.


url: https://www.youtube.com/watch?v=1jPyWXuc-pY
title: All Cops Are Broadcasting: Breaking TETRA After Decades In The Shadows - Wouter Bokslag
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=1jPyWXuc-pY",
    "title": "All Cops Are Broadcasting: Breaking TETRA After Decades In The Shadows - Wouter Bokslag",
    "description": "",
    "channel_url": "https://www.youtube.com/channel/UCgJoGNj3B2Mt2F3TUblcoOA",
    "duration": 1829,
    "channel": "OrangeCon",
    "uploader": "OrangeCon",
    "upload_date": "20240909"
  }

  This text was transcribed using whisper model: large-v2

   All right. Yeah, set up almost in time. Hi, guys. Welcome to this talk. All Cops are Broadcasting  Breaking Tetra After Decades in Shadows. I'm Wouter Bokslag and these are my colleagues  Jos Westeros and Carlo Meijer from Midnight Blue. And you may have heard of us before.  We have broken several vehicle immobilization systems, found vulnerabilities in the BlackBerry  QNX operating system, have broken a hardened variant of the Mifare Classic chip, well-known  from the OV chip card for the Dutchies. And we offer a variety of services ranging from  threat modeling, reverse engineering, vulnerability research, but also secure software development,  lifecycle consultancy, red teaming, capability development, so that red teams can use capabilities  that fit their use cases and trainings. Enough with the self-plug. Let's dive into it since  we only have half an hour. What is Tetra? Well, Tetra is a radio technology that's used  globally. It's a trunk technology, so you have these cell towers and you have these  handheld or vehicle-mounted radios. It competes with the likes of P25, DMR, and Tetrapole.  And it was standardized in the late 90s, mid-90s by Etsy, which is a well-known standardization  institute, also known for GSM, the various Gs. GMR also decked handheld, you know, these  portable phones that your parents used to have. And it was primarily developed for voice  communications, but it's also suitable for data communications, ranging from short text  messages like SMS, but also you can tunnel IP over it and do machine-to-machine communications.  What's interesting for us is that it relies on a secret proprietary cryptography. And  it's really broadly used by police forces all over the world, with the notable exception  of the United States and France, and some countries that kind of mirror their choices  to these countries. This is what we could confirm based on open source intelligence.  So there is definitely bound to be more, but at least these countries are using it  for police use. Then there is use cases by military and intelligence. It's even harder  to find out what these guys are using exactly. But for these ones, we've been able to confirm  use of Tetra. And also quite notable is use in critical infrastructure and industry. So  airports, harbors, industrial sites can use it for their security personnel, for their  engineers who can then talk together. But it's also used in a data-carrying capacity,  for instance, to have a SCADA telecontrol system control and monitor sites that are  remote. So you can use it for pipeline control, railway signaling, stuff like that. And it's  often heard that Tetra is an open standard, and that's a bit of a misconception because  it's a public standard. It has been funded with public money, and it is largely open.  But in the standard, you will find schematics like that. You see some key material. You  see how they are being combined by various functions called, for instance, TA-12 or TB-5.  But what these functions are exactly was held secret by Etsy. And you could get the actual  specification of these things if you would sign an NDA. But these are only available  for bona fide parties. And what bona fide is, is at the discretion of Etsy to decide.  And besides that, a manufacturer that wishes to integrate the secret cryptography of Tetra  into a product, they have to protect the algorithms against exfiltration. So they can  choose for a hardware implementation, which is really hard to reverse engineer. Or if  they want to implement it in software, they have to take countermeasures to prevent it  from being extracted from the radio. Now, the thing is that by now there is a lot of  bona fide vendors out there. Basically, every geopolitical block has a manufacturer on  their soil. So top tier adversaries like in intelligence agencies of serious countries,  they will probably have one of these manufacturers under their sphere of influence and they can  just kindly ask them to hand over the secret crypto. Or if this would not be the case,  which is the case for UK, France, United States, China, Russia. But still you could  try to target one of the smaller manufacturers and just hack them and maybe grab it off a  SharePoint or something. So by now it's reasonable to assume that any serious adversary would  have these specifications already. Now, Tetra security consists of two parts. There is the  TAA1 suite, which implements authentication and key management and distribution. It also  implements identity encryption so that you cannot immediately see which Tetra phone numbers  are talking together at any point in time. And there is some fancy remote disable, remote  wipe functionality that's also implemented here. And then there is the TEA suite of algorithms  and these algorithms are used for the actual data encryption in Tetra. And there's various  different flavors depending on the use case for the specific network. TEA2 is the one  that was originally envisaged and was intended for use by European public safety agencies  only. And TEA3 would be made available for the same use case in countries with which  we have friendly relations, but outside of Europe. And then there is TEA1, which is intended  to be readily exportable, which is also the only option for commercial use or infrastructure  use of Tetra. And there's TEA4, which to the best of my knowledge, no one has ever used.  So that's basically the cryptographic parts that exist within the Tetra standard. And  with that in mind, let's discuss project ReTetra. Now, many of you will be familiar with Gekhoff's  principle. It states that a crypto system should be secure if everything about the system,  except for the key, is public knowledge. And already in the 19th century, this was found  to be a very good idea. And why is it a good idea? Well, because violators of this principle  generally don't fare well. On this slide, you see various cryptographic primitives that  shortly or longer after their specification became public knowledge, were found to be  vulnerable. And also, there's quite a few backdoors in there. Everything that's marked  in orange was actually intentionally backdoored, exposing their users to dangers they were  not even aware of. And in the interview with Kim Zetter from WIRED, the chair of the Tetra  Technical Committee, Brian Murgatroyd, stated that in his opinion, obscurity is also a way  of maintaining security. And we will see if that holds up. So, we approached the EnelNet  Foundation, which is funding technology projects that are to develop open technologies or shed  light on closed technologies, which was our case. And we wanted to open up Tetra for public  reviews after about 25 years since its inception, in order to be able to have public reviews  effective informed risk analysis by the users of these technologies and resolve any issues  that we would identify. So, since we could not just get the specification from Etsy,  since we would be signing an NDA if they would give it to us in the first place, prohibiting  us from talking about the subject, we decided to try and reverse them out of a radio. And  after careful deliberation, we chose the Motorola MTM5400, which is a very widely used model  and commonly found online. You can just buy them off eBay. And what's interesting for  us is that it has a system on a chip that was developed by Texas Instruments. And that's  relevant because that means that the Tetra cryptography is likely not implemented in  hardware, in silicon, which would be exceedingly hard to reverse engineer, at least with our  expertise. And also, this chip has software security features that are specifically tailored  to protecting pieces of intellectual property from exfiltration. It has a so-called trusted  execution environment. And our guess was that this would be used to protect the secret Tetra  algorithms from extraction. Now, how we did that is a whole talk of its own. And we only  have 30 minutes here, so I'm going to skip over it. But what we basically did is find  a modem command interface on the rear of the radio, which you can use to send it commands  like call this number or change that in the address book. We found a format string vulnerability  in there, exploited it, and got control over the application processor. From there, we  jumped to the digital signal processor because they had a shared memory region, which was  not protected. So we could override the programming of the DSP and get our own code to run there.  And then in the DSP is this separate trusted execution environment that loaded the secret  crypto, which we could not immediately read out. But we found a cache timing side channel  attack on the AES decryption of the loading of such a module. So we extracted an AES key,  we were able to decrypt the module, and that module implemented the secret Tetra crypto.  So we reverse engineered that, and we could start doing what we actually came for. More  details on this in our DEF CON talk, but let's continue for now, and discuss some  of the findings that we actually found within this standard.  So first, a short introduction to how a stream cipher works for those of you that may not  be familiar with it. A stream cipher uses a cryptographic function, which we call the  key stream generator. And this thing takes a key as an input, and an initialization value,  which we will talk about later. And based on this, it generates a stream of bits of  ones and zeros. And these bits are then combined with your plain text message, using the bitwise  XOR function, and what you get then is your encrypted message. And on the receiving end,  you can simply generate the same stream of bits, the same key stream, combine it again  with the encrypted data, and recover the original plain text message.  Now in Tetra, this key stream generator follows always the same kind of high-level design.  Remember there's TEA 1 to 4, and they all share this outline. So you have a 10-byte,  80-bit key register at the top, which provides feedback to a state register, and out comes  key stream, which is used for the encryption of the messages. We've looked at it, we're  not professional cryptographers per se, but to us this seems like a fairly robust algorithm,  so no immediate problem here. But this is TEA 2. And once you start looking at TEA 1,  it's immediately apparent that there is a big problem here. Now remember TEA 1, the  target audience for this stuff is less friendly police forces and militaries, but also all  commercial industrial use. So they cannot use TEA 2 or 3, they have to use TEA 1. And  this function starts with a key initialization function, which compresses the 80-bit key  into a mere 32 bits. And then based off that 32-bit derived key, it will start generating  key stream. So as an attacker, you only need to brute force these 32 bits, which can be  done on my 6-year-old laptop in about a minute, and you're able to start intercepting communication,  decrypting communication, but you can also partake in the communication. You can start  talking on talk groups, but more worrying is probably that you can inject data whenever  Tetra is being used in a data-carrying capacity like SCADA telecontrol. Now in the aforementioned  interview, the Etsy chair said that we use some very high-powered equipment in order  to break these keys. Well, it's a 2016 graphics card for enthusiasts. And that 25 years ago,  32 bits of entropy was probably enough to withstand brute force attacks, and that you  need some pretty reasonable equipment in order to be able to carry out such an attack. Now  I don't think I need to convince you guys that this is nonsense, but why would we make  any assumptions or why would we limit ourselves to the use of very reasonable equipment? Why  not just see what this bad boy can do?  Hi, we're Midnight Blue. About two weeks ago, we announced the Tetra Burst vulnerabilities,  consisting of five vulnerabilities in the Tetra radio standard, two of which are deemed  critical. Since then, Etsy, the standardization body responsible for Tetra, has made public  statements in which they downplay the seriousness of the vulnerabilities. In these statements,  they resorted to a semantic discussion, not calling a spade a spade, or more specifically,  not calling a backdoor a backdoor. Furthermore, they made a number of evidently false statements,  such as claiming packet injection and TEA1 encrypted networks would be impossible, and  that 32 bits of cryptographic strength would have been sufficient in the late 90s. To any  information security expert, it's pretty clear that this is not the case. But to help remove  those few remaining doubts, we decided to take on the challenge of cracking TEA1 on  this beautiful machine produced in 1998, running good old Windows 95.  Frankly, the hardware is so old that it wasn't easy to get our hands on. When we run the  cracking tool, we see it reports that it needs about 13 hours to go through the entire search  space. After 12 and a half hours, the key is found, demonstrating the feasibility of  cracking TEA1 on 90s consumer hardware. Alright, Etsy, now that we've cleared up this issue,  please let us know if you'd like us to demonstrate packet injection as well.  Alright, so I think we got that out of the way. Now, that attack is a deliberately placed  backdoor when it was designed, but there are still the other stronger algorithms left,  right? There's TEA2 and TEA3. But we also found an attack on those. And in order to  understand that, you need a little more information on how this encryption process actually works.  So I mentioned the fact that besides a key, the keystream generator also takes an initialization  value. And that is necessary because you want to generate a different keystream for each  message that you want to encrypt. Because if you would use the same keystream again,  you can do statistical analysis, derive what the keystream was and decrypt traffic. That's  really bad. So you need a unique keystream for each message you encrypt. And in Tetra,  this is done by using the network time as a fresh piece of information, as an initialization  vector. And the network time is a series of numbers like the slot, the frame, the hyperframe,  which designates basically the time the network is operating at. And how does a mobile station  know what the time of the network is? Well, it knows because it's told. The infrastructure  broadcasts sync and sysinfo frames which contain these counters very frequently so that a mobile  station is aware of the network time, is aware of which IV should be used for the decryption.  And it's important to note that besides the encryption on the message, there is no further  integrity check, like cryptographic integrity check. So if a message would have been modified  by an attacker, the radio will still just decrypt the message and see if it can be interpreted in a  sensible way. So that brings us to an attack opportunity here. An attacker can identify a  mobile station which is connected to the legitimate infrastructure and overpower the infrastructure  signal. So basically taking over the link between the mobile station and the original infra. And  if the attacker will then start sending spoofed sync and sysinfo frames, the mobile station will  gladly oblige and start using these updated network time counters. And as such, the perception  of time of the mobile station has been changed. And it will restart reusing key stream that was  relevant before or that will be relevant in the future. So the attacker can now control  which key streams from which time will be used by the mobile station. And this once more works for  any of the of the air and interface encryption algorithms. So an outline of the attack would be  that as an adversary we capture a stream of tetra traffic that's encrypted and we identify a message  that we find interesting. We would like to know what's in that message. And say this message  has been sent at time t. What we then do is identify another mobile station or the same,  as long as they share the key material, this doesn't matter. You can pick one that's in a  convenient location. And we overpower the legitimate signal of the infrastructure.  You can do that by using a higher transmit power, by using a directional antenna, or simply by being  closer to the mobile station. And what we then do is tell this mobile station that the network time  is now again t. And then the mobile station will reuse key stream relevant at that time.  If we can then send traffic to the mobile station and somehow recover the key stream that was that  was being used back then, we can obtain the original key stream used to encrypt the message  we want to know. And if we have done that, we can decrypt the message and we have won.  How this works, I'm not going into that here because it'll take time and I don't have that.  But you can check out one of our other talks on this subject or read the research paper.  When we reported this to Etsy, they said, okay, that's a nice and valid theoretical attack.  And it's true that there is some caveats to this, right? Would a radio actually accept  these weird jumps in network time or will they just crash or will they have some safeguard against it?  So we also wanted to know whether this was doable in practice. So we asked, maybe we can have a  base station at our disposal that we can instrument and implement the attack on to  see if this actually works in practice. And they said, well, lol, no, or something along those lines.  Probably the wording was a bit different. So that left us in a bit of a tricky situation because  we wanted to validate our theoretical attack. So we could implement a Tetra base station stack  from scratch, which is a lot of work and not very fun to do. So instead we opted for another round,  the other route, and we bought ourselves a Tetra base station. That was one on eBay. It  was here in The Hague. It weighs 75 kilos and it's awesome. We found some vulnerabilities in it.  We wrote a module loading framework that we patched into the firmware so that we could  load modules at runtime. And we turned this thing into an attack platform to be able to assess  whether our theoretical attack was actually valid in practice.  Hi, we are Midnight Blue. We have uncovered several serious vulnerabilities in the Tetra  radio standard dubbed Tetra Burst. We will first demonstrate a decryption oracle attack to recover  a text message, but the attack can also be applied to voice communication and data.  The demonstration takes place on our lab setup. The radio receives an encrypted message,  which is also captured by the attacker.  We see the message says secret.  The attacker now needs to target a radio and impersonate the infrastructure  and carry out the attack to decrypt the previously captured message.  We have sped up this process.  The attacker has now recovered all he needs to decrypt the message.  This attack applies to all Tetra configurations, but can be resolved with a firmware update.  All right, so it was possible after all. Now there's many more issues we uncovered along  the way. I mentioned two issues in the Tetra standard. There's two more we found at the  Anonymization attack, allowing you to know exactly who's talking to whom at which point in time on  the network, and a session key pinning attack. Also, we found several issues in the Texas  Instruments chip that this Motorola radio was using. These are ROM level vulnerabilities,  so they cannot be fixed that easily. You would have to make a new mask revision for the chip.  We found four CVEs in the Motorola part of the firmware, and five CVEs in the Motorola  base station firmware stack. Both of these last ones allow for key extraction and for the placement  of persistent covert implants, so it's pretty serious stuff. Also, we found a backdoor password  in the Motorola base station, like a secret hard-coded password that would give you an  authorization level even beyond that of the system itself. So, this is a very important issue.  Even beyond that of the system's owner. Very fun stuff.  So, since this technology was developed in Europe, and since the TEA-1 backdoor was placed  deliberately, sure, Europe at least would not be affected by this, right? The ETSI technical  committee chair said that anyone who needs a lot of protection in Europe should not be using TEA-1,  and he would suggest using TEA-2. The thing is that TEA-2 can only legally be used by  law enforcement and emergency services, so that leaves out critical infrastructure.  That's a pretty serious case, because what you see here is a picture of how  Tetra can be used in a critical infrastructure scenario. You have your SCADA telecontrol system,  you have a Tetra link connecting it to a power distribution substation, and using either STS,  which looks like SMS, if you will, or the packet data features of Tetra,  telecontrol traffic goes back and forth between the substation and the SCADA service.  So, it's really sensitive stuff, and really bad if someone can mess with this.  Now, also, we found that up to very recently, we have actually been shipping backdoored TEA-1  encrypted material to European member states or candidate member states.  And we found this by going through a lot of tenders and using a lot of Google Translate,  but it's still being used at scale, especially in like the Eastern European countries.  And that can be explained, because back in the day when these networks were founded, were built,  we were a bit suspicious about these countries, and we were like, okay,  have this nice backdoor, we can listen in and eavesdrop. But now that the geopolitical  landscape has changed, it comes back to haunt us.  So, maybe all of this is not that relevant, maybe no one is actually targeting Tetra networks,  or trying to listen in or trying to manipulate traffic. Well, we dug through the Snowden archives,  and we found an example of Tetra being targeted for interception. For instance, during the  climate change conference in Bali, the NSA and ASD had a joint operation,  and they managed to recover demonstration routes and telephone number of the chief of police there.  And we also found a GCHQ operation called Quito, which surrounded oil exploration rights  around the Falkland Islands in a conflict with Argentina. And this is not proof that  the vulnerabilities that I've been talking about have been used in the wild,  but it is proof that Tetra is a legitimate target for attack and interception.  Now, what's next? There are new algorithms. Regardless of our research, ETSI has been  working on an update to the standard. There's now a TAA2 authentication suite, and TEA527  error interface encryption ciphers, which use longer keys. They were initially going to be  secret again, but following our disclosure, they published that they will make these algorithms  public. So that's a very nice thing, since in their own words, transparency is at the root of  ETSI. So that's fantastic. I mean, it's a step forward. We hope they will also publish their  design criteria, the reason why they would pick certain constructions, why they picked certain  constants or tables. And additionally, there is a clear front door now, because they have  already admitted that TEA7 will have an effective key length of 56 bits, as to make it freely  exportable. And that free export thing is a bit tricky, because Wassenaar, the convention  governing all of this, leaves room for strong cryptography in these kinds of use cases.  We all use HTTPS without problem. There are exceptions for civil use. There are exceptions  for connected civil industry applications. So at least the critical infrastructure use cases,  I think, should be covered by these things. And we can just give these guys strong crypto. So will  TEA7 get into critical infra again? I really don't hope so. But if it happens, at least we now know  on beforehand. So in conclusion, we have published the first in-depth security analysis of Tetra.  We've reverse engineered and published the secret algorithms that were being used.  We found multiple vulnerabilities, including a backdoor.  Patches are available for some of these issues. If you want to know more about that,  check out our website. There has been great progress in understanding these issues and  in mitigating the issues. But there's still a lot of work to be done for asset owners.  And in the broadest sense, it seems that these kind of mission-critical technologies are just  not being assessed enough. And with that, I conclude this presentation,  and I'd love to take any questions if there are any.  Yes, thank you very much. Are there any questions in the audience?  One question. Tetra is here to stay for a little while before we go over to a new system.  Would it be feasible to tunnel some other protocol on top of it,  which is encrypted, to overcome these hurdles? Yes, definitely. Etsy themselves, they envision  a multi-decade future for Tetra. At the very least, the networks that are out there are not  leaving anytime soon. So indeed, it's possible to use something like a VPN before you start  sending your IP traffic over Tetra, which would be a very good idea. For existing networks,  however, especially in the industrial context, due to the strictness of the acceptance testing  and the safety engineering involved, it's very hard to make these upgrades or modifications  because you introduce new failure cases. You have to do a lot of work, again,  proving that the safety of the plant cannot be compromised by adding security. So it's a great  idea. It should be done, but in practice, especially for existing plants, it's not that  simple to actually roll out. Thank you. Well, that concludes the time we have for this talk.  Thank you very much, and I would like to offer you with a token of our appreciation, of course,  like everyone else. Thanks. Thank you very much. My pleasure.


