In this demo, we will look at how OSSEC detects the use of the
sticky keys accessibility feature for authentication bypass. I
will start by showing you how to verify the syscheck feature is
properly configured and enabled.
Then, I will modify the set high contrast executable so that
it can be used to bypass the login screen.
When all of that is complete, we will look at the alerts
generated by OSSEC. Let's get started.
Once again, we're at a terminal connected to the OSSEC server.
There are two configuration files for OSSEC agents.
The one relevant to us is in the /var/ossec/etc/shared/
directory, and it overrides any local agent configuration
that exists on remote hosts.
The OSSEC server caches this file, so any changes we make
are not pushed to the agents immediately.
We can check if the current configuration file version is loaded
on the workstation by checking the md5 values.
Once we get the md5 hash of the agent config on the server,
we can use the agent control command to check for connected
agents and acquire the agent ID we need. After we have the
system and match an agent,
we can use the agent control command to view the md5 hash of
the currently loaded agent configuration.
Take notice that right now the two values are the same.
I'm going to clear the screen and then open the agent configuration file.
Different sections of the configuration file can be restricted by
operating system, agent name, or a custom profile.
This particular configuration block controls all deployed agents
running on the Microsoft Windows OS. One of our tasks is to verify
that the syscheck feature is enabled.
We can see that it is currently disabled, but before I enable
it, I'm going to jump over to the Windows workstation and show
you the local agent configuration.
Here we go.
If I scroll through the config file,
you will notice that the syscheck feature has been enabled.
Which setting do you think the agent will obey? The shared config or
this local config? The shared agent configuration takes precedence
over any settings in this file, so we need to make sure all our
changes are done on the OSSEC server.
Let's switch back to the terminal and enable the syscheck feature.
All right, that's complete.
The specific file we want to monitor is the set high contrast executable, and
it looks like it's already included in the default list.
Now, we need to repeat some things we did before. First, let's get
the md5 hash of the modified agent config file and compare it to the
configuration file loaded by the agent.
You can see that the two hashes are different, OSSEC will
eventually read the new configuration changes after a few
hours and then push the changes.
However, I'm going to force it to read the changes now by restarting OSSEC. Okay,
almost done.
I need to recheck the shared agent configuration hash on the OSSEC server, and
use it as a reference. In a production environment, you may have many agents. In
that case, we can use the agent_control command to identify the agent or agents
we want to check. Then, we can use the agent ID to query the Windows agent and
see if the two are a match.
If they match,
then we know that the remote agent has our new configuration changes.
Nice.
The two hashes are a match.
Keep in mind that I did wait several minutes for the
changes to push, and the video edit may make it appear to
update faster than it actually does.
The agent should start scanning the workstation in order to capture
information about all the files in the configuration.
I do think it is important to point out that syscheck does more
than capture the file hash. It also keeps a record of things like
who owns the file and permissions.
This is great news for defenders, since changing the file ownership or
permissions does not generally affect the hash that is generated.
I'll stop the video here and come back once the syscheck has completed.
Okay, I'm back.
If you're wondering where the agent stores the database
with the file integrity information, I'm happy to tell you
it's not on the workstation.
All agents send their results to the OSSEC server.
If I list the contents of /var/ossec/queue/syscheck/, you can
see some results from the other agents and our test system,
which is running the Jedi agent.
It's time to shift back to the Windows workstation and put on our
adversary hat. This is an administrative PowerShell session, and I'm
simply going to remove the sethc.exe file and then create a copy of
cmd​.exe, which I will masquerade as the sethc.exe.
Now that that part is over, I need to log out and test if
it works. If you recall, sticky keys is activated by
pressing the Shift key five times.
So, if I press Shift, 1, 2, 3, 4, 5,
awesome, it works. Once again, I will pause the video and
wait for syscheck to do another scan.
Okay, so the scan is complete.
Now let's take a look at the alert log and see what was generated.
I'm going to do a search in the file for the sethc
executable and see what we find. Bingo.
We can see that there was a change from our baseline, and
the OSSEC alert log details those changes.
Now, there is a configuration option to enable real‑time file
change reporting, but it's not on by default. However, you can turn
it on by using the realtime="yes" option.
That's it for this demo, see you in the next clip.