Skip to main content
  1. Policy to Packets/
  2. Writeups/
  3. LetsDefend/
  4. Challenge/

(Writeup) LetsDefend Challenge - Brute Force Attacks

Table of Contents

Welcome
#

  • LetsDefend is a Blue Team Training platform.
  • This writeup documents a Medium-level challenge focused on analyzing HTTP, RDP, and SSH Brute Forcing through a PCAP and Linux auth.log.

Challenge Overview
#

Role Targeted: Incident Responder
Skill Level: Medium

Scenario
#

Our web server has been compromised, and it’s up to you to investigate the breach. Dive into the system, analyze logs, dissect network traffic, and uncover clues to identify the attacker and determine the extent of the damage. Are you up for the challenge?
File Location: /root/Desktop/ChallengeFile/BruteForce.7z
File Password: infected

Information
#

“There are two files included in the archive: BruteForce.pcap and auth.log.”


Question based Analysis
#

  1. What is the IP address of the server targeted by the attacker’s brute-force attack?
    • Opening the PCAP, the very top is four simultaneous connections from 192.168.190.137 to 51.116.96.181 on port 3389 which is the port for Windows RDP.
    • Answer: 51.116.96.181
  2. Which directory was targeted by the attacker’s brute-force attempt?
    • This one actually threw me for a loop, because I thought it was referencing rdp.client.dir at first. It wasn’t until I looked at the Protocol Hierarchy under the Statistics tab that I realized there was HTTP at the bottom of the PCAP. Easy to follow the HTTP streams and realize they are using the POST method with the attributes username and password on index.php.
    • Answer: index.php
  3. Identify the correct username and password combination used for login.
    • To find the successful connection, I filtered http and ip.src == 51.116.96.181 and !(data-text-lines contains "Incorrect") to only get http connections coming back from the server that isn’t “incorrect.”
    • We end up at packet number 22249 and by following the stream of this packet, we can get the answers we’re looking for.
    • Answer: web-hacker:admin12345
  4. How many user accounts did the attacker attempt to compromise via RDP brute-force?
    • Luckily because this capture is fairly small, we can just look by hand in Wireshark otherwise I’d be installing tshark.
    • If we filter by rdp.userName we get back a ton of ClientInfo[Malformed Packet] packets back.
    • Looking at the first packet, the password sent is: TestTest and I’m willing to bet the first attempt on each user is going to be TestTest.
    • Filtering on rdp.userName and rdp.password == "TestTest" gives us 10 packets with unique usernames…
    • But that isn’t the answer?? Maybe they meant to put “HTTP brute-force”?
    • Similar to our last filter, urlencoded-form.value == "TestTest" gives us a list of 7 packets with unique usernames.
    • Answer: 7 works.
  5. What is the “clientName” of the attacker’s machine?
    • Much easier than the last. Filter: rdp.client.name will give us only packets that contain the client name.
    • Answer: t3m0-virtual-ma
  6. When did the user last successfully log in via SSH, and who was it?
    • A quick grep -i 'accepted' auth.log gives us a list of successful ssh connections.
    • Answer: mmox:11:43:54
  7. How many unsuccessful SSH connection attempts were made by the attacker?
    • A quick grep -i 'failed password' auth.log | grep -vi 'repeated' | wc -l gives us the number of failed logins, without the meta “repeated” logs being counted.
    • That isn’t the answer? Do they want to count the meta information?
    • Just doing failed password' auth.log | wc -l gives us the answer they’re looking for…
    • Answer: 7480
  8. What technique is used to gain access?
    • A quick search on MITRE ATT&CK for “Brute Force” gives us the answer.
    • Answer: T1110
Reed Eggleston
Author
Reed Eggleston
B.S. in Cybersecurity | SSCP | CySA+ | PenTest+ | Project+