BSidesDFW2025 Track 1

All right. Uh, cool. All right. Um, this doesn't look like a lot of people, but I guess some folks are still outside. Uh, welcome to I almost said the wrong name. Welcome to uh Oh, there we go again. Gosh. Besides DFW 2025. >> Um, so as you can tell, it's already been a long morning for me. Uh, I do not have any slides, so and I forgot to cue that up. Um, I'm just kind of gonna run through last year's as a reminder for myself, but you can't see that because I wasn't able to get anything updated. Um, so obviously you're in this room, you've either gotten a ride from somebody else or you've already parked. Uh, if you've

parked, please make sure you've actually registered for a parking pass. Uh, it's digital. There are uh various signs with a link and if anybody still needs it um it is besides UTA25 is the code. Um so yeah that's the parking situation. Um we're more or less facing south. Uh, we have access to lots 34, lots 36, and lot F12. Um, but you're here, so I assume that's been taken care of. If not, do it. Um, first rule of bides, don't hack the venue. Uh this is our second year at UTA and this there were various comments from last year but I think most of us thought that this space worked out very well. So we returned to the same area um

only the big difference this year since we don't have any real additional workshops everything is on the first floor so there's no going up and down the stairs. Um there's various maps around the building. If you need to find your way, reference those. And um the other piece is be excellent to each other. Um there is a full code of conduct. Come on. Um dumb it. I don't know where that's at at the moment. It's lengthy and detailed. Um, basically it it comes down to we encourage uh disparity of thought. We encourage having uh conversations and sharing those thoughts, but there is also a time and a place for certain discussions. So, just remember you are

in a mixed environment. Um, if for any reason uh things go too far, please find one of the volunteers or report to the regge desk and let us know so we can take care of it. Um, at the end of the day, uh, no tom foolery will be tolerated and uh, we'll take the actions that we feel are necessary. Um, so do the right thing. If you see something, say something. And the full COC is online. Um, again, I was not prepared for opening ceremonies, so I can't actually read it for you. Uh, our sponsors, um, we have a new record this year. Uh, we have GM Financial, uh, their booth is right outside track one. We have the

university themselves. Their booth is along the back wall. And we also have um Beasley Security. Uh they did not opt for a booth. Uh some of their employees are around. Um if you see the fine fellow with the suit and the handlebar nest mustache, he uh Oh, I just doxed him, didn't I? Um you might want to say thank you to him and uh uh for getting his company to sponsor. Um and and that's a I don't want to say a low. Um that is a new minimum for us. Uh we we've we've always operated on a sparse number of uh corporate sponsors and this year it just really kind of made a new record. Uh with that said, uh we do have

some honorable mentions. The UTA cyber security club has a table right next to the cse department. Uh they are running a CTF and a uh scavenger hunt. Uh hack Fort Worth. Uh I don't remember if they contributed to the same scavenger hunt or if they have a different scavenger hunt. Um but they are the next table over. They are assisting with the scavenger hunt. And we have North Texas vote or votes plural. Um again uh everybody knows the current situation and uh geopolitical uh environment. Um regardless of your opinion uh it's important that you do make your voice heard. Um so they're here with information on getting registered and participating intelligently. Um and we also have ISSA North Texas in the

house. Uh so if you haven't been to their meetings, um that's a good resource. They're a bit more on the corporate side. Um but that's all good, too. Uh again, diversity. Um I will call them out, not because I'm not seeing one of them in the room. um as part of the crew that rebooted ISSA Fort Worth in 2017 and brought that group back to a a regular functioning group with uh good attendance. It was painful to see them fold during pandemic. Um the management at the time did not consult the membership and they made an agreement. Oh, there's one of the ISSA. They made an agreement to become part of ISSA North Texas at that time. One of the things

mentioned was that they would also be doing things in Fort Worth, which was the whole reason why we had two groups in the first place. Uh, unfortunately, that has not really come to pass. Um, so the more people we get to join ISSA Fort Worth or North Texas from the mid cities, the more we can pressure them to actually bring events into our neighborhood so we don't always have to drive far north. With that said, they did start having some of their meetings in Los Kolinus and um lower areas uh actually in Dallas County. Um so yeah I I just encourage everybody to join. The more we get from mid cities the more we can influence them and become even more

uh participatory. Comment

Awesome.

Okay. So, as Jason said, if you're in the Mid City's Fort Worth area and you want to make sure that stuff happens, talk to them at their table and uh volunteer. Um, it's the same thing I've said for a lot of the different groups I've been a part of. We provide the space, but the groups are really yours, and it is what you all make it. So, please participate and help run some stuff. Um, so yeah, our our key volunteer or our key sponsors this year, GM Financial, uh, well, actually, let me take them in order. Uh, UTA, Department of Computer Science and Engineering, GM Financial, and Beasley Security. Uh, please let them know you appreciate them

sponsoring. Um along those lines, we had a small snafu with the t-shirts. Um unfortunately, things got delayed and they modified our ship date to after the event, so we do not have any t-shirts this year. Um, we bounced around the idea of the logistics of supplying t-shirts after the fact or um switching to a pay as you go option. So, we opted for the pay as you go. We're going to repost the design as a quote unquote fundraiser because that's the option on the service, but we're ratcheting the cost down to basically cover production. um they estimated like $5 profit for a hundred shirts. Um so we're we're trying to keep the cost as low as possible and if you want a shirt

be on the lookout for a link after the fact and um you can go uh purchase one on your own. Um I apologize for that. Uh everything kind of ran last minute this year and we just hit a hiccup that pushed the the delivery date back to something that wouldn't work for the event. [snorts] Um if I could computer badges. Uh as you might have noticed we had another snafu with the badges. Um, they took longer to produce than originally anticipated and some of them unfortunately were considered scrap and part of a garage cleaning uh adventure. Um, and they went away. So, we're short on the nice wood badges. Um, and we're we're right now we're doing those for

the prerege and if there's any left over at the end of the day, we'll kind of swap those out. Um, if you've got a paper and you really really want a wood, uh, at some point in time we will be collecting names and we will try to figure out how to get those distributed. Uh, apparently we're going to make more after the event. Um, the schedules, as I mentioned, are already out there. Uh, venue map is already out there. Uh, this is track one on the opposite side. Same room with a wall in the middle. have track two, track three, and along the back wall you've got speaker green room, which most of you will never be in. Um,

lockpick, hardware hacking, UTACF, UTD, CTF. Um, ah, yes, food. Um, we had an issue last year. There was a bunch of tours going on and a ton of, uh, civilians on campus. um they were getting vouchers for lunch and when people went to the UC to eat at the Connection Cafe and they were asked about a voucher, they said no and were sent away. Um for whatever reason, uh I believe it was even reported a couple people offered to pay and they even refused them. Uh which was weird. But anyways, uh we've supposedly Yeah, we have supposedly worked that out and Connection Cafe is very much aware we are here today and if they say anything,

remind them you are paying in cash or card and you're not part of a voucher group. Outside of that, um there are other establishments around campus for uh lunch and there are various maps posted uh to help guide you in those directions. Um so lunch is not provided this year except for limited for this uh volunteers. Um and really that's kind of about all I have unless I'm forgetting something which is very possible. Um, I think we've got a pretty good uh speaker lineup. Um, only I don't I don't even think it's half. Um, compared to some of the other schedules I've seen, I think we're on the lower end of AI. So, if you're

burned out on AI, that's okay because I think less than half of ours mention it. Um, and uh, yeah. Um, so badges, analog. Um, we do have stuff in the hardware hacking village to solder on, uh, if you want to do that. And I think we have a bunch of activities outside of the talks for you guys to engage in. Uh, I hope you have a wonderful time and I will get out of the way to let the talks begin. So again, welcome and THANK YOU.

HELLO AND WELCOME to Dallas besides Dallas Fort Worth for our first speaker of the morning. We have the Mr. Jason Hyde also known as Satic online uh with a talk on command control with silver an introduction to the silver command and control protocols and issues. Thank you. >> [applause] >> Thank you so much for having me. So online my name I go by static but I also go by Jason as he said it my >> hello. Oh okay. So it's for is that for the YouTube? All right. Louder.

All right, everybody. Welcome to How to be a Red Team Operator with Sliver C2. We're going to be going over some malware uh development. We're going to be going over some antivirus evasion, and we're going to be going over a in-depth discussion of how to hack Windows uh hosts. Who am I? My name is Jason Hyde. I go by the name static when I'm going online. Uh I am the founder of the security firm static security solutions. Uh I specialize in exploit development and command and control frameworks. I do in-depth clientele uh development for them. I do exploit development for different softwares. I do reverse engineering. And when I'm going about online, I usually do some Red Hat

operations as of hunting down traffickers, uh finding people specialize in selling less than legal content and overall just not great guys. And when I'm not doing hacking or offensive security in one way or another, I'm doing uh either playing guitar or I'm working out. As a slammer, I have to admit, do not hack the venue. Do not test software or uh items that you have not been given direct uh consent to test either verbally or written. And as a prerequisite, I got to say I can't teach y'all everything about hacking. I can't say hey this is how you hack an API. I can't say hey this is how you tunnel through a network. Some of this is going

to be expected to be known. So a little bit of network protocols is going to be assumed such as ADCS LDEP with Windows and just overall Windows security. And as always, if you do have you don't know me and you didn't learn how to do it for me. Welcome to part one your kingdom. This is going to be the more non-technical part. This is going to be downloading your server, setting up your client, and just getting your profile started. We're not going to be touching anything of generation or we're not going to be touching anything of that guy's network, right? That's it. Now, a C2 is essentially going to be a hacker's file manager. It's going to be

a task manager for a hacker. All it does is it says, "Hey, what do we have? Where have we been? And where do we go in attacking a network?" It's going to help you develop uh exploits on the go. It's going to help you generate which clients to go after next. and it's going to tell you hey here is your list of options what do you want to do it's very helpful and in depth and overall a good uh overall it's not required to be said we're not going to be talking about it too much but red teaming is something that I feel like is important to discuss as red teaming is going to be the

discussion of ethical hacking with a specific goal in mind legally for an operation so you're going to have penetration testing you're going to have gray hat hacking Red Hat hacking is you being hired to find a specific item to test such as a financial result or a means to an end such as I've heard recently that there was a report of a guy who had to do a red team operation of taking biological data from a one of those biolife firms. Now why sliver? Sliver is a terminalbased uh command and control framework written in go. It acts as a client server operation where your client is going to send everything to your server and the server does

everything for you. There's a very little connection back from your target to you when using the server. That is one of the great things about it. And as it's not really a common thing, it's not an uncommon things these days. You'll see it more commonly. Cobalt Strike had it, Armitage had it, a multiplayer mode where multiple operators can go through a server and attack the same thing on an operation. So when you're doing a red team operation, you'll have an engineer, an operator, a social engineer. You're going to have multiple people doing different roles. So a good thing to remind that all these different roles, you're not in the real world. You're not always going to be one guy hacking

everything. You're a team. That's an important thing to remember as a red teamer. So the best part about multiplayer mode is all of y'all are coordinating into one server and you can all just work together in that one area. Yeah, of course. >> Now, what are the benefits of Sliver? Uh, it's crossplatform. It comes in Windows, it comes with Linux, and it comes on Mac. I have seen maybe two other C2s that do this. This is one of my favorite parts about it. I've done it on Mac. I've done it on I promise I did it legally on Mac on hardware. Uh, I promise, Pinky. Uh, but I've done it on Linux and I've done it on Windows. All

of them can connect to the same server. That's so cool to me. Uh, it's evasive by default. When you compile a piece of malware through Sliver, it is automatically evasive signature- wise. I'm gonna add that because if you know how Defender works or how antiviruses work, it's signature evasive, not all antivirus evasive. Uh, it has a built-in payload generator. Now, I assume some of us have done some hacking in the past. We've all made a little bit of malware. We've all done a little bit of hacking here and there. If you know that feeling, you've had to go back and forth between making your own malware. You've had to download another tool to make your own beacons. You've had to use a a

new tool that just came out to do it. Sliver comes with its own built-in payload generator. It is amazing and it can be so customizable if you know what you're doing. We'll talk about that. And another part about it is it comes with the armory. Now, let me see. Have any of you all used a command and control framework before? Awesome. We have a few people. You might recognize that sometimes you have to download the tool individually to use a certain uh item. So you have to do like execute assembly on a tool you've already installed. Sliver comes with an armory and with an armory you can install all the tools you need to use.

