Cinema

The actual technical parts of the talk that no one's going to remember, the access management in AWS and specifically in S3 and EC2 instances, we'll go over one tool that's absolutely free and how anyone can assess security and the first time we've been here, has it? We've had an S3 data leak affecting millions of people every six to 12 months for the past three years. This is ridiculous. Companies can save billions of dollars and we, the millions of victims, can be saved some unnecessary suffering with just 17 lines of JSON. I'm talking curly brackets and key value pairs. But today I really want to talk to you about the 2019 Capital One breach. The folks at Capital One weren't stupid. They didn't leave an open bucket with credit

card data out on the internet. Thank God. But

the problem was the attacker was able to get onto an EC2 instance through a misconfigured firewall and then from that EC2 instance access a multitude of buckets from there. My thought is why did that particular EC2 instance have enough access to S3 to download that much content? I blame DevOps. I blame company cultures that prioritize pushing features at crackhead speeds. We're building things fast and they're breaking down even faster. The DevOps cult, I mean community, community, community, has taken over. Everything is moving towards the automation and cloud. And we all drank the DevOps Kool-Aid and we're paying for it. The members of this community, yes, community, they're aware of my critiques and criticisms, and so there's a new term, a

buzzword solution for buzzword problems, DevSecOps. And

I don't like it. It's not, like, it isn't sexy, is it? Like, if you're on a date with another IT professional, you're talking, you have a really good time, and then you just whisper, DevSecOps. I think the date is over. I think everyone's turned off by that. So, no. And besides, security isn't something that you just throw on into the middle of things. It has to be thoroughly ingrained in the business operations. DevSecOps is out. But part of me wonders, why stop there? I mean, we're all part of the same team. It takes a village, people, come on.

So I'm arguing for a DevOps that values genuine communication between development, security and operations, not just automatically throwing the code faster between the silos. I'm arguing that every developer be trained to understand the security and operations requirements of the code that they're supposed to write so that they can write secure code that works. And in order for them to do that, we need to understand what's so complicated about S3.

So there are two options when we consider identity and access management in AWS S3. And I say options in the same way that I say seat belts and airbags are options. Theoretically, you can make do with seat belts alone, but let's use both. So the first system is IAM roles and policies. And IAM stands for identity and access management, and it's an entire suite of services Amazon uses for federating access between users and AWS services and interacting with each other. Right now we're going to focus on specifically roles and policies. So our best way to start this out is with an example. Now, I am both a developer and a security consultant for Secure Ideas. So

as a developer, I have within my developer role I have access to the source code. So within that role there's a policy I have at delimiting what access I do have. Same thing with my role as a consultant. As a security consultant if I have a bunch of MD5 hashes I can spin up a server for cracking passwords. So users can have any number of roles with any number amount of policies built in, delimiting and defining what they have access to. Now, not all entities are human users. AWS services also have their inbuilt roles. And one example I'm going to use is CodePipeline, which is an Amazon service for building and deploying web applications and services. So within that CodePipeline role,

It has to have an inline policy attached to it that allows for a connection to wherever you store your source code, which is GitHub, whatever, has to have the permissions to build that source code and then deploy it out to some system. People often use S3. And so that is IAM roles and those are IAM roles and policies. On the other side we have S3 bucket policies. Now this is its S3 bucket with its own locks and there are a massive number of options that you have in order to lock it down. It really depends on your use case. So you can use MFA, you can restrict it so that only people from certain IP addresses can attach and connect to it. You can also

encrypt the data on the bucket and make it so that only encrypted connections can connect into it. Or you could just leave it open which is something that you might need to do if you're just using S3 bucket to host a public website. So the granularity and the level of security that you're going to use depends heavily on your use case. And as we've learned many, many times If you have a wide open bucket, you leave your information wide open on your internet. But what we've learned from the Capital One breach is that if you mess up your IAM roles, you give certain entities way too much access that they do not need. And so secure use of S3 involves

mastering IAM roles and policies and mastering S3 bucket policies. Insecure use is just a few easy clicks away. So we'll walk through the steps right here. And I want you to know this is the security dumpster fire right here. So first you create the IAM role, then you attach the S3 full access policy. The process of attaching the S3 full access policy is four clicks. This policy is built in to every AWS account and it's easier and you don't even have to learn about identity and access management. It just works. So once you set up and launch the EC2 instance through the wizard, you connect to it, it works. So this step by step process is

the easy go to answer for how to connect EC2 instances to S3.

Now let's walk through the secure use of the platform.

Yeah. We'll walk through it. We'll walk through it together. So first, of course, you create the IAM role. Then you create and edit the custom S3 policy, which is this black magic involving curly braces and key value pairs. Then you attach that custom policy, set up and launch the EC2 instance, SSH into the box, try to connect to S3 only to find access denied. And EC2 instances have to be torn down in order to apply a new rule to them. So you have to start all the way back over to step two in order to continue iterating through this process. So I'm not going to lie to you. Secure use of the platform is difficult and tedious and requires a lot of trial

and error. And you know who's really good at doing as bashing their heads at machines, trial and error, to get something to work? Devs, make them do this. This isn't something you're just going to hand off to the security team after months of it already being in production. This is just the interaction between two services, EC2 instance and S3. When you have a full-on cloud native application, you have dozens of AWS services and connecting between them and troubleshooting permissions issues gets exponentially more difficult. So how can we assess security on AWS resources? Well, the tool I'm going to show to you today is freely available to anyone who's working on AWS. It's a tool that costs absolutely nothing no matter how much you use it. And so we'll

go into a brief demo on the AWS Policy Simulator. And just know that when I say free, don't have your eyes glaze over. It's genuinely free. It's not going to cost $400 next month. So.

We're live. Good. So we're in the IAM policy simulator. We are in existing policies mode. So the beautiful thing about this tool is what it's used for is running AWS services as if you are a certain user, a certain group, or having a certain role. And there is a built-in editor in which you can custom make policies on the fly and troubleshoot them a lot faster. So in here, we're going to just go into roles. We're going to go into the bad S3 demo role and we're going to see what the full access role looks like. So here is the full Amazon S3 full access role. Again, this particular role is built into every AWS account.

And if you set up an EC2 instance with this role, select actions, all,

and then run the simulation. Allowed. Green means go, right? Yes, for you and for the legitimate user and any attacker that has access to this role. So not only can they do simple things like upload and download files, they can also view the contents of every bucket in your S3 environment. In fact, some of these tools can, some of these actions in S3

allow you to delete entire buckets. It also allows you to create new buckets, lock down the access permissions of existing buckets and as a general DOS attack. So maybe your EC2 instance doesn't need to do everything in S3. So let's try a more sane approach and a more lockdown policy. And...

So here is an example of a more secure policy. We clear the results and then select all, rerun the simulation. And then we get a lot of access denied. This is a good thing. What this policy says is, hey, anyone with this role, all they can do is put object, which is a fancy way of saying upload a file, get object, which is a fancy way of saying download a file, and list the bucket meaning associate, look at the bucket, and it's all its contents. And we've locked it down to one bucket on AWS. So you'll see that a majority of the simulation resources on the right-hand side are wildcard star. So in order to run a simulation on a specific resource, you need to type in

the ARN into the simulator.

And in this case, this wildcard specifies all files under this bucket. And this is just a list of complex name denoting this specific bucket meaning some bucket.

And of course because I am typing live I missed a colon.

So copy and paste. Copy, paste is your friend. And then we rerun the simulation. We still get access to 9 for a majority of these actions. But if we go on and search for get object action, we see that that is allowed for a specific resource and that is for some bucket. We can download files, we can upload files, and we can list the contents of the bucket. When people think about using S3 to store files, this is the typical use case. 17 lines of JSON and this

could save companies like billions of dollars. So let's say it's already too late. You've already, DevOps has already taken over your environment and you've already have people, it's just disgusting cloud environment with just full S3 access everywhere.

How can we lock down those permissions for those people without destroying any existing functionality? Here we're going to create a new, we're going to simulate a new policy. So go into new policy mode.

Go in here. And because I've learned my lesson now and I refuse to type JSON live, We're going to use the AWS policy generator. And this is just a tool that we use to just create policies.

And so in this case, what I'm going to do is I'm going to use those changes that occur in AWS. So if someone is spinning up an EC2 instance to run a container, mention that in the pull request. and this is the part where the security team can come in and embed ourselves and as security people we can embed ourselves in the process of having that review of the code while it's being built versus at the end. We can also use CloudFormation templates and other systems for infrastructure as code so you can have those changes already built into the code base. Second, we need to make sure that isolate resources and deescalate permissions. We understand that you've got to keep things separated in on perm environments.

You really do need to do so with cloud environments with a literal price tag attached to it. So my suggestion is make sure that your staging environment is separate from your production environment. So if the devs do something weird in staging, Production, all customer-facing data is protected. Also, do not use full access permissions. And please, if they're setting up a policy that has a bunch of wild cards in it, ask them if they can pare it down a bit. Then for step three, this is more of a cultural shift. You have to get the devs to understand that security requirements lead to bug fixes and feature. Security patches are bug fixes. And security improvements are features. They need to be baked into

the sprint and done and treated as such.

And while they're working on development, they can use tools like AWS Policy Simulator to pare down the permissions that are being used. Using all the techniques that we've discussed, we don't have to be left with DevOps that looks like this or this. And we do not have to have security that looks like this.

We can, together we can redefine together with security, development and operations working side by side, we can prevent many of these major headlines. If the attacker gained instance, gained access to that EC2 instance and found out that it only served some minor administrative role and only had access to one bucket, perhaps we wouldn't have to deal with some of these headlines. And those companies can save billions of dollars and the rest of us can be saved a lot of suffering and misery. We're all on this journey with an ultimate goal of making the world a better place with technology. Along the way, disasters can and do happen. And we can prevent most of these with a little training and

a little collaboration. If you, and there's a little proverb that I'm going to, that I've copied and pasted from the internet and I will say to you today, if you want to go fast, go alone. If you want to go far, let's go together. Thank you for your time.

Any questions?

Oh, the entire slide deck is at that link at the bottom. If any of you want to see sources for a lot of this material, also feel free to blow me up on Twitter and my email address.

Yep. Yep. And I'll just unplug.

that I'm off the stage I can pack that up as a separate process yep yep thank you so is there any adapters for HDMI or no no okay so I got on have a display port to HDMI so where does the HDMI where does this cable go to

I might have to go up there and ask yeah

We'll do a sound check.

on this side. Right there. Yep. Oh, other one. I had to flip it. There we go. Perfect.

Right. Right. Okay. Did you have audio on this as well? Yeah, there's audio on it. There's some weird stuff going on with how the screens are being done.

So I've got four different screens on the Mac, but for right now, that's acting.

The USS Defiance.

It's not fun to have your two ton SUVs brakes just as you're parking in front of a day.

Hello, B-Sides. All right. So our next speaker here is a lead security operations center architect at Block Harbor Cybersecurity. Mike lives to crush the deliberate denial of the emergency that is the cyber to physical security landscape. Just because it's not easy doesn't mean that we can't put our hands over our eyes. slip on our headphones and ignore what's happening. So Mike speaks, writes, and works in the field to help people recognize and promote positive solutions that are so desperately needed. Mike works in the automotive and financial cybersecurity fields. Yes, he is a truly multifaceted cyber warrior. He currently serves as the lead security operations center architect for Block Harbor Cybersecurity out of Detroit, Michigan. and is the chief information officer of a financial analytics startup, RapidCat,

based out of Raleigh, North Carolina. After realizing glaring vulnerabilities in financial technologies and e-commerce systems early in his career, he's since pivoted to securing systems to include software, web applications, and now his research is in the cyber-physical technology arena. He's a passionate researcher in exploring the increased attack surface that cyber-physical devices present in our everyday lives, exploring what can go wrong and how to secure IOT, ICS, IOTM mobility infrastructure that humankind relies on to push towards increased technological advances and keep people safe every day. Since cementing his expertise in this arena, he's taken to the public stage, presenting his insights and finding through a number of talks, conferences, and panels. And we are really happy to have him here. Besides, RDU is also

presenting him with a speaker gift, a sneaky book. So welcome to the stage, Mike Curnow. MIKE CURNOCKIFFEY-

Thank you for that very short intro. Anyways, yes, the moment that we've all came here for. So why we're at B-Sides 2019 right now. The Intermediate Guide to Navigating Active Directory.

No, I'm kidding. But the rest of the presentation is gonna be that much more interesting. So set the bar low, yeah. Any who's, but yeah. So welcome to, let's get cyber physical. Learn it.

See it. Secure it by yours truly.

Wait for it.

OK, that's me. So I have 60 minutes to cover a lot of shit, so I'm gonna be speaking pretty quickly at some points. So I'm gonna just get that out there beforehand. So who am I? A little bit about me personally. I'm always tripping or falling.

As a me at my baby shower, I tripped, someone caught on camera. I don't really get art. I liked fidget spinners.

That was staged, that wasn't candid by the way. And I have a hard time being comfortable while wearing a suit. Belong to a very distinct group of people. So the professional side, got my start in financial technology. Worked as a software integration engineer. for a financial tech company and Basically I was writing code to do things that would now be used for a mage car which is the injection of Frontside code that scrapes payment information sends it to a place I wrote it in a way that sent it to a financing platform that would you know run your eligibility and fraud checks through different lenders that kind of thing and I was the head of security services

for an international MSP. Formerly a programming cybersecurity instructor for the Coder School. Did that for about three years. Currently the lead security operations center architect for Block Harbor Cybersecurity, which is a cybersecurity firm based out of Detroit, Michigan that specializes in cyber physical security. So securing things that start with a digital instantiation that have a physical effect in the real world. And we have a foothold in mainly automotive. So working with automotive OEMs to secure the cyber physical systems that they use in the manufacturing side and or the dealership side. So like when you go get your car fixed. They use devices that plug into the vehicles and they connect to the cloud and all that kind of cool stuff.

Co-founder and Chief Information Officer for RapidCat. RapidCat's a financial analytics startup that basically tries to, we use machine analytics and pretty complex stuff to try and help lower the barrier of entry for people trying to get to the 4X binary market. Trying to make it easier so everyone can do it. You wouldn't think it, but I do a lot of public speaking. This is my fourth out of five conferences this year. do different panels, meetup talks. Just got done doing a two-day, six-hour cybersecurity seminar, which had my throat dead.

