Security Monitoring & SIEM Fundamentals

The capacity to accurately pinpoint high-risk events is what distinguishes SIEM from other network monitoring and detection tools, such as Intrusion Prevention Systems (IPS) or Intrusion Detection Systems (IDS).

• event.code:4625

• event.code:4625 AND winlog.event_data.SubStatus:0xC0000072

  • SubStatus value of 0xC0000072

    • indicates that the account is currently disabled

• event.code:4625 AND winlog.event_data.SubStatus:0xC0000072 AND @timestamp >= "2023-03-03T00:00:00.000Z" AND @timestamp <= "2023-03-06T23:59:59.999Z"

• event.code:4625 AND user.name: admin*

Windows Security Log Event ID 4625 - An account failed to log on

Now before I move on, have to finish this:

• Elastic Common Schema (ECS)

• Elastic Common Schema (ECS) event fields

Elastic Stack and Product Documentation | ElasticElastic

A Security Operations Center (SOC) is an essential facility that houses a team of information security experts responsible for continuously monitoring and evaluating an organization's security status.

The main objective of a SOC team is to identify, examine, and address cybersecurity incidents by employing a mix of technology solutions and a comprehensive set of procedures.

The MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework serves as an extensive, regularly updated resource outlining the tactics, techniques, and procedures (TTPs) employed by cyber threat actors.

MITRE ATT&CK framework is an indispensable asset for security operations, offering a shared language and structure for describing and understanding adversarial behavior. It is vital for enhancing various aspects of security operations, from threat intelligence and behavioral analytics to SOC maturity assessment and cyber threat intelligence enrichment.

Building a bypass with MSBuildCisco Talos Blog

What Are LOLBins and How Do Attackers Use Them in Fileless Attacks?Cynet

When creating an SOP and documenting alert handling, consider the following:

1. process.name

2. process.parent.name

3. event.action

4. machine where the alert was detected

5. user associated with the machine

6. user activity within +/- 2 days of the alert's generation

7. After gathering this information, defenders should engage with the user and examine the user's machine to analyze system logs, antivirus logs, and proxy logs from the SIEM for full visibility.

specify the date range as "last 15 years"

we can use a filter to only consider needed event IDs that match what yo need

We should use the .keyword field when it comes to aggregations. Please refer to this stackoverflow question for a more elaborate answer.

difference between a field and the field.keywordStack Overflow

Secure on-premises computer accounts with Active Directory - Microsoft EntraMicrosoftLearn

Computer accounts can be excluded by specifying the following KQL query and clicking on the "Update" button.

NOT user.name: *$ AND winlog.channel.keyword: Security

SubStatus value of 0xC0000072

"Create visualization"

4625 – Failed logon attempt on a Windows system

SubStatus (winlog.event_data.SubStatus field) that indicates, when set to 0xC0000072, that the failure is due to a logon with disabled user.

Service account credentials are never used for RDP logons in corporate/real-world environments. all service accounts on the environment start with svc-

Windows Security Log Event ID 4624 - An account was successfully logged on

4624 – An account was successfully logged

logon type which should be RemoteInteractive (winlog.logon.type field).

don't use the .keyword field in KQL queries.

user.name: svc-*

1. The service account whose credentials generated the successful RDP logon attempt event.

2. The machine on which the logon attempt occurred.

3. The IP of the machine that initiated the logon attempt.

4. The number of times the event has occurred (based on the specified time frame or the entire data set, depending on the settings).

click on "Save and return", and you will observe that the new visualization is added to the dashboard.

Windows Security Log Event ID 4732 - A member was added to a security-enabled local group

Windows Security Log Event ID 4733 - A member was removed from a security-enabled local group

• Which user was added to or removed from the group? (winlog.event_data.MemberSid.keyword field)

• To which group was the addition or the removal performed? (double-checking that it is the "Administrators" one) (group.name.keyword field)

• Was the user added to or removed from the group? (event.action.keyword field)

• On which machine did the action occur? (host.name.keyword field)

1. Initial Alert Review:

