DevOps: Building Impactful Hacking Tools for Profit or Not

Thanks for the the the the kind introduction there. Definitely sounds way cooler than than what we really are. But uh we'll go and jump into it. So just really quick, we've got probably a hundred slides in here. We're gonna breeze through a lot of them, but it's a lot of content to cover in such a short amount of time. So, we're gonna export the slides for you guys to look at them later in a deep dive. Um, but we'll >> Don't try to take all the snaps as fast as possible. >> It'll be there for you. We promise. >> Discord. >> What's up? >> Besides Discord, >> uh, yeah, it'll be all over. We'll we'll

figure it out. They >> they give us a link to send it to. >> All right. Uh so about me uh based out of Newberry, Florida. So just about 2 and a half hours uh north of us outside of Gainesville. Uh together Ralph and I uh co-founded Mayweather Group LLC and VTEM Labs. Uh Mayweather Group kind of serves as our our physical exploitation brand uh where we manufacture and and sell uh high-end u badge cloning equipment for physical security penetration testers. um as well as do uh some training for for government entities as well as uh commercial uh vendors. Soft veteran uh love to do veteran mentorship. I've been in the uh security industry now um probably a little over a

decade. I got my first start at uh Fishnet Security after I stepped out of the military which turned into Optive. Led the attack and pen team there uh for a number of years and I've led some some smaller uh offensive security teams as well. >> All right. Ralph May. I am Tampa native here. Um I work with Travis. Travis actually got me started in cyber security at my first Bside Bides Tampa, right? Uh so uh started there. Um I've written wrote, excuse me, a bunch of tools. Um and uh I also uh co-e the uh physical exploit class. I've been doing um offensive security for about 10 years now and also an army veteran. So yeah.

>> All right, jumping right into it. So, we're going to talk about some of our our current projects. You get an idea of what we have developed and then talk about how you can start uh doing uh development or building your own tools. Uh and then we'll talk some some hardware engineering. Ralph will talk about some software development. Uh and we'll open it up for questions. So, some of our our current projects. So, uh as we mentioned, we have two companies. U Mayweather Group. So, our primary brand with with Mayweather Group is practical physical exploitation. A lot of this is embedded engineering, uh, 3D modeling. We'll walk through some scenarios here and how you can get going

with that. Uh, also we can produce our our badge cloning kits or badge cloning gear, um, for for operational use, uh, in the industry. I hit on. >> Yeah. So, uh, we decided to start a company called V10 Labs. The reason we started a different company is because we actually started making, uh, SAS products, right? Um, which is kind of an interesting twist and like move, right? But uh it has a direction. Uh so we ended up making two products. Uh Spear and Arrow. Uh Spear is a pentesting in a box platform, right? So we do all the way from um scoping all the way to reporting, right? Uh so it's kind of the whole life cycle of doing pentesting. So

we took actual knowledge we got over the last 10 years and applied that into a product, right? So doing a lot of software stuff. And then the other um product we made was Arrow. And another thing uh trying to solve problems in our industry, which is remote testing devices. you've ever done an internal assessment, you got to ship those laptops out, right? And there's a whole process. You can build it yourself. Absolutely. But do you want to manage it? So, we kind of built a whole platform around that. Uh, very cool stuff. We're going to help uh during this uh presentation, we're going to talk about how we built those things. So, if you want to go do those things

that we've done, go at it. All right. So, so where do I start? The why. You got to have a why for what it is you're doing, right? So, uh what does it matter? uh is if something already exists, right? So, if there's a tool out there, I got this when I started building uh my badge cloning gear, like, hey, this tool already exists. Why why are you doing this this now? Uh so, initially my thought was, yeah, there's some great tooling there, but it doesn't meet the immediate needs of the team that I'm I'm working on or the features that I have. So, uh go for it, right? Um another another thing you might get when you tell someone you're

getting ready to develop a tool, uh there's no real need for that. Who are they to say that there's no need for whatever tool you're thinking about in your own mind, right? Build it. Build a proof of concept or at least mindm map it and then you can determine individually whether or not that's a viable product or useful to the industry. If it's not useful to the industry and it's useful to you, it's still worth building. Uh, one, you're going to you're going to continue to grow yourself uh both from a skill standpoint, but you're also going to you're going to build up those those repetitions when it does come time to build something that's maybe a little

more uh viable for the market. Uh so what what actually matters is your why, right? >> Um yeah. So the other thing I just want to say too about um you know building tools, I know in the industry we have a ton of open-source tools that people build that we all use and they're really successful and stuff. Um so when you first start looking at improving that also think about if you could improve the tool that's already out there too, right? Sometimes it's not the best plan and building it from the beginning does make sense but you know building 10 different things kind of fractures sometimes. Um so look to contributing at first and then if that thing still

doesn't solve your problem then look at starting um something else. So before you uh you get going you really need to to uh define the problem right? Uh you can't build the right solution if you don't know what the problem is. Uh so think about what it is you're trying to fix and that'll kind of be build out your road map for where you're going. Um solving the wrong problem waste time resources uh and adds extra features that that you may not need. Uh add all those nice to haves in your road map. So if you build a a huge product road map and you want to put all the features in it at one time and get

it out to the market, you're going to be working on that thing endlessly forever. And at some point you got to you got to figure out when good enough is good enough. Uh and and just go with it. So think about what you need right off the bat. Everything else goes on the road map for for future deployments. Key points to consider. Identify your pain points. Uh we already talked about this, right? What's what's broken, inefficient, or missing? Uh clarify the scope. What are the constraints and requirements behind what it is that you're doing? Uh what does success look like? Validate the problem. So gather data or evidence that that the problem exists. ensure that you're not just

fixing a s symptom. And we got a nice quote there by Albert Einstein. Things to consider. Uh define your costs. This will get you really quick. I could tell tell you right now as someone that that develops hardware uh appliances and and gets them manufactured, uh it could get very expensive very quick, especially when you when you rush things or you don't uh uh go over all the the the necessary costs. um it gets very expensive. So, think about what your budget is. Uh stick to that budget. Um things to consider, raw materials, electronic parts, custom enclosures, etc. Um software tools and licensing. Um there's a lot of open source tools out there that you can leverage, but when you go

to start selling these things uh commercially, you're going to have to go buy those those more expensive commercial tools. Um so you can have one the flexibility that you need and two you're not you're not uh infringing on something else that somebody else has created that is helping you um further yourself right uh manufacturing PCB manu uh fabrication 3D printing injection molding are you going to do that in-house or you going to do it contracted I can tell you right now I started out doing it by myself uh until we we made enough money where I can start getting those things manufactured so there was many nights where I was soldering 100 200 boards uh just by

myself um until until we got to the point where we can get things manufactured. >> The other thing, too, is don't be uh scared to buy something that already exists if it solves the problem, right? Because the one thing that's not on there is time. Your time is actually worth money. A team's time is worth money. All of that cost, right? So, when somebody's saying, hey, this is expensive. You go look at it. Yeah, I could build that myself. Then you look at all the time it takes to build the thing. It's kind of like essentially saying, I need a F-150, so I'm going to go build that instead of buying it. Right. It might take a long time to do

that. >> Yeah. >> Shipping cost and import fees. This is especially important now. Um I can't tell you how much I just how much ransom I just paid to DHL uh over the last couple weeks. I was not ready for that and I I was pretty pretty upset, but um be ready for that. Other things to consider, uh DIY versus outsourcing. So, um sometimes it might actually be worth it for some things. Uh if you don't have the skills or don't want to invest the time and the skills, uh find someone that's that's good at what they do and maybe pay them to do part of your project. Uh I can tell you right now

