paulo vulpes

Hey Demiad, I appreciate you looking into this. To be honest I have to confess that I didn’t test mimikatz ahead of time. I was under the impression that I might need to block it myself manually. I just tested and confirmed that Kaspersky catches it automatically. Sorry for the trouble. Thanks again.

Hello, We’re looking to explicitly block Mimikatz from installing/running on our machines. Mimikatz is a pentesting tool capable of pulling passwords and hashes from system memory, and could be used for nefarious purposes. I’d like to think that Kaspersky would immediately flag/delete the installation of such a tool, but in the event that it does not, is it possible to block it at the Application Control level using the CARO malware naming scheme? For example, Mimikatz is designated as HackTool:Win32/Mimikatz.PTT. Is there a way to target this through Kaspersky? Otherwise I’m assuming I’ll need to add each file in Mimikatz to the Untrusted group in HIP and/or add any executable files to Application Control blacklist. Thoughts?

I’ve been tasked with figuring out a way to isolate an infected/compromised endpoint from the rest of the network. Is this a function that Kaspersky Security Center provides out of the box? I’ve currently achieved this by creating a new endpoint policy that uses the firewall component to whitelist all traffic between the endpoint and the server hosting Kaspersky Security Center followed by a second rule that blocks all other traffic inbound/outbound traffic. In this way the machine is cut off from the rest of the internal network and Internet except for our Kaspersky server. I then assign this policy to an empty group, and then place any compromised endpoints into this group to receive the policy. I just wanted to see if there’s an easier/better way of achieving this goal.

Hey alexcad, thank you for the response! Occasionally we’ll see in Unassigned Devices online clients that have Kaspersky Network Agent installed but that had gotten removed from our primary group because they had been inactive for longer than the set 90 days. If I disable polling, will these endpoints still show up in Unassigned Devices? I’m assuming the installed Network Agent will try to “phone home” as soon as the machine connects back to the Internet and will end back up/remain on this list, but that Windows endpoints that don’t have a Network Agent installed will not end up on this list if polling is disabled. Is this correct? Thank you!

Kaspersky Labs probably shouldn’t have redirected links from the old forums to point to whatever Kaspersky Club is, because again, it doesn’t have a professional look/feel and seems suspicious and also because I was unable to find any mention of what Kaspersky Club was anywhere else on the Internet, not even on Kaspersky’s website. While a lot of the information was old/outdated, the overall function of many of the Kaspersky Security Center components, for example, remain unchanged, and so even though the forum posts about those components may have been referencing obsolete versions, the questions about how they function that the documentation may not reference are still prescient.

Is Windows Domain polling (or any kind of polling) necessary after setting up KSC and deploying the Network Agent and KES software to your clients? We don’t use KSC to deploy software and the network agent on each client is configured to check in once every 15 minutes. My networking team has noticed that Kaspersky is scanning everything once per hour (as scheduled through the poll) and noticed that the scan seemed to be accessing SMB shares of servers as well, which they thought was strange as Kaspersky does not manage servers in our environment. They asked if the scan was necessary. We primarily deploy KES and the KNA to our endpoints via another third-party management appliance, so is there any additional value to be found in having this polling enabled?

Hey John7788, just wanted to thank you for asking this question. I started seeing this Kaspersky Club come up as well and thought it seemed very suspicious (not to mention barely readable). It’s disappointing that Kaspersky decided against retaining years of troubleshooting data (or at least against keep it publicly accessible). It would’ve been nice had Kaspersky Labs been more communicative of this change.

So I’ve confirmed that in most cases where KES 11.1 is pushed to a machine, the .pem certificate is intercepted and altered as the hash of the .pem file in C:\ProgramData\Dell\KACE\ is changed after KES 11.1 is deployed. The value of the .pem certificate hash taken before KES 11.1 or KES 11.2 is deployed is standard across our production environment, but gets changed to a random value in many cases after deployment, and it’s in these instances that the machines lose connection with our KACE appliance. I’ve done everything I can think of: whitelisting the correct SHA256 hash of the .pem certificate as a scan exclusion adding each of the KACE program directories as scan exclusions adding each manual EXE in those program directories as Trusted applications adding our Trusted Root Certificate Authorities to the Trusted system certificate store adding the domain name of our system appliance to the list of Trusted Domains. I have configured everything I can think of (please correct me if I’m wrong). It is very frustrating how much I have to wrestle with my company’s own antivirus application so that it doesn’t break another critical piece of infrastructure and it is frustrating when I escalate this to Kaspersky Support I’m mostly greeted with shrugs and suggestions of things I've already tried. I don’t understand how there isn’t a clear answer to this problem and with each passing week it is becoming harder and harder to justify to my company the retaining of Kaspersky Endpoint Security as our AV provider considering how difficult it is to manage or get support.

Hey Alex, Thank you for that information. It looks like you’re looking at the Trusted Domains section of Network Settings, in which the domain name of our appliance is already added as an exception. I can test with IP as well. I will also test with disabling the “scan encrypted connections” feature altogether just to possibly rule Kaspersky out though this behavior has only been observed to occur after a machine has been updated to KES 11.1 or higher.

