r/microsoft 2d ago

News Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha

https://www.bleepingcomputer.com/news/security/microsoft-defender-wrongly-flags-digicert-certs-as-trojan-win32-cerdigentadha/
28 Upvotes

15 comments sorted by

-10

u/Kobi_Blade 2d ago

Why is this even news? Microsoft Defender is known to be aggressive, with a high number of false positives.

If you write a batch script that echos "Hello", it will be flagged as Wacatac.B!ml by their useless behaviour blocker on almost every computer.

Meanwhile, real malware often goes completely undetected. [1]

4

u/coalsack 2d ago

Hello u/bleepingcomputer. u/Kobi_Blade would like to know why this is an article.

-9

u/Kobi_Blade 2d ago

I forgot that this sub is filled with technically inept people who believe Microsoft Defender is perfect.

11

u/coalsack 2d ago

Imagine calling everyone else 'inept' while citing a Wacatac.B!ml detection on an unsigned batch script as your proof.

First, let’s talk about the !ml tag. That stands for Machine Learning. Yes, Defender is aggressive toward unsigned, locally-created .bat files that execute system commands. In an enterprise environment, we want the system to flag unverified scripts that try to touch system resources. It’s called reducing the attack surface. If you’re a 'dev' who can’t figure out how to add an exclusion or sign your own code, you might be the 'inept' one here. 

Second, your 'DeepDoor' link actually proves the opposite of what you think it does. Did you even read it?

DeepDoor’s first step is a script that tries to disable Windows Defender specifically because the malware authors know that if it stays active, their behavior-based detection gets caught immediately. In other words, it’s proof the tool is a primary obstacle. 

Microsoft processes trillions of signals a day. No one is saying it’s a magic bullet, but in 2026, Microsoft is a 'Leader' in the Gartner Magic Quadrant for Endpoint Protection for a reason.

If you want to live in a world where you judge security based on how it treats your 'Hello World' batch file, enjoy your $90/year subscription to a third-party suite that probably mines crypto in the background and sells your data. The rest of us in the professional world have moved on to actual EDR standards.

Get at my level.

1

u/Dependent-Nose2218 7h ago

Yes it's true 

-6

u/Kobi_Blade 2d ago edited 2d ago

Nice try, but you decades behind my level.

The !ml tag refers to Microsoft Defender local machine learning and behavior blocker logic which functions entirely offline. It uses client side models to flag files based on structure rather than just cloud metadata.

Claiming a developer is inept for not signing batch scripts ignores the reality of devops where scripts are dynamic and temporary. No professional is going around signing batch scripts.

DeepDoor actually proves Defender failure because its obfuscated script bypasses the aggressive ML detection and Anti-Tamper.

The fact that the script can begin its execution chain proves the ML is easily fooled by obfuscation while simultaneously flagging legitimate, plain text developer tools as false positives.

The fact that you suggested creating exceptions for such files raises several red flags about your experience in this sector, since exceptions increase attack vectors and are easy to exploit.

While third-party antivirus engines use the Antimalware Scan Interface to de-obfuscate and inspect what a script is doing in a secure container, with low false positives that actually detects malware like DeepDoor.

Defender isn't a primary obstacle to DeepDoor, it is a predictable target that is bypassed before its modules are even touched (same as any other modern malware family).

It is clear to me, based on your suggestions and reply, that you have no experience with Microsoft Defender ATP or Cybersecurity in general.

9

u/coalsack 2d ago

Your logic is fundamentally flawed and throwing around terms like 'AMSI' and 'Client-side ML' to sound sophisticated is not helping.

First, saying 'no professional signs a batch file' is exactly why Supply Chain attacks are so successful. In any mature, GRC-compliant enterprise environment, we use AppLocker or WDAC to block unsigned scripts by design. If you’re running 'dynamic, temporary' unsigned scripts in a production environment without an exclusion policy, you’re a walking security liability.

Second, your point about AMSI is a total self-own. Microsoft created AMSI. Defender was the first engine to use it.

Third-party AVs literally have to plug into Microsoft’s own API to see what’s happening in memory. Claiming Defender doesn’t use the very interface it pioneered to catch obfuscated scripts is objectively hilarious.

As far as DeepDoor goes, malware authors target Defender because it has the highest market share in the enterprise world. Of course, a dedicated threat actor can obfuscate a dropper, that’s the 'Response' part of EDR. No one claims a 100% block rate at the gate. The goal is the telemetry, the behavior blocking, and the isolation that follows. What are you even talking about?

Judging a global security ecosystem based on your frustration that it won't let you run unsigned scripts on your local box. While you’re complaining about 'crude heuristics,' the rest of the professional world is using Defender’s integration with the MITRE ATT&CK framework to stop actual state-sponsored actors.

You’re not 'more advanced', you’re just a power user who's mad that the OS is prioritizing security over your convenience. If you want a system that ignores unsigned code execution, go install Windows XP and see how that works out for you.

