Windows Defender Is Becoming the Powerful Antivirus That Windows 10 Needs

Defender's "quick" scan is back up into the 6-7 minute range again w/37,000 items, up from 16,400 items/42 sec. post engine update. Haven't deleted any logs or changed any setting. Anyone else notice a prolonged quick scan w/extra objects? Anything that can be done about it? I suppose a Custom Scan is faster but I'm too lazy to click more than once.

 

Noticed this too, used to take 2 minutes tops, now it's 5 and some.

 

I support your stance including inferiority of AV & BB. It's a waste of time to try to eliminate all of theoretical possibilities. If you're really targeted by such an advanced actor, you have more thing to worry about. You can say: give me a real malware which somehow can run on my system!

Maybe you can emphasize this more, 'cause there's always ppl who believe BM can block 0day malware. It's simply impossible to monitor all APIs and block all possible patterns of off-the-shelf attack proactively w/out breaking the system.

 

Process hollowing is one technique to initiate fileless malware, and BB can block this. Probably you misunderstand EDR, or too simplified it.

Exactly speaking, these vendors use a different mechanism (behavior lockdown, tho it may be included in umbrella term of BB) for fileless malware, tho it will be possible to terminate a process if it detected some of known patterns.

 

Let's address PPL first.

Matt Graeber and other pen-testers have demonstrated that bypassing PPL is a rather trival exercise. Microsoft de facto acknowledged this by offering sandboxing protection for WD which btw is optional and has to be manually enabled. This in reality was a smart move on Microsoft's part since a few pen-testers have related to me that with WD sandboxing enabled, it busts a number of WD's malware detection mechanisms. However, PPL is enough of a deterrent that bypassing it is usually employed only by the advanced malware strains. Note that the major third party AVs also use PPL to protect their kernel processes. However for them, it is supplementary security protection. Their primary protection being their own HIPS or behavior monitor.

Yesterday I was researching some stuff and happened upon Microsoft's WD ATP documentation which emphatically states it has behavior monitoring. However, the stated methods employed such as monitoring reg. key, Win startup directories, etc. modification indicates that what it is using is actually a HIPS. Further justification for this is existing ASR rules which monitor specific process modification activities. No where have I found any reference to WD in any form employing AMS methods such as monitoring of API call activity. Now it is possible such API monitoring is being done during the cloud block-at-first-sight phase. However, that would not protect against later post-execution code injection or thread hijacking activity by malware. In any case for plain WD users, it should be easy enough to test if it is actually using HIPS protection against reg. modification and the like by creating your own test malware that does so. Again, this activity would have to detonate after initial cloud scanning has completed.

 

Surprising a number of them don't detect it. This is because classic PH involves starting the targeted process in suspended mode as a child process and then "hollowing out" its memory space and injecting the malicious code in that space. After all this, the process is un-suspended and execution resumed. The problem is that a number of HIPS and behavior monitors do not monitor suspended processes started this way. Therefore detailed testing is required against the security solution to ensure that it does monitor processes started in a suspended state. One other important point. Unless the security solution injects a hook; i.e. .dll or thread into every process that executes, only selective processes are being monitored which is the norm. Barriers to this are PPL and processes that employ Win 10 code integrity protection. The later requiring that their .dll must be MS code certificate signed. -EDIT- To be determined. Is code integrity protection in effect for a suspended process - doubtful I would say. Ditto I beleive for PPL. Those protections I believe only become effective once the process is loaded and starts execution. Clarification - PPL will protect against suspending a running process and performing PH against it. The rub is only select OS processes have PPL protection. Also and assuming the running process is a monitored process by a behavior monitor, detection should be had to either the suspension activity or the subsequent PH activity. If the monitoring is being done by a HIPS, rules need to be specified in regards to process suspension/termination and modification activities. Obviously, this will be done for only select processes.

 

I will be switching to Windows Defender from a third party security suite. Once Windows Defender is up and running, what settings should I check to make sure it is properly configured? Which settings are the most important ones to check first?

 

If you want easy access to advanced settings you can use ConfigureDefender. It has Default, High and Max profiles or make any custom setup you like. High will enable all features except 3 ASR rules and Controlled Folder Access. Max will enable all features and set Smartscreen to Block, and hide Windows Security Center. Remember, you may easily configure individual features as you like, e.g. I will use Max and not hide WSC. Which features you use depend on compatibility/usability with other installed programs, if the machine is used by you alone or by others, etc. You may find CD on the web @ Hard_Configurator.com/Downloads

 

I agree with post above.