And so a little bit about my experience. The compulsory red team side, I got my start in doing penetration testing and then a senior pen tester. doing vulnerability assessments, social engineering campaigns on different organizations. I have done defensive security, blue team side. A lot of what I've done is mainly in the development and architecture of security operation centers. So basically all the plumbing and whatnot that goes into gathering and aggregating data from multiple sources, centralizing all that, doing the analysis and doing all the correlations, setting up the alerts, and then setting up also the policies that people follow in a SOC. Then industrial control systems. I got my start doing a SCADA pen test on a major piece of Metropolitan

Public Transportation. That was my first exposure to it and after completing that test I ended up falling in love with industrial control systems. Then on the research side I spent a lot of my free time really specializing in the ICS and OT convergence. So basically converging physical systems to talk to cloud systems in a secure manner. And working in IoT, so there's doing stuff with MQTT brokers on the IoT side, just a device-a-device protocol that lets devices talk to each other in the IoT realm. Automated tank gauges, did a lot of work with identifying tank gauges that are out there. These tank gauges are open to the internet for gas stations so that they can

hook up their gas stations to different management platforms. Another part of the ITOT integration. Then a lot of IOMT, but mainly in insulin pumps. So basically automated insulin pumps that you have either a phone or a management handheld device that allows you to manage the operation of an insulin pump that sticks into your arm Really good stuff, really convenient, helps a lot of people out. A lot of RF type hacking, mainly just a lot of capturing signals, replaying them, seeing what works, what doesn't, trying to break some decryption on captured signals. Then my latest and greatest thing that I've been spending a lot of time in is identity defined oriented network, which is basically adding a new layer, or sorry, a new

namespace to the network conversation. So you've got IP address, you've got DNS, and then you have the actual host identity, which is a cryptographic identity that's used to solidify the identity of the device you're talking to so you know you're not getting spoofed. So, What I'm gonna be talking about today, cyber-physical technology, what it is, why it's important, or what role it plays in our lives today. The problem, which is security. Security is the problem, or lack thereof, you dig?

Facets of cyber-physical security. So basically, going over the different realms of cyber-physical security, We're going to be looking at internet and medical things. We're going to be looking at automotive, like connected cars. We're going to be looking at industrial control systems. It wouldn't be a Mike Kernow talk if I didn't beat the dead horse on ICS and then beat the dead horse of its next of kin multiple times. Then we're going to do attack scenarios. It's a combination between some demos and movies I have. do an IOMT, automotive, ICS. And then we're going to talk about some prospective ways or ideas or mindsets or notional concepts, whatever abstract term you want to assign to it, ways to secure

these. So these are just to kind of get you in that mind space. and there might be a surprise parting gift later if it works. Any who's, yeah, so to kind of dig right in or get right into it, cyber physical systems are systems that are comprised of interacting digital, analog, physical, and human components engineered for functioning through integrated physics and logic. Basically, it's just you have an electronic thing that happens on a computer somewhere that then turns into a reaction in the real world. So like the factory equipment or something, right? It's the easiest way to think about it. Cyber physical security is protecting the assets on network from a cyber attack wherever physical

harm can be caused. Physical harm, damage to property, loss of life, these are all things that we want to prevent, I think, right? The importance of cyber physical systems, they are pretty much embedded in our

society and they're going to keep getting embedded in our society. So I have this definition from CPSC Labs here. CPS or cyber physical systems are identified as a core enabling disruptive technology that allows us to continue all the stuff in embedded systems and it basically helps us tackle a bunch of issues. And I'm not going to read the whole thing, but I'm sure you can read that. So to kind of get a better grasp on cyber physical technology and the importance of it and why I'm talking about it, we need to talk a little bit about the industrial revolutions that happened before now. Right now we're in industry 4.0, which is basically the computerization and the interconnectivity of everything. But we need to

do a little history lesson on what happened before. So I'm going to try and go through these relatively... So you have Industry 1.0, the mid to late 1700s. That's when we kind of pivot our economic structure from agriculture to industry. Then we have steam engine, coal mass extraction technologies introduced, and then the acceleration of economic material and human driven exchanges. So we have locomotives and railroads for goods and people transportation. And then that inherently created the foundational blueprints for industrial factories today. Industry 2.0 that takes place in the late 1870s and we have new energy introduced like gas, oil, electric, combustion engines created that also subsequently creates a need for steel. So the steel industry grew exponentially. New

communications like telegraph, telephone, along with transportations like automobile and the airplane. Industry 3.0 starts in 1969-ish. We have new energy, which is nuclear. We have new electronics, so we have the transistor, microprocessor, all that stuff listed here. Miniaturized materials, space research, biotech. Then revitalizing the industry through automation, right? So that's robots and things that constitute industrial control systems. And Industry 4.0 now is a little bit bigger. We have the nine pillars of Industry 4.0. So we have virtual augmented reality, additive manufacturing, building from the bottom up instead of taking raw material and chiseling away at it until it becomes what you want it to be. Internet of things, which is everywhere. Big data, cloud computing, advanced simulation, Autonomous robots

to think, act, and react. Universal integration, just basically the interconnectivity from systems to systems, which is a huge part, and then cybersecurity. So cyber-physical exists in the majority of these different pillars in different ways. So without cyber-physical systems, our Industry 4.0 advance isn't really gonna happen. and we need cybersecurity to secure those pillars and to secure the universal integration.

Cyber-physical systems are everywhere. That's what this graphic is denoting.

The problem, which is security, or the lack thereof, I'm going to get into a video here, just kind of identifying the process of

provisioning a cyber physical service, the use of it, and then how it can go wrong.

This might be a little bit loud at first. I'm going to try and temper that down a bit. If anybody is familiar with the show Black Mirror, I think you're going to recognize this episode. If not, that's fine too. But just a piece of context there.

Keep my hand the volume just in case.

That's the problem. Bees went extinct.

solution which is fake robot bees to supplement.

And the problem with this is

dead body.

Whoa, no way.

That's how they work.

And then the aftermath or the dumpster fire, notional dumpster fire.

We don't want to be saying this, right? We don't ever want to get into a situation where we find that we have a problem, we find a solution really quick, we throw it out there because it's feature-rich and people will love it and it'll make lots of money without securing it first, right? So this is, again, from Black Mirror. It's a little bit of hyperbole in here, but the idea is still the same. These cyber-physical solutions can be put out into the ether without proper security. So it's basically kind of like a drawn out, crowdsourced QA problem. So the facets of cyber physical technology, there's a lot of them, so I just kind of put what I could on this slide here. But if you were to imagine that

this sphere represents cyber physical security Then also this spinning dodecahedron is a representative of the multifacetedness, which is a word, I think, of cyber-physical. And the cool thing about a dodecahedron is that you can always be friends with it because it's a platonic solid.

Yeah, I knew it was pretty good, right? Okay, so to kind of draw upon this a little bit, or dig into this a little bit more, you have this diagram right here that kind of illustrates the taxonomy of the cyber-physical systems. And we can see cyber-physical systems are feedback systems that have humans, economics, and loop. They require cybersecurity, improved design tools, and design methodology. And they have applications in all of these right here and then some.

This diagram came out of a project that somebody was doing through the NIST project, or for NIST, and then coming up with that. To get a little bit more into this, we have Smart Grid. Smart Grids are pretty much just an electrical supply network that uses digital communication tech and smart meters and appliances to detect and react to local changes in usage. And we have robotic systems, systems that use sensors, actuators, and human interface to provide intelligent service and information by interacting with their environments. Then industrial control systems, collective term using to describe the different types of control systems and everything associated with that, including all the instrumentation. So the devices, the systems, the networks, and

controls that are used to automate industrial processes. manufacturing plants, light electrical, water treatment facilities, that kind of thing.

Automatic pilot avionics. So automatic flight control systems, they're just the systems that control key operations of the plane in its flight. So they also control, they also handle electronics and stuff, things for like communication, navigation, collision avoidance, and weather. And The original use was just to provide a pilot relief during tedious stages of flight, such as high altitude cruising. But advanced autopilots can do much more carrying out more precise maneuvers. And we have photovoltaic systems. These are basically just solar power systems, right? So it's a power system designed to use solar power as a means of energy. And so, I actually found something in the wild that was pretty interesting. There was a school in New England that's kind of well known

that purchased a plot of land a few years ago. It used to be like a reform school or a boarding school or something, and they bought it. They bought this land. They're like, hey, fuck it. We're just going to put solar panels everywhere. And their control system was open to the internet. And so I found it. I found...

It was the technology that was well known in that space so you can just find the default logins and get in there. But also it runs over Modbus so you can do pretty simple queries to the Modbus controller. Turn it off if you wanted to really, which is pretty dangerous. But we let them know. We let them know this and we gave them pretty much all of our research and said, hey, please fix this. Half of it's fixed. can't get into the control panel, but you can still talk to the controller. So essentially it's not fixed. Connected vehicles. Vehicles are now equipped with internet access and Bluetooth and other ways of doing fancy communication stuff. Connected cars, the hope for the future is basically

that cars can talk to each other and trade important safety and mobility information in transit. Then next we have the Internet of Medical Things, or IOMT, which is basically, it's IoT, but specifically for healthcare devices. So things like blood pressure monitors, x-ray things, pacemakers, the insulin pumps.

Smart homes, which if you can find a lot of these on Showdan, there's a lot of them in upper New York state. I didn't tell you that, but I just happen to know a guy. Yeah, so much other shit. It's everywhere and in everything and will be in everything. So smart toilets, right? Kohler has, they're selling a toilet now that has Alexa built in. Yeah, so imagine...

Imagine like your significant other, in my case, my wife leaves the house really quickly and leaves her keys inside and is knocking at the door. While defecating, I can lean over and say, hey, Alexa, unlock the door because the Alexa from my toilet will be connected to the smart home system in my home, controlling the temperature and the door locks and everything. So we are entering the age of Wally.

That's just one man's opinion. And again, I tend to be a bit hyperbolic with some of these, but it's just really me trying to drive a point home, you know? So the three facets we're gonna be concentrating on today are internet of medical things, automotive, and industrial control systems. So some of you have been to my talks before, we're sat in on other presentations. So some of the ICS stuff will be a little bit familiar to you, but I added some extra spicy things at the end, so I think it'll be really interesting for you all. So yeah, without further ado, let us begin. See how I did there? So yeah, internet medical things. We talked a little bit

about that, but basically what the internet medical things is is a way of IoT expanding into the healthcare space, right? And so we have Pacemaker that connects to an app on your phone.

Pretty cool. The idea of it's pretty cool, right? But the security implications are very wide. Now this particular application, I did do some research on it, and it says that only ingests data coming from the Pacemaker, but I need to get my hands on one of these. And then next, I've done a lot of research in the insulin pump arena. So really the things about the IOT is, or IOMT is, they lower costs. So like using IOT solutions and connected medical devices allows healthcare providers to monitor patients in real time, meaning like less unnecessary visits to the doctor, less hospital stays and readmissions. There's a better patient experience because being connected to the healthcare system through the internet

of things, patients get more engaged in their treatment. They're actually more of a part of it, and the doctors can improve diagnosis accuracy since they have all the necessary data on hand already before the patient even comes in. Better management of drugs and medicine adherence. So, excuse me, basically allowing staff to spend less time searching for drugs, tracking supplies and medicine, and all the logistical... and track hygiene practices in hospitals, make sure that they're effectively preventing hospital infections. They also help patients adhere to the treatment plans and the doctors to kind of maintain that integrity for them, making sure they're staying on track with their medicinal regimen. Reduced errors and waste. So using IoT for data collection and workflow

automation is a good way to cut down on the waste. Reduced system costs and minimizing errors, especially ones that can be due to the human factor, right? Human error. And improved outcomes of patient treatment. So healthcare solutions that are connected through cloud computing and using the big data can provide caregivers with the ability to access the real-time data they need to better take care of their patients. So here's a video. Here's a video that I did. This is, I have a insulin pump and I do some, I'll talk through as I'm going through it. So basically here we have a Omnipod PDM. We have an insulin pump that you can put insulin into. It works better

with this syringe. we can see that we can capture the radio frequency signals that it's transmitting trying to find a pump to contact or sync with. So that's just a bunch of that just using an SDR sharp to end a RTL-SDR antenna dongle to just capture those signals. And so for kind of a notional demo here, I have a dog that's pretty loud, right? And I have a newborn. And the ears are very sensitive. So when the dog acts up, we have a shock collar that goes around his neck. We don't need to use the shock option because it has vibrate and it has noise, right? And also I couldn't bring myself to be one of those people that shocks your

dogs on a regular basis. Yeah. Yeah, they are monsters. So I'm using this to display front to back how you can transmit, receive, capture, replay.

Or we can just go back to the beginning.

Okay, so we have the remote. It allows you to send the shock or the vibrate or sound command. And when I hit it, you can get these three little blips, right? We don't really know what that is. We just know that it's there and we can capture it. And I created a kind of a DIY hack RF because I didn't want to pay for it when I figured I'd just buy the parts to make it myself, which I'll get a little bit more into that in depth a little bit later here. But... We can capture those. That's what I was doing here. We're capturing those radio frequency transmissions there.

So we're going to replay it using the DIY HackRF, which is what we're doing here. And you can see that those same blips more or less come back to us. So I can just take my DIY HackRF there and just walk around, you know, zapping the dog if I wanted to. So another thing too, it's a little bit scary. So that example was just kind of show how you can use open source tools to go ahead and capture these transmissions and replay them. But the thing about the pumps that are scary is that you can set the bolus amount unit here to the highest is 15.50, but I put it to 15.45. And

you can basically say, hey, give me 100% of that right now and capture that signal and then replay it. Same with the dog collar. And so then you die if you have diabetes. I grew up with, like everyone in my family besides myself has the sugar diabetes. And so I told this to my uncle and his face, normally like a rosy red, went to pale. So that shit was scary. And it is true, it is pretty scary. He is my favorite uncle.

Wait, did I just say that on here? Oh. So really quickly, just to get into some of the components and what I did here to make this DIY HackRF. It's just, so I got a Raspberry Pi attached. There's a screen with a adjustable angling there. Power source and a keyboard and RTL-SDR dongle. And,

