none
Asking for the explanation behind the pass-the-ticket alert when one kerberos ticket was used on two different machines RRS feed

  • Question

  • Hello,

    I came across an unusual pass-the-ticket ATA alert. Please take a look below:

    Time (UTC)    Source Ip Address    Source Computer   Source Computer Resolution Method                Destination Ip Address
    06.10.2017   20:01:58,538           10.***.**.**1        LT******1           Netbios, RpcNtlm, Hint, Cached    10.***.***.*3
    06.10.2017   20:05:29,289           10.***.**.**1        LT******1           Netbios, RpcNtlm, Hint, Cached    10.***.***.*3
    06.10.2017   20:45:52,151           10.***.**.**2        LT******2           Dns, Cached                                 10.***.***.*3
    06.10.2017   20:45:52,615           10.***.**.**2        LT******2           Dns, Cached                                 10.***.***.*3
    06.10.2017   20:45:54,432           10.***.**.**2        LT******2           Dns, Cached                                 10.***.***.*3
    06.10.2017   20:45:55,707           10.***.**.**2        LT******2           Dns, Cached                                 10.***.***.*3
    06.10.2017   20:45:56,770           10.***.**.**2        LT******2           Dns, Cached                                 10.***.***.*3

    As you can see, the LT******1 machine had the 10.***.**.**1 IP address assigned at 20:01 and 20:05.

    However, the kerberos ticket from the XXX user was used on the LT******2 machine that had the 10.***.**.**2 IP address assigned to it at 20:45.

    The other logs (different technology) indicate that the 10.***.**.**2 IP address was assigned to the LT******1 machine at 20:45 and the user in question was logged in.
    However, the same logs indicate that the 10.***.**.**1 IP address was assigned to the LT******1 machine at 20:45 and the user in question was logged in.

    Since after authentication the TGT file is granted to a user for data traffic protection by KDC, is it possible that:

    1. the user was logged into the domain on two different machines with two different IP addresses at the same time
    2. there was an IP address conflict and one IP address was assigned to two different machines

    Please note that the LT******1 machine is located in location #1 and is assigned to the XXX user whereas the LT******2 machine is located in location #2 and is assigned to the YYY user.

    May I know what your thoughts are?

    Thank you very much in advance.


    Regards,
    MSSOC

    • Edited by MSSOC Wednesday, October 18, 2017 7:58 PM
    Wednesday, October 18, 2017 7:51 PM

Answers

  • As for the DNS, no, I don't know how exactly it would happen, I only said that if it did, it would provide ATA with false info.

    As for the VPN, it can explain how the same ticket would suddenly appear from a different IP, but it still does not explain how the new IP was attached to a different machine name, so there are 2 options:

    Either DNS was wrong, or the short time cache we had was invalid - thus a FP,

    or, if we can't explain it, it could always be a TP.

    • Marked as answer by MSSOC Wednesday, October 25, 2017 9:11 PM
    Wednesday, October 25, 2017 7:41 AM

All replies

  • #1 should not cause this, so that's not it.

    I never got to see it happens, but I guess if there really was an IP conflict it could have caused it.

    The question is if you can prove there was indeed a conflict at the time.

    Wednesday, October 18, 2017 7:58 PM
  • Dear Eli Ofek,

    Unfortunately, I have no proof that it was the conflict. It was just my assumption.

    Based on your experience and knowledge, what might be the most likely root cause behind this scenario?

    Maybe there is something I need to check on?

    Regards,
    MSSOC

    Wednesday, October 18, 2017 8:01 PM
  • There are several factor that can cause a FP on this one.

    you can see some of them mentioned here:

    https://docs.microsoft.com/en-us/advanced-threat-analytics/suspicious-activity-guide#identity-theft-using-pass-the-ticket-attack

    Wednesday, October 18, 2017 8:08 PM
  • Dear Eli Ofek,

    I am familiar with those common root casues but none of them seem to be the case here.

    ATA seems to rate the likelihood of LT******2 as the hostname as low. Is this something important here?

    What is the difference between "High" and "Low" in terms of the "Source Computer Certainty" column?

    Regards,
    MSSOC
    Thursday, October 19, 2017 12:32 PM
  • Dear Eli Ofek,

    I actually think that the "Source Computer Certainty" value will not affect this scenario.

    I feel that the source computer certainty was low in that case as it referred to the DNS lookup resolution method. The certainty would be most likely high if it came directly from the machine and not the DNS server.

    @Anyone: does anyone know why one kerberos ticket was used on two different machines in this scenario and why the alert was created?

    Anyone's explanation here would be highly appreciated.

    Regards,
    MSSOC
    Thursday, October 19, 2017 4:51 PM
  • Yes, you are correct about certainty.

    We consider DNS resolution low because it's less reliable and more easily spoofed.

    If DNS in this case was spoofed or not updated correctly, it might have caused the issue.

    Also, you need to understand why we fall back to DNS. Normally we would try NetBios and NTLM/RPC first,

    But we were blocked from using them on  LT******2  .

    Sunday, October 22, 2017 8:57 AM
  • Dear Eli Ofek,

    Do you really think that DNS not being updated correctly might have caused this alert? Can you justify this in more details, please?

    Also, I did some digging in my environment and have one question/suggestion. The user who used one kerberos ticket on two different machines with two different IP addresses suddenly switched to VPN from the internal network. Might be something related to this the root cause here? The VPN subnets cause lots of ATA alerts to appear.

    Regards,
    MSSOC
    Tuesday, October 24, 2017 11:24 PM
  • As for the DNS, no, I don't know how exactly it would happen, I only said that if it did, it would provide ATA with false info.

    As for the VPN, it can explain how the same ticket would suddenly appear from a different IP, but it still does not explain how the new IP was attached to a different machine name, so there are 2 options:

    Either DNS was wrong, or the short time cache we had was invalid - thus a FP,

    or, if we can't explain it, it could always be a TP.

    • Marked as answer by MSSOC Wednesday, October 25, 2017 9:11 PM
    Wednesday, October 25, 2017 7:41 AM
  • Dear Eli Ofek,

    Thank you for the explanation.

    The Dns, Cached resolution method for the LT******2 machine within the VPN subnet indicates the root cause here, then.

    Regards,
    MSSOC

    Wednesday, October 25, 2017 11:51 PM