You have 150 tools. We'll talk about that later. And as again multiplayer mode it's more standard these days but it's going to be something that when you h when you don't have it you realize how much you wanted it. That is a great point. [snorts] >> Someone pull the fire alarm. Don't do that. >> Hell yeah. [applause] That's your black. That's your black hat. Uh, SL is pretty cool. It can be installed in numerous ways. I'm sure of us had had the pain of having to install a software in one convoluted way. Snap. Uh or another way. Sliver has multiple installs. And so we're going to go through those. You can use apt. I'm sure

some of most of us have used Linux before. With apt you can install sliver as apt install uh sliver and that will download your single operator and your client. Well, no, that'll install your uh client server and that'll set everything up configured for you. You don't have to set up any of your uh config files. That will all generate for you. That's kind of my personal favorite because it does that for you. You have the bash method. So, Bishop Foxch, the company that generates sliver, uh they actually provide a uh a oneliner to install a sliver operator client for you. So, you have a sliver operator binary. It's going to be an all-in-one. If you're doing a solo operation, this

is going to be probably the better one for you because it has you don't have to do you don't have to beacon to a file through a server. You're just you have your you are the server. You are the client. It's all in one binary. And you have a client if you want it. Then you have make. If you know make, if you know programming, you know what making is or you know what compiling is. Make is just the command to compile it with a make file pre-generated. This is going to be the better one if you don't trust something to be done without yourself. You don't trust app. You don't trust automation. This is you doing it

yourself. So, and also this is probably the better one if you want to tinker around. If you want to add your own setups, if you want to add a way to hide under the wire because obviously things can be caught, this is better for you. And lastly, we have release on GitHub's uh official page. There is a release uh format on the right hand side where you can just download pre-ompiled binaries. You have I I wish I was joking. You can do ARM 64 or AMD 64 for Mac. a CPU you won't really see on Mac if there's it has every version for you just in case because you might be running on a operating system on a

virtual machine. They have thought of that and they do it for you. Now I'm going to go ahead and show you how to do the make installation and how to use the app installation or the oneliner installation, my bad. So we're going to see on the oneliner page, this is going to be where you just scroll down to the official GitHub. This is going to be both on the GitHub and the official sliver.sh SH website provided by Bishop Fox. Just copy and paste the line to your bash terminal. Don't judge me. I did use Cali for this. I I don't in my in my uh personal time. I promise. Um yeah, it's easy as that. You just

copy and paste. Now, if you're hesitant, like I said, I recognize some of y'all might be hesitant to run a pseudo bash script automatically. Yeah, you might be hesitant to do that. That's why I also showed how to do the make version where you can just download it yourself. You can get clone the official repo and then you can also compile it yourself. So, it's going to go through that. I just move my screen and you just run your sliver file for you. Just type sliver and it's good. And this is how it looks. It is a basic terminal that you can go through. And as I saw you nodding your head for that uh bash part, I assume uh

You can just go to this in uh GitHub. You copy and paste. You get clone that URL. That's going to clone everything in that repo to your local host. I'm assuming we all know what git is. Cool. So, you just get clone that. I went ahead and sped this up. This entire part, I will admit, took longer. Compiling a file takes a while, especially of something of this size. This is not a small program. So this took about four minutes and all from cloning to compilation I'll admit but with it you get every single binary that you will need or might have for sliver. >> Not bad. Thank you very much. So all right as you saw I get cloned it and I just uh

changed directory into it or cded into it and I just typed make. You do have to uh install mate typically for most Linux programs. It's easy as pie. I promise. Most of the time when you do run sliver or you have to try and install it, I will admit be careful which version you're running on. You need to be careful that you are doing everything properly and by the book because if you change it, Bishop Fox has made a warning about they have made a statement about it that not everything is made to be different. If you do it outside of what they planned, it won't always work. It will not always run. That's just

standard for hacking though. And as always, we're going to be needing to connect to our client. We need to have a server client setup anyways. So, I went ahead and showed you how to do that because it's going to be different. It's going to be a little bit unique. If you use Cobalt Strike, if you use Armmitage, you don't just simply connect as you do with some clients. It's more as you have to set it up on the server itself. So, I went ahead and generated a profile here. I chose any IP. Don't do that. Choose your server IP. I promise whether it's a remote server or your local host, choose your local IP to connect to. That's just a way to do

it securely. Then you're going to go and import that profile into your host for your client. And then you're going ahead and just run your client. It's easy as that. Welcome inside your tassel part two. This is the part where we're going to be going over what you're going to be generating. This is what going to be how you develop your malware. It's going to be how you create what you everything you need to attack that guy over there and specifically. So this part is going to be more technical. This part is going to be a bit more nuanced. You're we're going to go some over some things that a little bit is going to be taken for granted of

understanding specifically network protocols. If you understand some things, awesome. If not, I apologize. Specifically, we got to do some to some definitions. So a listener, a beacon, it's kind of what it sounds like, but just in case a listener is a item that waits for something to come into it. It's going to be waiting for an open call. Now, this can be a random port of anything or it can be a generic TCP listener. You can wait for anything or you can have a specific host, specific port, specific IP and specific just uh you can even have dedicated certificate keys for your listener to connect to in case someone you're worried that someone's going to try and attack you as

well. And for a beacon, this is a good definition of a beacon is this is your payload. This is your malware. This is going to be the thing that when you're on your target, this is what connects back to your listener. Simple as that. And as a little thing that will help us later, portable executables. These are going to be your basic file formats for Windows. It's going to be a service, going to be a DLL, this going to be an EXC. Talking about this later, and listening as a listener, it has five basic protocols. It has HTTP, HTTPS, MTLS, WireGuard, and DNS. Wireguard is a VPN protocol. If you do not use it, it

is a uh VPN protocol. This one is going to be in my opinion the best to stay hidden what you're doing but you will be black on white with what you're doing if you are going to be going through a network if that does not use wire guard if you're using a service or a VPN such as Cisco any connect or any other type you will be so visible then you have HTTP if you know networks don't use this is for practice only and doing your own stuff that's how I would phrase it do not touch at HTTP mls is going to be more for secure this going the below HTTPS and security and just bang for

your buck. MTLS is going to have your network as a peer-to-peer connection basically of mutual TLS, transport layer, whatever. Forgot that. Um, it's going to be more stealthier. It's going to be more under the radar. But if your company that you're targeting does not use MTLS, this will also stand out. Be careful. Uh, then you have DNS. DNS is going to be uh more unique queries. This is going to be uh called queries for a DNS name. This is cool. This is nice. It's pretty well known. It's pretty secure. But stick to this for exfiltration of data slowly. If you have a bunch of DNS calls on the network, it's going to look weird on the wire. I

promise wire guard is going to light up with DNS queries. Looks weird. And then or my personal favorite, HTTPS. This is the best bang for your buck. If you go to a network and use wire guard, you're going to see HTTPS flying through that thing because that is just what people use for the browser. It's what they use for YouTube. This is what they use for Git. With this service, it's going to fly high. It's so good. And you can even customize it inside the config files as I mentioned before with the make installation version. Now, for the part that Sliver doesn't tell you, if you use Sliver, none of this syntax is really told to you. You

can do all of this yourself if you use the ports, but it's better to just see it. I'm going to be covering this shortly, but you can. So, take a picture if you want to. I might show it to you later if you just come by. So, as I've gone down it, it uses the ones that I've already talked about previously. Uh, notice how both DNS, HTTP, HTTPS all ask for a domain. Have a domain set up as a red team operator first. Do not go into an operation without a domain. This will just make it better for you overall. Just it's going to look weird if you have some funky name of like hacker.local

pulling up or just your oper like Windows. It's going to look so weird. Do not do that. Do not have DC1 local as your DNS. Uh MTLS is going to be the most basic with the syntax you can use. And for WireGuard, you're going to have the basic commands of you're going to have your VPN port and you're going to have your tunneling port. This is going to be a good way to stay hidden, but you're going to light up a network. And as you can see, it does require for HTTPS and uh yeah, just HTTPS a key format. have that pre-generated before you start an operation. It cannot be st overstated. Have all of this started before you

start an operation. You want to have this done and completed weeks before you start. That's how I would recommend it. That's how I would describe it. And for your beacon syntax, I spend hours doing this part. I'm not joking. None of that file format part or the operating system part is uh none of that part is really told to you. But as you go through it, it's going to be a standard generate beacon-p protocol-m for wired or d-https. That's going to be your uh protocol type. Then you do an IP and then you can add any of these. Evasion is going to obfuscate your code during compilation. It's going to hide signatures and it's going to remove a

little bit things here and there. It's going to make it even more modified. It's going to have evasion on top of evasion. We're already at number two here. Then you're going to choose which operating system you want. Default is going to be uh Windows ext if you want to do a Mac operating system uh format type that you want to hack against or test against it's going to be Darwin. It's not going to be called Mac. And if you want to do Linux right there, Linux. That one's easy with Windows. Uh if you want to do architecture, your options are uh 386 or have ARM 64 and AMD 64. These are going to be your three

standard CPU types. If you see anything else, why are you attacking it? That's my answer. And for your format, those first three that you're going to see are going to be uh .exe, that's going to be your standard pre-generated one. You're going to have your service file, that's going to be your better one if you're going to be wanting to run long term. Then you're going to have want to have a DLL. This is going to be more stealthy if you're going in. This one's going to be a bit better if you know in-depth operations as a red team operator. This is where I would recommend doing it if you're going to be doing months or uh

years, but just sometimes those operations can last that long. And for the uh the uh limit function, this one I haven't really seen people use personally, but it's pretty good. It's the if then statement of sliver. If this file exists, do not run. If this user is online, do not run. If you know an administrator is online or a sock analyst is online, do not run. It is great when on the field. I've started using it and every time it's helped me immensely. Now, like I said before, it's it's it's so hard to generate a beacon file. You just type generate beacon d-protocol IP. You don't have to say what format. You don't have to say well, you do have to

say what uh protocol. You don't have to say a format. You don't have to say an architecture. You don't have to say an operating system. That is where you are done. If you want to stick to Windows and basic CPU types, if you want an executable, you are done here. But you can add more with evasion. It's you're going to see in a second here it's going to say code offiscation turned on. That's what it's called. Yeah, symbol offisation is online. That's where you're going to do that. You can use d-s or - save to save specifically somewhere. And you can just use d- format for whatever tech you're using. It's going to look like this. I will say

what order you use it in is unique. It is specific. If you use it in the wrong order, sliver doesn't always start for you. It doesn't always generate it for you. Now, let's do get into who's stopping you. This guy, this this is the biggest pain to me. He will always make your job the hardest as a operator, but he doesn't know everything. He doesn't know what you're there for. He doesn't know what you're doing. He doesn't know that your job is to make him not work. And Antivirus's goal is to have a basic few checks to make sure that you can get in. For standard installations, it's going to and a standard run. for executables.

It's going to have a little bit of a sandbox there. It's gonna make sure that, hey, what are you doing? Does it look normal? If it does, awesome. But it's going to have a sandbox to make sure what you're doing is good. It's going to have uh hoyeristic detection. It's going to be it's going to have a basic database of what it knows is bad and what it knows is anomalous activity. It's going to be going through the standard checks and procedures of, hey, why are you wearing that hat? Hey, why do you have a why do you have a shirt saying I'm going to steal your stuff? This is where that part is important.

And then you're have signature based detection. Why does your malware look like malware, my guy? That's how I would phrase that part. Your malware should not look like malware in the basic way, sense, and possible. I can say that when you're going into a network, you want to look like Notepad. You want to look like a standard just program Trojans. That's my point. And with Windows, there is Amy. This is a anti anti-malware signature interface. This going to be Windows is recent recent but in the last like decade for antivirus evate or antivirus techniques. This going to be PowerShell antivirus. This is going to be profile antivirus. This is going to be an overall hub of where

is your weird where did hackers find a way out? Amzy patched that. This was Windows's Windows this was Microsoft's way of saying we're going to stop you. They didn't want to update Defender overall. So they added a new antivirus to stop you. Luckily sliver starts with signature evasion already. That's the cool part. Plus you have other things that can add more evasion for you. You have a tool like peas or you have donut. You have sharpshooter shelter. Exactly. Shelter. And I'm not joking. Still MSF Venom to this day works to evade antivirus. But in my opinion nothing beats homemade let's do some malware development. Now, if you know what a PE loader is, raise your

