Stealthwatch logs missing destination IP, destination port, protocol

[mbrogioni]

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

[dcavalla]

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

[mbrogioni]

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.

[dcavalla]

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.

[mbrogioni]

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

[dcavalla · Accepted solution]

The response manager has a lot of flexibility when it comes to syslog formats. I would suggest to also look at examples of configurations here: https://community.cisco.com/t5/security-documents/stealthwatch-use-cases/ta-p/3611837. In the integration section you will see examples of how to customize the syslog format.

Hope this helps.

Dario

[mbrogioni]

Thank you, we will lokk in this docs. Thank you.