On the backside, you can see here, there's a... I had a broken mini USB charging cable, so I just kind of snipped the end of that, placed it on GPIO pinout 4, and that's when you're using RPiTX or the transmission app for Raspberry Pi. You want to have it on GPIO pin 4 because that's the output, right? So it allows you to transmit signals like we saw in the video. And... Yeah, the Raspberry Pi, Raspberry Pi 3 is plugged into the back here. It's got the pins exposed. That's just the receiver for the keyboard.

Yeah, so if you wanted to kind of branch out and abstract from there, you can purchase the How to Be an Asshole 3000 kit. This is, I just bought it cheapo drone on Amazon. I have a Raspberry Pi Zero that I wrote a Python script for that takes any EQ files or radio transmission captures and just loops through them. You can also make it so that it loops through different frequencies as well. So if you do have frequency hopping going on, hell with that. Maybe we can take care of that. And that too has a cable that's plugged into the underside of the GPIO pins that are exposed in the bottom. And then, so this is a notional concept. You can

physically do this. I just need a smaller power source and a Velcro. See, there's no Velcro there. If I had Velcro, this is the specific place I would put it in this picture. But I don't.

Yes, yeah, I can. The Velcro aisle. So some proposed security solutions for IOMT. I say proposed solutions because the devices that are out there that do things like this, they're vast in the protocols and the way that they do stuff is all different. So one way is a unique signal for every insulin pod pump. This is something that they do with car fob keys. So like with newer cars now, each car has their own you know, signal when they communicate with the key fob to the car. Adapting that same methodology and mindset to IOMT devices utilizing RF frequencies would be another one. A way to do that, I think is a good one. So making each pod unique, decreasing the attack capability to a single pod. So

that way, if I have the captures that I took, I can't just go around killing diabetic people. I got to capture each individual one

But yeah, instead of one signal to rule them all. Rolling codes, also known as hopping codes, transmission frequency from the personal diabetic man, that little handheld thing, that frequency changes upon each use in session. So you are doing frequency hopping, but frequency hopping coupled with the uniqueification of individual pod code would suss out a lot of these a lot of the attack surface there, or the attack vectors, I should say. So yeah, transmission frequency changes upon each use, and the code would be stored in the pod themselves, ensuring that unique transmission across all insulin pods. That way you can't just take one PDM and manage it, manage different pods, and then have to, like the code

that makes the communication unique is stored in the individual little white insulin pod pumps themselves. Yeah, so getting in the mindset of that, I think those are good ways to secure RF. So here's the thing, though, too, is that this is known, right? This is known stuff. And if we go on to GitHub here at OpenAPS OpenOmni, we can see that a lot of people have done some of the research before me. So they've done some of the work before me, meaning that they have these... they have all of these captures done, right? So one that I want to show you, the bolus packets. Here is the signal. I knew that.

So we can see here that we're confirming our units to this. It's basically somebody decoded the CRC encryption on these radio frequency signals and put all of them out on GitHub. So if you have little free time, you can kind of do an abstract step of stuff that I had done. And there's also a tool out there specifically for the RF transmitting insulin pump pods called RTL Omni. It's basically a Python wrapper for the RTL SDR application on Linux, and it is written to use the CRC decryption of Omnipod transmission signals. So instead of fixing this, apparently the solution is to just allow Bluetooth instead. Which I'm not joking, that's what they're doing. Yeah, so

next, automotive connected cars.

So here we have a few different pictures.

On the left here, we have what is called, what we in the biz call a buck, which is basically, it's the car network, right? So if you're to strip out all the physical mechanisms and everything in the vehicle, you're left with the CAN bus and ECU network and all the wires and stuff that go into it here. Then, Yeah, just a couple of illustrations denoting the increased use of connectivity in vehicles. So the vehicles are pretty interesting though, right? Because early on, there was no connectivity to a network, right? That just wasn't there. It's all physical. It's all mechanical functions. And in the 80s, we have the introduction to in-vehicle features, so sensors,

electronic fuel injections, digital gauges. And then in 86, the CAN bus or the CAN protocol is introduced and the CAN bus is just a, it's a network that ECUs or engine control units use to communicate.

And so that's there so you can just add ECUs to the network easily. And then today we have approximately 200 ECUs in some cars. And so Also new cars have new internet connections, which is the connected vehicles, right? So cars are becoming more and more data. And the vehicle attack surface is increasing to

meet the need of these new features. Faster than security professionals can take action in most cases, I think. So we're gonna get a little bit into the CAN bus network, which I don't expect everyone to remember all this stuff specifically, but the idea is just to illustrate how the buck that I showed you, this is kind of how it works in an architectural sense from a high up level here. And the idea is that we want to prevent somebody using the onboard navigation system to pivot to the brake control of the vehicle, right? Which is possible. Getting into the CAN bus frame itself, The CAN bus frame is, again, this is not trying to get super technical in

it, but this will probably, this will come up later at some point. So just to have reference of it. So you have the start of the frame, which is denoted by just a single bit. Doesn't matter what that bit is, just there. The next, we have the identifier part of the CAN frame. And that basically just represents the, like the priority of that can message. Then next we have remote transmission requests and really all that is is that denotes if it's a data frame or remote request which you don't really have to know what that is. It's normally going to be zero for data frames and then the yellow section here is the length code so that basically says hey other ECU here's how big the

can frame is going to be and then the red field is is data. So that is the thing that is being transmitted. So when we're thinking of networks and stuff and looking at network traffic, normally we think of the TCI, TCI P packets, where you can see things that are very verbal here.

I mean, we all know what network traffic looks like for the most part, right? So we have the interface name right here. We've got the MAC address, the vendor, or the guest vendor, IP address communication, payload, all that kind of stuff. But the network, how you look at a network in a CAN bus format is a little bit different. You have your CAN frames look like this when you're sniffing the CAN network. So, To get a little bit more into that, a video demo. Oops, I had text here, my bad. So moving from mechanical to digital. If your brakes are mechanical, no cyber attacker can compromise them. You can cut them, whatever. But they're becoming less mechanical because we're introducing drive-by-wire, which is basically relying on sensors from the

gas and the brake pedal and the steering column to talk to the ECUs that control those operations in a vehicle. and then take care of that for you. And the reason that a lot of this is happening is that we're making this shift into doing things like park assist and drive assist, preparing for the potentiality of completely autonomous vehicles. I say potentiality because as somebody who works in this space, I know a little bit of the nuances that are hard to navigate around. Though some might say it's an eventuality because they're the ones making the autonomous cars. From a security standpoint, it's a little bit different. So CAN bus security. CAN bus, CAN protocol, CAN messages, CAN

frames, everything that you see on the CAN network is unencrypted. It's unauthenticated. And if you gain access to a CAN bus with other available modules, you can freely communicate to them.

Then we're introducing new points of connectivity. The TPMS or the tire pressure monitoring sensor. It's basically a sensor inside your tire that uses a radio transmission to talk to an ECU on the CAN network that receives those signals. In-vehicle, Wi-Fi and Bluetooth, some of you guys with fancy cars out there have internet and Bluetooth connectivity. And you have telematics units and head units Sorry, the telematics unit that talks to the head unit. Then you have key fob, which talks to the body control module, which is the ECU that handles your beep, beep, all that stuff. Then anything plugged into the OBD port. So it could be a diagnostic tool, could be a progressive, has a really vulnerable OBD2

dongle that you can plug in. Then you have data loggers. There are companies that provide services like vehicle analytics. They say, hey, plug this into your OBD port. We get stuff about your vehicle. That can be used for things like going to the mechanic or it could be used for trying to lower or increase your insurance rates. But they're creating an additional, they're introducing a vulnerability that was probably not there before with that vehicle by doing that. And so a couple attacks that can happen. TPMS attack. This is basically using an RF capture and replay to trigger a low tire sensor light on your dashboard. An innocuous thing in and of itself. But say you pull over at night, you try and check your tire and your

car gets robbed. It's like high tech. carjacking. Key fob relay attack, using radio to extend the range of a key. So like the key fobs that, the cars that have a key fob that you just have to be in the vicinity and you can push the brake and turn the car on without having to turn a key. Those require a certain proximity. So if I'm in the middle and I'm using a device to extend that signal from inside your house to the car, I can steal the car, drive it somewhere. only thing that sucks is that when I turn the car off I can't really turn it back on again but there was I'm pretty sure those those still in car just get parted out anyways and

then we have the vehicle bomb attack which is I infect my car purposefully and then I send it to the dealership which then uses these diagnostic tools that connect to the cloud and do these awesome diagnostic operations and whatnot, but by having an infected car, that kind of spreads some of that throughout. You don't hear about that too much, but it's a definite possibility. Short range wireless, so hacking Bluetooth and Wi-Fi the same way that you would on a network. It's the same thing, it's just in a car, it's not in an office building or an organization. And then long range wireless with 4G satellite radio doing, these are attack surfaces basically. So here I have a demonstration video in which I had set up a virtual car.

So think of the CAN bus network. Think of the buck that I showed you before. That's just digitized, right? So it's on my laptop here. I'm gonna play that. And so what we see on the left side, these are the CAN frames. coming in as they happen. So you can see right here, the gauge is kind of moving up and down a little bit. Then we have a control unit right here that just lets you accelerate or unlock the doors, do signals, stuff like that. So I'm gonna go through and just kind of do a couple of controls, increase the speed to about, I think, 80 miles an hour. do a couple things with the

signals here. So we're actually seeing the CAN frames over the CAN network as they happen. And so here we're increasing the speed.

And then I'm going to let off the gas, let that go down a little bit.

I'll do some other stuff. There we go. Unlocking doors.

And so I'm just kind of continuing to unlock doors and play with the controls there.

Not a lot of them. Some of them do have units and stuff installed, but as far as motorcycle can networks are concerned, I'm actually unsure. I can say it's similar, but I can't speak for it.

All right, so now what I'm gonna do is I'm gonna end up

sniffing the network in the same way, but I'll be doing an actual capturing those can frames that come through. So all the things,

I type slow.

I'm just gonna fast forward a bit here because there is a,

some stuff going on.

All right, so we're gonna play the capture that we just did.

While using the can sniffer there. The best way to do this example is to turn off that controller, that way you're not keeping things going on the UCU network there. But yeah, so

with doing a replay, the replay is playing now, so it takes a second and you'll see the car automatically speeds up. And this is scary. So like imagine you're pulling up to an intersection and your acceleration ECU cuts off and all of a sudden you're slowing down, but then you're accelerating. That's kind of scary there. And to solidify some of what I'm talking about here,

will be

playing. Just got a few minutes of this here. A few years ago, a couple of researchers figured out how to hack a car remotely.

So pretty much, this guy's gonna be on the highway, and these two guys are gonna be controlling his jeep from their home. Now they're sending the same sort of attacks remotely and I have no idea what they might do. He's going this fast as I've seen him. So first we're gonna turn the fan on him. Yeah let's turn the fan on so he even notices. Alright all the something just turned on all the fans and AC and stuff. I didn't do that. The trick started small. Oh my god.

For time's sake, I'm gonna... X-price some of this here. There we go. On the highway.

on the gas but the jeep slowed to a crawl I turned on my hazard lights but I was still stuck in the right lane with no shoulder to escape on yeah so pretty much she had to turn the car off and on again typical IT reaction right so let me get back here I'm kind of speeding up some of that here cuz I'm eating up a little bit of

Let's back to there. Okay, so proposed solutions for automotive security. Secure gateway. Secure gateway is basically just segmenting the CAN bus network, basically the same way that you would an IT network in a sense. Considering the OBD port, untrusted, so anything that can stick into your car from the outside should always be untrusted, and it would require an unlock signal from the car itself to be allowed through. So diagnostic tools do have internet connections. They can get unlocks from OEMs, and they can pass to the secure gateway. Basically, a network segmentation. That's all I'm trying to say. Network segmentation, so you have a telematics unit, you have an OBD port, and go in, and then if you're talking

to the head unit here, you can see each of the ECU networks for powertrain transmission is split off into two. Body domain, safety chassis domain, that's all split off from the non-secure side of the CAN network. It might look a little bit different, but if you work in networks, you'll understand the process of network segmentation here. Vehicle intrusion detection system. There are a few companies that are doing this already. Karamba and Israel based company is one of those. What it really looks like is the putting analysis on the gateway module, doing anomaly detection. ECUs have standard communications. So if there's new stuff going on in the car, you can do that anomaly detection in your intrusion detection system. And Kind of going

from there, it's like, now you notice something weird's going on with the customer's car, what's the next steps from there? We don't really know. Honestly, we don't know because there's a lot of liability issues to hammer out. So while the technology is there-ish, it's not integrated, so it's still a concept. But the idea being we can put sim, see them in cars. That's really it.

And so here's what that might look like from kind of a optimistic point of view here, having an actual security operation center that's taking in info from all different data sources and working that in like a security operation center would. Okay, getting into industrial control systems. That is...

We covered that a little bit before. It's a term that covers the control systems and everything that goes into it. And we get a little bit into SCADA as well, which is basically like the management network stuff for it. I'm gonna be blown through some of these here, just again, time-wise. Where are they? They're everywhere. Straight lights, water treatment facilities, solar farms, oil production lines. Those of you who have been in some of my talks, I bring up the Klondike factory example. I will give the same disclaimer that I do. If you've ever been to a Klondike factory and you want to correct some of the things I'm talking about, I don't give a shit. I don't care. This is just to denote a process

in how controllers control things. So I'd say in the Klondike factory you have the machines that make the batter for the ice cream, you have a refrigeration unit that refrigerates those, and then you have the things that go into squares, right? Once you're in squares, they are packaged and shipped off. So you have PLCs or programmable logic controllers, which are tiny computers that manage the processes of each thing. These controllers can hook up to HMIs, which is basically just the point-click interfaces that might sit in the cabinet somewhere. And the way this works is that in the process, PLC, one that manages the batter stuff, that will say, hey, we're good, and send a message

over to the next PLC, which then says, hey, we're good, refrigerate. Once it's refrigerated, it goes to the next PLC saying, hey, put the shit in the squares. Once shit's in squares, you then move it over to packaging and shipping out, right? That's an easy way of just getting that process in your head. And in this manner, if one PLC fails, the rest will not work because it's relying on signals saying that the process is done. PLC is a small, rigidized computer.

