Hi, DEF CON. I'm Shai Nechman.
Today, I'll present InfectionMonkey,
an open-source breach and attack simulation tool.
We'll cover what the monkey is,
how you can use it to improve your network defenses,
or step up your testing,
and we'll go through a deep demo.
But first, let's dive into the breach.
We're going to see a simulation of a breach
that we saw in one of our real customers' networks.
As always, a server was breached.
That's how it starts.
Once inside the network,
the attackers were able to move laterally
using a vulnerable out-of-date Hadoop service
on a Linux server to jump to that Linux server.
That's the red line you're seeing on the map here.
And the attackers exfiliated information
back to their original breach server
through an uncommon port.
That's the gray line on the map.
After the original propagation,
the attackers were able to scan and find even more servers,
both Windows and Linux machines.
They stole credentials, breached more servers
using other protocols like SSH.
They even set up a tunneling station there in the middle.
That's the blue line.
Into a different sub-network entirely.
And started hopping, started stealing,
and basically took over the network.
And my question to you is,
how would your organization respond?
Now, this being DEF CON, obviously,
I don't only mean your organization.
I also mean the organization that you might be testing right now.
How would your organization respond to specific attack scenarios
like someone stealing credentials,
someone compromising a web server,
a malicious device logging into the network,
some blast radius attacks like pasty hash or connectivity checks?
What would the security do?
Would alerts be thrown? Would the SOC respond?
Would you know the attacker's visibility?
Let's take a look at a case study.
We have an environment, a large development network,
with a mix of Linux and Windows servers.
Multiple security products deployed on-site,
McAfee Move, an IDS on the network,
and the firewall between different segments.
And the scope of this test, the test scenarios,
were malicious devices logging into the network
and stealing some credentials.
What happened?
Well, what you would expect.
There were no security alerts,
even though we had more than 5,000 different attack attempts,
and there were no alerts on brute force attempts as well.
The antivirus solution was completely irrelevant
to stop the lateral movement inside the network.
The firewalls, while deployed, did not stop the cross-segment traffic.
And doing some credentials analysis,
we saw that a single old password that we stole
allowed login to all the Linux servers,
and some Windows machines had the domain admin passwords cached on them,
therefore were usable for propagation.
This all brings me to the point of our talk today.
What is InfectionMonkey?
So let's try to answer that by looking at a few key ideas.
The monkey is a breach and attack simulation tool.
It simulates an internal attacker,
which tests whether your security systems work,
whether they detect, they alert, they actually block something.
The monkey helps you make sure that changes don't open up new holes.
It's automated, semi-automated.
You have to run it manually the first time,
and it's exhaustive as much as it can be.
The second key idea to take a look at, it's open source and free.
This is a community project.
It's managed by GuardiCore Labs, but it is completely free, completely open source.
We have over 3,200 stars on GitHub,
a big active user base, hundreds of downloads a week.
This is by the community, for the community.
The third key idea to take a look at is the fact that the monkey is safe for production networks.
The monkey is being executed right now by large organizations in various verticals,
big telecom companies, education, school counties, universities, healthcare, in their production network.
The monkey is built to run on these infrastructures, on these critical infrastructures, and not crash them.
That puts some limitations on what the monkey can do while attempting to breach, while attempting to attack.
But safety is the first priority, since we do want people to run this in production networks and not lose their jobs.
And it's useful for you.
If you're a network engineer, a security engineer, a red teamer, a blue teamer, a purple teamer, a CISO,
the monkey could be useful for you.
And stick around to figure out why.
Since this is DEF CON, let's try to explain what is the infection monkey by comparing it to existing solutions.
You're all very familiar with classic manual penetration testing and with vulnerability scanners.
Let's see how does the monkey compare to these solutions that you know.
So here's a data center we visualized.
Each node in the graph represents a machine.
Each link in the graph, each edge represents a possible route between two machines.
If we're talking about vulnerability scanners, and we plop one down here.
And when we test the network using this vulnerability scanner, we place it in one or more places across the network.
And as you can see, it sort of checks every single route to that machine.
If we place enough scanners properly, we can probably test most parts of our network for remote vulnerabilities on an ongoing basis.
But it won't be able to simulate an attacker's move.
So talking about coverage depends on how you deploy it.
Frequency, you can do it whenever you want, since this is an automated tool.
But it does not simulate an attack at all.
Therefore, sometimes the results of vulnerability scanners are exaggerated.
It's huge lists of CVEs that you can't deal with.
And they don't actually simulate what happens.
So they might be closing routes, which are completely irrelevant for attackers that attackers will never use.
On the other end of the spectrum, you have penetration testing.
Here, we place the penetration tester on one side of the network, the red team.
And we give them a goal, some valuable assets.
And as you can see, some machines are exploited, some are not.
Eventually, the red team reaches their goal.
This is another popular method.
The pen tester can start from the internet.
Sometimes that includes phishing attempts or whatever.
But in the end, he gets to the network and simulates an APT.
On the one hand, you get yourself a professional in-depth testing, especially if the penetration tester is good.
Which sort of unveiled a weak path here, the red path.
And sort of discovered some weak points across the data center.
So the testing is in-depth.
But what if there are more routes?
Obviously, the human tester cannot cover all possible paths.
So the coverage might be low.
What happens if a few days after this penetration tester stops his or her work and leave?
The highly dynamic data center sets up a ton of new resources and deploys three new apps.
How would these results help those network changes?
After all, penetration testers don't work on a daily basis. That just won't work.
So the coverage is low, the frequency is low, but it does simulate an attacker, so it does do in-depth testing.
The monkey tries to take the best of both worlds.
It's automatic, so the coverage and frequency are high.
It's in-depth, since it simulates an attacker and it actually propagates across the network.
And the best of all, it's free, since it's open source.
Let's take a quick look at the main features of InfectionMonkey.
The monkey is highly configurable, so it can fit different use cases.
It has various attack techniques.
It uses brute forcing, it steals credentials and passes the hash around.
It has wormable CVEs that are optional.
If you're worried about running CVEs in your network, you can turn these off.
Same for credential brute forcing, by the way.
So you get quite a lot of attack techniques built into the tool.
Actionable reporting. This is really the meat of the matter.
You're going to see the reports later on in the demo, so we won't delay on this now.
But the monkey has three reports.
The first one being a security report aimed towards whomever wants the details.
This is the most actionable report out of all of them.
A Zero Trust Report.
If the organization you're testing or your organization is using the Zero Trust lingo,
the Zero Trust Extended Framework by Forrester,
this is the first-of-its-kind report card on where are you in your Zero Trust journey.
And lastly, the MITRE ATT&CK Report.
If you're familiar with the MITRE ATT&CK Framework,
the monkey maps its actions to the techniques that this framework offers,
and you get actionable mitigations on each technique that the monkey successfully used.
We're going to take a deeper look into those reports later on in the demo.
And lastly, it's easily deployable.
We didn't want some expert, super-hard tool.
This is supposed to democratize penetration testing and be easy for the community.
We have one-click options for cloud environments,
so if you're testing a cloud environment, just hop onto the Marketplace. It's free.
If you're not using a cloud environment, there is a Windows Installer, a Linux Installer,
a Debian package, a Docker machine, a Docker image ready with the Infection Monkey installed,
and a VMware OVA file.
So no matter where you're running, no matter which way you like to deploy machines,
we've got you covered.
And it's very easy to use with a friendly web interface aimed towards getting results quickly.
The monkey should be able to offer you is a different perspective.
What you have, what your organization have is a very nice, you know, Visio chart.
You always see these in presentations that shows everything is segmented.
Everything is beautiful. We have no problems.
But we have the monkey telling us what's really happening.
So on the other hand, you can see the attacker's knowledge
and maybe find paths that you didn't think were possible.
And you have the application diagrams and our tools can tell us who's really communicating with whom.
And obviously, as we know, in reality, it's all just a big mess that is just waiting to burst up in flames.
So which use cases is the monkey relevant for?
Going back to the beginning of this presentation,
it can help you test specific attack scenarios in a continuous and automatic manner.
Demonstrate breach detection, test for segmentation.
If we're talking about some specific scenarios, credentials tapped,
you can feed the monkey with credentials of an IT team member and see how far it can go.
You can test what damage results from having specific servers compromised.
Let's say testing from one location, maybe the web applications of your organization,
something happens in the databases, stuff like that.
Malicious device, someone added a malicious machine,
like a contractor maybe bringing his laptop to on-site and connecting to the internal network,
but that laptop is completely full of malware and seeing how far the attack can go from there.
Or blast radius, let's try to limit damage from a breach.
Are your firewalls and the routing rules and whatever separating different networks?
Let's say the development network and the production network.
Another example could be past the hash attack.
Can attackers build a path that shouldn't exist from a server to a domain controller
using cached credentials or SSH keys that are left on the machine?
The monkey can help you test the existing security setup, the security strategy of an organization,
see if alerts are popping up, check if the SOC is responding correctly to an attack,
where the organization stands in their zero trust journey,
or how much of the MITRE ATT&CK framework are they limiting?
How much are they covering?
And the main thing, the main benefit that the monkey can give you,
if you want to test your network or if you want to present your findings as a red teamer,
is to show the visibility from the attacker's point of view,
not in the sort of high-level way that the visios usually show it.
So, we're going to jump into a demo.
In this demo, the first thing we're going to do is run a simulation
with a few different use cases in the configuration, and I'm just going to pop into it.
So, when you open the InfectionMonkey island,
that's the command and control server of InfectionMonkey,
for the first time after you deploy it, this is what you're going to see.
A friendly UI, one, two, three, four, that's the stuff you need to do to get started.
So, let's get started.
It tells us to go ahead and run the monkey, and we jump here,
and it offers us to configure the monkey to fine-tune its behavior.
Since I already have a test scenario in mind,
I will choose this option and hop into the configuration.
Here you can see we have a few different tabs for configuration.
If you want to mess with the monkey, choose which techniques it will attempt
and which techniques it will not attempt.
If you're familiar with the MITRE ATT&CK framework,
and that's how you like to use stuff,
we mapped everything that the monkey does to the MITRE ATT&CK framework.
We're not going to do this today.
What we are going to do is first hop onto the network tab
and define the scope of this test.
And this is important since this is what will aim the monkey towards specific servers.
Now, the monkey doesn't have to be aimed towards specific servers.
We can check this and the monkey will just try to propagate to any machines it can find
along with the targets that we will manually configure.
But in this instance, I only want it to run on the targets that I've defined.
And I want it to hop from the initial infection point three deep.
Sort of giving a spoiler here, but jumping to the map,
the monkey started from here, but you can see it hopped pretty deep,
three deep from the original place where it started.
This is the scan depth configuration.
Moving on to the target list, this is the list of the targets that the monkey tried to scan
and obviously attack.
So we have quite a... just a bunch of IP addresses here.
This is just the IPs that I know I want to test in this demo, in this simulation.
And lastly, I also configured the monkey to test for network segmentation.
I know I have these three different segments.
This network range of a segment, 10.2.0 from 11 to 12.
So basically a two server segment.
This segment, which is a single IP segment, a network segment that only has one machine.
And the slash 24 segment here at 10.2.2.
So what I'm telling the monkey is to try and test for network segmentation,
see if it can create cross segment communication.
Other than setting up the scope of this test,
you can also configure which exploits the monkey will try to attempt using the exploit selector here.
In this instance, we went with the Struts2 exploiter, the Shellshock exploiter,
SSH exploiter, which brute forces using credentials,
the MSSQL exploiter, the WMI exploiter, and the SMB exploiter, which again is a brute force exploiter.
As you can see here, we have some unsafe exploits.
The Microsoft Bulletin 08-067 is an unsafe exploiter that might crash due to the fact that it uses buffer overflow.
And we, you know, marking security of our users first,
even if you were to check this and check all of the exploiters,
and uncheck them and recheck all of them,
you won't get the unsafe exploiter.
You really have to opt into that.
We also set up some passwords here.
This is in order to simulate a credentials theft, let's say a phishing attempt was successful.
So we got some passwords that the exploiters will try to use and some users here.
And yeah, we can take a look at the infection map and see what happened.
You can see we started from here.
This is the Monkey Island.
This is the server.
We started from here because we clicked on run on Monkey Island server.
And once we clicked on this, everything here went pretty wild.
Every red line represents a successful exploitation attempt.
So let's just take a look at the line from the Monkey Island to the server called struts2,
which obviously is a struts server.
Let's take a look at this line.
And as you can see here, it was successfully exploited using the struts2 exploiter.
And you can also see which services were found on this machine.
So you get a mapping of which services were found.
And once the monkey got here, did exactly the same.
Yellow lines represents scans.
These are the monkey trying to scan a machine and trying to find ways to attack it.
But in this case, it didn't manage to attack.
All the exploiters failed, but it did find open services.
So it marks this interaction as a scan line, as a yellow line.
Lastly, we have the island communication lines,
which just show how the agent communicated back to the command and control server and reported everything back.
We also have this nice configuration here with the blue lines.
What we can see is the monkey started on the Monkey Island,
moved to this server called tunneling-9.
This is the first tunneling endpoint.
This server connects two network segments.
You can think of it like some sort of jump box that the organization is using.
This server connects the 10.2.2 subnet to the 10.2.1 subnet.
It has two network interfaces, one in each segment.
Now the monkey hopped onto this machine and was able to propagate to this machine.
For instance, using SSH.
Now, what is this blue line?
This blue line tells us that the monkey on tunneling-10 needed to send information back to the island.
It needed to report back to the command and control server what it has found.
However, that's easier said than done.
If there was a path between the machine tunneling-10 and the island, the monkey could just send the information back, no problem.
However, these two machines are not connected.
They are not in the same network segments.
They don't have any direct communication in between them.
In this case, the monkey on tunneling-9 turned itself into a tunneling server.
And enabled tunneling-10 to report back to the monkey island over tunneling communication.
In that exact same fashion, this happened twice again with tunneling-11 and tunneling-12 with a different subnetwork, 10.2.0.
So what we really had here is two hops between the monkey and the island.
And the monkeys helped themselves tunnel the communication back completely automatically.
So what we're seeing here is sort of a very deep network test.
And the monkey sort of bridging networks and showing how you can hop between different subnetworks in this test instance.
Now we can hop on to the security reports section of the monkey.
We have three different reports.
The first report is the security report.
As you can see here, the report starts with an overview.
This is sort of the summary of what happened.
First of all, it let us know that critical security issues were detected.
Which is obviously the case when the monkey was able to run rampant in a network like this, do tunneling, use a ton of exploits and propagate to a ton of different servers.
The monkey started propagating on this machine.
And it tells us which machine it started on. In this case, it's the island Windows machine.
It tells us the configuration we used, which we went over already.
Which usernames and passwords were used for brute forcing.
Which exploiters were selected.
Which IPs were selected to scan.
And it notes that the monkeys were configured to avoid scanning local network.
This is a really useful feature to limit the spread of monkey.
If you want to run it in a network and you're afraid the monkey will just spread all over your network.
This is a pretty good way to avoid that scenario.
And what did the monkey find?
During the simulated attack, the monkey uncovered four threats.
Stolen credentials that were used to exploit other machines.
Machines that were vulnerable to shell shock.
Machines that are accessible using the passwords we provided for brute forcing.
And the struts2 vulnerability as well.
So we have two wormable CVEs in our network.
And we have two credentials-based attack vectors in our network.
And we also found segmentation.
Potential weak segmentation and actual segmentation issues.
Communication from this segment to this segment.
Which we defined as two different segments in the configuration.
And from this segment to this segment.
Jumping back to the map.
This is these lines.
From the 10.2.2 segment to the 10.2.1 segment.
And these four lines.
From the 10.2.1 segment to the 10.2.0 segment.
Obviously, if you have your segmentation on lockdown, these communications just won't happen.
And on every issue here, you can read more and get more specific details.
Which services were used.
To which IP was able to communicate, etc.
Taking a look at machine-related recommendations.
You can see which recommendations we have for each machine.
So if we want to fix the critical app, the crown jewel, we can find it here.
Let's say it's Tunneling11.
And we see that we need to change the user monkey password to a complex one-use password.
Because it's shared with other computers on the network.
And again, you can read more.
Specifically, this is vulnerable to SSH.
And you need to do micro-segmentation policies to disable communications that aren't required.
Because a tunnel was set up.
Which obviously means that the machines aren't locked down.
Because they can create communication paths that we didn't want them to create.
Some different recommendations.
The struts24 machine.
Struts2-24 machine.
You need to upgrade the struts version.
Because the struts server at this machine, which is this IP, is vulnerable to a remote code execution attack.
You can get even more details here.
The attack was made possible because the server is using an old version of Jakarta.
That does the multi-part parser thing.
And there is more information.
You can click on it and obviously see the CVE public information.
And there are a ton of machine-related recommendations here.
For example, the machine that was vulnerable to shell shock tells you that you need to update your bash version.
And you need to segment your network to make sure that there is no communication between machines from different segments.
The next section of the report shows us the network from the monkey's eyes.
This is the part of the attacker's visibility.
From the attacker's point of view, this is how the network looked like.
Basically, Swiss cheese.
It tells us that the monkey discovered 10 machines, successfully breached 9 of them.
What's the last 10%? Well, it's just the machine we started on.
Every single machine in this test was breached.
Obviously, this is a test network and we set up this as an example.
But this is not very different to the results we've seen when running with customers.
Now, we can see a summary of which services and on which machines the monkey has found.
This sort of maps your attack surface.
This shows which ports can be knocked and see who's answering.
For example, the tunneling machine, which has both of these IP addresses, as we've said, 2.2 and 2.1, is accessible from all of these machines using SSH.
And the struts24 machine listens on 8080 as well.
You can also see which exploits were used on each machine.
So if you want a sort of vulnerability assessment summary, you can see that here.
This machine was exploited using SMB.
Specifically, credentials were stolen using Mimikatz.
And you can see the post-breach actions that the monkey has performed.
It performed 243 post-breach actions on 7 machines.
Which actions? Well, we're going to see in a second.
But if you want the whole list, you can see here.
And you can see which credentials were stolen from machines in order to propagate further.
So this is sort of a credential analysis part of the report.
This is the security report.
But we also have two other reports.
The first one is the Zero Trust report, which is the first Zero Trust assessment report available.
As you can see, we've mapped what the monkey does to the seven pillars of the Zero Trust Extended Framework.
And we've got a lot of red in this report card because we failed a lot of the tests.
The monkey tests for violation of principles defined in the Zero Trust security model.
And maps it to each of the seven pillars.
Networks, devices, people, workloads, data, visibility and analytics, and automation and orchestration.
Now, the gray just means that this wasn't executed.
In this test, in this simulation, there wasn't anything relevant for workloads, automation or orchestration.
Red means that something related to this component failed.
Something related to data failed.
Well, what was it?
We can take a look at the test results and see exactly what happened.
So let's take a look at data, for example.
We can see that other than everything else that the monkey has done in propagating, stealing credentials, running exploiters and giving us all this data back,
it also scanned for unencrypted access to data.
Because one of the Zero Trust principles in relation to data is that you need to secure data at transit by encrypting it.
However, while the monkey wasn't able to find Elasticsearch instances, it was able to find unencrypted HTTP server.
Someone is not using HTTPS and that's a problem.
Now let's say we want to know even more data about this specific problem.
Which servers? When did this happen? What's up with that?
We can scroll down to the finding list and see that the monkey was able to access HTTP servers.
And if we look at the specific events, we can see exactly which monkey tried to perform the network scan and when.
We can see which services it found. It found TCP80 and then it mapped an HTTP service that was recognized as an open data endpoint.
Specifically, it's an Apache server on Ubuntu. And this is the version.
So, as you can see the details, it is a pretty detailed report.
You can also export all the events to JSON. So you can run scripts on it, match it up with other APIs, etc.
Let's take a look at a different test. Let's take a look at networks, for example.
Obviously, with the monkey being a breach and attack simulation tool and GuardiCore being a network company,
which sort of mainly maintains this tool, this is the part we invested the most into.
And we do have quite a lot of tests here.
Now it's time to circle back to all the segmentation problems we saw.
The monkey tried to scan and find machines that it can communicate and do cross-segment communication.
And it was able to, so this test failed because Zero Trust Networks tells us that the most important thing we need to do
is to apply segmentation and micro-segmentation inside our network to lock that down.
Again, if we go back to the findings, we can see that the monkey performed cross-segment communications
and we can see exactly which violations occurred.
In this instance, Tunneling 10 managed to talk to 10.2.10.11 in this segment.
So you get a pretty detailed report on which segmentation violations occurred.
If you have a firewall solution or a micro-segmentation solution, every single event here should be an alert.
So you can export all these results and try to match them up with the alerts from your whatever security solution.
You can see also that we failed the Network Policy Should Be As Restrictive As Possible test.
This is because the monkey was able to tunnel traffic using other monkeys.
We also failed this test, which appears in the people pillar as well.
So let's take a look at that. What does people mean?
Well, it talks about users. People means Zero Trust users.
In this case, the monkey tested whether users' permissions to this network and to the resources inside the network is MAC only,
mandatory access control, whether it's a need-to-know basis,
whether only known users can access the small subset of resources that they should be able to.
The way the monkey tests for this is pretty creative.
It creates a new user, a new local user on the machine and tries to communicate online,
tries to just go out to the internet with an unknown new user.
This is a completely unknown user because it's a random username.
There's no chance that it existed before.
And as you can see, it was able to do that two times.
It created a new user and reached out to infectionmonkey.com,
so not even a super well-known domain, even though we do get quite a lot of traffic,
with some new user and a bunch of random characters.
And the process succeeded. It managed to create this communication with a new user.
That means that our network, this sample network, doesn't block unknown users from communicating online.
And as you can see, some tests can be mapped to quite a lot of different pillars,
because this is about people, this is about networks, and this is about visibility.
You should be able to see this stuff.
The monkey also obviously maps every single device that was exploited as a problem,
because you need to do some traditional endpoint security to stop the monkey from propagating across the network.
And as you can see, the monkey was able to exploit those endpoints,
and you need to check the logs to see if you can recognize this activity.
Specifically here, we can see all the exploit attempts.
Now, even failed exploit attempts should be logged, but successful attempts obviously should have been blocked.
And again, you can export all these results to a JSON file that you can then match up and script to other stuff.
The monkey also mapped whatever passed.
So, in six different instances, the monkey wasn't able to create a new user,
because of endpoint protection or maybe firewalls blocking the communication.
So, even if some tests are failing, the monkey lists everything for you.
So, you can see what you do have on lockdown and what you don't have on lockdown.
The verify part of the report tells you the stuff that you need to verify manually.
This is basically a list of everything bad that the monkey has done in this simulation,
that you need to test and see whether you can find all the malicious activity in logs and alerts.
This is sort of the, let's check how the organization will respond part of the report.
And again, once you're done fixing all the holes, going over all the reports, pushing out all the information,
you can start over, run again, and within a few minutes, you'll get this report anew.
So, you can see if you actually closed all the issues, or maybe you did it incorrectly this time.
Lastly, the monkey has the MITRE ATT&CK report.
This shows information about the MITRE ATT&CK techniques that were used by InfectionMonkey.
This enables you to see which techniques were successfully used by the monkey,
which techniques the monkey tried to use, but it failed,
which techniques just weren't attempted,
and which techniques are disabled and you need to enable in order to run.
In this case, we don't have anything disabled because we had monkey running full throttle.
And if we want to get more information about some of the ways that the monkey utilized techniques,
we can click on any of these techniques and see what the monkey exactly did when it tried to use this technique.
Let's take a look at multi-hop proxy, for example.
Let's say we want to completely lock down our network and disallow attackers from doing command and control.
We want them to be completely lost, even if they manage to breach.
So, what did the monkey do?
Well, the monkey used multi-hop proxy, and we can see exactly which tunnels it created.
It created tunnel from tunneling 11 to tunneling 9 with two hops.
We saw that on the map before.
This is these lines.
Yes, this communication path is a multi-hop proxy.
Now, let's say you are using the MITRE ATT&CK framework,
but you don't exactly remember what's the multi-hop proxy technique.
Well, you can just click on this question mark here,
and we immediately show you the relevant page in the MITRE ATT&CK framework.
The MITRE ATT&CK being an open source project as well, greatly beneficial to the security community.
We also pull the mitigations, because the moment you find that a technique was successfully used,
you want to know how to mitigate it.
So we just list the mitigations from the MITRE ATT&CK database.
Let's say uncommonly used port.
Well, the monkey, you get, again, more details.
The monkey used this port to communicate to the command and control server.
And you also get mitigations.
Obviously, popping up again is network segmentation.
Some other stuff, you can see that the monkey did some persistence testing.
It's important to note that this is only testing.
The monkey doesn't persist on machines.
It only tests if it can persist.
For example, it used the create account technique.
As we saw before, it was able to create a new user on the network system.
And we can see the results for each attempt, even if it failed.
And you can see different mitigations.
Again, you should use multi-factor authentication.
You need to configure your operating system so that malware can create new users, etc.
As an accessibility feature, we also list all the techniques in a list instead of the matrix.
So it's easier to navigate.
And also, if you have problems seeing the colors of the report, you can see the icons.
However, we found out that even our regular users love this display.
So just all users like the display as a list as well.
And again, you can open up the techniques and see that, for example, in the collection tactic,
the monkey used the data from local system and gathered sensitive data, like SSH keys.
These are the three reports.
Deploying the monkey is super easy.
You have the different deployment options, and you can see them or ask some questions.
Let's say you're not sure what's the MSSQL exploiter or how does it work.
Well, in this version, which comes out for DEF CON in a few days from when I'm recording this,
we also brought up a new documentation site, which guides you towards setup guides, getting started guides,
frequently asked questions, references for all the exploiters we're using and all the operating systems the monkey runs on,
which operating system it supports, some scenarios that you can run.
This is the test scenarios we talked about, like a breach from internet-facing servers, phishing.
You want to test segmentation or you want to verify security solutions and the procedures and the teams.
This is sort of the purple team, you know, magic option, a deep dive into all the reports and seeing how to integrate monkey into other stuff.
At the time of this recording, we're supporting integration, deep integration with AWS, both the security hub,
and automatically on your EC2 instances. And the guides are pretty deep about every single option that we provide.
Let's say the Windows installer, well, it's supposed to be very user-friendly with troubleshooting,
and it's open source like the rest of the project. So if you find something that you want added,
you can just edit it or open an issue for us, and we'll take care of that.
Now what? So we're done with the demo. We took a look at how does the monkey work and what can it offer for you.
So first of all, from us to you, we're releasing a new version, version 1.9.0 with more attack techniques,
as you've seen in the report, the monkey runs faster and completes the simulation a lot quicker.
The server itself has great performance improvements as well, so you can run it on large-scale networks,
and the UI is improved. Compared to old versions, maybe you can pull up old versions of the tool
and see that the UI has been vastly improved. It's also a lot more secure.
We've integrated with Snyk IO, a service that checks the dependencies of a project for vulnerabilities.
So we've vetted the product from having vulnerabilities in its bag, and we've run a lot of tests.
This really coincides with the fact that we do have big enterprises running us in production networks that actually matter.
So we had to step up there. And the monkey is secured by default. For this demo, I turned this feature off,
but every single InfectionMonkey instance that you will deploy has password protected by default.
You have to set up a user and password combination in order to access the monkey.
So even if you set up the InfectionMonkey in a network and somehow lose access to the server,
or maybe open up access to attackers to that server, that doesn't mean that they are going to take control of the monkey,
because they will need the password combination as well.
So you can download this version for free from InfectionMonkey.com, our homepage.
You can also access articles and the documentation site from InfectionMonkey.com.
And I'm inviting you, first of all, I'm inviting you to use the monkey. Use the InfectionMonkey.
If you're doing red teaming, purple teaming, blue teaming, this is a great tool for you.
It's automatic, it's free, covers a lot of ground, covers a lot of frameworks.
If you're doing penetration testing, for me, the monkey is a no-brainer.
It takes out all the skidding part of penetration testing, does it for you, gives you a pretty nice map,
and from the results the monkey gives you, you can do much smarter stuff.
You can focus on the harder parts of penetration testing, on the manual parts, maybe the human parts.
I don't know if we're still doing physical examinations in COVID times, but if you're hacking a site physically,
opening doors with credit cards and whatever, let the monkey take care of scanning ports and using the vulnerabilities
and stealing credentials and remembering them. You don't need to do that manually anymore.
If you want to do network analysis or even IT and security analysis, let's say you purchase a new security solution
for your network, you want to test that stuff and you don't want to test it manually.
Run the monkey after you install it and make sure you configured it correctly, make sure it actually works.
So the main invitation for me to you is to use the monkey.
Secondly, you can join us. You can join the monkey trainers community. You can contribute.
User feedback is the number one priority setter for us on the roadmap.
If a user has a question or a problem or discovers a bug, it jumps to the top of the backlog.
So your feedback could really impact the project.
Now with our new documentation site, you can also very easily contribute documentation.
If you have new scenarios in mind, maybe you want to add more information about specific exploiters or share your screenshots,
something you can add to the troubleshooting section, a whole new part of the documentation you think about,
you can easily contribute documentation directly from the web.
And obviously, if you're a developer, if you're a security developer, if you want to contribute new exploits, new scanners,
new MITRE ATT&CK techniques to increase the coverage.
If you're into Zero Trust and you want to add more Zero Trust tests, you can contribute code.
The project is completely open source and completely free.
There is no freemium version. There is no pro version.
This is a 100% community project.
And lastly, I invite you to spread the word.
The monkey is completely dependent on the users and the community to do good in the world.
And if you want to help it, you just need to tell other people about it.
Since this is a recording, I can't take questions in the recording.
But in DEF CON safe mode, I should be online on Discord right now to answer your questions.
However, if you're watching this recording after the event happened, don't worry.
You can reach out to the entire InfectionMonkey community by going to infectionmonkey.com and clicking on the community button.
You will be able to access our public Slack.
We have a public Slack workspace where all the developers and all the users hang out, answer troubleshooting questions, talk about features, and discuss security in general.
You can also access it from the documentation site right here in our Slack.
You can also reach us by support at infectionmonkey.com if you're having any issues.
Take a look at the code at github.com slash Gartic or slash InfectionMonkey.
And just take a look at our homepage, take a look at the articles.
Thank you very much and enjoy the rest of DEF CON safely.
Wash your hands, keep your mask on, but since we're at home, we can ignore these for now.
Thank you very much.