when you're when you're running a business, uh you can't just spend all your time doing R&D, manufacturing, all the fun stuff, right? Uh you got to be able to go out and do sales. You got to be able to to to meet with clients. You got to have customer support. So, uh think about what it is that you need to do yourself uh and and what you need to outsource. um buffer for overruns. So 20 to 30% is typically what we we expect to pay anytime we're doing any type of development. Um >> yeah. >> Yeah. If you're going to leverage open source tools to reduce cost, just make sure to put a credit in there, right?

>> Yep. >> All right. Hardware engineering. This is where the bulk of the slides are going to be. We're going to run through it real quick, quick as possible as we want to have plenty of time for Q&A, but uh these slides will all be there for you guys that that want to deep dive into them later on. Uh tools to get started. All right, so if you're going to do hardware engineering, you're going to have to you're going to have to jump on the bandwagon. Uh I can tell you right now you will get lost in the options of what's there for you uh to start designing PCBs. Keycad Altium Designer uh if you're really bougie or maybe you

work for a manufacturing company that's going to get you that license. Uh or easy easy EDA. Uh I use Easy Easy EDA uh as that's just what I got started on. It's what I uh kind of kind of started building things with and I'm comfortable with it. Uh, not only that, I can go straight in there and and look up parts that I want to use, uh, add them directly and I'm not kind of jumping through hoops to to kind of find what I was looking for, what I'm looking for. Um, I have tried Keycad since getting going with with EDA and really doing a lot of uh, designs and iterations and for whatever reason, I keep going back

to easy EDA. Now, that's my personal preference. If you're already started up on Keycad, stay there. Stay there. Keep keep with it. Um, got some funny jokes there. I'll let you guys read those later. 3D modeling uh software. There's a bunch out there, right? So, if you're going to do this, I would recommend starting with with Tinkercad if you've never designed anything before. Um, if you want to make a cube, it's great. Um, it also let you make another cube. Um, but if you work with simple shapes, you can actually actually make some pretty complex things inside of inside of uh Tinkercad Fusion 360. Um, it's free until you actually need it. Then it's pay to play. And man

oh man, do they make you pay. But uh it is definitely worth it as you can go back design your sketches and you start to extrude and move things around. You can go back modify your sketches and you're not rebuilding an ultra complex uh shape or part. Um there's other stuff that that you can go out there and and use. Rhino Blender Solid Works. Um again, we got some more funny jokes in there. Microcontroller. So, chances are if you're manufacturing a PCB, you probably got some ESP32 or uh what have you. You're going to have to kind of choose your fighter uh on how you want to develop. Um Arduino IDE is there and available to you. I personally like uh

VS Code or Cursor. Uh much much more prefer Cursor at this point is it's got the the AI integration in there as we like to call it our assistant. Um, we just send all of our dumb questions that way and it tells us our dumb questions are dumb and tells us how to an ask better questions. Uh, and it it helps us solve some of our our more complex uh problems. So, um, give them all a look, give them all a try. Uh, this one's worth investing your time into to find the one that that you actually do like. I would strongly recommend either VS Code or cursor if you're doing anything uh with a microcontroller as it has the

uh the platform IO directly integrated and that helps immensely with uh building flashing what have you. >> I'll talk this I'll talk about this a little bit later on in the software stuff, but if you're not using VS Code, you absolutely should be as your as your editor. Um and if again, as Travis mentioned, if you're not starting to use AI, you're going to get smoked. So, >> yeah. Uh, that's not to say let AI build your entire application. >> Yeah, I'll talk about that, too. >> All right, hardware tools. How many people are are into gear? I know I'm into gear. Former army guy. I love I love my gear, right? So, grab the

essentials. Uh, you don't need to buy everything. You don't need to go ultra high-end. I would say if you're going to invest in a few things right off the bat, a good soldering iron if you're you're hand soldering. Uh a hot bed or heat plate. Uh that will get you so much further so much faster. And then one of these little rulers here for components. If you're doing PCB design, you can look down and you you could size up a component and you can say, "Yeah, no, I'm definitely not hand placing that on a PCB. Let's maybe go uh with something larger like an 085 size uh resistor." Uh, also a bench power supply. I can't

tell you how much I use my bench power supply to this day. Uh, almost three, four times a day at least easily. And then a good set of calipers.

3D printing. Buy once, cry once per year. Um, this technology evolves so fast. I would recommend if you're going to do this and you want to make money at it, maybe not getting one of the DIY U 3D printer kits. You'll spend more time tuning that thing, fixing it. While it is fun and we're tinkerers, we're not looking to build 3D printers. We're looking to build products that we could take to the market or to help us in our our daily lives. Uh so I personally uh despite the uh the commotion online, I do like my Bamboo Labs printer and we will probably be buying an army of the H2Ds here. uh HD2s, whatever they are, the new one

>> the new thing that they >> here here in the near future. Uh as it comes to 3D printers, research what it is that you uh you plan to build, right? Uh and then start thinking about the the filaments for each one of those things. Each one has kind of their own little little takes on it. U PLA prints like a dream and it melts like one too. Uh ABS, smells like cancer, prints like disappointment. Uh PETG because your love for strong prints but also stringing everywhere. Um, it gets pretty ugly pretty quick. Uh, PETG, uh, carbon fiber reinforced. Uh, my personal f favorite. It's strong, heat resistant, and brittle. Uh, just like my patients

when I'm printing it. So, um, >> who's got a 3D printer? >> Who's used one? Right. Yeah. Right. So, just a little caveat with 3D printing. Even the best 3D printer can gonna have issues, right? So, just kind of know that it like you can get a lot of consistency, but there's going to be an issue that pops up. It's it's uh it's a little more of like um oiling a machine, right? Like it needs the right uh uh what do you call it? Uh inputs. It does take some kind of um management to make sure it's still going to work right and print right. So um just be just be cognizant of that. Just cuz you know you

bought the best thing and then it didn't print right. Maybe you have to, you know, make sure you're doing it right. So >> don't think that because you calibrated it once that it's always good to go. >> Humidity changes, right? So yeah, >> anytime anytime you get ready to go do a good print or or something for um use >> what happened? >> Oh, there it goes. We're back. We're back. Uh yeah, that humidity will kick in and you'll be like, I just calibrated this thing. Why does my >> print look like garbage? Um so yeah, in Florida, definitely calibrate and calibrate often. Also, uh what are those little bags called? >> Oh, the decadent. Decadent bags.

Yes. >> Put as many of those things if you have an AMS in there as you can possibly fit. Um that's my recommend if you're in Florida. >> For anyone who hasn't 3D printed the um uh moisture in the filament is what causes issue. So we're trying to get it as dry as possible. >> All right. Proof of concept to prototype. >> All right. All right. So, we got a a little hypothetical um um project here. Building an RFID reader, right? So, what's our problem? Uh we need to know if we want to go build a reader, we need to know how to interface with the reader's uh wean interface as we know that a HID reader or whatever

type of reader typically puts out uh a wagon signal. Uh we need to know what voltage is that signal and can my microcontroller support that voltage. Uh how will we power the reader? So, we got to we got to solve for a power source. uh what we know we know that we want to use an OLED display. So we want to be able to see what's going on uh from a user standpoint. We're comfortable developing with uh an ESP32 and we want two buttons to navigate through the screen. So as we we catch badge reads, we want to be able to arrow through, go back and and see what we caught and go from there. So what are

