Incident handling

  1. aim to know the attackers' tactics, techniques, and procedures

    1. The preparation phase covers the readiness of an organization against an attack

    2. The detection phase covers everything related to detecting an incident and the analysis process of the incident

      1. This phase also covers hunting for the unknown threat within the organization.

    3. Containment, Eradication, and Recovery actions needed to prevent the incident from spreading and securing the network.

      1. steps taken to avoid an attack from spreading into the network

      2. isolating the infected host

      3. clearing the network from the infection traces

      4. gaining control back from the attack

    4. Post-Incident Activity / Lessons Learnt

      1. includes identifying the loopholes in the organization's security posture

      2. improving so that the attack does not happen next time

      3. identifying weaknesses that led to the attack

      4. adding detection rules so that similar breach does not happen again

      5. training the staff if required

Cyber Kill Chain

  1. Map the attacker's activity in each phase during this Investigation [ https://static1.squarespace.com/static/5b636d897c932781e8002af9/t/6018dc12e670955289be56d6/1612241938544/Cyber+Kill+Chain+Report+for+APT+Group+PoisonIvy.pdf ]

    1. Reconnaissance

    2. Weaponization

    3. Delivery

    4. Exploitation

    5. Installation

    6. Command & Control

    7. Actions on Objectives

  2. log sources showing visibility into both network-centric and host-centric activities

SPLUNK [ index=botsv1 ]

  1. click on the Data summary and navigate the available tabs to get the information

    1. wineventlog

      1. It contains Windows Event logs

    2. winRegistry

      1. It contains the logs related to registry creation / modification / deletion etc.

    3. XmlWinEventLog

      1. It contains the sysmon event logs. It is a very important log source from an investigation point of view.

    4. fortigate_utm

      1. It contains Fortinet Firewall logs

    5. iis

      1. It contains IIS web server logs

    6. Nessus:scan

      1. It contains the results from the Nessus vulnerability scanner.

    7. Suricata

      1. It contains the details of the alerts from the Suricata IDS. This log source shows which alert was triggered and what caused the alert to get triggered— a very important log source for the Investigation.

    8. stream:http

      1. It contains the network flow related to http traffic.

    9. stream: DNS

      1. It contains the network flow related to DNS traffic.

    10. stream:icmp

      1. It contains the network flow related to icmp traffic.

Reconnaissance Phase
  1. Reconnaissance is an attempt to discover and collect information about a target

  2. start our analysis by examining any reconnaissance attempt against the webserver imreallynotbatman.com

  3. First task is to identify the IP address attempting to perform reconnaissance activity on our web server.

  4. stream:http, which contains the http traffic logs

    1. examine the src_ip

  5. We have narrowed down the results to only show the logs from the source IP

  6. what do we need to do to validate the scanning attempt? Simple, dig further into the weblogs.

The attacker needs to exploit the vulnerability to gain access to the system/server.

  • We found two IP addresses from the reconnaissance phase with sending requests to our server.

  • One of the IPs 40.80.148.42 was seen attempting to scan the server with IP 192.168.250.70.

  • The attacker was using the web scanner Acunetix for the scanning attempt.

Exploitation Phase
  1. index=botsv1 imreallynotbatman.com sourcetype=stream* | stats count(src_ip) as Requests by src_ip | sort - Requests

narrow down the result to show requests sent to our web server, which has the IP 192.168.250.70

  1. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70"

    1. This query will look for all the inbound traffic towards IP 192.168.250.70.

  2. Check what methods were used

    1. http_method

  3. index=botsv1 imreallynotbatman.com sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST

    1. src_ip

    2. form_data

    3. http_user_agent

    4. uri

    5. uri_path

    6. http_referrer

  4. Establish CMS

  5. Establish Log-on page of the CMS

    1. examining the traffic coming into this admin panel for a potential brute-force attack.

  1. index=botsv1 imreallynotbatman.com sourcetype=stream:http dest_ip="192.168.250.70" uri="/joomla/administrator/index.php"

    1. We are going to add uri="/joomla/administrator/index.php" in the search query to show the traffic coming into this URI.

    2. Check for form_data

      1. contains the requests sent through the form on the admin panel page

  2. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST uri="/joomla/administrator/index.php" | table _time uri src_ip dest_ip form_data

    1. We will add this -> | table _time uri src dest_ip form_data to create a table

        1. attacker from the IP 23.22.63.114 Was trying to guess the password by brute-forcing and attempting numerous passwords.

        2. The time elapsed between multiple events also suggests that the attacker was using an automated tool

  3. Extracting Username and Passwd Fields using Regex

    1. use Regex in the search to extract only these two fields

      1. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST uri="/joomla/administrator/index.php" form_data=usernamepasswd* | table _time uri src_ip dest_ip form_data

      2. extract all the password values found against the field passwd in the logs

        1. rex field=form_data "passwd=(?<creds>\w+)"

        2. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST form_data=usernamepasswd* | rex field=form_data "passwd=(?\w+)" | table src_ip creds

  4. Investigate user agents

    1. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" http_method=POST form_data=usernamepasswd* | rex field=form_data "passwd=(?\w+)" |table _time src_ip uri http_user_agent creds

    2. Python brute-force script used

