Hi there,
Did anyone here know how to do Threat Hunting report using SIEM in Kibana?
Hi @syafeera, would you be willing to share some details about your objective? For example:
- What is the purpose of the report?
- Who is the intended audience of the report?
- What details would it contain?
Thanks!
Hi There,
i have setup Elasticsearch/Kibana in my office environment..
However, i'm still confuse how to read the signal..Based on my reading, signal is for threat detection? The purpose of my report is i want to know, who is the attacker and threat that happen in my office..For now, i just monitor from SIEM.. may i know, after we do threat analysis, can we do report based on SIEM?
What details would it contain?
might be the details related with the threat.. The attacker, the attacker destination and what they trying to attack..all in one reports.
Based on my reading, signal is for threat detection?
Yes, and as of the 7.9 release of Elastic Security, Signals are now called detection alerts.
The documentation on Detections and Alerts will help you get started, so you can load and activate prebuilt Elastic rules.
To start an investigation from a detection alert, optionally mark it as In progress, or just click the Investigate in timeline action:
Expand events in the timeline to see, (per your example above)
the attacker destination and what they trying to attack.
The fields in the event above are part of the Elastic Common Schema, and documented in the ECS Field Reference.
Pin events of interest in a timeline:
Annotate events in a timeline with Markdown notes:
When you're ready to report the results of your investigation, click Attach timeline to new case
Cases are used to open and track security issues directly in the Elastic Security app. Report and share details of an attack with your team using cases:
Additionally, you can send cases to these external systems from within Elastic Security:
- ServiceNow
- Jira (including Jira Service Desk)
- IBM Resilient
2 Likes
Hi there,
There is a few field that i cannot understand in SIEM..Especially
- Source ip address
- Destination Ip address
- Event category
- Event Action
- Source port
- Destination port
Is that all the info is for attacker details? Who is source Ip ? Who is Destination IP.. i'm still new in security.. Please guide me.. Thank you...
- The IP Address of the device that initiated the packet/connection
- The IP Address of the device that received the packet/connection
- The category this event belongs to ("Process" for example)
- Event Action is a subcategory of event category and describes it in more detail ("process-started" for example)
- The port used by the source computer
- The port the source computer targeted on the destination
To put the network stuff into perspective imagine the following scenario:
You have two clients in your domain, one has the IP 1.0.0.1 and the other is 2.0.0.2
Now 1.0.0.1 initiates and RDP connection to 2.0.0.2, the resulting event would look like this:
Source IP: 1.0.0.1
Destination IP: 2.0.0.2
Event Category: network
Event Action: Network-connect
Source Port: 60100 (random high port)
Destination Port: 3389 (this is the default port for RDP)
A full list of ECS references can be found here ECS Field Reference | Elastic Common Schema (ECS) Reference [8.11] | Elastic
1 Like
Example Scenario
To put the network stuff into perspective imagine the following scenario:
You have two clients in your domain, one has the IP 1.0.0.1 and the other is 2.0.0.2
Now 1.0.0.1 initiates and RDP connection to 2.0.0.2, the resulting event would look like this:
Source IP: 1.0.0.1
Destination IP: 2.0.0.2
Event Category: network
Event Action: Network-connect
Source Port: 60100 (random high port)
Destination Port: 3389 (this is the default port for RDP)
Question: Do you mean, source ip is the attacker and destination ip is the victim? This scenarios means the attacker want to attack port RDP? This is what you mean?
No this was simply an example to show you what the Elastic Fieldset views as "attacker" and "victim" from the logs it ingests. The field names are not to be conflated with the meaning behind those names!
You're not able to tell if this was a regular RDP connection or a legitimate attack without doing proper log analysis.
But if we assume that this was a illegitimate RDP connection then yes, source IP is the attacker and destination IP is the victim.
ok. understood.
what if i analyse through signal list? signal is use to detect threat right? Does all the signal detected is a threat and we can further investigate using timeline..or not all the signal are threat?
Hello Syafeera,
this entirely depends on your signal.
There are certain alerts that are always a threat and then there are alerts where you have to do further analysis to determine IF this was actually a threat.
Heres some examples:
Brute Force
Lets say you have a Brute Force Threshold rule that alerts when 5 failed logons happen. This can be a legitimate Bruteforce alert, it could also just be a co-worker that forgot his password.
Here you need to do further investigation to determine the actual threat behind this signal.
(Link to Mitre Bruteforce Techinque)
Port Scans
Port scans can happen for many reasons. Some are malicious, some are from vulnerability scanners and some are from closing faulty TCP connections.
When a server looses a TCP connection and it wasnt properly closed it will send RST-ACK or FIN packages to the host on multiple ports.
All three of these actions can generate a SIEM signal. Its not possible to tell if this is a legitimate threat or not without further investigation.
(Link to Mitre Network Service Scanning Technique)
Pass the Hash
The conditions for a pass the hash attack are so unique that you can 100% be sure that this is a legitimate threat. Because in order for PtH to work the standard authentication steps are bypassed and instead of the actual password a hash is passed through.
This should NEVER happen in a productive environment.
(Link to Mitre Pass the Hash Technique)
Process Spawning
It is possible for processes to start child processes. Some processes should obviously never spawn certain other processes.
If you have a rule that detects the spawn of child processes and you can see that the Calculator.exe process started cmd.exe as a child process you can always be sure that this is a threat.
I hope this helps you to better understand how to determine threats and what your signals actually tell you.
may i know, where can i get this rule?
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.