Create Account

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

8 hours 29 minutes
Video Transcription
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 clown account.
It is considered a form of persistence 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. Okay, and so we can use command line commands on 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 than the capability to alert on this is not going to be anything that will get is well. So this is overall a normal process for day to day operations
in the eyes of, you know, a V and are an amorous and things of that nature
within our network. So let's talk about the serve helper malware and how it functions and so serve help arm our eyes classified as a back door, and it has several functions as follows. And so really these air steps that it takes a step number one.
Extracting and dropping an open ssh binary onto the system
than to extracting and dropping and configuring the RTP rapper library. Creating a new user. Okay, support account kind of messed it up, but support account with the password G h a r four F five now somewhat complex but not super complex
and then four, 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 Rdp and accessing that system.
Now, the creation of an account such a support account seems somewhat generic, and maybe you would not fall for that. But I have seen a lot of environments where printer test
guest has been used to support account
technical lead support desk. Ah, support administrator, system administrator, software administrator.
That's the name of the account. And you know, we're implementing these accounts not for malicious purpose, but from a threat. Actors perspective. That ambiguity is great because if I've got ah, 100 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 slipped one more accounting there, it kind of fits the mold, really not doing us 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 you know, 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 multi factor authentication for user and privileged accounts. Now some would argue that putting multi factor authentication on a standard user account is probably the equivalent of, uh,
career craziness there because
we're 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's gonna have a problem. Or, you know, we've always run into the power user or the senior manager of the executive that doesn't like the extra step.
But again that comes back to education. Why are we doing this? What are we protecting? Where's 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 there
if they're pushing this and helping to put it in place
and it's working its way up to that CEO level
nine times out of 10 we won't be successful. But if that approach is inverted Okay, 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 in the top supports it,
then it's got a better chance of being implemented. And so you know, that's how we always want to approach these mitigation techniques. We won't top down support.
Multi factor is getting easier and easier to implement. Easier and easier to use were seen 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 filing 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 on Lee needs to access a domain controller and a file server,
then it doesn't need to access every other maybe SQL 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 off their own configuration. Best practices and hardening guides
do not allow day to day operations with a domain administrator account.
Um, I know you know. You may be a business owner. You may be a C x o 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 haven't? And if you do have it, don't use it for day to day activities like checking your even. You put the business at risk and you could cause undue harm there.
Now let's talk about detection, so utilize low collection tools to alert on account creation within the network, especially focused on event I D 47 20 which has 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 Onley active accounts are
enabled that everything else is put in a proper oh you 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 AWS Azure Whatever the case may be,
if there are logging functions, especially for the administrative accounts, take advantage of getting every activity that comes out of that, whether good or bad for evil, are legit purpose. Being able to track those accounts and what they're doing and how they're acting could potentially help us to solve a complex puzzle one day
and then alert on. Members on there are assigned to administrator roles,
much like we were talking about cloud out men's.
If my domain admin account is long thin on the system at 8 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're using techniques from the execution and persistence vectors of the framework that being the minor attack framework.
So if you mean 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 vector. So it is true. We are essentially kidding. Two different phases
at the same time by using a script to create an account.
Now in summary today we talked about account creation. Okay, we described 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.
Up Next