Your lab systems are the core of your lab environment. They run the operating systems, software, and data that make your lab a realistic training environment. Snap Labs maintains a core set of system images which you can deploy into any new or existing lab environment to configure to your specific needs.
To add a new system to a deployed lab environment, select the Add System button under the Systems tab within your lab. From here, you'll need to provide a number of details.
First, select a Name, Hostname, and Image.
We provide a set of images covering several operating systems and versions. There is also a growing set of systems with pre-configured toolsets under the "Security Tools" category.
We also support bringing your own AWS images to the Snap Labs platform. You'll need the AMI ID of your image, and it will need to meet a few requirements:
- Shared with the AWS account hosting your Snap Labs infrastructure
- Located in the same region as your Snap Labs infrastructure
- Marketplace images are not supported
AMIs which have the
EnaSupport property set to true will be launched as t3 type instances; otherwise they will be t2 type.
After choosing your Name, Hostname, and Image, you'll need to select a System Type and Disk Size. System type has the biggest impact on the performance of your system, and also the biggest impact on its running cost. Currently, we support systems with 1 vCPU and 0.5 GiB RAM through 8 vCPU and 32 GiB RAM. We support disk sizes from 8GB - 10TB (though we highly recommend keeping your storage to a minimum, you can always increase this later).
Estimated Runtime Cost
We provide an estimated runtime cost based on your selections of System Type and Disk Size (GB) when adding a new system. This is calculated based on the hourly AWS cost of the Image and System Type, plus the static costs of the disk storage (monthly) converted to an hourly amount.
This is only an estimated hourly runtime cost, and your actual costs may vary.
Please monitor your AWS bill on a regular basis to avoid unexpected expenses.
Total running lab cost estimates are available in the Settings of your currently running lab, or the Template details of individual templates.
The next step is to choose which Subnet your system will be launched into. You can choose from any of your currently configured lab subnets. You may also choose a specific IP Address within this subnet. This is optional, and the IP address will be randomized if you leave this field blank (if you template this environment, future lab launches will preserve the original IP Address of the system).
You're now ready to Launch your system! The system will deploy in a Pending state, and will typically be in a Running state within a minute or two.
New System Credentials
For every lab deployed, the Snap Labs platform automatically generates an SSH key pair to use for Linux system connections. This key pair is available in the Settings tab of your lab environment, and will be automatically used for Console Sessions.
For Windows operating systems, AWS will dynamically generate an Administrator password for the system on launch. We automatically fetch this for use by Console Sessions, and make it available to you in cleartext in the Credentials settings of the system.
After a system has been launched into your lab environments, you can manage most properties of system directly through the Snap Labs dashboard. The edit system properties, first select the Edit icon for the system you'd like to modify.
There are four types of system properties you have control over:
Modify the System Name, Hostname, and Student Access. By default, newly launched systems are not accessible to users with the Student role. To allow Student users to access systems in your lab you must explicitly allow this by selecting the "Allow students to access this system" checkbox and saving your changes.
This section also shows system details including:
- Operating System
- Launch Date/Time
- Source (who launched the system)
Modify the System Type and Disk Size in this section of the system settings. You can only modify one attribute of the system specs at a time, and your system will become temporarily unavailable while the modifications take place. This section of the settings also shows the Estimated Running Cost of the system.
You cannot modify the primary network interface of an existing system. To change this attribute you must delete and relaunch the system.
However, you may add (or delete) a Secondary Network Interface which allows your system to access multiple subnets. This also means multiple sets of security rules will apply to this system.
Console Connection - This setting controls how you connect to the system when connecting via Console Session (browser). You may specify the connection protocol, username, domain, password, and port for this setting.
Credential Caching - You may also specify additional connections to be made at lab power on, or when deliberately running the Cache Creds functionality. Similar to Console Connection settings, you may choose the connection protocol, username, domain, password, and port for this setting. This is useful for facilitating specific escalation paths throughout your lab environment.
After making configuration changes or installing specific tools, you may want to save this configuration to deploy into other lab environments. On the Image tab within the system editing flow, you can specify an Image Name and Image Description, then Create Image. This will template the individual system and make it available as an option to deploy through the Add Systems list.
Sample Credential Caching Scenario
The most common use of the Credential Caching is to create RDP sessions on Windows hosts for Active Directory lateral movement and privilege escalation scenarios. To create an RDP session on a Windows host, perform the following steps:
- Ensure the user has access to RDP to the target machine. This can be accomplished easily through the "Remote Desktop Users" or "Administrators" local groups.
- Add the Credential Caching configuration to the target machine.
- Cache the credentials. The "Cache Creds" functionality can be invoked manually, and is also run automatically after a short delay on lab power on.
- Verify the RDP session started successfully by checking for processes running on the target machine as the appropriate user via Task Manager.
File Sharing - Enable this setting to control whether file sharing is possible through Console Sessions. This is a helpful control for allow access to licensed or proprietary software to guest users.
To delete a system, first select the Edit icon for the system you'd like to delete, then select Delete and Confirm your choice. Your system will be immediately removed from the Snap Labs dashboard.
To add an App to your lab environment, navigate to the Apps tab and select the Add Lab App button. You'll be presented with a view to input the following information about your app:
- Name: A display name for your app.
- Description: A brief description of the app.
- URL: The location of the app within your lab. This must start with "http(s)://" and use an IP address
- Student Access: Select whether students are allowed to access this app.
After adding the App, users can access it directly from their browser in the same way they access lab systems with Console Sessions.
Modifying & Deleting Apps
After an App has been created, Creators and Admins can modify any attributes of the App by selecting the Edit button and updating the relevant info. Apps can also be deleted from this view.
Updated about 1 month ago