our constraints that we we have with uh our our prototype? Uh we'll be self assembling. Uh so SMD components uh need to be large enough for hand placement. Uh case will most will be mostly enclosed. So thermal aspect needs to be considered and cost uh we need to save money on components where possible because these readers do get very very expensive. Uh problem uh so we need to know how to interface with the readers. Uh I think this was kind of a duplicate slide there. So, we have to go in and analyze things, right? So, the way I like to go in and analyze things is I pull out my my multimeter, right? And I'll just turn on the device and I'll

hook up to the wires, see how much power is going out. Uh, we could tell that when the the reader is is just on uh it's getting 4.8 volts uh out the uh out the the data lines where the weekend's coming out. Um, so we have to solve for that right there. If we pick our our board or our our ESP32, these uh T display S3s um by Lilliggo are incredible. If you don't have one, I strongly recommend grabbing one just to just to play with. But if we look at the uh the the the requirements here, we can see uh that it operates Oh, sorry. This is our reader. Uh so our reader requires a a 12volt uh power

supply, right? So, we have to one power the ESP, right, which is probably going to require 3.3 volts or maybe 5 volts input. Uh, and then our reader is going to have to solve for for a 12volt input. So, we got to think about how we're going to get the proper power to each one of those uh without uh frying anything. When we look at our ESP, the output there, uh we've got some 5V pin headers, but that's output only when you look at the data sheet, right? So, uh, the only way we can really input on this one is to either go through the battery connector or directly to the, uh, USB type-C input. Um, so when we think about

this, we got to think about the thermal aspects, right? So, if we put 12 volts to a 3.3 volt connection, we're going to have to really step that down. And as you step down voltage, uh, you're going to generate a lot of heat. So, we got to think about where we step down from. I can take that 12vt input and I can step it down to 5 volts. And then once it's on the board, it can step down to 3.3 volts. Um, as we do this, we're going to look at what type of uh power we're going to use. So, here we're just looking at for for our prototype purposes, just a LD uh 1117. This is a

low dropout uh voltage regulator. And it comes in different different form factors, right? Uh you can see this DAC. You just solder that directly on. This is a bit larger. We can actually use that on a a breadboard uh just to get going. So, uh, we do know that it it supports an output current of 800 milliamps and we can get it in fixed voltages of 1.2 volts out all the way up to to 5 volts out. Um, so as we look back at these these readers here, we see that the reader pulls 250 milliamps and uh our ESP32. Uh, it doesn't say exactly, but I can tell you that it's probably around 250 milliamps as well,

depending on what you're what you're uh powering off of it. So that's our our solution for power. Uh now we need to look at the uh the the fault tolerance or the the ability to support 5V data lines coming off that those wagon connections. Uh as you look at the the chip itself from Expressive for the ESP32S3, it says that the that the pins are not 5V tolerant. So that tells us that we need to put some type of system in place to drop our 5V signals coming off those readers down to to 3.3 volts to support uh the reader itself or the the the SP itself. So how do we do that? Uh one, we

can use a logic level converter. So this will convert the signaling from high so 5 volts down to low the 3.3 volts. Uh and that's uh birectional. uh we don't really need a birectional communication with the the wagon interface on a on a head reader. We just want to take that data bringing it in bring it in and process it. Only only reason we would want to um send it back to the reader is if we had another interface where we sent it downstream to the controller. So if we wanted to like replay a badge read at a later date, that's the only time we would really want to convert that back up to a 5volt. Um so cons requires a lot

of uh connections and and costs a bit more, right? uh to to implement. Our option two is voltage divider circuit. Um this is probably the best way to go for our application as uh we just need to receive data. We don't need to send it back out. Uh super cost cost effective uh to implement and we'll talk about each one of those right now. So voltage divider, how do we how do we do that? We're just using two resistors, right? So if we put a 10k resistor and 20k resistor, we could take that that high output at 5 volts and drop that uh immediately down to 3.3 volts, right? With just two simple resistors. Uh

here's some some math on how to get to to those those points there. Uh I won't get into the nerdy stuff too much. Um but pretty simple. If we were to do the uh the logic level conversion, you would have to have a 5volt power line going to a 5volt power source. You'd have to have a 3.3 volt power line going to a 3volt uh power source so you can determine or tell the the logic level converter what was high and what was low. Then you would need to have four lines total for weekend for data 0 and data 1 to determine the 5V signals path and then the 3volt signal path and then you'd have to have grounds

on both sides. There's a whole lot of connections that kind of go into that circuit. over this one. We're we're just uh tying to ground on that 20k resistor and essentially uh altering this signal. Other things we'll need for our our proof of concept, right? Uh we'll need our our momentary button so we can jump back and forth. Uh we talked a little bit about the power power requirements on the ESP32 uh where we need to um supply 5 volts directly to the USBC. So, on this particular design, we're just going to hook a USBC connector directly to uh the ESP32 for the powering. And then we'll need some uh some screw terminals to connect everything up.

All right. So, as we we we jump into uh easy EDA, right, we're going to look at our data sheets. If you ever have a question, any any anytime you you're you're pulling up a part, don't just go blindly look at another design that you've seen. Actually go look at the data sheet. Nine times out of 10, it's going to tell you exactly how to how to set things up. And if you follow that that that diagram, uh you'll you'll be good to go. Also, they'll have some uh placement um suggestions inside the the data sheet itself. So, when you go to design your PCB, you're putting it in a recommended fashion uh where where noise

might be an issue or or what have you. So, again uh components look at the uh the size of the component to determine uh how much heat it might uh dissipate. Right? So as we look back at our our our first slide, one of our constraints is it's going to be an enclosed area and we want to have we want to take thermal uh into into consideration. Here you can see what what the thermal data looks like on the different size um components of the same LD uh 1117. And you can see here uh that that TO0 220 has much better heat dissipation uh than some of the other ones, right? All right. Designing the circuit itself. So just be

simple with it, right? Uh look at what you need. Here we talked about what we needed to do and and how how to kind of get there. Uh now we're just kind of mapping everything in our our easy EDA in our in our sketch prior to moving that off into design world. Right. So, we've got our LD uh 1117. This layout looks a little bit different just because this component looks different inside easy EDA, but for all intents and purposes, uh we still have our capacitors in the same orientation. We've got our voltage in um we've got two uh screw terminals here. That's what these CN1's are. Uh that's for our our power input and our power ground. And

we're just labeling what that actually is. Here's our wiring for our ESP32. We've got our data data zero, data one. This is the low side. We've got our left and right buttons. And we've got some inputs over here. We're actually connecting the reader uh and the the buttons themselves. And here we all we only other things we need on this simple circuit is our uh voltage dividers. So, we got our high side, our low side, and we're just tying those those two resistors together to pull down that that current to the the recommended current um on each one of those those data lines. Now, the fun part. So, this is where we actually do our our proof of concept,

right? So, get your your breadboard out. Uh I like to make sure that I have my power supply here. I set it to exactly 12 volts. Uh, another reason why I love this power supply or having a a bench power supply. I could I can see exactly what the wattage is. I can see what the amperage is that I'm pulling. Um, this looks a little bit ugly, but I do have my my power input here. This is my 12 volts are coming in. I've got my voltage or my my level shifting circuits here. Uh, got my my buttons plugged in, and everything's kind of orientated the way it should be. Uh, this left side over

