2
1 CREATING A NESSUS AUDIT FILE Nessus Plugins are written in the NASL (Nessus Attack Scripting Language) scripting language. Nessus compliance checks are written as an .AUDIT file. With over 55,000 NASL plugins offered for download to Nessus subscribers, anything that is not covered by an existing NASL plugin is more easily written as a .audit policy. Nessus audit files are a specific language containing syntax similar to XML. The Tenable Support Portal provides a number of pre-written audit files for customers. These audit files have been written by Tenable, and many of them are certified by the appropriate governing body. To perform a compliance scan on a Windows target, a scan policy needs to be created. This scan policy must contain the following items at a minimum: a name, administrative level credentials, the Windows compliance plugin, and a compliance check audit file. There are also a number of tools available to generate your own audit files, rather than using the pre-written audit files available via the Tenable Support Portal. The i2a tool (version 2.0.0) is available from the customer support portal. It generates version 2 compliant audit policies based on existing Windows GPO .inf files. The Nessus Compliance Checks Reference document goes into extensive detail on how to construct your own audit file, syntax of the language, and more. There are currently five different structures for audit files, depending on the target: * Windows, for both server and desktop operating systems; * Unix, for Linux and Unix operating systems; * Database, for SQL servers; * Cisco, for Cisco brand devices on the network, and * Windows File Content, which is used to check Windows hosts for potentially sensitive content that is unencrypted. For example, a Windows audit file contains a check type item followed by a group policy item. After the group policy items, there are a series of individual checks. This is somewhat different from Unix audit files, which do not contain a group policy tag. There are a series of built-in checks that Windows audit files use. These checks are designed to simplify audit file creation. * Account checks allow you to verify the minimum password length, password complexity, group settings, and the status of the targets account lockout. * Service checks are built-in compliance audits for status and permissions of running services. * Audit checks show what type of Windows auditing is turned on such as logins and login failures, policy changes, and system events and process tracking. In addition to having a series of built-in checks for Windows auditing, the Tenable audit files can check the Windows system registry to confirm specific keys contain expected values. In addition to pre-written checks, as well as files and registry checks, Nessus also supports portions of Windows PowerShell. For example, you can look for existing services and determine if they are currently running.

Create a Nessus .Audit File and Using Windows Management Instrumentation Command-line (WMIC)

Embed Size (px)

DESCRIPTION

Create a Custom Nessus .Audit File and Using Windows Management Instrumentation Command-line (WMIC)

Citation preview

Page 1: Create a Nessus .Audit File and Using Windows Management Instrumentation Command-line (WMIC)

 

1  

CREATING A NESSUS AUDIT FILE 

Nessus Plugins are written in the NASL (Nessus Attack Scripting Language) scripting language. Nessus compliance checks are written as an .AUDIT file. With over 55,000 NASL plugins offered for download to Nessus subscribers, anything that is not covered by an existing NASL plugin is more easily written as a .audit policy. Nessus audit files are a specific language containing syntax similar to XML. The Tenable Support Portal provides a number of pre-written audit files for customers. These audit files have been written by Tenable, and many of them are certified by the appropriate governing body. To perform a compliance scan on a Windows target, a scan policy needs to be created. This scan policy must contain the following items at a minimum: a name, administrative level credentials, the Windows compliance plugin, and a compliance check audit file. There are also a number of tools available to generate your own audit files, rather than using the pre-written audit files available via the Tenable Support Portal. The i2a tool (version 2.0.0) is available from the customer support portal. It generates version 2 compliant audit policies based on existing Windows GPO .inf files. The Nessus Compliance Checks Reference document goes into extensive detail on how to construct your own audit file, syntax of the language, and more. There are currently five different structures for audit files, depending on the target: * Windows, for both server and desktop operating systems; * Unix, for Linux and Unix operating systems; * Database, for SQL servers; * Cisco, for Cisco brand devices on the network, and * Windows File Content, which is used to check Windows hosts for potentially sensitive content that is unencrypted. For example, a Windows audit file contains a check type item followed by a group policy item. After the group policy items, there are a series of individual checks. This is somewhat different from Unix audit files, which do not contain a group policy tag. There are a series of built-in checks that Windows audit files use. These checks are designed to simplify audit file creation. * Account checks allow you to verify the minimum password length, password complexity, group settings, and the status of the targets account lockout. * Service checks are built-in compliance audits for status and permissions of running services. * Audit checks show what type of Windows auditing is turned on such as logins and login failures, policy changes, and system events and process tracking.   

In addition to having a series of built-in checks for Windows auditing, the Tenable audit files can check the Windows system registry to confirm specific keys contain expected values.  In addition to pre-written checks, as well as files and registry checks, Nessus also supports portions of Windows PowerShell. For example, you can look for existing services and determine if they are currently running.

Page 2: Create a Nessus .Audit File and Using Windows Management Instrumentation Command-line (WMIC)

 

2  

CREATING A NESSUS AUDIT FILE 

The IT systems management field uses Windows Management Instrumentation (WMI) to develop scripts and automation procedures. Some pen testers use the Windows Management Instrumentation Command-line (WMIC) interface to query Windows system internals. Most administrators rely on a WMI-compatible tool such as Microsoft Operations Manager (MOM) or Security Center Operations Manager (SCOM), instead of trying to master WMIC commands. Related Links: Enabling Compliance Checks with Nessus http://www.tenable.com/tips/enabling-the-compliance-checks-with-nessus Nessus Compliance Check Reference Manual https://support.tenable.com/support-center/nessus_compliance_reference.pdf Tenable Compliance Check Guide https://support.tenable.com/support-center/nessus_compliance_checks.pdf Version 2 of Windows Compliance Checks Available for Testing (ia2 Tool) http://www.tenable.com/blog/version-2-of-windows-compliance-checks-available-for-testing CommandLineKingFu Blog http://blog.commandlinekungfu.com/p/index-of-tips-and-tricks.html SANS WMIC Cheat Sheet http://www.sans.org/security-resources/sec560/windows_command_line_sheet_v1.pdf Security Center Operations Manager (SCOM) http://en.wikipedia.org/wiki/System_Center_Operations_Manager