hello and welcome to another application of the minor attack framework discussion. Today. We're going to be looking at boot kit or boot kits.
So what are the objectives of today's discussion? Well, again, pretty straightforward. First, we're going to describe what boot kits are, how they can be used so mitigation techniques. And then, of course, we're going to finish out with detection techniques now
moving over to boot kits. A boot kit is malware okay that modifies the boot sector of a hard drive, impacting areas such as the master boot record and the volume boot record. Now this is a persistence mechanism that exists below the operating system,
and these types of tools are typically difficult to re mediate.
And so, just on example of some boot kits or things like rock boot and boot rash. And now
I've had the pleasure
of having to clean up boot kits in the past and things of that nature, and there are tools out there
that will assist in doing pretty boots. Skins
imp, reboot cleanup. Now it's not always a guarantee that it's going to completely get the root cause off the system, and so you may run into an instance where you have to completely clean out the system may be re flash. A few things reinstall that kind of beat order. Do things of that nature
just to ensure that you get the infection completely off of the system. Because again, this isn't something that's in the operating system. It is something that persists prior to the loading of the operating system.
So looking at some instances, touching on both nbr and VB are components. So changes to the master boot record. Ah, threat actor can make changes to the NBR,
which is the section of the disc, of course, that is first loaded after completion of hardware initiation by the BIOS.
This can result in the threat active, diverting normal startup execution to malicious code.
Now same but different with the V b R or the volume boot record. The NBR passes control of the boot process to the V B R. And again much like that, the adversary in this case diverts execution during startup to malicious code.
And so again, that's what makes this very difficult to take care of and very difficult to clean up because
you're working with an environment that is pre operating system Prib boot.
Now let's talk about some mitigation techniques for boot kits, so utilize some form of boot integrity you something like a TPM chip or trusted platform module on essentially a trusted boot process. And so, if you disabled TPM, maybe you want to run
dual boot. I know in some cases you may have to disable
um, or used legacy boot. Or if you're trying to boot from media or something of that nature that changes the integrity of the boot order or the way the system boots
could result in you having to disable this process. And so if you have to for troubleshooting or changes or things that you know are for business purpose and then good ensure that you revert those changes and implement everything back to the way it was prior to those those
either changes to the boot order or the way that the system boots
so that in the future, you know you don't get something that could take advantage of that and then ensure that least privilege is properly implemented within the environment. To make the job of installing a boot kit harder for the threat, actor again,
least privileges. Ah, commonality between all of the discussions that we have and in some form or fashion least privilege can be used
to reduce the capabilities of what the threat actor is able to achieve, are able to do, at least in that instance. So if they're using automated tools on, they're not directly engaging with the system and that tool is limited to user permissions,
then you know that could, ah, again reduced the impact to maybe just a few system folders. Maybe it doesn't get into the boot record. If you're dealing with something like Ransomware, something of that nature, it's boots. It's centric to permissions and things of that nature, and we've seen where you know, it may only get a few folders instead of the entire network. So
again, we'll talk about least privilege over and over again because of the importance that it plays in protecting systems and mitigating some risks there
now detection techniques. The recommendation here is to perform checks on the master boot record or the volume boot record. Eso would you would do is essentially have kind of like a golden image or the standard for the organization for those areas you reduce and maybe hashes or check some things of that nature.
And then you would compare those checks
to unknown good sample so you would take your system,
hash the particular areas or check the particular areas,
and then you would compare that information against
the known good sample. And so, in this case, changes to either should be reported and reviewed.
this is of course, you know something that you can do to combat these types of threats if they are going to be real for your organization, especially if other mitigating factors are not in place like least privilege or if you know you, let's just they have a sales team that is wide open as far as being able to use laptops in any way, shape or form that they see fit.
You could run into these types of issues, and so
this could be beneficial. But in my experience,
and I'm just speaking transparently here, I'm not run into an organization that was doing some form of regular integrity checks on boot records and things of that nature. Now that may be different from person to person,
but in my experience, I have not come across an organization that is a part of their security
posture and risk mitigation techniques was using this. But that doesn't mean that it's not something you should implement if you have a need.
Now, let's do a quick check on learning.
True or false, a boot kit is used for cleaning or taking care of boot issues on a system.
All right, well, if you need some additional time, please take a moment to pause the video. And if you want to go back and review the information, you're welcome to.
A boot kit is used for cleaning or taking care of food issues on a system, so first off, this is convincing. But a boot kid in this case is malicious, and so it is not used for cleaning or taking care of food issues on a system. Quite the contrary, it is the reason
that we would be cleaning or trying to diet nous
boot issues on the system, so it is definitely malicious. So this is a false statement.
So with that in mind, let's go ahead and jump over to the summary for today's discussion. So we described what boot kits are again. These are pieces of malware, either as a part of the malware package that is establishing persistence for the threat actor by manipulating
and taking advantage of
the boot record. Okay, either the master boot record the volume boot record. Right before that operating system leads up, it's executing or putting malicious code
into the system to be used by the Threat actor.
Now, when we looked at mitigation techniques, we look at things such as again least privilege and ensuring that those things are taking care of their on. That, of course, would not allow malware and things of that nature to run if it needed administrative privilege to make those modifications,
as well as looking at trusted Plant four modules or having systems with T PM's in place TPM chips
so that the boot record cannot be manipulated as long as those things are in place, not seen again, where you can disable those and you may have business reason for doing so. Just know that this does open you up to manipulation of the boot record.
And then we looked at some detection techniques again,
somewhat hard to implement in practice. If you don't have the scope or the personnel to do so. But taking a known good hash of a boot record and then comparing that to suspected systems that maybe have been tampered with or have issues would definitely be something.
Ah, that you conduce in these cases.
So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.