SOC Challenge/Day 26-Investigate SSH Brute Force Attacks

tarih:

 D26 - Investigate SSH Brute Force Attacks

1. Introduction, Purpose and Problem Statement

1.1 What is this guide about?

  • This guide focuses on the investigation of SSH brute force attacks, outlining the methodologies to detect, analyze, and respond to such security incidents. It aims to provide a comprehensive framework for understanding these attacks and implementing effective defenses.

1.2 What impact does this guide have?

  • The guide aims to:
    • Enhance Security Posture: Improve the organization's ability to detect and respond to SSH brute force attacks, reducing the likelihood of unauthorized access.
    • Educate Stakeholders: Provide insights into the nature of SSH brute force attacks, helping staff and decision-makers understand the risks and necessary precautions.
    • Facilitate Incident Response: Offer a structured approach to investigating incidents, enabling quicker and more effective responses.
    • Promote Best Practices: Encourage the adoption of security best practices to mitigate the risk of such attacks in the future.

1.3 What caused this necessity?

  • The necessity for this guide arises from:
    • Increasing Threat Landscape: The rise in frequency and sophistication of SSH brute force attacks targeting various organizations.
    • Need for Proactive Defense: Organizations require effective strategies to identify and mitigate these threats before they result in significant damage.
    • Regulatory Compliance: Compliance requirements may mandate the implementation of security measures and incident reporting procedures, emphasizing the need for thorough investigation and documentation.

2. Brute Force Investigation Methodology

2.1 Target IP Address

  • IP: 124.225.4.160
  • User: root

2.2 Initial Assessment

  • Is this IP known to perform brute force activity?
    • Answer: Yes.
  • Sources:
    • Apuseipdb: This IP has been reported 45 times. Abuse confidence is 100%.
    • Greynoise: Identified as an opportunistic scanning IP, not a risk to our organization.

2.3 Affected Users

  • Are there any other users affected by this IP?
    • Answer: Yes (root, user).

2.4 Success of Attacks

  • Were any of them successful?
    • Answer: No.
  • Query:
    • source.ip:124.225.4.160 and system.auth.ssh.event: "Accepted"
    • Result: Zero accepted login events.

2.5 Post-Login Activity

  • If successful logins occurred, what activity took place afterward?
    • (No activity recorded.)

3. Configuration for Alerts to send Ticket to osTicket

3.1 Accessing Kibana

  • Navigated to the Kibana/Security/Alerts section.

3.2 Selecting the Alarm

  • Chose the alarm I wanted to modify.
  • Clicked on the Edit Settings button.

3.3 Configuring Actions

  • Navigated to the Actions section.
  • Added the desired message for alert notifications.

3.4 Transforming osTicket Payload

  • Modified the osTicket default payload to fit my requirements.

3.5 Saving Changes

  • Saved the configuration successfully.

4. Conclusion

An action was implemented to ensure that a ticket is created for each generated alarm. This will help streamline the incident response process and ensure that all alerts are properly documented for further analysis

Yorumlar

Yorum Gönder