Define Acceptable Sociable Engineering Pretexts Part 1
13 hours 9 minutes
Hello and welcome to another penetration. Testing execution Standard discussion. Today we're going to be looking at define acceptable social engineering pretexts within the pre engagement interaction section of the Pee test standard. So let's go ahead and start with a quick disclaimer.
The Pee test videos do cover tools that could be used for system hacking. Any tools discussed or used during demonstrations should be researched and understood by the user. Please research your laws and regulations regarding the use of such tools.
Remember, while we're having fun and learning, we won't. We don't want to get into any trouble with the law.
So let's go ahead and look at our objectives for today's discussion.
So at a high level, we're going to look at what social engineering is we're going to discuss at a high level some types of social injury in engineering attacks and a person can undertake or do against an organization. We're going to discuss permission to test language that would be reasonable and acceptable prior to doing social engineering.
And then we're going to discuss at a high level the social engineering tool kit, which is something that you could use in your social engineering activities. So let's go ahead and look at what is social engineering.
by definition, it is the psychological manipulation of people
and getting them to perform actions or divulge confidential information. And so some reasons that we would want to look at social engineering is an applicable testing component of a penetration test is that the average success rate sits around 70 plus percent
now, for those of you that do some type of
annual security awareness training their support of your organization, that's probably reduced the overall percentage. But every week we're hearing about ransomware attacks that are successful. We're hearing about CEO fraud and things of that nature that is successful. So
these attacks continue to happen because of the nature of their success. The other part of this is, is that the human element is the easiest to bypass, and it's much, much easier to bypass than technical controls in any respect. So if I can fully user
into doing something and running something into giving a particular payload administrative privilege, if I can trick them into letting me have access to their system, that is much much easier than doing research on an exploit or some type of zero day attack
and potentially spending a lot more time
in getting into those systems and then people. So individuals in most cases tend to trust another person. And so the thing about social engineering that we have to remember unless you're tailing with a party that has been, um, nailed in the pastor's had problems in the past or has trust issues
Generally people want to trust
other people inherently. We want to try to help. We want to try to do what we can do to, you know, make someone's life easier, especially if we've got a social engineering attempt that involves, you know, the manipulation of emotions or something of that nature. And so,
you know, because of that tendency, it also makes social engineering attacks very, very lucrative for these organizations.
looking at types of social engineering attacks, we're going to start with fishing and so fishing is broken down into some different categories. But essentially these types of attacks can be conducted through several methods. Generally, the attacker is rushing the party to action, posing as a party in a position of authority
and these attacks coming. A few flavors.
Spearfishing is very targeted s so it's not like mass mailers or things of that nature where the attacker throws out hundreds of emails at a time. It's very specific. CEO fraud is typically when the CEO Sze email account is compromised, and then the attacker, either
with the CEO is a count or posing as the CEO through spooking will attempt to
get another party to transfer funds. Do things of that nature
fishing is fishing over the phone and then swishing is text message fishing as well. And in both of these cases, the attacker is attempting to get a party to do some type of action that would divulge information or provide access to systems that they otherwise would not. And so as a tester,
it's important to understand these different types of attacks
and to be able to see what would be the best fit for the client or customer organization. If they've been innocent area where they've experienced close calls in the past
war, they've had phishing emails have come through and they've fallen victim to those emails. It may be prudent to go back and re test the organization, you know, to see if controls that they've put in place of help to reduce risk,
as well as to see if you know the organization could fall prey to efficient attack again. And it's also good for organizations that don't have any experience in receiving these types of emails or attacks, because now
you could get a realistic sense for the likelihood that the organization would fall victim to a phishing attack. And so, with these types of attacks, will get into some some things that we would want to do. But typically we would want to get some type of pre approved list for testing as well as, um,
you know, individuals that may be out of bounds.
And this is especially
peculiar when you're dealing with fishing or swishing. You want to make sure that the equipment that you're testing is owned by the organization and not the employees, because we run into some issues. Um, when we start to pose as a threat actor and we send potentially malicious
content and it's quot fingers because we're not actually developing content for saved to destroy
ah device. But if we were to skim information or tried to collect Screenshots as evidence of a successful attack for testing purposes.
We could run the risk of taking information off of an employee device that we would not have authorization to to obtain. So always keep that in mind when you're doing any type of fishing.
is a little bit different than fishing, So fishing is typically, um, again high stress, high level of authority coming in. Do something now, Now, now do it, Do it, Do it. Don't take any time to think about it. Pretexting, however, focuses on, strangely enough, a good pretext or story
in the case to still a person's information.
So typically you as thieves, social engineering, individual or as theater. Acker will go through and research the organization. Research the individual.
You would focus primarily on figures as faras, posing as a figure that has authority or a right to know. And so in larger organizations where maybe not everybody is known, you could pose as a co worker carefully. You could pose as a police officer
as a bank, like a teller or ah, customer service rep for a bank
tax authorities, clergy members. It just depends on the organization and the story that you're trying to weave. This would definitely take a little more time, effort and energy than a phishing attack where you could go
and maybe do a little research on the organization, get a key list of personnel, put together some some kind of bait and switch type content or some high value content, and send that out and see who you nail. This requires some eloquence. It requires three ability to think on one's feet.
You really can't go into pretexting
on shaky ground. Are without really knowing the individuals that you're targeting, because likelihood there's that they'll see through it and they'll catch you. So that's why these impersonations are typically done as either trusted co workers or is members with authority who would kind of have a reason for asking.
You could also, if you knew the um,
let's just say that the client has an I T company as well. That they do business with
you could potentially poses a member of that organization trying to get access to the systems again. We're mimicking a savvy,
targeted attack by a threat actor, and so pretexting is the scenarios in which they weave those stories and they attempt to gain access through gaining trust over time.
Now, Beijing is also something that I kind of like to do in tandem with fishing. I don't like to do it just on its own, but it typically involves curiosity.
Oh, agreed of the victim, the victim being the individuals that you're testing or, in the case of real world scenarios, the people who fall for the attack. The attacker will typically leave malware on drives like USB drives. You know you can do it with CD, depending on what your target is and what the media is that they normally use.
And then you leave those devices to be found. And so often times these may contain documents that look like they talk about money.
Or maybe they talk about reviews and things of that nature. So maybe it's you know, that time of year when everybody is going through the process of having their annual reviews, there's going to be salary discussions.
No better town to leave. A USB device may be in a Commons area or something of that nature that may contain what looks like a char data about reviews or HR data about you know, the pay raises or, um, you know, information, maybe about particular persons or layoffs that they plan to do that year.
And so you make it
very, very, for lack of better words. Juicy. The information is something that if a person
is worried about their role, if they're trying to understand who's getting what that year, if they're just overall interested, too, to see what's happening,
this could be a very good way to get them to interact with content. Now
a lot of systems will block auto run when devices were plugged in and things of that nature. And so we definitely have to get craft year in these types of attacks where we're creating fake documents were maybe embedding Mac Rose or some other type of
method for doing a callback thio a system or something of that nature. So these
definitely, you know, auto runs probably won't won't work in the majority of environments. Now,
you may get lucky from time to time, but these were definitely great. If you've got a kn organization that's got a lot of foot traffic again scoping, you have to be careful that you don't have a multi tenant it building because then someone could pick up the drive that's not in scope of test. And so that may cause issues. It's always keep those things in mind when you're discussing that
now, quid pro quo in itself means something for something. So it's essentially you scratch my back, I'll scratch yours s Oh, this could be a scenario where you call a person within a facility posing as a member of technical support. So we talked about that earlier,
and you say, Hey,
this is Bill. This is Raam. This is whomever. And, um, you know, I'm calling back about your technical support issue. Well, chances are you may not get someone on the first hook that may say, Oh, no, sorry, I don't have any issues. I don't have any problems. I didn't put in a ticket. Whatever the case may be.
But chances are, as you work through the roll index of individuals that you've been given permission to work with, you may run into a person who in fact, does need assistance. They did submit a ticket, ah, support request, an email, whatever the case may be,
and if they're not really familiar or they're not really interested in following protocol. So, you know, asking you know who you are. What organization are you with validating that you are a trusted party? A lot of times, organizations that have good policies in place will require that maybe you call back
or that reference a certain ticket number or whatever the case may be prior to giving access to a system.
But the way that this could be posed is that the attacker would essentially calm, indicate maybe that they're having issues using the standard beans for accessing the system. They need a little extra assistance in getting on the system, and so then access would be given to the attacker
on Dhe. Then they can launch malware on the network or do something of that nature. And a lot of times, you know, if
someone is working with a trusted party, they think it's a technical resource. Whatever the case may be, I could open up what looks like the fix for something or what is a piece of software,
and it made request credentials. And then I could ask the, you know, potential target. Hey, please. Usual credentials here so that we can run this and get this issue addressed. And so a lot of potential here again,
this somewhat plays on trust. But depending on the scenario, you're really playing on a person's need for assistance or trying to get some help, or
depending on on the length of the engagement. This could be a lot more thought out and deeper scenario that you could play into with the party.
All right, everybody. So today we discussed what social engineering is. We discussed types of social engineering attack such as fishing, pretexting, baiting and quid pro quo. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.