01
Short timeline
The team had roughly two and a half months to become operational before competition.
Cyber Defense Team Captain Journey
Building a CCDC team from scratch.
As Cyber Defense Team Captain, I rebuilt a CCDC-style training environment, organized weekly practice plans, created inject simulations, wrote technical playbooks, and prepared a mostly beginner team to compete under real pressure.
The challenge
A team could not be built with lectures alone.
CCDC is not just a technical exam. It is live infrastructure, business injects, service uptime, incident response, red-team pressure, documentation, and team communication all happening at the same time.
02
New competitors
Most teammates were first-time CCDC competitors, so the training had to start from fundamentals and move fast.
03
Realistic pressure
The preparation needed timers, injects, service failures, scoring, and attacker-style validation — not just theory.
1
Split training by experience level
Create separate schedules for newcomers and experienced students so beginners could build foundations while advanced members handled deeper operations.
2
Recreate the competition network
Rebuild VLANs, Palo Alto firewall behavior, servers, operating systems, and services so the team could practice in a familiar CCDC-like environment.
3
Build reusable playbooks
Turn practice discoveries into Linux, Windows, AD/DNS, Web, FTP, and incident-response checklists for current and future teams.
4
Automate repeatable hardening tasks
Prepare teammates to use practical scripts, checklists, snapshots, service setup steps, and verification workflows so they could move faster during practice.
5
Validate with attacks
After hardening, run pentest-style drills against hosts to test whether the team could detect and respond to reverse shells, rootkits, and service abuse.
Practice agenda
Weekly plans, now organized as expandable agenda tabs.
Each tab opens the actual agenda for that practice week: times, groups, focus areas, notes, and the operational purpose behind the session.
Oct
Oct 25 → Nov 1First week as captain: action plan and practice launch
In the first six days, I moved from being named captain to organizing interviews, drafting the action plan, assigning scarce lab access, launching a file-upload site, and running the first chaotic but successful practice.
+
Oct 25 → Nov 1First week as captain: action plan and practice launch
In the first six days, I moved from being named captain to organizing interviews, drafting the action plan, assigning scarce lab access, launching a file-upload site, and running the first chaotic but successful practice.
| Moment | What happened | Impact |
|---|---|---|
| Saturday · Oct 25 | I learned I would be captain and started shaping the action plan, including ideas later shared in ccdc-captain.pdf. | Turned the role into a concrete preparation strategy instead of waiting for practice day. |
| During the week | I interviewed interested teammates over Zoom to understand availability, motivation, and skill level. | Helped prioritize machine access and place people where they could contribute. |
| Practice day | Almost 30 students showed up for only 8 machines, so I organized groups of 3–4 and rotated access fairly. | Everyone experienced the competition chaos while staying focused on system enumeration. |
| Team leadership | Devya took command of reporting, and Kori emerged as the Linux lead helping others understand Linux. | Identified key leaders for reports and Linux operations early. |
| Infrastructure | I built a DigitalOcean upload site so teammates could submit files in one place. | Made collection and extraction of practice artifacts simple and centralized. |
The main objective was simple: get everyone exposed to CCDC-style pressure and teach them to start with enumeration. For six days as captain, that first week was a successful launch.
Nov
Week 2 as captainOrganization system, guest plan, and training infrastructure
After the first chaotic practice, I formalized the co-captain role, organized reports and Discord channels, planned expert guest sessions, created VM access through my own infrastructure, and turned the reports site into a searchable scoreboard/CTF-style system.
+
Week 2 as captainOrganization system, guest plan, and training infrastructure
After the first chaotic practice, I formalized the co-captain role, organized reports and Discord channels, planned expert guest sessions, created VM access through my own infrastructure, and turned the reports site into a searchable scoreboard/CTF-style system.
| Area | What changed | Why it mattered |
|---|---|---|
| Leadership | Formally named Devya as co-captain and organized the report workflow for the week. | Created ownership around reporting, submission, and team coordination. |
| Team structure | Created separate Discord channels for Linux and Windows. | Reduced noise and gave each group a clearer place to coordinate. |
| Guest agenda | Planned sessions with experienced professionals, including pentest and blue-team perspectives, past competitors, and possible HTB licenses. | Gave the team real-world context from both sides of the competition. |
| VM access | Because school-server access was not ready, I created VMs on my own server and exposed access through Cloudflare Tunnel. | Unblocked hands-on practice before official infrastructure was available. |
| Reports and scoring | Built the report-search site at scoreboard.4rji.com and later added a scoreboard/CTF-style layer. | Made injects easier to find and made performance measurable. |
| Practice space | Looked for a smaller room where the team could work better and secured the Cyber Center. | Improved focus and made in-person practice more effective. |
| Guest session | Hosted Travis, an Arctic Wolf engineer with CCDC experience. | His visit gave the team direction, motivation, and a clearer view of cyber defense careers. |
Cloudflare Tunnel reference used for the VM access approach: docs.4rji.com/cloudflaretunnel.
Nov
Nov 6 · 11:52 AMScoreboard site and scoring model launched
After discussing team-structure ideas, we moved to a scoring-based approach: each completed inject was worth 10 points, tracked through the scoreboard navigation site.
+
Nov 6 · 11:52 AMScoreboard site and scoring model launched
After discussing team-structure ideas, we moved to a scoring-based approach: each completed inject was worth 10 points, tracked through the scoreboard navigation site.
| Date | Decision | Implementation |
|---|---|---|
| November 6, 2025 · 11:52 AM | Use a scoring-based team structure to evaluate performance. | Each completed inject was worth 10 points. |
| November 6, 2025 | Make progress visible to the team. | Published the scoreboard navigation site at scoreboard.4rji.com. |
This was the start of turning practice into a measurable system instead of loose training sessions.
Nov
Nov 7 · 3:34 PMTemporary WireGuard VPN and FTP access path
When official VPN access was taking too long, I created a working WireGuard-based access path with FTP support so teammates could start connecting and practicing sooner.
+
Nov 7 · 3:34 PMTemporary WireGuard VPN and FTP access path
When official VPN access was taking too long, I created a working WireGuard-based access path with FTP support so teammates could start connecting and practicing sooner.
| Date | Problem | Action |
|---|---|---|
| November 7, 2025 · 3:34 PM | Official VPN access was delayed, which slowed down hands-on practice. | Created and shared a working WireGuard VPN access method. |
| Same day | The team still needed practical file/service access for training. | Added FTP support to make the temporary access path useful for practice workflows. |
Message shared with the team: “Everybody try this when you can. It’s the VPN access. It’s working for me.”
Nov
Nov 10 · 11:55 AMNextcloud access site published
I created and shared the Nextcloud access point so teammates could reach the file-sharing platform from inside their VMs or through the Cisco VPN.
+
Nov 10 · 11:55 AMNextcloud access site published
I created and shared the Nextcloud access point so teammates could reach the file-sharing platform from inside their VMs or through the Cisco VPN.
| Date | Access path | Details |
|---|---|---|
| November 10, 2025 · 11:55 AM | Inside VMs | Nextcloud available at 172.16.101.16 or 172.16.102.22, depending on the teammate’s subnet. |
| November 10, 2025 | Cisco VPN | When connected to the Cisco VPN, teammates could open 10.100.1.190 in the browser. |
| November 10, 2025 | Login URL | http://10.100.1.190/index.php/login |
This gave the team a shared platform for practice resources and mirrored the kind of service access they needed to understand during CCDC.
Nov
Week 3 · Nov 15Lab buildout, two-team structure, and first structured agenda
With the lab still limited, I split the team into Linux and Windows focus blocks, kept building the ESXi environment, and used the first clearer Saturday agenda to reduce chaos and improve progress.
+
Week 3 · Nov 15Lab buildout, two-team structure, and first structured agenda
With the lab still limited, I split the team into Linux and Windows focus blocks, kept building the ESXi environment, and used the first clearer Saturday agenda to reduce chaos and improve progress.
| Area | What happened | Impact |
|---|---|---|
| Lab status | The lab was still incomplete: VPN access existed, but VMs did not yet have internet, so work was possible but limited. | Forced a more focused plan instead of trying to help everyone at once. |
| Team structure | I split practice into two focus teams: dedicated Linux time and dedicated Windows time. | Reduced distractions and kept my attention from being pulled in every direction. |
| Infrastructure buildout | After waiting for ESXi/VPN permissions, I uploaded ISOs, waited for firewall images, and configured subnets, firewalls, IPs, VyOS routing, and topology details manually. | Moved the team closer to a functional competition-style lab. |
| Nextcloud | I installed Nextcloud on an external server and made it reachable from outside and inside the VMs. | Prepared the team for a service required in the competition. |
| Linux leadership | Kori taught Linux/scripts to teammates, and I slowed down behind him to explain the concepts. | Confirmed Kori as the Linux lead and helped beginners keep up. |
| Inject practice | Morgan showed how last year’s inject process worked while I observed reporting readiness. | Helped define how future inject hours should be structured. |
| Roster decisions | I started making difficult roster choices based on readiness, fundamentals, and role fit; Alex became the AD/DNS lead. | Shifted the team from open practice toward a competition-ready roster. |
Week 3 was the transition from “everyone is trying everything” to a more deliberate operating model: Linux lead, Windows focus, report workflow, lab buildout, and defined Saturday blocks.
| Time | Group | Focus |
|---|---|---|
| 1:00 PM – 4:00 PM | Linux Team | System hardening, kill chain checklist, firewall configuration. |
| 2:00 PM – 5:00 PM | Windows Team | AD/DNS, GPO, service auditing, patching checklist. |
| 2:00 PM – 4:00 PM | Cross-Team / Report Writer | Collaboration between Linux and Windows teams on injects, documentation, and scoring deliverables. |
Guest: Morgan joined around 2:00 PM to show how injects were handled the previous year. After the Linux block, the remaining time shifted into Windows work.
Nov
Week 4 · Nov 18–22Topology completion, scoring engine, and competition tooling
With the team taking shape, I pushed the lab toward a complete topology, improved VM and file access, expanded the scoreboard into service scoring, stabilized VPN access, and prepared scripts for the Saturday mini-competition.
+
Week 4 · Nov 18–22Topology completion, scoring engine, and competition tooling
With the team taking shape, I pushed the lab toward a complete topology, improved VM and file access, expanded the scoreboard into service scoring, stabilized VPN access, and prepared scripts for the Saturday mini-competition.
| Area | What happened | Impact |
|---|---|---|
| Topology | Finished the topology using Palo Alto for the machines and configured the remaining Cisco/firewall pieces when ownership stalled. | Moved the lab from partial infrastructure to something the team could actually practice against. |
| CCDC scoring research | Found source code related to how CCDC scoring works and planned a more accurate replica. | Shifted the practice scoreboard closer to real competition behavior. |
| VM navigation | Built and updated esxi.4rji.com with direct links to VM consoles/configuration and lab resources. | Saved time inside the ESXi client, where finding VMs was slow because there were no folders. |
| File portals | Created internal pages for collected Windows files and enumeration files at 10.100.1.190:9000 and 10.100.1.190:8080. | Made upload/download workflows simpler and kept collected artifacts organized. |
| Study direction | Asked the team to study Linux and Windows hardening books. | Focused learning on the fundamentals the team would need most during competition. |
| Injects and scoring | Updated scoreboard.4rji.com with injects and created a local port-monitoring scoring app. | Made service availability measurable: online services gained points; offline services changed color and stopped scoring. |
| BloodHound | Made BloodHound available through the Nextcloud/server resources at 10.100.1.196:8080/ui/login. | Gave teammates a way to learn AD attack-path analysis before competition. |
| VPN reliability | Implemented WireGuard with bounce servers because the Cisco VPN was unstable. | Provided a slower but functional backup path for the lab. |
| After-hours practice | Started evening practice sessions; Alex and Ty joined Discord while I configured Splunk with Kori and coordinated Derek’s demo VMs. | Turned preparation into continuous work instead of only Saturday sessions. |
| Scripts | Prepared kill-chain hardening scripts, plus redhavi and redhavi-check for the mini-competition. | Created a repeatable way to misconfigure systems, harden them, and verify fixes. |
Week 4 was the infrastructure-heavy week: the lab, access portals, file resources, scoring logic, VPN fallback, Splunk work, and scripts all moved closer to competition-ready.
Nov
Nov 20 · 11:15 AMESXi quick-access page and Kali test machines
I published a fast VM access page and added Kali machines inside each firewall network so teammates could run Nmap scans, test connectivity, and exercise scripts.
+
Nov 20 · 11:15 AMESXi quick-access page and Kali test machines
I published a fast VM access page and added Kali machines inside each firewall network so teammates could run Nmap scans, test connectivity, and exercise scripts.
| Date | Infrastructure | Purpose |
|---|---|---|
| November 20, 2025 · 11:15 AM | esxi.4rji.com | Quick access page for VMs. The first click prompts a server login; after that it sends teammates straight to the VMs. |
| November 20, 2025 | Kali machines in each firewall network | Used for Nmap scans, connectivity testing, script testing, and general network checks. |
This reduced friction: teammates could reach the lab faster and immediately test whether services, firewall paths, logging, and scripts were working.
Nov
Nov 22Hardening, mini-competition, and service testing
With the new agenda ready, Linux moved from hardening into services, the team ran a mini-competition, and Windows finalized user configuration and service testing.
+
Nov 22Hardening, mini-competition, and service testing
With the new agenda ready, Linux moved from hardening into services, the team ran a mini-competition, and Windows finalized user configuration and service testing.
| Time | Group | Focus |
|---|---|---|
| 12:00 PM – 4:00 PM | Linux Team | Finish basic Linux hardening; begin installing and bringing up essential services. |
| 1:45 PM – 2:00 PM | Linux Mini-Competition | Quick competition based on the Linux checklist. |
| 2:00 PM – 4:00 PM | Cross-Team / Report Writer | Collaboration between Linux and Windows teams; injects, documentation, and scoring. |
| 2:00 PM – 5:00 PM | Windows Team | Hardening; finalize user configuration; begin service testing. |
Last week Morgan collaborated with the team on injects; this Saturday Thomas joined.
Dec
Week 6 · Dec 6Full topology online, team identity, and service tasks
The lab finally came together: Cisco, Palo Alto, and VyOS were working, the team became “404 Not Found,” Will helped with catering, and the week focused on Windows services, certificates, logging, NTP, firewall rules, and Splunk/Wazuh routing.
+
Week 6 · Dec 6Full topology online, team identity, and service tasks
The lab finally came together: Cisco, Palo Alto, and VyOS were working, the team became “404 Not Found,” Will helped with catering, and the week focused on Windows services, certificates, logging, NTP, firewall rules, and Splunk/Wazuh routing.
| Area | What happened | Why it mattered |
|---|---|---|
| Access reminder | Kept using esxi.4rji.com for quick VM access, with Kali machines in each firewall network for Nmap, connectivity, Splunk, and script testing. | Reduced time wasted finding VMs and gave each network a test node. |
| Practice logistics | Will helped secure pizza, drinks, and catering for the team. | Made the longer in-person practice more sustainable for everyone. |
| Topology | The full topology finally worked: Cisco, Palo Alto, and VyOS were all functioning. | Marked the point where the lab could support more realistic practice. |
| Team identity | The team name became 404 Not Found. | Gave the group a shared identity going into deeper competition preparation. |
| Windows focus | The week leaned more toward Windows: configurations, certificates, HTTP/FTP, and AD/DNS planning. | Balanced the team’s preparation while Linux interest and availability were lower that week. |
| Assigned tasks | Scheduled work for logging, NTP, firewall rules, Splunk/Wazuh routing, GitHub executables, and snapshots. | Turned open-ended lab work into concrete responsibilities. |
| Task | Assignment | Target |
|---|---|---|
| Logging | Send Splunk and Wazuh logs to my Kali machine first for verification, then redirect Splunk logs to Splunk and Wazuh logs to Webmail. | Verify collection before final routing. |
| NTP | Send NTP traffic to the Kali machine first, then set the final NTP destination to Web Ecom. | Confirm timing/logging traffic before production-like routing. |
| Palo Alto | Create specific traffic rules: allow FTP, NTP, DNS for AD authentication; allow SSH only between our networks; block everything else. | Practice least-privilege firewall policy. |
| Splunk | Configure the Splunk machine, open needed ports for both networks, snapshot after hardening, then install Splunk. | Avoid repeated rebuilds and keep logging stable. |
Week 6 was less flashy but important: the topology finally worked, the team had a name, and the work shifted into service configuration, certificates, firewall rules, logging paths, NTP, and reliable snapshots.
| Time | Group | Focus |
|---|---|---|
| 12:00 PM – 4:00 PM | Linux Team | Kill Chain practice and hardening. |
| 1:00 PM – 1:20 PM | Pizza & drinks | Thanks to Will for helping secure catering. |
| 1:20 PM – 4:00 PM | Cross-Team / Report Writer | Collaboration between Linux and Windows teams; injects, documentation, and scoring. |
| 4:00 PM – 5:00 PM | Windows Team | Hardening; certs for HTTP and FTP; Domain DNS backup plan. |
Practice injects with a timer, refine scripting techniques, continue service testing, and keep validating the now-functional topology.
Dec
Final December weekScoring system finished and timed injects deployed
After the last meeting, the lab finally behaved closer to the real competition: basic inject times were improving, the scoring system worked, timer-based inject drops made practice more realistic, and Linux cleanup verification scripts gave the mini-competition measurable checks.
+
Final December weekScoring system finished and timed injects deployed
After the last meeting, the lab finally behaved closer to the real competition: basic inject times were improving, the scoring system worked, timer-based inject drops made practice more realistic, and Linux cleanup verification scripts gave the mini-competition measurable checks.
| Area | What happened | Why it mattered |
|---|---|---|
| Post-meeting review | By Dec 13, basic inject completion time was improving, but Windows still needed more automation for ClamAV like the Wazuh and Splunk work. | Showed progress while identifying the next speed bottleneck. |
| Realistic testing | Because the lab now worked more like the real competition, scripts could be tested against conditions that actually mattered. | Made automation more reliable and less theoretical. |
| Red team research | Shared the National CCDC 2025 red-team writeup as preparation material. | Helped the team understand how attackers think and what defenders should expect. |
| Linux verification | Created a Linux cleanup verification script for mini-competition checks. | Evaluated user audit, system accounts, cron spool, SSH keys, and PHP execution risk. |
| Scoring system | Finished the scoring system and continued working through FTD/public-network issues while Palo Alto remained functional. | Gave the team a working scoring baseline even while some applications/network pieces still needed polish. |
| Timed injects | Implemented timer-based inject deployment like the real competition. | Made practice more exciting, realistic, and closer to competition pressure. |
| Roster | Added Minh to Linux because other Linux members had been absent during finals and personal schedule conflicts. | Kept the Linux side moving despite availability issues. |
| Urgency | With only about four meetings left, the focus became speed, independence, and reducing reliance on captain-led next steps. | Shifted preparation from learning the environment to executing faster under pressure. |
Reference shared with the team: Red Teaming at National CCDC 2025.
Dec
Dec 20Flag drop and live inject website practice
All-team inject work with a defined arrival time and first-inject launch on the practice website.
+
Dec 20Flag drop and live inject website practice
All-team inject work with a defined arrival time and first-inject launch on the practice website.
| Time | Group | Focus |
|---|---|---|
| 1:00 PM | Linux & Windows Teams | Arrival time. |
| 1:00 PM | All | Pizza time. |
| 1:30 PM | All | Flag drop — first inject appears on the website. |
| 1:30 PM – 4:00 PM | All Teams | Working on injects. |
| 4:00 PM | All | Practice ends. |
Website used for the session: score.4rji.com.
Jan
Jan 2Timed injects and scripting refinement
Cross-team work focused on injects, documentation, scoring, and scripting technique improvements.
+
Jan 2Timed injects and scripting refinement
Cross-team work focused on injects, documentation, scoring, and scripting technique improvements.
| Time | Group | Focus |
|---|---|---|
| 12:00 PM – 4:00 PM | Cross-Team / Report Writer | Collaboration between Linux and Windows teams; injects, documentation, and scoring. |
| 12:30 PM | Injects | The first inject will start to come out. |
Same as last time: practice injects with a timer and refine scripting techniques. Moved to Friday because of the Malware Analysis Workshop event.
Jan
Jan 10Inject work and scripting where possible
A focused cross-team session for injects, scripting opportunities, and team coordination.
+
Jan 10Inject work and scripting where possible
A focused cross-team session for injects, scripting opportunities, and team coordination.
| Time | Group | Focus |
|---|---|---|
| 12:00 PM – 4:00 PM | Cross-Team | Working on injects, scripting if possible. |
| 1:00 PM | All | Pizza time. |
Jan
Jan 16–17Templates, scripts, machines, and inject day
Friday preparation for injects and templates, then Saturday machine setup and timed inject execution.
+
Jan 16–17Templates, scripts, machines, and inject day
Friday preparation for injects and templates, then Saturday machine setup and timed inject execution.
| Day | Time | Focus |
|---|---|---|
| Friday · Jan 16 | 5:30 PM – 8:30 PM | Prepare for injects, test scripts, prepare templates. |
| Saturday · Jan 17 | 12:00 PM – 1:00 PM | Prepare machines, finalize plan, set up screens and environment. |
| Saturday · Jan 17 | 1:00 PM | Pizza time. |
| Saturday · Jan 17 | 1:15 PM – 4:00 PM | Injects for the day. |
Logan and Alex joined to help with injects. Everyone was expected to come prepared with questions.
Jan
Jan 24Last Saturday: snapshots and first inject at noon
Final Saturday readiness session: get ready, snapshot systems, and start injects on time.
+
Jan 24Last Saturday: snapshots and first inject at noon
Final Saturday readiness session: get ready, snapshot systems, and start injects on time.
| Time | Group | Focus |
|---|---|---|
| 11:30 AM – 3:30 PM | Cross-Team / Report Writer | Get ready, snapshot, etc. |
| 12:00 PM | Injects | The first inject will start to come out. |
Since this was the last Saturday, everyone needed to arrive on time and be fully ready before the first inject.
Jan
Competition day
Jan 31Competition day
+
Competition day
Jan 31Competition day
Feb
Feb 7Review injects, plan next steps, and build ESXi VMs
Post-competition review and continued training through labs, SimLab, and ESXi VM creation.
+
Feb 7Review injects, plan next steps, and build ESXi VMs
Post-competition review and continued training through labs, SimLab, and ESXi VM creation.
| Time | Group | Focus |
|---|---|---|
| 12:00 PM – 1:00 PM | 3rd place Team | Review the injects. |
| 1:00 PM | 3rd place Team | Plan for the next weeks. |
| 1:30 PM – 4:00 PM | All | Practice labs and SimLab. |
| Cybercenter | Cybercenter | Cybercenter. |
VMs were being created on ESXi; teammates were encouraged to come early if they wanted to learn more.
Feb
Feb 14Cybercenter follow-up practice
A simple follow-up practice block to keep the team connected and working after the main competition push.
+
Feb 14Cybercenter follow-up practice
A simple follow-up practice block to keep the team connected and working after the main competition push.
| Time | Focus |
|---|---|
| 12:00 PM – 4:00 PM | See you at the Cybercenter. |
Training infrastructure
Web platforms built to make practice feel real.
I used web-based practice infrastructure to simulate inject delivery, scoring, and team navigation so practice sessions felt closer to the real event.
Inject simulation
A practice platform used to deliver competition-style injects and structure timed team responses.
Scoreboard navigation
A search/navigation layer for scoreboard access and inject lookup during practice operations.
Systems I organized
The environment was designed like a training ground, not a slideshow.
The goal was to give teammates a place where they could break things, recover services, document evidence, and understand the systems before competition day.
NET
Network recreation
- VLAN-based practice structure
- Palo Alto firewall familiarity
- Service routing and fallback planning
SRV
Server roles
- Linux services and BIND9 DNS
- Windows AD/DNS, IIS, FTP/FTPS
- NextCloud-style component practice
OPS
Operational workflow
- Evidence collection templates
- Checklists for hardening and review
- Timed inject and report-writing practice
Custom scripts
Automation for the work people forget under pressure.
I created internal scripts to reduce command fatigue, speed up server management, and help teammates avoid mistakes during practice and competition-style scenarios.
Access & SSH
Verification & scoring
DNS & time services
Hardening & deployment
Repository reference: github.com/4rji/ccdc_scripts
Outcome
The result was bigger than one scoreboard.
The project produced a prepared team, reusable infrastructure, operational playbooks, and a stronger path for future CCDC competitors.
On January 31, 2026, during the Minnesota State CCDC / IN-MN Qualifier, the team initially reached 2nd place — a direct signal that the practice environment, training strategy, and team coordination were working under real pressure.
Team pipeline
Evaluated about 30 candidates and selected the strongest 8-person competition team.
Reusable training infrastructure
Practice platforms, checklists, playbooks, and scripts can support future competition cycles.
Leadership under pressure
Coordinated technical decisions, people, inject responses, and service operations in a live adversarial environment.