Normally you put these on racks You can have a PLC unit right here. You can be adding additional CPU or an RTU, remote terminal unit or something, and then that rack goes into a cabinet. And you can also have a long distance connection to the device itself like that so it controls something from afar or right next to it. Programming languages, there's a bunch of programming languages right here. Letter diagrams, sequential function charts, Basically, a lot of these are ladder logic or abstracts of ladder logic. Multiple protocols used. So PLC manufacturers, a lot of them will kind of make their own secret sauce, right? They'll say, hey, this is my communication protocol. And there's no real standardization of that. There are some, there's the

IEC, but these are, a few different protocols that are used for PLCs to communicate. And function codes, holding register addresses, programming coils. Programming coils basically consists of ladder logic drawings with a binary output. Holding register addresses are 16-bit words that are numbers. It's like counter presets, accumulated values, math results or whatever. SCADA, Supervisory Control and Data Acquisition. This is just saying this is the top of the hierarchy. This is, you can control and delegate tasks to different PLCs from there and do all the analysis and data gathering from there. I'm not gonna read all that. We'll be here even more past lunch. So

this was how like a, SCADA network from a very high simple level can look. You can also have a PLC that can, you can have a controller that controls the controllers. You can have the SCADA device and you can have a controller that controls the controller that controls the controllers. Or you can have a SCADA device with a controller that controls the controller that controls the controller, right? You get the message okay. It's just But again, just trying to drive that point home here. So what we get into with industrial control systems is ITOT convergence. I talked about a little bit this before. Basically taking the operational technology network or the IOT, industrial IOT network, or whatever nomenclature you want to use, basically saying, take this and

I want to talk to the IT cloud analytics system doing everything remotely, right?

So that's when we get into bridging the air gap. That's the process of making those communications secure. So the concept is that physical gap can stop attackers, but the idea is if you want to do this convergence, you can't really do that. And so the goal of it is to take the operational technology network and to marry it with the IT network to work with each other. And then the expectation is that things will work in harmony, like this oddly is.

But then what really happens is large influx of companies and then these rush to meet industrial relevance, new features of communications, management, analysis, tools, all the flashy stuff, right? And so you have organizations that rush to bridge this gap and they drop the ball. Drop the ball, the ball is security. And then there's Bomber and there's Fire. And then there is this guy falling flat on his face. And just to get into a little bit of some scary stats, these are things that I've seen within the past few months. These are just different types of PLCs or SCADA devices that are open on the internet now, or they're visible on the internet at least. So we can see Modbus,

Tritium, and Siemens are three of the bigger offenders here. And again, putting your stuff on the internet is just asking for things to hit it. And the way that these communications work is that if you have a PLC or a SCADA device on the internet receiving signals it's not expecting to, things will break. Okay, so.

Really quick, I've got a quick live demo that I wanted to do

gonna miss the demo. They're lost. Yeah, so I'm gonna go ahead and... Yeah, I am fully aware that it's gone a little bit over, but I'm lucky to have the lunchtime spot, so... Thank you. So I'm gonna get into a tool that I actually released open source at KakalakiCon this year called RapidFire. And RapidFire is a tool, well, when I did my first pen test ever, there was a lot of iterative functions and things that I had to loop through that the tools that I was using at the time were only accounting for single interactions. And so iterating manually would be a pain in the ass. So I created a tool that would rapidly query the things I

needed to, hence RapidFire, because it would rapidly fire off the queries

So

a virtual PLC running, right? And so we're gonna enter the Modbus module of rapid fire. And we have a few different options here, but for expediency's sake, I will just go into the Modbus testing framework, which is, I'm doing that thing again. Why didn't nobody say anything? Thought I was sharing it. Here, I'm just gonna mirror displays.

a little bit easier for me yeah so uh here we have uh rapidifier we're inside yeah let me let me get back out real quick this is what it looks like when you open it uh we're going to go into the mod bus menu here we're going to go into number five which is this mod uh framework uh whoops

and we're going to go ahead and get the functions of a target PLC.

Let me just set these real quick to our target PLC, which is home. We're going to... with UID to one, because I know that UID is one. And we're gonna exploit it. And we're gonna identify the different function codes that are on the virtual PLC. The function codes basically say, hey, this is what the PLC can do, right? And once we have a few that we can see here, we can see that we can function code three and function code

16, that's active, meaning I can read a register and I can write to it, which is a no-no. And the same thing with coils, so code one and code 15 are active. So what I can do really quick is, I'm gonna open up a new tab here and we're gonna take a look at what these look like.

And what we'll do here is just set up a watch for the device's current.

That's the coils. I don't want that.

Okay, we'll stick with the coils then just for expediency's sake. All right, so we can see this is just binary output. This is the logic of the controller itself. And we go back into the Modbus. We can go into coil injection, target IP address, put it in there. Please enter start address, that'll be one. And address will be 19. And what we want to put in it, that's fine. We can see we just rewrote all the coils, all the coil values, right? That's a no-go because if you can talk to a controller on the internet, you can query certain things about it. You can see that the function codes are open. You can do this and break whatever processes those things control. So going back to the

presentation.

Okay, so demo time for that is over.

So we're gonna get into a little bit about the network. We saw a little bit of this before, but we're just adding in this little cloud analytics symbol here. So we're gonna do a little bit of a high level lightweight threat modeling, just very notional, very high level. What are we building? Secure architecture, conducive for ITOT convergence security. Again, it's gonna be that same diagram here. What can go wrong? Lots, a lot of things. Incoming communications from any kind can compromise the system. PLCs have very rigid communications they're expecting. So if anything kind of is off kilter, things will break. So here we have a trust barrier saying anything that goes out is fine, but anything coming in from over this trust barrier is not good.

So what are we gonna do about it? We wanna protect the network from unsolicited incoming traffic. And so by doing that, oh, we don't wanna do this. We don't wanna just stick it right on the internet like that. So we wanna test it. So when we have the network up, this is a unidirectional gateway or just a, I'm gonna get into that a little bit. But we're basically just having somebody test if they can try and communicate to the SCADA device or the PLC from the outside, much like I kinda just did the demo, right? I shouldn't be able to talk to anything on a PLC. It shouldn't be on any internet in that way.

Yep, that's redundant. So there are ways to secure this that I came up with here, or that I'm going to talk about. Combining, like basically just advanced network architecture, so combining layers and obfuscation and stuff like that. So we can have a couple examples here of a SCADA network that's segmented, basically separating the IT and OT traffic. Then we have another one where we have relay servers set up to send data out to the cloud if you really wanna do that. This segment to network handles just a relay server handling incoming information from here and it's over a one way VPN connection, some kind of network trunk going on here. Then getting more of the network trunk side, we're looking

at basically saying, if you don't know how network trunking works, this is kind of just a quick in your face, here's how it would look. Basically saying everything from the OT segmented network would talk to the segmented network for the relay servers coming out utilizing some kind of reverse proxy technology that if somebody were to try and get back to it, you might be able to reroute that to a honeypot, right? And you can send all this stuff to a security monitoring server, your IDS collector here. And you'd also have a tap or span port to do the same thing. And that's something I've set up a lot of times and it's a really valuable

thing. So, employing hardware at the network level, restricting traffic. This is talking about the unidirectional gateway. Unidirectional gateway is basically a network device that makes it so that traffic can only go out using a one-way data diode. And they exist both as hardware and software. Waterfall Security makes the hardware for it. And there's a tool called HairGap, which is a one-way network transmission. It works, I just don't like it as much. So this is what a network would look like that uses unidirectional gateway. You'd have the diode saying stuff can go out, but it can't go back in. Then we have this example again. The last way, I promise we're getting close to the envelope, I've got a couple

more slides left. The last way is using HIP. HIP is a host identity protocol. It's a host identification technology for use on IP networks. And we're basically adding a whole new namespace to internet conversations, right? So the host identity namespace is based on a PKI, public key infrastructure. The advantages of this is IP address is only used for location of a thing on the network, so that's the address. Native security and verifiable cryptographic identities are bound to any IP-enabled devices. Mutual authentication authorization before transport and trust security communications. So you know that every time that you're talking to something on the HIP network, that is that device. It's not being spoofed. It works over NAT. So you can, it's all NAT-able. You don't

have to, and when you're NAT-ing, you don't have to open up all the ports that you would need to. Think of like if you're doing a, kind of like if you're doing a VPN, but the difference is the peering is from peer to peer, you don't have to route it through the VPN. It can be routed through a relay, which I'll get into in a second, but disadvantages are that it's really hard to set up, meticulous setup involved. And so here we're just gonna kind of get into little visuals here. So say if you have a regular IP network where you have the SCADA device right here, Acme Corp, whatever IP here, you're talking to a cloud service application, that's for SCADA analytics and stuff.

The HIP network would be an overlay. So instead of an IP, you have what's called a local scope identifier, which looks like an IP. It's got four octets, but it's all weird and fucked up looking. So when you're talking from here to here, there's no possibility of being spoofed because before that communication even happens, a PKI-based trust system happens before that, right? And we can also look at this in the form of a relay. So basically, let's say that your SCADA network has, you have, I don't know, let's say you have two factories and you have two SCADA devices that you want to send to the cloud. You can do this way, or you can do this way through a

HIP relay. Anything that's connected to the relay, you can do what's called wide area segmentation. Micro-segmentation basically saying, you know, at a whim or the drop of a hat, this can talk to this, this can't talk to this, everything is kicked off the network, oh shit, mistake, bring it all back, right? You can do that very quickly. And so I'm gonna introduce you to a tool called Defiant. The Defiant that we all know and love is the USS Defiant, the Captain Benjamin Cisco commands. It's the only ship in Starfleet to have cloaking device which the Romulans provided during the middle of the Dominion War. And that brought the Romulans into the fold there. Anyways, yeah, so that's really important

stuff, but I gotta skip that. Here is a demonstration of a tool that I made that makes implementing HIP easy. And you have a relay, and the relay, everything is connected to it, but from the relay, you can actually, decide what can and can't talk to one another. And I call it Defiant because it's a cloaked network. And the USS Defiant was a cloaked starship. So really, I'm just gonna fast forward a little bit to the end here. You can get the, if you, server info, you get the local scope identifier, the information that you need to add new networks and copy and paste it. But really what we can do is identify the agents connected. So we have Taco

Bell, we have hip test, and we have test. And if I want to, I'm going to run the connection manager. The connection manager allows me to, I can pick one of these, I can see if it's active. And then what I'll do, can tell the tool to say which agent at an endpoint do I want to control. And I do that. And it tells me what connections those have. We have Taco Bell, Taco Bell, and some bullshit test. So we're going to remove some bullshit test. And I mean, yeah, that's pretty sad.

or cool, but it does work. That's the point. So being able to do wide area micro segmentation is really valuable. So today, I know a lot of people left because it is lunchtime. I'm gonna release it right now.

working here.

Anywho, I was going to open source it but I'm having issues with the outro one more time before I stop.

Oh yeah, I'm an idiot.

If that doesn't work, then that's, oh, there we go. Yeah. So I got it. Got that. And then I need to...

All right, so I just pushed the agent. That's open source now. Now I'm gonna do the same thing with the relay.

Okay, so that's that.

Okay, and if we go,

if I refresh this, it should be full of stuff. Yeah, so

yeah, that tool that I showed you to do the micro segmentation is now on the GitLab. So anybody can use it if they want to.

And yeah, GitLab links are here if anybody wants some of these. The agent and relay, unfortunately, I only have it working on Zorin OS. However, I am working on a containerized solution for rapid deployment. Then rapid fire is down here as well. Okay, and then to do a recap, cyber physical technology, the digital action with physical reaction, it's everywhere. It's necessary to further our industrial advances. A lot of it is insecure. IOMT, convenient but not really secure. Lots of open source intel on how to hack IOMT devices, especially those using RF transmission. Communication methods, rolling signals and codes are best way to perceive to secure, from my point of view at least, following what cars are doing at least. And then automotive, feature-driven

development, increases the attack surface of the vehicle. Industrial control system, automation systems are open to the internet, making things easier. It's a big no-no. They can be secured through advanced networking schema, unidirectional gateways, or host identity protocol like I showed before. I gotta give credit where credit is due. So Zombie Craig, who is an automotive hacking expert, he's the author of the Car Hacker's Handbook, Guide for the Penetration Tester. He created the tools that basically let me do the virtual car with a virtual can there. And that's his GitHub. He's got a few good things on there I like. Next, Dr. Bryson Payne, Funding Director, Center for Cyber Operations Education. A lot of the research that he did kind of simplified how to

do your own demos, and I really like that, so giving him a shout out here. And then the Block Harbor CEO, Brandon Berry, he is probably the most known, foremost automotive cybersecurity expert out of Michigan. He's the one that introduced me to it. Me to automotive and other areas of cyber physical. And one of his accomplishments is that this past DEF CON, his team won the car hacking village. So hacking a Tesla and like other smart grid type stuff, his team won that. Additional shout outs for equipment, subject matter knowledge, or just inspiration. Alex, Mohammed, Spacer, and Kyle. And my contact info is all that.

Basically every handle is Taco the boss. That's really it. And if anybody wants to email me or do any collab or say hello, you can reach me on any of those. Shit, yeah. Yeah, that's it.

Thank you for sitting through that. Is there any questions? Any inquiries? Yes.

Yeah, I can do that. Any other questions? No questions on HIP or RapidFire or the history of UTP? All right, cool, awesome. Yeah, thank you.

Thank you. Sticking around for lunch, Sam, or no? OK.

Yeah? Well, what year are they? Yeah, so those vulnerabilities that I showed in the video, I couldn't get into the details, but pretty much there was a tool that allowed their network to be seen on the internet. So you can see Jeeps in real time based on the location. And you can interact with this and there's Python libraries out there that you can just import to simple scripts and talk to whatever IP address that port, I think it's like 6607 or something like that. And there's still some out there, maybe showdown. I was gonna get into showdown today, but I finally looked out and I'm like, I'm in 40 minutes, shit, I couldn't.

They might have used the range extender. And that's really what this is, just trying to make you aware of the expanding attack surface that cyber technology is. It's compounding, and it's coming out fast. Yes.

