$ cat blue-team.md --date 2025-02-27 --read 9 min
last modified 2025-02-27

Preparing for a Blue Team Competition

This past February, I began volunteering in WGU’s Cyber Club, which afforded the opportunity to participate in the 2025 NCAE Cybergames — a single-day, blue-team-oriented competition aimed at first-time competitors. This is one of my first experiences on a team-based defensive engagement like this. Our teams hadn’t yet competed but had been hard at work preparing.

The NCAE has its own YouTube playlist covering fundamental Linux skills — high-level, comprehensive, and lengthy. It’s a great introduction, but it doesn’t hint at the vast amount of other knowledge a team might want after watching.

With a background in software development, I’d call myself fairly capable at the terminal, but nothing truly prepared me for the open-endedness of all the potential skills a team could bring in. There’s an overwhelming number of approaches to take, which made it hard to land on any single “comprehensive” practice plan — so, alongside my own research, I sought the help of others. Here’s what they told me. This competition mostly uses Linux hosts, so I don’t give Windows-specific advice below.

Credits — thanks to w33t (w33t.io) and echotango for taking the time to offer their expertise.

Core Skills

0) Research / OSINT Skills

Knowing how to quickly and tactically prompt search engines and other tools gets you needed information fast — and knowing when to question the results matters just as much. This isn’t “formal” research, it’s the proverbial google-fu. When you don’t know something, be prepared to figure it out on the fly.

1) Conceptual Knowledge

Fundamental concepts and frameworks within networking and security. Without at least a surface-level understanding of these, it’s hard to communicate with teammates about specific elements of the engagement.

  • The TCP/IP model — the OSI model, while popular, isn’t how the internet actually works (ask John Strand).
  • Least privilege
  • System monitoring
  • Network monitoring

2) Linux Fundamentals

In a competition like this, you’ll feel dead in the water without rudimentary command-line knowledge. Ideally you’ll have some passing knowledge of the system as a whole. Roughly in priority order:

  1. Navigating the filesystem — cd, ls, cat, cp, mv, and a basic understanding of the Filesystem Hierarchy Standard.
  2. Bash — overall syntax, operators, stdout vs. stdin vs. stderr, input/output redirection, piping.
  3. Users and groups; sudo.
  4. Process management — ps, kill.
  5. Service configuration — systemctl, systemd (to a minimal extent).
  6. Networking and protocols — opening/closing ports, DNS configuration (the NCAE uses bind in its tutorials), routing.

3) Knowledge of Communication Protocols

Some of the Linux skills above require familiarity with widely used protocols. If you’re touching network configuration, you’ll need to understand what you’re working with — though a comprehensive knowledge of each protocol isn’t required, just enough to acquire the skills necessary to protect your environment.

  • Know these no matter what: TCP, UDP, IP (v4, and v6 if in scope), ICMP, SSH.
  • Know what these are, tailored to your role: DNS, FTP, SSL/TLS.
  • May not always apply, depends on the scenario: NFS, SMB, Syslog.

Gaining a Competitive Edge

This is a bare-bones list — dive deeper into each topic, ideally with direct advice from someone more experienced, if you want competitive results.

In the NCAE, teams get external network access and few restrictions on tools they import, as long as everything used is disclosed or already public. Don’t assume you can bring in any cutting-edge defensive solution, though — you rarely know the state of each endpoint. The NCAE’s practice environment uses Kali Linux 2021.1 as its attack box, a rolling distribution whose package repos will refuse to install onto such an out-of-date system anyway. That’s seemingly by design: the organizers want you to get creative, so much so that in cases like this they’ll downright force you to.

Realizing this, our teams started brainstorming, with more help from w33t and echotango. This is a growing list, in no particular order:

  • A shared cloud sandbox for practice — Digital Ocean + Terraform?
  • A list of IoCs to triage — which indicators of compromise carry the largest risk? netstat and ss are good for spotting some of them.
  • Pre-built scripts & configs — an Ansible playbook (run over SSH from a player’s own machine, for compatibility) to set up user accounts, groups, and least-privilege permissions; pre-built bash scripts for initial setup; a secure SSH config; a vulnerability-analysis script.
  • System & network monitoring — syslog for simple, compatible monitoring, ideally automated.
  • Deterrence — per-host firewalls (iptables/ufw) where available.
  • Operational security — unique, memorized passwords with a backup in case of compromise; a secure way to share them; SSH keys used with extreme caution on potentially vulnerable hosts; regular backups, or at least a SHA256 hash to verify integrity before trusting one.
  • Least privilege — tailor folder and file permissions to specific roles.
  • Monitoring processeslsof -i -n and lsof -p <pid> to find open backdoors, ls /proc and /proc/<pid>/cmdline to trace where a process was invoked, strings against a suspicious executable.
  • Common services worth knowing, even unmentioned by organizers — nginx, SQL/Postgres/Flask, certbot (dry-run first to avoid rate limits).

Roles and an engagement playbook were both still work-in-progress at the time of writing — delegating tasks (someone watching connections for intrusions, and so on), and a roughly ordered sequence of steps to run through on connecting to the environment: get spice-vdagent working for shared clipboard, get accounts provisioned fast, open external access through the router first, run the Ansible playbooks over SSH, inventory and vuln-scan every host, take manual rsync backups, remediate and harden, then stand up monitoring. Coordination is the constant: make sure your actions don’t conflict with a teammate’s.

Two general tips: with this many options, don’t consider too many at once — pick a tool to get experience with it, and move on if it isn’t working out. And the Black Team is usually there to help when needed.

Fin

That’s all I have for now, but I’ll keep updating as preparations continue. There’s much more I could cover in preparing for an event like this, but as is always the case in security, staying current means always learning. Security is never a guarantee — all you can do is build the best castle you can, repair your walls as needed, and hope your enemies don’t bring a trebuchet.

Go back to the index.

r3b1s@[redacted]$~/blog/blue-team.mdt hat  ? keys