 go. Meaning Xavier talk a lot about cyber security. A whole lot. A whole lot. And we want to talk about some of the actionable the results of some of it. So as you know during today when we're not goofing off making YouTube videos and sharing how they got hack stories and all that fun stuff, he actually has his fingers on the keyboard well digging into and finding security vulnerabilities, assessing them, going through and auditing networks. And he's audited networks at a lot of big companies and we have to remain unnamed. But we have a treat for you. He has a report. And this is a report he made from one of those audits. Some names were changed protect the innocent. And honestly, this is what you want. You want an Xavier to break your applications, poke on your network, find out what you had at default passwords. Because there's one of those things where you go, Oh, I secured everything. Well, is it until you've audited until a third party, not the person that locked the door at it, someone came back and checked to make sure the lock was secure. That's a standard practice and well, maybe not so standard practice, but it should be standard practice. Yeah. And that's what he does. He goes through and assessment and we figured instead of talking about all the nuts and bolts, we'll talk a little bit about the tools he used to come up with assessment. But we want to show you the results and what an assessment looks like. And this can be very enlightening. And like I said, you really want someone like Xavier going through and doing it because trust me, this is the same thing. If someone gets in your network, they're going to do simulation. Yeah, they're simulating it on his side way better than them finding out and whoever them or they are, if they're in your network, they will do all these things. So he's this is why you kind of have to have a lot of real world kind of hacking experience, you kind of have to have that. No, I don't want to say foot in both worlds, but it's kind of running the edge. You have to understand how the hackers are doing it, what tools they're using. So we're using a lot of the same techniques, tools, to produce these reports. These are the same things that they're going to come in your network. They're going to start knocking things down and going through. But that's we're going to start and we're going to jump over here to the report and kind of walk you through what an assessment looks like in the end. And like I said, this is, this is all essentially we like so we changed names of application thing that so took a lot of editing to bring you this. But this is really what it looks like. This is not fake. So So this is an example of security penetration test for an HIE portal, HIE being health information exchange. So I would, you know, have my logo here enterprise offensive security, go check out enterprise offensive security.com if you want to actually download the sample report. And we would have your logo and who was prepared for the date in which it's prepared and who it's presented to. One thing you'll notice is it has a version number. And the reason why has a version number is because we actually will work with you over a period of time to come up with a multitude of versions of this report so that it's the most effective for you. Of course, we always leave every engagement off with let or the report off with letting the reader know and the amount of confidentiality that should be taken to account for this document. So you need to follow a certain need to know basis protocol when it comes to sharing these reports. And then it comes with a number of disclaimers. And this is important. When we come in here, we're going to find flaws. There's always something that's going to be found when this audit's done. And that's why you have to find something you can trust. You have to go, Hey, these guys are going to disclose this to the wrong people. And I don't just mean hackers. You're when you deal with some of the larger companies that we deal with. The concern is, are you going to share holders about this? Like they will be concerned or our venture capital. And this is why we have to understand all parties involved. And sometimes you get hired third party and sometimes even the investors may hire to do it. We have to figure out who the audience is, but these are real important is whoever hired us, that's who the confidentiality agreement is going to be with. And this is a important process in this. It's extremely important to get the confidentiality. We have to know. We have to know who we're working for and who gets this results and who can or cannot be told. And that's part of the pre engagement. Just letting you know that's a big piece of this. Yes, that's certainly. And then we'll get into the table of contents, right? And a part of the table of contents, you'll find the purpose, scope, summary of findings and a conclusion. And this is about as simple as it can get. So we lead off with the purpose. This, this is a fiction fictional ABC health company. ABC health company here. They've asked us enterprise office of security to go ahead and perform a detailed security examination. It's a custom implementation of a portal. We, we go ahead and let, let it be known at what time the actual testing took place. And then we get down into the scope where we talk about exactly which levels of access exist. What group membership should be associated with that access level. And then the actual application and the the URI for the application, and which we're doing a penetration test for. We'll put down important notes. If there's anything that we need to bring to the reader's attention, a lot of the time, you have to understand that as a tester, you're not the person that's actually going to go present the results most of the time, unless you're like me and you do a little bit of both, right, where you're in front of the client and you're behind the keyboard. The majority of the time your testers won't actually go see the client. So in the event that the tester wants to be able to get a complete thought through before or sort of a disclaimer that that's basically what we would do. And then we get directly into the summary of findings, right? We don't BS around. The idea is this is your only opportunity to be able to communicate effectively for your team exactly what it is that they need to be doing. So we we break out the summary of findings based on the risk rating, right? So this table down here is something that we will put together with our testing categories and the three levels of severity. Sometimes it could be up to five levels, but for simplicity sake, we like to use three. And you know, just a testing a bit of our categories for testing. One thing you'll notice is this is a web application pen test. So our network penetration test will be a little bit different. Our Wi-Fi penetration test will be a little bit different. These are things that we offer, but this is the the manner in which we communicate those deficiencies in your environment. So as you can see here, we have a couple of highs, a couple of mediums, and a low. Yeah, and bypassing client validation obviously is really big. And just to roll back a little bit, this is a engagement there. All the teams are involved and everybody knows this is not like a blind red team test where someone at the very highest level hired us covertly to go in. This is one of those. We get a lot of information. That's how we know levels of access. We don't have to try to fish it completely from the outside. So you're starting with the law, but that's that's type of test. That's the results of that. And this is the first one you want to do. Later after you've closed all these is when you want that blind red team test. Precisely. And I think it's super important to talk about compliance and the compliance regimes that be to keep compliance. You often will need to do one or one or two things of vulnerability assessment and a penetration test. What I'm displaying to you today is an actual penetration test. So we use manual techniques and procedures to actually go and execute out on these exploits and these vulnerabilities, whereas like a vulnerability scan would be more going to your network from the outside and or inside looking at all of the endpoints doing a fingerprint from the outside and actually seeing what services could be used and leverage for vulnerabilities as well as scanning your repositories and the libraries that you use for deficiencies and vulnerabilities and your packages that you're using. But the very first thing we found here was, you know, we went through website pilfering. And this is basically when we get into the meat of the report, we go through and we talk about the different type of attacks that we would do. And in this case, there was none found. Then we go over into, well, of course, we give a conclusion, which is basically letting us let letting the the this is our executive summary, so to speak. This is our too long, didn't read. What was the conclusion? Okay, they did full text searches and Carl's thoughts. Okay, cool, they didn't reveal anything. And this may be presented in two different levels. So we're going to talk to maybe an application development team, because they want to know the details. And then a management above them is going to go just look for the conclusions and summarize it. So this is going to be presented and pivoted in different ways, depending on the audience, that people at the top, they go, how bad is it? And the application people go, how do we fix it in detail? Precisely. And how do I actually replicate this inside of my own environment, so I can learn from it? Right. A lot of what we find is that developers will actually read these reports and start to learn how to think like a hacker. And that's that's literally ideal. That's what we want. So we went down and we did a little bit of file guessing attacks. We went through and did some modifying input choices parameter tapping, tampering, which is very, very fun to do and is prolific. The findings that you'll find often inside of web applications where you're tricking the application into thinking you're someone that you're not or by you know, changing a parameter to be able to move laterally throughout the application, elevate privileges, etc. And the tool we use for that is Burpsuite. Yeah. Burpsuite will really do some interesting things. It's so much in there. You can start just pushing so much and you can't what you're doing is you're getting in between and doing things that are completely unexpected to the application, sending it weird data, sending it things. And Burpsuite, there's plenty of videos you can find on it. We maybe we'll do a video on it one day and kind of show it in action as well. But but whatever we're just going to do is going to sit between the website and my browser and it kind of fits that little middle between more like send something random that was not expected to send. And that's what we're doing here really pushing the limit to see if the application will do that. And it's funny because you get pushed back from some devs. Well, I would never expect that input. Well, you didn't sanitize for it. And trust me, this someone who's wanted to poke at and find holes, they're doing this they're going to use this Burpsuite is pretty standard hacker tool. It's part of the Swiss Army kit for web application testing. Precisely. And then after we actually use that tool and we identify the issue, we go ahead and we'll use CVSS to map out the risk versus the complexity and explain that to our customer and then give them a summary of exactly what we did to do this test and how to actually retest for this particular use case, as well as any screenshots that will need to actually pass along. Yeah, because the goal of this is not to say how we broke your app at all. That's there's a misconception sometimes there's sometimes people will chip on a shoulder like that. Our goal is to go. This is how we do it. This is how we repeat the process. This is the string we sent to get this result. Or sometimes a series of strings you send if you do this it fills up this buffer and then we send this command and then it dumps. So we go through the process to make sure it's repeatable. We do have to do that on beforehand and then the documentation is given to the app team because the goal is here's how you guys here's this parameters you use. Fix your code on the back end until that doesn't happen no more. It's it's the goal is all remediation here. Exactly. And so we also give our recommended resolution, which is always one of our favorite parts for us to be able to get in and put the put the blue team had on and think about how would we defend against this. What's the proper way that this functionality should be executed out or implemented in. And then of course we give a conclusion. So a constant is always you know if we do find something we try and do a resolution and we always try and have a conclusion. So we went ahead and did a test for bypassing client side validation and we're able to find another issue for data birth validation for a patient patient patient search patient search. I'm a math guy not English guy. I love to read though. So yeah, I would love to read your code. Please let me know if you would like me to do a code review for you. Yeah. So yeah, we go ahead and now you'll start to see the pattern of our risk versus complexity. And you know your risk appetite in certain environments, maybe at different levels. And that's the reason why we break this down to a high medium low risk type of ways so that you're able to say, hey, this is a low. I'm not really looking at this right now as far as the risk or you're looking at complexity and going, hey, this is, you know, in this case, it's a risk high complexity low, which means you don't even need to, you know, be authenticated. You just need to be the man in the middle, right, which is, you know, often outside of the control of the operator of the web app. And that's something we're looking for is that in between because you started with an encrypted session, but is there a way to drop it back? That's one of the tests. It's one of those simply overlooked things we can figure web servers leaving for compatibility reasons, old ciphers in there and doing downgrade attacks as one of the tests. And sometimes you find that we, oh yeah, we authenticated what we realized we can get your users stuff because we can downgrade it after it's authenticated and get to the bypass. Precisely. Um, so yeah, this complimenting screenshots, um, examples excuse me, I moved a little bit too fast complimenting screenshots and examples, um, moving down to more screenshots and examples, more details and our recommended resolution. And again, you'll start to see the pattern. These are the ways that we do it, right? So we'll go through. We have a long list of checklists. When you work with us, um, we actually will have a base template in which we do these, uh, these penetration tests with. And then we work with you to find exactly what are your most important parts of your business. And then we tailor our attack and our and our tools and techniques around trying to be able to get to those, uh, those assets. Yeah, important assets that you hopefully are protected on that. Right. Um, also, like, uh, you know, there's often a time in which architecture has to find certain things for a reason, um, such as character limits. And this was something that we found here, even though it's a low risk level. Um, but there's a low complexity. So this allows for a potential attacker to come through and do a denial of service and consume all of your resources. Um, so we go ahead and do a summary details and recommend your resolution. Yeah, this is another side of it. Um, it says even though they may not get in denial of service, especially if you're some type of public facing, uh, portal that you know, you're either retail or B2B, people being able to shut down your portal by just filling up one form with some data and hitting send a couple times. That that's still bad. Yeah, it's bad. It's another aspect. I mean, competitors could be doing that now. Oh, they found this weakness. Um, you may be doing running some advertisement. They could be super both Sunday and now they've taken down your entire, you know, onboarding and, you know, you could have potential customers but you're going under the knowledge service and it's not biometric and it's application flow and you don't have a way to mitigate that immediately. And there's definitely some competitiveness in the market. Uh, precisely, spend a few minutes reading. I know they've improved but like uber, you know, they did certainly exploit anything they could find and lift to slow their system down. So yeah, that happens. It's a when it's competitive markets, but you want to do that testing before your Super Bowl Sunday. Exactly. And so one of the things that I love most about testing is sometimes you're running the things that just were done right. Um, and that's like my favorite. Yeah, especially on a retest. If I come through and I hit a few things and I retest you and you don't have any of that, I'm always excited. But even when I go the first time at any time, I can say, Hey, there was no way for us to be able to leverage hidden hidden fields. Right. That's always fun. Um, cookie abuse. This is really, really big. Yeah. Uh, you know, just being on a network network with someone and being able to be the man in the middle and grab those cookies that are flying over the wire. If you are invalidating, if you're using them for sessions, um, this basically can allow for an attacker to take over the identity of or the session of another user that has a legitimate credential and that credential could be a DevOps credential or a senior engineer credential, something that's overpowered that allows them to be able to, you know, give themselves unlimited of further unlimited powers. So, uh, cookie abuse is really, really big. One of the things I like to tell people to do is set the secure flags on their cookies. Um, and that's basically what you'll, you'll see right here. Yeah. It's, it's those little things, but a lot of times developers cause they're focusing on front end experience, uh, user flow and they may go, I'm just going to use this framework. Well, if they leave the default or they're not asking me with that framework, the default may not have secure flag and cookies. And that's all these little mistakes you're made. And that's why you need a third party because they're going, well, the default should have secure. Right. That's why you need these tests to make sure that's right. And another thing is, is even, uh, even, you know, sometimes if you handle cookies properly, there can still be session hijacking due to not enough entropy in the way that you actually issue those cookies so they could be guessed. Um, so this is one of those tests that we run using Burp and, uh, you know, we're often able to find, uh, ways for us to just generate the cookie that will allow us to not enough digits in you. And the, how that happens is you go, well, you know, we're B to B, we're a healthcare, uh, we'll never have more than, like, uh, 200 clients on this. Well, cool. So you think you, a thousand would be enough entropy. You know what I mean? Something goes small like that because they're not thinking like scalability, but that, of course, opens up to this type of attack. They're like, oh yeah, adding a couple of zeros, even though we're not going to be that. And luckily, this client actually stood up against this, this attack. So that's, that's always good. They passed it. They passed this one. So, even though sometimes you may see a lot of charts, big pictures, that could just be our way of proving to you and showing to you the effectiveness of our testing and giving you that validation of your hardening, even if you did pass. And we're happy when the conclusion is, you passed. Great job. Pat on the back. That's, that's great too. It's good to know. So, URL jumping, they also passed. Cross-site scripting, they also passed. And of course, directory browsing, this is one of the easier ones that people get, right? The proper HT access, proper file permission. They do now. It's, it's not as preliminary as it used to be. It was so much fun for so many years. I misspent youth. There you go. Reading files on directories that were not meant to be read. Like configuration files, right? A lot of web applications will have a config.php, a config.aspxn, will be, you know, or a war or a jar that sits on the route that's actually run by Toncat. And sometimes you're able to get your hands on those credentials or those packages and start to learn how to move further in the environment or get access to things that you otherwise wouldn't have had access. So directory browsing is always fun. Yeah. And sometimes people think because they hid the directory that there's like, oh, we hid it. But one of the examples is going to be WordPress. There's a couple of different WordPress backup plugins that create a common file naming structure. Now, even if you block access to it, if you know the URL, I was actually kind of surprised at some of these. I think that one is gone. It was one of the backup ones. But because they had a common naming structure, you could just guess if a company was using it and grab their WordPress backup and then have their passwords. There you go. So there's definitely things like that. And sometimes developers are busy or under the gun. They're pressured. And they go, I'm just going to back it up over here. It didn't work unless I put 777 on it. Right. Yeah. So those are those things we want to be tested for and some of the file guessing do it. So it's all a valid test even though it's not. It doesn't happen as often, well, at least with the application. Well, I mean, now it's all about open S3 buckets. Oh, yeah. It's basically they've moved the ball over to S3. You know, man, those are being discovered all the time. That's a whole different game. That's a different topic. That's another. That's cloud security from enterprise offensive security. Yeah. We'll do another report on that one. So a SQL injection is another fun one. This could lead to people being on a misuse of authentication. So being able to elevate privileges from unauthenticated to authenticated as well as dumping of files to actually dumping of database to actually get records for of your patients of your customers for competitive advantages for just defamation for anything. So SQL injection is always a big one that we test for. We test for multiple ways using the multitude of tools including SQL map and our favorite burp. This this client tested clean for it, which is which is always good. But they didn't test clean for some logical design issues. And this is what we were talking more about earlier with that code review. Sometimes if a client will give us access to their code before even testing it, we'll be able to see ways in which our entry and exit will be available. Right. And so one way one way that their logical design was incorrect was they didn't allow for a password. They didn't force passwords to be set when setting an email. Yeah, right. So you're basically allowing someone to be able to potentially take over a legitimate user's account because they're not validating the password that's associated with that account when they actually change the account. Right. So I'm already logged in and then I go to go change my account to your password. I mean to your email using no password at all. And now all of a sudden I become your user. You have to test for those types. It's part of the breaking it in unexpected ways. That's what we're going to do is, you know, the developers really focus on, all right, this is the way the user flows through. They're thinking about that. We're thinking of a way we can reverse it and, you know, swap an email and pull something over. And it's one of those little things we are trying to break that flow that the people created because this is that thinking like a hacker. Exactly. And so we give our recommended resolution and we give our conclusion, right. And then we talk about system and software vulnerabilities. This goes back to like that vulnerability scan topic. That kind of is inherently done during the penetration test because it's a part of our information and data that we gather for further exploitation. So anything that we run across any systems or softwares that are vulnerable, old, knee-patching, we always bring those up. In this case, it was a Yahoo library, YUI, which, yeah. That goes to show how old this test is. Yeah. It's been a while. So we also talk about secure attributes not being set on cookies. That's what I talked about earlier, passing the secure flag. And then we will wrap it up with the conclusion where we'll remind you exactly of the risk rating and the page reference where you can find the six issues that we have found. And we'll do a whole entire conclusion and let you know exactly what we found, what you guys did good, what you guys did bad, what we expect to see moving forward. And usually, we'll sit down with a CISO or development team sometimes. And we'll just have a couple of coffees, bring some snacks, work through everything, find where this stuff is happening in the co-base, or think about when this mistake was made, plan it out, and then set time for a retest. Once we retest, hopefully this stuff isn't present again and they get the bill of clean health. And in the event that we're there for a compliance reason, such as FedRAMP or HIPAA or PCI-DSS compliance, we'll see you in a year. And hopefully you're still clean. Yeah, and this is why the versions are important. You know, the first thing we're going to do is hit the same things again. Did you fix them? You can say you fixed them, but we're going to run and test them. Even though we gave you all the tools to do it yourself, we need to know, did you do it? Were they implemented? And this is usually, you're not the one hiring us if you're the developer. It's the C-levels that are hiring, but this is one of those things. And there's auditors, and compliance, or investors again that want to know, all right, this is the short summary of version one. How does version 1.1 look? Version 1.2, version 2.0, what app changes are made, and the assessment starts over. But this is an important aspect of it. And like I said, this is for an application testing that was for a medical client. A little bit older report, but you know, we're tight. Very, very relevant. Yeah, we're tight to the vest of, trust me, we do not, confidentiality is of the utmost. That's one of those things. Very important. When I do these, even when I do some of the implementation or IT assessments that we do, I can't talk about the clients. They're, it's just, I would not have those, some of those gigs if I talked. Right. And I mean, I'm doing pen test literally every single day. And it was even hard to find a report that I could even anonymize. So, Because they just become a blur. We take your privacy extremely seriously. Me and Tom have been working on this report for like four days. So, Just redact, redact, redact it all, right? Just to make sure that we didn't get ourselves any trouble. So this report, the sample report is actually up for download right now. If you go to enterprise, offensivesecurity.com We'll leave a link down below where you can get this and check out the services and things like that that Xavier offers. But this is, this is where all this knowledge we have. This is how we understand when we do these, how they got hacked videos and we like talking about it. We want to raise awareness for it. You know, that's a big piece of this is you can do a lot of yourself or use in birth suite. You can do some of this testing. And matter of fact, do that before you ever call for an audit. That's how you'll get past cleaning. You know, you'll scream through this article. Now this was a lot easier because you tested with Burp Seat. You tested with that. And there's some great YouTube channels out there. And I can leave a couple of links out there that show you how to use some of these tools. And there's been some questions about YouTube, whether or not they want us doing those videos about those tools. I mean, but I'll say there's a good in-map scan. Enumerate the network, figure out what's on it. Just knowing what's on the network is a really, really good start. A vulnerability assessment, something like a scan, like a Nessa scan, a Kuala scan. These things are open vast, they're extremely valuable before you ever even pick up the phone to give us a call. And we actually have a white paper that we're working on right now that actually goes into the differences between a vulnerability assessment and a penetration test because they are different. So you do have opportunities to do vulnerability assessments in a much lightweight and easier fashion than going through a full penetration test. And again, that penetration test is on the way to a full red team engagement. And the best part, if you're a new company starting out, start there. New company starting out, you don't have money to pay for not it. But if you start thinking about these things ahead of time and start testing this, and you have Kali Linux, you've got Parrot OS, I'm partial to the Parrot one because I think it comes a little bit more completely set up. He likes it as well. Open vast is in there. You can, this is no charge free. You can go download that software, start poking away at it. And then when you start building your app, you've started from the ground up. A lot of times when we're doing assessments or companies that didn't start from the ground up, they started running with an idea, maybe some investment money, and then they call us. Whichever way you're starting, that's the important part is start thinking more secure. These applications that are going to be public facing, you have to get that mentality out there. And that's a lot of what we're preaching here is. And this is trust, and this is your customers, and this is your digital relationship with your customers. And it's super important to keep your reputation, your digital reputation secure. You don't want to be in an episode of how they got hacked. Maybe as a guest, but certainly not as a victim. Not as a victim, not as a victim. So like I said, we'll leave a link to the security and all the stuff that we do and where to get a hold of Xavier and how you go through the process. And of course, the assessment will be on there. I'll leave it in the description below. And thanks. Thank you. All right. Peace. Thanks for watching. If you liked this video, give it a thumbs up. If you want to subscribe to this channel to see more content, hit that subscribe button and the bell icon and maybe YouTube will send you a notice when we post. If you want to hire us for a project that you've seen or discussed in this video, head over to LawrenceSystems.com where we offer both business IT services and consulting services and are excited to help you with whatever project you want to throw at us. Also, if you want to carry on the discussion further, head over to forums.lauranceystems.com where we can keep the conversation going. And if you want to help the channel out in other ways, we offer affiliate links below which offer discounts for you and a small cut for us that does help fund this channel. And once again, thanks again for watching this video and see you next time.