Red Team Village - Making Breach and Attack Simulation Accessible
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Nehmad, Shay
Oftentimes one of the greatest challenges for security professionals today is finding a way to effectively communicate the state of a network’s security posture, and what steps are necessary to achieve the organization’s security goals. Red teamers are already familiar with executing a typical Breach and Attack simulation, but how can they take greater advantage of their findings, and better yet, share those with the C-suite? The Infection Monkey is a mature, widely-used Open Source GPLv3 licensed tool specifically developed for enterprise red teams. Designed to test an organization’s detection and response methods and teams, the Monkey simulates all steps of an attack by mimicking a variety of adversary moves such as scanning, exploitation, lateral movement, password stealing, network mapping, security control bypass and more. Overall, the Infection Monkey’s simulation reveals it contains a lot of stages one might find in a manual penetration test (or in a real attack). The Monkey is easily configurable, and starts from a single machine and propagates according to the test scenario while collecting data, employing attack tactics, performing security tests and looking for more machines to attack. The results are generated in real-time, shown in a network map and also presented in 3 detailed reports. With the Monkey, red teams can autonomously test specific parts of the network with multiple attack scenarios on a regular basis - like executing a lateral movement scenario from an internet-facing server to a sensitive system deployed in a different part of the network. Further, the Monkey maps its findings to both the MITRE ATT&CK knowledgebase and Forrester’s Zero Trust framework to provide in-depth reports with actionable recommendations for achieving a stronger security posture. When mapping to the Zero Trust framework, the report identifies and prioritizes the steps and decisions required to achieve a true Zero Trust network - whether that’s verifying that the current security stack meets Zero trust requirements or outlining specific actions that blue teams can perform to implement better security measures. By mapping the reports to MITRE ATT&CK, the Monkey communicates the results of the attack in plain language, making the advanced tool accessible and effective for any red team. These reports enable security professionals to address and improve their security posture using the metrics, methods, and ideas they already care about aka if your CISO wants to achieve Zero Trust, their team can clearly map out the steps required to get there with the Monkey’s reports. In this talk, Penetration Testers, Network Engineers, Exploit Developers, and other Security professionals will experience a typical Breach & Attack simulation through the lens of the Monkey to learn how open source solutions can improve and add efficiencies to their teams. Shay will take attendees through a demo of Infection Monkey to demonstrate a typical “before and after” scenario with the Monkey. He will run the Monkey in a test environment, aka the “before,” to identify security gaps and then mitigate the issues using advice offered by the Monkey’s reporting. Finally, Shay will run the Monkey in the “after” environment to show how effective this Breach and Attack simulation can be in strengthening security posture.
 Hi, Defkhan. I'm Shai Nekhmand. Today, I'll present Infection Monkey, 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 subnetwork 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 Server servers. Multiple security products deployed on site, a CAFI move, an IDS on the network, and a 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 infection monkey? 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. They make sure 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 is managed by GuardiCorps 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. 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 plot 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 all 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 under 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 fishing, and so on, but at the end, he gets to the network and simulates an APT. On 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. So 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 Infection Monkey. The monkey is highly configurable, so it can feed 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 for your network by Forester, this is the first of its kind report card on where are you in your zero trust journey. And lastly, the MITRE attack report. If you're familiar with the MITRE attack 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 the penetration testing and be easy for the community. We have one flick 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 VM, 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 you'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, web organization, something happens in the databases, stuff like that. Malicious device, someone added a malicious machine, like a contractor maybe bringing his laptop to onsite 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 pasty 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 sock is responding correctly to an attack, and test whether the organization, where the organization stands in their zero trust journey or how much of the MITRE attack 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 visuals 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 attack framework, and that's how you like to use stuff, we mapped everything that the monkey does to the MITRE attack 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. 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. In this instance, I only wanted to run on the targets that I've defined, and I wanted to hop from the initial infection point three deep. I'm 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. 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 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 a 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 struts to exploiter, the shell shock 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 building 08-067 is an unsafe exploiter that might crash due to the fact that it uses buffer overflow. And we are 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 credential step, 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 at this time. 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. We just show how the agent communicated back to the command 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. Move to this server called tunneling-9. This is the tunneling, 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 on the monkey hopped on to this machine and was able to propagate to this machine, in this 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 and needed to report back to the command and control server what it has found. However, that's easier said than done. Obviously, 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 difference of network, 10.2.0. What we really had here is two hops between the monkey and the island. The monkeys helped themselves tunnel the communication back completely automatically. What we're seeing here is a very deep network test in the monkey, sort of bridging networks and showing how you can hop between different sub-networks in this test instance. Now we can hop onto 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. 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 user names 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 struts to 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 you can, on every issue here, you can read more and get more specific details, which services were used, which IP, 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 tunneling 11, 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 Struts 2-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-path parsers 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 Shellshock tells you 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 nine of them. What's the last 10%? Well, it's just a 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, you 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. The STRUT 24 machine listens on 8080 as well. You can also see which exploits were used on each machine. If you want vulnerability assessment summary, you can see that here. This machine was exploited using SMB, specifically credentials were stolen using Mimicons. You can see the post-reach actions that the monkey has performed. It performed 243 post-reach actions on seven 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 test for violation of principles was 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 elastic search 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 a boom 2. And this is the version. So as you can see the details, it is a pretty detailed report. You can also export the 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 GuardiCorps 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 the 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. So here in this instance, tunneling 10 was 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, these 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. Zero trust people mean zero trust users. In this case, the monkey tested whether users permissions to this network and to the resources inside your 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 test 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 infection monkey.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, that 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 is 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 attack report. This shows information about the mitre attack techniques that were used by infection monkey. 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 this allow attackers from doing command and control. We want them to be completely lost even if they managed 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 thought 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 was, did some persistence testing. It's important to know 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, we 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 exploitors 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 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 we report our findings there, and also giving you the option to run monkey from 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 Sneak.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 use 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 minor attack 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 free new 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 Defcon 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.guardicore.infectionMonkey. And just take a look at our homepage. Take a look at the articles. Thank you very much and enjoy the rest of Defcon safely. Wash your hands, keep your mask on, but since we're at home, we can ignore these for now. Thank you very much.
 Hi, Defkhan. I'm Shai Nekhmand. Today, I'll present Infection Monkey, 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 subnetwork 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 Server servers. Multiple security products  deployed on site, a CAFI move, an IDS on the network, and a 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 infection monkey? 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. They make sure 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 is managed by GuardiCorps 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. 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 plot 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 all 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 under 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 fishing,  and so on, but at the end, he gets to the network and simulates an APT. On 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.  So 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 Infection Monkey.  The monkey is highly configurable, so it can feed 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 for  your network by Forester, this is the first of its kind report card on where are you in your  zero trust journey. And lastly, the MITRE attack report. If you're familiar with the MITRE attack  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 the penetration testing and be easy  for the community. We have one flick 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 VM, 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 you'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, web  organization, something happens in the databases, stuff like that. Malicious device, someone added  a malicious machine, like a contractor maybe bringing his laptop to onsite 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 pasty 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 sock is  responding correctly to an attack, and test whether the organization, where the organization stands in  their zero trust journey or how much of the MITRE attack 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 visuals 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 attack framework, and that's how you like to use stuff, we mapped everything that  the monkey does to the MITRE attack 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. 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. In this instance, I only wanted  to run on the targets that I've defined, and I wanted to hop from the initial infection point  three deep. I'm 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. 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  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 a 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 struts to  exploiter, the shell shock 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 building 08-067  is an unsafe exploiter that might crash due to the fact that it uses buffer overflow. And we  are 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 credential step, 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 at this time. 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.  We just show how the agent communicated back to the command 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. Move to this server called tunneling-9. This is the tunneling,  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 on  the monkey hopped on to this machine and was able to propagate to this machine, in this 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 and needed to report back to the command and control  server what it has found. However, that's easier said than done. Obviously, 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 difference of network, 10.2.0. What we really  had here is two hops between the monkey and the island. The monkeys helped themselves tunnel the  communication back completely automatically. What we're seeing here is a very deep network test  in the monkey, sort of bridging networks and showing how you can hop between different sub-networks  in this test instance. Now we can hop onto 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. 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 user names 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 struts to 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 you can, on every issue here, you can read more and get more specific  details, which services were used, which IP, 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 tunneling 11, 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 Struts 2-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-path parsers 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 Shellshock  tells you 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  nine of them. What's the last 10%? Well, it's just a 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, you 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. The STRUT 24 machine  listens on 8080 as well. You can also see which exploits were used on each machine. If you want  vulnerability assessment summary, you can see that here. This machine was exploited using SMB,  specifically credentials were stolen using Mimicons. You can see the post-reach actions that the  monkey has performed. It performed 243 post-reach actions on seven 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 test for violation of principles  was 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  elastic search 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 a boom 2. And this is  the version. So as you can see the details, it is a pretty detailed report. You can also export  the 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 GuardiCorps 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 the 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.  So here in this instance, tunneling 10 was 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, these 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. Zero trust people mean zero trust  users. In this case, the monkey tested whether users permissions to this network and to the  resources inside your 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 test 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 infection monkey.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,  that 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 is 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 attack  report. This shows information about the mitre attack techniques that were used by infection monkey.  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 this allow  attackers from doing command and control. We want them to be completely lost even if they managed  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  thought 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 was, did some persistence testing. It's important to  know 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, we 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 exploitors 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 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 we report our  findings there, and also giving you the option to run monkey from 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 Sneak.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 use 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 minor attack 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 free new 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 Defcon 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.guardicore.infectionMonkey.  And just take a look at our homepage. Take a look at the articles.  Thank you very much and enjoy the rest of Defcon safely. Wash your hands, keep your mask on, but since we're at home, we can ignore these for now.  Thank you very much.
DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_0_503.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_504_731.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_732_2363.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_2364_2663.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_2664_4139.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_4140_5279.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_5280_5459.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_5460_8447.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_8448_8903.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_8904_10139.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_10140_17027.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_17028_18275.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_18276_23615.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_23616_24491.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_24492_26735.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_26736_30539.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_30540_30815.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_30816_30911.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_30912_36983.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_36984_37355.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_37356_37559.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_37560_37787.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_37788_40583.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_40584_46967.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_46968_47051.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_47052_47183.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_47184_47387.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_47388_52259.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_52260_55991.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_55992_57167.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_57168_57419.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_57420_58523.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_58524_59063.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_59064_60695.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_60696_60971.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_60972_61211.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_61212_61319.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_61320_61511.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_61512_61787.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_61788_62579.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_62580_63035.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_63036_63131.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_63132_64583.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_64584_64643.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_64644_64883.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_64884_65267.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_65268_65315.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_65316_65723.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_65724_66983.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_66984_67199.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_67200_67631.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_67632_76163.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_76164_76583.png DEF_CON_Safe_Mode_Red_Team_Village_-_Shay_Nehmad_-_A2FQNBwBwD8_76584_76951.png