First post of 2025. Only three months late, oops!
Blue Team activities don’t often get any CTFs. It’s a lot more fun to exploit some fun vulnerability and get root access than sort through countless logs.
However! I’ve been meaning to go back to the blue team focused tools. On the CTFs I’ve done I felt a lot more comfortable doing blue team things than I have with anything else. I’m still not sure what I want to specialize in, but analysis is my jam at the moment.
So I decided to jump back in to TryHackMe. I had a 100+ day streak, but life got in the way and I decided to leave it until I was ready to knuckle down.
Snort is a pretty popular FOSS tool. I’m not going to give an overview of the tool here. If you’re reading this blog, you most likely know what Snort is. I’ve wanted to pick it up and understand it for a while. It seems pretty popular and I know it’ll be a useful skill to have under my belt.
So let’s get into it!
The Challenge
I’ll be going through TryHackMe’s Snort Challenge - Live Attacks room. I’ve already completed the previous Snort challenge in the series.
You might’ve picked it up from the name, but this is the first room where we’ll be using snort against a live attack. The previous rooms have just had .pcap files to investigate, so this’ll be a bit different.
This challenge has two parts to it; A brute force attack, and a Reverse shell.
Scenario One - Brute Force
There’s a bit of a story to this challenge. The first part of this is written like a script. I won’t post it all here (try it out yourself!) but this last line made me laugh.
[+] J.A.V.A. Sir, you need to observe the traffic with Snort and identify the anomaly first. Then you can create a rule to stop the brute-force attack. GOOD LUCK!
That one line sums up pretty much the whole task. The flavor text is nice though.
First of all, start Snort in sniffer mode and try to figure out the attack source, service and port. Then, write an IPS rule and run Snort in IPS mode to stop the brute-force attack. Once you stop the attack properly, you will have the flag on the desktop! Here are a few points to remember: Create the rule and test it with “-A console” mode. Use “-A full” mode and the default log path to stop the attack. Write the correct rule and run the Snort in IPS “-A full” mode. Block the traffic at least for a minute and then the flag file will appear on your desktop.
Whenever I sit down and start any sort of hands-on exam I have an initial moment of freaking out and forgetting everything. This happened again here!
I took the first line ‘start Snort in sniffer mode and try to figure out the attack source’ very literally.
The first command I ran was simply; sudo snort -A console.
The output gave me pretty much nothing. Here’s a condensed version:
WARNING: No preprocessors configured for policy 0.
03/17-01:04:05.558856 10.10.245.36:46602 -> 10.10.140.29:22
TCP TTL:64 TOS:0x0 ID:49317 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x2060B7EB Ack: 0x2788DF14 Win: 0x1EB TcpLen: 32
TCP Options (3) => NOP NOP TS: 1884573899 4119681329
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
WARNING: No preprocessors configured for policy 0.
WARNING: No preprocessors configured for policy 0.
03/17-01:04:05.562517 10.100.1.238:56774 -> 10.10.206.76:80
TCP TTL:64 TOS:0x0 ID:47716 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x95430E85 Ack: 0x8730D54A Win: 0xD4D TcpLen: 32
TCP Options (3) => NOP NOP TS: 1995116991 3129098785
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
WARNING: No preprocessors configured for policy 0.
03/17-01:04:05.602573 10.100.1.238:56774 -> 10.10.206.76:80
TCP TTL:64 TOS:0x0 ID:47717 IpLen:20 DgmLen:68 DF
***AP*** Seq: 0x95430E85 Ack: 0x8730D54A Win: 0xDDD TcpLen: 32
TCP Options (3) => NOP NOP TS: 1995117031 3129098785
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
^C*** Caught Int-Signal
WARNING: No preprocessors configured for policy 0.
===============================================================================
Run time for packet processing was 20.26492 seconds
Snort processed 4209 packets.
Snort ran for 0 days 0 hours 0 minutes 20 seconds
Pkts/sec: 210
===============================================================================
Memory usage summary:
Total non-mmapped bytes (arena): 786432
Bytes in mapped regions (hblkhd): 12906496
Total allocated space (uordblks): 679312
Total free space (fordblks): 107120
Topmost releasable block (keepcost): 104416
===============================================================================
Packet I/O Totals:
Received: 4255
Analyzed: 4209 ( 98.919%)
Dropped: 0 ( 0.000%)
Filtered: 0 ( 0.000%)
Outstanding: 46 ( 1.081%)
Injected: 0
===============================================================================
Breakdown by protocol (includes rebuilt packets):
Eth: 4209 (100.000%)
VLAN: 0 ( 0.000%)
IP4: 4209 (100.000%)
Frag: 0 ( 0.000%)
ICMP: 0 ( 0.000%)
UDP: 0 ( 0.000%)
TCP: 3412 ( 81.064%)
IP6: 0 ( 0.000%)
IP6 Ext: 0 ( 0.000%)
IP6 Opts: 0 ( 0.000%)
Frag6: 0 ( 0.000%)
ICMP6: 0 ( 0.000%)
UDP6: 0 ( 0.000%)
TCP6: 0 ( 0.000%)
Teredo: 0 ( 0.000%)
ICMP-IP: 0 ( 0.000%)
IP4/IP4: 0 ( 0.000%)
IP4/IP6: 0 ( 0.000%)
IP6/IP4: 0 ( 0.000%)
IP6/IP6: 0 ( 0.000%)
GRE: 0 ( 0.000%)
GRE Eth: 0 ( 0.000%)
GRE VLAN: 0 ( 0.000%)
GRE IP4: 0 ( 0.000%)
GRE IP6: 0 ( 0.000%)
GRE IP6 Ext: 0 ( 0.000%)
GRE PPTP: 0 ( 0.000%)
GRE ARP: 0 ( 0.000%)
GRE IPX: 0 ( 0.000%)
GRE Loop: 0 ( 0.000%)
MPLS: 0 ( 0.000%)
ARP: 0 ( 0.000%)
IPX: 0 ( 0.000%)
Eth Loop: 0 ( 0.000%)
Eth Disc: 0 ( 0.000%)
IP4 Disc: 797 ( 18.936%)
IP6 Disc: 0 ( 0.000%)
TCP Disc: 0 ( 0.000%)
UDP Disc: 0 ( 0.000%)
ICMP Disc: 0 ( 0.000%)
All Discard: 797 ( 18.936%)
Other: 0 ( 0.000%)
Bad Chk Sum: 918 ( 21.810%)
Bad TTL: 0 ( 0.000%)
S5 G 1: 0 ( 0.000%)
S5 G 2: 0 ( 0.000%)
Total: 4209
===============================================================================
Snort exiting
4209 packets in 20 seconds is quite a lot!
Instead of -A console, I’ll just change it up to -A console -X so we can get a nice full packet hex detail. Unless I’m missing something obvious, there’s not much from the above output.
So I ran sudo snort -A full -X instead. I saw something that looked pretty interesting while the packets came streaming by:
03/17-01:16:10.440710 10.10.140.29:22 -> 10.10.245.36:46500
TCP TTL:64 TOS:0x0 ID:39780 IpLen:20 DgmLen:1108 DF
***AP*** Seq: 0x99A57D7B Ack: 0x4172780E Win: 0x1E3 TcpLen: 32
TCP Options (3) => NOP NOP TS: 4119659329 1884551896
0x0000: 02 67 7A 27 40 23 02 6D 84 B4 B4 1B 08 00 45 00 .gz'@#.m......E.
0x0010: 04 54 9B 64 40 00 40 06 05 EA 0A 0A 8C 1D 0A 0A .T.d@.@.........
0x0020: F5 24 00 16 B5 A4 99 A5 7D 7B 41 72 78 0E 80 18 .$......}{Arx...
0x0030: 01 E3 99 9C 00 00 01 01 08 0A F5 8D 03 41 70 53 .............ApS
0x0040: FA D8 00 00 04 1C 0A 14 D8 B6 62 6A BE DA 66 62 ..........bj..fb
0x0050: 72 D1 B8 48 D0 44 08 67 00 00 00 E6 63 75 72 76 r..H.D.g....curv
0x0060: 65 32 35 35 31 39 2D 73 68 61 32 35 36 2C 63 75 e25519-sha256,cu
0x0070: 72 76 65 32 35 35 31 39 2D 73 68 61 32 35 36 40 rve25519-sha256@
0x0080: 6C 69 62 73 73 68 2E 6F 72 67 2C 65 63 64 68 2D libssh.org,ecdh-
0x0090: 73 68 61 32 2D 6E 69 73 74 70 32 35 36 2C 65 63 sha2-nistp256,ec
0x00A0: 64 68 2D 73 68 61 32 2D 6E 69 73 74 70 33 38 34 dh-sha2-nistp384
0x00B0: 2C 65 63 64 68 2D 73 68 61 32 2D 6E 69 73 74 70 ,ecdh-sha2-nistp
0x00C0: 35 32 31 2C 64 69 66 66 69 65 2D 68 65 6C 6C 6D 521,diffie-hellm
0x00D0: 61 6E 2D 67 72 6F 75 70 2D 65 78 63 68 61 6E 67 an-group-exchang
0x00E0: 65 2D 73 68 61 32 35 36 2C 64 69 66 66 69 65 2D e-sha256,diffie-
0x00F0: 68 65 6C 6C 6D 61 6E 2D 67 72 6F 75 70 31 36 2D hellman-group16-
0x0100: 73 68 61 35 31 32 2C 64 69 66 66 69 65 2D 68 65 sha512,diffie-he
0x0110: 6C 6C 6D 61 6E 2D 67 72 6F 75 70 31 38 2D 73 68 llman-group18-sh
0x0120: 61 35 31 32 2C 64 69 66 66 69 65 2D 68 65 6C 6C a512,diffie-hell
0x0130: 6D 61 6E 2D 67 72 6F 75 70 31 34 2D 73 68 61 32 man-group14-sha2
0x0140: 35 36 00 00 00 41 72 73 61 2D 73 68 61 32 2D 35 56...Arsa-sha2-5
0x0150: 31 32 2C 72 73 61 2D 73 68 61 32 2D 32 35 36 2C 12,rsa-sha2-256,
0x0160: 73 73 68 2D 72 73 61 2C 65 63 64 73 61 2D 73 68 ssh-rsa,ecdsa-sh
0x0170: 61 32 2D 6E 69 73 74 70 32 35 36 2C 73 73 68 2D a2-nistp256,ssh-
0x0180: 65 64 32 35 35 31 39 00 00 00 6C 63 68 61 63 68 ed25519...lchach
0x0190: 61 32 30 2D 70 6F 6C 79 31 33 30 35 40 6F 70 65 a20-poly1305@ope
0x01A0: 6E 73 73 68 2E 63 6F 6D 2C 61 65 73 31 32 38 2D nssh.com,aes128-
0x01B0: 63 74 72 2C 61 65 73 31 39 32 2D 63 74 72 2C 61 ctr,aes192-ctr,a
0x01C0: 65 73 32 35 36 2D 63 74 72 2C 61 65 73 31 32 38 es256-ctr,aes128
0x01D0: 2D 67 63 6D 40 6F 70 65 6E 73 73 68 2E 63 6F 6D -gcm@openssh.com
0x01E0: 2C 61 65 73 32 35 36 2D 67 63 6D 40 6F 70 65 6E ,aes256-gcm@open
0x01F0: 73 73 68 2E 63 6F 6D 00 00 00 6C 63 68 61 63 68 ssh.com...lchach
0x0200: 61 32 30 2D 70 6F 6C 79 31 33 30 35 40 6F 70 65 a20-poly1305@ope
0x0210: 6E 73 73 68 2E 63 6F 6D 2C 61 65 73 31 32 38 2D nssh.com,aes128-
0x0220: 63 74 72 2C 61 65 73 31 39 32 2D 63 74 72 2C 61 ctr,aes192-ctr,a
0x0230: 65 73 32 35 36 2D 63 74 72 2C 61 65 73 31 32 38 es256-ctr,aes128
0x0240: 2D 67 63 6D 40 6F 70 65 6E 73 73 68 2E 63 6F 6D -gcm@openssh.com
0x0250: 2C 61 65 73 32 35 36 2D 67 63 6D 40 6F 70 65 6E ,aes256-gcm@open
0x0260: 73 73 68 2E 63 6F 6D 00 00 00 D5 75 6D 61 63 2D ssh.com....umac-
0x0270: 36 34 2D 65 74 6D 40 6F 70 65 6E 73 73 68 2E 63 64-etm@openssh.c
0x0280: 6F 6D 2C 75 6D 61 63 2D 31 32 38 2D 65 74 6D 40 om,umac-128-etm@
0x0290: 6F 70 65 6E 73 73 68 2E 63 6F 6D 2C 68 6D 61 63 openssh.com,hmac
0x02A0: 2D 73 68 61 32 2D 32 35 36 2D 65 74 6D 40 6F 70 -sha2-256-etm@op
0x02B0: 65 6E 73 73 68 2E 63 6F 6D 2C 68 6D 61 63 2D 73 enssh.com,hmac-s
0x02C0: 68 61 32 2D 35 31 32 2D 65 74 6D 40 6F 70 65 6E ha2-512-etm@open
0x02D0: 73 73 68 2E 63 6F 6D 2C 68 6D 61 63 2D 73 68 61 ssh.com,hmac-sha
0x02E0: 31 2D 65 74 6D 40 6F 70 65 6E 73 73 68 2E 63 6F 1-etm@openssh.co
0x02F0: 6D 2C 75 6D 61 63 2D 36 34 40 6F 70 65 6E 73 73 m,umac-64@openss
0x0300: 68 2E 63 6F 6D 2C 75 6D 61 63 2D 31 32 38 40 6F h.com,umac-128@o
0x0310: 70 65 6E 73 73 68 2E 63 6F 6D 2C 68 6D 61 63 2D penssh.com,hmac-
0x0320: 73 68 61 32 2D 32 35 36 2C 68 6D 61 63 2D 73 68 sha2-256,hmac-sh
0x0330: 61 32 2D 35 31 32 2C 68 6D 61 63 2D 73 68 61 31 a2-512,hmac-sha1
0x0340: 00 00 00 D5 75 6D 61 63 2D 36 34 2D 65 74 6D 40 ....umac-64-etm@
0x0350: 6F 70 65 6E 73 73 68 2E 63 6F 6D 2C 75 6D 61 63 openssh.com,umac
0x0360: 2D 31 32 38 2D 65 74 6D 40 6F 70 65 6E 73 73 68 -128-etm@openssh
0x0370: 2E 63 6F 6D 2C 68 6D 61 63 2D 73 68 61 32 2D 32 .com,hmac-sha2-2
0x0380: 35 36 2D 65 74 6D 40 6F 70 65 6E 73 73 68 2E 63 56-etm@openssh.c
0x0390: 6F 6D 2C 68 6D 61 63 2D 73 68 61 32 2D 35 31 32 om,hmac-sha2-512
0x03A0: 2D 65 74 6D 40 6F 70 65 6E 73 73 68 2E 63 6F 6D -etm@openssh.com
0x03B0: 2C 68 6D 61 63 2D 73 68 61 31 2D 65 74 6D 40 6F ,hmac-sha1-etm@o
0x03C0: 70 65 6E 73 73 68 2E 63 6F 6D 2C 75 6D 61 63 2D penssh.com,umac-
0x03D0: 36 34 40 6F 70 65 6E 73 73 68 2E 63 6F 6D 2C 75 64@openssh.com,u
0x03E0: 6D 61 63 2D 31 32 38 40 6F 70 65 6E 73 73 68 2E mac-128@openssh.
0x03F0: 63 6F 6D 2C 68 6D 61 63 2D 73 68 61 32 2D 32 35 com,hmac-sha2-25
0x0400: 36 2C 68 6D 61 63 2D 73 68 61 32 2D 35 31 32 2C 6,hmac-sha2-512,
0x0410: 68 6D 61 63 2D 73 68 61 31 00 00 00 15 6E 6F 6E hmac-sha1....non
0x0420: 65 2C 7A 6C 69 62 40 6F 70 65 6E 73 73 68 2E 63 e,zlib@openssh.c
0x0430: 6F 6D 00 00 00 15 6E 6F 6E 65 2C 7A 6C 69 62 40 om....none,zlib@
0x0440: 6F 70 65 6E 73 73 68 2E 63 6F 6D 00 00 00 00 00 openssh.com.....
0x0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0460: 00 00 ..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
This looks like it lines up with a brute force attack!
According to the question we need to figure out the ‘attack source, service and port’. Based on the above packet this is targeting SSH (port 22), and is originating from 10.10.245.36:46500.
Let’s whip up a quick snort rule for this ticket. The local.rules file in /etc/snort/rules/ is blank by default, so I’ll put this in there.
alert tcp 10.10.140.29 22 -> 10.10.245.36 46500 (msg: "Possible brute force attempt seen"; sid: 100001; rev:1;)
I’m not all that happy about this rule. It’s detecting solely off of the IP and port. These can be changed pretty easily, so looking at content or byte sizes and alerting off of a few things would be better, imo.
This writeup shouldn’t be taken as a tutorial or step-by-step for completing the challenge as fast as possible. This is more just a place for me to go through my process and document it. Don’t judge!
In fact, I got the alert wrong! I mixed up the direction flow. The rule should be:
alert tcp 10.10.245.36 46500 -> 10.10.140.29 22 (msg: "Possible brute force attempt seen"; sid: 100001; rev:1;)
I ran this for about a minute and the output showed 20 alerts had been generated. That’s good!
===============================================================================
Action Stats:
Alerts: 20 ( 0.348%)
Logged: 20 ( 0.348%)
Passed: 0 ( 0.000%)
Limits:
Match: 0
Queue: 0
Log: 0
Event: 0
Alert: 0
Verdicts:
Allow: 5750 ( 98.950%)
Block: 0 ( 0.000%)
Replace: 0 ( 0.000%)
Whitelist: 0 ( 0.000%)
Blacklist: 0 ( 0.000%)
Ignore: 0 ( 0.000%)
Retry: 0 ( 0.000%)
===============================================================================
That’s great, but… They were still allowed.
I checked my notes and couldn’t see why these weren’t being blocked. After a quick search I realized my mistake. It was pretty obvious once I knew what I had done wrong.
drop tcp 10.10.245.36 46500 -> 10.10.140.29 22 (msg: "Possible brute force attempt seen"; sid: 100001; rev:1;)
Instead of alert, we just need to make this a drop rule.
Oddly I don’t think this is covered at all in the previous snort rooms. It’s good to know now!
I needed to check previous rooms, but the above rule seems to work fine. After tinkering with the command to test the rule out I got it working.
sudo snort -c /etc/snort/rules/local.rules -A console -Q --daq afpacket -q -i eth0:eth1
03/17-01:48:04.664605 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:04.699616 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:04.699645 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:05.786550 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:05.935104 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:06.332060 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:06.861454 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:06.881773 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:06.941571 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
03/17-01:48:07.001806 [Drop] [**] [1:100001:1] Possible brute force attempt seen [**] [Priority: 0] {TCP} 10.10.245.36:46500 -> 10.10.140.29:22
Awesome.
This was all just to test the rule.
This didn’t work.
I kept trying this again and again, changing small things in how I was running this for a while. I eventually sat back and decided to rethink it.
It turns out I was right earlier, this was a bad way of doing it. I already know that the brute force attempts are targeting SSH, so we can just block that. There’s no need to mess around with the IP. We can even just block any SSH attempts:
drop tcp any 22 <> any any (msg: "Possible brute force attempt seen"; sid: 100001; rev:1;)
After running this, I received the flag. Go me!
Scenario Two - Reverse-Shell
This time we’re going after outbound traffic. The story for this scenario assumes that the dwell time for an attack is 1-3 months, and we have just arrived on the scene.
Like before I started off by running sudo snort -A console -X. Just to see what’s going on.
One packet immediately jumped out to me:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
WARNING: No preprocessors configured for policy 0.
03/17-02:09:42.779442 10.10.196.55:54124 -> 10.10.144.156:4444
TCP TTL:64 TOS:0x0 ID:9999 IpLen:20 DgmLen:136 DF
***AP*** Seq: 0xB3F98B5C Ack: 0xF6F1290C Win: 0x1EB TcpLen: 32
TCP Options (3) => NOP NOP TS: 2358270806 1980438505
0x0000: 02 15 8B 5C 4F EF 02 7C 9A 93 DF DD 08 00 45 00 ...\O..|......E.
0x0010: 00 88 27 0F 40 00 40 06 AA 79 0A 0A C4 37 0A 0A ..'.@.@..y...7..
0x0020: 90 9C D3 6C 11 5C B3 F9 8B 5C F6 F1 29 0C 80 18 ...l.\...\..)...
0x0030: 01 EB 72 C5 00 00 01 01 08 0A 8C 90 5B 56 76 0B ..r.........[Vv.
0x0040: 17 E9 0A 0A 1B 5D 30 3B 75 62 75 6E 74 75 40 69 .....]0;ubuntu@i
0x0050: 70 2D 31 30 2D 31 30 2D 31 39 36 2D 35 35 3A 20 p-10-10-196-55:
0x0060: 7E 07 1B 5B 30 31 3B 33 32 6D 75 62 75 6E 74 75 ~..[01;32mubuntu
0x0070: 40 69 70 2D 31 30 2D 31 30 2D 31 39 36 2D 35 35 @ip-10-10-196-55
0x0080: 1B 5B 30 30 6D 3A 1B 5B 30 31 3B 33 34 6D 7E 1B .[00m:.[01;34m~.
0x0090: 5B 30 30 6D 24 20 [00m$
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The specific port number caught my eye to begin with. I couldn’t find anything outright malicious in the other packets, but this looked like what we were after!
I decided to write a rule that would specifically drop any packets with a destination port of 4444. No need to overcomplicate it.
drop any any <> any 4444 (msg: "Reverse shell detected! Gadzooks!"; sid: 100001; rev: 1;)
Simple and to the point. And that’s all we needed for the flag!
Conclusion
That was fun.
This was just a small post to go through my process. I need to stop worrying about being so specific with some of these CTFs and just throw out rules that will do the job.
We might’ve blocked all SSH attempts, but we still stopped the brute force attempt! That’s a win… I guess.
I’m going to start writing a few more blog posts for the smaller rooms and challenges I do. Writing these posts is fun, and I need to have an excuse to keep my TryHackMe streak up.
More to come soon!