here is our our 5volt side. So, we're bringing in our our 12vt. Uh we've got our little guy soldered up here which is dropping it down to 5 volt. Uh we kind of see the circuit before we ever go and and design our PCB or get it manufactured. We know that everything works kind of as intended. Um some things things to think about here. While we're not going to jump into actually designing uh during the talk, think about where things should be on an ESP32. You've got these little uh Wi-Fi antennas. They don't like to have any copper anywhere around it. So, even if I'm just do doing a PCB to mount a an ESP existing ESP32 directly to the top,

I'll still put a no pour area. So, if my antenna is going to be hanging right here, I don't want any copper back here. If it's sandwiched between two pieces of metal, that's going to one degradate that that Wi-Fi signal, but it can also cause noise issues on those those small microcontrollers. Uh, inversely, anywhere that's not in that no pour area, I always fill it with ground. Um, depending on how many layers of board you have, that ground works great for for taking all that that thermal um all that heat out and dissipating it. So, this is just how I like to lay things out. Uh, additionally, thermal vas uh consistent everywhere. Uh that again if

you have multi-layer boards, it kind of acts as a heat sink as it passes through the boards. Uh look at the component recommendations for for layout and it'll kind of tell you like, hey, put a bunch of thermal beads or uh what's recommended, right? Uh here's our our logic level conversion. Uh so we've got 5V signal all the way from here and then we're just wiring it up exactly as we said we would uh to those those parts where our ESP32 will attach. Here's the uh uh fully designed board what it'll look like. Very simple design. We're not actually putting uh ESP32 components directly on it as we're using a pre-manufactured part. We just need to

do the logic conversion and the the handling of the power. Inside of Easy EDA, uh you're going to need a few things uh before you go into manufacturing. Uh your DRC. So, this is going to essentially make sure that you didn't make any mistakes uh when running your lines. I would strongly recommend never auto routing anything. That's an expensive ma mistake I made when I first started uh doing this. I was like, "Oh, I got an auto button." Boom. Off to the manufacturer. Nothing worked on that board. Not Not a single thing. I went back, I was like, "All right, well, I'm an idiot. I'm going to go back and do this the right way." Uh manually route

everything. Uh one thing that I would say, too, trace widths by default, these things can be super small, right? So depending on how dense a board you're creating, you might have to have small trace widths. You can look up the uh the the minimum sizes. We'll talk about that here on your manufacturer. I like to make my trace widths as large as I possibly can uh for anything that I'm doing. One, it adds more more conductance. Um two, makes it easier to see, test, what have you. Uh so you'll need your your bomb. So that's your your build of materials. You only need this if you're getting the boards assembled. Uh you'll need to generate your Gerber

file. This is essentially the um um the CAD file that the machines use to cut out your boards and then pick and place. Again, you you really only need that uh if you're um getting your boards uh manufactured. Just tells where those where those parts go. All right. What are your options for manufacturing? Uh there's not a whole lot that I recommend. Uh, if you go to Osh Park, I don't believe they actual do manufacturing there. I think they just do PCBs. I could be wrong. Uh, I've used JLC PCB since I've started. Um, pretty quick. Um, pretty pretty fast turnaround. They're not exorbitantly expensive, especially for for just PCB work. I would say that if you are going

to get PCBs manufactured, uh, tile those things out. So, don't just do one part on one PCB. put as many PCBs as you or many as many parts on a single PCB uh as your money will go much much further. >> They're uh they're all in China, so just expect there could be tariffs now. >> Yeah, >> all pretty much all PCBs are made in China, Taiwan. They're just not made in America. >> Understand their capabilities, right? So, we talked a little bit about trace widths and spacing. Um, so minimum trace width here for for JLCPCB, um, laid out right there. So, 6.5 mil. Uh, make sure you don't go below that. Otherwise, they'll try to manufacture it

for you, but they're going to charge you a lot more, uh, for for stuff. Uh, impedance control. So, if you are building a like a custom ESP32 and you've got um um you get a flash over USB, uh impedance is a big thing, right? So, you want to make sure everything's uh properly properly aligned there. So, you can go in here and you can see uh the spacing and and what have you as you as you build out your uh differential pairs. is a calculator at DigiKey that I love to use for um doing that. Um so

panel. So we talked about panelizing things. Just hit panel by JLCPCB if you're going to go to JLCPCB and your part will come up and you'll just say how many you want to go across and what the size requirement is for that. Uh and it's essentially the same price as you would with only single single board on a panel. All right. So, you order your boards, you get it back, uh you're going to do this by hand. What I like to do is take a bunch of boards and kind of make a template out of it. Uh tape them down real good. And then I'll uh take my stencil that I got from the manufacturer. Just tape that right over

the top. Here, you can just put your uh your um solder paste down. Scrape it across really good. As soon as you lift up that that stencil, everything's exactly where it should be. Another thing that I like to use when it comes to manufacturing, maybe not on a board this small, uh, but there's an awesome tool out there called interactive HTML bomb. So, you can essentially take your your pick and place file and your Gerber and it'll automatically map it. You can pull that up into a web guey uh and and set it up next to you so you know what part goes where and how many parts you should have for for each of your builds.

Soldering paste that I like to use is chip chip quick stuff. It's very expensive. Uh expires really quick. So if you're going to buy some, wait until you're getting ready to to do some manufacturing at the house uh or wherever you're doing it. Uh and then at the end of it, you're probably going to have to toss it unless you're going to do a lot of manufacturing uh right away. Uh here's our our our heat plate. Much quicker than hand soldering. Uh you you do your solder paste, use some tweezers to drop your components down, heat that thing up, and you can literally watch the the uh the solder kind of fall into place. All right,

hands soldered the remaining components. And here we have our our somewhat finished product uh that lets us read badges. It's got a little clock built into it and what have you. firmware design. We won't really touch a whole lot here, but as you've done any type of uh ESP32 development, there's libraries for everything. You there's the chances you need to write a whole lot of complex code are very minimal. Go to those libraries and then go to the examples. The examples have just about every application that you could want to do with that library directly built into it. Uh take those examples out, modify them to your needs, and you're you're good to go. 3D modeling. Uh, keep it simple, stupid,

right? Uh, so here our aero product, we have uh these imaging racks that we created. So, we just took a bunch of those Jet KVMs, put them up at a fancy angle and and mounted them into our racks. Uh, so we have them all all in the same place at the same time. You can use the existing components. You can go on to like for JKVM for instance, you can go find the product itself, get the step file, import that into Fusion 360, and you can build your parts essentially uh right around those existing parts. That way you have a nice um snug fit or positive fit um on on each component. Don't over complicate

the process. Start with with small stuff, right? if you're going to build a bunch of uh really complex designs. So, what I like to do when I go to 3D print is I'll say I want to make sure this fits. So, I'll put a pause in my print maybe 5 mm in and I'll pull that first print out, grab my device, plug it in there. Is it a good fit? No, it's not. Let's go. Let's go make this thing a little bit bigger. Uh so that way I can get the the whole the whole part in there before I I print this entire thing, which probably costs about five bucks per per print. When I asked Travis

to make this, I was like, "Hey, they've got the step file. You're good to go, right?" He's like, "No, I need the device. Like, you can't like you have to like make sure it actually fits." I'm like, "Yeah, but it's already in the CAD. Like, it should fit, right?" No, I think he printed out like a ton of these before it actually worked. >> Yeah. There was probably seven different designs before we landed on on this one here. Uh 45 degree angles. That's a big one, right? Uh so, when you do any any type of chamfering, uh don't go beyond 45 degrees. Anything above 45° will require some supports in some aspect. Uh if you

