Security Monitoring & SIEM Fundamentals
SIEM Visualization Example 2: Failed Logon Attempts (Disabled Users)
Question 1: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Either create a new visualization or edit the “Failed logon attempts [Disabled user]” visualization, if it is available, so that it includes failed logon attempt data related to disabled users including the logon type. What is the logon type in the returned document?
Answer :
we need to add the login type in the table
then we just need to filter for failed logon attempt (event.code: 4625) and (winlog.event_data.SubStatus: 0xc0000072) that indicate the failure is due to a logon with disabled user.
Question 2: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Either create a new visualization or edit the “Failed logon attempts [Admin users only]” visualization, if it is available, so that it includes failed logon attempt data where the username field contains the keyword “admin” anywhere within it. What should you specify after user.name: in the KQL query?
Answer : just add the stars (*)
SIEM Visualization Example 3: Successful RDP Logon Related To Service Accounts
Question : Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Browse the visualization we created or the “RDP logon for service account” visualization, if it is available, and enter the IP of the machine that initiated the successful RDP logon using service account credentials as your answer.
Answer : After following the steps from the module.
add filters :
4624 — An account was successfully logged on
winlog.logon.type: RemoteInteractiv — logon type
add the following rows to the table :
host.hostname.keyword — represents the computer reporting the successful RDP logon attempt
related.ip.keyword— represents the IP of the computer initiating the successful RDP logon attempt.
we want to monitor successful RDP logons specifically related to service accounts, knowing that all service accounts of the environment start with svc-. So, to conclude our visualization we need to specify the following KQL query.
user.name: svc-*
SIEM Visualization Example 4: Users Added Or Removed From A Local Group (Within A Specific Timeframe)
first we need to filter for 4732 and 4733 events where the local group is the “Administrators” one.
Get Abdelhamid Houari’s stories in your inbox
Join Medium for free to get updates from this writer.
then add to the table the following rows :
- Which user was added to or removed from the group? (
winlog.event_data.MemberSid.keywordfield) - To which group was the addition or the removal performed? (double-checking that it is the “Administrators” one) (
group.name.keywordfield) - Was the user added to or removed from the group? (
event.action.keywordfield) - On which machine did the action occur? (
host.name.keywordfield)
finally as requested, we want to monitor user additions or removals from the local “Administrators” group within a specific timeframe (March 5th 2023 to date).
Question : Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Extend the visualization we created or the “User added or removed from a local group” visualization, if it is available, and enter the common date on which all returned events took place as your answer. Answer format: 20XX-0X-0X
Answer : March 5th 2023
Skills Assessment
Question 1: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “Failed logon attempts [All users]” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer:
Such a visualisation might reveal potential brute force attacks. It's important to identify any single user with numerous failed attempts or perhaps, various users connecting to (or from) the same endpoint device. However, the current data does not point towards any such scenario. One anomaly is noticeable though. It is related to the “sql-svc1” account.
So we just Consult with IT Operations no need for Escalating to a Tier 2/3 analyst and we can’t just say Nothing suspicious and pass it
Question 2: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “Failed logon attempts [Disabled user]” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer:
It seems that there is one incident where the user “Anni” has tried to authenticate, we need to Escalate to a Tier 2/3 analyst, this is a disabled user trying to authenticate we are talking about this should not be happen
Question 3: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “Failed logon attempts [Admin users only]” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer:
Nothing suspicious all events took place on either Privileged Access Workstations (PAWs) or Domain Controllers (DC).
Question 4: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “RDP logon for service account” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer:
we need to Escalate to a Tier 2/3 analyst because svc-sql1 is a service account and service accounts should never be used for RDP logons
Question 5: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “User added or removed from a local group” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer: we should Consult with IT Operations in case that the account was added by an admin if not the case will be Escalate to a Tier 2/3 analyst.
Question 6: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “Admin logon not from PAW” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer:
we should Consult with IT Operations because admins should exclusively utilize PAWs for server remote connections, which is a policy violation, but not necessary a sign of compromise.
Question 7: Navigate to http://[Target IP]:5601, click on the side navigation toggle, and click on “Dashboard”. Review the “SSH Logins” visualization of the “SOC-Alerts” dashboard. Choose one of the following as your answer: “Nothing suspicious”, “Consult with IT Operations”, “Escalate to a Tier 2/3 analyst”
Answer: we should Escalate to a Tier 2/3 analyst because we can see there is 6 failed ssh login attempts against the root account (highest-privilege account) this is a sign of brutforce or credential-guessing activity
