5 Replies Latest reply on Oct 29, 2014 10:18 AM by odin13

    Mastering the filter/rule Creation Engine...

    shadowhawk100

      Hi guys...

       

      I've only been working with LEM for about a week now and I must say that I am quite impressed by the possibilities I can foresee with this program. I have been tasked by my company to master LEM so that I can essentially take over the responsibility for managing it. I'm a learn by doing kind of guy... The problem that I'm running into is coming up with real-world scenarios that I can implement in the engine. Is there in existence any such list of questions/example tasks that LEM is made to fulfill that I can teach myself with through practice?

       

      If not, I vote that we start a forum here and you guys (The awesome LEM community) post scenarios that you have run into so that future LEM-noobs have a place to start and learn the program through practice. What would even be more awesome would be to see successful implementations of posted questions so that best practices could be established.

       

      Thanks!

      John

        • Re: Mastering the filter/rule Creation Engine...
          byrona

          If you haven't already checked out the LEM videos then I would strongly recommend doing so.  I used those to learn much of what I know about it today.  Those can be found HERE

          1 of 1 people found this helpful
          • Re: Mastering the filter/rule Creation Engine...
            pmcdougal

            A good real world example rule is based off the rule template Critical Account Logon Failure.  This rule is great at catching someone trying to guess user passwords without locking accounts.

             

            For instance PEN testers/hackers will have a script that will attempt a logon twice using a common password or variation and then move to the next IP on the network to keep from locking accounts.  Commonly they will try hitting the default local administrator account “administrator”. This account by default is in the user defined group, but if you rename that account on your PC’s/servers you should add that account to the user defined group.

             

            The default rule is built as

            1. UserLogonFailure.DestinationAccount contains User Defined Group(Admin Accounts)

             

            By default the User defined group Admin Accounts contains “Root” and “Administrator”

            If you rename that account on your PC’s/servers you should add that account to the user defined group.

            You should also add any none Active Directory based privileged account to the User Defined group

             

            I then like to expand the rule to cover my privileged Active Directory accounts


            UserLogonFailure.DestinationAccount contains UDG(Admin Accounts)

            OR

            UserLogonFailure.DestinationAccount contains DirectoryService Group(Enterprise Admins)

            OR

            UserLogonFailure.DestinationAccount contains DirectoryService Group(Domain Admins)

            OR

            UserLogonFailure.DestinationAccount contains DirectoryService Group(Schema Admins)

             

            Etc…. for any other Active Directory user group that has privileges

             

            The rule by default creates an incident alert, which will create a record in the incident report.  If you are looking at your incident report daily a scripted attack such as described above will be very obvious.

             

            If you change the action to something else like creating an email, you can easily watch the scripted attack move through a network.  This is great fun when you can tell your Pen Tester exactly where they are at, on your network.

            1 of 1 people found this helpful
            • Re: Mastering the filter/rule Creation Engine...
              shadowhawk100

              @byrona ... The videos in that section provide a decent overview of LEM functionality and have a few advanced examples, however, they are generally too basic for what I am looking for. Thanks though ... I'm looking for people to give me scenarios that I can work through so that I can teach myself (truly learn) the software... You know, kind of like doing your math homework

               

              @pmcdougal ... I appreciate the scenario ... you forced me to learn about incident reports which was a nice bonus ... I'm hoping that we get more scenarios like yours or even more advanced ones.

               

              I'll mark as "Correct Answer" the answer which helps me the most in my learning progession and has the neatest scenario to implement... so far thats you mcdougal

                • Re: Mastering the filter/rule Creation Engine...
                  pmcdougal

                  Another good rule template is called the Kill Suspicious Process

                  Requirement for this rule: Group policy enabling process tracking.  (Caution: process tracking can be very chatty, not all environments can handle it)

                   

                  Default Rule

                  Correlations

                  ProcessStart.ImageFile = *.*.*

                  AND

                  ProcessStart.ImageFile NOT CONTAINED IN UserDefinedGroup (Safe Processes)

                   

                  Action

                  Kill Process By Name

                   

                  The key to this rule is to identify all safe processes on your network.

                  The default User Defined Group contains a bunch of common processes, but not all.

                   

                  Hint:

                  Create a rule to capture all your processes so you can decide what is safe in your environment.

                  Then a second rule to block anything not deemed safe

                   

                  Rule# 1

                  Requirement – clone the default Safe Processes user defined group – make it your own

                   

                  Correlations

                  ProcessStart.ImageFile = *.*.*

                   

                  Action

                  Add User-Defined group Element

                                                  User Defined Group = Your version of Safe Processes UDG

                                                  Value = ProcessStart.ImageFile

                   

                   

                  Let this run for a few days to get a good record of your environment, then turn it off.

                  Review the UDG to determine what you consider safe, delete anything not considered safe from the UDG

                   

                  Now start rule #2

                  Correlations

                  ProcessStart.ImageFile = *.*.*

                  AND

                  ProcessStart.ImageFile NOT CONTAINED IN UserDefinedGroup (Your Safe Processes UDG)

                   

                  Action

                  Kill Process By Name