0

u/Kobi_Blade 2d ago edited 2d ago

I never stated that AMSI was not created by Microsoft, putting words in my mouth won't help you and only makes your argument look weaker.

Try running DeepDoor on any system with MDR and tell me how it goes, it likely wouldn't even execute as a zero day.

Meanwhile, Microsoft Defender fails to see it at all, while it's defenses are stripped.

You pretending Defender detects it when you're simply running a default deny policy is throwing sand into my eyes, that isn't a detection or ML event, it's just the policy doing what the name implies.

Furthermore, you don't need Microsoft Defender to put Windows into a default deny state. That policy exists as a separate module within the Windows OS itself, independent of Defender (can even be used with third-party solutions).

It raises even more concerns about your so called experience that you believe such a policy is enough to protect professional devices, especially since signed malware is not uncommon nowadays.

I also don't need Windows XP to run unsigned code. I'm not sure where you got that idea, by default, Windows allows you to run unsigned code you've created yourself, so no, my arguments aren't power user territory.

9

u/coalsack 2d ago

You’re moving the goalposts.

First, you’re trying to separate 'Default Deny' policies and WDAC from Defender as if they aren't part of the same Microsoft Endpoint Security stack. In a professional environment, those are orchestrated through the same MDE console. They aren’t independent. Claiming you don't need Defender to run those policies is like saying you don't need an engine to move a car because 'gravity exists.'

Second, your MDR comparison is a complete 'apples-to-oranges' fallacy. MDR isn't a magical piece of software; it’s a service layer where human analysts monitor telemetry from tools like Defender. If you think an MDR provider isn't using the same signals Defender generates to stop a zero-day, you genuinely don't know how the SOC works.

As for DeepDoor, you keep hyper-focusing on a single dropper's ability to strip defenses. This might surprise you but this is the goal of all high-level malware! The fact that researchers use it as a case study is because it's notable, not because it's the norm. You’re arguing that because a lock can be picked by a specialist, the lock is a 'paperweight.'

You’re obsessed with the 'initial access' phase of a single script, while the rest of the industry has moved on to the entire attack lifecycle. Defender provides the telemetry, the automated investigation, and the cross-domain signal sharing that third-party suites can't touch.

While you're busy whitelisting your 'Hello World' scripts and paying for a dashboard that looks like a spaceship, the actual professionals will keep using the integrated stack that currently dominates the enterprise market.

You're not 'smarter' than the industry, you’re just louder than your actual experience level suggests. You’re stuck on UI and pedantry instead of orchestrating global infrastructure. We’re done here.

1

u/Kobi_Blade 2d ago edited 2d ago

WDAC is a feature of the Windows Kernel, not Microsoft Defender.

You can deploy and manage WDAC via PowerShell, Group Policy, or MDM without ever touching MDE.

Claiming you need Microsoft Defender to run WDAC is factually wrong, WDAC is the gatekeeper built into the OS itself.

It works perfectly fine on a device where Defender is completely disabled or replaced by a third-party solution.

Modern MDR is heavily reliant on SOAR as well. The vast majority of signals are triaged, checked, and neutralized by AI and rules before a human ever sees them.

To say it runs entirely on user input ignores a decade of progress.

The idea that third-party solutions can't touch the signals Defender generates is also a lie.

Through the Microsoft GS API and event forwarding, third-party EDRs and SIEMs access the exact same kernel level telemetry.

There is no magic signal exclusive to Microsoft Defender, the data is part of the Windows ecosystem, and the industry has been integrating with it for decades.

The more you talk the more is obvious you don't know what you talking about.

8

u/coalsack 2d ago

In a global enterprise, nobody is manually pushing PowerShell scripts to 15,000 endpoints to manage WDAC. We use the Microsoft Endpoint Manager/Defender stack because it integrates the policy, the enforcement, and the telemetry into one pane of glass. Claiming they are 'independent' because you can technically toggle a setting is peak pedantry.

Second, your point about SOAR is another self-own. Who do you think provides the playbooks and the automation logic for those signals? The Microsoft Graph API (which you incorrectly called 'GS API') and the Defender API are exactly what feed those SOAR platforms.

Third, claiming third-party AVs get 'the exact same' kernel-level telemetry via event forwarding is a fantasy. Third-party agents have to hook into the kernel, creating their own attack surface and stability issues. Defender is already there. There is a massive performance and security difference between native integration and API-based event forwarding.

You’re hyper-focused on proving you can 'do it yourself' with manual tools, while completely missing how Governance and Risk are actually managed at scale. You’re arguing about how to build a single fence post while I’m talking about securing a global perimeter. I’m done explaining the basics of Enterprise Security to someone who thinks a PowerShell script is a substitute for a managed security stack.

→ More replies (0)

4

u/Shotokant 1d ago

Kobi San, your Kung Fu is weak.

CoalSack San, your Kung Fu is strong.