Infection Monkey

Infection Monkey is a breach and attack simulation tool that tests your network’s security by acting like an actual attacker. Deploy the application on a machine inside your network, give it a starting point, and it begins probing systems looking for weaknesses, attempting to spread laterally, harvesting credentials it finds, and exploiting vulnerabilities it discovers. The simulation runs automatically until it either runs out of new targets or hits the boundaries you’ve defined, then produces detailed reports showing exactly how far an attacker could have gotten if this had been real.

The application doesn’t just tell you what could happen in theory. It shows you what actually did happen during the simulation, with complete maps of every system the attack reached and every technique that worked.

How the simulation actually works

The application’s central design treats your network the way a real attacker would. Drop an agent on a starting machine, and that agent begins reconnaissance. It scans network ranges to find other systems, attempts known exploits against discovered services, tries to authenticate using compromised or default credentials, and looks for sensitive data on accessible storage. When the agent succeeds at compromising another machine, it copies itself there and the new agent begins the same reconnaissance and exploitation cycle from the new vantage point.

This propagation pattern matches how actual breach incidents unfold. Attackers rarely hit their final target directly. They compromise an initial system through phishing, exposed services, or credential theft, then move laterally through the network until they reach the data or systems they actually want.

The simulation reproduces this lateral movement pattern, which means the resulting reports show you not just what individual systems are vulnerable but how those vulnerabilities chain together to produce real attack paths.

The Monkey Island server coordinates everything. Each agent reports back to the server with its discoveries, the techniques that worked, the techniques that failed, and the specific systems it managed to compromise. The server aggregates this information into a network map showing the full extent of the simulated breach, with timestamps and technique details for each successful action.

For incident response teams using the simulation to validate detection capabilities, this real-time visibility into what the agents are doing matches what defensive monitoring should be catching.

Exploit modules and known vulnerabilities

The exploit library covers vulnerabilities that real attackers actually use rather than focusing on theoretical edge cases. Log4Shell (CVE-2021-44228) is included, which matters substantially because the vulnerability affected most enterprise networks and verifying whether your patching actually closed all the exposed instances is more difficult than it sounds. The application attempts the exploit against discovered Log4j-using services and reports success or failure for each, providing the kind of comprehensive coverage check that manual testing struggles to achieve.

Other exploit modules cover EternalBlue (the SMB vulnerability behind WannaCry), ZeroLogon (the Netlogon authentication bypass), MS08-067 (the older but still occasionally exploitable RPC vulnerability), Hadoop YARN exposed APIs, Drupal and other web application vulnerabilities, SSH brute force with common credentials, and various others. The collection grows over time as new vulnerabilities emerge and become relevant to enterprise networks.

For organizations dealing with compliance requirements that include penetration testing, the exploit coverage produces evidence of what was tested and what the results were. The reports document each attempted exploit, each successful compromise, and the network paths the agents discovered, providing the kind of audit trail that compliance frameworks expect even when external penetration testers aren’t involved.

Credential collection and lateral movement

Beyond exploits, the application tests credential-based attacks that don’t require unpatched vulnerabilities. SSH brute force against discovered SSH services. SMB authentication using credentials harvested from compromised systems. Domain credential reuse patterns where credentials valid on one system unlock other systems across the network. WMI execution using captured authentication.

The credential harvesting works through Mimikatz-style techniques on compromised systems, extracting cached credentials, hashes, and tokens that subsequent agents can use for further movement. This matches how actual ransomware and APT groups operate, with credential theft being the primary mechanism for spreading through enterprise networks once initial access is established.

For users testing whether their network segmentation actually prevents the lateral movement it’s supposed to prevent, the agent-based approach produces realistic results. Configure agents in different network zones with different credentials, and the simulation shows you whether the boundaries between zones actually hold up against credential-based attacks.

Theoretical segmentation that sounds correct in policy documents often turns out to be incomplete in implementation, with this kind of simulation revealing the gaps.

Ransomware simulation

The ransomware simulation feature tests your defenses against the specific attack pattern that has dominated security incidents across recent years. The agents perform the file-touching behaviors that ransomware uses, modifying file contents in ways that resemble encryption without actually destroying data. This produces the file system activity patterns that endpoint detection should be catching, with the simulation revealing whether your protective tools actually catch them.

The activity stays safe by design. Files get modified in detectable ways, but the modifications can be reversed and the simulation doesn’t actually encrypt your data with keys that need to be recovered. The point is verifying detection rather than testing whether you can recover from real ransomware, which would require actual encryption that creates real risk.

For organizations that have invested in EDR (Endpoint Detection and Response) platforms, antivirus, file integrity monitoring, or SIEM-based detection rules, the ransomware simulation tests whether those investments actually catch the relevant activity. False confidence in detection capabilities is one of the central problems in security operations, and simulations like this expose gaps that defensive tools claimed to cover.

Reports tied to ZeroTrust and MITRE ATT&CK

The reporting system maps simulation results to security frameworks the industry actually uses. The Zero Trust report shows your simulation results organized around the seven Zero Trust principles defined by Forrester (people, workloads, devices, networks, automation, visibility, data), with the actual attack techniques mapped to which principles each one violates. For organizations pursuing Zero Trust architectures, this report shows where your current implementation has gaps that contradict the principles you’re working toward.

The MITRE ATT&CK report maps the simulation’s attack techniques to the corresponding tactics in the framework. Initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, command and control, exfiltration, impact.

