Crypto Monitoring - Alert tripped when user does exports to Excel

I reviewed the 3 part series on monitoring for Crypto viruses and have setup my alerts for my file servers. I set the threashold for 50 files in 1 minute for any single user by setting:

Log - Security
Event Severity - Audit Success
Filter Settings - Include
Event Source - Microsoft-Windows-Security-Auditing
Event ID - 4663

Threshold - 25 in 1 minute

For Threshold Options I set to match events based on Insert String 1 so that I only get an alert when any 1 user writes 50 files. This works great except for one issue.

The issue I am seeing is that we have some report utilities that can export files to Excel and other formats. When they do this, they appear to write the Excel file block by block which can cause about 100 write actions for a single file and this ends up triggering the alert.

Is there an additional way I can filter the events so that I am only counting 50 unique files written in 1 minute?


  • Hi Jordan,

    Thanks for the feedback. This is an interesting challenge, but there should be a way around it. We'll do some testing on our end and will let you know as soon as we have a solution. Please check back shortly.

    Thank you!
  • Hi Jordan,

    There is a way to get avoid a false alert if the same file is written to. It does make the setup a bit more complicated, but we can utilize EventSentry's timer filter capability to clear a pending Crypto alert if the same file is written to more than X number of times within a configured time period.

    The only downside is that this approach will delay the execution of the preventive anti-crypto action by a short time (e.g. 30 seconds).

    You would end up with the following filters (more details below):

    #1 4663 Same File (threshold filter)
    #2 4663 Bulk File Write (threshold filter, similar to what you already have)
    #3 Crypto Alert (timer filter)
    #4 Clear Crypto Alert (clears timer filter)

    The flow is actually pretty straightforward. The 2 threshold filters (1 & 2) do nothing but look for 4663 events, and log event 10601 if their respective threshold is met.

    I've added the "4663 Same File" alert, which will log a 10601 if the same file is being changed X number of times. It's identical to the filter you already have except that it uses insertion string 7 (which contains the file name):

    The 2nd 4663 filter is mostly identical to the filter you already have, except that I configured it to neither process events before nor after the threshold is met (just like the previous filter). That filter also generates a 10601 event when a single user generates X number of write events.

    * For versions up to, the two 4663 filters have to reference a different action (I suggest a dummy action for the first 4663 filter), so that they don't block each other.

    * The threshold in filter #1 should be higher than the threshold in filter #2, since filter #1 needs to be triggered after filter #2 (more below).

    The "Crypto Alert" filter looks like this:

    Note that the action in the screenshot is "Desktop", you will want to replace that with the script you run which will stop the server service (or whatever else you want to do). The timer interval determines how long EventSentry waits for a 2nd threshold before it triggers the action.

    And this is the biggest difference between this configuration and the more simple setup from the blog. Now, we don't have the threshold filter itself trigger the action. Instead, we configure a chain reaction where the threshold filter generates the 10601, and the timer filter subsequently triggers the corrective action - but ONLY if "Same File" threshold is not met within 30 seconds. You can experiment with this, I suspect that the timer period can be set much lower, depending on the speed of the 4663 events being generated by the export.

    This is what the 2nd "Clear Crypto Alert" timer filter looks like:

    Here is the chain reaction summarized with a "standard" crypto infection:

    1. A user is infected with Ransomware, which in turn starts modifying files on behalf of the user on the server and triggers the threshold of filter #2
    2. Filter #2 logs event 10601
    3. Filter #3 sees event 10601 and starts a timer
    4. Filter #3 triggers its configured action (e.g. turn off server service)

    Here is the chain reaction summarized with a user running a report:

    1. A user runs a report and triggers a lot of 4663 events, all for the same file
    2. Filter #2 logs event 10601
    3. Filter #3 sees event 10601 and starts a timer
    4. Filter #1 logs event 10601 after (since it has a higher threshold)
    5. Filter #4 sees that event 10601 and clears the timer setup by filter #3
    6. No corrective action takes place

    I hope this makes sense, let me know if you have any questions please.

Sign In or Register to comment.