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
The next question ask what is the notBefore time(UTC) for this self-signed certificate? We can find this within the same packet we used to find the answer to question 6.
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.