Valid Accounts Part 1

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 39 minutes
Video Transcription
hello and welcome to another application of the minor attack framework discussion today. We're looking at valid accounts within the initial access phase of the framework. So let's go ahead and jump right into our objectives for today's discussion.
So today we're going to be looking at a few different areas we're going to define and look at what valid accounts are as defined within minor. We're going to look at some types of accounts that they define as well. We've got some statistics that we're going to look over together and kind of discuss. This will help us to
better frame the importance of the valid accounts vector
and some of the industry statistics that go along with that. And then, of course, we're going to hit our wonderful mitigation activities and detection activities that we conduce within each of these areas. So with that in mind, let's go ahead and jump right into our definition area.
So what are Slash is a valid account. What are valid accounts? Well valid accounts under minor our accounts used by users or services in an organization threat actor still account information in a variety of ways and then use those credentials toe later. Gain access
or initial access in this case is we're discussing
to the organization. Now.
These are just some generic categories as provided. As we know there are different types of accounts, depending on which you set up in like a domain that could be a domain administrator. Or there could be service accounts that run on the domain. We've got local accounts, as you know, they're just specific to an individual system,
and then there are built in accounts like guest accounts, administrative accounts with network equipment. This could be like the ad man accounts that we see on Google when we do searches for certain brains of hardware
and things of that nature. So what's important here is that the level of access that each of these account types gives may not be directly reflected by the type. So a local account, for example, can be an administrative account. It could be a limited access account.
It could be a servicing help,
and then default Accounts are typically, as we said, those that are built in. So these are accounts that come with hardware out of the box, and typically you have to go in and enable or create new accounts. If you want new accounts on the system,
sometimes these accounts can be disabled. Sometimes they can't, and you just have to implement complex passwords and things of that nature. And then domain accounts come in different flavors as well. There could be accounts that air domain administrators, which
would have again Administrative X, is much like a local administrative account or just typical
India's or access. Now the difference between again local accounts and domain accounts is that domain accounts are managed by a central server on provide access across all systems in a domain. So if you've got a system in Europe
that connects back to, ah, central active directory infrastructure and a system in the US that connects to that same infrastructure, in theory, a user that travels to Europe could access workstation in that domain much like they would in the U. S. So I have to keep that in mind.
Now let's go ahead and jump into some statistics.
So with
Voronin's the first statistic here they did a survey and found that 65% of companies have over 1000 still user accounts now typically still, user accounts are accounts that haven't been long been to for over 30 days. And these air like active user accounts.
And the reason that this statistic is so troubling
is because if we don't have some form of central monitoring that's in place, there are 1000 potential a niche initial access attempts it could be made here. These could be
accounts that were created for testing purposes that were never disabled. These could be accounts that are from users that have come and gone from an organization over the years on, and they've never, of course, been disabled either.
And that provides a risk to the organization, even if the password has changed on these accounts. If the administrator or person managing the system
uses a week password or doesn't set the passwords to be unique to each of those accounts
than the ability of ah threat actor or even the user to guess the password or a cracked, the password becomes that much greater. And that could be risky, especially if these accounts have remote access capabilities to the systems.
in Black Hat 2017 32% of black hat hackers admit that privilege accounts are the number one way to gain access to critical data.
Now this is, um,
I would say brings true because
it's easier to find an account that uses a week password that it is to develop a zero day attack. It's easier to try admin, admin or admin, password or admin blank
to get into, um,
a piece of network equipment or a firewall or potentially a test account that was set up like test test or printer printer. Seen a number of those over the years, and you know,
it's the path of least resistance. In this case, if I don't have to do heavy amount of vulnerability research if I don't have to do buffer overflow attacks. If I don't have to do any type of manipulation and I log into a system as a legitimate user,
that's much easier
and better for me than trying to make a bunch of noise and get into a system.
All right, and then our last statistic hears from the Verizon Data Breach report, which, if you haven't looked through this report before, Horizon publishes it every year, and I take the time to review some of the statistics and kind of what's popular
here over here, as far as threat actors go on what we're seeing in the industry. So in the previous reporter in the actually the recent report, 80% of data breaches caused by compromised and we credentials. So 80%
of data breaches are caused
by compromised and weak credentials, meaning that credentials were stolen. Credentials were re used elsewhere.
They're not subject to complexity requirements and things of that nature.
And so
that's a pretty high number.
29% involved the use of stolen credentials again. Compromise meeting stolen. Um, in this case,
password dump was provided on the dark Web or something of that nature. Or there was just a listing of passwords that came from another site.
And then, ah, threat actor would try to use those credentials across other areas, like banking sites and things of that nature. So
again, this comes back to good password hygiene, good password complexity, implementing Dole factor things of that nature, which we're going to look at in our mitigation activities coming up.
Oh, right, everybody. Well, we're going to go ahead and take a quick intermission. The next part of our discussion will be coming up. Please stay tuned
Up Next