Welcome to my write-up about the event #88 on letsdefend.io, a platform where you can respond to certain information security events as if you were working in a SOC. I really enjoy solving these challenges while learning about incident response and its methods.
Assigning the event
Well, our SIEM detected a potential malicous activity, which triggered the „Phishing URL Detected“ rule. I always start by structuring and storing the core information in my text editor in order to have a better overview and decrease the time accessing the data. This will kinda look like this:
Most incident response teams have the necessary steps to approach security events written down in so-called „playbooks“, describing each action to take. Letsdefend.io provides a playbook to solve the cases, too, so we will stick to the requested steps .
Step 1: Collection Data
Solving the first page of the playbook should be very easy, since we pointed out the core information in our text editor.
Step 2: Search Log
The second step wants us to investigate the correlating logs, so we switch into the log management of letsdefend.io. First of all, I searched for the source IP address, which is the host „MarkPRD“ (IP: 172.16.17.88).
In the first picture we see two HTTP requests from Mark’s device. Take care, I almost fell for the fact, that the first request was in August 2020, not April 2021. Be sure to double-check the date! Comparing the timestamps, I conclude that this request triggered our „Phishing rule“. As we see the raw log entry, we have the „proof“, that this URL was visited from Mark’s device. We copy these clues to our text editor. Searching the log for the destination address and the destination hostname did not gave any further results, so we can leave the logs for now. Let’s quickly check the MD5 hash of the parent process to make sure, it is not a fake explorer.exe.
Step 3: Analyze URL Address
I really like using virustotal.com for these kind of tasks, so let’s check this (weird looking) URL.
So this URL is flagged as „malicious“ once by Cyan and as „suspicious“ and „spam“ by three other vendors. That obviously does not look like a „safe“ URL to visit. Take your notes.
Step 4: Add artifacts
For the next step, let’s take a look at the actual mail. So we visit the „mailbox“ in the letsdefend.io-dashboard and check the timestamp. We find following mail:
There are many indicators you should not click on this URL, but Mark obviously did. Copy the data (sender, sender mail address, timestamp and text) to your text editor.
To gather all relevant data for our team and the report, we fill our artifacts we found during this investigation. The MD5 hash can be left out, but hey, we got what we got.
Step 5: Access
Since we found the proof of Mark (or someone else on his device) visited the malicious URL in the web log, we can select „Yes“ here.
Step 6: Finishing the case
Looking at our notes about this case, we can state, that the malicious URL from the phishing mail was visited by Mark’s device. So according to our policy (I guess) we have to contain his machine. This can be done in the „Endpoint Management“ section in the dashboard.
Now we can close the alert, deciding whether it was a true or a false positive.
Checking the result
Nice, we chose the correct answer to all actions in the playbook! 🙂 Make sure to share your success on twitter by clicking the button at the bottom! Let me know, if you want to see more letsdefend.io write-ups in the future!