There's like Wi-Fi tea kettles out now too that you can break into and get the Wi-Fi passwords. It's like typical. Yeah, the toilet.

Some of the graphics that I showed with the

around their necks. Those are our core team, and our core team are people that have been working for the last year to help bring a new conference to you guys. So it's a lot of work. It's always ongoing. So we really hope that you enjoy it, and you'll look for us come back next year as well. All right. So Heath, the cyber mentor, Adams is a senior security engineer and founder of TCM Security. He has a strong background in network administration and information security, including penetration testing, network design and implementation, network security, or and network security. currently holds multiple cybersecurity related certifications including the OSCP, the OSWP, and the EWPT. Heath also proudly served as an

officer in the Army Reserve. Outside of work, he is an online cybersecurity instructor, YouTuber, and Twitch live streamer. When Heath is not at work, he enjoys spending time with his wife, Amber, and their four animal children. So here we have the top five ways I own your internal network.

Thanks for speaking today. So this is a scenekeeper. Sorry. Thank you. Good luck. Hi, everybody. So today we're going to be talking about the top five ways I owned your internal network. Really quick, who am I? I already kind of got the introduction, she covered a lot of it. But I am a husband, hacker, military vet. I enjoy gaming, Overwatch mostly. Sports fan and animal dad. We're actually up to five animals now. We're close to the limit on the city, so don't tell them. But former accountant, joined security not too long ago, about three years ago. Really hated accounting and made the switch over. So day-to-day senior security engineer and business owner at TCM Security. And I do run a couple of projects. So one is

VeteranSec. If anybody in here is a military veteran, we have a nonprofit organization. Basically, it is for anybody that is current, former, it doesn't matter the country, military that is interested in cybersecurity, works in cybersecurity. And there is close to 1,000 of us now in that group. So we just help each other out. We do resume reviews or just networking, help each other find jobs, et cetera. So if you're interested in that project, VeteranSec.com. The other project that I do is called the Cyber Mentor. So I am a YouTuber mainly. I do Twitch streaming and just makes cybersecurity videos usually related to ethical hacking or penetration testing. So if you are interested, there is some

material on there. If you're interested in becoming an ethical hacker, there's a lot of material on there. Other than that, I do blog over at veteransec.com. Occasionally I write on tcm-sec.com and you can find me pretty much Twitch, YouTube, Twitter, Instagram, wherever, at the Cyber Mentor. So briefly, why this talk? So there are a couple of reasons. Offensively, we want to know how can we leverage these attacks inside of a network. Defensively, we're going to talk about how can we defend against these attacks, at least talk strategies. And this is also for awareness. So many of you might not have heard of these attacks at all. So how can we attack or defend if you don't know about it? So just bringing awareness

to some of these topics. Quick notes. So this is talking about internal networks. internal network assumes breach. So when we do a pen test on an internal network, that means that either we were doing an external test, we already got in, we left a Dropbox, we social engineered, it doesn't matter, we're inside the network. So when we talk about internals, we're just inside the network. This talk is based on my experience as a pen tester. Your mileage may vary. If you are a pen tester here, you might think that your top five is way different than mine. So in my career as a pen tester, this has been my top five. And the only thing I ask for is if you please just hold questions till the end, that

way we can get through it. I was gonna do a live demo today, we've been having issues with live demos, so I've got everything in the slides as well, so we should have plenty of time if there's questions or there's plenty of time, I'll be available to talk afterwards if you want, plus I've got stickers, so.

Okay, so the first one is what's known as LLMNR, that's Link Local Multi-Name Resolution.

So basically what it is, is it's used to identify hosts in a network when DNS fails to do so. This was previously known as NBTNS. And the key flaw here is that the service utilizes a user's username and their NTLMv2 hash when appropriately responded to. So we're gonna use a tool called Responder to respond to these requests. So before we get into the attack, let's talk about how it kind of works. So we have a victim. And the victim here is trying to connect to a share. Let's just say the share is called hack me. For whatever reason, they try to connect to the share and they put hack M and it doesn't know how to resolve. The server doesn't know what it's talking about. So what's gonna happen

is the victim's gonna send out a broadcast message over the whole network and it's gonna say, hey, does anybody know how to connect to this hack M? And as the hacker's sitting in the middle, we're gonna say, yeah, I do. Just go ahead and send me your hash and I'll get you connected over there. And the victim's just gonna say, here you go, here's my hash. So what that looks like is we're going to boot up a tool called Responder. Now, Responder is part of impact. So there's an impact toolkit. If you've never used it, it does come built into Kali. The GitHub version, I think, is better. So I would recommend if you're interested

in running these tools or practicing in a home lab, the GitHub version is a little bit better. So we run Responder here, and we are just sitting here listening for events. and then we trigger an event. So here is again that network access error trying to connect to a share that doesn't exist. And when that happens in the network, all of a sudden a hash comes through. So we can see information here already that this is the hash type is the NTLMv2 hash. It came over SMB version two. And we identified the IP address that it came from. We identify the domain, which is Marvel, and we identify Fcastle as the user.

And then on top of that, we get the user's hash credentials. So depending on the security of their password, or the complexity and length of their password, we might be able to actually crack this. So we could take this hash offline, run it through something like John or Hashcat, and we try to crack it, and when you see a weak password like this, like password one, we're gonna get it all day. So this is still very common in networks where the password policies are like six, eight, even 10 characters. We get these hashes, them offline, crack them and use that to move laterally in networks. This is probably one of the first things I'll do. Usually when I'm doing a pen test, I will boot up

Responder as one of the first things. Good time to do it is at 8 in the morning or right after everybody is getting back from lunch because you need a lot of traffic in the network for this to be successful. So overnight, usually not the best idea. So we'll run this, we might run scanning or different types of scans in the network to generate some traffic and maybe get this moving. But let's talk about defenses really quick. And this first one, this LLMNR poisoning is gonna come back into play here in a few minutes as well with another attack. So the best resolution here is to disable LLMNR and MBTNS. So if you just disable LLMNR, then MBTS takes over and you still have the same kind of issue.

If there was a reason that a company does not disable this, or cannot disable this, then we would recommend to use network access control so an attacker can't easily plug in a device and get access to your network. Also, the thing that really blocks this attack is to have strong, unique passwords. You're going to see later in one of the attacks we have a 14 character password that gets cracked. I think that we have, the longest I've cracked is a 19 character password, which was a Bible verse. It really is more of not using common words with a combination of length and a combination of complexity. Not just length in the policy is really big. You're gonna see that as a common theme and as

an attacker, bad passwords are what's gonna get us around the network more often than anything else. Okay, so the second one is called pass the password or pass the hash. So if we crack a password like we just did, or we can dump SAM hashes on a machine, then we can leverage both of those for lateral movement. And we can use a tool called crack map exec to do that. So crack map exec just takes the, if you see here, the username of Frank Castle, the domain of Marvel, and then the password that we cracked. And all we do is we sweep that subnet that we're in, And you can see that it found not only the Punisher, which was at .7,

it found Spider-Man over at .6 as well. So this user has local admin rights on this machine. And from here, I mean, we can use something like PSEXEC to get onto the machine. We can use CrackMapExec with like a switch of dash dash SAM to dump the SAM hashes off of this machine as well. So just being able to pass this password around is super critical. I had a assessment two weeks ago that was using CyberArk. So if you don't know CyberArk, it's a privileged access management tool. Basically, it is a password rotation tool. They utilize complex passwords. You log in as a user, and then in order to get your account, you'll check out an account. That password's good for like eight hours. Then

you check back in the account, that password rotates. So cracking those passwords via LLMNR, very, very difficult to do. But we were able to do one of the other attacks that you'll see here in a minute, which is called SMB relay, get onto a machine and dump the hashes. One of the hashes was a tech support user, didn't have to crack the password at all, just passed it around and got into every single machine in the network. So password reuse like this is very common, especially at the local level. And that was a company that spent millions of dollars on cybersecurity and we owned the domain controller without ever touching a domain account, ever compromising

a domain account. super critical to care about not only your domain passwords but also your local passwords here. Same thing with the local hashes. Again, you don't have to have a password. So if we just grab the hash here and we put it into CrackMap, we can try to pass it around. In this instance, this password wasn't actually, this local account wasn't reused, so we only pwned the same machine that we had before. But again, this is a situation where we would use this tool and try to get multiple machines in the network and just get lateral movement because you never know what you're going to find on the next machine. Okay, so this is hard to

completely prevent, but we can make it a lot more difficult. So limiting account reuse. So avoid using local admin passwords, reusing local admin passwords. Disable your guest accounts, disable your admin accounts. Limit who is the local administrator. I know everybody on the network wants to be a local admin, but they don't need to be a local admin. On top of this, utilizing strong passwords, again, this is a theme that you're gonna see come through over and over again. The longer the better, long sentence, like a 40 character sentence, perfect, never gonna get cracked. And then again, privilege access management can help prevent some of this past the hash, past the password attack. So a tool like CyberArk or a tool like Thykotic can really help improve your security

overall when it comes to this attack. Okay, so the next one is token impersonation. So what are tokens? They're just temporary keys on a machine. You can think of them like a cookie for a machine, essentially. And there are two types of tokens that you see. So one's called a delegate, which if you logged into that machine or use remote desktop to log into that machine, you're gonna leave behind a delegate token. The other one is impersonate, so this is non-interactive. So delegates you can think of as interactive, impersonate you can think of as non-interactive, And basically that is like attaching a network drive, having a domain logon script, et cetera. So what happens is if a user, say you're using your computer, but for whatever

reason a domain admin remotes into that desktop or helpdesk remotes into that desktop and they've got domain admin privileges, they're leaving behind this token until the computer is restarted. So let's see why it's bad. So here is the user. You see we've got authority system here. So we own the system, but we can actually impersonate this Marvel Fcastle. This is the machine we own. He's actively logged in. We can impersonate him and act as if we are a user on the domain. So when we impersonate this token here, you see up at the top, we initialize a shell and then we do a who am I and you see now that we are Marvel Frank Castle. Come through. And we tried to

run a Mimikatz command here. This is a PowerShell version of Mimikatz. And basically what we're trying to do is access the domain controller and dump the NTDS or the LSA and get all the passwords or at least the hashes and take those offline and either utilize them or try to crack them, et cetera. So here we have access denied because this user is not a domain administrator. However, if a domain admin was available, we could repeat the process. We see that Marvel Administrator is actually here. We impersonate the administrator, we say who am I, again now we are Marvel Administrator. We run the same command over again, and we dump all the hashes. So once we own the Kerberos ticker granting ticket hash,

we own your domain. We can do a golden ticket attack and pretty much log into any machine we want. Once we take these hashes also, we will take these hashes offline and try to crack them. We do this because this will give us an idea of what your password policy was and how strong your passwords are. So if we're cracking 30% or 50% of your passwords, we can bring that back and give you statistics and say, hey, this is really bad. This is something that you need to focus on and actually have some data to back it up.

So mitigation strategies. Limit your user or group token creation permissions. So the mitigation strategies are It's hard to prevent fully. Another thing is account tiering. Say you have Bob and Bob is a domain administrator. You should have Bob have a local or a regular domain user account and then maybe a bob-a for a domain administrator. And bob-a only logs into the domain controller. You're not using that domain admin account anywhere else in the network other than domain controllers. prevent us from ever being able to compromise an account with token impersonation, at least one that is sensitive to do anything incredibly damaging. And again, local admin restriction. We're not able to run this attack if we can't be on the machine. So if we

can't like PS exec or use something to get a local admin account and actually gain a shell on the machine, this isn't going to happen anyways. So it's all a common theme here, and it's just going to keep repeating itself. And it's just these really common things that take down take down major networks. All right. So when I told you guys earlier that a responder would come back into play, this is where it comes back into play. And this is called SMB relay. So basically, instead of capturing the hashes and taking them offline and trying to crack them, what we can do is pass that hash over in what's called a relay attack. And we can try to gain access to a machine with that account.

Now, the account that's being relayed has to be an admin on the machine for it to be any sort of useful information that we're going to gather. The other thing is, the big thing here is that SMB signing has to be disabled. Now that's useful because SMB signing is disabled on all regular Windows operating systems, only the servers come with SMB-enabled, signing enabled. So unless an administrator has already gone in here and done this, this could be an attack that easily gets us onto other machines. So again, the relayed credential has to be not only a credential that's coming from a different machine, but it has to be an administrator on that machine as well. So we've got administrators in the networks on multiple machines. This

is where things can get bad. So one thing that we do is we turn off the SMB and HTTP capturing because we're actually just going to relay this. We take this off of Responder. And it just kind of looks like this. Instead of where it was all green, now it kind of looks like a little bit of a Christmas tree. It's got some red, some green, just saying that it's off. And we put up another tool which is called NTLM Relay X. The other tool that we could use here is SMB Relay. So both kind of do similar things. Here we're selecting a target file. So we'll put the targets that we want to identify.

Maybe we've done a scan, we've identified what users or what machines have SMB signing disabled and we just target those with anything in the network. So we sit here, we listen, we wait. An event occurs again, same thing as before.

This time you can see that the attack has succeeded. It's trying to connect from 10.0.3.7 against 10.0.3.6. Marvel, Frank Castle is an administrator on that machine. So it connects and then automatically you can see down there it dumps the SAM. So we've got all the local machine or local account hashes on that machine. Other things that you can do, you can utilize Metasploit, Empire, and you can actually add a command back like in this this NTNLM Relay X, we can actually use a command feature and push a command in that will give a shell back to us and we can have full interaction with this. Another way to do that is with SMB Relay, you can use SOCKS to have a shell

on that as well. So this is very bad and still very common. And all the mitigation strategies are still gonna be kind of the same as what you're seeing before. So we can enable SMB signing on all devices. That is the recommendation that we make as pen testers. This can be an issue. It can cause file performance issues. The data that's out there says 15% increase in time for file transfers. Some people have reported longer. So you might get some, as an administrator, you might get some feedback from your users that file transfers are taking longer. But it is for security purposes. You could also disable NTLM authentication. So if you don't have the NTLM to authenticate with, this attack won't work either. But if Kerberos stops