hand. Awesome. A good few of y'all. You all know this already. I'm sure you all have even done development of it yourself. But if you haven't, it is just going to be a basic software that loads your executable into memory. And in our case, we're going to be adding a little bit antivirus evasion in that method. Now, a few things to include. You can include some encryption and decryption on the go. You can include a little bit of uh delayed activation. Hint hint. You can add a little bit of thread hijacking. You don't want to spawn a process as a hacker because why is this random software spawning a process of notepad or calculator that looks weird. So doing

thread hijacking will just load it into memory just under the covers. Like it's way better in my opinion and it's easier. Then you have memory execution. Do not let your malware touch the disc. Do you do not want to leave artifacts behind on the field. Anything left behind is something that they can trace back to you. And overall, this is my version of a loader. I just went ahead and have it automated for myself. It takes the standard binary file generated by a sliver as a shell file. And then I run my loader and it turns it into an executable. And as it is important in my opinion, I feel like I need to show what happens

when you use a loader versus when you don't with sliver. As I said before, sliver has signature evasion only and it popped hot on that defender right there faster than I could talk. But if I use a loader, I can run it. I can I even add a little bit of code for that hint right there for my HTTP. And as I said before on the I didn't say before, but on the previous slide, sliver sandbox is six seconds. 5 seconds you're bad. 8 seconds you're good. That's the best way to describe it. I've been doing this for about a year now, year and a half for using this method. This has gone past that sandbox

every time. Yeah. Oh, yeah. It's stupid. Yeah. Now, I'm sorry, but I will say if you're here and you don't know how to hack, initial access is out of scope in my opinion. I'm not going to teach you how to get into that guy's network off of a simple thing. But as a hacker, right teaming is always pretty good. Sliver does not come with a method to generate with as visual basic or power shell. So, you have to program it that yourself. Good luck. Welcome to Storming the Castle. We're going to hack that guy right there. This is where we're going to be taking what we've learned, what we've generated, what we've made, and using it

to compromise a network on a level. When you run Sliver, when you run your beacon, when it's generated, when it's auto run, this is what it's going to look like. It's going to be taken and it's just going to pop hot on your terminal. It's going to show up for every operator that's connected. you're gonna when everyone gets it back, they might be doing their own thing and then they see that and they might go, "Oh, let's go. He did it." That is a great part of that uh mentality of going through as a team where one of y'all is spending minutes, hours going through. You can connect to that beacon that you just ran on that system. You can run who

am I? Yes, I did make it my own name on that system. Don't judge me. Up to my favorite part of Sliver, the armory. Now, I know some people die hard saying, "Oh, you need to make it yourself. You need to make your own tools. You need to make your own malware. I'm not like that. That's not what the beginner, that's not what Johnny Smith hacker one is going to do. That's going to be the person who's going to be if you're at that level. I understand. But I've seen a few adversaries, a don't do that. Some of those people that are targeting networks, they're just using an AI to make their own malware. You need to be

better. So, what Sliver does is you can install every part of your malware. You have 150 tools that you can install that you will use as a Red Hat on the go. These hatchers use the exact same tools. These use the exact same formats and they use everything just like you. You can type armory install all and have 21 profiles and 150 tools. You want to do a ker roast, type kerarost. It's that easy. You want to do a sharp dump with uh for blood hound, you type uh sharp hounds 3, you're good. You want to find every vulnerable certificate for a service, you're good. You type certificate find or certify findvulnerable. I'll show you what that

looks like here in a minute. But I cannot overstate how much tools, how many tools come with the Armory in the system. It is amazing. And as I said before with the make file, you can add your own. If you're thinking, I want to add my own tools. I want to add my own malware. Using that mate format in the vendor catalog will install that for you. It's amazing. Yes, I did include a meme. So, you got in. So, you made your payload, you made your you set up your server, you connected your profile, you even were able to uh infiltrate your malware onto the system. You even ran it through the loader and you got a

connection. What now? These frameworks are called post exploitation frameworks for a reason. Post exploitation. I'm sure we all know, but just as a refresher, it is what you do once you're in. This is a part where no hands all bets are off. This is where there should be no handholding. You need to you are now under that guy's network. You are now under the wire. You need to be as evasive as possible and you need to be careful. This is where you are going to light up like a Christmas tree. Be safe because when you're going through everything you do has an action on that network. You're not on you're not physically there. So every time you

do a beacon tenant, you light that thing up. Now for post exploitation, there's two things you can generally do. You can either go up or you can go around. That's thinking taking over a service with privilege escalation, taking over an account. This is where you're going to be doing a little bit of uh internal tinkering. You're going to be attacking a specific profile or doing overall profile enumeration. This is where you want to hack. And it's it's not really in-depth, but lateral movement. This is we're going to be moving from one host to another. It's important to do if you as a hacker, some people will say why. If you needed a why, you were never a

hacker. The goal is to make sure everything is done and complete unless you have a specific goal in mind like a red teamer. So, as a hacker, I'm sure we've all made our own checklists. I'm sure we've made our all our own little like notepad for like, oh, what do I do next? What what's my skeleton checklist look like? But these are the four mentalities. Enumerate locally and check out your network. What services are open? Check out the surroundings. What's on the network? What's your architecture for your enemy look like? Well, for your target, let's not say enemy. We're redteamers here. And then overall, look for easy wins. Sometimes they are just right there. If you've done hacking,

you've gotten an easy win. Maybe you've gotten uh domain admin in 20 minutes. It's been that easy for all of us before. Silver comes with a tool for every single one of those. It comes with certified, it comes with sharpound, it comes with rubious, and it comes with seat belt. If you've done Red Hat, if you've done tools like this before, you know, I see you shaking your head. >> Exactly. It does. You can privilege escalate just from everything with seat belt. If you you can find everything with seat belt that once again I'm going to call back to where I said install it differently with mate file with the mate file you can change how it looks over

the wire I recommend that version if you truly want to be evasive as a red team operator and for every single one of these I'll show you how to do it for seat belt it's as simple as just typing seat belt on it I'm not joking uh what are you testing against you're testing about the host itself you're testing against us local user accounts uh with seat belt You can just run it and you can just do any type of item. You want to do a PowerShell history, it has that. You want to do Chrome history, I'm not joking, it has your internet browser history, you can grab that as well. You want to do test

threads, cool, it has that. You want to search for uh files that have a specific item attached to it or a specific privilege attached to it that you know is going to be vulnerable, you can search for it with uh seat belt. My only downside for seat belt over sliver is the fact that you it doesn't have the standard seat belt-all format that you normally have with seat belts. But if you know everything, you can copy and paste, make a little list and do uh do it in uh quotes. For Rubious, if you know Rubious, this is going to be attacking your Kerros protocol. It's going to be your uh standard authentication protocol for Windows. Uh if there's a tit attack that

you want to do, if there's a standard Kerros attack you want to do, if you want to do a targeted Kerros, you can do it with Rubious. In two words, I'm not cheating, two words. Uh most of the time you're going to be pairing this with hashtag to crack a password. This is going to be downloading your kerros hashed password for an account with with the overall kerros. Be careful though. Make sure you're doing this dedicatedly. Sometimes accounts are going to sometimes domains are going to have honeypot accounts that you need to be wary of. So before doing this, make sure you enumerate for local users locally and find out if they can be cured

already. You're going to want to go ahead and run that kuros right there. You can do download and uploads through sliver. It's as simple as that. You don't got to choose which location. You don't on your local machine. You don't don't got to choose which type of system are we attacking here. All you have to do is download file and then I'm sure we've all seen this hundred times. Hasht little refresher, but just in case you don't know, it's as easy as just doing the standard download of the tool. You can do hashtag right there. Uh, something to note though, as I said before, I during a Pentest, I actually did get hit by this and I and I

actually did say, "Hey, good job." Uh, it was the first time I've ever seen it. They made a honeypot kurostable account just just to see if someone would try it. Huh? It's athlete. If you know security, this is good for if you're a blue teamer as well. And then for hack, what's up?

>> Yeah. Yeah. Yeah. Oh, yeah. >> It's awesome.

>> It's so cool. I I love when I see that on a for as uh for the defense side because I I do both sides personally. I love seeing that.

>> Yeah. Yeah. Well, as you can see, I was able to run hash with the 13100 service and then use a hash file that I downloaded from my to host and I was able to run that against the uh password file I have. It gave me my file and it gave me my password which was password one. Now, something to note with hashcat is it's only as good as your password file. If it has that password in there, you're good. If it doesn't, you it's going to be a bit harder and you can't you're going to have to brute force it. for certify. Certify is going to be attacking the ADCS, active referee certificate service. We're going to be

going against any certificate attacks that come with it. And certify, I will say it's good. It's not the best though. I know we have an ADCS talk later on with uh E uh ECS 1 through 8. And I recommend using part of this uh for that talk as well. With Certify, what it's going to do is you're going to want to pair with Certify- AD. That's going to be the modern name of that tool. With this, you can enumerate locally. With that, you can exploit remotely. This is going to be one of the better tools to use as a red team operator because for some reason to this day, we still see networks that just skip over certificate

service security. It's a bit deeper than it was in the last couple decades, but still pretty vulnerable. Be careful and make sure to do it right. At the end of the day though, certificate attacks will always get you next level as an operator. You're going to find deeper ways to compromise a domain and you're going to be able to escalate your privileges deeper than you've ever thought you could before. Here you can see the vulnerable names that I was able to compromise. It's as simple as that. You just take a template name and you run it against a certain profile that you know has access to it. You don't even have to have fully compromise that account. You just have

to know the name. Sometimes uh you can and use it to uh upload the privileges of a account that you want to attack with. So let's say you have an account that you have compromised and you know another account that you know has access to a vulnerable template. If you have access to that name, sometimes you don't even need a password. You can just raise your privileges here. Simple as that. That's where you're going to be doing that with certifi. Now I'm sure we all use blood hound. I'm sure we all have seen that recent update that they made. It's pretty cool. But sharpound is going to be essentially what you use to figure out what's around

your network. What's the architecture of your target? It's going to be show going to be showing you accounts. It's going to be showing you GPOs, group policy objects, and this is going to be showing you computers on the wire. It's going to be showing you your locally system local systems. And this is going to be able to fully map it out for you. Luckily, Sliver can just install all it automatically with all the different arguments that you need as sharp. Need nothing else. You just download that file that it has and you just throw it into your uh your binary for uh Blood Hound. I'll admit I did not have the time to show how to do that on the side. I did

not think I would have time, but I'll show you what Blood Hound looks on this next page. You can see where I was able to run Sharpound and you can then download it and just drag and drop it from the text editor or upload it as the terminal. So, what Blood Hound looks like. That's a bit brighter than usual, but you can see where you have your different objects. You can have your map of your victims. This is where you're going to see. Let's say you want to get domain admins over there and you have GPO-8. You can see that you need to go to CA users. You need a certificate user, certificate authority users. This

is going to be where it's best to take that route right there. Maybe you have compromised GPO_8. This is why it's better to use Blood Hound. This is why Sharp Hound is amazing with this tool. It can be hidden, can be used, and you can see every person that you want to compromise or can see. Let's say as the red team operator, you know that NY users has the target that you need to attack, and you're all the way up there as WA users. You know that you need to go all the way down there. This is going to help you figure out as a team operator, which is going to be your best attack path. You

don't want to be taking all day. You don't want to be taking every day. You want to take do this directly. Now, with Sliver, I can't go over everything I want to talk about. It is an amazing tool. The official SLendor Github page has so many modules. I can't even talk about them all. You just scroll and scroll. It has them all. I would recommend going into that and reading it and it will show you so many things that Silver can come with. And this also, if you are doing a make file, this is where you're going to be uploading your own. I c I didn't have time to talk about beacon object files or common object file formats but these

are going to be something that you want to go in depth more on as a red team operator o overall because this is going to be where you just go next level with the evasion this is going to be kind of where you're going to be talking more with pe loaders malware development I do recommend learning if you're a red teamer it's common knowledge it's standard I get that if you do not do red teaming this is the best thing to truly take that next step in in my opinion Now when I first took this when I first practiced this talk I took an hour 40 minutes for an hour practice. So I had to remove a few things. So reverse sucks

