Investigating "Batch Script Execution" findings

Overview

This guide contains helpful tips for investigating "Batch Script Execution" findings using Report Builder to review log data when the source of the script is not provided directly in the finding's evidence table. It includes recommended follow-up actions after you have completed your investigation and best practice tips for using these scripts in your environment.

About batch scripts

A batch script, also known as a batch file, is a text file containing a series of commands that can be executed by the Windows command-line interpreter (CMD). Scripts can use variables to store and manipulate data and use Windows' built-in commands like copy, move, and del. These script files have a .bat or .cmd extension. 

Batch scripts use basic commands and straightforward syntax, making them very accessible and simple to execute. Common use cases for batch scripts include the following:

• Normal activity: Batch scripts automate repetitive tasks or perform a series of operations in sequence, which makes them an important part of normal business operations.
  • System maintenance – automating backups, cleaning temporary files, or updating software.
  • File management – Organizing files, renaming in bulk, or moving files between folders.
  • Network operations – Mapping network drives or running network diagnostics.
  • Application launching – Starting multiple programs with specific parameters.
  • Installation processes – Automating software installation or configuration steps.
• Malicious activity: Batch scripts can pose several security risks when executed on a Windows system, especially if they come from unknown or untrusted sources. Here are some security concerns and potential malicious actions that can be performed using batch scripts:
  • File system manipulation
  • Registry manipulation
  • System commands execution
  • User account manipulation
  • Information gathering
  • Persistence
  • Disabling security features
  • Privilege escalation
  • Malware deployment
  • Social engineering
  • System resource abuse
  • Logging and monitoring
  • Service manipulation
  • Application interference

Verifying the source of a batch file

Verify the source of the file to determine if the script's nature is normal or malicious. If the source of the batch script is not clear from the data in the evidence table within the finding's details, use Report Builder to review more detailed device logs.

To review the logs for more details about the batch script, do the following:

1. In the finding, locate the following data, which you will use to build your report in later steps:
   • timestamp
   • devname
   • command
   • parent.cmdline
   • process_name
   • parent_process_name
2. Keeping your finding tab open, open another browser window and navigate to Reporting > Report Builder.
3. Set Time Range to the timeframe when the activity occurred, and add a few extra minutes before the finding’s start time to include the logs showing the process name, which are usually in the direct lead-up to the activity in the finding’s log evidence.
4. In Data Sources, select Blumira Agent Endpoint Logs and Microsoft Windows, if applicable.
5. Click Edit Report and then click Add Filter.
6. Add two filters to narrow the report to the logs containing the host and file name as follows:
   • devname – Equal – device name
   • command – Contains – filename.bat
7. Select Submit

In the example image below, the originating parent process displays the same .BAT file that triggered the detection:

Using part of the command (tmp.bat, as seen in the finding) that was run for the batch file on the impacted host, you are able to see which process was triggering the batch file at each timestamp.

Responding to the script's action

After determining the source of the batch file, take the following actions depending on the nature of the file:

• If the batch file is malicious in nature and is not approved to be running, do the following:
  1. Locate the file and delete it.
  2. If the batch file was run under a standard user account, lock the user account and reset or expire the user's password.
  3. Run an anti-virus scan on the impacted host to check for other indicators of compromise.
  4. If the scope of the file in your environment is unknown and the risk is high, remove the host from the network and quarantine it until you can complete full remediation of your systems.
• If the source of the file is approved and is a known behavior, then create a detection filter to reduce future false positives.
  Reference: Learn about adding detection filters here.
• If the source of the file is approved and is a known behavior but you would like to keep a close watch on the file's actions, you can create a custom saved report. This can help speed up investigation in the future if there are other batch files that need to be investigating.

Best practices for using batch scripts in your environment

Batch scripts are fairly common in Windows environments, but there are some best practices to follow to help secure your script use, including the following:

• Limit execution permissions:
  • Use Group Policy or local security policies to restrict who can run batch scripts.
  • Implement AppLocker or Software Restriction Policies to control script execution.
• Code signing:
  • Digitally sign your batch scripts using certificates.
  • Configure systems to only run signed scripts from trusted publishers.
• Secure storage:
  • Store scripts in protected directories with limited access.
  • Use file system permissions to restrict read/write access to authorized users only.
• Input validation:
  • Validate and sanitize all user inputs to prevent command injection attacks.
  • Use proper quoting and escaping techniques for variables and arguments.
• Avoid hardcoding sensitive information:
  • Don't include passwords, API keys, or other sensitive data directly in scripts.
  • Use secure methods like Windows Credential Manager or encrypted configuration files.
• Use least privilege principle:
  • Run scripts with the minimum necessary permissions.
  • Avoid running scripts with administrative privileges unless absolutely necessary.
• Version control:
  • Use a version control system (e.g., Git) to track changes and manage script versions.
  • Implement change management processes for script modifications.
• Regular review and updates:
  • Periodically review and update scripts to address security vulnerabilities.
  • Remove or update deprecated commands or syntax.
• Secure network operations:
  • Use secure protocols (e.g., HTTPS, SSH) when scripts interact with network resources.
  • Implement proper authentication and encryption for network communications.
• Documentation: Maintain clear documentation for each script, including its purpose, usage, and any security considerations.
• Consider alternatives: For complex tasks, consider using more robust scripting languages like PowerShell, which offers enhanced security features.