go if you stay below 45°, you won't need supports and you just have a a cleaner, more polished print. So that's just a little pro tip. 3D printing itself. Uh we talked about this. Dry your filament, calibrate your machine uh to the filament and do it often. Add a pause in your prints. Um terminate the printing while dialing things in. Uh use the right nozzle plate etc. So, if you want to have a textured print, use a textured plate. If you want a smooth print, use a smooth plate. Um, think about those things in the design process and that'll usually design uh figure out where you need to go. Also, look at the the types of filament. If

it's going to be outside, probably shouldn't use PLA. Uh, think about where the where the where the weather's going to be or or where the device uh whatever it is you're making is going to be at. Um, be ready to make mistakes. You're going to make a lot of mistakes. There's going to be a lot of plastic stacked up in your trash can as you get to learning this. Even when you're you're you're pretty good at it, there's still going to be a lot of plastic stacked up in your trash can because filament sucks. Um, embrace the process. >> Embrace the suck. >> All right. All right, >> you're up. >> Yep. All right. So, I'm going to talk a

little bit about software development. Okay. So, um, who's used any SAS products before? Probably everybody, right? If you go anywhere, they're everywhere. Um, so we're going to talk about not necessarily developing SAS products, but developing a web interface, right? Um, and uh yeah. So, uh, software, do I need a web interface or do I need a CLI? Okay. Um, there's a lot of tools out there that are just made with a CLI or, uh, software that's made with a CLI, especially a lot of hacking tools. Uh, I love my CLI and it has its place, right? But if you're going to give that same thing to a mass market of people, um, they now have to learn what every single

of those commands do, right? Has anyone ever tried to learn how to use metas-ploit or any of the other big CLIs, right? There's a process that comes involved with that. Even if there's a huge documentation now, I need to know how the CLI works, right? Which is why when we browse the internet, we don't browse the internet with a CLI, right? Um, there are some benefits. Absolutely. Um, so I'm not hating on CLIs. I'm just saying that um you know we as a uh kind of a a collective have decided that the web interface is where we're going to interface with our applications right um are people running my code or am I running it for them right so here's

another question when you're designing some software um am I going to be using this tool internally probably make it a CLI right save yourself a ton of time but am I going to be giving this to other people well maybe I should spend the time to make the web interface because how the document who's read the document on how to use their bank website, right? It's kind of self-explanatory. That's the point, right? Um and so, uh that's that's another reason why it might be a good idea. Think about who's going to be using it, right? Who's your user? Who's your intended user? Um and, uh you know, where will you put the documentation? Um even when you do make a simple product,

uh you still need some documentation. Um, I've used products that I know how to use a web interface and I just can't find the button or something like that and it's just not intuitive. That gets into, you know, actually building a product that is intuitive, but um, you know, I'll leave that up to your discretion. Um, and then also deciding how you want to license your software. Are you going to make an open source tool? Awesome. Decide what you want, how you want to license it. This is not going to be open source. Um, you know, what what your what your plan is uh with that software, right? All right. So with that being said,

let's talk about building a web application. All right. Um so web applications uh typically have a front end or think about a modern front end to build your web application. Um you want to maximize your compatibility. So uh out of box you want to be able to support mobile and desktop. People are going to visit whatever web application on a on a phone as well. So consider these things. Um try to make it extremely customizable. Um, web apps can also be applications. So, who's used Discord, right? That's just a big web app that's wrapped in Electron. Electrons everywhere, right? Um, now there's things that uh a local web app can do. It can interact with the file

system. It can interact um it can use some more um processing resources, but um you know that you can make a uh you know interactive web app that runs as an application on the computer, right? Um, same with uh many uh iOS apps or Android apps or just web apps that have been rolled inside. Um, everyone loves JavaScript, right? Um, that's a joke. Uh, so but uh yes, when you start developing a modern web application, it's a ton of JavaScript, right? Um, I remember the first uh not web application I made, I tried to make a CLI in JavaScript and I hated my life and I abandoned that project. Um, but uh I've gotten older and I've realized that

uh nobody's getting rid of JavaScript and uh it's used all over the place. So here I am. Um when you're making your application um you know try to try to cover the most use cases. All right. So here is a modern web application stack. This is just kind of like the general gist of it. I said you have a front end which is going to be a JavaScript library. You're going to have possibly storage like an S3 bucket, right? Um the reason you might use a S3 bucket is that you know your application doesn't have unlimited storage, right? You might want to be able to have big files on there. Let's think a PDF or

something. Um you're going to have a backend. Um the backend can be part of JavaScript framework. Think Node.js or it can be a actual um programming language, which we'll talk about that. You're going to have a database, some place to store data to reference, and then possibly an IDP, which is essentially an identity provider. So, one thing you've seen or I've seen and I think is a smart way from a security standpoint is just separating your authentication outside of your application. You could do that locally if you want. There's no problem with that. But if I use a IDP, then I can offload that whole task and then we can think about that security from a

separate standpoint, right? Um, also a lot of these IDPS include a lot of other features that I then have to build inside the web application. With that said, we have a bunch of different frontends out there. If you have uh looked in the landscape, some of the big ones are React, Angular, Vue.js, Sevelt, Nex.js, the list goes on and on and on. There's tons of of uh JS frameworks for building your front end. Um, many of these frameworks can also be the back end as well. essentially they can process server side data as well as be a front-end interface. Um, but they don't have to. Um, additionally, another thing that I discovered is there's UI

toolkits. So, instead of trying to make a UI, you can use these toolkits to accelerate your process significantly. Um, so this is all the buttons and the notifications and the drop downs and all the other fancy stuff that makes a web interface look cool. You don't have to manually go build all of that stuff, right? Um, many of these libraries are, excuse me, open source and free. Um, some of them like material UI, you've seen, um, uh, Shadas, CN UI, there's a bunch of them out there. Um, they're probably in applications that you've seen before, but you didn't think about it because you're just trying to use the app and you don't really care. That being said, uh, let's talk about

the back end. So, you can also write your back backend languages like, uh, Golang Rust.net Python JavaScript. Um, I prefer Golang. Uh, if you want to get really like uh hipster with it, you can go Rust. Um, another really popular framework isnet. Uh, there's a there's a bunch of um uh web frameworks in .NET is actually more popular than you realize. Um, also Python. I would probably avoid Python. That's just a personal opinion. Uh, I've written Python a lot. Um, but as far as making a full stack web app, performance becomes a huge issue, right? um and also um where it gets ran. So if the person is you who is running it, use whatever language you want, but if

you're giving it to other people, now they have to run it and the dependency hell of Python um is going to come to bite you and now your documentation is going to get really big. Um and then also JavaScript. Uh there's many libraries that essentially use node on back on the on the back end both sides. Um all right. And then finally for database, honestly, I don't even have an opinion on this. Um, you could use SQL light. It's actually really fast. Like it's incredibly fast depending on what you're trying to do. It just doesn't scale. So if you're if you need to uh be a Facebook, SQL Lite's not going to work for you, right? Um or if you have uh

something where you need to make a essentially like a redundant cluster of databases and stuff like that. It just doesn't scale. But it is very very fast. Uh Postgress is another one. my my SQL or uh whatever the current open source version of MySQL, right? I think it's Mirror DB. Um same thing, MongoDB if you want to go with like a JSON objects, that's another uh fun way to store data. Um Reddus is also kind of thrown in there. Um a lot of people use Reddus for uh acceleration. So uh what people don't realize about Reddus is that all of it, it's a key value store and all of it is in RAM. So it is designed to be really