traffic encoding uh pivots uh stagers and cursed chrome. I don't know if you all know cursed chrome but that's going to be a cursed extension to have uh chrome be your command and control client and target. But with stagers, stagers are going to be an item that you can that you're going to install onto a target and that can pull the deeper payload onto you. And so, in my opinion, there's a lot more that can be learned from the official sliver-sh. I recommend going there if you want to really get deeper into this. It has tutorials, it has documentation, and has more stuff than I could ever talk about in an hour. As a little shout out, thank you so much

for besides DFW for hosting this convention. This is an amazing time to be here. Been here for a good few years. Uh something I'm been doing a group with. I've been doing a group with Hackers for Justice. It's a little group that goes against uh different uh groups that are online. It goes against it hunts down traffickers. It goes finds up pages online that maybe have an ad for not so legal content. And currently there is an operation that's been going on with multiple governments. We work with uh police departments, legal authorities, and governments to do the best that we can to help make the world a better place. It's entirely volunteer, but I do recommend it. And a little

shout out to Bishop Fox for making this amazing tool that I do not have enough time to talk about. And got to do the offices LLC. If you need a penetration test, reach out to me. More than happy to talk about it. And thank you to all the hackers who came today. Any questions? [applause]

Yeah. >> Uhhuh. Yeah. >> Yeah. >> Uh I tested it both and without it passed the evasion both times with a Uh yeah, I didn't need to. I tried it with both evasion generation and without it. And using a PE loader, I was able to

>> In that case, you are right. Less is more as an antivirus evader. If you the more things you have that to evade antivirus, the more antivirus you're going to pop hot on because they're going to be looking for that. So you're all right. Adding using a stager or using a PE loader is going to help you evade individ. Any other questions? >> Excuse me. >> Uh pretty consistent actually. I mean, >> yeah, exactly.

>> Yeah. >> Yeah. >> Yeah. Uh yeah. Uh the PE loader I customized uh does also assist in crowd strike evasion. Uh obviously I'm not going to show someone how to do malware development with my code. I don't want you just stealing it because that's me. That's mine. But Uh there can be uh items you can use to your loader to help evade crowd strike antivirus. >> I'm sorry. >> Yeah. Yeah. In the maid file, uh when you're doing the make command, you can go into the vendor uh page and you can write your own module. It's going to be doing it through a YAML file. Uh yep. Simple as that. [clears throat] Uh, have you ever used Cobalt Strike

before? Have you ever used a Cobalt Strike before orage or Havoc? Okay. Uh, if you It does have an execute assembly command where you're going to go in and you can choose which location you're going to be testing with. But if you do want to have it be set to a direct path to that location, there is an a pre-made file like free compilation you can say hey this is the location of it make sense

>> zero point >> Daniel Yep Daniel >> yep uh CRTO CRTO2 or uh uh red team operator and red team lead there they go in depth and they give you a lot of understanding on how to do red team operations for a using command and control. It is a great tool that I would highly it's a great certification I recommend. Uh recently the CRTP re got a huge update and that's also one I recommend. It goes in depth into antivirus evasion and but I would say as a hacker your knowledge is best. Get one certification get two certifications for red teaming but that's it. I I'm not trying to say any specific uh certifications, but a evasion

practitioner specific. Uh I can't fully recommend that one if you know which one I'm talking about.

>> I'm not telling you my personal choice, but the common answers are Notepad and calculator. uh since I do know an item that is a bit more secure and also is pretty well to hide under. But if you're going to do I >> no Yeah. Yeah, that's right. I remember reading about that and I didn't see that. But yeah, calculator >> Yeah, calculator uh is going to be the common answer that you see people use, but

Absolutely. There's uh >> yeah, there's Teams, there's Chrome, there's Discord, there's Telegram, there's

>> Absolutely. Absolutely.

Yeah.

>> No. Yeah, absolutely. I know some people do. I have not personally tested that myself. I'll say that. No. Yeah. >> Yeah, definitely. Cool. Any other questions?

>> That's a great question.

Uh the answer to that would be directly to that's why you use a stager. You have a stager payload that's inside your uh Trojan beacon that is going to call out to download the rest of your uh payload. That's why you use a stager. If you know that you can get in and use everything, uh you go, it's if you want to test uh everything, going all the way can work because sometimes you can go all the way. But if you know you have to hide in a a Microsoft document, that's where you're going to want to use a stager like that. >> Yeah.

Yes.

>> And you'll have all my answers. [laughter] >> This is the way we're going to do it. Uh, I have two minutes left, but let's do one last question. >> What's up? >> Uh, I'm actually gonna probably post them on GitHub today. Uh, so at the end of this talk on my official, uh, Jason hide my first name, last name, no spaces, GitHub. I'm about to post this talk. Any other questions or are we good? Awesome. Thank you all so much for coming. continue to be silenced. [applause]

Hello and welcome to Besides Dallas Fort Worth. We are beginning our second talk of the morning uh governing AI and emerging tech risk management in the age of chat GBT by Chhaturia Pandarangan from BDO digital.

>> [applause] >> Good morning everyone. I am Chhaturya Pandarangan. I am an manager in BDO's uh cyber security practice focused on cyber risk management and transformation. Glad to be here on a Saturday morning uh just after a Halloween night. So thank you for coming and joining the session. Today we are going to talk. Are you able to hear me or no? Speak up. Okay. Sure. Thank you. Good morning everyone. Can you hear me now? >> Perfect. Thank you. So we are going to talk about how to manage the risks in the age of chat GPT where we are hearing about AI, how to manage AI, where are we going to head with the security? Are we

even considering cyber when we are talking about AI tools? Are we adopting AI securely? And if so, what are the risks to consider? What are the areas to look at when we are adopting AI in university, in organizations and everywhere else in our day-to-day uh lives maybe. So that's what we are going to talk about today. Um we'll have a detailed question and answer session towards the end. So if you have any questions, comments or if you want to discuss some new perspectives, we are all here and then we can discuss during the session or just after that. So with that we'll start the session governing AI and emerging tech risk management in the age of chat GPT.

Today we are going to cover uh not a lot of things maybe five things we are going to talk about why AI governance matter. uh what is it to consider when adopting AI? Why is it uh why does it matter? Anyways, we are going to talk about key AI risks. What are the risk that we haven't seen in our traditional uh IT information systems? So, we are going to talk about that. Then we are going to cover how to manage the AI um risks that we are seeing. So things like um are there even governance framework that has already uh been addressing the AI risk. We are going to talk about all those frameworks that are available till now

and the thought um that is getting evolved as AI is getting evolved. Then we are going to talk about how can you adopt AI securely balancing the innovation aspect and also not um forgetting about the accountability aspect. So these are the things and then we have a summary then that's how we are going to plan the session. Any questions before I begin? Am I audible now? Perfect. I don't have to talk to you about um the benefits of AI. All of you already know about it. It helps with productivity. It can help you create content. It can help you with your day-to-day activities. It can help you with writing emails faster, efficient, without any errors. So, it

boosts productivity. It helps with a lot of things. And all of us are using AI in our day-to-day life already. So, I don't have to talk about benefits. But on the flip side of benefits, there are a lot of things that AI offers. Um, the risks that comes with all the benefits. So, it's not just the benefits, but also the risks that comes with it. So the the premise uh what I want to highlight today is that AI needs to be managed and the management is not like how a traditional information security or in information systems are managed because AI is threatening the traditional risk management models. the the very way in which an AI system is

designed is different from a traditional information system. So it is threatening the traditional riskmanagement models. So that is what we are going to talk about. Um and you also know that just like the pirates and ninjas, you have AI threatening the current risk ma management models, but at the same time it is also helping with um information security. So when you all talk about an traditional information system, there is input, there is processing and then there are there is the output. That's the traditional information system. But when it comes to AI, these three uh elements or these three components are fundamentally different. In a traditional information system, input generally is definitive. You know what kind of inputs are accepted by a

traditional information system. If you're talking about uh Uber, then you know what to enter as inputs. If you're talking about a PowerPoint, you know what kind of inputs go into that. But in a in an AI system, it can accept a number of things and it is not definitive. So the the promise of a definitive input for an AI system is different than a traditional information system. So the risk that comes with that is also different that we haven't seen before. When it comes to the processing side of it, the second component in an information system, there are a number of things that every information system is designed to and it will produce exactly same kind of

outputs. But in an LLM or any any AI tool, we really don't know how it works. We know that it has a brain. There are neural components to it. It can predict but it is not easy or it is not 100% accurate to know how it generates what it generates. So again there is a bit of confusion or ambiguity or there is no 100% clarity into how an AI system processes the inputs that it processes. Again there are risks that comes with it when it comes to the output. For an information system you really know what an output uh comes back from a traditional information system but for an AI system you really don't know even

if you give the same kind of input to the same AI system depending on when you give it depending on the context or depending on how the AI system learns the output changes. So there is also the the definitive nature of a traditional information system is challenged there. So the the that's why I said for a information system the traditional riskmanagement models do not directly apply to an AI system. It will help a number of things for risk management professionals but they are they are also being challenged because you really don't know how to manage an AI system because the traditional models no longer work. So how can you solve this? It is an impossible

um situation for many but you have to solve it. How do you solve it? That's what we are going to talk about today. So on the right you will see information security objectives the CIA triad I don't have to explain a lot you are all experts you know about the confidentiality the integrity and the availability triad on the right that will cover um when you are transmitting any information to an information system it should be confidential the the information should not be altered the it the system that you have designed or somebody else has designed should be performing it should be available when it is receiving a request and also the integrity should not be compromised. So

the CIA triad we all know about it when it comes to the AI control objectives the key AI control objectives are the trust ethics and explainability. So these three things are different from an information system. I'm not saying that the CIA triad is not applicable in an AI system. What I'm trying to say is the three new things, the ethics, trust and explanability parameters are new in an AI system. So what are these and how to solve for addressing these three control objectives? When it comes to trust, you have to trust an AI system to some level of accuracy. There should be kind of reliability when an AI system is being deployed. For instance, if an AI tool is

implemented in a financial services for loan processing, it should be able to identify the criteria to categorize a loan applicant as an approved one or a rejected one. It can be based on income, it can be based on credit score and many more things. But it should be able to perform that function reliably and predict the outcomes reliably. But if it is not performing then the trust factor is compromised. That is one key principle handling the AI system. When it comes to ethics, ethics um the the literal meaning of ethics all of us know. But when it comes to the AI system, it should be designed in such a way or it should be performing in such a way that

the ethics principles are taken into consideration are applied and no discrimination happens. For instance, if an AI tool is deployed in a human resource department within an organization that tracks the applicant and see whether the applicant is fit for a role or not fit for a role, then it should not the AI system should not discriminate based on age, gender, race or any other factors uh that will discriminate a group of people from not getting selected or getting screened to do the job. So ethical considerations are very important in an AI system when it comes to the design of it. How the learn how the entire system learns it. The way an AI system produces the

output. So ethics is another consideration. The third one is explainability. So AI provides you the results. But do we know as humans whether the kind of uh conclusion that it derived from is what it is supposed to do or how it came up with that conclusion. Uh I can give you an example in a health care system where a AI tool is deployed for uh a patient diagnosis for a preliminary diagnosis and if the AI system is saying that this patient is diagnosed with ABC How did it derive at that conclusion? Did it take into consideration the test results, the blood report or any other markers, the symptoms? So the doctor who is reading the initial uh diagnosis

should be able to understand how the AI system produced just like how a a new doctor will give to their seniors. How did they derive at this conclusion based on what factors? So these three system these three principle make up the core elements of AI when it comes to managing risk. So the trust, ethics and explanability. These are not present in a traditional information system but these are the new things that a risk management professional should solve for when deploying any kind of AI tool into their organization. any questions?

So based on uh what we already know, there are a number of risks that comes with AI. I don't have to talk about data leakage. So there was a a recent situation in my organization where they just uh in my client organization where they deployed AI tool without taking care of the security related situations. And what happens was that there was an intern who um maybe out of curiosity or just to try out the systems, he typed in how can I get the salary information of the CEO and since there was no information protection, access control, any file sharing restrictions put in place, the intern was able to see the CEO's salary right away. It is the intern is not supposed to say

