Windows 10: Can Windows Defender detect external win32/kernel api calls?

Arzenal · Jun 6, 2020

There's a lot of win32/kernel based keyloggers on the internet. Can Windows Defender detect when a simple application calls key stroke related win32/kernel functions?

:)

Brink · Jun 6, 2020

Microsoft filling in divide between Win32 apps and new Windows APIs

Many new and sought-after Windows APIs and features such as BackgroundTasks, Notifications, LiveTiles, Share and more, are either not available or not easily callable from non-packaged Win32 applications. This is due to the programming model for UWP APIs that integrate with the system and have a dependency on the following concepts:

Identity – The need for package or application identity to identify the caller, and an identifier to scope data and resources.

Registration – The need for configuration of machine state during application deployment, which is required by the API and indexed by the package or application identity.

For packaged applications, Identity declared in the Appxmanifest.xml, and Registration is handled by the MSIX deployment pipeline based on the information in the AppxManifest.xml. This allows a simplified calling pattern for UWP APIs where the application code just uses an API. Compare this to a typical Win32 API that requires a register-use-unregister pattern for managing a callback.

We’ve heard your feedback, and in response we’re filling in the divide between Win32 apps and new Windows APIs & features so that you can take advantage of these new APIs & features and enhance your applications. As of Windows Build 10.0.19000.0 we’re introducing the following new AppModel concepts to provide your Win32 app with deeper integration into the OS:

Sparse Package registration
Signed MSIX packages can be installed on Windows today but all content referenced in the package’s Appxmanifest.xml must be present inside the package. A ‘Sparse’ Package contains an AppxManifest.xml but unlike a regular/full package, the manifest can reference files outside its package in a predetermined ‘external location’. This allows applications that are not yet able to adopt complete MSIX packaging to gain Identity, configure state (Registration) as required by UWP APIs and then take advantage of these APIs.

Package ‘External Location’
To support a Sparse Package, a package definition now has a new <allowExternalContent> element. This is what allows your package AppxManifest.xml to reference content outside its package, in a specific location on disk. For example, if your existing Win32 app installs content in C:\Program Files\MyWin32App\ , you can create a Sparse Package that declares the <allowExternalContent> element and during app installation or first run of your app, you can register the Sparse Package and declare C:\Program Files\MyWin32App\ as the external location your app will be using. This way you can continue deploying all your other app artifacts in the locations you do today while taking advantage of the Sparse Package.

Win32 type RuntimeBehavior
To help with compatibility of your existing Win32 app when using a Sparse Package, the app can register to have its application process be run like a non-packaged Win32 app as much as possible. This differs from a fully packaged Win32 app in that it is not subject to filesystem + registry virtualization, lifetime management by the system and other runtime attributes of fully packaged applications. The main runtime similarity between such an app and a fully packaged app is the presence of app/package identity in the running process.

Activation via CreateProcess
The activation path for UWP applications today ensures the app has PackageIdentity in its process token. This is used by UWP APIs to identify the caller and refer to later – either to perform a callback or to look up state that was configured during deployment. Because of this requirement, calling CreateProcess() on a UWP exe will fail as the CreateProcess() pipeline was not enlightened about Identity. In order to support Sparse Packages with an External Location, we leverage the classic Win32 application.manifest to provide Identity in CreateProcess() scenarios.

At their core, these features are about providing a foundation for non-packaged Win32 processes to use our latest APIs and features.

*Please note that these are still new and somewhat advanced development features that do not yet have full Visual Studio integration i.e. there are still some gaps in the end to end authoring experience such as having to create a Sparse Package outside of Visual Studio...
Click to expand...

Read more: Identity, Registration and Activation of Non-packaged Win32 Apps - Windows Developer Blog

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

KevinNjau · Jun 6, 2020

Win32/Neshta.A virus detected

My Windows Defender is detecting the Win32/Neshta.A virus but can't deal with it effectively. What should I do?

Bill_Bright · Jun 6, 2020

"Attestation" A new feature coming to Windows Defender in Windows 10

Tech Republic - Upcoming Windows Defender feature will tell you when security fails

An upcoming feature of Windows Defender, called runtime attestation, will be able to detect the most minute signs of security compromise, all the way down to the kernel level.

Runtime attestation is designed to improve antivirus software detection, detect changes caused by rootkits, kernel tampering, and other exploits, ensure security of sensitive transactions, and ensure conditional access systems are secure.

The end goal of runtime attestation is to create a security system that can detect the most minute of symptoms, Microsoft said. "The idea is to continually elevate defense across the entire Windows 10 security stack, thereby pushing attackers into a corner where system changes affecting security posture are detectable."
Click to expand...

This seems very promising. Microsoft is in the unique position to know what Windows should look like, even before Windows Update pushes out new changes. As long as MS can properly sync WD with WU changes AND this new features does not make any "noticeable" hit on system performance/resources, all without any false positives, this should be a big step forward for consumer security, and a blow to the bad guys - always a good thing.

Of course, there will likely be some hiccups the Windows/Microsoft/Windows Defender bashers will surely pounce on - regardless how extensive the Beta process is. But hopefully open and unbiased minds will prevail. After all, the goal is to stop the bad guys and if this gets us closer to that, that's a very good thing.

For more detailed information, see Introducing Windows Defender System Guard runtime attestation)

Windows 10: Can Windows Defender detect external win32/kernel api calls?

Can Windows Defender detect external win32/kernel api calls?

Can Windows Defender detect external win32/kernel api calls?

Can Windows Defender detect external win32/kernel api calls?

Can Windows Defender detect external win32/kernel api calls? - Similar Threads - Defender detect external

Windows Defender detected Win32/Floxif.H

Windows Defender detected Win32/Floxif.H

Virus Threat Protection: Block Win32 API calls from Office macro

Windows Defender -VirTools Win32/ExcludeProc.D and Win32/ExcludeProc.A

unable to call external payment gateway api via dotnet code

unable to call external payment gateway api via dotnet code

unable to call external payment gateway api via dotnet code

[Win32 API] Resizing a borderless window?

Win32/MicTrayDebugger - very late detection by Defender