8 hours 39 minutes
hello and welcome to another application of the minor attack framework discussion today. We're going to be looking at bash history. So with that, let's go ahead and look at our objectives for this discussion.
So today we're going to be describing what bash history is within the context of credential gathering for a threat Actor to be able to Take Credentials From Bash History What are some mitigation techniques and what are some detection techniques? So let's go ahead and do a quick look at bash history.
So it's a pretty simple thing. Bash keeps track of the commands users type, using the command line with the history utility. And so when a user logs out,
it is flushed. The history is into bash underscore history file, And so the file resides at the same location, and it is bash history here. So it's a hidden file, and so typically this is limited to about 500 commands, and anything beyond that just rolls off
the history file.
Now, the reason why this is so important to kind of keep track of and understand. You know, you may not have thought that this existed for some reason, or you just may not be aware.
So when users inter credentials via the Bash Terminal or the terminal in general, it has the ability to get flushed or will get flushed into this history file. And so it's important
to remember that if you're not using a mechanism that encrypts a connection or that does anything to obscure the password, then that password is simply going to be dumped into the history file in plain text manner. And so, if a Threat actor were able to gain access to this file,
they would be able to use its content to maybe log onto additional systems or to further delve into the system that they have
Now there are a few mitigating techniques that we can take with respect to bash history. So the first thing that we can do is set the history filed two plus zero or oh, in this case, and what this does is
is prevents users from doing things to that file, and then we can unset the HIST file and add to a user stop Bashar. So this is added to the user stop bash, underscore R c file.
And so essentially this, these steps will keep a user from flushing to the bash history found, so not flushing it out in itself. But from Flushing to the history found some meaning that if I do things in the terminal and I look out, then that information will not get flushed into the history phone.
Now, as far as detection techniques, really, the only thing we could look at here is maybe when a user attempts to read their history fouling. So what we can do is we can alert on that capability or the user attempting to do so. And from that point, we came in
investigate that and see if there was legitimate activity tied to trying to read the history fall.
Now, with that said, let's do a quick check on learning.
True or false, the users bash. History remains in the terminal, even after the user's logs off the system.
So the user's bash history remains in the terminal, even after the user's logs off of the system.
So in this case, this is false. Anytime a user logs off of a system, the bash history is flushed or the bash information is flushed into the history found, so it does not remain in the terminal. It gets flushed to the history file.
All right, So in summary, we describe Bash history today and why that's important with respect to gather and credentials. We describe some mitigation techniques, and we've looked at detection techniques. So with that, I want to thank you for your time today, and I look forward to seeing you again soon.