Now that we have an understanding for setting up an attack through
the selection and configuration of exploits,
targets, and payloads, we can launch an attack and review the results.
If the attack was successful, then we can take the next steps.
Our focus in this module is two‑fold, exploitation and post‑exploitation,
that is launching the attack which exploits our targeted
vulnerability and making sure it worked by understanding the
output in the console and adjusting as needed.
Then, post‑exploitation using post modules, local exploits, and Meterpreter.
We'll have a few demonstrations along the way.
There is an attack flow once we've identified our
target system and vulnerability.
As we've discussed,
we configure the exploit for the target and the payload to deliver.
We execute the attack by launching the exploit from
the Metasploit Framework console.
As the attack is executing,
Metasploit will provide messaging back to us in the console.
We need to understand what Metasploit is telling us
about the progress of the attack.
If we are successful in exploiting the vulnerability and
gaining access to the target system,
then we can start our post‑exploitation activities.
We spent a lot of time on the search, selection,
and configuration of our exploit module and its payload.
The next step is quick and easy.
Type exploit.
This command begins the attack.
The Metasploit framework console will start any listeners needed,
begin the execution of code in the exploit module,
and generate some output to the console as it progresses.
We will look at that output to see if we were successful or not.
On the Globomantics red team,
their attack and testing activities are completed as a coordinated effort
with the business and IT stakeholders, an overt or visible testing
methodology in which the IT teams are aware of the testing or an evasive
and secretive approach where the teams are not aware that testing is taking
place. They use a goal‑oriented approach where the testing should produce
key outcomes that allow the stakeholders to improve their security posture
and practices.
Often,
the goal is to discover vulnerabilities that may have been missed in
the system development and deployment process,
misconfiguration of systems, or software with known
or previously unknown issues.
When systems are deployed,
there are security devices and software in place to
detect malicious and anomalous activities.
They provide visibility to the network and allow blue teams to detect,
contain, and stop bad actors in the environment.
Red team testing may be used to identify areas where
visibility on the network is lacking.
The testing may be used to run through an exercise for the blue teams to
detect and respond to activities generated by the red team.
It can be part of an annual compliance and training process.
It may also be used as an opportunity for technical training for both the
red team to try new tools and techniques or for the blue team to get
better at detection and response activities.
In terms of the awareness of the teams involved in the testing,
the red teams may or may not issue notifications depending on
the rules of engagement or the goals of testing. In a
coordinated or overt testing project,
there may be notification given in advance. Sometimes when a more
realistic test is needed, any notification is given after the test
is complete or sometimes not at all.
These are generally more rare,
but may occur when data is needed to understand the security of the
operating environment and the response to testing.