ConfigureDefender is portable, and recommend High setting. If you have any questions, the dev is very active on MT.

 

OK then I misunderstood, I didn't know you considered AV and BB not the most important. I thought you were trying to stick up for Win Def, as if AV bypasses weren't a big deal. But just recently, a research done over here in Holland showed that most small and mid-sized companies use AV as their main protection against malware.

I didn't know about this, I thought these BB's would always rely on user input and that it needed to be turned on which is mostly done by expert users. So why don't they implement this into Win Def AV? I'm guessing because they are afraid of false positives.

 

I disagree, most malware rely on using certain techniques that can be blocked by BB's. Of course there's always a risk of false positives, but most apps that are goodware don't use techniques like code injection and process hollowing.

No what I meant is, Win Def AV won't block process hollowing, but Win Def ATP will at least spot this, and alert the system manager. Then it will disconnect the attacked PC from the network to block it from spreading any further.

 

Probably many large companies too. I work for one and they use an Enterprise-level AV, but I know they have several other measures in place to secure their corporate environment. In no way do they rely solely on AV. Is it their main protection? That I don't know.

 

@Rasheed187
As I said in #2562 your use of the word BB is uncommon, it usually refers to SONAR etc. but you mean HIPS. Only some AVs such as Comodo & Kaspersky implement it (BTW, they by default come w/ very lax rules and automatic classification so no user interaction required). Modern BB is different, it mostly relies on behavior signatures which define specific patterns of resource accesses & API calls to catch malware. If you use corporate AV such as SEP, you can see what behavior signature version has been downloaded and applied. So if it's not up-to-date, you're not protected from latest malware. Ofc what comes w/ WD is also this type, and what you says BB corresponds to ASR as I said before. Also don't confuse them w/ cloud ML analysis which is fundamentally different in not distinguishing known & unknown.

You're only right if you mean most low-end malware targeting common user. I know you're concerned w/ code injection, but remember it's just one family of possible techniques malware may or may not use. Process hollowing is already an old technique, even process doppelganging is one year old, and unlike them code injection generally have legitimate use. Development of these new techniques have never been stopped and every year new techniques make news, but most of them are on Windows. Don't circumvent this by saying cat & mouse game. Even the most advanced malware which takes root on Android was not as capable as on Win, despite Android is becoming more n' more fascinating target. Windows hasn't had formal security model (*) so @itman 's saying band-aid is understandable. Yet MS is still adding new resources and APIs w/out fundamental change and not removing legacies so new techniques will be keep coming, while doing so on other OSes is getting even more cost so only state-sponsored actor can pay. Despite it's no secret that MS, Google, & Apple are competing to advertise their security, many ppl just take what they advertise as is and never try to see what they don't tell you. MS occasionally "report" stats from their Intelligence Report to say "Win X is Y times more secure than old Win Z" but they've not been proper statistics if you saw details. They're nothing more than marketing hype.

Whether Win Def can block PH needs to be tested, but theoretically it can block this. What I meant was while I thought you're talking post-execution detection of fileless malware, if PH was blocked the malware wouldn't run.

(*) https://www.tu-ilmenau.de/fileadmin/media/vsbs/Publikationen/ModelBasedSafetyAnalysis.pdf

 

In hot pursuit of elusive threats: AI-driven behavior-based blocking stops attacks in their tracks.

https://www.microsoft.com/security/...based-blocking-stops-attacks-in-their-tracks/

 

I will also add there are two types of process hollowing attacks.

The first and most difficult to detect is when the attack process opens a legit .exe as a child process in suspended mode. This one is the most difficult for security solutions to detect since starting a legit .exe as a child process in any mode is not considered malicious activity. A HIPS such as Eset's can detect modification of the suspended process but only if you manually create a rule to detect process modification activities for the specific process. And of course and Catch-22, you will have to also create allow rules for trusted processes that perform legit modification activities against the process. Also of note in this scenerio is once the hollowed process is modified, the attack process starts the hollowed process and immediately terminates itself. Also in some malware variants it also deletes the attack process from disk, making the attack totally invisible. There are also "fileless" attack process variants.

The second type of process hollowing involves suspending an existing executing process and attempting to modify it. Security solutions have a better detection track record against this type of process hollowing modification.

 

It's a given that @Rasheed187 is obsessed with process hollowing attacks. The current reality is they have pretty much fallen "out of vogue" with attackers. I have seen PH employed in a couple of recent attacks but those were targeted advanced threat types. PH is very "messy" to implement. One false step in "tidying up" existing code memory will result in the targeted processing aborting or a system blue screen.

