We covered cyber incident analysis with ELK Kibana or Elastic Search. We covered http logs pulled from a compromised Windows machine communicating with C2 server. This was part of TryHackMe ItsyBitsy.
TryHackMe ItsyBitsy Challenge Description
During normal SOC monitoring, Analyst John observed an alert on an IDS solution indicating a potential C2 communication from a user Browne from the HR department. A suspicious file was accessed containing a malicious pattern THM:{ ________ }. A week-long HTTP connection logs have been pulled to investigate. Due to limited resources, only the connection logs could be pulled out and are ingested into the connection_logs
index in Kibana.
ItsyBitsy: Incident Response with ELK
I tackled the “ItsyBitsy” TryHackMe challenge, which simulates an incident response scenario using the ELK stack (Elasticsearch, Logstash, Kibana).
The scenario was that John, a Security Operations Center (SOC) analyst, received an alert from an Intrusion Detection System (IDS). The alert suggested potential Command and Control (C2) communication originating from a user named Brown in the HR department. The suspicion was that Brown’s machine had been compromised and had accessed a malicious file containing a specific text pattern, which was the flag for the challenge. To investigate, a week’s worth of HTTP connection logs from the IDS had been pulled and ingested into Kibana under the index connection_logs
.
Investigation Steps in Kibana
My investigation began in Kibana’s “Discover” tab, where I could view the logs.
- Setting the Time Range: I first adjusted the time range to cover the entire month of March, from the 1st to the current recording time. This brought up 1482 events for analysis.
- Identifying the Suspect IP: The first task was to pinpoint the IP address associated with Brown. I examined the
source_ip
field. Interestingly, one IP address (ending in .52) generated 99% of the traffic, while another (ending in .54) only accounted for a mere 0.4% (two events). Counterintuitively, the IP with only two events (ending in .54) turned out to be the actual suspect. Filtering by this IP revealed communication over port 80 topastebin.com
. - Discovering the Malicious Activity: By scrutinizing the URL accessed by the suspect IP, I found
pastebin.com
followed by a specific path. Navigating to this URL directly revealed a file namedsecret.text
, which contained the elusive flag. Finding this immediately provided answers to most of the challenge questions. - Identifying the User Agent and Binary: I then revisited the logs without the IP filter and focused on the
user_agent
field. I noticed two distinct user agents: “Mozilla” and “bitsadmin.” Filtering by “bitsadmin” showed the same two suspicious events linked to the .54 IP. The presence of “bitsadmin” was a key indicator, as it revealed that a legitimate Windows binary,bitsadmin.exe
, was used to download the file, rather than a standard web browser. This answered the question about the binary used. - Answering Remaining Questions: Once those two suspicious events were identified, the rest of the questions became straightforward:
- The file-sharing site was
pastebin.com
. - The URL was the specific Pastebin link.
- The accessed file was
secret.text
. - The flag was the content of
secret.text
.
- The file-sharing site was
Room Answers
How many events were returned for the month of March 2022?
The user’s machine used a legit windows binary to download a file from the C2 server. What is the name of the binary?
The infected machine connected with a famous filesharing site in this period, which also acts as a C2 server used by the malware authors to communicate. What is the name of the filesharing site?
What is the full URL of the C2 to which the infected host is connected?
A file was accessed on the filesharing site. What is the name of the file accessed?
The file contains a secret code with the format THM{_____}.