Each technique used during simulation appears under its corresponding tactic with the specific results from your environment. For teams that have built their security operations around the framework, this mapping integrates simulation results into the same model used for threat intelligence and detection engineering.

The Security report provides the technical detail. Each agent’s path, the specific exploits attempted, the credentials harvested, the network connections made, the files accessed. For users investigating specific attack paths or trying to understand exactly what the simulation discovered, this raw detail beats summary reports that hide the underlying mechanics.

Network map and visualization

The network map view shows the simulation results visually rather than just textually. Compromised systems appear as nodes with connection lines to other systems they reached. Color coding distinguishes successful compromises from failed attempts. Hover over any node to see the techniques used against it, the credentials that worked, the data that was accessible.

For users explaining simulation results to non-technical stakeholders (executives, board members, auditors, business unit leaders), the visual map communicates what the simulation found in ways that text-heavy reports can’t match. A picture of compromised nodes spreading across the network produces more impact than a paragraph describing the same finding.

The map also helps technical users understand attack paths that aren’t obvious from individual incident details. Seeing how compromises chain together across the network reveals the structural weaknesses that enable the chains, which informs which defensive improvements would have the biggest impact.

Sometimes the right fix isn’t patching the entry point but eliminating the lateral movement path that turns the entry point into widespread compromise.

Configuration and target boundaries

The configuration interface controls what the simulation does and where it goes. Set network ranges the agents can scan. Configure credentials to attempt during brute force. Define exploit modules to enable or disable. Set termination conditions that stop the simulation after specific time limits or when reaching specific systems.

The target boundary configuration matters substantially for safe production network testing. Without clear boundaries, an aggressive simulation could spread beyond the intended scope into systems that weren’t supposed to be tested, which produces both technical and political problems. Properly configured boundaries keep the simulation contained while still providing useful coverage of the systems you actually want to test.

For users new to BAS testing, starting with very tight boundaries and gradually expanding them as confidence grows produces less risk than running comprehensive simulations from the first attempt. The application supports this incremental approach by letting you configure narrow tests focused on specific scenarios before expanding to broader coverage.

Cleanup and reversal

After the simulation completes, the agents need to be removed from the systems they compromised. The application includes automatic cleanup that uninstalls the agents and reverses any changes they made during the simulation. For tests where cleanup completes successfully, the affected systems return to their pre-simulation state without manual intervention.

The cleanup isn’t always perfect. Edge cases where agents crash or lose connectivity to the Monkey Island server before cleanup can leave artifacts behind. The reports highlight cleanup failures so you know which systems need manual attention, with the application providing tools to assist the manual cleanup when it’s necessary.

For production environments where leaving agent artifacts isn’t acceptable, the simulation should be followed by verification that cleanup actually completed across all affected systems. Most users find this verification straightforward, but the discipline of confirming cleanup matters more in regulated environments than in lab testing scenarios.

Considerations and limitations

The simulation tests known attack patterns rather than novel zero-day attacks. Real attackers occasionally use unknown techniques that the application’s exploit library doesn’t include. For comprehensive security validation, this kind of automated simulation complements but doesn’t replace skilled human penetration testing that can identify creative attack paths and exploit unusual configurations.

Running breach simulations on production networks carries real risk if not configured carefully. Aggressive simulations can produce performance impacts on tested systems, trigger security alerts that flood SOC teams with notifications, and occasionally produce unexpected behavior on systems with unusual configurations. Starting with constrained tests in non-production environments before moving to production reduces these risks substantially.

The setup complexity is real. The application isn’t a simple click-to-install tool that works without configuration. Users need to understand network segmentation, configure credentials, define target boundaries, and interpret results in the context of their specific environment. Organizations without security expertise on staff struggle to extract value from the application even when they install it successfully.

Some specific environments produce challenges. Modern Zero Trust architectures with extensive micro-segmentation, sophisticated EDR platforms with anti-tampering, and various other defensive technologies sometimes interfere with simulation operations. The interference is usually a sign that the defenses are working, but it can complicate getting useful simulation results when the defenses prevent the agents from operating effectively.

The reporting depth varies based on what the simulation actually found. Simulations against well-defended networks may produce reports showing very little successful compromise, which can be either good news (defenses worked) or misleading (the simulation didn’t discover the relevant attack paths). Interpreting null results requires understanding what the simulation actually attempted and whether the attempts were comprehensive enough to draw conclusions.

Conclusion

For security teams wanting realistic breach simulation that goes beyond vulnerability scanning without committing to commercial BAS platform subscriptions, Infection Monkey delivers serious capability through its open-source MIT licensing. The agent-based propagation model produces results that match how actual breaches unfold, the exploit library covers vulnerabilities that real attackers use, the credential harvesting and lateral movement testing reveals network segmentation gaps that policy reviews miss, and the reports tie findings directly to the security frameworks the industry actually uses.

The reasons to consider alternatives are mostly about specific organizational fit. Organizations with substantial security budgets and preferences for managed services find commercial BAS platforms producing smoother experiences with dedicated support.

Organizations without security expertise on staff struggle to configure and interpret simulations regardless of which tool they choose. Organizations wanting one-time deep penetration testing benefit more from skilled human testers than from automated simulation. But for the specific scenario of repeatable automated breach simulation in organizations with the technical expertise to configure it properly, this software remains one of the most capable options available, with active development from Akamai keeping it current with the threats actual networks face.