Current attack methods have migrated to techniques such as APC reflective dll execution. All that is required for success is to hook a thread in the targeted process. Actual dll execution is performed in the attack process. I also believe this will bypass Win 10 code integrity protection if so employed in the targeted process. The only way to detect APC activity is via AMS protection and only if the security solution is monitoring the attack process for specific API's used by APC.

 

@itman I think the oldest technique using NtUnmapViewOfSection or ZwUnmapViewOfSection can presumably be detected, but the problem is there are many ways to achieve the same or similar, as shown by e.g. QtLoader. So security solution, in ideal world, have to monitor all possible combinations of all abusable APIs - maybe this is what Rasheed missed.

[EDIT] A quick search showed that potential PH (the oldest one) can be caught at least three ways: 1) discrepancy in parent, 2) discrepancy btwn kernel-land info, and 3) PAGE_EXECUTE_READWRITE which the kernel doesn't usually set while can not be set via VirtualAlloc (user space).

 

No I mean BB. The difference is that BB blocks processes when they see multiple signs of suspicious behavior and then auto-block it without relying on the user. It seems like Bitdefender does this, but I don't believe that Emsisoft and Kaspersky do this. I'm not sure about Norton.

Also, I see anti-exploit as a separate thing, I don't count it as behavior blocker. And from what I've read from the article that Martin_C posted, it seems like Win Def AV does block certain things like process hollowing? That is news to me.

It might be my imagination, but in almost all malware attacks that I read about, some form of process hollowing is used. And no, it's not impossible to stop it, HMPA does this out of the box.

 

The detection WD ATP threw in that article was Behavior:Win32/DefensiveEvasion.VF!ml. Also from that article is that WD ATP has AMS and every other protection mechanism known to security mankind. So lets assume that WD ATP being an enterprise level security product is as good as Microsoft states it is.

Where I have a problem with these WD ATP Microsoft propaganda articles posted here is the assumption by many that their Win 10 Home WD version has all those enterprise grade protections. That I believe is really a stretch. If WD Home had like capability, why would anyone pay for the Win 10 Pro version w/ATP licensing fees or Win 10 Enterprise?

 

Easy to read chart for comparing Windows Defender features across platforms.

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE2O8jv

 

To earn that "suspicious score", the "suspicious" behavior have to match w/ any of predefined ones, it's almost just an extension of traditional signature (*). Don't confuse this w/ human judgement which can identify suspicious behavior w/out signature. Also I think you're confusing w/ cloud ML analysis as you mentioned Bitdefender - yes, in their (and many more vendor) architecture they're combined but technically they're different.

So you call any kind of code injection as PH? Then no solution can stop it perfectly w/out causing lots of FPs. I don't know if HMPA can stop process doppelganging, but at least they use internal whitelist to allow some legitimate-yet-ill-behaving programs for the old PH technique.

(*) One diff is update frequency. Traditional sig updates every hour while behavior sig every week.

[EDIT] Apparently HMPA blocked PD.
[EDIT2] I think this discussion will never end until you stop using blanket terms such as suspicious behavior or process hollowing and instead going into internals.

 

My previous comments about WD ATP vs WD client based still stand. The "meat" of WD ATP protection is had from the Microsoft cloud server component.

 

Microsoft Now Enables Windows 10 Tamper Protection By Default
October 14, 2019
https://www.bleepingcomputer.com/ne...bles-windows-10-tamper-protection-by-default/

Microsoft: Tamper protection now generally available for Microsoft Defender ATP customers

 

Where did you see me saying this? Process hollowing is just one form of many code injection methods, but it's only used by malware, so it makes sense to block it.

And this whole discussion started because of your comment that BB's are inferior. I don't understand why you would say such a thing. What do you think happens in the cloud? They run malware in a sandbox to see how they behave, and based on their behavior they classify it as malware or not. This all happens in seconds.

To me it's still not clear if Win Def AV blocks process hollowing or not, it is indeed a bit confusing because in these articles they often mention both Win Def ATP and WD AV.

 

I ran across a "home brew" malware a while back that performed classic process hollowing; start child process in suspended mode, hollow it out, inject malicious code, and start suspended process. This sample was coded to "wait out" conventional sandbox analysis. The process hollowing activity did not commence until the malware .exe had been running for some time. As such, block-at-first-sight cloud sandboxing if set for maximum 60 secs. would not have detected any process hollowing activity assuming it could detect the PH activity. WD ATP on the other hand will perform a complete cloud sandbox analysis in that it will not render its verdict until the malware .exe sample terminates. At least I believe that is how it works.