Hi Alex, Thank you for the response. When you say “configure an exception for the communication of the application,” what do you mean specifically? Is there a specific option that if configured a certain way should allow this? I ask because I’ve already added every .exe in the C:\ProgramData\Dell\KACE directory as “Trusted applications”, also added that directory and every exe manually as “Scan Exclusions”, added the URL of our appliance in the list of “Trusted Domains.” Do you know of any other places in the policy that this can be whitelisted? I forgot to mention in the original post, but it seems that if you manually regenerate the certificate after Kaspersky intercepts it, Kaspersky leaves the regenerated certificate alone. I’m not sure why this would be the case.

I am in the process of upgrading a segment of our production environment from KES 11.0.0.6499 to 11.1.1.126. Last year a number of machines were successfully upgraded to KES 11.1.1.126 and even KES 11.2, however, back in April 2020 we discovered that any machine that had been upgraded to KES 11.1 or 11.2 was no longer checking in to our KACE K1000 Systems Management Appliance. We use this appliance to monitor machine metrics and deploy software. Earlier this year we upgraded the Kace Agent from 6.4 to 7.2, and in this new version a separate .pem certificate gets saved to C:\ProgramData\Dell\KACE\ and is used by the locally installed agent to communicate with the appliance. We believe that as soon as a machine that has Kace Agent 7.2 installed is upgraded to KES 11.1 or 11.2, Kaspersky intercepts and replaces the certificate used to facilitate that communication. As soon as the endpoint comes back from the restart to install KES 11.1/11.2, it loses communication, and if we look in the KACE Agent log, we see activity like this start to loop indefinitely: This behavior shows that when the KACE Agent starts it sees that the certificate has been signed by an unknown authority and will not allow it to connect. This happens only after the client restarts after installing a KES client higher than 11.0. As far as I know there is nowhere in the Endpoint or Security Center that highlights if/when Kaspersky replaces the certificate. The only known fix at this time is to regenerate the certificate manually client-side, which is not feasible for an organization of my size. I have whitelisted C:\ProgramData\Dell\KACE everywhere in the Kaspersky Security Center policy that I could find. I added the URL of our K100 Systems Management Appliance to the list of Trusted Domains. I even repackaged our Kaspersky Endpoint deployment entirely with install.cfg so that our policy comes installed with the endpoint on the off chance that Kaspersky is intercepting the cert before KES has a chance to check into our server. We checked with KACE Support to confirm what locations need to be whitelisted (and they already were). I have opened a few tickets with KL Support and am simply told that enabling/configuring this option here or that one there should do the trick, but it never does. I have spent an inordinate amount of time troubleshooting this issue and I am sick and tired of this. Has anyone else had to get these two technologies to work together or have any tips?

Hi Nikolay, Thank you for responding. Interestingly when I came in this morning, my computer had ceased to block these malicious sites along with the rest of our machines, so it appears that Web Control isn't functioning correctly across all machines in my environment. I am running the GSI log now. When it is finished should I post it here or send it to you? I am concerned that it contains unique, identifiable information for my environment. I am also scheduled to speak with a Kaspersky Labs support engineer four hours from now, so I can provide it then as well.

I discovered in our environment this past Friday that new URLs we add to be blocked via the Web Control component of our KES 11 policies in KSC (10.5.1781) are not getting blocked. Existing URLs in the Web Control component are getting blocked. I found that this was the case in two of our three primary policies. I ended up deleting the two policies that were not passing this correctly, copying out the third policy, and using it as a template to recreate the two original policies. I found that after doing this, my machine and my test machine (KES 11.1.1.126) were now blocking the URLs successfully. However, other machines in my environment (KES 11.1.1.126 and KES 11.0.0.6499) are still not blocking these URLs, even after forcing them to check in. It appears that this policy is not being applied uniformly across my environment. I don't know what's causing this to occur. Essentially the Web Control component in multiple policies is not being applied uniformly. This is a priority for us to resolve as it leaves us vulnerable. We are a Business Account. I've opened an INC in the support portal.

Hello, I understand that when a removable device is encrypted via Kaspersky Endpoint Security's file level encryption policy, a copy of the key is saved to Kaspersky Security Center, a location on the Kaspersky-managed computer that encrypted the removable device, and on the removable device itself. Where specifically in each of these locations is the key saved?

We're testing the removable device encryption policy in our environment. In a few instances we've found that a USB flash drive can be plugged into a computer that has KES 11 installed with a removable device encryption policy being pushed to it, and the policy fails to trigger. If we plug the same USB flash drives into other computers with KES 11 installed w/encryption policy getting pushed to it, the machines immediately prompt to encrypt it, so it's not an issue with the flash drives. We found in these instances that if we restart the Kaspersky Endpoint Security Service on one of these problem machines, either locally or from the Kaspersky Security Center console, the policy suddenly prompts to encrypt. Is this a known issue? Unfortunately I do not have one of these computers available to run GSI, but wanted to see if anyone else has had this issue. We're running 11.0.0.6499.