Incident Analysis with ELK Kibana | HTTP Logs Analysis | TryHackMe ItsyBitsy

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.

1. 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.
2. 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 to pastebin.com.
3. 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 named secret.text, which contained the elusive flag. Finding this immediately provided answers to most of the challenge questions.
4. 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.
5. 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.

Room Answers

Video Walkthrough