This webcast was originally published on April 7, 2022.
In this video, Mike from Black Hills Information Security discusses the comprehensive process and various methodologies involved in penetration testing. He breaks down the different types of penetration tests, such as external, internal, and cloud pentests, and explains the phases from reconnaissance to reporting. Mike also highlights the importance of persistence and situational awareness during testing engagements.
- Pentesting helps organizations understand their security risks from a practical, not just theoretical, perspective by simulating real-world attacks.
- A good pentest provides comprehensive assessment, including technology, processes, and security controls, and offers actionable recommendations.
- While pentesting, it’s crucial to stay within scope to maintain legality and avoid adverse consequences.
Highlights
Full Video
Transcript
Jason Blanchard
Hello, everybody. Welcome to this Black Hills information security webcast. My name is Jason Blanchard. I’m the content community director at Black Hills. And today we got, Mike. Mike’s going to do an introduction to pen testing, and I’m glad that he is.
And we’ll talk about that a little bit, as he starts his presentation. But, we get a lot of requests on. You all do pen testing. You talk about pen testing. Well, how do you get started? And so Mike has put this presentation together.
If you have any questions, you can always ask them inside of discord and a whole community of people that will be there to answer them. Yes, this is being recorded. Yes, this live are available on discord. So you can go ahead and grab them there.
And I think that’s it for now. Mike, are you ready?
Mike Felch
I’m good. Yep.
Jason Blanchard
All right, Mike, I’m going to kill my camera. If you need anything at all, just ask. I’ll be on the, I’ll be here.
Mike Felch
All right, cool. All right, cool. So, as, Jason introduced, we’re going to talk about introduction to pen testing. This is not going to be like a deep dive into anything super sophisticated.
It’s mainly put together for people that are looking to either transition into like a pen testing type role and wanted to kind of navigate through the details around that, and then also for people that might be hiring pen testers that want to know what they expect from an actual pen test.
So it’s kind of that if you’re here because you’re like an advanced red team or looking for zero day, you’re in the wrong webcast. And so a little bit about me, I am on, the black Hills team. I do red teaming and pen testing.
I do some security research here, looking for new cool stuff. I got started way back in the day, in the late late 1990s. I got started in the BBS days.
So if you were a part of that, you could appreciate hacking renegade BBS backdoors. got my start, actually in pentesting before it was actually pen testing, with a vulnerability called CGI bin PhF, which is super cool, gave me the ability to read, local files on computers and stuff.
I did, start developing software in visual basic. Three downloaded, awares copy. Actually, a, friend of mine, that’s on the webcast, he actually got me started writing some sort of AOL tools.
I didn’t do the AOL thing. I kind of skipped over that. But I was able to write some cool roombusters and punters and stuff back in the day. So this is a long time ago. And been technically pen testing career wise since around 2005.
So been seeing a lot of cool stuff over the years and we’re talking about some of that now. But Before we get kind of jumped into the presentation, my video is going to be jacked up for next couple of slides because of these animated gifs.
But and yes I said gifs not gifs. The problem. So a lot of people are confused. How do they transition into pen testing? And So we’re going to talk about that. We’ll also look at some of the ways that people might already be in tech and how they could transition in We’ll talk about the difference between pen testing and red teaming.
So we’re going to try to answer some of these questions in this And then also kind of look at some of the ways that we could build experience. So these are all kind of some of the issues that people have when they’re trying to navigate into the pen testing industry.
We’ll talk about certs and training and bug bounties and all of this and all of this confusion that comes. And so we hopefully can work through some of that by answering some of those. So we’ll look at the different types of tests, as it relates to pen testing.
We’ll break down the phases of the methodology that we typically use in most pen testing engagements and then how to leverage some of those existing tech skills that you may or may not have in order to kind of build a pathway into it.
And then also some ways you could kind of build some of that experience. So the agenda pen testing intro we’ll talk about what pen testing is and talk about what it isn’t.
we’ll go through some of the boring stuff. Sorry. Brian and some of the other people at Black Hills, there are some business processes that we want to look at because it’s really important to get introduced to those.
We’ll talk about the pen testing engagements that we’re going to break them down and look at them because there’s a lot of confusion around. Well is it a network pen test? Is it an external pen test? Is it an internal pen test?
We’ll walk through some of that and to get some indicators of that side of it. then we’ll break down the phases of ATT and Ck methodology. Now this is going to be a little bit tricky. We’ll talk about it once we get there, but the idea is that there’s certain methodology steps that we usually always hit, even if it’s just for a small step in the engagement.
We’ll talk about the necessary evil of reporting, sorry for those people that are expert at reporting and love reports, but it’s a necessary evil. We’ll talk about why and then we’ll look at ways to build experience.
And so that’s kind of the agenda today. So just kind of on an intro. So what is pen testing? I’m glad you asked. so it’s painting the target. Think about this from the perspective of an organization looking to strengthen their security posture, or basically painting them the target on real risk within the vulnerabilities, and then work on identifying them, exploiting them and simulating real world attacks.
This is going to obviously help the organization understand their security risks from a practical, not just theoretical perspective. You get somebody in there trying to do an audit or looking at it from some sort of compliance perspective, necessarily demonstrate the risks that are associated with the vulnerabilities, although we have to do them all the time anyway.
and then we’ll look at providing recommendations on shoring up some of the security issues and what makes a good finding versus a bad finding. And so pen testing really is going to help be a comprehensive assessment.
This is going to be looking at technology, it looks at the processes that security teams might be implementing and it’ll look at the security controls. And so in a nutshell we hack stuff and then explain how we did it and then offer solutions, on how to remediate it.
and so what is not pen testing? This is not an opportunity to show how talented we are. a lot of people use this as an opportunity to kind of showboat and show how bad an organization is.
It doesn’t last well. it’s also not just a vulnerability scan. You get a lot of shops that are on the lower end that are just trying to throw out vulnerability scans and show vulnerabilities and get paid.
not going to be the case. Although we may look at a vulnerability scan and part of a certain type of network, pen test, it’s not just a vulnerability scan. People are scared of vulnerability scans.
I’ve been at companies where employees didn’t even want to do a vulnerability scan, because they were scared of the results of the organization reflecting bad on the company, which is not really the good side either.
It’s not really the case, it’s not just a place to play and have fun and get paid, although we do have fun and play and do get paid. it’s not an opportunity for us to be cooler or smarter than other others, especially from like the blue team and, and the elephant in the room.
And I’m going to say it because I say it all the time and I’m not scared about it. It’s actually more difficult, than defending, believe it or not. So defenders have to be right all the time.
M in offensive security, we only have to be right once. It’s actually, weird. I probably said that wrong. But anyway, it’s great for, it’s great that good testers avoid egos.
it’ll destroy the team. So it’s not pen testing just because you’re a pen tester, just because how to hack stuff and break stuff. If you have a horrible ego, you’re going to destroy team. That’s not pen testing, that’s being a jerk. so I’d avoid that if I were you.
and if you’ve been around people that have horrible egos, what I’m talking about. Don’t be that guy or that girl or that whatever. So what makes a good pen test? pen testing is really about understanding the needs of the organization.
a lot of times, sometimes just getting in there and hacking stuff is fun, but we also really want to understand where are their needs, where are their concerns. If we could highlight those concerns, sometimes they can get budget from the executive staff.
the idea is that you want to stay within scope, obviously, because that makes a good pen test and it also keeps it legal. the moment you start venturing out of scope and not understanding that and start hacking on stuff that’s not yours or not your organizations that you’re being tested is the moment you start risking breaking laws and raising red flags and just making a really bad day, especially happen by accident.
A lot of times, customers will give you a list of IP ranges or something. And if you don’t really just keep your eyes on what they’re providing in scope, they could be providing you IP addresses that they no longer have allocated and that have changed, that are owned by their competitors or another organization.
The last thing you want to do is hack on something that’s out of scope and, you’re going to be demonstrating that the risks are vulnerable. I mean, I’m sorry that the vulnerabilities that create the risk are exploitable. So the idea is that, you’re not just finding the issues.
You want to demonstrate that those risks actually occur within the organization. a good pen test also will have the report as you go. We’ll talk about that in the reporting section. But you’re going to want to capture the evidence as you’re going.
The, last thing you want to do is get through a week, two weeks, three weeks of a pen test, and then realize you didn’t report anything and you have to go back through your notes and it’s a mess. And then you end up getting, in trouble because you don’t have what you need.
another good pen test component, is frequent communication. So you want to be able to provide status updates to the customer. You don’t want to just leave them in the dark. Although sometimes they can get really annoying if they want. Want to have, super daily stand ups or multiple hours throughout the day.
I try to avoid that, but, it can get annoying, but it’s definitely something that you want to maintain proper communication. You want to keep them in the end. You might want to be able to get some feedback from them on navigating in a different direction if they highlight something on your radar.
So it’s good to know that kind of in the middle of the engagement, and you’re going to want to really spend time on the report and any of the actionable details about that report, because that’s going to be the deliverable. You’re providing that to the customer.
We’ll talk about that later. later. Slide. And then I think one important part is also staying healthy. being pen testers, sometimes we’ll run through the night. It happened to me just like two weeks ago.
I ended up working through the night. Didn’t have to, but I did. Because of pressures from, the engagement. I was on a limited time. My session was going to be expiring when my VPN connection dropped.
And, and I worked until like 05:00 in the morning. That’s not the norm. It was in my case, because I wanted to follow an attack path that was all the way through. And I knew my time was limited.
but immediately the next day, I took that day off. And so, and that’s important because that’s the health aspect of it. If you’re not healthy, your test is going to be unhealthy, and the deliverable is going to be unhealthy, the customer is going to be unhealthy.
And then your employer is going to suffer from that. And so with that we’ll talk about the business processes. This is once again a necessary evil.
so the scoping portion of it, this is normally handled by another team within the firm, or another team within the pen testing side.
So usually we try to avoid a lot of the hands on business process and we want to focus on the technical and the deliverables. But part of that scoping process is really understanding the scoping and how it’s, how it’s brought together, because as a pen tester you’re going to want to make sure that you understand it.
And so one of the things that scoping brings to us is to be able to spend time before the engagement preparing, to understand what those needs are of the organization so we could properly capture them properly understand, understand the pen test perimeters and what type of engagement we want to be able to introduce.
sometimes they’ll come in and say, hey, we want a red team, but they don’t really know that they don’t need a red team, that they need a pen test or something specific. So understanding what those are and then defining those pen tests into perimeters, this really outlines who’s in scope or what is in scope, if it’s technology, not people, and then it’s also too great to really understand how to avoid or be cautious about certain critical servers that are on there or certain times of the time of the day when backup processes occur and really understanding what to be cautious about.
Super, super critical. sometimes they’re tied to third parties, they might be implementing like a third party provider of some sort. This is especially useful within cloud. So if they’re using a cloud provider, we want to understand that before we get into the engagement because we want to really make sure that we’re setting the scope properly.
one of the big components I would say too is understanding the size and number of resources. So like we’ve had situations where we’ve had a cloud pen test, they hire us to do a cloud specific pen test and they want us to test their cloud provider’s environment.
But the problem is they don’t tell us upfront or we don’t ask up front properly and we do this. Now, we didn’t always do this when we were rolling this type of stuff out, but when cloud was new, a lot of companies have 20 different AWS environments.
We need to understand that because having 20 environments with 1000 resources in there and scoping it for just a small portion of time that leaves us in a really weird bind where we have to go back and rescope and then reassess.
And then a lot of that can be mitigated if we did that upfront. and then also we set bi directional expectations. So what are their expectations of us and what are we delivering for them?
and so while it is a part of the business and it’s not necessarily always depending on your firm, a part of the pen testers obligations, we need to know, and you want to be able to confirm it because we’re going to have meetings with the customers and we want to be able to stay on the same page as the scoped originally was, laid out, and so understanding that will avoid a lot of trouble in the future.
there’s another component to this where statement of works and master service agreements kind of come together. So an MSA or sow will come together. This is really highlighting the scoping, the pen testing details, the deliverables, it’s the formal position and, permission from the organization for testing.
So it kind of hides the signatures and the agreement and all that. It outlines the testing objectives and the logistics of that. It’s also a get out of jail free card. if you are hired to do a physical pen test and you’re breaking in, you want to be able to have a copy of that signed and delivered because you start getting caught or you get busted and law enforcement gets brought in, you need to have some sort of, proof that you’re supposed to be there.
It can get really dirty really quickly. and it’s also a single snapshot of the who, what, where, when, and even why of the agreement between the organization.
So why do we care as a tester about this? Because it’s important that we align with the sow before we start. If we don’t, shame on you.
and so meetings, business process meetings, another horrible component, for some people, usually we have scoping meetings that, a tester will be in part of, in order to kind of walk through the app and walk through the network or walk through the cloud environment, that way there’s no hidden scope.
We don’t want scope creep. Scope creep is horrible. it’s a bad day for the tester, bad day for the organization, bad day for the testing firm. And so, usually if you can be a part of the scoping call that’s super good, it’ll benefit, you in the long run and then daily stand up sometimes these are optional, sometimes these are mandatory.
It depends on the organization, but it’s an idea of being able to just communicate, what was accomplished and what’s next. If you’ve been in like a scrum meeting as a developer or a database admin or a scrum master, you can appreciate daily standups sometimes, especially if they’re real short.
usually this can be resolved in emails. A lot of companies that we’ve seen want emails rather than daily stand ups. Nobody likes meetings except for, people on movies.
Important meetings that are there. So rules of engagement, some people call these like a pre engagement, meeting. It’s the opportunity to discuss the objectives, make sure all the prerequisites are laid out and that the logistics are there.
This is like, hey, we need this from you and you need to provide us with this. That’s what goes on in those rules of engagement, types of meetings. it’s useful, very important and it’s a good opportunity to kind of really just, just inform the organization that hey, we’re starting testing on this day and be ready.
A hot wash is another important meeting. Some people call them debriefs. it’s a place where you, after the engagement, but before the report is technically delivered, you can have a discussion of the findings.
A lot of times executive staff gets pulled into this. You might be interfacing a lot of the c suite, kind of just going over a high level overview. It’s really a good opportunity to highlight what went well. You want to, especially if the people who like, if you compromise the software development lifecycle for some reason, or you compromise an application and that developer is going to be there, it’s really good to highlight the positive things because you’re coming into that engagement and you’re going to be talking about some of the bad things that were discovered.
And so you want to make sure that you’re not just tearing people down when you’re doing it. And it’s a good opportunity to kind of do that. And then another important meeting is the emergency meetings. If you find something critical, or there’s something that’s going to interrupt the business continuity, you want to make sure you raise that, as quickly as possible.
So it’s another important meeting, and so service delivery. So this is going to be when we’re actually engaged and we’re starting, we want to adhere to the start and stop dates. They need to be well defined.
So if it’s starting on this day and ending on this day, if you need to go beyond that, make sure that it’s communicated and then you get their permission, get it in writing and email, whatever. and you want to stay within the confirmed testing time.
So I usually offer up. Is it okay that we test after hours if we need to, rather than say, is there a set time that you want us to be testing? Because if there is, there’ll be, depending on the organization, they’re either going to say, yes, only test from nine to five, in this time zone, or they’ll say, yeah, could you please only test 08:00 p.m.
to 04:00 a.m. because we don’t want to interrupt business. You don’t want to get caught in that thing. so it’s usually better to offer up, hey, we plan on testing during the day. but in the event where we have to move into the night, is it okay if we do that?
usually they’re super appreciative of that and they’re usually good with it. And, also understand when do we need to escalate findings and issues. So, in the event where there is something that was successful and we’ve compromised, let’s say we’re on an external and we compromised internal access.
sometimes it’s, it’s, it’s always good to stop because that’s the scope. But you could always go back to the, the point of contact and ask, hey, can we reestablish objectives? I’ve compromised the server. I know we, we said we were going to do external, but we compromised internal.
Should we move laterally or do you want us to stop? That’s a good, good point. Sometimes they’ll get more bang for their buck if we move in other directions. Once we compromise it, you really want to capture evidence, write your methodology and track those changes as you go.
If you don’t, like I said, it’s going to be for a bad day having to go back and do all of that. And then, the other thing too, that I would, I would highly, highly recommend is, post engagement cleanup can be really messy.
And so if you’ve dropped a payload on a server or compromised some credentials, you want to track what you’ve compromised because somebody has to clean it up. You can clean it up if they want you to clean it up. If they don’t want you to, you can provide it as an artifact at the end of the report, we’ll cover that.
but it gives them a healthy way of being able to understand what was exploited and what was not exploited. And then obviously stay in scope, that’s going to be a huge, huge thing.
hot washing or debriefs. They don’t have to be an exhaustive list of findings. Just high level is really good. Usually highlight the high or critical findings. I try to avoid medium or low. If, unless it’s absolutely necessary, necessary to build an attack path, speak to the systemic problems as much as possible.
High level. Sometimes you want to avoid technical, depending on your audience, if you’re on with a bunch of executive staff, they don’t want to hear deep down technical details of how you were able to exploit some server with some remote code execution.
They want to know high level systemic problems. and so really highlighting that as much as possible. It only needs to be a couple slides. But it’s good if you do that because you can provide them with a slide deck. They could take it away. And then it also gives you the ability to talk about next steps and report delivery.
So let’s talk about the pen testing engagements. So I break these down into different types of engagement. So we’re going to talk about network first. so we went talk about the business processes. Let’s move into some of the pen tests.
These are going to be the different types of things. This is where confusion should be cleared up a little bit. so on an external network pen test, you’re looking for external network vulnerabilities that can be compromising their perimeter.
So it’s not like your active directory, so to speak. It’s going to be more like web apps or network services that are running remotely, or cloud, for instance. and your goal is to really uncover issues that could lead to a breach.
And so we’re looking at everything from, cloud attack paths to vulnerable, web apps that lead to a compromise of a server. Although we’re not necessarily scoping web apps to be a deep dive, it could be leveraged as an attack path to gain access to a server that’s sitting on the perimeter.
Who knows what’s behind that? It could be putting you into a VPC environment within AWS and you wanted to laterally move there, which would be reestablishing those objectives. But it gives you that kind of attack path in, it’s usually scoped to IP ranges, or subdomains or domains, and so sometimes they’ll give us URL’s.
But I try to avoid that and just try to scope it back to, hey, I’ll just focus on the domain or the subdomain or an IP range because you’ll be surprised how many cider blocks they’ll provide to you. And so in the event where it is a domain or a subject subdomain scope, just be aware that sometimes people assign a subdomain to a third party service and so you’re testing the third party service, not necessarily the subdomain.
And so this is where you really wanted to get familiar with that because it’s important to understand the scope on where those IP addresses go. So make sure you’re double checking and crossing your t’s before you go popping boxes.
and then also there’s a lot of times there’s web application firewalls that are in front of that. so on an internal network pen test different than an external, you’re finding and exploiting internal network vulnerabilities. This is commonly active directory environments.
sometimes these can be considered like an assumed breach. So they’ll start you off instead of like having to fish your way in or social engineer your way in. They’ll put you on like a compromised host and give you like basic standard user domain user access.
And they may or may not want a vulnerability scan with that. there’s going to be people probably on the webcast, that are pen testers that say vulnerability scan on an internal network pen test.
Yes, we do it. It’s not necessarily about thing, it just runs in the background. We look for vulnerabilities that we may have missed. I usually look at them towards the end of the engagement so I can, walk through everything, beforehand.
It’s usually objective based. So a lot of times internal network pen tests are saying hey, can you pivot to this ScadA environment over here and, or here’s our gems. Can you find these gems and find what tac paths that get you there?
and so these are a lot of times they’re not necessarily vulnerabilities in systems. So like all of the super crazy cool stuff where vulnerabilities and memory corruption occurs, it’s not really that anymore.
It used to be, now it’s more like misconfigurations in technology. so active directory misconfigurations or network file shares that are misconfigured. and it’s usually objective based assessment.
So we’re focusing on exploiting paths or misconfigurations that lead us there. And so it’s really understanding the risks that are associated with breached perimeter.
So breached perimeter happens, boom, we’re done. So now what’s the risk? And that’s kind of what we’re looking at. a lot of them could be monitored by soc or mssps.
they could be. A lot of security controls are on the internal network, more so than the external network. these go beyond your external pen test. It’s a great, it’s a great way if you’ve been doing external pen tests and you wanted to start doing internal, it’s a great transition.
It’s also great for baselining before a red team. And so the difference between a network pen test and a red team engagement is that the red team engagements is assessing the ability to detect, contain, eradicate and recover from a breach.
So you’re assessing the security controls and teams that are there monitoring and responding to incidents. And so a lot of times these are going to be detecting and exploiting all the vulnerabilities that we could find that lead to an, I’m sorry, that lead to an attack path, not all of the vulnerabilities that we find.
So it’s about low and slow testing to stimulate a motivated attacker, blending in, telling stories. These are all the things, we usually leverage phishing and social engagements in order to compromise the perimeter and gain internal access.
And we’re basically simulating a real world security incident in a short winded time. It’s great for organizations that have mature security programs and or whoever mediated prior internal pen testing engagements.
I’m going to kind of skim through some of these. These are going to get deeper. I want to make sure I have time to cover everything. But, cloud pen test, this is a newer thing that’s been popping up a lot more.
what we test is infrastructure as a service or software as a service. So you can imagine infrastructure as being like your Azure environment or your AWS environment or Google Cloud provider, for infrastructure.
Whereas a Saasden is usually some of the big platforms, g suite or workplace or whatever, workspace or whatever it’s called now, or office 365. So you have misconfigurations that are within these platforms.
And so it’s assessing the misconfigurations within, Google groups. I found a Google group where some software developers and system admins had spun up an internal Google group and they had all of their Crontab logs, that threw errors going to this Google group for distribution.
But that Google group was wide open. So being able to leverage that Google group, I was looking at command lines and finding passwords all day. Those are the types of vulnerabilities that you’re looking for within this configurations, whereas AWS might have like a wide open policy or something.
and so we’re looking for those overprivileged cloud resources that we could leverage to gain access further into these environments. a lot of times we could do password spraying or we could find vulnerabilities in web apps for like a server side request forgery.
If you could find a server side for request forgery like within AWS, you could sometimes hit the metadata URL and that gives you kind of useful, credentials, access keys and stuff like that. So we’re looking for those, and we’re basically just looking to compromise resources or source code or misconfigured storage within cloud.
Then for container escapes there’s a number of different types of vulnerabilities that highlight specific like kubernetes or docker, where you can leverage different types of misconfigurations in order to gain elevated access or data.
this is more focused on specific tasks. So if you’re like, if you’re a cloud admin or someone that wants to get into pen testing, this is a great transition. There’s really a shortage of people with cloud pen test experience.
So it’s wide open industry right now. So good transition there. if you’re a network admin or a system admin and you wanted to transition, maybe focusing on network app pen test is a great place to do that.
if you’re a developer, web apps are great for you. so we do a lot of authenticated and unauthenticated testing. So from different user levels as well. So standard users, can we escalate to admin privileges?
Can we go user to user and be able to compromise other users? Users? on the system, we usually focus on owasp top ten. So your SQL injections, your cross site scripts, all of the stuff that’s pretty critical to the integrity of a web app is what we’re testing.
there’s a number of frameworks that are affected by different types of issues. You can imagine finding a WordPress or finding a drupal, system. We want to look for those types of vulnerabilities that are plaguing those types of frameworks a lot.
we also want to look at it from an unauthenticated perspective. Can we log in from an authenticated perspective, then log out and then test it? From an unauthenticated perspective because you’ll be surprised what you can actually find there.
then on the web API, it’s basically the same thing with the web app, but you’re looking at more of the parameters, the endpoints, like the swagger, the customer will sometimes give you a swagger of all the endpoints and the parameters that go with it.
It’s a great way, to tie it in with the mobile app pen test because a lot of times mobile apps are speaking with the API. Usually good, and then it’s also great if you have a mature SDLC for software development already.
It’s a great way to roll a pen test into the end phase of the SDLC before it goes to production. So you’ll curb a lot of the issues before they make it into prod and don’t have to test on prod.
So it’s great for that. mobile apps, mobile apps really focus on iOS and Android apps. So as you can imagine it’s static and dynamic testing. So static being looking at the app from the vulnerabilities from a non running phone versus dynamic looking at what could be exploited while it’s running on the device.
Android testing is a lot easier than iOS. IOS is going to be tricky because they have jailbreak, and then there are certain types of jailbreak that don’t work with certain versions of iOS, and then certain versions of iOS don’t work with the apps that you’re testing.
So it gets really tricky. but we’re looking for ways for everything from statically embedded credentials or other security, issues with regards to IPC, for instance, where it’s inter process communication, or maybe they have some overprivileged that they shouldn’t have.
So we’re going to be looking for those. Android’s a lot easier, you can reverse Android, fairly easy. There’s a lot of cool tools that do it automatically, but you’re basically taking the APK, converting it to Dex.
if you’re familiar with mobile app development, you can take that Dex, reverse it back to jar and then get the classes and go through the code that way. iOS is a little bit more tricky, but there is a way that I found this really cool blog a while back that talked about instrumenting, this gadget, with what’s called Frida.
It’s like a reverse engineering gadget, but you could basically it into like an IPA, which is the mobile app, application. And you could sign it with your own certificate and then put it on a new phone that’s not jailbroke and then just approve that signed certificate that’s your own.
and it gives you the ability to kind of do some dynamic analysis on iOS. It’s super useful. and then once I said once again, you could wrap this into a web, web, web API test as well.
And so wireless engagements are a little bit different. So you don’t have to know all of these. I’m talking about all of them just to give you a highlight because you might find one that you like more. but sometimes you specialize, like we have people that specialize in web apps or specialize in red teams or cloud.
You don’t have to know everything. but a wireless engagement really focuses on common wireless problems. So this is everything from evil twin attacks to rogue, AP’s that are running and we’re looking for are there authentication issues?
are they using wep, like a weak encryption where we can crack it? Or is there a pre shared key that could be cracked that gives us the ability to gain access to this network? And if we do gain access to the network, what’s the damage?
are there allow lists that could be bypassed? Are there guest isolation where maybe if I’m on the guest network, can I see the other guests that are on there which would make their computers vulnerable? We want to identify those.
is there a system admin that’s using a wireless keyboard or mouse that could do, keystroke injections? those are good because then you could just be outside the room and inject keyboards into, computers or mice.
we also, I don’t know if you can see it up here. There’s a Dropbox right here that I have. It’s a wireless Dropbox. it’s great for remote testing so you don’t have to go on site. if you do go on site, you might want to consider a physical pen test.
This is where we’re assessing the physical security controls. We’re looking at the badges, we’re looking at the processes that they have for letting people in or letting people out. We’re looking at the environmental security issues that could relate to a compromised server room, for instance.
we’re looking at door locks. Are they using weak locks that could be picked fairly easy. are the door locks safe? Are they falling off? We’re looking at the fence line. Is there a way to compromise the fence to gain access to the perimeter?
if you look at it from like an onion perspective, you’re trying to compromise different ways, into the environment where you’re trying to break into something where you could access technology. we’re looking at unsecured assets like vehicles in a parking garage.
Are they leaving vehicles unlocked in a parking garage with a work computer. all of these are in scope. A lot of times, you want to obviously verify beforehand because you don’t want it up in jail. But, we’re looking at exposed badges.
Can they be cloned? Are they verified? are they verifying them as we’re walking in? are they checking hitchhiking? Hitchhiking is when you’re jumping on an elevator with someone else that’s going to a floor that you don’t have access to or tailgating to get into the perimeter, into the entrance.
Can you just follow someone in and have them hold the door for you? and so basically it’s gaining access to computer equipment. Usually, we usually join these with wireless as well.
hardware pen tests. These are very specialized. there’s only a handful of people at black hills that do these. but we do do them. It’s basically, if you’re good with hardware, if hardware is your thing, you might want to consider looking at doing hardware pen tests.
it’s really specialized on analyzing hardware security. So you’re looking for serial interfaces, Jtag or spy interfaces where you could actually get serial console access, to the firmware to get, extract the firmware or to gain access to the device.
sometimes you can do voltage stuff where you’re glitching the hardware in order to disrupt the boot process and then get into it. there’s side channel analysis tax where you can break cryptography and extract stuff, all kinds of really cool stuff.
It focuses on wireless stuff is your thing. not many people do it. I don’t know how demanding it is, but it’s really cool. nonetheless, social engineering, phishing is another big one.
So this is, broken into two different ones, right? So there’s metric based phishing. Like some other, firms, they’ll track like click throughs and only checking to see if you’ve opened it or provided, credentials and just track those metrics which are useful, but they have their place.
we also, have seen, phishing engagements on the side where, we get hired to only do phishing engagement. So if you just want to like social engineer people make phone calls or send SMS text messages or other types of, phishing, this is a great place to do that.
sometimes it involves malicious payloads, sometimes it’s establishing c two on a network. but the idea is that you’re phishing, sometimes you just want to grab credentials. I focus on credentials.
I say creds are king. and the reason is because if I could fish capturing credentials or authenticated sessions, then I could try to pivot in the cloud and maybe gain access externally.
We’ve done that before. so I’ve seen that where you can gain access internally just by compromising external. So just something to consider. and then also I would encourage if you’re phishing, don’t just rely on email.
I think a lot of people just their go to is email. But think about like social networks like LinkedIn messages or collaboration tools. Like one of my favorites is using Google, google comments on word docs, or calendar injection where you can inject calendars into it.
It’s super useful fishing, but it’s highly overlooked, I don’t know why. So let’s talk about methodologies. This is going to be the phases of methodology. And so reconnaissance, this is passive reconnaissance.
This is going to be the first step of your engagement. And this really goes for any engagement. So if it’s an internal or an external, it’s the reconnaissance that you’re doing will look different. But if you just break this down into like a passive, passive reconnaissance is when you’re looking for information without actually interacting with the hosts that the customer owns.
And so everything from network and IP information to SSL certificates and subject alternative names that are on there. Anything that you could interact with a third party to gather intel.
This could be LinkedIn for usernames, or for names that you generate into usernames. It could be GitHub for source code repositories or DNS providers that have cached DNS already where you’re not actually hitting the DNS server, but hitting a third party DNS, that’s useful.
You can look for third party breaches. I have like I don’t have a database. I know Ralph has a massive database where we just gather all third party breach data and then go to it and query for the domain name and extract, usernames or even passwords that might be used.
open source intelligence techniques. This is other sources that aren’t necessarily technical, but it’s useful. and then you can look at like the technology stacks at the company. Do they have a listing?
They’re hiring for a system admin with experience with this security product or this other technology stack. It’s a good indicator that that’s what they’re using. So grabbing that if they’re a cloud provider, grabbing the cloud tenant information from that provider if you can.
There’s a lot of cool tools like that and then Google Foo. So just kind of walking through search engines looking for files and URL’s and intel, whereas active recon is where you’re actually port scanning.
You could go to get port information from like Shodan or you could actually interact with the service directly. That’s going to be interacting more of an active way. and so you’re going to look for subdomains, port scanning, looking for services, what’s running on the services, screenshotting web servers, looking for vulnerabilities that are there.
You might want to enumerate usernames. This is going to be one of those things where you’re trying to find valid usernames to a service. So that’s good. directory and file, brute forcing.
If you’re looking for certain endpoints on web servers you want to really fingerprint as much as you can because it’s going to be in your reconnaissance that’s going to lead directly into your vulnerability discovery and your exploitation phase which we’ll talk about next.
vulnerability discovery, this is really brought into the phase around like looking for vulnerabilities without necessarily exploiting them.
So vulnerability scanners like Nessus or Nikito, if you’ve gone through any offensive security courses, you’ll notice those names, technology scanner. So if you found that they’re running some sort of specific web app, you could throw SQL map at it for instance, and it’ll look for SQL vulnerabilities within databases.
if you’re finding older JavaScript versions of frameworks, retired JS is good. But the idea is to really try to look for vulnerabilities as much as possible.
If you’ve configured Bert before, that it has some active and passive discovery for vulnerabilities and you’re basically looking for what you could exploit. That’s the nature of it. There’s everything from NMap scripts to manually doing work to trying to find service version information and then cross referencing that to CVE’s is good.
on the exploitation, I don’t use Kali personally, I’m not a big fan of it. I use it every once in a while. If there’s a tool there. But consider using kali for the tools. If you’re going to do it that way you don’t have to pre install everything.
It’s a great way to get started. I’ve gotten to the point where I know what tools I usually use, so I just pre configure an Ubuntu version. but Kali is great if you just don’t want the headache of having to install tools, and then consider using a framework like metasploit.
It has a lot of built in stuff where you could scan, find and then exploit vulnerabilities and give you access. You can look for exploits on exploit DB, but you might want to verify what they’re doing beforehand.
Don’t trust the shellcode that’s there. You never know what it’s doing. but it’s a good place for finding stuff, vulnerability scanners sometimes can exploit as well.
So just keep that in mind. If you’re scanning and it’s on a critical server, you don’t want to interrupt anything. I would always, always, always mess with manually inputting stuff into URL’s, into parameters, into network services.
Netcat’s your friend, look for ways you could try to get some feedback or some sort of different errors back and you could exploit vulnerabilities that way in order to achieve some sort of objective, within there.
This could be anything from leaking data from a database to compromising a web app, on a server. But the goal of exploitation a lot of times is either to get access to data or to gain access to a server.
so a lot of times this could be file uploads on a web app that gives you the ability to a webshell and compromise a server. And then once you’re there you have lateral movement and escalation. But you want to look at those things.
So it’s basically executing something under elevated privileges is a good way of considering what exploitation looks like. Once you do compromise something, this could be a database that you’ve gained access to.
You’re going to want to really focus on situational awareness. This a lot goes overlooked and I can’t tell you how many times I’ve seen even red teamers that are not doing any sort of session prepping or situational awareness where they’ll just run in and then just start running rampant.
But they don’t realize that there’s an internal team that’s watching their, everything that they’re doing. So you want to really spend some time understanding, what did I gain access to? What data do I have access to?
Am I on a shell? What operating system, what users and groups are here, what processes are running, is there a security product? did I capture credentials? What do they go to? All of these things are really useful in being able to understand what you have access to and where you need to go next.
And so if you’re on an internal network is a domain joined super critical? what users are currently logged onto the machine that I’m on? Are there m mounted network file shares or mounted partitions that I could, access?
Is it missing any patches? Are they running laps or anything like that? these are super critical in order to understand, where you’re at and where you need to go, because if you don’t know where you’re at, you don’t really know how to get where you need to go.
So and then persistence, now all of this is going to look different for different types of attacks. I’m just kind of throwing that out there. So I’m kind of blending some of these persistent methods, whether it’s external or whether it’s an internal together, or cloud.
So the idea behind persistence is maintaining access for either command and control or a beachhead into something, or having a weaponized service that you’ve compromised so you want to maintain that access.
That’s what the idea about behind persistence is. Consider the different types of persistence also. Is it user lane? Are you only a standard user and don’t have admin access? Well, persisting on a machine is going to be a little bit more tricky if the way that you’re trying to persist requires administrative access.
And so, can you write your own web shell, for instance, and then make sure you password protected so you’re not exposing the customer to external attackers. But can you find ways to leverage, the service that you’ve compromised to regain access in the event where you’re kicked out?
So if you’re on an internal network and you’re on a machine, there’s registry run keys that you could do run and run once. so there’s ways you can set those. You could add backdoor access if you’re on Linux to the authorized keys.
if you’re in a cloud account like Microsoft Azure, you can actually create guest accounts by default unless they change it. you could just create a guest account. So that way if your account has been compromised, you can just log into your guest account and still regain access to the active directory within Azure.
you can plant DLL’s for side loading. So this is a really cool technique. If you wanted to do like Microsoft Teams for instance runs is in the app data folder and if you wanted to drop like DBG help DlL into that folder, it’s user land.
So you could basically put your malicious DlL there. And next time that computer starts and Microsoft Team starts up, it’ll get your shell back. you could backdoor.net app domain configs, which is really cool.
So if you find like a SQL um.net app that’s running, you could backdoor the app domain in the config file to launch your own binary. So there’s other stuff too, but that’s just basically persistence.
so on pivoting, this is when you’ve compromised it. Now where you need to go. Now you go right. So it’s laterally moving. and there’s a way, there’s a number of things you could do.
One of the more popular ones, this is usually one of my ones that I like to kind of, I like to highlight upfront and I try to do it quietly. is exploring the file system.
is there anything you could abuse on the file system? Sometimes there are services that are running, that you could escalate with, or that you could leverage in order to move laterally, with that there’s different techniques that you could run.
So there’s a lot of different windows services and I’m only highlighting a few of them here. But like WMI or SCM, these are protocols that are running within the environment that you might be able to run code on other computers if you have the ability, the user permissions to run code on those.
So if you staged like a binary on like a network file share that’s accessed on another computer and you’re able to, your user has the ability to run like RDP or something over there.
You could run your code on that server and then just laterally move to that machine. It’s important because you want to identify where your target users are having existing sessions on the network because that’s going to be where you’re wanting to pivot, especially if it’s a domain admin.
You could poison some of the Microsoft protocols like llmnr, or netbios in order to do some of the old school relay attacks. You can capture credentials also and pull them offline to crack passwords, but your goal of pivoting is basically to compromise services on other machines.
This could be SQL servers. This is like my favorite, being able to find a SQL server that’s running, have some credentials, pivot over to there, escalate privileges, which we’ll talk about next.
Escalating privileges. This is super cool for password spraying. You could do this for leveraging protocol attacks. you could do kerberosing where you’re pulling spns and pulling these hashes offline and being able to crack them to access file shares or other systems.
but your basically goal is to elevate your access. There’s a number of ways to do that. You’re elevating access to these other services in order to be admin or domain, admin ultimately if that’s part of the objective, but it’s to gain access to a machine where domain admin for instance is logged into, where you could dump memory and extract credentials.
so you’re basically wanting to escalate into some sort of administrative credential role, and attack those services or servers that way.
So I’ll kind of go through this fairly quickly. This is the necessary evil of reporting. This is what reporting is all about. So you have key components, executive summary, findings and methodology.
Now there’s a lot more into this. Executive summary can be broken down and I’ll try to highlight some of it. But John Strand, favorite quote, or not, maybe not favorite, but my favorite quote of his report as you go, he’s created us plaques for it.
It’s super important. Do it, take useful screenshots, understand that you’re painting the context of what took place. You want to be able to provide enough detail where they can recreate it. And so as you’re gathering this information and you’re going to provide a list of artifacts to be cleaned up, but you’re providing context to the report.
Your report is your deliverable. So if it’s not useful, it’s, the whole service is useful. It doesn’t matter if you compromised every objective as domain admin. If you don’t have a quality report, you’re doing a disservice to the organization.
So just remember that executive, summaries are high level. It’s mainly to the executive staff. it’s non technical, systemic findings. You could just think about it from that perspective.
It does highlight the risks that are involved with this. So if there’s something critical that you find, you want to really highlight that, and it’s strategic guidance for the organization. and so just remember, don’t use technical language.
The technical language is going to be in the findings. So the findings is going to be, we’re going to break down some of that. But the risk associated with it, it’s not a one size fits all. So should you upgrade like let’s just say you found like a super low information disclosure, but that information disclosure could be chained together with something else that led to something super critical.
Should you upgrade information disclosure? Yeah, you found a bunch of SSL issues that you’re going to want to put in the report because it’s, it’s useful for them but it’s not exploitable, really requires extensive cryptanalysis.
Shouldn’t you just downgrade it or maybe make it an informational, these are the things you want to consider. you want to really clearly communicate the problem as best as possible. If you have multiple types of findings, consider like grouping them together.
it’s useful. And so you want to talk about the observation. This is what you found useful to the context of the environment that you’re testing. So you’re describing what you observed.
It’s the lower level technical details. This is where you really want to put how the exploit happened. Include screenshots or lists or code snippets and anything useful.
Did you find something sensitive on the network file share, provide the details of what you found and where you found it. Something that they can go back and make sure that they just look at and resolve. you want to stay current to the current finding too.
And the finding details should be unique, because the discussion component of the finding is where you’re going to be explaining why the finding is the finding to begin with. It’s not necessarily the details of their environment, it’s more of this is why this is bad and why this creates risk.
You could provide narrative if you want, but it’s going to be expanding on the risk that could lead to further impact, in the event they don’t remediate it, because in the remediation phase you want to be able to provide recommendations.
This is the strategic guidance for the recommended finding. and so this is going to be unique, for the environment. This is a recommendation. This is not saying you need to do this. You want to kind of make sure that they understand their environment better, but you’re going to want to provide some defense.
In depth recommendations. It’s a great place to start, to include like best practices and even follow up for recommendations. I feel like I went backwards. I did methodology.
so this is your attack path. This is what you did for your exploitation. It’s third person narrative. You want to talk about the what, the when, the why, and screenshot everything that you used in order to compromise it.
Consider using like descriptive sections like recon or initial access. Always provide descriptions and screenshots. So if a lot of findings are there, consider only highlighting what was successful.
You don’t want a 300 page report talking about everything you tried that didn’t work. Only focus on those findings that did work. In the event where you had minimal findings, consider highlighting what you did because you definitely want to be able to demonstrate that you actually did something.
So anything, that you’ve tried to do would be a good thing to include in here. Scope, and data archives. I’m going to just skip over this, but basically what was in the scope and then if you have any supplemental data that you wanted to provide, like scanning, you can include that in the data archive.
and so let’s talk about building experience. So you kind of got the gist of the engagements and then what goes on in an engagement. Capture the flag is a great place. It’s a competitive or non competitive way of hacking on a cyber range.
It’s useful, it’s a great way to learn and practice. And it contains solvable challenges. So they actually do have something that can be solved. And it’s an all different technical verticals. Really useful.
most conferences have them. Here’s a few links. It’s in the slide deck. We’ll put it in there so you can kind of go hack around on some ctfs. It’s fun to do together with friends as well. Bug, bounty is another really great way.
People make massive livings off just doing bug bounties. They attack real companies, they find real vulnerabilities and they get paid. there’s a few major providers like Hackerone and Bugcrowd. there’s a huge community behind it that’s strong.
There’s public programs, private programs. but the idea is that you can go hack, get paid for it, and you’re legally hacking and it’s fun. so super cool. There’s some links on there on how to do that.
Another big one, infosec conferences. these are good. Go listen to awesome talks, connect with companies, create relationships, practice in labs. It’s all hands on. You build friendships.
I can’t tell you how many people I’m friends with now that I consider like good friends that I met in a conference, hacking on a CTF. So, there’s also, also in onsite training, blah, blah, blah, all that stuff.
play ctfs. It’s fun. and the cool thing with that is, it’s, usually your employer will pay for it. training. Consider there’s a lot of specialized training out there. We cover a bunch. I want to talk about my training next on this last slide as I close.
but the training behind this, is really, there’s a lot of really specialized. So if after seeing this, you see all the different types of pen tests and you say, I think I could do web app pen testing. Their specialized web app.
Pen testing, training. You want to do cloud, you’ve been doing cloud administration for a while. Bo’s classes. Bo has a cloud training class specialized in cloud. Go do it. Learn it.
There’s a lot of really cost alternatives out there that are, that are cheaper than like the $9,000 ones that nobody could afford, that even exceed company budgets nowadays. Find, them, look for them. They’re out there.
anti siphon has a bunch, there’s some other really good ones out there. I know offset, I has a bunch of, offensive security has some all you could eat plans now that are good. Just consider it.
you’ll develop a mindset. Don’t focus on just doing checklists. you want to develop the mindset. Checklists are good, kind of for looking to see if you miss anything not good to follow for a pen test.
Pen testing is art. Just remember that. also, it’s great for resumes and can open doors and build friendships that way as well. and then if you’re interested in getting more into pentesting, I’m going to put my own class here, obviously, because we’re getting down to the wire here, I have an introduction to pen testing class.
it’s June 27 through June 30. It’s super cheap. It’s like $545. You also get a cyber range access. we’re going to deep dive, more into internal. So actually, hands on, we’re going to do pen testing.
we’re going to do external pen testing. We’re going to do internal pen testing. We’re going to do some web app pen testing. we’re going to look at it from hands on, start to finish. When you’re done, you’ll be like, I can actually do a pen test.
And I feel comfortable. I feel comfortable digging in more, I like this over here. I want to focus on this kind of technology better. and then we’ll look at the different types of pen tests a little bit more clear as well.
it’s great for people that want to get started. if, you’re an organization that wants to hire pen testing firms or execute in house pen testing, it’s good for you as well.
if you’re a technical person already or maybe you’re comfortable with technology and you want to transition into pen testing, it’s a great way to do it. Highly recommend database admins, just anybody.
Anybody across the board. I try to, I try to tailor it for different technology verticals. it’s not, if you’re, if you have existing pen testing experience or a red teamer, it’s something that you don’t want to do.
It’s going to do you a disservice. So I would just discourage you from doing it. If you’re looking for new zero days, like, that’s a different class that I have that I sell. Zero day. No, I’m just kidding. It’s not here either.
You’re not going to get it. so just kind of throwing that out there. I do talk about one of my recent ones, recent, attacks that I do. I’m actually talking about it besides Tampa coming, up here in like, just a little while.
So, yeah, so that’s it, man. So if that’s it, if you’re interested in the training, antisyphon training.com, it’s on there. Check it out. But, yeah, so that’s all I have.
Thanks for joining. That’s it. Jason, bring me back.
Jason Blanchard
Holy cow. Mike, that was a lot of information.
Mike Felch
Sorry.
Jason Blanchard
Three minutes.
Mike Felch
Tried to pack it in.
Jason Blanchard
No, you did it. You did it. at some point, I think, like 24 minutes in, you’re like, hey, I have a bunch more to go.
Mike Felch
I was like, hmm, how are you going to pull it off?
Jason Blanchard
Because you’ve already given pretty much a whole webcast by the minute. 23. All right.
Mike Felch
Yeah. The main thing, too, I wanted to put as much in here for the slides because people are going to be taking it away and I want them to make sure that they have something tangible that they can go reference.
Jason Blanchard
Yeah. what I think we’ll do is ask, the others to come back on, like Steve and Ralph, if he’s here, if not the time. But Steve, if you want to come back on, if you have any questions from the audience, because, pen tester to pen tester.
You, can go ahead and grab some of those questions and ask Mike. in the meantime, I will ask Mike. How long did it take you to put your class together? Because I’m always fascinated.
Mike Felch
Okay. So I used a part of my class from another class because I have a python pen testing class, too. So some of the pen testing material I already had. So I got to repurpose that.
it’s taken like, weeks. Like, weeks. And part of this problem, weeks heads down. Part of the problem is, it’s a changing landscape.
So there’s certain things that pops up and they’re like, I gotta add that to the class. Like, that’s super important to have. The, other part, too is I work full time. And so then you have to do it, like, in after hours. And then I have a farm.
Like, I have, like, all kinds of life outside of work. So finding a couple hours here, a couple hours here, a couple days on the weekend here, of doing that over and over and over.
It, it takes time. So I say weeks, but I really mean, probably it’s months, but broken down into, like, if I put all the time together, probably, weeks to all.
Jason Blanchard
The people checking out Mike’s class right now. Thank you for doing that. And, if you get a chance, this is what it would be like. Mike would talk like, this would teach the class. There’s a discord channel. You communicate. You talk to each other.
You help each other out if you want to. All right, Steve, what questions you got?
Steve Borosh
so we did have quite a few questions. I think the last and most important one was, did Mike teach me everything I know?
Mike Felch
Yeah. So Steve and I, like, I’ve known Steve how long? I’ve known you for a long time. but Steve actually taught me. So, like, everybody knows when you go Google something, usually you come across certain people that have already did the technique, like years before.
So a yddeh lot of times, Steve was that guy. So, no, I didn’t get, I didn’t teach Steve. Steve, Steve indirectly, no.
Steve Borosh
You don’t have any, like, residual questions? We, we answered a lot of them during the training. I think we just got a lot of positive feedback that, was a good, good webinar.
And that, everybody kind of hit home with everybody. The sections were laid out really well and how, how you split it all up. So great job.
yeah. so, yeah, Deb said something that she asked me too. How long it takes. And you’re right, it takes a lot of hard work to build a class and especially when you’re doing stuff like in this type of environment where everything changes literally by the minute.
So like I would test something in my class for like on one day and then the next day test it again and it just completely fails because, Microsoft or whatever changes something in their stack and yeah, it’s tough.
Jason Blanchard
Sean wanted to know when the hacker hoodies are going to be back in stock. The Rekha hoodies will be back in June, just in time for summer supply chain. we ran through 500 of them really fast.
And so I was like, hmm. And then John was like, we should get more. So the record shirts are coming back too. They’ll be a part of the summer collection. So the green reco hoodies are coming back.
In case you’re, in case you’re wondering, I got questions. Mike, Steve, one of the things that you commented on is the fact that we all teach each other, like sharing your knowledge.
And black Hills is just a conglomeration of people who have been sharing knowledge for years and years and years. And sometimes when people join, they’re like, you all are the people who taught me.
And so, one of the reasons that we do this is because we want to make you better at what you do in your career. So that way, if you ever choose to join us, you’ll already be, where we need you to be to be able to jump right into your work.
But the other thing is like, if you’re a defender and we’ve been teaching you to be a better defender, we love that. Like, I know Steve and Mike, you probably don’t want an easy pen test. You want like the hardest pen test you can come across.
So that way.
Steve Borosh
Yeah, somebody mentioned that. What do you, I guess that is a good question, Mike, what do you do if you have a report that has no findings, how do you convey that to the, to the client and, in a manner that’s still helps them.
Mike Felch
Right. So usually you’re always going to find something. Right. but I would really say if you have, if you found minimal stuff, you want to at least convey that your attack pass or what you’ve tried to do, because to not have anything raises a red flag of, well, did you actually do anything?
What did you try? So, being able to answer that question is super important because, that just confirms that their maturity is where it needs to be. And maybe they should be procrastinating, pressing into a red team engagement or something a little bit more in depth.
so it’s not necessarily bad, but I would, I would praise them on what they did. Right. And then highlight those areas and then encourage them to take it a step further and look at areas where they haven’t tested yet.
Jason Blanchard
All right. and one of the things that we talk about, or one of the things I learned when I came to Black Hills is that a pen test report also includes the things that you couldn’t get past.
Like, it’s not just all the things that you did get past, it’s the things you couldn’t get past.
Mike Felch
Yeah, we do that. so one of the things that I like that we do also is the positive finding. So in the event where we find something like that, where we hit a dead end or something was blocked or remediated before we were able to exploit it, being able to showcase the positive aspects of it, because you have to remember also, sometimes it’s like the security manager who hired us, but is going to the executive report.
The executive. And they need to be able to spell out that that money that they spent last year that highlighted that, issue with their password policy actually resolved it. So you want to be able to paint that picture as well.
It’s super useful.
Steve Borosh
yep. And one last question. Any advice for graduating college students interested in pen testing? And I’ll chime in on that real quick, too. I think what helped me, I literally got hired.
I didn’t finish college until I was in my early thirties, and I literally got hired the day I did because I put co on GitHub, that somebody noticed.
Mike Felch
Right.
Steve Borosh
So I put myself out there and the things that I was learning and trying, I put it out there in the form of GitHub and a blog post. So document your journey, right. Make sure you have, that laid out, your learning path.
And people like to see that, we like to see that you’re passionate and that you’re building blocks of knowledge right as you go.
Mike Felch
Yeah. And on that note, real quick, I just want to kind of piggyback on that because that’s something Jason said also a second ago was the idea behind sharing. It reinforces it in your own mind.
So as you’re doing it over and over and you’re teaching it over and over, it just reinforces it. but it also encourages people to get out into the community to be able to share back.
and I think that’s really critical because there’s a lot of people that have a lot of wisdom that they don’t share out of fear that they’re going to be rejected because they, whatever, people don’t want to put it out there because they’re afraid that they’re nothing going to be accepted.
And that’s one thing I like about this community, is that we, everybody is accepted. I mean, everybody pulls in, and so it’s super cool to do that. I’d encourage everybody to share.
Jason Blanchard
Yep. I gave a presentation on how to give presentations the way human beings want to receive presentations, and that just kind of spells out an entire just form structure, for how to give a talk.
Mike, you gave a fantastic talk. Any final thoughts before we end today?
Mike Felch
Yeah, that’s it. I’m good.
Jason Blanchard
All right, if you need a red team thread, hunt pen test active, sock, any of that stuff. We do have a sock. We actually have a sock. It’s fantastic. And like, our junior pen testers get a chance to do threat emulation simulation.
Anyway, if you need that, where to find us. that’s it. Go ahead and kill fire, Ryan.
Mike Felch
Kill it with fire.
Jason Blanchard
See you all later.