working, then... Windows will default back to NTLM. So on top of that, again, the account tiering that we talked about, having your domain admins and your powerful accounts not be allowed to be relayed like this, so you have to limit that. Same thing with the local admin restriction. So you might run into issues where people, it might increase the amount of service tickets. If you're limiting the local admin, people will need something to be installed. They're going to put in help desk tickets for that since they can't do it themselves. So it might cause some headaches, but again, it's for the better of security. Okay, last one is Kerberosting. So Kerberosting, basically, Kerberost is a way of authentication method, right? So if we look here, we've got a

domain controller up at the top of the triangle. We can call this domain controller a KDC, that's a key distribution center. So what's gonna happen is the victim or the user is going to request a ticket. This is how authentication works. We request a ticket, provide our NTLM hash, and we receive a TGT back, which is a ticket granting ticket. And that comes back encrypted with the Kerberos ticketing hash. And the only thing that we need to do this is a valid account credential. So if we've compromised a domain account at all, we've got a username and a password, this attack is gonna work. It's not going to be successful, but you're at least gonna be able to do part of it. So the second part of this

is we have this application server down here. It can be application server, it can be a SQL server, it can be whatever you want. When we have these applications in the network, they have what's called a service principal name or an SPN, and that's gonna come back here and play in a second. So what we do is say we want to access this application server. Well, we're gonna say to the KDC, I want a service ticket, a TGS for this server. It's gonna say, okay, give you a service ticket, I'm going to encrypt that with the server's hash. So we're going to take that TGS that's encrypted with the server's hash and we're going to

pass that over to the server and if we have access to the server, it's going to decrypt it on the server side and if we have access to it, it will give us access. The whole process for us as an attacker stops at four. So we're only receiving that ticket because it's encrypted with a hash. So this looks something like this. We run an attack, again, impact it comes into play, and we say, Python get user SPNs. We're getting the SPNs in the network. You see I'm using the Frank Castle password that I've gathered before. I'm using a, I'm identifying the domain controller IP address, and then I'm using a request. I'm requesting this, and

out comes this Kerberos ticket granting service ticket hash here, down at the bottom. Another thing that we can see here, and this is super common in networks, this is why this is really dangerous. is if you look at the SQL service here that's been requested, it's a member of the domain administrators. We see services as domain administrators all the time. And this is where it gets really bad. So if we have an account with a bad password that's utilizing services and that account is a domain administrator, it's also a game over situation. So here we go into, hashcat again, we attempt to crack the hash, and you see that we have cracked a 14 character hash of mypassword123 pound. So even though it is 14

characters, really not that secure of a password, and now we've owned a domain administrator.

So mitigation strategies here, strong passwords, least privilege. That's really what it comes down to. Questions? Yes.

is also good. Yes.

I'm not a blue teamer, so I'm not strong in the detection side of it, honestly. Yes.

depends on the organization. So if they've got like a six or eight character password policy, you're looking at like at least 50%. The one that I was talking about last week, or two weeks ago, where I was up against CyberArk, that was, we cracked two passwords out of the whole thing. So I mean, CyberArk works as long as you're utilizing strong, and not reusing and using strong local passwords as well. So it just depends on the organization. But anywhere from, I would say 25% is probably the average.

poisoning? Yeah. So I see that on pretty much every network I encounter. I don't know. I can't remember the last time I've seen it off. I think it really depends on your clients. Like I watched a Black Hills InfoSec and they said they're seeing it on one of three. But I'm guessing their clients are probably repeat. They kind of know. They might have more of the elite clients as well. So they're probably seeing a decrease in that LMNR on networks. But I see it pretty much everywhere.

I don't think in the hash strength now.

Anything else? All right. Thank you, everybody.

likely they don't know about it, honestly. I don't think until they get their first pen test do they really realize how devastating it can be. So it really just depends on the client. And you'll even get clients that do it for a checkbox and you've been on a third or fourth and they just say, you know, screw it. So it just depends.

I'm not

going to the other talks.

or if it's just... Ah. Oh, it is. That's so cool.

So our next speaker here for you today is a security analyst and former wizard eaten by a rat, but it looks like he got better. Joe Schottman is an application security focused security professional with experience ranging from web application development to purple team engagements. He has spoken at regional and national conferences on threat hunting, web shells, purple teams, and more. So he's gonna be talking to us about realigning from chaotic evil. And as a speaker for B-Sides RDU, we just wanna show our appreciation with a sneaky book to you. Fine literature. Yes. Write better, speak better. That's not a message in any way.

Good afternoon, is the volume good? All the way in the back? Great.

So about me, I got the introduction already. You may have noticed from the title, I am not just a security person, I am a geek. I've done pretty much a little bit of everything in IT at some point. I started in web app development and system administration, did DevOps, then I've done just about everything in security at some point or other. So it's given me a variety of perspectives on the different incentives that we have in this industry. You can add me on Twitter, I don't really post much, just kind of sarcastic comments on other people's posts. You're welcome to add me on LinkedIn, I'll add just about anyone. I am not speaking on behalf of BB&T, Truist or any other entity. All opinions expressed are

my own. I'm a stickler about using images with permission so everything is cleared. And an additional disclaimer, I am not just talking about my employers, past and present. So please don't take the takeaway that I should never work with Joe because he works terrible places. A lot of this is gathered from stories I've gotten from friends working at most of the big companies in this area. out in Silicon Valley, that sort of place. And the last disclaimer, I'm not actually a D&D guru. And if you are, at some point, you're probably gonna start reaching your hand up and saying, you're using that term wrong. It's just assembly. It's just sort of a metaphor. So bear with me and don't correct me. I played a brand X ripoff

of D&D in my misguided youth, so I use the terms a little bit differently.

So why am I giving this talk? There's a big threat that I've seen a lot of industry research on that I wanted to update you about, and that is orcs. You see here in the Gandalf magic quadrant that there's a number of things. There's COBOL and Windows XP still hanging out as the undead. Kubernetes is coming up, but really in the upper right-hand corner of the leaders, big teeth and sharp pointy things, we've got orcs. So really, why did I choose this as a talk? at a security conference. So I started with the very typical thought of we need to realign the synergies of how we incentivize things in security, blah, blah, blah. And if I submit this talk, how many people would

have actually shown up? But if you want something a little bit more InfoSec as a title, you can think of this as social engineering your way to security success. A lot of people have the technical parts of security nailed. They can do the defensive stuff really well. They can do the offensive stuff really well. But if you don't know how to communicate with the other sides, your counterparts, whether you're working as a contractor or whether you're working as someone who's part of the main company, you need to engage with the other sides effectively. And I've seen a lot of people making mistakes on how they do that because people assume that what motivates them motivates everyone, and that's not always true.

And the big problem is the corporations and corporations, companies, organizations, what have you, they often don't align the incentives that are given people. That's the things that affect their raises, their bonuses, whether they get praise internally, that sort of thing or not. They don't actually align that for security. So these are some ideas on how to fix that. So I've got a dear friend who worked with a guy that he got very, very upset about because this guy would pick out the projects that management rewarded people for working on. only work on those projects. Anything that he knew that management didn't really care about, he did zero work on. This made my friend very upset

and he thought that this guy was a jerk. And obviously doing that to an extreme, probably kind of problematic. But if management doesn't actually recognize what needs to be done and reward people that do the necessary work, that's a management problem.

So very often people do what you incentivize them to do. So this may be counter security, this may be counter stability, this may be counter to everything good that you want as a corporation or organization, but if that's what's gonna get them the $10,000 bonus, the $20,000 bonus, what have you, they're gonna do that. And there's other factors too. People have pet projects, they will pursue certain things doggedly because they love a certain platform or a certain application. So it's not always about incentives, but within the corporate structure it very often is. If you're not familiar with D&D or AD&D, which is advanced, D&D is Dungeons & Dragons, AD&D is Advanced Dungeons & Dragons. It's a fantasy game where it's a collaborative form of fiction basically that's mediated by

dice. People come together and tell a story and when you need to figure out what happens, you roll some dice and figure things out. It was inspired by the Tolkien's Lord of the Rings mythos, which as we know, has a guy that gets corrupted by the one ring zero.

So this popped up the other day and it's a little introduction to what alignment is.

I thought it was a fun little thing. Also as a side on D&D, it's had a rebirth right now because it's been featured prominently in the Netflix show, things, which I'm not actually familiar with, but a bunch of people came up the previous time I got this talk. It's like, yeah, my kids love Stranger Things, so we've been playing D&D with them. So it's kind of neat seeing this come back from the 80s. So what is alignment within the system? So good, it implies that you're altruistic, you value life, you're trying to do things right within a fairly typical human ethos. That's the defense of people within your companies. The blue team, the people monitoring the SOC, people, hopefully, your

developers all have the best interest of the company at heart. Evil is all about doing what you're not supposed to be doing. This could be a malicious insider, it could be an insider who just doesn't care, they're burned out, they're stressed out, and they're doing the bare minimum to get by without actually doing what it takes to keep the company safe. Or it could be outright evil. This could be foreign companies, foreign countries trying to get into your company's defenses, that sort of thing. Also, within the good and evil, you've got lawful and chaotic. So you can be lawful evil. So this might be someone working for the Russian government who, they obey the Russian laws, they obey the rules that they're supposed to do. They clock in

in the morning and they do that sort of thing, but they're evil because they're coming against you, against your best interests. You can also have pure chaos. It's all about the walls, it's about the fun. A chaotic evil person might just be doing things to destroy things, out files, getting lots of money. A good chaotic person, again, this might be someone who's kind of, they're working for your company, they're a little burned out, and they're not doing what they're supposed to do, and they're a force that kind of spins around, especially within state governments where people often can't be gotten rid of. I've seen people kind of bounce around and disrupt whatever department they happen to end up in for a while, and they get pushed out the

next one, and they're just a force of chaos within the company or departments. when you're putting together a group of D&D players, you want to have kind of similar players with kind of similar motivations. So, borrowing from the Creative Commons, I found someone did some fun illustrations using Lego characters. If you have a good character who is a priest who supports the forces of light within the game and obeys all the laws and throw in a necromancer, you're not gonna be able to tell a good story together because the players are going to be fighting against each other rather than working with each other to make this collaborative story.

This is what you should try to avoid when you're putting together people's motivations.

So as a brief aside, when I say red, there's this technical term in the industry for red team that I like, which is when you're actually simulating an advanced attacker. This is commonly misused. A lot of people use red team as general pen testing. context of this, red just means offensive security, so it could be anything from running vulnerability scans all the way through doing actual red team exercises. The red team, or offensive security, is simulating evil. You're doing things that shouldn't be done to the applications, to the systems. But generally you're doing it as someone who's been authorized to do so. It's the fun part of the industry, generally when someone says, when I talk to someone, say I do security, oh, you hack things? because no

one says, oh, you work in a sock. That's the really fun part of the job. And so I think that one of the problems we have as an industry is we give too much respect to the defense of security and not enough respect to the defense of security. And I'll talk a little bit more about that later.

From the defensive side, because I've been on the defensive side, when you're getting the security report from the pen testers, it can feel kind of like this. You know that there's something bad lurking out there and you're gonna get smacked down and your management's gonna need to come down hard on you. And it doesn't matter how hard you work. In a large enough organization, there's going to be some risks that are gonna get exposed by a test. So some common things that seem to incentivize the offensive side. It could be objective based, it could be get shell, get root access on the system, get domain admin. It could be generate a really scary report, say I got three million credit card records that I

could have published. Or it could just be do so many tests this year, this quarter, what have you. As I said, the defensive side is more of the good side of things. This is the commonly referred to as the blue team. It could be SOC, which is Security Operations Center. It could be people doing threat intel, people that do your forensics, malware analysis, that sort of thing. The blue team is often restrained in what they can do. They're often dealing with long shifts. I know a lot of companies that use 312s, and that can be pretty grueling to deal with. There's often a lot of training. Sockwork is a really good first place in the industry. but you kind of get thrown in with a

little bit of security background maybe, and you're just kind of being bombarded with the alerts and messages from systems you don't really understand, but you know that you're supposed to respond to 20 of these a day. It can be hard to advance sometimes. There's not always a good pathway forward once you get started on the blue team path. And there's not necessarily a playground set up that you can start learning some of the hands-on offensive security parts. Depending on your organization, the analyst side may also have a lack of funding. Some of the really good tools like SIMS, the search engines that go through terabytes of data can be real expensive to license. Management may not be willing to provide that for the blue team. That can

be a frustration. They're often differently aligned. In a large corporation, the blue team and red team often has a complete different management structure.

not just their team, but the people they report to and the people they report to may have completely different things that they're incentivized to do by the company. Some common metrics I've seen with blue teams, it could be the number of tickets closed. This can create a perverse incentive where if it's actually a percentage of tickets closed, if you open fewer tickets, you can have a much higher hit rate. It could be the reaction time to alerts, The really big one, especially for the high-level executives, is not appearing in the news as having been hacked. That's a really important metric for many blue teams. And if you fail at that one, that may be a

career-limiting move. So if you have these different incentives coming together, the blue team, this is where I got the title of this from, may see the red team as a force of chaotic evil. And I'll expand in just a second, but I'm also gonna throw in people like operations and programmers here. Security only creates problems for them. So every time a security guy comes and says you need to do this extra thing, it's taking away from some other responsibility that they have. That's probably what their bonus depends on. So you need to balance what you do working with them. So if you come in just smashing things, causing problems, and being completely unsympathetic to them, you do look like chaotic evil. Because at

that point, there's not much difference between you and an external attacker as far as affecting what they're getting paid to do. The red team often sees the blue team as being too tied down. The blue team tends to be a lot less flexible. There's the good side and bad side of things that the blue team often has a playbook that is a strict side of things that you're supposed to do and execute that playbook when something happens. But very often they're supposed to do exactly that sort of thing and the red team will say that's a problem because they're not flexible enough. A few of the other incentives I see in corporations, developers very often are incentivized by adding new features rather than stability or security.

At a previous company I worked at, we had a big stability problem for quite a while where the developers would do a software release and stuff would crash and crash and crash and people would be paged all night. So in that case, we actually did realign the incentives because we put the developers on the pager duty also. And strangely enough, when they started being woken up at 3 o'clock and 3.20,

