How to check the Virtual machine is vulnerable to Log4j or not ? ( checked the wiz and Defender couldn't find any)

Hello, @Saradha Kannan !

How do I detect, prevent, and address Log4j vulnerabilities?
Detecting Log4j vulnerabilities is a complex task as Log4j vulnerabilities not only affect your applications but services that use vulnerable applications making this much more difficult to track down:

By nature of Log4j being a component, the vulnerabilities affect not only applications that use vulnerable libraries, but also any services that use these applications, so customers may not readily know how widespread the issue is in their environment.

To help in this task, Microsoft has a list of topics for preventing and detecting Log4j vulnerabilities:
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

This includes using solutions like Microsoft Defender for Cloud Apps, Microsoft Defender for Cloud, Microsoft Defender for IoT, Microsoft Sentinel, Azure Firewall Premium, and Azure Web Application Firewall (WAF).

What solutions should I use specific to my Azure resources?
The Microsoft Security Response Center (MSRC) covers this subject in depth as well, and includes guidance for a list of Azure services. It also guides you through applying security updates which is an essential first step:
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

In addition to product specific guidance, the following is recommended to help mitigate the risk of vulnerabilities in Log4j 2.x:

• For all releases of Log4j 2.x prior to 2.16.0, the most effective mitigation, besides a security update, is to prevent the JndiLookup.class file from being loaded in the applications’s classpath.
• Customers can do this by deleting the class from affected JAR files. For example:
  $ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• Log4j may also be present in other files as a bundle or as a shaded library. Microsoft advises customers to do an extensive search beyond log4j-core-*.jar files.
• In case the Log4j 2 vulnerable component cannot be updated, Log4j versions 2.10 to 2.14.1 support the parameter log4j2.formatMsgNoLookups to be set to ‘true’, to disable the vulnerable feature. Ensure this parameter is configured in the startup scripts of the Java Virtual Machine: 
  -Dlog4j2.formatMsgNoLookups=true.
• Alternatively, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change.
• Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
• An application restart will be required for these changes to take effect.

Additional Resources:
This is a large subject with many potential vulnerabilities. This list will help you get the information you need to be more secure:

• Microsoft Security: Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability
• Microsoft Security Response Center: Microsoft’s Response to CVE-2021-44228 Apache Log4j 2
• MSRC Security Update Guide: Apache Log4j Remote Code Execution Vulnerability
• Reactive guidance for customer inquiries regarding a Log4j 2 RCE vulnerability affecting various Apache products