03-19-2020 02:57 AM
Hi, we have a Stealthwatch 7 deployed.
We send the events to QRadar and in QRadar we receive this kind of log:
(...)
<110>Mar 04 14:23:01 vap11039 StealthWatch[4925]: LEEF:2.0|Lancope|Stealthwatch|6.8|51|0x7C|src=10.90.7.10|dst=0.0.0.0|dstPort=|proto=|msg=Unauthorized, potentially malicious scans using TCP or UDP are being run against your organization's hosts and may be early indicators of attacks against your network.|fullmessage=Observed 4k points. Policy maximum allows up to 1k points.|start=2020-03-04T14:22:22Z|end=|cat=Recon|alarmID=5C-1FNZ-1QOK-APS7-8|sourceHG=DG|targetHG=Unknown|sourceHostSnapshot=https://10.151.240.21/lc-landing-page/smc.html#/host/10.90.7.10|targetHostSnapshot=https://10.151.240.21/lc-landing-page/smc.html#/host/0.0.0.0|flowCollectorName= vap11035|flowCollectorIP=10.151.240.20|domain=group.enterprise.it|exporterName=|exporterIP Address=|exporterInfo=|targetUser=|targetHostname=|sourceUser=|alarmStatus=ACTIVE|alarmSev=Major
(...)
As you can see we miss (at least):
- destination IP
- destination port
If we watch on the console we see all this informations, including destination IP, port and protocol as you can see from the attached png.
This is the template we use on StealthWatch to compose the logs (from QRadar docs):
(...)
LEEF:2.0|Lancope|Stealthwatch|6.8|{alarm_type_id}|0x7C|src={source_ip}
|dst={target_ip}|dstPort={port}|proto={protocol}|msg={alarm_type_
description}|fullmessage={details}|start={start_active_time}|end=
{end_active_time}|cat={alarm_category_name}|alarmID={alarm_id}|
sourceHG={source_host_group_names}|targetHG={target_host_group_
names}|sourceHostSnapshot={source_url}|targetHostSnapshot={target
_url}|flowCollectorName={device_name}|flowCollectorIP={device_ip}
|domain={domain_name}|exporterName={exporter_hostname}|exporterIP
Address ={exporter_ip}|exporterInfo={exporter_label}|targetUser=
{target_username}|targetHostname={target_hostname}|sourceUser=
{source_username}|alarmStatus={alarm_status}|alarmSev=
{alarm_severity_name}
(...)
Thank you
Solved! Go to Solution.
03-20-2020 02:50 AM
03-19-2020 10:51 AM
Hello,
0.0.0.0 in either source ip or destination ip means that the alarm has affected more than 1 host, in this specific case as destination. I would suggest to consult the online help for the specific event to determine the next step in the investigation process.
Hope this helps.
Dario
03-19-2020 11:23 AM
Okay, but what I don't understand is: if I look in the console I see this flows, I think the flow of the event is the one higlited in red in the attached image.
If I am right, for every row in the console there is a log row, right ?
Thank you
P.S. Which help on line, the one on the console ? Thank you.
03-20-2020 01:36 AM
You are right in thinking that for each alarm there's one or more flows associated to it. Certain alarms (like worm activity and worm propagation, various scans, etc.) trigger only when multiple flows are associated to the event. To avoid overwhelming the syslog server receiving those alarms, and respect the byte limit in the UDP packets, a throttling feature has been added to the response manager. So when an alarm is triggered, the product will go through this logic:
- Does the alarm contemplates multiple sources or destinations? Yes: swap multiple values of the alarm with 0.0.0.0 and aggregate the alarms into 1 alarm line.
FYI.: this feature will very likely change in the next future.
03-20-2020 01:45 AM
Yes, but there is something strange.
Taking logs in another way (if you need more technical detail I will ask to the collegues) we see this events:
(...)
<134>LEEF:2.0|Lancope|Stealthwatch|0x7C|src=10.90.5.157|dst=10.91.17.0|dstPort=7680|proto=tcp|msg=The source host is attempting to contact multiple hosts (using TCP) within a natural class C network (/24) on the same port and most connection attempts are either being rejected (TCP Reset) or the target hosts are not responding at all. This is used to trigger the Worm Activity and Worm Propagation alarms. These are commonly seen during network scanning or enumeration.|start=2020-03-17T09:43:35.000+0000|end=2020-03-17T09:43:35.000+0000|cat=Addr_Scan/tcp|sourceHG=DG Firenze - wp-users|targetHG=DG Roma - Area USR - wp-users|alarmSev=Major
(...)
As you can see here there are all of the informations we need, but unfortunately is LEEF 2.0 who is not the format the QRadar Stealtwatch DSM expect to see.
Shall we build a custom DSM to get the logs in this format and manually integrate Stealthwatch in QRadar ?
Thank you
03-20-2020 02:50 AM
03-20-2020 03:42 AM
Thank you, we will lokk in this docs. Thank you.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide