locked
False alarm about "Malicious replication of directory services" - both source and destination are DC's and this is possibly IPv6/DNS related RRS feed

  • Question

  • Hello,

    We received an alarm from ATA with title "Malicious replication of directory services" and description is "Malicious replication requests were successfully performed from (DC-01's IPv6 address) against (DC-02 FQDN)."

    We are using version 1.8.6765.36693.

    DC-01 and DC-02 have "normal" IPv6 addresses configured but ATA has only the Link-local IPv6 address, and ATA is not part of the domain.

    I can ping from ATA to DC-01's Link-local IPv6 address but not the normal IPv6 address. And when I do nslookup from ATA searching DC-01's FQDN, it does return DC-01's normal IPv6 and IPv4 addresses to ATA.

    Also in ATA the domain name has been configured in the IPv4 and IPv6 vNIC DNS suffix settings so I can ping both DC-01 and DC-02 with their hostnames and it will resolve automatically to the FQDN. i.e. pinging dc-01 with resolve to dc-01.domain.com

    Does anyone know how to fix this? It would seem that probably assigning a "proper" IPv6 address to ATA might solve the issue, but then again ATA does get the DC-01's IPv6 address when using nslookup so shouldn't it be able to figure out that the address is for the DC-01 anyways?

    Thanks!






    Monday, October 2, 2017 1:35 PM

Answers

  • You need at least 135 OR 137 for high certainty resolution.

    We do fallback to DNS if those are closed, but it is considered low certainty as DNS is easily spoofed. 

    BTW - this is true not only for the DC machine, ATA needs to access these ports for all machines in the network.

    • Marked as answer by Mika 192781 Thursday, October 5, 2017 11:58 AM
    Wednesday, October 4, 2017 7:39 PM

All replies

  • When ATA tries to resolve an IP address, it first tries to use Netbios or NTLM/RPC. if it fails to resolve the machine name with these methods, it falls back to DNS lookup. if all fail (as it seems so in this case), we can't resolve the IP, thus raise the alert as we don't know it's the DC.

    Can you make sure the ATA Gateway machine can access the DC machine either via TCP/135 or UDP/137 as specified in the docs:

    https://docs.microsoft.com/en-us/advanced-threat-analytics/ata-prerequisites#ata-gateway-requirements

    Eli

    Monday, October 2, 2017 6:50 PM
  • Hello,

    You also can read the following article, which introduces alerts in more details, and also helps investigate suspicious activities. It should help.

    https://docs.microsoft.com/en-us/advanced-threat-analytics/suspicious-activity-guide

    Best regards,

    Andy Liu


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, October 4, 2017 6:34 AM
  • Thanks,

    Both DC's have Windows Firewall enabled for inbound and outbound connections and we are using Lightweight Gateways installed on DC's. There are rules allowing inbound and outbound TCP/135 and UDP/137 but only for certain programs (like SVCHOST.exe, System, DNS.exe etc.) 

    So do we have to allow also Microsoft.Tri.Gateway.exe to connect using TCP/135 and/or UDP/137 for this to work? I mean that the Lightweight Gateway doesn't simply query the DNS.exe (or something similar) for the resolution?

    Wednesday, October 4, 2017 1:00 PM
  • You need at least 135 OR 137 for high certainty resolution.

    We do fallback to DNS if those are closed, but it is considered low certainty as DNS is easily spoofed. 

    BTW - this is true not only for the DC machine, ATA needs to access these ports for all machines in the network.

    • Marked as answer by Mika 192781 Thursday, October 5, 2017 11:58 AM
    Wednesday, October 4, 2017 7:39 PM
  • Thanks for the help,

    I allowed Microsoft.Tri.Gateway.exe for outgoing TCP/135 and UDP/137, let's hope this fixes the issue.

    Thursday, October 5, 2017 11:58 AM
  • It's not outgoing.. it's incoming to all machines.

    The GW needs to be able to connect via at least one of these ports to all the machines in the network which should be listening on those ports.

    Thursday, October 5, 2017 6:28 PM
  • I have seen the same issue with version 1.8.6645.28499. But in my case i'm using ATA Lightweight Gateways.

    Would expect the Lightweight Gateways to be able to resolve the "local-link" IPv6 address of the DC.

    Monday, November 20, 2017 5:19 PM
  • First, I strongly suggest to upgrade to Update 1.

    Second, that fact that there is a LWGW running on the source DC as well does not effect the resolution.

    technically, we don't use the information we have from the GWs themselves for resolution as this data can change, thus dynamic resolution makes better sense, and once configured correctly, it should work for any source computer, not just DCs which is a more general solution that we need anyway.

    Monday, November 20, 2017 8:26 PM