really fast. So a lot of people use it in their web applications for some kind of caching, right? So they'll cache data in there so your web application sees faster. Um there's also um uh elastic. You could technically use elastic for kind of a database store, right? Um many like uh sims and other big products, they use actually elastic when you're searching as like a database. That's when you're dealing with lots and lots of data, but you're not doing it in a uh in like a CRUD, which is essentially like an updating system, right? you're not trying to update entries. Um, it would be a horrible application for that. Um, and then finally, your identity

provider. Um, again, uh, local is not really identity provider. Essentially, when you make an application, you can save username and password inside of the database. Uh, that would be like a local authentication. But you can also use something like Ozero or Octa, one login, uh, Zitadel. Some of those are commercial products. Some of them are open source like Zitado. Um, there's other ones out there. I think Ozero you can use almost for free for a lot of the different uh applications that you would be doing. The benefit of this is that they already include things like pass key, user password reset. Uh they're already include all the security of actually using B-crypt for the hashes

and all the other fun stuff, right? Um and another really fun thing is that a lot of people including myself would like some kind of single sign on where I can use my Office 365 across a lot of different things. uh when you use something like uh identity provider, you can implement that, right? Without having to code all of that. Um and now your web application just essentially gets a uh a thumbs up that says, "Hey, this is the person they said they are." And then the application itself, right, decides what their permissions are inside that application. All they're getting is that they are who they say they are and uh they go from there,

right? Uh okay. So, uh another fun thing that started to come out was is like web framework backends. So let's accelerate the process even faster. So uh Firebase was the original one with uh Google and then there's uh Superbase, Pocket Base, Trailbase. I feel like there's a theme here. Um but what these are in general is that they are a kind of like a quick start for a full stack web application. What they bring to the table is they already have user authentication built in. they already have some kind of database set up and they're ready to integrate with a JavaScript language and then a backend language. Um, one example of that is PocketBase. It's written in

Go. And what happens is is that it's a single executable. It already has the ability to hook into a front end, Angular, React, whatever. It has a database, uses SQL light, and then it also has um, what do you call it? Uh, authentication. So you can use local off or you can hand it off to an IDP, right? Um the benefit of this is that now I can just get started right away. I have something that's working. All I have to do is build the front end, bring those two together, and now I have a full stack web app, right? Um Trailbase, I believe, is the uh uh Rust version if you want to get hipster.

All right, so some of the goals um building a full stack web application is what I recommend. Um I would avoid things like PHP. Um if you're writing in PHP, God rest your soul. Um today, uh so the the really benefits is just to modernize the web application. Uh try the performance is significantly faster and the ecosystems, all these libraries and plugins and there's so many uh SDKs that you can plug into. Uh speed in the front end and the back end. So um you want a framework that's uh quick, right? um something like Go is significantly faster than um PHP uh for example, especially when you want to interface with the actual underlying operating

system or do some kind of function, right? Um you want security in the backend API. So all of your calls should have some kind of authentication check, right? Every single API request should be authenticated in some way. Uh so consider that and um ability to scale to cloud storage or scalable databases, right? Another thing to consider depends on your application. You're running something local that just runs on the computer. I don't really need scaling. So just consider all of these things when you're kind of putting putting it together. Um finally, uh here's just an example of a front end that I quickly quickly but I wrote for uh the arrow device deployment. This is just allows us so so

some of the cool things is that this just allows me to see uh resources from the device itself, right? And IP addresses. While this isn't amazing, what I didn't have to do is actually work very hard to get this data out, right? Because the full stack web application, meaning the go binary, can query a command on the host or use some SDK, I was able to get this information quickly and the front end uses an API to ask for that data and a JSON blob easily shows up, makes it refresh. So, um, it makes it really quick. All right, so who's heard of vibe coding? It's a vibe, right? >> Okay. So, um there are a couple

different things you could use to vibe code or to code with AI. Um cursor is one of the big ones out there. They're probably on their way to be a trillion dollar uni unicorn. I don't know. Um wind surfer, uh client or other ones. Essentially, what is vibe coding? So, vibe coding is using large language models to essentially write all the code for you, right? Um, and the vibe part of it is that you're not really looking at it. You're just asking it to do stuff and then you're like, "All right, what does it did? Okay, it did that. All right, let's keep No, it didn't do it right." So, you keep asking it back and

forth, right? But you're not technically looking at the code. You're just kind of vibing it out. But I will say, um, I started using cursor to write code and, um, if you're not using this, you're really missing out on on what it what value it has to add, right? um I would not be able to write half the amount of code that I've written so far without the speed of a large language model. Um and uh it's going to continue. It's when I first started I know when I first started with uh coding with AI actually with just AI in general. I remember the first like chat GBT3 or whatever and you asked it questions and

every look it's hallucinating. This thing's you know so stupid. It's never this is this is a joke. It'll be next 20 years before this thing gets smart, right? But it's like less than a year and it pretty much started stumping and getting faster and faster and even over the last 6 months I'm like are they going to just keep dropping new versions? Like it's just getting insane. I can hardly keep up. But that being said though, it is getting smarter. It is getting really good at coding, right? And the reason why it's getting really good at coding is um the kind of fundamental way that if you have an input and you know the output, it can

keep going until it gets that right output, right? And uh AI is really good at that. So anyways, these are things to look at. Uh they can help accelerate the process significantly. Um using large language models is not free though. So uh just note that the um uh the uh what do you call it the uh the bigger models once you start using them a bunch there it's going to cost money. Um also one last thing I will mention about vibe coding or coding with AI. All right. So if you just start and you have no idea what you're doing, this is going to blow your mind, right? You're going to be like, "Holy crap, it wrote something

amazing." Um, but eventually you'll start to be uh coding and realize, hey, I need to change this one color on this thing, right? I know how to do it, but I'll just ask them to do it, right? And then it takes like 5 minutes for it to think about this whole thing. Go back and write it all out just to change a color. My point is is that don't get too lazy with this because you you actually slow yourself down when you ask it to do really really simple task. Um and uh uh it should be used for kind of bigger tasks. Also, if you don't want it to code at all for you, I would absolutely

recommend asking large language models to help you design what you want to do, right? Playing out that whole design decision um is is really really powerful. So, all right. I think that was >> we made it. >> Yeah, we made it. >> All right. >> All right.

If anyone has any questions, I think we got a couple minutes here. >> Yeah, we got Yeah, we got like five minutes. >> Yes, sir. >> I'm sure when you're building physical products, using social media to market it is huge, but apart from social media, what would you say is the next way you get your >> uh things that draw your your your your customers to it? So, for us, we make physical products and we make it specifically for physical pen testing. So we have a physical training class that gets people hands-on with the equipment which also drives a lot of sales. >> What are some things that you focus on for like of your devices making sure that they

can't be >> so used against them? >> Yeah. So uh what we do is very like simple. So everything's kind of broken into into purpose. So if it was hardware security where I'm putting like processing payments is going to look a lot different than hardware security where I'm processing car data. So, I like the ESP32 specifically cuz it's got onboard encryption. You turn it off, you're chances are you're not going to compromise car data that might be stored on it. Uh, but as you go further into that, you might want to think about adding some type of additional onboard storage and encry encryption controls and then penetration testing on top of it. >> Hi, buddy. Good to see you, man. Yes,

