CDC FAQs and Known Issues

This page is a collection of commonly asked questions and known issues with the environment.

FAQ

The Users document says some passwords are “Team-Specific”; where do I get those?

You can find your Team-Specific passwords (and other information) in IScorE on your dashboard. The Team-Specific info is listed in the “Team Info” section. Simply hover over the black box to see the password. More details can be found in the IScorE Documentation.

Why can’t I log in to the VMs with a scenario user’s credentials?

White Team does not typically add the scenario users to your VMs before giving them to you. You will need to use the default credentials to access the VMs. You will never be able to log in to the scenario VMs with your ISEAGE credentials.

Important

Make sure you add the users listed in the scenario with their appropriate level of access to your systems before the start of the attack phase. The service scanner and Green Team will use these users to check your systems.

What are the default credentials for the scenario VMs?

The default credentials for Scenario VMs is almost always some combination of the username root, cdc, or Administrator with the password cdc. These credentials and any exceptions are explicitly listed in the Scenario for each box.

The provided passwords are weak. Can I change them?

No, you may not change provided passwords (with exception of password resets for Team-Specific passwords; you may request a password reset from White Team if you have evidence that passwords have been compromised during the Attack Phase).

The reasoning behind this is threefold: keep in mind that in the real world, attackers have a lot more than 8 hours to try and crack passwords, and limiting their complexity increases the feasibility of cracking them during the attack phase, if hashes are recovered. Additionally, while password complexity requirements can be set, users will almost always try to circumvent them, and will likely choose insecure passwords regardless of the requirements. Lastly, in many scenarios, it is expected that low-privileged users will have their passwords compromised. In the real world, users may have their passwords phished or even may attempt to use their access maliciously. It is up to you to ensure that these users have their access restricted appropriately such that this type of breach doesn’t result in a compromise.

Can I remove this user/application/service/file from our server(s)?

If a user or service is not explicitly required by the scenario, it can typically be removed. That said, there are often many moving parts in the scenario, and you may risk accidentally breaking required functionality by removing a dependency of something. It is on you to ensure that the changes you make are in line with the scenario requirements and that you have backups in case you break something.