Core issue
In this issue, the CSA MC continues to flag certain programs as rootkits. A rootkit can be detected when module loads after boot time or a module attempts to modify kernel functionality. Note that if a rootkit gets marked as both trusted and untrusted, a trusted rootkit gets precedence over an untrusted rootkit tag.
The rootkit Lockdown Module was put into the default policies as it is useful to detect drivers that load after boot time. On some systems especially those with many software installed, there can be many drivers for which you need to make an exception. In regards to this potential, root Lockdown Module was put into testmode by default and anticipated that the customer takes the module of testmode when it is ready.
Resolution
In order to resolve this issue, make an exception for the ROOTKIT detection module with these steps:
- Go to the event log.
- Choose the blue change filter link.
- In the filter text field, enter the word UNTRUSTED.
- All events with the word UNTRUSTED appear.
For example:
Kernel functionality has been modified by the module C:\WINDOWS\System32\DRIVERS\TPInput.sys.The module 'C:\WINDOWS\System32\DRIVERS\TPInput.sys' is monitoring the keyboard.The specified action was taken to set detected rootkit as Untrusted. Details Rule 46 Wizard
Note: Rule 46 is in: the System Hardening Module [V5.0 r176] Rules Kernel protection [46]
- Use the wizard in order to make exceptions for all events that mention a *.sys file, drivers that load after boot-time. You can also use the wizard for one or two of the *.sys events and manually enter all other legitimate *.sys files.
Note: Make sure you choose the same policy in the wizard in order to place all your exceptions for this particular issue. Then, you can track the exceptions you made.
- The next step is to change the state of the hosts from rootkit detected to normal. You need to do this because when a host is in a rootkit detected state, it does a network lockdown with the priorty deny attribute, which is formerly high priority deny. Thus, it generates many events in the event log, but the action actually is not denied because the rule module is in testmode.
- In order to do, this, choose the group that the host(s) belong and choose Reset Cisco Security Agents in the quicklinks section. Then choose System State. This changes the state of all your hosts back to normal at the next polling interval.
- You can also go to the hosts page and reset the agent state individually with the same instructions previously listed.
Refer to the System State Sets section of Rule Module Configuration for more information.
