Seeking advice on next steps in investigation
-
@michmoor Sounds like it’s a bit late now but if you run Suricata on the internal (physical) interface of the VLAN it would tell you the internal IP of the devices.
You could make a temporary firewall rule logging all traffic from that IP.
-
@SteveITS hey Steve! I traced it back to the device internally and I log all flows to my remote log server.
I’m just going to have to monitor this device fora few before I rule out a false positive -
@bmeeks that’s a reasonable assumption of the flow.
The risk level here is low but that rule that triggered just had me concerned.
I’m going to monitor for a few before I rule out but so far the endpoints it’s connecting to are clean in virus total. -
@michmoor said in Seeking advice on next steps in investigation:
The pearls of TLS in the cybersecurity world :(
You should still be able to sniff the traffic and in the handshake see the sni its going to.. This would/should be some validation that talking to something about the pictureframes, and not some odd ball domain being hosted on aws space doing bad shit, etc.
-
I once got the advice here to turn off internet for IoT and only to enable it for updates etc.
-
I appreciate everyones feedback here.
Letting ntopng run for a few hours so new flows could be seen and analyzed this issue can be concluded as a false positive for env.
Checking DNS queries along with TLS Hellos for the CN shows that all outbound connections appear to be related and are part of the normal flows a product like this would make.
-
@michmoor said in Seeking advice on next steps in investigation:
can be concluded as a false positive for env.
No say it isn't so - and IPS/IDS with false positive.. Can't be! ;) hehehehe
-
@johnpoz LOL
edit: This was a pretty good lesson/refresher for me to go through and break down how to investigate an alert. I hope i was clear in my approach to help others after me.
-
@michmoor said in Seeking advice on next steps in investigation:
his was a pretty good lesson/refresher for me to go through and break down how to investigate an alert.
You might consider posting feedback to the Emerging Threats/ProofPoint team on the false positive of that rule Signature. I suspect it was written a bit "loose" on the pattern matching end. There are likely other innocent Android-based devices that may also trigger that alert needlessly. Supplying them some packet captures would be helpful to them along with your other findings.
Rule authors sometimes get too focused on some "thing" a piece of malware is doing and may fail to fully recognize that some behavior is "just the way it works" with a certain operating system. I have not examined the rule in question here, but it may be that the trojan this rule was originally created to detect does a number of things using normal Android API techniques in addition to the trojan's "not normal" things. Very important for all those to be carefully filtered and analyzed by the rule's detection logic to reduce such false positives. For instance, if a lot of Android apps generate traffic of type "X", and your target trojan also generates traffic of type "X", then using solely traffic type "X" as the trigger for the rule is a bad design. In that case the rule needs to look for multiple triggers, and logically AND them together before deciding on whether an alert is appropriate.
-
@bmeeks Thanks Bill. Ill reach out to them on their forum and on Twitter.
