[Tuning] Suspicious File Downloaded from Google Drive

[Samirbous]

rule is generating lot of FPs, use of sequence is unecessary, since the main suspicious part is the process arguments pointing to google drive and the download and AV exclusion url flags. In addition the expected process to handle phishing URLs are browser processes (excluded in previous logic) which will cause to miss the scenario referenced in the referecnes url https://github.com/elastic/detection-rules/blob/main/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml#L25

[terrancedejesus]

Original issue reference: #3391

@Samirbous and I had a great discussion about tuning this rule. Ultimately, the original PoC leveraged custom code to download a file from Google Drive directly via a manipulated URL that included URI parameters to allow direct downloads and skip Google's antivirus scanning. This PoC leverages HTTPS, thus lacking visibility into the URI parameters, resulted in an attempt to string together a series of events that would happen (binary -> HTTPS request to Google Drive -> execute or load file).

However, multiple FPs arised due to a combination of attempting to cover multiple events and be cross platform. Rather we agreed that this rule needs to be adjusted, including the intent of the threat identification. Our plan is to do the following:

1. Tune existing rule and adjust intent to be browser redirection focused to a rather unusually used Google Drive URL
2. Create a new rule, primarily identifying HTTP requests (so we can have logic on the URI parameters) to that URL
3. Start some digging into new terms for process executable and dns domain combinations to web services and chat platforms (telegram, discord, etc.)

This would ideally tune 1 rule and create 2 more depending on research and testing.

For reference, we have begun hunting for malicious binaries to run in sandboxes for appropriate telemetry rather than custom tooling created initially. Example - https://www.virustotal.com/gui/file/1c398cb6f3014c8979cda49158a4a30de5040c693f30ffbc3b4f35820350118b/behavior

This should reduce performance concerns and FPs considerably. Note that while it is common for user redirection to Google Drive to download a file, the means by how that is downloaded here is not. When creating and storing a file in Google Drive, it is give a unique ID. A user, through the UI, typically can create a share link that automatically generated by Google and copied to clipboard, then shared with others. These URLs do not have export=download and confirm=no_antivirus URI parameters and this has to be manually created. Programmatically the URL could be hardcoded in a binary in which only an ID is given as to what file to download.

[terrancedejesus]

Looks good to me based on our discussion.