• Thoroughly review the initial alert, including metadata, timestamp, source IP, destination IP, affected systems, and triggering rule/signature.

• Analyze associated logs (network traffic, system, application) to understand the alert's context.

1. Alert Classification:

• Classify the alert based on severity, impact, and urgency using the organization's predefined classification system.

1. Alert Correlation:

• Cross-reference the alert with related alerts, events, or incidents to identify patterns, similarities, or potential indicators of compromise (IOCs).

• Query the SIEM or log management system to gather relevant log data.

• Leverage threat intelligence feeds to check for known attack patterns or malware signatures.

1. Enrichment of Alert Data:

• Gather additional information to enrich the alert data and gain context:

  • Collect network packet captures, memory dumps, or file samples associated with the alert.

  • Utilize external threat intelligence sources, open-source tools, or sandboxes to analyze suspicious files, URLs, or IP addresses.

  • Conduct reconnaissance of affected systems for anomalies (network connections, processes, file modifications).

1. Risk Assessment:

• Evaluate the potential risk and impact to critical assets, data, or infrastructure:

  • Consider the value of affected systems, sensitivity of data, compliance requirements, and regulatory implications.

  • Determine likelihood of a successful attack or potential lateral movement.

1. Contextual Analysis:

• The analyst considers the context surrounding the alert, including the affected assets, their criticality, and the sensitivity of the data they handle.

• They evaluate the security controls in place, such as firewalls, intrusion detection/prevention systems, and endpoint protection solutions, to determine if the alert indicates a potential control failure or evasion technique.

• The analyst assesses the relevant compliance requirements, industry regulations, and contractual obligations to understand the implications of the alert on the organization's legal and regulatory compliance posture.

1. Incident Response Planning:

• Initiate an incident response plan if the alert is significant:

  • Document alert details, affected systems, observed behaviors, potential IOCs, and enrichment data.

  • Assign incident response team members with defined roles and responsibilities.

  • Coordinate with other teams (network operations, system administrators, vendors) as necessary.

1. Consultation with IT Operations:

• Assess the need for additional context or missing information by consulting with IT operations or relevant departments:

  • Engage in discussions or meetings to gather insights on the affected systems, recent changes, or ongoing maintenance activities.

  • Collaborate to understand any known issues, misconfigurations, or network changes that could potentially generate false-positive alerts.

  • Gain a holistic understanding of the environment and any non-malicious activities that might have triggered the alert.

  • Document the insights and information obtained during the consultation.

1. Response Execution:

• Based on the alert review, risk assessment, and consultation, determine the appropriate response actions.

• If the additional context resolves the alert or identifies it as a non-malicious event, take necessary actions without escalation.

• If the alert still indicates potential security concerns or requires further investigation, proceed with the incident response actions.

1. Escalation:

• Identify triggers for escalation based on organization's policies and alert severity:

  • Triggers may include compromise of critical systems/assets, ongoing attacks, unfamiliar/sophisticated techniques, widespread impact, or insider threats.

• Assess the alert against escalation triggers, considering potential consequences if not escalated.

• Follow internal escalation process, notifying higher-level teams/management responsible for incident response.

• Provide comprehensive alert summary, severity, potential impact, enrichment data, and risk assessment.

• Document all communication related to escalation.

• In some cases, escalate to external entities (law enforcement, incident response providers, CERTs) based on legal/regulatory requirements.

1. Continuous Monitoring:

• Continuously monitor the situation and incident response progress.

• Maintain open communication with escalated teams, providing updates on developments, findings, or changes in severity/impact.

• Collaborate closely with escalated teams for a coordinated response.

1. De-escalation:

• Evaluate the need for de-escalation as the incident response progresses and the situation is under control.

• De-escalate when the risk is mitigated, incident is contained, and further escalation is unnecessary.

• Notify relevant parties, providing a summary of actions taken, outcomes, and lessons learned.

Regularly review and update the process, aligning it with organizational policies, procedures, and guidelines. Adapt the process to address emerging threats and evolving needs.