I mentioned previously the different roles within security and who
would perform memory analysis within an organization.
I also mentioned the potential time, effort, and skills required.
And it's courses like this and other more advanced courses that will give
security professionals the skills to perform analysis.
When to perform memory analysis will more often be
dictated by your organization and procedure.
It could arrive as an alert.
A critical or high‑severity alert is generated by security software,
like a SIEM solution, that monitors for suspicious events from logs,
and the alert could be severe enough to perform memory analysis,
for example, during a ransomware attack.
An external request where another team, for example,
a threat intelligence team may ask you to perform memory analysis to extract
indicates a compromise from a system to enrich their reports.
Or it could be an investigation,
maybe an employee is suspected of stealing company information,
and the memory analysis may be able to identify
additional evidence to help with this request.
A number of memory image formats are supported by volatility,
and it's important to know this in advance.
RAW images are generated using tools like dd,
which takes a copy of the memory at the time of capture and saves it as a file.
VMWare format in a virtual machine environment when
a VMWare machine is suspended,
the RAM is saved to disk as a file so that when the virtual machine is resumed,
the saved state file is used.
VirtualBox, as with the previous, but using the open source VirtualBox software.
Hibernation is specific to Windows,
and when enabled is used by the operating system to store suspended states.
So when the user puts their laptop into hibernation,
the content of the RAM is saved to disk.
There are also the formats not covered here,
but the above are going to be the most common that you will encounter.
As an example incident, your SOC, security operation center,
receives an alert from their security software.
The alert is generated on the 3rd of May,
and it's late in the evening when the office is supposed to be closed.
The alert provided the IP address of 10.11.1.12, which is a company server.
The alert also shows that the server may be connecting to an IP address,
54.93.101.71.
The company incident response process is started.
The affected server is a VMWare virtual machine,
and it's put in a suspended state.
The memory state file is captured and saved to a secure location.
The analyst will need to analyze the memory image for indicators of compromise,
and where possible, provides security recommendations.
Okay, so let's analyze the memory image.
We're going to run the volatility command with the connections plugin.
We can see a remote address of 54.93.101.71 and process ID 2213.
Now let's look at the processes.
And here, we're using the plugin psscan.
We're interested in the process ID 2213, which is showing as explorer.exe.
Now we've identified the suspicious process.
We can extract that as a file and perform further analysis on it.
You can use the memdump plugin, and we'll export process 2213.
That's now successfully exported, and here I'll list the contents of that export.
You could, if you wanted,
send this to a malware scanner or additionally
perform malware analysis on the file.
That concludes this demo where we looked at extracting indicators of compromise.
Some of the areas you may want to review as part of remediation could
include reviewing users affected during an incident to limit the
blast radius and making sure users only have permissions needed to
perform their duties and no more.
You may also want to disable credentials.
If accounts are not immediately needed,
disable so they cannot be used in an unauthorized manner.
Consider introducing system hardening to include removing unwanted software
and services and only use business‑approved software.
You may need to rotate credentials of existing
accounts to prevent password reuse.
And finally,
have an incident response process that ties all these
actions into a coherent series of steps.
Overall,
we want to reduce the risk to minimize any occurrence of
incidents where memory analysis is required.
Firstly, security awareness to teach and train good behaviors to employees.
Employees need to know what's permitted and the importance of security.
Users should not be given excessive access to systems,
and privileged access should be strictly controlled.
Finally,
is monitoring at a minimum to detect something bad has happened
through logging and monitoring processes.
In this last demo of the course,
I'll quickly show how to perform whitelisting on a Windows system.
Had whitelisting been implemented on the server incident in the previous demo,
the attacker would now have the ability to start a new process.
First, we need to navigate to the policy editor.
And we can navigate to the Windows Settings,
Security Settings, Application Control Policies.
And from here, we can run AppLocker,
which we can use for whitelisting applications.
In this demo, we're going to enforce application execution.
So under Enforcement, we're going to enable Configure.
I'm going to enforce the rules and then apply that.
Now we need to create some enforcement rules.
Under Executable Rules, Create New Rule.
Click Next.
We want to select Deny for everybody, and click Next.
Here, we want to identify unapproved software by File hash, then click Next.
And here, we want to select the unapproved software.
In this demo,
I'm going to select a hacking tool that I don't want employees to run.
Then click Next, and click Create to create the new rule.
Since this is the first time AppLocker is being run,
it's asking us to create some default rules,
so we'll click Yes on that.
So a quick review of the rules that we've got.
Should allow system applications to run,
but the hacking tool should not be able to be run by employees.
Before we test the rules,
we just need to make sure that the service for AppLocker is running correctly.
We can see that this service is started,
and it's worth making sure that this starts automatically on reboot as well.
With AppLocker configured and running, let's test our rule.
And here we can see that the Group Policy is preventing the tool from
being executed while other applications are unaffected.
This concludes our software whitelisting demo.