Jul 09 2020 01:30 PM
Jul 09 2020 01:30 PM
After a good number of implementations with normal service account I tried the first one using gMSA.
In the past, when AD Connect had the first sync after the sensor installations, I immediately had the Suspected DCSync attack alert on the timeline, without have to wait days of learning... This time I had no alert after hours (and a lot of full and delta sync). I also tried a Directory Service Reconnaissance (Directory Service Enumeration) from a client and still no alerts.
The sensor logs are clean (only showing this warning: EventActivityEntityResolver ResolveNtlmEventAsync).
In my experience is not a normal behaviour.
I verified the gMSA and the DCs could retrieve the account password correctly. The sensors services ar running.
Do you have any troubleshooting suggestion?
Jul 15 2020 02:00 AM
in my sensor.log I found a lot of this entries:
Debug NetworkAdaptersManager UpdateIpAddresses ignoring network traffic [ignoredNetworkAdapters= _ignoredIpAddresses=]
It could be a npcap driver problem related (even if I don't have nic teaming)?
my timeline is still desolately empty, after a week...
Jul 15 2020 07:56 AM
@Michele D'Angelantonio This line in the log is fine. it means you did not exclude any interfaces.
npcap can work without nic teaming.
Did you try to simulate attacks using the playbook and nothing showed up?
Any health issues in the console?
If not, I suggest to open a support ticket to diagnose possible causes.
Jul 15 2020 08:09 AM
thanks @Eli Ofek for your reply
I imagined that the line on log was fine comparing it with my others implementations but thanks for the confirmation.
I have not any alert on the health console.
on the tri.sensor log I have this entry (once a day):
2020-07-14 09:54:39.3243 Error HttpResponseMessageExtension Microsoft.Tri.Infrastructure.ExtendedHttpRequestException: Response status code does not indicate success: 500 (Internal Server Error). ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 500 (Internal Server Error).
at HttpResponseMessage System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at HttpResponseMessage Microsoft.Tri.Infrastructure.HttpResponseMessageExtension.CheckHttpResponseMessage(HttpResponseMessage httpResponseMessage)
--- End of inner exception stack trace ---
but after that on the log I have other entries like:
2020-07-14 10:04:23.7554 Debug DirectoryServicesResolver UpdateDomainControllerIpAddressesAsync domain controller [DnsName=DC2.mylocaldomain.it IsReadOnly=False IpAddresses=10.0.0.182]
2020-07-14 10:04:23.7554 Debug DirectoryServicesResolver UpdateDomainControllerIpAddressesAsync domain controller [DnsName=DC1.mylocaldomain.it IsReadOnly=False IpAddresses=10.0.0.181]
so it seems that is all ok
I have two suppositions:
- a problem regarding the gMSA account permission (in the log is explicit that the DC can retrieve the password without problems)
- a network configuration that block traffic from the sensor to the cloud
tomorrow morning I will have a troubleshooting session with the customer, if I can't find a solution I will open a support ticket.
Jul 15 2020 01:10 PM
@Michele D'Angelantonio The long entery you mentioned last indicates a communication issue , but if it indeed happens only once a day, it should not create the effect you are describing, so I don't think it's related.
As for your suspicions:
If the sensor would have failed to get the gmsa password, and it's the only ad account it has, it would have constantly crashed.
As for the blockage from cloud, if that would have happened, you would either experience startup issues, or a log full of communication errors.
Jul 16 2020 07:56 AM
Hi @Eli Ofek
I checked the implementation with the customer this morning.
I've noticed that on the activity page of the AD Connect server is not presente any dc sync related activity. I was aspecting something like the picture attached (I always see this data in any other implementation):
We installed the NPCAP driver but nothing is changed.
I think the sensor is not alalyzing some data, but I can't understand why.
Do you have any clue?
I think we will open a support case on the next days.
Jul 17 2020 10:18 AM - edited Jul 18 2020 04:11 PM
My Guess -> Don't add gMSA to domain admins or delegated permissions set.
Make sure your gMSA is correctly set before next step.
Remove AATP Installation.
Remove anything you've added including prior WinPCaps whether it was for Nmap, Suricata, etc.
Reinstall it using a fresh pull from the portal.
Do not go to Services and change anything like the user account. It needs to say as the Local Service.
Hope this helps.
Jul 18 2020 01:16 PM
This is a security risk, and is not needed for sure for AATP to run correctly.
the AATP AD account should be a low privileged user with read only access to AD, plus some specific permissions (SAMR, deleted items etc) for enhanced functionality.
Jul 27 2020 01:08 AM
Just for update:
I checked and fixed the gMSA account Domain User membership and now I can see more activities and some alarm.
I've the last strange problem. On the AD Connect server activity page I can see everityhing but the DC sync activities performed by AD Connect are still missing.
in other implementations it was the first alerts I had.