>> they will. We're going to send them to the uh the con here in just a minute.

Yes sir. >> Uh yeah, hit me up on uh on on LinkedIn. Uh it's uh just search Travis Weathers and BM Labs. You should come right up. Shoot me a shoot me a note on that.

>> Say, "Hey." >> Yeah. What's going on, man? How you been? >> That was a really good talk. Thanks. Thanks. >> Hey, >> thank you. >> Whole [ __ ] crew. >> Thanks. >> How are things? >> Doing all right. I uh been testing for a few years, both of us, and then we're now both on the management. So, yeah. >> Right on. >> Right on. >> Yeah. Went into leadership now. >> Sweet. How big is the team? >> It's growing. Uh we just did a huge hiring spree. Um but I think total not including testers probably like up to like 30ish like not including the tester which goes like 184. >> Uhhuh. >> But yeah, no we in our in our steady

way. >> Great. That's great. How's uh you guys still doing all the same offerings or expanded? >> RTO center. >> Perfect. Is it just you or someone else? >> Okay. Amazing. So, what I'm going to ask you guys to do,

if >> I can have you guys,

>> put this in your pocket And then right up under your shirt >> and then just hook it up right here.

>> I might just have

same thing for you. Just uh Yep. >> And I'm going to come up. I'm going to give you guys something just uh There'll be an email address just to send the presentation to after. So, give me just

talk. I went in had a microphone at the top. I was like absolutely not. >> When you guys are done, you have a chance after you present, just send the presentation this email so we can have it and get it up for video. >> Yeah, sounds good. Yeah, thank you.

>> There's a whole lot of extra cable. >> Wired up. >> I'm going to do real quick. >> Say again. >> I'm going to do your introduction real quick. >> Yeah. Give me like one minute. Okay.

Everybody else.

Now I did it right. See if this works. Woohoo! First time. >> One second. Where? >> Kaden, where you at?

>> Say, "Don't worry about it the whole time. Just do like a couple shorts or something." Okay, >> make sense.

Yeah. >> Yeah. Go ahead everyone. >> Okay. Welcome everyone. Uh this will be about purple. Please welcome Tyler and go to two cyber security leaders from SIT with deep roots in both defensive and offensive operations. Tyler brings over a decade of experience in defensive cyber operations. While Trey leads an an advis advisory emulation efforts and co-founded the Neon Tumble, a hub for co a hub for cyber collaboration. In their talk purple team cheat codes, they'll share hardearned lessons and practical strategies to strengthen your security program. No matter what team you're on, get ready for actionable insights you can take back and implement right away.

>> Thank you. How's it going everybody? How's Bides been so far? >> Have you guys made it into a lot of talks or just kind of overwhelmed by what all's going on? >> Little overwhelmed. >> This one's a lot. There's a whole lot going on. >> Say again. >> I'm going to need an Aville later. Uh, I hear you there. So, as she said, this is our purple team cheat codes talk. Me and Tyler, both we work at Scythe. We'll do the whole who am I here in a second. But, um, this is kind of our thing and this is a culmination of a lot of our experience over the last 10, 15, actually 17 years. We did the math this

week. It's how long I've been playing this game. So, we'll dive into this. Hopefully, you guys will take something cool from it. >> Who are you? >> Hi, everybody. I am Tyler Casey. Um, as you see over here, I am the lead detection engineer over at Scythe and the deputy of Scythe Labs. Um, I over at Scythe, I perform the blue team side of our purple team engagements, which if you don't know, we're going to talk about it here in a second. Um, I've been in defensive cyber operations for about 10 years now. Um, before I came to Scythe, I was on a cyber protection team, both as an active duty marine and as a federal civilian. What a cyber

protection team is it? Yeah. Little ya devil dogs. Anybody out here? um what a cyber protection team is. There we go. Too bad you got a meds hat on my guy. But uh um we would essentially deploy all around the world for targeted threat hunting and incident response. So I hope to take some of those lessons I've learned and pass it on to you guys today. >> Who am I? Hey, I'm Trey. See faces match. I swear that's me. I'm the person. So I am the lead AE engineer over at Scythe and the head of Scythe Labs. So really what that means is a lot of the content you see coming out from our organization our thread emulation

plans, webinars, workshops, all that kind of stuff. That's me, Tyler, and our team. My background, 17 years at this point in IT and cyber from anything basic IT networking, um, RF and satcom that got me into the whole cyber security realm of the 2013 apocalypse happened and from that defensive and offensive cyber operations. Now we're here sharing some knowledge with you guys. If you care about Alphabet Soup, I hold some of these and a few others. You can check out my LinkedIn if you would like to know more or just connect. So, let's actually get into the part you guys care about. You don't really want to hear about us contents today. So, if you've never

heard of purple team before, actually, you know what? Who's who's been a part of a purple team engagement before or done anything purple teaming? Okay, cool. So, almost half. >> Yeah, a lot more than yesterday. So, we'll talk about kind of what it is. is we'll give you a quick primer on basic tenets, concepts, things that go into a purple teaming engagements. From there, we'll actually dive into some of our we'll call them cheat codes or combos from the red side, the blue side, a couple good general tips, and then we can open it up for questions and then let you guys get on to your next talk. So, we're going to start off with what

is it anyways? So, at a bare minimum, if I was to boil it down, it is a collaborative milestone-driven methodology. Now, we use this methodology to bring red teamers, bring your blue teamers, and bring everybody else that's involved in the organization together to collaboratively collaboratively improve your overall security posture and defenses. That's the whole goal here and what we're trying to do. >> Main point on that collaborative, right? We're going to talk more on it, but a purple team engagement is very, very different than a typical red team or pentest that you might do. It's blue and red working together. Again, the point of all of this, offensive, defensive, purple, silver, all which I just learned

the other day, all the colors, is to build up your defensive posture. That's why all of us are here and have a job. >> So, what is it? How does it work? So, put a fancy little graphic diagram together to kind of basically explain what's going on in a purple team engagement and how it starts. Obviously, you've got to have some reason to do it, something you're afraid of, right? So, we're going to utilize thread intelligence based on whether that happens to be a ransomware group, a specific threat actor, activist, anything like that, and pull all that data we can about them, find true actionable bits and pieces of intelligence and the behaviors that they

exhibit and use that to test your organization. So, we're going to actually based in realism, based in facts, we're going to take that information and throw it against you and see how it sticks. Maybe you see something cool happen. Maybe you notice you've got some gaps and you've got some things to fix. That's kind of what we're trying to do here. But once we gather up all of that thread intelligence, we've decided who it is that we want to emulate or we're trying to protect against. We've got to go into the preparation, decide how we want to do that. Whether that's going to be just kind of like a collaborative purple team exercise where it's just the red team

you guys have in or internally your security analysts and just kind of letting them go at it. Maybe you do a hybrid tabletop exercise where you're bringing in the whole organization. We've had some pretty good um experiences with this with getting everyone involved, not just your analyst and the outside red team, but your legal team bringing in pao, your sea levels, management, because it's one of those things there is all of those people are involved during an incident, right? So why are you practicing without them? We bring them all together. We prepare that whole engagement and make sure they're participating. Once we've we've prepared, right, we've got to do the thing. Run the exercise, see how

