Hello again.
And in this section, we're going to cover investigating user
command history. Before we get into the demo, it's worth briefly
covering the order of volatility and some recommendations, but
what is the order of volatility?
Well,
it's a list of areas where data is stored and how
long that data typically persists.
If we look here taking registers as the example where operations are measured
in millions of operations per second, this is the most volatile of data and
not practical to capture. Next, we have RAM, random access memory, and this is
what most users will typically associate as computer memory and it's here
where a copy of RAM is obtained.
It's here where things like running processes and open documents are returned
and constant power is needed to refresh the current data until the data is
either overwritten or the computer is switched off.
As we proceed further down this list,
the data becomes less volatile, generally meaning it's retained
longer, taking the hard disk as the example where applications and
user files are returned even when powered off. And finally, at the
bottom of the list are considered to be the least volatile and an
example of this would be archived data where you may have years worth
of backups stored on tier.
Understanding the order data should be captured is vital. A failure to do so
could lead to loss of evidence. Considering if you're investigating malware
that only resides in RAM and you only capture hard disk data, this would not
give a good outcome to the analysis.
So from this list, we would focus on item two, RAM,
create a copy of the memory, and transfer to a secure location to analyze
with tools such as volatility. As I mentioned previously, there are many
opportunities to extract information using volatility.
One very useful source of evidence, if available, is command history activity.
This is an interesting area because command history is typically not returned.
There are circumstances where this activity is remotely logged,
but it's not common across an enterprise.
A user may open a command prompt,
enter some commands, and when done, close the terminal window. That history is
not returned so there is to some degree a level of anonymity.
If we can use volatility to extract the commands typed by a user,
that would be extremely valuable evidence,
it can show evidence of a user attribution if commands are identified entered
at the command prompt. With other corroborating evidence,
it can provide a strong indicator of intent showing that the
user intended to commit certain actions.
They could also be indicators of compromise showing lateral
movement and this could mean a user's active on one system
typing commands trying to access other systems on a network to
either find more information,
avoid detection, or further compromise additional systems. You can also find
evidence of privilege escalation which would show an active user was
entering commands in attempt to increase privileges.
So some very useful evidence overall can be found with
a single option using volatility.
It's also important to remember that using command line is not necessarily
malicious or suspicious and many users will have valid reasons for using.
Ideally, you should implement least privilege to limit the ability of
actions to only required responsibilities.
However,
approved users could include, but are certainly not
limited to system administrators,
developers, or DevOps personnel and these example groups may
need terminal access for day to day work.
The second group are unapproved, which is usually not through formal process,
such as within an organization,
but you would typically group malicious actors not permitted to access systems,
but you can also include the non‑typical users that you wouldn't
ordinarily expect to use a terminal prompt, as an example,
office administrators.
Some further examples of the user roles you may expect to see in the
workplace using command prompt could include administrators who need terminal
access to maintain and configure systems and services.
We could also have developers and testers who work in your organization
and have responsibilities in writing code and may also need to install
their own tools to help with development tasks.
And then we have others which could be, for example,
third‑party contractors working on a temporary basis to fulfill various roles.
We also need to think about unapproved user roles. A common term you may
hear is insider threat and this could be an employee who may be trying to
circumvent application or security controls and they may do this to
complete a task just to get their work done.
In doing so,
it may use terminal access to turn off services or run unauthorized commands.
Overall, this is not malicious, but potentially damaging.
We also have inside a threat where the actions are by an employee,
but the intention is malicious or deliberately damaging.
This could be an employee seeking to destroy or modify company assets or
to steal information as part of corporate espionage.
As part of this activity,
they could be using the command line to avoid detection.
Finally,
we have a broad group of external threats which could come in many forms.
It could be people trying to access internet‑facing
systems as part of an opportunistic attack.
They could also be targeted attacks against our organization with
the intention to exploit systems and services.
Volatility provides the analyst with a lot of information that can
quickly become overwhelming without some direction and this can lead
to excessive time spent performing analysis and getting lost in the
data. By using specific plugins,
you'll get much more specific results that will allow you to identify
relevant indicators of compromise much more quickly.
Pslist lists the processes present within a memory image and can be
used to quickly list processes running at the time.
This is great for identifying anything suspicious that may look out of
place, as well as give a sense of what was running at the time. Next, we
have connections, and if you imagine systems today are rarely
standalone, there will always be some form of network connectivity and
this plugin lets you identify any connections from processes and that
could be internal to your network or external connections out across the
internet.
Pstree is another useful plugin that displays processes, but also
the parent‑child process and can provide a quick indicator of how
malicious processes are executed.
For example,
if it originated from an internet browser, a command prompt, or explorer.
Process is another useful plugin and this extends on the previous and provides
more detailed information on the current process.
Cmdscan is used on a Windows memory image and is used
to search for command‑line activity.
I'll demonstrate this in the upcoming video and this can help show what a
person typed in the console. And consoles is another plugin used to search
for the command‑line activity, both work slightly in a different way so
the results may vary, and again, I'll show this in the upcoming demo.
Okay, that was a very brief overview of some of the plugin options and
I would recommend you take the time to look into each, as well as the
other plugins not covered in this course.
Okay, so to recap, we'll be using volatility to search for command‑line activity.
The results of these plugins will be reviewed.
We will use the plugin cmdscan to search for console
command‑line activity entered by a user.
We will then use the consoles plugin, again, to search for
command‑line activity, but this option may provide additional
output. For the demo, this could be considered a triage in a sense
the memory image is not completely analyzed.
Instead,
specific plugins are used to answer specific questions that you may receive.
For example,
you may receive a request that an employee has been acting suspicious
in the workplace and was using a command prompt in a job role that
does not require this. In this scenario,
it's possible to look for any activity to enrich or refute any question.
Using my analyst machine, here I've entered the volatility command
which I have already installed on my system.
Then I will specify the memory image.
This is called exampleserver.vmem, and as you may guess, this is the memory
image from a server, and then I'll specify the plugin cmdscan.
We quickly have some results and we can see that there is a
command to navigate to a folder called HackingTools.
It also looks like a command to run Netcat listener on port 443. Let's now try
the console's plugin and we'll use the same memory image.
It's the identical command, but we will swap the plugin to consoles.
This seems to have generated a lot more information than the previous command.
If we look closer,
we can see again the command for the Netcat listener on port 443, and this
time, we also have the screen buffer output and this is showing the command was
successfully executed and is listening on port 443.