13 hours 9 minutes
Hello and welcome to another penetration testing execution Standard discussion. Today we're going to be touching on persistence in the post exploitation phase of the pee test standard.
Now, remember that pee test videos do cover techniques and tools. It could be used for system hacking. So any tools or techniques discussed or demonstrated should be researched by the user and understood by the easier. Please research laws and regulations in your given area regarding the use of such tools Thio to ensure that you do not violate any applicable laws.
Now the objectives up today's discussion are going to be discussing the installation of backdoors.
Discussing the installation and or modification of service is and discuss the creation of accounts and how that looks within the standard. So jumping right in the installation of back doors. And so this could be the use of something like a covert channel. And so for those of you that don't know backdoors essentially a way to get back into a network,
and so the use of covert channels is one way to do that. So this is when the data's being sent through alternative routes such a void T and S tunnels icmp tunnels.
Http tunnels that could be used for data extraction from inside the network. We could use root kits, which is a type of mount where that typically hides itself on a system it's usually deployed. With the assistance of a Trojan,
we could set up a listener and essentially set up a script that calls out upon system startup and connects to the tester system or our system.
Now, in any method, used complex credentials to avoid compromise. So, in any method, used complex credentials to avoid compromise. If you use weak credentials or no credentials and you expose the client system, that could put you on the hook for damages. And we definitely don't want that. Now,
when we look at the installation and our modification of service is, don't make changes to critical service is the last thing you want to do is get on a system, make a modification to a critical service, crash it,
it needs to be rebuilt. Something happened, something's damaged or corrupted,
and then you're in a world of hurt. Do not make undocumented changes or modifications to service is document every single thing that you do with respect to changes to systems do not make changes using methods not to find in the rules of engagement. Just because you think it'll work just because you think it may be appreciated by my client.
If it's not covered by the rules of engagement, you do it.
You're liable for anything that happens. At that point, it's on. You do not install software that could leave a system vulnerable to attack. So while you may be able to put something on a system that would allow you to then access the system later and maintain persistence,
you don't want to do harm to the client. So if you can't put protection mechanisms in place to keep that particular application secure,
or to hide it and keep other Attackers from finding it. If the network may be compromised and we don't know,
then you know don't do it if you can't do those things at a minimum.
Now, creation of accounts used accounts that are not obvious to detection mechanism, so you know, don't use administrator, don't use commonly or do not enable commonly known accounts like guests. The last thing you want to do is again having attacker find admin administrator or guest and you've got a week password on it and they
brute force it. Now
a real threat actor is in. Do not set up accounts with weak credentials. Do not modify service accounts or administrative account credentials.
Help you if you do. Modifying administrative account that is tied to 60 70 80 100 different systems and all of them stopped working and they start crashing. They start having issues.
Don't modify service accounts, administrative account credentials. You can cause a lot of trouble for an organization, and overall, we want to avoid doing damage to the organization and thereby avoid doing damage to ourselves.
Now let's do a quick check on learning
so true or false, back doors should be set up with simple credentials to ensure that they can be accessed later.
All right, so if you need some additional time to look through the question, please pause the video. So this is a false, false, false, false statement. Back doors should never be set up with simple credential sense.
You should set them up with complex credential sets and ensure that you keep them as secure as possible. If you set up a back door. Was with
basic credentials or no credentials and a threat actor gets into that system and wreaks. Having it is on you. At that point, that would be a bad day at the office. Now let's go ahead and summarize everything we talked about the day. So we touched on back doors at a high level in some ways that we could keep persistence and systems
we talked about. The installation and or modification of service is,
and we discuss creation of the count's really throughout this, just focusing on some things that we don't want to do and some things we would want to do as far as security, any accounts and making sure that we keep our clients safe. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.
Kali Linux Fundamentals
In this Kali Linux course you will learn about the industry standard tool for penetration ...
1 CEU/CPE Hours Available
Certificate of Completion Offered
How to Use SET (BSWR)
The Set or Social Engineers Toolkit is a commonly known open source framework available on ...
Certificate of Completion Offered