SigmaHQ / sigma

Main Sigma Rule Repository

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

net_connection_win_rundll32_net_connections.yml leads to false positive via multiple vendors

bill-e-ghote opened this issue · comments

Rule UUID

cdc8da7d-c303-42f8-b08c-b4ab47230263

Example EventLog

Threat Info:
Name: showjournal.exe
URL: https://.sentinelone.net/incidents/threats/1872591144725886494/overview
Path: \Device\HarddiskVolume4\Users<redacted>\msys64\mingw32\bin\showjournal.exe
Process User: <redacted>
Signature Verification: NotSigned
Originating Process: pacman.exe
SHA1: e9156f92e402358f75f298c3cfab17e70cfacb1b
Initiated By: Agent Policy
Engine: SentinelOne Cloud
Detection type: Static
Classification: Malware
File Size: 1.45 MB
Storyline: 1075A15E74C15669
Threat Id: 1872591144725886494
Endpoint Info:
Computer Name: ETG-HP840-30X0T
Console Connectivity: Online
Full Disk Scan: Completed at Aug 03, 2023 19:21:38
Pending reboot: No
Network Status: Connected
Scope:
OS Version: Windows 10 Enterprise 19045
Agent Version: 23.2.3.358
Policy: protect
Logged In User:
UUID: 3a3b95c1679849d18766343b925d923f
Domain:
IP v4 Address: 192.168.8.157
IP v6 Address: fe80::efa:4f39:ad02:c598
Console Visible IP Address: 107.128.237.195
Subscription Time: Aug 03, 2023 19:10:02

Description

I'm running Msys2 on Windows 10. Attempt over the weekend to update all installed files (pacman -Suy) led to detection, alert and quarantine by my company's enterprise EDR, SentinelOne, of showjournal.exe.

Detections on VirusTotal:
https://www.virustotal.com/gui/file/db218d848641aff7c9d37369f57c55a65da5b7ca5653ebebdd233d74558eb3b1/detection

This is the Msys2 32-bit package that includes showjournal.exe and triggers the alert:
https://packages.msys2.org/package/mingw-w64-i686-sqlite3?repo=mingw32

This is the Msys2 64-bit package that includes showjournal.exe but does not trigger the alert:
https://packages.msys2.org/package/mingw-w64-x86_64-sqlite3

From the package build instructions we see the original, Debian sqlite3-tools.
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-sqlite3/PKGBUILD

From Debian sqlite3-tools

_sqlite_tools="showdb.exe showjournal.exe showstat4.exe showwal.exe sqlite3_analyzer.exe dbhash.exe sqldiff.exe"

My report to the Msys2 package maintainer was closed as invalid.
msys2/MINGW-packages#19912

Please advise.

Welcome @bill-e-ghote 👋

It looks like this is your first issue on the Sigma rules repository!

The following repository accepts issues related to false positives or 'rule ideas'.

If you're reporting an issue related to the pySigma library please consider submitting it here

If you're reporting an issue related to the deprecated sigmac library please consider submitting it here

Thanks for taking the time to open this issue, and welcome to the Sigma community! 😃

Hi and thanks for reporting this.

Unfortunately your issue has nothing to do with Sigma. The rule is detecting what it's intended to do which is "rundll32 communicating with a non local IP". Its something interesting from a detection perspective.

The AV engine have nothing to do with SIGMA :)

Also the rundll32 execution is a sandbox artifact not related to your binary (see behavior tab)

I will be closing as unrelated. Best course of action is to report the binary to your AV vendor to get it whitelisted

Multiple AV engines are consuming Sigma as well they ought. I disagree it has nothing to do with Sigma. Indeed, the rule in question already whitelists certain known IP network ranges. I would try to identify the range that this Debian tool is connecting that is triggering the rule and suggest an update to the script, but I will need to expand my own technical skills to do that. I will make the effort. Thanks for the suggestion to examine the sandbox, I will look closer there, and of course will follow up with our AV vendor.

You can't disagree XD because it's not a subjective opinion. Either you show me proof that they are basing their logic on sigma (which you can't) because the same rule triggers on other binaries with 0 positives in VT.

The flagging occurs because of bad sigs that tried to flag similar malware but chose strings and op codes related to the compiler instead.