• State Suggested Answer
  • Replies 16 replies
  • Answers 2 answers
  • Subscribers 14 subscribers
  • Views 10470 views
  • Users 0 members are here
Options
Related

False Positive Alerts

benybb
over 3 years ago

Hello!

I installed for the first time Intrust agent on Terminal Servers.

I just can't find the reason why but :

I am receiving 2 specifics alerts from all my terminal servers (hundred of times per day).

The Alerts have been causing by the server computer name itself!

Here are the alerts : 

First to come is :

InTrust Major alert - Multiple failed logons by the same user.

There were 5 failed logons by user domain.com\MSTS-TAL1 from workstation MSTS-TAL1.

Alert was generated on computer msts-tal1.domain.com.

The Second Alerts is :

InTrust Major alert - Multiple failed logons from the same workstation.

There were 5 failed logons from workstation MSTS-TAL1.

Alert was generated on computer msts-tal1.domain.com

I just can't find what process or service causing that.

It's Happening every 10 minutes or so in every single Terminal Server.

What's best to do?

Is there a way to filter out the "computer":     "domain.com\SERVERNAME"      from this alert ?

IS IT a known false alert for terminal SERVERS that you know about maybe ?

Thanks inADvance ...

100

Parents
  • 0 over 3 years ago

    Hi benybb,

    Let's try the following change. Open the rule properties, go to the Matching tab, click Advanced, click Find on the toolbar (binoculars icon), type "EventID = 4625", and find the last occurrence of this string in the rule text. Now type the additional condition right after: change "EventID = 4625" to "EventID = 4625 and not striequ(String6, String14)". If you see "Z." before EventID, just ignore this fact, because "EventID = 4625" and "Z.EventID = 4625" mean the same in this context. Click OK, and then commit your changes. Do the same with the second rule. This additional condition should filter out all the events where user name and workstation name are the same.

  • 0 over 3 years ago in reply to Igor.Ilyin

    UPDATE :

    Some Terminal servers still send me : (Multiple failed logons from the same workstation)

    but not :

    Who's the user that tried and failed (Multiple failed logons by the same user)

    Probably the "Multiple Failed" is still from the Server Itself.....

    Thanks in advance

  • 0 over 3 years ago in reply to benybb

    The rules should work well once they reach the agent. Try to find them in the CFG folder like you did in one of the previous threads.

  • 0 over 3 years ago in reply to benybb

    Regarding the rule "Multiple pre-authentication failures", most of our predefined rules still contain conditions for Win XP machines, it's OK to get rid of them and simplify a bit, here is the simplified rule text which you can substitute in Advanced rule editor:

    <prefilter>
    EventID = 4771;
    </prefilter>
    <body>

    count( select( Z.EventID = 4771,
    <parameter name="Time period"></parameter> ) )
    &gt;=
    <parameter name="Threshold"></parameter>

    and set_alert_field("UserIP", String7, true);

    </body>

  • 0 over 3 years ago in reply to benybb

    Regarding "Still getting hundred of alerts for  DOMAIN\COMPUTERNAME$", let's make another change as we did above, "EventID = 4625 and not striequ(String6, String14) and not( in( String6, "bi", ".*\\$" ))". I believe this is only Terminal Server specifics.

  • 0 over 3 years ago in reply to benybb

    Regarding "I get all the alerts exactly 3 hours later" - this is the most interesting problem to me, which might mean you have overloaded your InTrust configuration. Could you please tell something about the number of agents in your lab and the number of rules sent to each?

  • 0 over 3 years ago in reply to Igor.Ilyin

    Hi Igor 

    Regarding the rule "Multiple pre-authentication failures" - Made the change and still not working - I don't get any alerts on any RDP LOGIN FAILED...

    We will try to open a support ticket to Quest (by our provider) for that - It seems to me that there is a problem with my PDC (it is one of my 8DC's).

    All the events like 4771 (RDP LOGIN Failed) or like 4740 (LOCK ACCOUNTS) exists in my Event Viewer PDC  but Intrust won't alert me on them  - Somethings Wrong.

    I Noticed that if those events arrive at Other DC's, they are handled (and send alerts)  just fine - 

    (Sadly for us, Most of the Events get to the Primary DC)

    Do you have any thoughts on that?

    Anyway - Just for your information :

    We have 8 DC's with Change Auditor and Intrust agents.

    We have about 150 Win Servers with an agent (among them about 15 Terminal Servers)

    And also something like 600 Agents on Regular Windows Pc's.

    Any events on Windows PC Like  for example "Change Password Attempt on Administrative Account"   are alerting me right away - no delay ...

    ******************

    Regarding "Still getting hundred of alerts for  DOMAIN\COMPUTERNAME$" - I mistake about the rule...

    The rule that sends me hundred of Emails with "DOMAIN\ComputerNAME$" is :

    InTrust Minor alert - Change Password Attempt on Administrative Account.

    (those alerts happened on any windows pc)

    2 THINGS : 

    First: Is the rule Perform on AGENT or  SERVER mode?

    Second: How can i change this XML exactly to ignore those computer names, please?

    ( i tried alone with no luck)

    Thanks for everything!

     

  • 0 over 3 years ago in reply to benybb

    "Multiple pre-authentication failures" - if the rule is in the Agent's (DC's) CFG folder, then it is strange it does not work. What about PDC load? Does it have enough resources, are there any resource bottlenecks? Also what are the CPU amd MEM usage of the InTrust agent process (adcscm.nt_intel.exe)? Yes, it's ok to open a support ticket, also can organize webex session directly with me.

  • 0 over 3 years ago in reply to benybb

    "Change Password Attempt on Administrative Account" - AGENT or SERVER mode - this is set on the Matching tab of the rule. You can set any, but it should be AGENT for this rule, SERVER mode has no sense here.

    Well, you ask to ignore something, but why do you think it should be ignored? InTrust reports about multiple change password attempts, maybe you should investigate why you have so many change password attempts? I mean resolve this issue in the environment. Please consider this option first. Also it is not clear to me, do you have DOMAIN\COMPUTERNAME$ as a target account or originator account? Could you please post a real example of email.

  • 0 over 3 years ago in reply to benybb

    Also I have some general recommendations for you. Looks like you are receiving hundreds or thousands of alerts into your Alert database. I have to say that receiving hundreds of alerts, at least from the same rule, is not a normal situation. Firstly, you have to investigate why this happen and try to resolve a possible problem in your environment. Secondly, you have to clean-up alerts from the Alert database because the more alerts you have the less is the whole system' performance. You can use "Weekly Alert Database Reporting and Cleanup" task located in the "Tasks | Predefined tasks" folder.

  • 0 over 3 years ago in reply to Igor.Ilyin

    Thank you for the responses.

    1. Regarding "Multiple pre-authentication failures" - I would like to schedule a Webex with you - just tell me when (i am at IST time)

    What do i need to do for that to happen?

    2. Regarding "Change Password Attempt on Administrative Account"  -  it's happened only in a few computers that I sadly don't have full control on them and therefore cannot perform troubleshooting properly on them (Academic rules - go figure...) - it's probably a policy in GPO that does that - I just assume.

    I thought that they should be ignored because I tried a few times (real-time) to RDP the pc that sends the alerts and found nothing unusual in there...

    Here is a full alert mail like you requested (Notice that its always created by the computer itself) :

    There was administrative account password change attempt by DOMAIN\WYL313-54-216$ user. Target account: WYL313-54-216\admin.

     

    Alert was generated on computer WYL313-54-216.domain.com.

    Alert was generated at Sun Jun 14 10:54:29 2020 (Sun Jun 14 07:54:29 2020 GMT).

    ************************************************************

    3. Regarding : too many alerts on database - i tried the cleanup but it failed :

    Reporting job "Weekly Alerts Reporting"  Summary: Started at: 6/15/2020 10:46:00 AM (GMT: 6/15/2020 7:46:00 AM) Completed at: 6/15/2020 10:46:03 AM (GMT: 6/15/2020 7:46:03 AM) Completion status: Failure Status description: Connecting to http://sql2016.domain.com/ReportServer failed with error: No connection could be made because the target machine actively refused it 10.1.12.101:80 

    I checked the FW and port 80 is open for sure ...

    Something i need to change in the SQL SERVER?

    P.S : Because GDPR is applying on us -  we need to keep 24 MONTHS data -  are those cleanups interfere with this obligation ?

    (i am just sorry that i get so many errors for the same system (also sad to bothering you) - but that's the reality)

    Thanks in advance

  • 0 over 3 years ago in reply to benybb

    Webex results:
    1. Alert clean-Up job works well.
    2. Reporting job does not work due to no connectivity with SSRS - need to fix on your side.
    3. The PDC problems exist due to this machine overload, with excessive amount of rules and also maybe because of low performance of the machine.
      a) the trace data says that InTrust agent can hardly read the security log, the events date is 13 hours behind: ( 7104) Wed_Jun_17_12.54.45.565_2020 | 40 | [032f6e90] RTCEngine: Event time Tue Jun 16 23:25:59 2020
      b) the difference between DC and other machines that work fine is that on DC InTrust is trying to resolve SIDs, GUIDs and other strings in all events.
      c) the recommendations are reducing the number of rules on the DC and/or improve the machine performance (SSD, CPU, RAM).

Reply
  • 0 over 3 years ago in reply to benybb

    Webex results:
    1. Alert clean-Up job works well.
    2. Reporting job does not work due to no connectivity with SSRS - need to fix on your side.
    3. The PDC problems exist due to this machine overload, with excessive amount of rules and also maybe because of low performance of the machine.
      a) the trace data says that InTrust agent can hardly read the security log, the events date is 13 hours behind: ( 7104) Wed_Jun_17_12.54.45.565_2020 | 40 | [032f6e90] RTCEngine: Event time Tue Jun 16 23:25:59 2020
      b) the difference between DC and other machines that work fine is that on DC InTrust is trying to resolve SIDs, GUIDs and other strings in all events.
      c) the recommendations are reducing the number of rules on the DC and/or improve the machine performance (SSD, CPU, RAM).

Children
No Data