Another Blue Team CTF, yay!
I’ve been studying hard on TryHackMe lately. Gamifying learning is always going to draw me in better than being handed some documentation.
As soon as I saw the name of this room I was excited. I use Sentinel every day, this should be easy!
Link to the room found here!
Task 1
This is the first time I’ve seen an Azure/Sentinel instance deployed specifically for a TryHackMe room. It’s great to see this! Sentinel is a pretty widely used SIEM, and any sorts of hands on experience is good to see.
Task One just asks us to launch the lab instance. You’re given some genuine Azure creds and just need to log in.
Once logged in we can search for ‘Resource Groups’ to confirm that the lab is being set up properly. Once we see the resource group we can move on to the next task.
Easy start!
Task 2
Now that the resource group has been set up, we can deploy the logs for us to look through.
We can check on the deployment status by going back into Azure and checking the previously mentioned Resource Group -> Settings -> Deployments
It took my lab 2 minutes and 41 seconds to deploy everything. Once that was done we could move on to the questions!
Question 1:
What’s the row count for SigninLogs_CL table?
This one is pretty easy if you’ve used Sentinel/Azure before. If not then don’t worry.
The room has a pretty cheeky line;
You know where to find log tables, right? Of course you do.
I mean… Not everyone will. It would’ve been nice to give some guidance for anyone who hasn’t used Azure before. When I first completed this room I did it a very different way to the screenshots included in the task. Instead of checking the ‘Log Analytics workspace’ I just went straight to Sentinel.
I’m a lot more comfortable querying logs like this, so this is how I answered all the questions.
After opening Sentinel, click on ‘Logs’, expand the tables, and query the ‘SigninLogs_CL’ table:
The answer is at the bottom right, it can be pretty easy to miss (and there’s probably a better way to query this).
Question 2:
What’s the row count for AuditLogs_CL table?
This is almost the same as the above question. Instead of querying SigninLogs_CL we can just swap this out for AuditLogs_CL.
Question 3:
Key combination for running KQL queries in Query Editor? _____ + Enter
I knew this one! If you’ve ever used Sentinel and like using keyboard shortcuts, then you’ll likely know this too.
When in doubt just search it up. You can also hover over the ‘run’ button to see the shortcut. Neat!
Task 3
Time to launch some Analytic rules! These rules are what drive Sentinel as a SIEM. I love writing KQL rules, so seeing these made me excited for any future rooms that go a little deeper into KQL rule writing.
Anyway, onto the task.
Back on TryHackMe we need to deply the analytic rules. This is pretty easy:
We can check on the analytic rules by going to Sentinel -> Configuration -> Analytics
Originally I had some issues with these not running properly. The task mentions that editing and immediately saving the rule will cause them to relaunch. The option to edit rules is weirdly hidden, so see my screenshot below if you’re having issues:
Question time
Question 1:
MITRE ATT&CK sub-technique for rule: Account Created and Deleted in Short Timeframe
From the Analytics page we can see this. Just expand the ‘Account Created and Deleted in Short Timeframe’ rule, then further expand the ‘MITRE ATT&CK’ heading:
Question 2:
Rule frequency (in hrs) for rule: Attempts to sign in to disabled accounts
Like with the above question just check the details pane for the ‘Attempts to sign in to disabled accounts’ rule. Scroll down to the ‘Rule frequency’ option, there’s the answer!
Question 3:
ResultType filter in rule: Explicit MFA Deny
We can take a look at the KQL now. We can do this from the same page. Just click on the ‘Explicit MFA Deny’ alert and check out the ResultType being filtered for in the KQL:
Question 4:
AppDisplayName filter in rule: Brute force attack against Azure Portal
This is a similar question to the above. We can view the KQL for this rule and see what is being filtered for. You may need to scroll down a little, or try a Ctrl + F for ‘AppDisplayName’:
Question 5:
Category filter in rule: Privileged Role Assigned Outside PIM
Checking on the ‘Privileged Role Assigned Outside PIM’ KQL we can find this too. The category filter is right up the top of the KQL.
And that’s task two done. If you’ve used Sentinel before then it should have been pretty easy. If it’s your first time then I hope the screenshots I’ve provided have helped.
Onto analyzing some incidents!
Incident #1: Account Created and Deleted in a Short Timeframe
Let’s look at the incidents, go to Sentinel -> Threat Management -> Incidents to see the incidents generated by the analytic rules we checked in the above task.
There’s not much else to do here other than dive into the incident for this task (Account Created and Deleted in a Short Timeframe), let’s go!
I mentioned this above, but I had to ‘Edit’ and save all the analytic rules again for the incidents to generate.
Question 1:
How many accounts were created and deleted in a short time frame?
With any incident I like to open the whole incident page. Clicking on the incident, then on the blue ‘View full details’ button will open the incident fully in a new page.
For this question we can look at the ‘Entities’ pane, which shows answer. Just count the accounts!
Question 2:
Which entity deleted these accounts?
Under the ’evidence’ heading we can click on the events. This will run some KQL and give you the events, reviewing the KQL output will give us the displayName of the entity that initiated the deletion:
Question 3:
Tactic for this incident?
Look on the incident overview pane on the left. If you scroll down under Entities you’ll see the ‘Tactics and techniques’ field.
Question 4:
Workflow Id involved in this incident?
The answer for this question is back in the KQL, expand the ‘Deletion_AdditionalDetails’ field and copy the workflow ID. It can be a bit hard to find so check the screenshot below:
Question 5:
UPNSuffix
This one is in the KQL as well, it’s a pretty easy field to spot!
Incident #2: Attempts to sign in to Disabled Accounts
This incident focuses on the ‘Attempts to sign in to Disabled Accounts’ incident.
Once again I suggest opening the full incident details to properly answer these questions.
Question 1:
What’s the IP Address involved in this incident?
Under the Entities pane, click on the IP address. The insights on the right hand side will provide further information for the following questions.
Question 2:
IP Geolocation (City)
In the insights pane, scroll or look around for it. It’s not too hard to spot!
Question 3:
Disabled account?
THe disabled account is the only other object in the Entities pane. No need to defang your answer.
Question 4:
ResultType filter in rule?
We need to view the rule for this. The easiest way (That I’ve found) has been to open the events, and read through the KQL. The filter is near the top of the rule. You shouldn’t need to scroll down.
Incident #3: Explicit MFA Deny
MFA deny time. These incidents are pretty fun to investigate.
Question 1:
Tactic for this incident?
Scrolling down on the incident overview shows this under the ‘Tactics and techniques’ field.
Question 2:
How about its technique?
Expand the Tactic, then we can see the technique.
Question 3:
What’s the error code when MFA is denied?
Open up the Events and view the KQL, the error code is the ResultType that’s being filtered for.
Question 4:
What’s the name of the Access Policy that triggered this MFA during authentication?
There’s a field in the KQL called ConditionalAccessPolicies_s, expand this. The Access Policy is shown under the displayName field.
Question 5:
Which authentication method was used for this MFA?
In the KQL expand the MfaDetail_s field. The authMethod value is the answer here.
Question 6:
Browser version of the device initiated this authentication?
Scroll down in the KQL again. The browser version can be found in the UserAgent_s field. You don’t need the full user agent, just the version at the end of the string.
Question 7:
How many entities are mapped in this incident?
This question felt a bit different to the rest. Just count the entities!
Incident #4: Privileged Role Assigned Outside PIM
The last incident we need to look into. Checking the KQL and being comfortable reading is pretty important for using Sentinel. You can parse a lot of the data when you create rules, but for this room you need to understand the questions, then find the data.
Question 1:
Which UPN escalated Marcus’ privileges?
The KQL gives the InitiatingUserPrincipalName column here, which shows the answer. It’s always nice when we don’t need to parse out the answer.
Question 2:
Which privileged role has been assigned to Marcus?
Expand the event targeting Marcus’ account. Under the first TargetResources_s field (Number 0) expand the modifiedProperties. The newValue of the Role.DisplayName is your answer:
Question 3:
In which source table has this privilege escalation been logged?
The Type field in the alert gives this answer. It’s one of the tables we looked at in a previous task!
Question 4:
Which other user has been a target?
We can check the KQL under the TargetUserPrincipal field. There are only two entities here, one is Marcus’ account, the other is the answer.
Question 5:
What’s the initiating IP Address?
The KQL gives us a InitiatingIpAddress field. The correct IP is the one for Marcus’ account.
And that’s the room done!
Conclusion
I liked this room a lot! I felt at home answering some Sentinel incident questions. I was surprised to see Azure tenants were being deployed on the fly for rooms and I’d love to see more rooms going deeper into KQL. Writing analytic rules and debugging broken ones could be fun.
TryHackMe have just come out with their SAL1 certificate, so It would be nice if they had some SIEM/Vendor specific certs, or just a pathway for the SC-200/400/900/Whatever number.
Anyway. Fun room! I can’t wait to see more.