it. The organization did not take into consideration what SharePoint or what kind of folders are accessible in their AI tool. Everything was open to everybody. So the information that they are not supposed to see they saw it. So data leakage is a key AI risk. The second one is model bias. when it comes to model bias uh as I said ethics is a key consideration. So if you do not take into consideration while training the LLM or training the input set there could be inherent biases within an AI system and that could complicate the output that could question the integrity that could question the the trust factor within an AI. So bias as we all know it is another key

consideration key AI risk when it comes to ethical oversight. If you don't do it then there could be a lot of discrimination that can come up as outputs uh in in the AI model. it can classify or it can uh not select any uh person or any group of people because ethical principles were violated. That is also another uh key risk adversarial attacks when it comes to cyber security kind of thing. AI is a great tool. It can help with faster threat detection. It can help with um you know detecting fishing emails faster. All things are taken into consideration from a defender point of view. But at the same time for a threat actor AI is helping too. It can create

faster attack vectors in an accelerated it can launch attack vectors in a very accelerated manner. It can help with creating sophisticated social engineering campaigns without uh taking too much time. It can help with a lot of things. So adversarial attack just like how a defender is uh favorishly fighting for safeguarding the information system in an organization. The threat actors are also working extra hard to launch a very sophisticated campaign just like a human will do. Maybe the voice simulation, the action simulation, all those things can happen. So adversarial attack is also a key risk from AI. The second one is privacy risk. Just the example that I told you about the salary information getting leaked. So if you

don't have your guardrails on, if you don't have the right access control, then privacy is compromised. Your key information like your SSN number, your driver's license, your health information, your salary information, your your family personal information. It's all up for take. And just if you have to scan the dark web, you would be amazed to see how much of information is up for sale. And if you take into consideration the the fundamental controls, if you understand what it needs, the the basic cyber hygiene, those things can be um can be managed too. Then the data quality and integrity. Again, it is very important to know that the LLM systems learn from what it is getting um

what it is trained on. So if you don't provide the right data, if you don't provide the correct information, unbiased information, then the AI systems won't have a surprising result. it will learn from the same thing. So data quality and integrity issues are also a key risk from AI. These are the things that needs to be addressed for a riskmanagement professional or organizations when it comes to adopting AI tools. We spoke about the risks. We spoke about how AI systems are different from a traditional information system. There are a number of uh thoughts around how to manage the AI system. One from the NIST family. It's the NIST AI RMF, NIST AI risk management framework. The next

one is the ISO 42,0001 AI management system. Just like how you have the ISO 27,0001 for information system then you have the CISA guidelines for secure AI development for organizations who are developing AI tools from scratch. It's not the consumer aspect but it is the one who are producing AI on its own. Then there are uh schools of thoughts from Microsoft from Google AI and then of course you can ask Jenna about AI about how to manage risk management for AI. So these are some of the most popular um management frameworks to manage risks coming from AI. I'm going to cover in detail the NIST AI RMF because I feel that many of the uh

concepts or how to manage AI risk in these frameworks are fundamentally the same. It is going to talk about how to do the governance, how to safeguard the processes, how to safeguard the technical controls. There are nuances when it comes to if you are an AI consumer or if you are creating AI tools but I don't want to delve that into that topic uh deeply right now. I'm going to cover from a very high level perspective on how to manage AI risks for risk management professional without getting too much into the technical details of it. So when it comes to the NIST AI RMF framework, we are going to talk about four pillars. The first key pillar is

the govern function. The second one is map. Third one is measure and the last one is manage. So when it comes to the govern, govern is a fundamental uh domain or pillar in managing AI uh risks. So any risk coming out of the AI system. So when it comes to govern we are not talking about the sophisticated technical tools but we are talking about the hygiene factors. So many many of us would think that for AI security or managing the risks coming out of AI you have to have more tools you have to have more technologies deployed. But that's not the case for AI. It needs to be a balanced approach coming from governance side of it,

coming from the organizational side of it, the people side of it, uh then the physical security elements and also the technical controls. All of those things come together will only be able to address AI risks um in an effective manner. So, govern has a number of things. So govern starts with identifying who are the key people responsible in an organization. Who is accountable? If something were to happen from the risk coming out of AI, who is responsible for it? Who is accountable? Who is deploying the kind of tools? Who are the end customers? basically having a map out on the what we call as the traditional racy metrics on what who are the stakeholders basically external

stakeholders internal stakeholders it can be anything so having an AI ethics committee or an AI committee is the first starting point for govern where we have uh representatives from cross functional groups such as data security legal ethics HR technology teams and they all come together and talk about the implications of AI from their uh department perspective, their organization unit perspective and having that uh ethics board or an AI committee is the starting point and within govern the other thing would be having those roles and responsibilities clearly documented. uh talking about the roles and responsibilities another fundamental aspect of govern is to have the policies put in place correctly. So when it comes to policies the information security

policy the AI policy the employee ethics policy the use of AI uh and the protection of AI tools all of those things. So when it comes to policies, not just drafting policies is enough, but it will also to follow up with the clear enforcement whether the policies that are written are correctly documented, correctly enforced and operationalized. So for a govern it should talk about not just having those structures in place but it should also follow up with very effective implementation of the policy statements. Also I wanted to touch upon in govern the risks coming from third party vendors uh suppliers that could affect an organization. Say for instance the recent AWS incident. I was uh trying to call progressive our

insurance and um they said sorry ma'am we can't serve you today because our AWS system is down. I'm sure at least some of you in this room would have had similar experience with AWS last week. So the risks coming out of third party even if they are um helping with any AI tools because Adobe Microsoft in all their tool sets the productivity suite the copilot everything has AI plugins now so the when you're considering the risk elements it's not from the internal side but also from the external side that you have to take care and so if you are doing the correct due diligence from them are you able to see what kind of safeguard the third party vendor is

putting in place. All those things have to be taken uh care of in the govern pillar. The next one is map. So when it comes to the map side, we are trying to talk about it's basically mapping out what is present in your organization from an AI perspective. Are uh are employees able to go to their browsers and uh look at AI tools? Can they adopt uh any AI tools without an admin's permission? Can they go to browser, put in their organizational email ID, password trying to experiment with any tools like the chat, GPT, Gemini, Claude, all of those things without without any restrictions. So what is the attack surface looking like? What are the AI tools where are

those adopted? Is it uh browser based or can they have executables? Are they sharing information confidential to the organization? Are they able to upload files without any restrictions? So understanding the attack surface, understanding what is the kind of AI exposure any organization has. That is the second part when it comes to managing AI risks effectively. So map is a fundamentally what you're trying to see is understanding the attack surface and trying to getting an inventory of the AI tools internal external where is it adopted and things like that. There are tools in place that can help with getting this. So things like uh perview Microsoft purview is a great tool. Things like u data security tools like

veronus can help with uh configuring these things effectively. Then AI trism as they call it to manage the threats coming from uh AI that can also be an effective tool in mapping the attack surface from an AI perspective. The third pillar is measuring. So you have mapped it now you have to measure whether it is actually uh performing the way it is supposed to u perform. So conducting vulnerability assessments on uh AI tools having a penetration testing done to see that are you able to break through organizational defenses with uh the AI tools in place. Are you uh secure enough from a data security point of view? Is it encrypted? Do you have operational metrics that can help you

with uh understanding the kind of uh uh the performance that an AI system is doing? Are there any variations with respect to how the LLM model is trained? Like uh is bias introduced? Are there variances deviations uh from what the LLM systems learned in at the beginning of deployment and after it learned through the organizational things? has it changed fundamentally or is it remaining the same? Is it resilient enough or uh when it comes to data sharing the considerations include are you able to excfiltrate data out of the organization? If so, can you track it? Are all the activities on the browser identified? Who is responsible for what? All kinds of metrics should be tracked

within this pillar of measure. So the first one is setting up everything like your organizational structure, the governance structure, the policies and everything. The second one is mapping. So basically you are trying to take an inventory of the AI tools. You are trying to uh get an understanding of the attack surfaces that comes with AI and then you put all the defenses that are required to safeguard. The third pillar is talking about the measure where we are measuring the metrics. We are measuring the effectiveness, the design, how well it is designed, is it operating correctly and all that. And the third, the last one, the fourth one is talking about manage. So it is about the

sustainment aspect of it. So like I said at the beginning of uh the session, AI systems fundamentally differ from a traditional information system in the sense that it has a brain. It it trains and can produce different results based on the time, the context, the personality with which it's interacting. All those things can change. It's not definitive. So it is very important from a sustainment perspective to manage the AI system. So when it comes to testing the AI system uh in a routine manner to see has the weightages changed in the training model, can it um can somebody intelligently put any uh inputs that it will accept and produce a result that it is not supposed to produce?

Are the ethics principles compromised? Uh do you have all those fundamental things put in place? That's what the manage pillar is talking about. So the AI risk management framework is one of a popular framework that uh many organizations are adopting when it comes to managing the AI uh risks. So it will cover everything from third party security ethics explainability

explanability. So all those uh domains that I spoke about uh these four pillars will address the core principles of AI, the ethics, trust and explanability. Any questions before I move further or can we park it towards the end of the session? Okay. So the next topic that I want to cover is balancing innovation and accountability. So there were interesting conversations from some of my client organizations that they say we have taken a business decision to not adopt AI for the next 6 months. We are going to sit tight not making any changes and then we will adopt it later. But the funny part is you do not have the control over whether you can uh stop

adopting into your organization. It is going to come anyway. It is going to come in one form or the other through tools, through plugins, through the existing third party vendors because they are not going to uh you know push back on AI. All organizations are going full steam ahead with AI. Maybe the results or the return on investments they are questionable and we'll know about it sooner than later from the big uh companies sooner or in the next 12 months or 24 months. So what I'm trying to say is there is no stopping of AI. It has to happen and it is happening. The only thing that is in our control is to balance the innovation aspect of it

along with having the accountability element. So this could be a good framework for organizations when it comes to governing AI. There are four key elements. This is a little bit of uh technical flavor to it. Four elements that all organizations can consider when they are adopting AI system. The first one is having uh a digital workplace segment where it is talking about having a product owner. remember the responsibility point. So everything to do with defining an owner, how are you enabling it uh having socialized thing adoption and most importantly the change management aspect of it. So even if you are adopting AI tools, it should be done in a responsible manner. So the change management starting with uh what kind of

tools are adopted verifying third party controls implementing it and rolling out to a small group of people like the co-pilot uh phase roll out all those things are important and there should be a a digital workplace uh team that will manage this from an AI perspective. So that is one. The second one is data security element of it. So we are pro giving additional responsibility to the information security folks in in any company and data security will starts with classification of sensitive information. So masking things like SSN numbers, driver's license, your health card information uh and your critical medical information all those things should not be available to everyone. There should be restrictions around where it is kept, where it is stored,

who can access it. So the data security controls begins with classification of what is considered as sensitive and then moving to the advanced elements of it including data loss prevention. So um there are many tools that are already in the market that covers the data security elements of it. So starting with um implementing something as basic as a Microsoft defender uh for the endpoint detection and response or any antivirus tool in all devices that are manage that are using AI tools is the first step. So I don't think anybody operates uh their machines without an anti- virus or an anti malware tool. So that is the first step for data loss prevention so that you

know what kind of interactions are happening in the machine and then you can put restrictions maybe a browser based restriction or uh a device based restriction all those things. So the data security team is critical because you cannot have AI tools in place without a good data security hygiene. Your data should be AI ready otherwise the security elements of it has gone for a toss. So data security is very critical. The third one is identity and access management. Like I said at the beginning of the session, interns are not supposed to access uh CEO's salary information. So you should be able to define access management principles based on roles uh what who is responsible for what and what kind of

information they have to access for performing their job duties uh effectively. So talking about uh conditional policies talking about time bound access say for a contractor if they are coming in and for only uh three months then you will only provide access for those three months and then if somebody is retiring from the organization getting terminated then that access should be revoked ASAP. Those are fundamental security hygiene practices all those things should be carried just like how you do in your current environment. then contextual access. Um these are all new things uh that are already um many of the security tools have in place depending on what they uh what they're trying to solve for. So um if somebody is logging in

from um say India today and then tomorrow the same person is logging in from Russia or any other country where they are not supposed to log in that that's not the usual pattern then there are tools in place to identify that to alert the right people so that the risk is getting elevated hey do you want to see this so the things around insider risk management data loss prevention conditional access and all those things are also very important in managing AI security. The last one is compliance and uh legal. So talking about the ethical elements of it, the uh legal implications, the regulatory impacts all those things and I think uh the legal compliance they are the experts. So

