Before submitting to the User-Generated Content (UGC) program, please be sure to review this FAQ in detail. All information regarding the expected details for your actual submission is covered here.

• How to Build a Vulnerable Virtual Machine
• Grouped and Chained Machines
• Automatically Declined Submissions
• Base System Requirements
• Difficulty and Flags
• Virtual Machine Deliverables
• Submission Archive
• AI Usage
• Walkthroughs
• Tracking Your Submission

How to Build a Vulnerable Virtual Machine

The basic premise of a vulnerable virtual machine is to host any vulnerable application, whether web or non-web, and create a scenario whereby the software, service and/or misconfiguration can be exploited. 

Skills learned on academic programs or through practical experience contribute heavily to the quality of your build.

Your concept process can be summed up with the following steps:

• Collect information regarding your proof of concept (PoC) build
• Build your virtual machine (VM) by installing the operating system and the vulnerable software, or creating misconfigurations which can be exploited by an attacker 
• Set the hostname of your VM
• Test your vulnerable software to confirm that the exploit chain is working
• Review your build and implement fixes where needed
• Add your local.txt and proof.txt flag files
• Add any required firewall rules
• Clean up leftover and old log files
• Clean up the Bash history for all users
• Create your walkthrough and all other required documentation
• Submit your machine concept for review, not a built VM

A build script must be created and included in your UGC submission, which allows OffSec to create your vulnerable machine or chain, if your concept is accepted.

When you submit through the UGC Creator Platform, your submission goes through automatic validation checks before it reaches a reviewer:

• Confirming that declared files are present in your uploaded archive
• Checking whether a referenced CVE is already covered on the platform

Make sure your build is complete and the contents of your archive match the information declared in your submission to help avoid unnecessary delays.

Grouped and Chained Machines

OffSec is accepting "Grouped" and "Chained" machine concepts.

Current Submission Acceptance Policy

Submissions are currently limited to the following lab types:

• Chained-host Offensive VM labs
• Grimoire labs
• Defensive VM labs
• Defensive CVE labs

Sample Submission Guidance

Where available, review the applicable sample submission template or package linked through the Creator Platform or related documentation before finalizing your submission.

Automatically Declined Submissions

Your submission may not contain any of the following:

• Hate speech or any forms of discrimination
• Plagiarized content
• Copyrighted content of any nature
• Adult/sexual/lewd content
• Profanity in passwords or applications

Base System Requirements

Please ensure your system does not exceed these maximum specs:

• 2 x CPU
• 2048MB RAM
• 20GB HDD

Difficulty and Flags

The difficulty of the target is a matter of the skill set of the attacker. Each submission must contain a method to determine the "success" of compromise via the use of flags.

• Direct-to-root box: one flag in /root/proof.txt
• Privilege escalation required: two flags — /home/lowprivuser/local.txt and /root/proof.txt

Difficulty selection in the Creator Platform

When submitting through the UGC Creator Platform, difficulty is set per proof or flag directly in the submission form. Points are automatically derived by the platform based on the difficulty you select, so you do not need to calculate or assign points manually.

Virtual Machine Deliverables

Your Virtual Machine submission should include at a bare minimum:

• Build script 
• Detailed build guide in Markdown 
• Walkthrough in Markdown and PDF formats
• MITRE map alignment

Docker Usage
We want to provide clear guidance on Docker usage in your submissions to avoid unnecessary delays or declines during review.

Docker is accepted under the following condition:

• Your submission includes a Docker escape or exploitation as part of the attack chain, ultimately leading the attacker to gain root privileges on the host machine. In this case, Docker is a meaningful and intentional part of the exploitation path.

Docker is not accepted in the following cases:

• The machine is built on Docker with no meaningful path forward or no Docker escape involved.
• Docker is used purely as a convenience for building or hosting the challenge with no relevance to the exploit chain.

We may make exceptions in cases where Docker usage is considered near-essential to the concept - this will be evaluated on a case-by-case basis during review. However, we strongly encourage submitting your submission without Docker, unless it is a core and intentional part of the exploitation path.

Submission Archive

This is one of the most important parts of your submission.

Archive Requirements

Your submission archive must contain all required documentation and supporting files for your lab. The archive must not be password protected. Accepted formats include .zip (recommended), .7z, .tar.gz, .rar, and .tar, with a maximum size of 10 GB.

Please ensure that the following items are included in your archive:

• autopwn 
• build guide 
• walkthrough
• artifacts 
• README
• Text file containing usernames and passwords for all accounts 

