the task for the Suricata skill assessment is about completing a rule for detecting WMI execution. I guessed the correct answer after 70 minutes, but I have no idea why it is correct or if I even understood the question.
The task: There is a file […], which contains network traffic related to WMI execution. Add yet another content keyword right after the msg part of the rule with sid 2024233 within the local.rules file so that an alert is triggered and enter the specified payload as your answer. Answer format: C____e
My interpretation: I need to find the right value for the additional content field. The answer is the value to which I set the new content field "content": "myanswer".
I first activated the unaltered rule with its two pre-existing content filter values and ran Suricata on the pcap. The problem is, the unchanged rule already created an alert for me, and inspection with Wireshark yields that this alert indeed flags the correct packet. So I was already stumped as to what I should do with that rule at all. As I said, after tinkering for 70 minutes I just guessed the answer. I then also tried it out by adding the relevant content filter to the rule, which resulted in the exact same alert(s) as before.
Is it possible for someone to explain to me how one should derive the correct answer without spoiling the task completely?
Hmm
Just try the following: Carefully review the task description and WMI discovery rules. Try to identify the key elements and symptoms associated with WMI execution to determine the correct answer. It may also be worth seeking help from more experienced users or teachers for further clarification or tips.
As I said, at the time I just guessed it. I replicated it again and my finding is still that the addition of the answer to the rule does not change Suricata’s output for this pcap in any way - the WMI Execution is detected with or without it.
Reading the assignment and the linked article again however, I at least now understand how one would arrive at the answer without much guessing. It has to do with how the process is launched.
I figured out the answer but using wireshark inspection using DCERPC protocol. WMI, Win32_ProcessStartup and powershell keywords are there in that packet. I still want to understand why my suricata process is not working.
I have the same question: I also just guessed the answer, I mean used some logic to make the guessing a bit easier, but still, the task seems to be made porly, I personally couldn’t prictise my rules writing skill with this one
That one was odd, it’s just common word you need to add here, starting with C and ends with e. I have no a clue what’s the difference with and without it.
Yep, same issue here. (Educatedly) guessed the correct answer based on the wording of the skills assessment, but don’t definitively know why it’s correct, and why it improves the rule at all.
Have requested the write-up from HTB support. If I get an answer that makes sense, I’ll edit my post here and hopefully provide some guidance.
Edit: I received and read the HTB solution write-up. Without posting the solution, it simply instructs students to become familiar with the linked reference (‘Attack description and possible detection points’) and deduce the answer given the clue: C___e. This is a keyword which you’d expect to also be in the packet details/bytes, based on the reference material’s description of the attack flow. However, you’ll find that the summary provided in the skills assessment page is also sufficient to deduce the answer.
The solution then goes ahead with modifying the local.rules file to add the above keyword, runs Suricata against the pcap, and shows that alerts appear in fast.log. Whilst completing these extra steps would probably test your understanding of Suricata better, none of this is actually necessary to pass the skills assessment.
As an observation, I personally don’t believe adding this content keyword into the rule affects the alerts generated against this specific dataset (i.e. pipkatposhc2.pcap). However, perhaps it refines the rule slightly, to avoid triggering against other datasets with false positive matches.
