Enable Windows Command Line Parameter Logging

Windows command line parameter makes up a significant number of modern exploits, commonly those exploits used by ransomware actors. Alert Logic recommends you enable a logging configuration for Windows command line parameters because, if not enabled, command line parameters passed into the executed binary are omitted from event logs collected by the Alert Logic agent. Without this log collection, it is more difficult to identify what an attacker's true intentions might be, as it excludes valuable insight that could be used for correlation and incident response.

For example, an attacker may attempt lateral movement activities using the following net command:

net use x: \\10.0.0.1\c$/USER:administrator

Without command line arguments, this command would only appear as a call to 'net.exe,' without any of the other supporting parameters.

Security Considerations

Note: Windows command line parameters can contain sensitive information like passwords, and with logging enabled, this information will be sent to Alert Logic, where your users can find it in plain text via log search. Alert Logic believes that this is valuable logging information and is important in identifying compromising attacks.

Configure Windows Command Line Parameter Logging

Note: The following steps are provided as general guidance when using an Amazon Web Services instance template with Windows Server 2019. There may be variations in necessary steps depending on the version. If you have concerns or issues, consult your Windows Administrator or Microsoft TechNet articles for the most up-to-date information on Windows logging configurations and specific best practices.

1. Open Command Prompt, type gpedit, and press the Enter/Return key. This will open the Local Group Policy Editor.
   
   Note: This must be done on a Domain Controller unless the Server is a standalone.
   
   
2. On the left-hand side of the Local Group Policy Editor, navigate to Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies - Local Group Policy Object > Detailed Tracking > Audit Process Creation.
   
   
3. Within the Audit Process Creation Properties window, check the following boxes:
   - Configure the following audit events
   - Success and Failure
   
   
4. Again, navigate to Computer Configuration, and then to Administrative Templates > System > Audit Process Creation.
   
   
5. On the right-hand side, double click Include command line in process creation events and select Enabled.
   
   
6. Open Command Prompt, type gpupdate /force, and press the Enter/Return key.

Note: Logging can be enabled using a variety of means, including custom PowerShell cmdlets, registry modification, and the Group Policy Object. We have explained here how to use the Group Policy Object method because it is simple and scalable.

Disclaimer: Whether you apply advanced audit policies by using group policy or by using logon scripts, do not use both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Security Settings\Advanced Audit Policy Configuration. Using both advanced and basic audit policy settings can cause unexpected results in audit reporting.

Validate the Configuration

Open Command Prompt and run a few commands with arguments. Wait about 15 minutes from logs to begin coming through.

In the Alert Logic console at (navigation menu) > Investigate > Search > Search and via Expert Mode search, use the below SQL query to validate logs are coming through to Alert Logic as expected. Check the tag process_logs_with_cmd_line_args - the number of logs in these categories that have come to the console will be visible. This will confirm that the Windows command line parameter logs are successfully being collected by Alert Logic.

Validate Using Alert Logic Log Search

The following is an Alert Logic search query for the presence of PowerShell, Windows command, and other ransomware-related log types:

SELECT 
coalesce([asset.dict.asset.host.name, metadata.dict.dict.local_hostname, parsed.token_names.header.addr.host_name]) as hostname, metadata.dict.dict.local_ipv4, metadata.dict.dict.host_type, 
SUM(IF(Coalesce([parsed.token_names.log_information.win_log.win_event.win_event_code, parsed.token_names.event.event_id]) in ['4624', '4625'], 1, 0)) as num_login_events, 
SUM(IF(Coalesce([parsed.token_names.log_information.win_log.win_event.win_event_code, parsed.token_names.event.event_id]) in ['4723', '4724', '4725', '4726', '4720', '4738'], 1, 0)) as user_account_events, 
SUM(IF(Coalesce([parsed.token_names.log_information.win_log.win_event.win_event_code, parsed.token_names.event.event_id]) in ['4100', '4101', '4102', '4103', '400', '500', '501'], 1, 0)) as powershell_logs, 
SUM(IF(Coalesce([parsed.token_names.log_information.win_log.win_event.win_event_code, parsed.token_names.event.event_id]) = '4104', 1, 0)) as powershell_script_block_log, 
SUM(IF(Coalesce([parsed.token_names.log_information.win_log.win_event.win_event_code, parsed.token_names.event.event_id]) = '4688', 1, 0)) as process_logs, 
SUM(IF(not parsed.token_names.action.command = '' and Coalesce([parsed.token_names.log_information.win_log.win_event.win_event_code, parsed.token_names.event.event_id]) = '4688', 1, 0)) as process_logs_with_cmd_line_args 
FROM logmsgs 
WHERE 
( 
parsed.token_names.log_information.win_log.win_event.win_event_code in ['4624', '4625','4723', '4724', '4725', '4726', '4720', '4738', '4100', '4101', '4102', '4103', '400', '500', '501', '4104', '4688'] 
or 
parsed.token_names.event.event_id in ['4624', '4625','4723', '4724', '4725', '4726', '4720', '4738', '4100', '4101', '4102', '4103', '400', '500', '501', '4104', '4688'] 
) 
group by hostname, metadata.dict.dict.local_ipv4, metadata.dict.dict.host_type