340, the code stability got a whole lot better. So that wasn't security related in this case, but it was just general stability. But it was a case where the management did step in and say, we have your problem. What can we do to realign those incentives and make an actionable difference? And it did. Operations. So if you're not familiar with D&D, this is a basilisk who has turned the horse there into stone. They're often incentivized by uptime or speed to deployment rather than security. So operations generally doesn't like change. If something's working, they want to keep it that way. They don't necessarily want you doing security testing on it. If you do find security testing, they may say, well, that doesn't actually need to be fixed.

Because if their bonus is based on how many nines percentage uptime they have, if you make them take something down and spend an entire weekend doing reboots to get things fixed, that affects that. And management.

Off incentivize to just not hear from security at all. Other than consulting companies, security doesn't bring in money. Management usually cares about bringing in money. And I'm exaggerating a little bit, good managers do pay attention to security because they know that there's an impact if there's a breach, if they get owned, if they hit the news. But very often, if they think things are fine, they may stick their fingers in their ears and try not to hear from security very often. I mentioned the nines a second ago. If you're not familiar in the system in world, there's the nines of uptime. So two nines would be 99% uptime, three nines is 99.9% uptime, and five nines is 99.999% uptime, and that's something that's very often sought after.

These are photos of my actual dice from my misspent youth. That is a rare 30-sider, which was hard to get back in the day before the internet, and I traded pretty dearly to get that. So one of the companies I worked at decided that they should have five nines uptime for the storage facility, for the storage. And that's what the people were incentivized to do. So they bought some very expensive storage that had five nines uptime. It was down for something like 15 minutes a year, if that. But because it was so expensive, we ran out of space constantly. So about once a week, no one in the company could get work done for a while until we went through and figured out some files to delete.

But that wasn't what the systems were incentivized to care about because that one metric is what they were told to care about by management. So this is another example in the other way of where incentive went poorly for the company.

So a lot of the big picture here is beyond our ability to change as a practitioner. Management, especially senior management, can start to do some of this.

what I'm here to talk about is to tell people to tell their managers to change this sort of thing, but also to think about the different incentives that come together. If you can weave a narrative based on what incentivizes different people, and this could be about fixing things, this could be about getting funding, getting training, that sort of thing, if you know what they care about and you can tell the story that makes them care about why you get this thing that you're going after, that will give you a better success rate. Some things that we can actually do, I'm gonna get a little bit more hands on on some practices that I have put

into place. So a lot of D&D adventures start in the tavern. It's a good place to throw random characters together and gives them an excuse to start talking and then someone comes up and gives you a quest. I get a lot of value out of doing lunches with people. I do lunches with people on the same team I work on, with people on different teams within security, in completely different groups, like going out and talking to accountants. They have completely different views about how things work at the company, and sometimes you get really good intelligence out of that. And also going out and talking with vendors, staying topical, and vendors will often buy you lunch

as part of this, so you can take advantage of that a little bit. And it also helps build camaraderie. If people like working with you, if they think of you as a human, if they know that you've got four kids or you do mountain biking, whatever it is, you're not just some security person coming in and breaking stuff. someone that they want to help. That's just human nature and that goes back to the social engineering part. The more likable and approachable you can be, the better results you're going to get as a security practitioner. And you can use this to recruit new members for your party. So I know someone who started doing lockpicking classes

as a little fun extra within his company. And the people got really fired up about that, turned into really good sources of intelligence about what was going on inside the company. So he dealt with, among other things, physical security. And there was an admin assistant who got really into picking blocks. And she started saying, oh, you can get around the security gates here and here and here, stuff that he didn't have the time to do, going out and checking every single door. But by recruiting her as someone to help him, even though that wasn't how it was sold to her, or even his initial intent, he got a lot of value out of that.

There's also this concept of security champions. This is especially big within development. So D&D has multi, you have a class. So you might be a fighter, a wizard, magic user. Generally most people start with one thing, but as you get more experience with your character, you can start doing two things at once. So you can start recruiting people to be your security champions within development or even operations where you give them training, you give them additional incentives based on keeping things secure. And they spread knowledge within the application development teams. not practical to get everyone doing the development at a master's level of security, but if you have that person saying, okay, here's a great

baseline, here's how it will help you, because bugs get progressively more expensive to fix the longer they go on. If you have a tool built into your IDE or into your brain that catches the security bug as you type it, that's almost free to fix. If it gets into your CI pipeline and you have to go back,

fairly cheap. If it gets to the actual build and then it's starting to be deployed into test systems and it has to go back, be fixed, and then you have to redo your user acceptance testing or your integration testing again, that's getting expensive. If it gets all the way to production, maybe you have a breach. That could be millions of dollars just giving out lots of credit card monitoring and credit monitoring packages to millions of people. So if you can have that security champion working with the developers saying, here's why you care about this and here's how to do it, you get a lot of value out of that. So bringing everything together, I talk a lot about purple teams. It's something that I'm a

fairly big believer in because I've seen the blue team, red team models working separately and it typically doesn't work. But if you're not familiar with purple teams, there is no single purple team. It's when you have the red and blue teams incentivized to work together, incentivized, enabled, empowered, all that good stuff. Both sides work with the other and you get this wonderful feedback loop of getting stuff discovered and fixed quickly rather than working in opposition. And, you know, people often say, isn't this obvious? Shouldn't we be doing it? Well, yes, but I've seen very obvious things not happen very often, especially in the large corporations, things are very slow to change or there's that siloization where they have these completely

different management chains I mentioned. So I push to get the two teams working together as much as I can. So a focus on detection, which I think might be a better metric that both the red team and the blue team can work towards. So this is a, the 11060 framework was created by CrowdStrike. The idea is that you have one minute to detect an intrusion. After you detect it, you have 10 minutes to investigate. And after you investigate, you have 60 minutes to react. They're pushing this because they've got some research they put out fairly recently on the breakout times for APTs, which is a great word to say at security conferences, I know. So

according to their research, and they're a little biased because they are an incident response and defense company, if you get hacked by a Russian government group, you're looking at 19 minutes before they go from the initial computer they get into to another computer on your system or the network itself. North Korea, they say, is about 140 minutes. Then the Chinese, I think, I suspect there are some Chinese groups that are way up there in the Russian range, but I have no actual proof. And 582

minutes sounds like a lot, but many people don't detect breaches for months. So by that point, they've gotten into your network, they've gotten into different systems, and they've probably gotten your crown jewels, the things that actually matter, and gotten them out of your company. So I've done some purple team engagements where it was more or less a big red team engagement that we're saying was a purple team engagement.

when you're just getting started with this, if you have a large gap, you don't get a lot of value out of it because you find a hole and then you go on and then you do this and you do this and you do this and the blue team still hasn't seen you get in through the initial hole. And that gets really demoralizing for the blue team because it's not really collaborative at that point and it's just, the analogy I use a lot is you're getting punched in the face and you're doing your best and there's so many holes, you've been telling management for years that you need to get thing done, the red team comes

in, does exactly what you said that they could do, and then you get blamed for it. And so one of the big things that's being talked at, probably about 40% of the talks I've seen at conferences this year have at least mentioned the attack matrix. If you're not familiar, this was created by MITRE. It is kind of a add-on or a successor to the cyber kill chain TM by Lockheed Martin. And what it does is it takes the concept of the different phases of attacks breaks it into granular segments. So I will not read all of these, but basically it is top down, left to right, what an attacker does once they start getting into your network. And really what you care about is how they get in

and then impact at the end. And all the things in the middle are important. As with security, this is a great thing to push left on if you assume that left is the upper left, because Each one of those is cheaper progressively from impact to detect and stop. So by the point that they're already doing exfiltration, you've lost the game. That's very expensive to recover from. If you can catch them doing defense evasion, that's reasonably cheap. If you can catch the initial access, that's the cheapest you're going to get. And you can find this online. This is actually a large enough screen. You can probably read some of it. So this is an example. But each column actually goes way down to the bottom. This

is just what I could fit in the screen. And so it's examples. The execution may be a compiled HTML file that has JavaScript that exploits Internet Explorer, privilege escalation, the AppSert DLLs. It's taking advantage of Windows, not having great security. And so it's specific ways that attackers are known to do these things. So each one of these, if you go links if you go to the actual attack matrix and it will say who's known to use them, so the big APT groups that are known to use different things and give examples of it. There's some hands-on example. They've got MITRE themselves has an emulation program that will do various parts of these segments. I'm not going to go

too much deeper into it, but if you're fired up and want to learn more, they're actually doing a conference that is online at the end of the month and it's free to attend on the online streams. I would definitely recommend checking out at least some of those if you wanna learn more about the tech.

And so what you can do is start building, you take that chart and turn it into a heat map and say, here's what we can detect. Here's what, well, you can start first and say, here's what does and doesn't apply to our environment. So if you're an OS 10 shop and Linux shop and you have no Windows, you can take all of those things that are Windows specific and eliminate them. It's also a framework that you can add to. So if you find the attackers are actually doing something that is not part of the framework, you can add it for your personal framework and you can also submit it to them and if they validate it, they will add it. So you can go through, figure out what your

best choke points are, where you've got the best visibility into what people are going to be doing and start going through and saying, okay, here's where, What we can detect, here's what we can't detect and should be able to do. And you do a small granular test rather than doing the big red team test where it's getting domain admin and getting the credit card numbers out or what have you. It's just, okay, we found a gap. Let's stop and work on it together. Once you can detect it, then do you have a playbook? If you don't have a playbook, work, in some cases, the attackers can explain hands on with the blue team, here's how

this attack actually works. A common example of when defenders don't know how an attack works, SQL injection, a lot of people use the one equals one as a logic, part of the logic within SQL. A lot of people wrote rules that said, okay, look for one equals one. That doesn't actually solve the problem because you can use any sort of logic there. It's having the attacker go to the defense side and say, no, that doesn't actually make sense. Here's what you need to be looking for. That's when you can start getting the effective defenses. We have the effective defenses set up. Do you have the playbook? Does the playbook work? And just go through, pick

out the places where you can detect the attackers cheaply and easily, and also look for that exfiltration because that's the big one that you need to worry about also.

I went through some of this already, but a big part of it, like I said, the blue team, You want things to be repeatable because it has to be reliable, especially with a large corporation. How you respond day to day shouldn't vary on who's working that day. I've seen some people advocate for having people in the SOC have different toolkits, so one person might be using completely different tools than the other. If that person goes on vacation, the other person doesn't know how to use that tool, that's a bad situation. You need reliability and repeatability for the defensive side. red team can help ensure that these actually work properly.

So the two teams can share information back and forth. Both sides know things that the others don't and have experiences that the others don't. They use different tools and, you know, the defensive side's probably heard of Metasploit but may not know a whole lot about it. The attackers may have heard of Splunk but they may not know a whole lot about it. By having them work together, you can get better results. things I always say is the bad guys have almost infinite amount of time. They can spend weeks, months, even years in some cases if it's a really high valuable target. Very often a penetration test might be scoped for a week, two weeks, maybe four weeks if you're lucky. So everything you can do to cheat,

or I've been criticized for calling it cheating, but everything you can do to make it more effective, that's what you can do to take advantage of it. getting that internal knowledge from the developers, from the systemans, from the blue team, that lets you do a much more effective pen test more quickly and get better, more accurate results. So on the web application side of things, as an offensive web person, I know that large applications, you have to do a lot of scanning because it'll have hundreds or thousands of pages and thousands, if not tens of thousands, or hundreds of thousands of variables, and finding which one of those actually has a vulnerability do it manually,

you might get lucky right off the bat, but you probably don't have time to do it all. So you have to use an automated scanner. If I share that information with the defensive side, they can start taking steps to prevent this. So as a programmer, I can say, if I detect what's obviously SQL injection or really any kind of attack, just drop the session. If you as the attacker have to go and log in again every single time it catches you doing something that's an attack, whether it works or not, That's a big pain point. If they really care about you, if there's billions of dollars on the line, they may keep going. But a lot of the time, you just have to be faster than your friend that's

running in front of the bear with you. On the same side, it's not just on the programming side. As a defender, I can put in WAF rules that do the same thing that drop the session or cause the session to be terminated. But had I not worked on the defensive side, I also wouldn't know to tell the aside that these capabilities exist. So in this case, it's things I've done on both sides of the fence, but if you haven't, work with your counterparts and see what can be done to make each other's lives easier and make the attacker's lives more difficult. I advocate for setting up a cyber range. Like I said, the hacking part is the fun part. Everyone loves doing this part.

Having an environment set up within the work structure where they're given time and access to systems that they're given permission to hack, especially taking web developers who don't understand what cross-site scripting is, don't understand what the impacts can be, letting them actually run some attacks can be really eye-opening. And with the SOC staff, give them the context to understand what SQL injection is, because of the time they just know that this tool is saying that there's SQL injection, or even worse, there's a one equals one attack, letting them see that you can actually use SQL injection to get all the credit cards out of the database. Or in some cases, if they have command shell enabled, that they can start running commands through the web interface

using SQL. That can give them the context of understanding, oh, this is what I need to be really caring about when there's an alert that comes in for this versus a low impact alert that might be popping up at the same time. Giving them the training also gives them a career path. Every time you have someone on the blue team leave because of lack of advancement opportunity, they're taking great domain knowledge about your company, about your systems, about the problems. That's going out the door and that's very expensive to replace. So if you give them a career path, they can go from that low-level analyst position and start doing some of the more fun, better

paying and glamorous positions. That's a big help in my opinion.

And having people actually pair up, do side by side engagements, writing alongside, that can be really eye opening. When someone's saying, okay, I just did this attack, did you see it? And they're saying, right there. You can start going back and forth really quickly and finding these holes and start plugging them.

Part of what the red team needs to get out of this is how are the defenders going to react when this is detected? Because there's often ways around the defenses. they see the playbook being executed and what's catching them, what's not catching them, they can start thinking of more evil things to do to get around that and then provide feedback on how to fix the playbook. At the same time, the defenders, the common term in the industry is TTPs, tactics, techniques, and procedures. They see what the bad guys are often doing. One of the big things in the field right now is adversary emulation, where you'll take a group that you think might be attacking

you and go book up what they're known to do as part of their attacks and try to emulate that specific adversary as closely as possible to see how your defenses are. So the red team doing that research, deploying tools, showing them exactly how the bad guys are doing things and why, that can be really eye opening for the blue team and they can start coming up with how to make defenses for that. So you can strive for similar synergies. try to get the management on board with this. So like I said, I like the MITRE ATT&CK framework that if both the red team and blue team are incentivized based on taking that heat map and turning it green, rather than things that don't