having those is also very important to manage the AI risks effectively. So what I'm trying to say the key takeaway here is that establishing a crossf functional team starting from the AI um starting from the security starting from the HR legal the executive management maybe board of directors is very important in having an AI adoption journey managed with the risks optimi optimized without that in place if you have AI tools maybe you are building your own tools you are taking it from third party vendor but if you're do not have the guard rails in place if you do not have the accesses managed uh the policies laid out correctly the disciplinary actions all of those things if you don't have it

then you cannot be in a good shape with respect to managing the AI risks uh effectively So that's it. That's all from my side. Any questions, comments.

[applause]

Thanks a lot everyone for listening to me patiently. You've been a very good audience. Thank you for coming on a Saturday morning. Um I hope you learned something from the session. Thanks a lot besides for the opportunity. Thank you.

Hey, good morning. Welcome. Uh, today we're here at track 1 11:30. Welcome to Bides DFW, of course. And, uh, I want to welcome you to this talk AD trifecta, ADCS, ESC1, and ESC8, and Shadow Creds, the pwnage of ADCS, MTA. Welcome, Matt. >> Thank you. So, appreciate everybody for coming. Um, it's my second time here at Besides DFW, so I'm I'm happy to be invited back. Uh, today we're going to talk about three different types of attacks on Active Directory and using Active Directory certificate service escalations. So, ESC1 ESC8 um, We're going to dive into a little bit of how you can add shadow credentials uh using certificates and keys so that you can have persistence in

the environment. So about me, I'm just some guy with a presentation. So that's why I'm here. Not really. I'm a security engineer. I work at Visual Edge IT as it's a nationwide MSP. I've been there for about three years. Um, I have a whole bunch of certifications and all kinds of different stuff. I was a system administrator for many, many years. So, I've got some Microsoft ones. Um, I mainly worked in the school and local government space before I came over to the the dark side of MSP. So, why did I want to talk about Active Directory and Active Directory Certificate Services? Um, here's some facts about it. So, according to Inspector Robs, back in 2021, about 85%

of all ADCS implementations had some type of misconfiguration. There's a paper that was published by them called Certified Pre-Own. If you've never seen it, I would highly recommend going and taking a look at it. There are multiple techniques now with Active Directory Certificate Services. I think we're up to like 16 different ways to escalate using Active Directory certificate services, but I wanted to talk about these two in particular mainly because these two I have seen attackers use in real life attacks. So the gist of it is with ESC1, you're going to have forge certificates that you can take yourself straight to domain admin. ESC8, this is using NLM relay to go to the active directory certificate

services and possibly being able to issue yourself a domain admin. And then with shadow credits, that's backdooring the accounts, adding keys that probably won't get noticed and then you don't even have to rotate a password or if the password changes, you still have that. So, how does it work? How did or how does it work? ESC1 when there's a template misconfigured in active directory services that does not have a sand validation or allows enroll supplies subject is the actual attribute. It's going to be a bad day. ESC8 is when you use the NLM relay actually through ADCS web services to coersse a certificate out of the web services using the relay and then with the shadow creds as I said back door the

accounts so the password resets won't fix it. Oh, and I forgot to mention the shadow creds. I'm actually talking about an attribute in regular Active Directory that's called the MSDS credential link. Keep credential link. So, I'm late to the game on this. Somehow missed it all. That's my rant. Until I saw a ransomware group actually doing it, I didn't know anything about it. So, I'm not really a red teamer. I'm more of a incident responder or a blue team guy. So, this is just some of the stuff I learned. So, I thought I would share with the crowd. Like I said, there's 16 of these. I've only see seen a few of them in action um

from attacks that I've dealt with. You know, thank thanks for your attention. So, back to ESC1. what that is. Um, reiterating again, it has to do with the way that the SAN is configured in Active Directory Certificate Services. Um, how many of y'all know that you use Active Directory certificate in your environment? I'm not doxing y'all or nothing. I just want to know. How many [clears throat] of y'all have actually audited the certificates to make sure that you don't have any of these escalations? Awesome. Got a few of them. Sweet. So you guys probably already know. So if the certificate template allows you to specify your subject alternate name, that's SAM and ADCS is cool with it.

That's really bad. So around the time of that certified pre-owned white paper, a tool was released called Certify and its counterpart now is Certy. So there's two different ones. Um just so I I may flip them back and forth. Certify is the Windowsbased tool. Certify or Certify AD is the uh Linux based one. If any of y'all were in the talk earlier, that was pretty cool that that stuff's included in the SL framework. So, um ESC1, like I said, this is the most straightforward way to get domain admin, you know, just from a certificate template. Now, when I went to make this lab, I thought this was cool. I went to make a demo environment where

I could actually do this. So when creating certificate template and setting that setting to allow the enrolly to supply the subject alternate name was granted with this big giant window that says this may be bad, don't do it. So combining these options may create security risks, but I did it anyway just for this. Now, another thing that I wanted to mention on this, um, it doesn't mean that it won't let you do that. It also doesn't mean that you didn't inherit a server that already had this. maybe an older 2008 or 2012 that got upgraded, you know, at Nauseium kept certificate services. So, if you haven't looked at the templates, I'll show you how to do that

here in a minute. Now, where I've seen that um is usually like Wi-Fi enrollment type certificates using trying to use 8021X allowing the computer to say I am this computer. All right. So, how do we do it? ESC1, you need some type of lowprivilege user or their credentials. That could be a machine account if the machine account is allowed to enroll into that particular certificate. Um, this is just my example. I say that I already have the credits for Mac. Mac.local password. I can use certify ad find command to actually list out the known vulnerable templates. We need a little bit of information out of there. We need the CA name, right? We need the username. We need that DC IP.

I'll show on the next screen some of the output of that. And then once we find a vulnerable certificate that this user can enroll themselves into, then we make the request.

So this is what it would look like if you ran certified ad and I'm running just this is included in Cali. If it's not, you can just have to install it. Um you can also grab it off of GitHub and as I said there's also certify.exe um that you'll have to compile yourself if you want to run it on Windows unless you're using one of those C2 frameworks apparently. So you can see it dumps out text file. Just look through that text file and it tells you which ones are vulnerable. And that shows enroll subject. So we make the request. Sorry for the squishy thing. I just wanted to make sure it was legible. But you can see we we have this EA name.

We have the template name now because we just ran the find and found that vulnerable template. So, we need that template name. And then the thing that always throws me off on these is that UPN. Sometimes if you forget to do that, then you might uh end up with a certificate that's difficult to use. But you can see once it does the request, it'll actually just dump a PFX file for you. then you can authenticate with it. So this is an easy way to just grab the administrator hash. So I have now a pfx file. I went straight from a regular user to domain admin just by running one or two commands with certify. And then there at the bottom whenever

you authenticate using certify and use the pfx it'll it'll grab that admin hash for you so you can crash it. I mean crack it, you can relay it, just whatever you want to do. So the second technique, second escalation ESC8. So this is NLM relay to web enrollment. So this is a little bit different. It's a little bit harder, but it's not that hard. So I thought NLM was gone. Everybody was supposed to have NLM gone a long time ago, but we never did. It's still everywhere and refuse to turn it off because it breaks stuff. So, it's probably here to stay for a little while. So, I think this will be valid. So, the second step is we have to

coersse the machine on the network to authenticate to a web endpoint and to our relay. Certify again has its own way that you can set up a relay. So, certify- relay is the command. And at that point, If you already know the DC name, you already know its IP. You're looking for that serve cert finish and that's what we want to actually relay with our Cali machine. So why would we want to do this? Um well because it can bypass MFA. Um it's a certificate based enrollment. Ignores MFA. We're going to use that web interface if we know that it's there. So DCS issues the certificate from the relayed account which in most cases if

we're trying to do this technique we're trying to grab it from a domain controller if that makes sense. So we would coers the domain controller to authenticate and grab it certific. So NLM coercion there's a couple easy ways to do it. The pedit potam and coercer are really popular to do this. We use that coercion on the DC to relay to the web certs issued and then that that gives you domain admin access or access as the itself. And then the second part of that is actually the more commands that you use is the impact nm relay and then send that over complete that enrollment and then certify will do the same thing. It'll dump out a pfx and we

can use that later. So that's what it looks like setting up certify relay. And I think I'm missing a screenshot or of the other part of this, but you can see that the tool is built in and it does work.

All right, shadow creds. So this is like Certify is is just a really great tool. It just does a lot of stuff. So again, we're going to use certify ad. So requirements um to use or to create the shadow creds usually um admin is is what I would see or a user that can actually request certificates. So if those templates are missing then you may not be able to do this. But the idea is that we're going to abuse that MSDS key credential link attribute. Um, that's what's used in something like Windows Hello. We're going to attach public key in that attribute and then we're going to later use the private key that we created so

that there's no password need. And then that's the command certify- a shadow auto. basically the syntax to actually do it. Um there was a couple times where I did have to add computer accounts compromise but doesn't seem to be required all the time later authenticate and then that also persists even if you change the use password or you know after an attack they rotated the KRB TGT password all that jazz this will still

PFXs, what are they good for? So, like I showed earlier, you can use certify certify AD off, point it at the DC and actually grab the hash and relay it. Um, you can also use impact tools. So, if you do a get TGT using the impacted tools. You can export that, take that to your session, use a WMI exec or SMB exec just using that certificate get you that far. How many of y'all have used the impact tool set like Exc and all that? So, I'm not speaking Greek, but the gist is you can take you can take the PFX, convert it in a way to get the the Kerros ticket, and then use that Kerros ticket

and and those other tools. So, you're not just tied to certify anymore. And then this is what I was showing earlier. We've got a PFX that we use the shadow command. And then we use that to authenticate as domain administrator. Now this is because Brad said you asked Paige. So for what what can we do here for ESC1 the template misconfigurations need to check the certificate template name. Is there is there one that we know is weak? Um look look at that subject alternate name setting in the ES1 in the case of the ES1 template. Um also reviewing certificates does it have a different username in it that the person than the person that requested

it. So for example, if uh Joe at company.com requested a certificate for administrator at company.com, that's the kind of thing that we want to be looking for to make sure that the the certificates that have been issued are actually valid. The other thing would be checking the requester. Is it a regular user that is requesting a certificate? Is that normal activity? Do you have some templates that regular users use? Because if you see something like KBT is requesting a Wi-Fi certificate or something like that, huge hu huge red flag. And then also looking at the IP address of the requester. Is it coming from a server? Is it coming from a user's computer or a computer

name that doesn't make sense? Maybe they're maybe it's coming from a VPN subnet cough cough and then correlate the network logs showing connections to that search serve website and or any other strange places. So other thing would be checking for Windows event locks of ids 4768 and 4886. If you have found that you have a bad template, those are probably the event logs that you're looking for. And then you want to disable that enroll supply subject on any of the templates that you find. The other thing would be to look for changes related to event ID 5136 that are not related to user enrollments. This is for your ESC8 ones. So, like I said, strange

IPs for requesters that don't really make any sense requesting that template. And then another thing would be event ID 4885. This would be for a certificate template security was changed. So, that could be maybe they escalated your network in one way or another and then they're just trying to add a another way back in if they get kicked out. So you could potentially create an ES ESC1 vulnerable template and then just allow all users to to use it as from an attacker perspective. Then on the shadow credits, so we saw that we could add them certify AD. Now how to detect them? So first thing we need to look at um is the logs on domain

controllers. I neglected to mention here that um to find these logs on the domain controller, you have to have directory service access auditing turned on, which may or may not be turned on. The main event log that we want to watch with that is 5136. So this is what gets logged when someone uh changes an attribute in active directory. And then what we want to look at in that log, what was changed? That's that is what we want to find out. Um, if you see changes to the MSDS key credential link, that's probably not good unless you happen to know that you're in the middle of some type of Windows Hello roll out or something like that.

So, also who was changed? What was changed? Is it a high value account like administrator? anybody in domain admins, help desk, even the Kerros ticket account, service accounts. You wouldn't normally see that credential link on a service account. So, I see that a lot with SQL services and things like that. And then the other thing that you could look for is event ID 4768. So, that's the pre-op type for certificate log on. So if somebody has pawned you, you can actually find that event ID to find out what where all of the certificate logs are happening. And then this is kind of the end. How much time do I have left on here? We're approaching the end of the slide.