everything plays out. And then everyone's favorite part and especially Tyler's favorite part, lessons learned. What' you take away from it? Notes or it didn't happen, right? These are the core tenants and the things you need to run an engagement when you think about purple teaming. Benefits you get. I swear we've only got like two more slides talking about this, then we'll get into the stuff that's actually fun. First and foremost, and realistically the best part of this is training your defenders. We always like to say you don't want the first time you're responding to an incident or putting your procedures into play being during an incident. That's really kind of that's poor timing, right? And is anyone

had to actually do that? Who's doing IR? Who's working in any of that kind of space? You've had to respond and not knowing where your SOPs are, not knowing what tools you have accesses to, that is the worst feeling in the world. And that's the whole point of this is to avoid that. Improving communication. This is something that's often overlooked. Running these kind of engagements and doing these not just annually but frequently. Getting everyone together and actually running through a real problem is going to ensure one you understand how your tools work, your SOPs work, but your people know who to talk to. If you're in the middle of an incident and you need to

put out some kind of statement, get something word out through legal, that doesn't just go to a lawyer and then they say you're good to post it on Twitter, right? That's not how things work. Do you understand that process right now? Do you think your team does? These are all the kind of things you're trying to accomplish. So, it's not just making sure your logs go where they go. You're also ensuring that you know who to talk to, when to talk to them, what frequency, and making sure everyone's working together. The part that most of you in the room actually might care about is identifying those gaps. Maybe making sure that all of your endpoints are rolling logs up

into your seam sore XDR crazy data lakeink combo, whatever you got going on right now. Most people think, "Oh yeah, that's going it's fine. We're good." Until you're not till drift happens or something changes, somebody turns something off and now you're not getting anything. I know that sounds very catastrophic, very drastic. We've seen it happen. We've been in engagements and had teams go, "Oh, yeah, no, we're fine. we're going to crush this. And then turn around, we do one or two things. They're like "Um did y'all do anything yet?" >> When you guys when you guys getting started, start looking. >> What do you mean? It's like, "Yeah, we we've been doing stuff all morning that,

oh, we've got a problem now." And just finding out for the first time their logs aren't doing what they think they're doing. But then lastly, the probably one of the coolest parts about running a purple team engagement is showing immediate value. bringing someone like us in or even internally running your own engagements. You have everyone talking together. It's not like a pentest. You sit through a pen test, you bring in someone from outside, they throw the book at you, they write up some report, hand it to you, and then do one of these, right? And just disappear. The value comes later. Maybe if when you can read that report, interpret it, maybe do an out brief with them. But all

of those are ifs or wins, right? If you're doing it live in a purple team engagement, as we're executing and doing different behaviors in your environment, you're able on the spot to determine, hey, are we seeing alerts? Are we getting logs? Is the stuff ingesting properly? Or do we have a visibility gap? Is something wrong here or misconfigured? And on the spot, you've identified the gap, you can provide a solution. Sometimes, depending on your organization, if you don't have a crazy six-month change control review board, maybe fix it on the spot. So now it's not even a problem. And not only just to fix it on the spot, like for example, if you know that you're missing a log or

you don't have one of the buttons turned on on your EDR that enables some other kind of logging, if you have the ability to in your organization, you can turn it on, rerun that same procedure we just ran and know immediately if you're able to see it. There is no waiting until much later or thinking that this is going to find it. You you can prove it. And that's really the true benefit of this collaborative nature of the purple team. The end goal being to get to something like this, an operationalized purple team. This is just a kind of a more expanded diagram to show you everything that kind of goes into it. All the stuff

you would think about. You're not here to learn about purple teaming 101. So, I'll just leave this up here for a second, then we'll move on. But wanting to show you kind of what the actual end goal is and everything you need to do this. >> Yeah. And to hit on this too, I know that Trey kind of talked about it, but not all purple teams are technical. You can have tabletop exercises. Um, maybe you're not ready or there's no trust yet, which we'll talk about how important that is in a little bit, but maybe they don't want you to deploy some emulations in production or or demo or or prod or wherever. Um, you can run

these like almost thought exercises tabletops with all of the all the stakeholders with your blue, with your legal, with your red, with everybody and think what's going to happen almost as a precursor to actually performing the emulations on the endpoints. And that's a great way to to build trust, get an idea, start to see some value before you even get to putting hands on keyboard. >> All right. So, what it's in it for you to summarize the last five sides of quick TLDDR personnel, that continuous training and adaptation to the threats you're actually facing in real world. You're not just having someone throw some crazy obscure exploits or using something they tested out on Hack the

Box yesterday against your organization. you're actually seeing how you stand up to the threats you're going to face in real life. From a processes perspective, you're going to be able to streamline your your processes, your procedures, everything that you guys do, the typical operating um stance of your teams by running these engagements. Then lastly, tooling. Reducing noise, improving your response times, triaging less tickets. I know that's got to sound great to someone, right? So that's really what you're kind of looking to get out of this. So enough about purple teaming. Let's talk about the more fun stuff. So, we'll dive a little bit into red team combos, then I will let Tyler talk about some blue stuff.

>> Who understands what game shark is? >> Okay. All right. >> Who in here's too young to have ever used a game shark? >> Oh, man. >> Yeah, >> it's like a AI for video games. >> It's a whole different world now. >> Whole different world now. >> But cool. >> It still did the transition. >> That's fun. There's a really weird Easter egg in the slideshow. I just cleared all transitions and it still decides to do it anyway. But anyways, um first one, assume breach. And truly, whether or not you're doing these kind of things as an outside consult consultant coming in to help organizations or you're doing it internally, assume breach. Your customer

or your teams are going to thank you later. Now, now you might be saying, well, why? And oh, that doesn't feel like a real test. What's going on here? That wouldn't have happened if we wouldn't have assumed breach. That's not the case at all. We've seen it quite a bit. You can assume breach and save a ton of time, effort, money, and frustration on just trying to potentially get that initial impact, right? Who in here's had a user in their organization get fished before? More than half the team. Probably all of you in here, some of you just don't want to admit it. Who in here has read an article recently about a major organization that got hit by a fish or

some other kind of attack like that that caused a full compromise? >> Heard in the last hour that fishing is 100% effective, >> right? We all we all know it. >> So if you know that's the case, why waste the time? Why waste the money? Go ahead and assume one of your users is going to click the thing. You can avoid spending six weeks and the money it takes to have someone come in and do this for that kind of time frame and just already say, "Hey, I'm the user. I clicked the link. Uh-oh, we have a problem." And you're good. You're saving yourself so much frustration and time. How long do you guys think an average

pentest uh engagement or red team engagement is? How many days? >> Five, seven, two weeks maybe. How long do you think >> customer pays for? >> Yeah, exactly. >> We'll do it until you quit paying for sure. Let's say it's probably a week, maybe two weeks, right? How long do you think a purple team engagement is that we do? >> About four hours. >> Yeah. >> Eight hours on a on average. four hours to a day. If it's an organization that really wants to do some crazy stuff, two to three days. >> Yeah. Taking the assumption that you are going, you know, it's not the uh it's not the if, it's when, right? Everybody's heard that, I'm sure. Taking

that and really internalizing it and utilizing it saves you not hours, but days, but weeks. That's a ton of money. That's a ton of time to hire an outside consultant to come in and do all the stuff that you are pretty sure is going to happen anyway. Um, you can really save yourself a lot of time and money just by assuming the breach. >> This one here, this is actually really cool. We've got a little side note incident story for this one, but just crafting a good story. Something like utilizing CTI drops within your purple team engagements will really change how it all flows, how your teams interact, and what they're trying to accomplish. from this perspective.