actually matter, that don't actually increase security, then you can start delivering some real value for the company. Pushing the application testing left, if you can get the developers involved, get things built into the CI pipelines, the earlier you can catch stuff, the cheaper it is, the more effective you're going to be. tell the developers, this is what you need to be logging. Very often application developers don't think in terms of security context as far as what they log, so they may not be logging the actual IP. So a common situation that pops up with complex web applications is the IP address you get in your logs is the load balancer that's talking to your application server. There's a separate header exported for, or if you're using something

like Akamai, Akamai provides a different header that is the actual end user's IP address. and in cases where you're trying to do analysis and try to figure out what's going on, and all you know is that your load balancer is attacking you an awful lot. There's no way to actually trace it back to who was actually making it attack and see what else they were doing. So giving that information to the developers of here's what we deem to know as the blue team, here's what I'm afraid of getting logged as the red team, that can let them make sure that things actually get logged. As an attacker, I try really hard to only demand remediation

of serious issues. A lot of it, especially the scanning tools, we'll find on an application sometimes hundreds or large applications, thousands of unimportant vulnerabilities. There's no effective way to turn them into an exploit. It's just a violation of best practices. If you're doing vulnerability management using something like Qualys or Rapid7s or Nessus, you can get many, many things that may not actually have any impact on that system. you narrow it down to just what actually matters. Make them fix the things that matter, but don't hang it over the heads if they can't fix the things that don't. That gets them more on your side and lets them do the things that actually bring in the money. For working with web

application developers, if you can deliver bugs into their bug tracking system directly in a usable way, that saves them a lot of time. It lets their management see numbers of bugs caused by security issues, lets their management create incentives to actually do code securely, but it also works better than, so you email this project manager and say that there's a problem here and send them a report and you can look in our bug defect tracking system here to see it. And then they have to take that, they cut and paste it and they may miss something. That's really hard from the developer's perspective, giving them the full information natively in the workflow they're used to, that makes their lives easier and better. And in general with any sort

of security test, assuming that there is any finding, if the pen tester's offensive security, whatever it is, don't take as an opportunity to help educate the blue team, that's a missed opportunity. So getting towards the end, I wanted to divert to another bit of geekery. So I'm going to talk a little bit about tanking. If you're not familiar with tanking, this is commonly used in the role-playing games, the massive multiplayer online role-playing games like World of Warcraft is a big one, but there's a number of other ones. It's also used in some other games, but tanks exist mostly to take a lot of damage. They usually don't get to do the really fun, cool stuff. There's the people

who are the wizards and that sort of thing, standing behind them, throwing the spells and doing all that sort of thing. and the tanks are there to take the damage in the front and they swing the sword and they get to have something like that. But it's not the cool glamorous part. And I think that the SOC staff, especially the really junior ones, often exist to do a lot of the grunt work that's not fun. But they're the ones that actually keep the company secure. So I can sit there and do an offensive test, whether it's an application test or pen test. That doesn't actually make the company more secure until the vulnerabilities get fixed.

Day in, day out, if the SOC is doing their job, making the company more secure. They're doing the actual defense. So I think as an industry we can do better to make them feel appreciated. I think that we should be mentoring them better. This is part of why I started speaking is we had junior SOC people that were coming to me with questions and it was the same questions again and again. So I started saying how can I start delivering the information that they need ahead of time so they don't have to come to me and ask. And that I like to explain rather than tell, a lot of the tools that they do just throwing information at them and they know it's a severity five

which is red and that they have to do this and click here and do that. Giving them a context of understanding what something does, why it's important, what the impact is, what it can lead to. That makes them feel a lot better. They feel included. You get better results with that. Because of the low people on the totem pole, they often don't get the big training budget. That's another thing that I think we should start trying to fix. And, you know, very often management will say, well, if we give them training, they'll leave for a better job. Well, if we don't train them, they're still gonna leave for a better job. Why don't we give them training, give them a better job ourselves? And just saying thanks,

it's grunt work, it's unpleasant. They often are going through some very, very boring logs doing the stuff that isn't very fun. And you can feel really unappreciated, especially if you're doing that 12 hour night shift. You're living in a cave, you don't get to see daylight. reaching out as a company and making them feel appreciated, I think is a big win. So to wrap up, the takeaways I'd love to have you come away with today is just to start thinking about the different incentives that affect both you and your team in other words, and how you can start utilizing that to get better results. Going back to the social engineering aspect, we need to take a moment to understand why they're doing something,

because there have been times that people have come, things that make absolutely no sense to me and I get upset, I get angry, and I stop and consider why they're doing something. And from their perspective, there was a very good reason. And once I understood that reason and could rephrase what I needed, I could get what they wanted by expressing it in a way that motivated them. So I got much better results with that. If you have the power, if you see a negative incentive, get rid of them, talk with your management. When you're doing something, does this actually increase security or not? Because doing the test that has no results, writing a rule in the search engine for the security side, for the defensive side

that doesn't actually find anything, those don't increase security. So think about whether what you're doing has actual business value for your company or not. Break down the silos, share information, get other people outside of security on board with you. them understand what the impact of it is so they can understand why they have to stop tailgaters coming in, why they can't plug in USB drives. You know, I work in banking, we have mortgage people that have to get a whole suite of documents from people in order to get the post-processing done. And it's very easy to say, oh, I'll just go out to Google Drive and download this and stick it on my system, giving them the knowledge of what the impact is and give them the

tools and the ability to do it as safely as possible. what gives the actual value to the company. And as best you can, take care of the people doing the not fun stuff. Make them feel appreciated and push management to treat them as best as possible. Questions, comments, magic missiles?

Thank you for your time.

The only thing that we have is we have a hard stop in an hour. So like you go on at 2.40, so at 3.40 we have a hard stop. Is that cool? Yeah, that should be good. Yeah, I had originally...

Good afternoon, everyone. Yes, I love this audience. It's a great welcome here. So thanks, guys, for coming to this afternoon's session. I have the honor of introducing Josh Smith, who I'll introduce in a second. But before that, I have some housekeeping announcements. One is that at 3.40, we pretty much have a hard stop in this room. So basically, that means you have to get out of this room. And so 3.40... Don't kind of linger if you can. We have to kind of clean it up so the theater can get on creating business through different events that they have later on the day. The second housekeeping announcement that I wanted to make is regarding our vendors. Please go and say hi to them. A lot

of them have great job opportunities and or are explaining some of their techniques and offerings that they have. And we can't hold conferences without their support. So please go say hi to them and see what they're all about. Last thing that I wanted to announce is that in your bag, everybody got raffle tickets. So if you haven't had a chance to kind of go through your bag, you should have blue raffle tickets in there. Downstairs at the registration table is where you can actually put them in different areas, different boxes to potentially win prizes at the end of the day. Also, some of the vendors have raffle tickets. So if you talk to them, you might be able to get a raffle ticket too. So now I have

the pleasure of introducing Josh Smith. He's of Vidant Health. So one, he is a homegrown hacker. He started taking apart stuff at the age of eight and has been learning ever since. So he has his OSCP and he is trying to go on and get the advanced certification in that area to have that expert level as well as the CISSP. So warm welcome for Josh. And I also have this amazing book here. is Going Rogue, which I think has a fun little surprise inside for him. So he probably doesn't need to read it. It's more of a take-home homework assignment. So if you guys will help me welcome Josh Smith, and he is going over, starting a dumpster fire.

All right, so how many of you actually have professional programming experience? So a few of you. I'm going to go over extending a couple of open source tools that are used for data exfiltration. By doing that, we are going to come up with a common interface for, I guess, what you would consider transforms, which could include anything such as encryption,

any sort of data manipulation and the network transport side as well.

Why would we want to create our own tool rather than use what's already available out there? One key feature is that one tool may not do everything we need it to. Using these methods we can leverage open source software. I'm a big advocate for anything that is open source. How many of you have children? A decent portion. So as you know, children take up a fair amount of your free time. I have two kids myself, so basically reusing things is my method of creating an environment where I can rapidly test and not put as much effort in as I would writing something from scratch.

So we're going to be using a design pattern called interface.

Using an interface we're going to adapt third party code to fit the bounds that we want it to. And with that, we can

reproduce these... Sorry. It's my first time giving a talk. I apologize.

you can create a method to get expected results no matter what the input code is. So the transform object that we are going to design will include binary input. It does everything like a black box and then binary comes out. This interface is going to implement two functions, encode and decode. It's pretty straight forward, takes the input binary encode, will encode it and the opposite is the decode.

Then we will group them together like layers in an onion in an engine object so therefore the top layer would take the raw data and then pass it to the and encoded data would come out. Decode's obviously the exact opposite except for the engine object will process everything in reverse.

So this is an example of the test code that I came up with for this concept. Some of the transforms that I chose were commercialized encryption, SWAP actually just reverses the input binary to the exact opposite, base64 which I'm sure plenty of you know, and Markov chains.

So that's half of the equation of exfiltrating data is you want to implement some sort of steganography to plain sight, the other half would be actually removing it from the network. So with that we design an interface for the transport objects which implements two methods, listen and send, pretty straight forward. Inputs, exact same thing, everything is just expecting a raw binary stream and it processes same way as the transform object except where it operates over the network protocols.

All right, so this is a diagram of the entire process. So starting with a client it would implement the first transform and go down through the fifth. Then it would actually the network translation to a server object which would then perform the decode operation in reverse.

So how many of you have used DET, it's an open source library for data exfiltration? Other features of it include Slack, Twitter, IPv6 which can be used over Teredo, 6-4,

several other different technologies to

translate from IPv4 to 6, as well as Gmail, Google Docs, SIP, and Ping. The method that needed to be in that is it actually implements a controller class for the application itself and we will go over how I chose to encapsulate that inside of the code.

So the above screenshot is the actual plugin architecture that this open source project used. It implements the config and it expects an app object to register several callbacks such as the send receive.

So this is my implementation of the wrapper. Essentially this small piece of code takes the entire source of and all the network objects it implements and wraps it to the binary interfaces that we discussed earlier. It's pretty short compared to writing all of those network protocols myself, it would have been a lot more work. So even the register plug-in one doesn't actually do anything, it's just because data expected it.

Essentially this implements the application side that all of the plugins were expecting. From that, this is an example of just one of the protocols, TCP. I implement the send and receive objects that are expecting the input.

The second project I chose to use was PyXFIL. It uses JetDirect, MDNS, all joined a couple other different ones. Some of the more interesting features it had is it actually has physical means for exfiltrating data such as QR codes, audio. I think there's even a plug-in for AM radio transmissions using the built-in sound card.

By wrapping that in the same type of interface I'm able to leverage all of those features for exfiltrating data as well.

This is the example of the DNS implementation within PyXFill. It just implements the class itself for the send and receive.

PyXFill did not need any data. kind of special adaptions except for some binary changes so it expected binary instead of character input. Other than that, all of the methods were pretty much ported over with six to eight lines of code.

Okay, the top one, I'm going to say this word once because it It short-circuits my brain. Markov obfuscate. I butcher it every time. I've practiced it. I can't do it. So it's an interesting project that takes a corpus of text, which could be a book. And the instance that I'm going to use in a short demo is going to be Taylor Swift lyrics. And the original authors, that's the... example they used as well. This is a form that we can use to encode data in plain sight and bypass DLP filters that are relying on signature analysis. As well as base 64, compression and encryption as well.

All of the code is available on GitLab on forward slash Joshua-Smith slash bsides rdu2019. Obviously the credits go to the open source projects that I decided to use in it. And we will, if I can get

my examples pulled up here.

Please.

The actual code that itself accepts a list of the transforms. In this example I chose to use the same ones that I showed in the slide. But as you can see it's fairly straightforward. One of the neat features about the framework that I decided to implement is the fact that these steps can be rearranged or removed at any point. So say we want to remove the AES.

And with the debugging enabled it shows the entire process and here are your Taylor Swift So just to put yourself in a scenario, if Facebook is allowed on your egress in a corporate environment and someone is posting Taylor Swift-esque lyrics to Facebook, it's not going to trigger any sort of a response to the untrained eye. I believe that Methods like this would render any kind of signature based analysis completely useless and you would have to allow behavioral or even statistical anomalies to determine if there was any strange activity going on.

So instead of the full process, this just encodes the data and then sends it across a simple network connection, just using the TCP engine for this. I did have a Windows VM setup for some of the PowerShell modules, but I'm unable to get to that it seems, unfortunately. But

this should be an example of

working over the network. Essentially the only thing that has to be shared in these instances would be the AES key and the actual list of manipulations you chose to use such as encryption, swapping, base 64, the Markov chains.

input data was actually some fake information for myself. On the left hand side you could see what would actually leave your egress on the network and on the right what any threat team or actor would receive on their end.

I ran a little bit short, and for the mishap at the beginning, like I said, it was my first time I gave a talk. It's hard to judge how much content I needed. But are there any questions that anyone has? Yes, sir. On and off since May. Yeah. Yeah.

It pulls in all three of these open source projects and allows you to utilize them seamlessly. Probably total time for me to develop it would be under 20 hours would be my estimate.

Any other questions? Yes, sir.

Yes, so some of the roadmap features that I have mapped out for myself would be implementing a C2 which would then include a feature such as that but one of the ones that I wanted to expand upon would be including a pseudo random list, I guess would be the best way to describe it. So the order of the list would also be random with each transaction.

The Python client was for the Linux implementation of it. There are some PowerShell scripts in that repository. There's more I need to push to it, but my Windows implementation is actually using PowerShell and reflectively loading binary or even shell code into memory rather than writing anything to disk.

Any other questions?

Well thank you all for enduring.

your brain fart and then it messed me up the rest of the time. Don't worry about it. Don't worry about it. I mean, we all have to start somewhere. And you should start at a B-side. You know what? I don't have the balls enough to commit to B-side yet, so good for you. And there were some really good questions as well, so congratulations. Oh, yeah.

Brain fart messed me up, man. Yeah.

This is like one...

Yeah. So I gotta pace myself better. And I gotta get a better night's sleep. And I gotta expect to...

Yeah, I'm connecting to it from here in the house. Like I tried to pull it off, but it's pretty poor connection.

Just