So why is this important? Um, it's a direct direct path for privilege escalation. It doesn't require any special permissions to AD objects unless you've already found some cool stuff in Blood Hound and you see that people have permissions to enroll in different templates. It's fairly easy to escalate with these techniques. So using certify AD or certify.exe and then ADCS and these attacks are much more common than you would think. So, this one's probably going to be a short one because we're already at the end. >> Sure.

Um, in my case it's usually post. >> So usually I'll I'll get a call something's already happened. >> Um, occasionally. So we we do take in a lot of data, bunch of different systems for customers that have things like SIMs. try to run down events like that. But not everybody has not every company has capability.

Right.

I love

Yeah, it depends on the customer. >> Yeah, everybody has something different and you know being from the MSP space, different customers may have different tool sets. So, I'll check out that Corite though. I do know heard of them and their demo at my homes. Any other questions?

Um, honestly, most of the time they're they're doing password sprays or using stuff that they found on the dark web already. Um, it seems to be the past year or so. It's all of these firewall vulnerabilities that that have been ad synced um and attackers getting in that way and then escalating from there. Um, the certificate stuff I haven't seen as much, but I have seen a couple groups use these two techniques in particular that and the shadow credentials I've seen before as well. Anything else?

Cry. No. No, look for all the all those things I was talking about. Looking for those uh credential attributes. Um and then in active directory certificate services, you can see what was issued. Um make sure that the templates are remediated to the best of your ability and then actually just revoke them. Then we should be pretty good on that. Obviously have to rotate the passwords on everybody doain admin, but

you could. Yeah. And that would be probably the best way to stop it before it happens. Um, so both of them have the capability to do a bunch of different methods, especially a coercer. It goes through all of them whenever you try to ride. So it is extremely noisy and should be detected if you have something set up like like he was talking about the >> RPC.

Yeah. And there's actually u if you look at the documentation for the pedit potam github and also on coercer there's there's quite a bit of information on exactly how it does the thing that it does but the gist of it is yeah it's nm and rpc

anything

Yes.

>> Yeah. I I actually uh tried to set up originally the game of active directory. I just didn't have all the resources for it. run the full one and then also I was using VMware Workstation which was not easy to get that stuff imported correctly. That was on my creat workst.

Well, I guess that's it. Thank you all so much for having me. >> [applause]

>> Welcome everybody to track one. This is the serverless meeting. If you're here for a different presentation, you're in the wrong room. So um I'll let these gentlemen uh tell you much more about serverless today. Uh Nimish Chararma is a cyber security engineer with diverse experience across health care, banking, public and telecom sectors, cross functional project guidance and stakeholder support. That's a lot. Uh security architecture, strategy, arch application security, predictive analytics, and enterprise risk management. adept at designing and implementing scalable solutions, driving automation and delivering quantifiable value and innovation. [laughter] And then your second speaker today is Siobhan Dar. With nearly a decade of experience across e-commerce, healthcare, gaming, open source, and cyber security in both large enterprises

and agile startups, Siobhan brings a creative solutionsdriven approach to complex challenges. He mentors cyber security talent, reviews research, supports tech for good initiatives, and currently leads cloud security efforts at JP Morgan Chase. Let's welcome our two speakers.

Thank you. All right, so let's get started. Um, I'll just like to talk about a scenario. Imagine how we deploy an app today in few seconds. How do you think that's happening? So there are no servers to manage, no infrastructure headaches anymore, and it's just pure code in motion, right? That's the magic of serverless computing. This one. Okay. Can I move it towards me? Okay. All right. So it feels almost effortless until it's not. Right. Because beneath that smooth performance is the hidden misconception that serverless means less responsibility. In reality, when we move fast like that, it is easier to overlook some hidden risks. And because serverless architectures are event- driven, they are highly dynamic. Defining and

enforcing trust boundaries is paramount. traditional security models that are built for you know infrastructures which last longer and not for ephemeral functions. The core of serverless architecture is different here and we will dive deeper into the attack surface for the serverless environment today. So with this in mind in today's session, Nimsh and I will help you navigate through the security in serverless world as risks still bite while the servers are not in sight. So before we dive in, let's take a quick look into how the infrastructure abstraction has evolved over the last five decades. I'm sorry. Please bear with me. Today I'm an active speaker. I just move around a lot. But today I'm little bit

confined with the mic not being able to move with me. All right. So as you see on the screen today uh we'll talk about the infra abstraction. Uh so computing infrastructure has undergone a massive transformation. We all agree to that from the physical racks in data centers to the invisible functions on cloud. The story begins with the bare metal era which was in 1970s where the mainframes the physical servers they kind of ruined you know ruled the world. IT teams were managing everything from hardware to networking to cooling and even maintenance. This setup was powerful but rigid. Scaling meant buying new pieces of infrastructure, new machines and downtime was common. Yet many enterprises still rely on this era

stability for critical applications. We still have applications which are on prem and they haven't moved to cloud yet. And as we move on to the early 2000s, we saw the revolution for virtualization where one physical server could now host multiple workloads. It unlocked better resource usage, faster recovery and flexibility. Tools like VMware hypervisors and later AWS EC2, they all changed how we thought about compute. Now this was the birth of cloud era. As infra became more elastic and scalable, applications grew. Teams wanted something lightweight, more portable. Why? because something works in my laptop but it doesn't work in image laptop right so then arrived the container evolution with docker and kubernetes developers could now package code and dependencies

consistently deploy anywhere and scale faster this was also the era of devops which was very common as a culture automation and microservices bringing that agility but also new orchestration complexity And then in 2014, AWS launches Lambda making the start of serverless era. So no more servers to manage, just upload the code, let the platform handle scaling patching execution everything. It accelerated the innovation but also blurred responsibility. Developers lost the visibility into what once was under their control, right? Serless brought that agility, but also new risks like the ephemeral compute, event-driven attack surfaces, which we'll dive deeper into, and implicit trust boundaries. So each layer of the abstraction made life easier yet added distance from the

underlying system. So the evolution from servers to no servers teaches us that you can outsource infrastructure, but never responsibility. And in the symphony of this abstraction, security and accountability still conduct the orchestra. And since we spoke about the responsibility model, this slide here talks about what as a customer we and the cloud providers should be responsible for in a serverless shared responsibility model. So as we see here uh we can talk about the traditional models like EC2, right? The split was clear. The provider secures the infrastructure which means the hardware, networking, hypervisor and we manage the OS, the runtime, the applications and the data. There's full control but also full responsibility for patching which means repay your

instances every 15 days but also full responsibility for patching, configuration and monitoring. While in serverless the cloud provider handles almost everything like talk about the function layer the servers runtime scaling and patching right I know I'm repeating these words but just to make it sound this is what happens but that doesn't mean that there is no responsibility for us we still own identity and access management data security and encryption code quality and dependencies configuration and triggers So the shift to serverless moves our attention up the stack from infra to logic and event flow. And the key here is to apply those dev secc ops principle which we need to again be reminded of which is validate your inputs, restrict

the IM roles, audit your configurations and monitor the function behavior. With that we'll now move on to the next section which is about serverless attack surface. So as we spoke about very briefly the event sources are your front door always right here attackers can inject malicious payloads via the APIs or the object metadata or the messages. It could be in terms of AWS it could be SQS. It could be an API gateway or other services. Now, because event flows are trusted, a bad event can trigger a chain of functions. So, what's the quick defense here? Validate your schemas at the edge and enforce event signing and origin checks as well. Double check if the request is from the trusted party or

not. Moving on to the second class of risks here, which is the function level vulnerabilities. Now individual functions often carry the risk from outdated packages to unsafe dialization. We all know about how vulnerabilities in third party dependencies can cause troubles to us and a single vulnerable library can lead to code execution or secrets leakage. So what's the quick defense here? Implement dependency scanning, runtime protection and avoid sensitive secrets in plain environment variables. Never do that. Moving on to the third class of category here for attack scenarios which is the platform misconfiguration. Wildcard permissions or public buckets let attackers pivot widely. We all agree. So there are guardrails in place to check whether a particular bucket

let's say is public should it be public or not. So misisconfigurations definitely scale the blast radius and as a quick defense we want to enforce least privilege automated config scans and posture checks which hardens your security posture. The remaining two classes which we will see are kind of subset to what we discussed already. Um so the fourth one being CI/CD risks. Your delivery pipeline is also an attack vector. If CI/CD is compromised, attackers ship malicious code or builds or insecure configurations at scale. So what's the quick defense here? require artifact signing, immutable builds and security gates in the pipelines. Block your pipeline if a infra piece is misconfigured. And last, monitoring apps. Serverless can definitely be noisy, but also blind

if you don't capture the right telemetry. Without distributed traces and retained logs, incidents are hard to detect. and investigate. So what's the defense here? Enable distributed tracing, centralized queryable logs and retention policies tuned for investigations. With this uh I would like to call upon Nish to talk about the some top three examples here. Yeah. Hi everyone. So in addition to the engineering piece of serverless security um a different aspect that we you know when we talked with professionals like such as yourselves over here was we found that another challenge in terms of you know having visibility into the different aspects of serverless security is the governance risk and compliance aspect. So a basic tenant of this session is

you know uh we know that serless doesn't just remove responsibility it more like shifts it. So um the challenge of the from the governance side and the constraints associated with the infrastructure abstraction within the serverless architecture risk assessments and building accurate racy matrices is you know something that came up time and again when we talked to the the GRC analysts working with the engineers in the within the serless space. So the table over here maps the three prominent impact high impact serverless risks which Sham talked about to two popular frameworks that I'm sure each of you would be using or referring to uh in your operations or in your work which is the OASP the open web application

security project top 10 and the CWE which is the common weakness enumeration top 25 frameworks and pairs these serverless based risks with concise mitigation steps that you can even take back and ship come Monday morning. So I'll be taking AWS as the standard CSP over here and just for the sake of reference but they're obviously replicable within other CSPs as well. The the first one is platform misconfiguration and with OASP we we mapped it with security logging and monitoring failures and in CWE it's insufficient logging. So in serverless the platform in itself is your run is is your runtime. Misconfigurations especially missing or weak logging turns incidents into silent failures and if you cannot see it you can't obviously

defend it. So for mitigation strategy first is capture the right logs by default. So you can do that by enabling cloud trail lambda and API gateway logs S3 data events and DPC flow logs for egress paths. Now enabling logs is just the first step and we modern one but but we also need to make logs usable. So for that we need to structure them say based on the principal role the request ID the resource uh the resource name and consolidate and centralize them into a seam solution which is a security information and event management solution. There are many popular uh you know options out there. So essentially they help with the detections uh and within the seam

solutions we can configure the different detection rules for anomalies such as spikes in the invoke function get object from new roles or any cross region copies or anything. Now, if you don't want to buy one, if you don't have a seam solution, Vazu in my uh experience is a great open-source uh seam solution, at least for the basic part until it gets paid. It's definitely better than Microsoft Sentinel based on my experience. I apologize if anybody uses that. So, next is runtime monitoring. So this can be achieved this is again part of the mitigation strategy and it can it can be achieved by configuring in the context of AWS cloudatch metrics and alerts for error ratios throttle spikes

cold start anomalies and fire alarms to on call and auto remediation runbooks. And as a reminder logging isn't just a nice to have. It is the control surface for foreign containments and documenting audit trails. Second is event injection or with OAS just injection it I think it encapsulates different aspects like SQL injection SSRF uh and within CWE it's the improper code control of code generation or just code injection. So now serverless apps are event fabrics that are sort of knitted knitted together using a plethora of different resources such as API requests, S3 object rules, u the simple Q service, the CQ CQS messages, scheduulers and other different aspects. Now each event is an ingress point and an event injection

captures the risk of unvalidated inputs forcing unintended behavior code paths or even straight up denial of service. Now mitigation strategy primarily revolves around configuring boundaries to enforce at the edge which can include schema and content validation at the API gateway security layer that can reject any say malformed JSON scripts any oversized payloads any rogue headers or any unexpected mime which is the multi-purpose internet main extension type before the function runs. Second is the strong identity configuring strong identity on events. It can be done by using a JSON web token authorizers configuring a mutual TLS you know if it's feasible for the transport layer or enabling signed URL or requests if you want to grant temporary say

