2

I'm working on a script I can push out to a few dozen Windows Server 2012/2012R2 servers to enable FSRM File Screens that will write an alert to the event log when they detect a particular filename being written to disk.

$a = gwmi win32_logicaldisk -filter DriveType=3 | Select -ExpandProperty DeviceID

Install-WindowsFeature -Name FS-Resource-Manager -IncludeManagementTools

New-FsrmFileGroup -Name "CryptoWall File Monitor" -IncludePattern @("*DECRYPT*")

$Notification = New-FsrmAction -Type Event -EventType Warning -Body "Alert text here" -RunlimitInterval 30

foreach ($i in $a){
    New-FsrmFileScreen -Path "$i" -IncludeGroup "CryptoWall File Monitor" -Notification $Notification
}

Now, the script itself works fine, with one tiny issue: when it runs, the first filescreen (usually on C:) has the correct settings:

Active          : False
Description     : 
IncludeGroup    : {CryptoWall File Monitor}
MatchesTemplate : False
Notification    : {MSFT_FSRMAction}
Path            : C:\
Template        : 
PSComputerName  : 

But subsequent screens do not (note the Active : True output below)

Active          : True
Description     : 
IncludeGroup    : {CryptoWall File Monitor}
MatchesTemplate : False
Notification    : {MSFT_FSRMAction}
Path            : D:\
Template        : 
PSComputerName  : 

The "Active" attribute is supposed to be set explicitly by using the -Active flag when running the New-FSRMFileScreen cmdlet, which I'm pretty confident I'm not somehow inserting into subsequent iterations of the loop.

This is an issue, because we do actually want the files to be written to disk in the event of a Cryptowall infection on an endpoint. The malware generally writes files into the affected directories with "helpful" instructions on how to pay a ransom, and this is meant warn us as soon as possible that something is going on. If the file screen actively blocks the files from being written to disk, it becomes more difficult to identify affected files after the fact.

So is this a bug, or did I make a mistake?

1 Answer 1

3

Is there some reason why you aren't passing the -Active:$false switch to explicitly set the option to false? I haven't tested, but this certainly seems like it should force it to be off always.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .