Hello and welcome to
another application of the minor
attack framework discussion
today we're going to be talking
about create account
account creation, creation
of accounts with respect to
persistence.
So with that in mind, let's go ahead
and look at our objectives.
So today, again, we're going
to be describing what create account
is within the persistence area
of minor, how
the vector has been used.
What are some mitigation techniques
and what are some detection
techniques? So with that in mind,
let's jump right in.
So create account is
the creation of a local
system domain or Klown account
and is considered a form of
persistance for the threat actor.
Also, this allows the threat actor
to avoid malicious software,
detection tools and other
protectors because the account
is considered normal.
OK, and so we can
use command line commands in windows
such as net user to
create accounts.
So this is great, right?
If a threat actor is able
to create an account through
legitimate processes,
then there's no need to use
malicious software.
There's no need to raise the flag.
And if we don't have proper logging
and monitoring in place, then
the capability to alert on this
is not going to be anything
that will get as well.
So this is overall a normal
process for day to day operations
in the eyes of
AVY and our antivirus and
things of that nature within our
network.
So let's talk about the server
helper malware and how it functions.
And so serve help or malware
is classified as a back door
and it has several functions
as follows.
And so really these are steps that
it takes a step.
Number one, extracting
and dropping an open SFH binary
onto the system, then to
extracting and dropping and
configuring the already
wrapper library, creating
a new user support
account kind of messed that up, but
support account with the password
g h a r
four F five
now somewhat complex, but not super
complex. And then for adding
the user to the remote desktop and
administrators group.
So why would this be beneficial
as far as those two groups and
this account? Well,
you have to be in typically
in the remote desktop group in order
to take advantage of ODP and
accessing that system.
Now the creation of an account
such as support account seems
somewhat generic and maybe
you would not fall for that.
But I have seen a lot of
environments where Prenter test
guest has been used to support
account, technical lead
support, desk support
administrator, system administrator,
software administrator.
That's the name of the account.
And we're implementing
these accounts not for malicious
purpose, but from a threat actors
perspective. That ambiguity
is great because if I've
got one hundred accounts
that are active in the network
and let's just say they're stale,
they're not used regularly and we
don't have a mechanism to report on
whether or not they're legitimate.
If I slip one more account in there
that kind of fits the mold,
really not doing as any good.
And then by adding ourselves to the
remote desktop and administrators
group, it really gives us
the capability to get on that system
and to kind of have our way with it
and do what we need to then to
either get system level privilege
or to move laterally into
other systems as well.
So definitely
a nifty piece of malware
here and would be one
that if you see this support account
or some type of account creation,
it could be a variant of that
as well.
Now, let's talk about mitigation
techniques so
the use of multifactor
authentication for user and
privileged accounts.
Now, some would argue that
putting multifactor authentication
on standard user account
is probably the equivalent
of career
craziness there, because we
are definitely going to up the
amount of support that we would be
providing for that organization or
for those users, because it's going
to have issues at some point
or somebody is going to have a
problem or
we've always run into the
power user or the
senior manager or the executive that
doesn't like the extra step.
But again, that comes back to
education.
Why are we doing this?
When are we protecting?
Where is the support coming from?
Again, I think I've drawn this out
before, but if your support
is bottom up initiative,
meaning that the
front line folks,
the tier one folks, the technical
individuals that really aren't
decision makers, maybe they're
implementers and supporters
if they're pushing.
This in helping to put it in place
and it's working its way up to
that CEO level
nine times out of ten, we won't
be successful.
But if that approach is
inverted, OK.
Number two here and the CEO
is in support of this, it doesn't
matter if you're the senior director
of whatever and you're throwing
a fit about it. If the guy or
gal at the top supports it,
then it's got a better chance of
being implemented.
And so that's how we always
want to approach these mitigation
techniques. We want top down
support.
Multifactor is getting easier and
easier to implement, easier and
easier to use. We're seeing it with
bank accounts, health records, any
number of things.
It just makes sense that we start
talking about it and putting that in
place.
Utilized network segmentation to
provide systems and users access
to resources necessary to achieve
their core functions.
Meaning if I don't need access
to all the file and folder
structures in the organization,
my account should not be able to
access them and get to them.
Same thing goes for the system.
If the system only needs to access
a domain controller and a file
server, then it doesn't need
to access every other.
Maybe Ezekial Server database
whenever in the organization.
So limiting both user
permissions and access and system
access is going to
be key to what a threat
actor could do if they were
able to get something on a system.
Implement best practice security
configurations for servers such as
domain controllers.
Lot of documentation out there on
configuration, best practices and
hardening guides do not allow
day to day operations
with a domain administrator account.
I know you may be a business
owner, you may be a CEO
of some sort.
Just because you are doesn't mean
you need administrative access at
all times.
You could have a separate account.
I get it. You want to have that
level of control, but if you don't
need it legitimately,
then why have it?
And if you do have it, don't
use it for day to day activities
like checking your email.
You put the business at risk and you
could cause undue harm there.
Now let's talk about detection.
So utilize log collection tools to
alert on account creation within the
network, especially focused on event
ID forty seven twenty, which is
generated when a user account is
created.
The event should be validated
as legitimate action.
So if it is not legitimate
action, if it's not tied back to a
request or the proper sequence
of events to create the account, it
needs to be investigated and
understood and cleaning
up your active directory
infrastructure or whatever you use
for account creation and ensuring
that only active accounts
are enabled, that
everything else is put in a proper
view and it is separated and you
audit that regularly.
That will help in detection of rogue
accounts.
Long collection from cloud
administration accounts can be used
again to identify unusual activity.
We're seeing more and more Office
365 attacks, attempts
on eight of US Azure, whatever the
case may be, if there are
login functions, especially
for the administrative accounts,
take advantage of getting every
activity that comes out of that,
whether good or bad for
for evil or legit purpose.
Being able to track those
accounts in what they're doing and
how they're acting could potentially
help us to solve a complex puzzle
one day and then alert our members
that are assigned to administrative
roles, much like we were talking
about cloud admins.
If my domain admin account is logged
in on the system at eight a.m.
and it does activities
X, Y, Z, I should hopefully
be able to capture some of those
activities and ensure that I
am using that account for legit
purposes and not just checking
emails.
Now check on learning.
When a threat actor uses a script
to create accounts, they are using
techniques from the execution and
persistence vectors of the
framework, that being the minor
attack framework.
So if you need more time, please
pause the video.
So when we use a script,
a script was from the execution
area. Phase of minor and
account creation is from the
persistence factor.
So it is true.
We are essentially killing two
different phases at the
same time by using a script to
create an account.
Now, in summary, today we
talked about account creation,
OK, we describe that.
We looked at how the vector has been
used.
We describe mitigation techniques
and we talked about detection
techniques.
So with that in mind, I want to
thank you for your time today,
and I look forward to seeing you
again soon.