access to file or any objects in the storage at the storage level. Now in in addition to the secure authorization, you can even use S3 event filters and referring to the least privileged notification topics to utilize attribute based access control. And another cool technique can be configuring the fail safely which can be done by using the DLQs, the dead letter cues on async triggers, item potency keys to prevent replays and rate limiter or any web application firewall rules for any bursty probes. Now the core objective is that if an un an if an attacker or a threat actor injects any malicious payload into the stream these boundaries they're able to stop lateral movement and keep the blast

radius small. Third is the vulnerable dependencies or in OAS vulnerable and outdated components and CWE is the use of unmaintained third party components which you know makes sense because it entails the entire software development life cycle. Now in serverless dependencies are the supply chain embedded with the lambda layers, container images and transitive packages. Now the OASP and the CWE controls point to components that are outdated, unsigned or unscanned. For practical hardening or mitigation strategies, you can utilize steps like either producing an SBOP with tools like Maven that can be done for to to produce an S bomb for like Java mainly and verifying signatures for images and layers or blocking any unsigned artifacts within the CI layer.

Next is a scan early and scan always. It's a crucial strategy for runtime protection. SCA or the software component analysis scans to analyze open-source components. The SAS and DAST, the static and dynamic application security testing scans for analyzing code functions before and after execution and image scans on pull requests. Now you can also configure fail builds on critical CVEes that are known and have been doc and have been you know uh documented within the CVSS database and scheduled rescans on a cadence conforming with your own sprints. A third can be the constraint egress and third party access strategy which this includes steps like VPC integration with egress controls, private package repos and scoped oath or API tokens.

It also includes secrets rotation either automatically or at a particular schedule or manually which is for you know effective privileged uh access management at the function level. Now, the overall result with these strategies is fewer moving parts, fewer surprises, and less attacker leverage through your build chain. Now, we've been talking a lot about the serverless architecture risks, its attack surface, and the governance aspect of it. But why why put an hour of your time which is a valuable time to one aspect of cloud computing as a whole. Now this section often gets the management's attention for any CIOS or CTO's out out here u because it this deals with the the economic aspect of the serverless

security. Now, we've established that serverless isn't a silver bullet and responsibility shifts. But what's the tangible cost when the responsibility isn't met? Now, if you look at this graph, it illustrates the rapid and exponential growth of the serverless computing market as a whole. And this is just subserverless. It's exclusive with or independent of the cloud computing market. Now, we're talking about a market that was just over around $19 billion in 2024 and is now projected to exceed by over 60 76 billion by 2030 with a compound annual growth rate of 23%. Now, this isn't just a trend. It's uh it it signifies a fundamental paradigm shift driven by benefits like we discussed which are you know reduced

development cycles faster time to market u and a huge portion of this almost 61% is driven by function as a service and which is why we often use the function as a service of fast and uh serverless interchangeably. So it's no wonder that you know it's a sort of like a fan favorite amongst the micro uh small and medium enterprises and even uh early stage startups and now even the larger companies have particular services like Netflix you know they use serverless for you know making more effective uh streaming and it's because of the fact that you know uh the cost savings that are attached with it and the ease of scalability and the shift of responsibility to

certain extent obviously. Now the growth however uh also magnifies risk. So the other graph is the projected losses due to serverless weighted breaches. This isn't just like a direct damage. It also includes the forecast the cascading secondary losses uh associated with a breach particularly associated in in tandem with the serverless. architecture. It can include anything from investor losses, insurance or legal fees and settlements, reputation damage or any external consulting uh costs. So obviously as the serverless market grows so will the losses by associated security incidents. Now which is what we have modeled into by taking these three scenarios which can which are sort of like stress tests in the form of base, high and high plus. And as you can see

uh you know from 2022 to till 2030 as the market grows the associated costs are uh with the beaches will almost constitute 1% of the entire entire serverless market. So now I think it's probably enough from our from our side and uh we look you know we'll shift it over to you you know what gaps and vulnerabilities you know you do you think are associated with serverless architecture either you have seen them in your own uh at your own workplace or uh you know in your own in your research. So if you can slide uh scan the QR code and you can provide your questions and they can sort of start coming up over here. So we give

you a few minutes for that. Folks, this is not the talk. We still talking but this is just a small activity you guys are doing and I hope you are doing your classwork really well. There's a bingo card. Whoever has it, please keep striking off the words which you heard during our presentation and we'll get to that later.

So, whoever submits the answer, yeah, it just shows up here. It pops. There's the emoji. Okay.

Does that mean you're human? Is a gap

people? That's right.

Oh yeah.

>> They had an outage too. Yep. Data leaks. All right. So while this is happening just a disclaimer we are not representing our employers today. uh this particular kind of a research was also published recently and the proceedings will flow soon but um yeah we were just trying to create more awareness around the topic gather some more insights from you guys and what we'll now shift to is something which is more practical and a little bit more interesting than the theoretical stuff which we just went through. All right. So the poll can stay open still. You can still answer the questions. But in the interest of time, we'll just move to the next slide. Um all right. So we have a case study

here which talks about securing AI workflows within serverless centralient analysis model. And this is the diagram we are talking about for few more minutes now. So what we did as part of the research we also added something called as our home lab setup which is links lab and what this what this does is it spins up an AWS stack for us wherein we can kind of work on a sentimentbased analysis model. So the components of the stack are there is a API gateway which allows users to pass in their queries. Then there are worker and authorizer lambdas in the back end which do the processing. We'll talk about that in a minute. And we do have the other components like the

secrets manager, the S3 bucket for logging and the bedrock model which is used to kind of generate the sentiment. So two key things here. One, the stack works and spins up something on an AWS account. So since this was research and not funded, we had to use the free tier account which is available and all these services which we have listed out here, they are all free to use. Uh now yeah and the QR code is for the repo which is also in the handouts which we gave to couple of you. Um now as part of that uh the bedrock model is something which helps us do the sentiment analysis and this is something which can be configured in your

accounts. So if you want to use llama as the model that's something you can select or there are other options which are available on AWS. So two key things to remember. One as I was mentioning that this is something which is pinned up on AWS account today. And the other thing is the intent is that we want to do sentiment analysis on some text which means given a piece of text is it positive, negative or neutral. That's the response which we'll get from the bedrock module. Now this is the lab setup and uh the GitHub repo as we were mentioning is part of the QR code. Um it is an open source initiative so any contribution is

mostly welcome and we would like this to grow up. Yeah. You want to Okay. So the next up uh what we have here is the sample video of how This tag gets spinned up, spun up, sorry. Um, so as you can see, uh, this is also available as a CLI. Uh, and we just run the driver main program with a keyword called create, which helps us create the stack. While the stack is getting created, we'll take a look on the AWS console as well to see how the resources are getting created. Now that we have an idea, a fair idea of the resources which we want to spin up, we will soon look at the console how each of the resource

gets created from the API gateway to the worker lambda to the authorizer lambda. So just to explain the difference between the two lambda functions what we saw earlier the requiser lambda kind of authorizes the incoming requests. So that's where we kind of add the checks in terms of who is authorized to call the API, right? So that validation happens at that layer and then the main worker lambda kind of takes the input coming in from the API gateway as part of the request and then calls the backend bedrock model to kind of get the response for the sentiment. So that's what the worker lambda does and all these requests and responses they get kind of stored in the S3 bucket and

that's why there is a connection from the worker lambda to the S3 bucket. So as we further see also apology this is a recorded demo so uh we didn't want any live things to not go well for us and uh what we are showing here is while the stack is getting created these are the different resources which get created on AWS console

and the next part is uh this particular setup which we just created also allows you to get the endpoint for the API gateway because at the end of the day you want to interact with the model that happens through the API gateway and the subsequent request which we do via Postman now shows how you want to configure your inputs. There are two inputs primarily. One is the input text which needs to be analyzed for the sentiment and the second one is the operation like you want to basically tell your bedrock model you want to do a sentiment analysis. So which also means that your bedrock model is generic enough to take any other operation which

you want to conduct and once you hit send it basically uh makes the API request does the authorizations in the back end and then calls the bedrop model to generate the sentiment and now within few seconds you'll see a response whether it is positive or negative and this shows the S3 bucket as well where we kind of record the requests. This is where the file gets dumped in. You can see the request logs and responses.

All right, moving on. So likewise, we also have a tear down option to bring the stack down because we don't want to have the stack up and running all the time. So, and also since it's serverless and also event driven, there are no requests coming in as long as no one is initiating any activity here. But what we also tried doing here is we kind of set this baseline model for us to kind of simulate attacks and defense scenarios. And to know more about that, again, Nimish will go through that slide and we'll see how the three examples we spoke before, how can those be modeled with the same setup which we just showed. So this is what the GitHub repo is for

uh which you again either scan on the bingo sheet or on the the QR code over here. So this is to simulate the attack and the defense scenarios. So the first the we had a short demo just for the configuration of the stack. Now this di modified diagram sort of highlights some critical attack vectors and risks within the very same workflow. So we want to draw your attention to three primary areas which is again we something which we discussed from the attack surface u in the context of platform misconfigurations uh that is our leading scenario. So which is on also on the top left. Now a discussion about the authorizer lambda and its policy effect. Now if that

authorizer lambda due to a platform misconfiguration returns say a deny policy to the API gateway, we will lose the observability of incoming requests to the lambda function which because of which the API gateway will deny the request and the authorizer lambda's logs will show it ran and it denied access. But the worker lambda is was never invoked because of this. So which creates a sort of like a blind spot and our security teams because of that they lose crucial visibility about the forensics forensics data and about the malicious request which can be either the full payload in this specific intent uh the the originating IP or any contextual information that the worker lambda would have otherwise processed

and logged. Now this isn't just a loss of logs obviously it's a loss of the ability to conduct uh a full incident response or an effective incident response response for that matter and to prevent future occurrences. It is also it can also be seen as a failed uh forensics scenario. The next is the function level vulnerabilities or in this case it's the leaked secrets. Now even if the authorizer lambda allows the request, our lambda functions themselves are not immune. Any function level vulnerability, say an injection flaw like we discussed earlier or any vulnerability dependency within the worker lambda could lead to lead leaked secrets. Now this might be API keys for the bedrock model. The S3 credentials

something that happened with a certain company uh that was pretty popular uh in which they basically left the uh the credentials for the S3 buckets out in the public domain and it can even be uh secrets for other internal services when pulled from the secrets manager. Now if an attacker gains control through say a remote code execution or by exploiting a vulnerable library those secrets are their first target. So because it allows for subsequent lateral movement or data excfiltration as was also mentioned by someone in the uh in the previous on the slide which causes obviously makes the archite architecture or the model susceptible for data leaks. Now third is the trigger risks or in our

context which is through the malicious inputs. The user's input to the gate API gateway uh is not just a benign sentiment analysis text uh it can even represent trigger risks and the potential for malicious inputs. Now this could be a command injection attempt, a SQL injection payload targeting a the backend database for say like a Dynamo DB uh in the case of uh our model or AWS if you're using and then further down the workflow uh or it could even be a prompt injection attempt designed to manipulate the model's behavior and prompt injection is even more uh more risky in that sense for the LLM based models that we that you know everybody's using now

uh in in production. This could read lead to extracting the training data uh elicit sensitive information or even bypass content filters. Now without robust input validation at every layer, these malicious inputs can trigger unintended actions or exploit vulnerabilities deeper within our workflows. So in summary, a simple platform misconfiguration such as that deny policy doesn't just block a request. It can create a black hole uh in our security telemetry which can lead to failed forensics and masking potential resource exhaustion if any denial of service attempts repeatedly hit the authorizer lambda without being properly monitored downstream. So this demonstrates that the serverless security isn't just about securing code. It's fundamentally about securing the configuration and the interaction

between these highly decoupled sort of ephemeral components. So now for the we are towards the end of the session we have our final takeaways and best practices [snorts] starting with the first one which is serverless doesn't mean clueless. We spoke about that a lot of times today. So you still identity data dependencies and configurations. >> What's next? >> Faster deployments or faster disasters. >> Exactly. Because you enhance your production pipelines. We are something we call structured velocity. >> Isolation wasn't just a pandemic thing. Because radius management right

boundaries matter validate inputs isolate events.

>> I think it's working. It's not a strategy. >> You need the traces that follow and across services and logs which can be lastly you lose the server not the responsibility. >> Y and serverless changes the shape of risk and your job is designed for failure and not sit back and relax. >> Thank you. >> That's the end of our session. If you have any questions, you

have any questions?