Once the attacker has successfully exploited the security of a system, he will try to install a backdoor or an application for persistence or to gain more control of the system.

Installation phase
  1. found evidence of the webserver iamreallynotbatman.com

  2. getting compromised via brute-force attack

  3. attacker using the python script to automate getting the correct password

  4. the attacker used different IP for the attack and the IP to log in to the server

What I will do:

  1. Investigate any payload / malicious program uploaded to the server from any attacker's IPs

  2. Check is there anything installed into the compromised server

Narrow down any http traffic coming into our server 192.168.250.70 containing the term ".exe." This query may not lead to the findings, but it's good to start from 1 extension and move ahead.

  1. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" *.exe

  2. index=botsv1 sourcetype=stream:http dest_ip="192.168.250.70" *.exe "part_filename{}"="3791.exe" c_ip="40.80.148.42"

  3. Switch now to host-centric logs.

  4. Narrow down logs to .exe file

    1. What are sysmon eventID's meanings?

      1. https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

        1. Event ID 1: Process creation

          index=botsv1 "3791.exe" sourcetype="XmlWinEventLog" EventCode=1

          1. This query will look for the process Creation logs containing the term "3791.exe" in the logs

Action on Objective

start our investigation by examining the Suricata log source and the IP addresses communicating with the webserver 192.168.250.70.

index=botsv1 dest=192.168.250.70 sourcetype=suricata

Check for "source" ip.

None, see if any communication originates from the server.

index=botsv1 src=192.168.250.70 sourcetype=suricata

Check "dest_ip"

  1. Web servers do not originate the traffic

  2. The browser or the client would be the source, and the server would be the destination

  3. Check each ip "url"

  4. index=botsv1 url="/poisonivy-is-coming-for-you-batman.jpeg" dest_ip="192.168.250.70" | table _time src dest_ip http.hostname url

    1. or click on the .jpeg and check for "src"

  • Attacker uploaded the file to the server before defacing it

  • Attacker used a Dynamic DNS to resolve a malicious IP

  • Examine the network-centric log sources

    • fortigate_utm to review the firewall logs

  • Objective: find the IP that the attacker decided the DNS

Command and Control

index=botsv1 sourcetype=fortigate_utm"poisonivy-is-coming-for-you-batman.jpeg"

Another log source

  1. index=botsv1 sourcetype=stream:http dest_ip=23.22.63.114 "poisonivy-is-coming-for-you-batman.jpeg" src_ip=192.168.250.70

Check DNS log stream.

  • Create Malware / Malicious document to gain initial access / evade detection etc.

  • Establish domains similar to the target domain to trick users.

  • Create a Command and Control Server for the post-exploitation communication/activity etc.

  • Found a domain prankglassinebracket.jumpingcrab.com associated with this attack.

  • Object: find the IP address tied to the domains that may potentially be pre-staged to attack Wayne Enterprise.

Weaponization
  1. https://www.virustotal.com/graph/http%253A%252F%252Fprankglassinebracket.jumpingcrab.com%252F

      1. www.threatminer.org

      2. ipinfo.io

      3. www.hybrid-analysis.com

      4. www.lookip.net

      5. static1.squarespace.com

      6. whatismyip.live

      7. any.run

General OSINT sites:

  1. Virustotal

  2. ThreatMiner

  3. Hybrid-Analysis

Delivery Phase

Last updated