⚠️ Important: Do not include virtual machine files (.ova, .vmdk, .vmx, or other VM images) in your submission archive. Including these files significantly increases archive size and may cause submission failures.

Automated file checks 

The UGC Creator Platform automatically verifies that files declared in your submission are present in the uploaded archive by checking the file names. If the declared files and archive contents do not match, the submission may be flagged before it reaches a reviewer. Before submitting, confirm that all required files are included, file names match what you declared, and the correct archive has been uploaded.

AI Usage

The use of AI tools is permitted within this program; however, authors must exercise independent judgment and avoid over-reliance on AI-generated content. AI systems inherently follow predictable patterns, which can compromise the uniqueness and quality that is fundamental to the User-Generated Content (UGC) program.

Acceptable AI Usage

AI assistance is permitted in the following contexts:

• Generating or refining build scripts for an existing, independently conceived concept.
• Populating test data, including databases, user accounts, and web page content.
• Brainstorming and idea exploration during the initial concept sketching phase.

Note: Authors should exercise caution when using AI for ideation, as AI-generated suggestions tend to follow recognizable patterns that may reduce originality and thus reduce the likelihood of acceptance.

AI-Resistant (AI-R) requirement

All new UGC lab submissions must adhere to the AI-Resistant (AI-R) standard, with the exception of Defensive CVE labs. This means your lab should increase processing complexity, session length, and token costs for automated AI solvers without changing the intended difficulty for human learners. AI testing against a model is not required before submission. 

For complete requirements, refer to the Grimoire Build Guide and UGC Submission Expectations.

Non-Acceptable AI Usage

The following uses of AI are prohibited:

• Generating the walkthrough: Refer to the Walkthrough section below for detailed requirements.
• Generating passwords, tokens, or secrets: AI-generated secrets follow predictable patterns, resulting in values that are effectively identical across different submissions.

Examples of commonly observed AI-generated secrets include:

X-TOKEN: <value>

v3ct0rDB_r0cks!2024

xyz-api-k3y-1390yZq

/usr/local/bin/PLACEHOLDER-helper

/tmp/rootbash

• Selecting or deciding on vulnerabilities to incorporate: AI tools tend to gravitate toward a recurring set of vulnerability types, leading to repetitive and predictable challenge concepts. Commonly over-represented examples include: Basic SSTIs, Gitea, MQTT, SpEL Injection, GraphQL Introspection, Python Pickling, SSRFs, Tar Injection, PATH Poisoning, SUID Binaries, Cron Job Script Modification, SeBackupPrivilege.

Note: The above vulnerability classes are not inherently prohibited. The concern is that AI-generated concepts built around these techniques are frequently overly straightforward and lack the depth expected of original submissions.

Submissions that are determined to be predominantly or entirely AI-generated - with little to no original author contribution - are not acceptable under the UGC program. The following measures will be taken:

• First instance: Author will receive a formal warning and be asked to revise and resubmit.
• Second instance: The author will be suspended from submitting labs to the program for six (6) months.
• Third instance: The author will be permanently banned from participating in the UGC Program.

Walkthroughs

All walkthroughs must adhere to the following standards to ensure clarity, completeness, and verifiability.

Format Requirements

• Walkthroughs must be submitted in PDF format. 
• Screenshots must be included to illustrate the essential exploitation path, serving as proof that the concept has been built and is functioning correctly. 
• A screenshot is not required for every individual step; however, all critical steps must be visually documented.

Content Requirements

• All steps must be described clearly and in sufficient detail.
• Tokens, exploit code, and payloads must not be truncated or omitted.
• Any file paths or system-specific values required when crafting an exploit must be explicitly shown, including the method used to obtain them. 
• Command outputs must be included for each command in the walkthrough.
• Walkthroughs generated, drafted, or substantially written by AI are NOT permitted.

Exceptions to the above requirements may be considered on a case-by-case basis.

Tracking Your Submission

My Submissions 

After submitting your lab, go to Resources UGC My Submissions to track its progress. You will see the machine or lab name, submission date, and current status. 

Submission statuses include: 

• Approved - Your submission has passed review and has been accepted. Payment processing and deployment will follow according to the program timelines. 
• Rejected - Your submission did not meet the requirements or review criteria and will not move forward in its current form. Where possible, feedback may be provided. 
• Blocked - Your submission is temporarily stopped and requires changes before it can proceed. Review the UGC team feedback, make the requested changes, and resubmit so the review can continue.

Need faster support?

When submitting a support ticket, please include your Discord name and ID. This information is collected when you opt in as a UGC author, but including it in your support request can help the team identify your Creator Platform account and assist you more efficiently.