5 Replies Latest reply on Apr 9, 2016 8:29 AM by alhaawi

    McAfee's Crazy Rasomware recomendations

    eobiont

      I have a problem.  Intel Security has released a document called "Combating Ransomware" and it is making the rounds with our management level.

      It has been passed to me to look at and implement, but the recommendations are super crazy and impossible to implement.

       

      This makes me look bad because I have to tell those folks that the recommendations are super crazy and cant be implemented.  Why would McAfee put out a recommendation that cannot be implemented they want to know.

       

      Well...  Here is a "for example"

       

      In the "Combating Ransomware" document for CryptoLocker v. IV Rule number four suggests a user defined Access Protection rule of

      Processes to include: *

      Processes to exclude: rundll32.exe, winlogon.exe

      File or folder to block: *.scr

       

      I turned on this rule in "report only mode" and had > 1/4 of a million hits in the first day!!

      rundll32.exe and Winlogon.exe are by far not the only processes that legitimately call *.scr files.

       

      Almost all screensavers get called where the calling process is the screensaver itself.  Like 

      The threat source is :C:\WINDOWS\SYSTEM32\LOGON.SCR  the Threat target is:C:\WINDOWS\SYSTEM32\LOGON.SCR

      The Threat Source is:C:\Windows\system32\PhotoScreensaver.scr  threat target is C:\Windows\System32\PHOTOSCREENSAVER.SCR

       

      Like I said, there have been 250,000 hits in the first day.  If I sorted though the exclusions just on this rule alone, It would take me all day and into the weekend and I would need to have HUNDREDS of process exceptions including for explorer.exe, svchost.exe, etc and if I have to exclode those, then what is the point?

       

      On the other hand no one believes me when I say the rule is ridiculous because if it was, then why would McAfee be suggesting it as a way to combat CryptoLocker?  It MUST be a good rule if Intel is proposing it...  UGH.

        • 1. Re: McAfee's Crazy Rasomware recomendations
          wwarren

          On the other hand no one believes me when I say the rule is ridiculous because if it was, then why would McAfee be suggesting it as a way to combat CryptoLocker?  It MUST be a good rule if Intel is proposing it...  UGH.

          Sorry about that.

          Tell those folks that Intel Security folk feel obligated to provide every plausible avenue or to leverage every mechanism available in combating the malware threat. They're not intended as a "This will work for you and everybody else".  The particular example you cite contains AGGRESSIVE rules, which will be subject to false positives. But for an environment that doesn't run screensavers... or logon scripts... there are many environments out there that run with a LockDown type of configuration.

           

          Instead of writing them off as crazy, you might assess if there's an implementation that provides similar or better protection; something more suited to your environment.

          e.g. instead of blocking SCR at the client, block it at the gateway.

           

          I agree with you, these should not be interpreted as "You must do this".  We also avoid providing you rules that turn your system into a brick.  And, because that has happened before (someone misreads a policy or Typo's a path entry), always exercise care when implementing Access Protection rules.  Putting it in REPORT mode to start with is smart, until you're confident no adverse effects could come of it being set to Block.

          • 2. Re: McAfee's Crazy Rasomware recomendations
            eobiont

            Believe me, new access protection rules stay in report only mode for weeks before I ever would consider checking that "block" box.  Some of these rules are real clunkers though.  I can't even afford to leave a rule in report mode that dumps 300,000 hits to the event log each day.

             

            What would make Access Protection useable in these circumstances would be if there were a way to specify exclusions in the target path.

             

            Like don't let any *.scr files to be executed except for ....  But the only exclusions are available for the calling process, and that is not enough in almost all cases.

             

            I have very few executables that I need to let users run out of AppData, but I do have a few.  Unfortunately, the Access Protection rules are all or nothing, so either I block all exes or none.  I wish there were a way for me to exclude particular targets in the File target value.

             

            like block access to all **\Users\**\*.exe except for this list  [myprogram.exe,myotherprogram.exe,etc].  I have to trow out the good with the bad, and since I absolutely cannot block the "good" I also am unable to block the "bad".  There is just no way to write exclusions that are effective.

            • 3. Re: McAfee's Crazy Rasomware recomendations
              wwarren

              Yes, you are describing a problem that we solved with Endpoint Security 10.1.

              The expanded capability of the Access Protection feature in that release is a welcome relief.

              • 4. Re: McAfee's Crazy Rasomware recomendations
                eobiont

                I've started reading about that.  I may not be fully understanding the product, but my initial though is that the idea of a single policy to cover the whole suite is a real stinker.  But that is a whole different discussion.

                • 5. Re: McAfee's Crazy Rasomware recomendations
                  alhaawi

                  hi eobiont

                  I am testing the same thing!

                  300k hits! how many systems you have?

                  now I am testing the rules, the one I got many hits is rule number 3 from

                  Generic mildly aggressive Access Protection Rules

                   

                  we should disable the report though if we have too many events from rule number 3.

                   

                  now regarding HIPS protection

                  did you try this? on page 5 of the document

                  CryptoWall

                  HIP signatures 6010 and 6011 block the injection immediately. Ensure they are enabled.

                  I tried them and it blocked browsers and acrobat and I have to exclude them