PowerShell Script with Veeam Credential Access Capabilities
Identifies PowerShell scripts that can access and decrypt Veeam credentials stored in MSSQL databases. Attackers can use Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2024/03/14"
3integration = ["windows"]
4maturity = "production"
5updated_date = "2025/01/15"
6min_stack_version = "8.14.0"
7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
8
9[rule]
10author = ["Elastic"]
11description = """
12Identifies PowerShell scripts that can access and decrypt Veeam credentials stored in MSSQL databases. Attackers can use
13Veeam Credentials to target backups as part of destructive operations such as Ransomware attacks.
14"""
15from = "now-9m"
16index = ["winlogbeat-*", "logs-windows.powershell*"]
17language = "kuery"
18license = "Elastic License v2"
19name = "PowerShell Script with Veeam Credential Access Capabilities"
20references = [
21 "https://forums.veeam.com/veeam-backup-replication-f2/recover-esxi-password-in-veeam-t34630.html",
22 "https://www.crowdstrike.com/blog/anatomy-of-alpha-spider-ransomware/",
23]
24risk_score = 47
25rule_id = "5c602cba-ae00-4488-845d-24de2b6d8055"
26setup = """## Setup
27
28The 'PowerShell Script Block Logging' logging policy must be enabled.
29Steps to implement the logging policy with Advanced Audit Configuration:
Computer Configuration > Administrative Templates > Windows PowerShell > Turn on PowerShell Script Block Logging (Enable)
reg add "hklm\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1
1"""
2severity = "medium"
3tags = [
4 "Domain: Endpoint",
5 "OS: Windows",
6 "Use Case: Threat Detection",
7 "Tactic: Credential Access",
8 "Data Source: PowerShell Logs",
9 "Resources: Investigation Guide",
10]
11timestamp_override = "event.ingested"
12type = "query"
13
14query = '''
15event.category:process and host.os.type:windows and
16 powershell.file.script_block_text : (
17 (
18 "[dbo].[Credentials]" and
19 ("Veeam" or "VeeamBackup")
20 ) or
21 "ProtectedStorage]::GetLocalString"
22 )
23'''
24note = """## Triage and analysis
25
26> **Disclaimer**:
27> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
28
29### Investigating PowerShell Script with Veeam Credential Access Capabilities
30
31PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats.
32
33### Possible investigation steps
34
35- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts.
36- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin.
37- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications.
38- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information.
39- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack.
40
41### False positive analysis
42
43- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators.
44- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system.
45- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts.
46- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring.
47- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening.
48
49### Response and remediation
50
51- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
52- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts.
53- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access.
54- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred.
55- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
56- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future.
57- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege."""
58
59
60[[rule.threat]]
61framework = "MITRE ATT&CK"
62[[rule.threat.technique]]
63id = "T1003"
64name = "OS Credential Dumping"
65reference = "https://attack.mitre.org/techniques/T1003/"
66
67[[rule.threat.technique]]
68id = "T1555"
69name = "Credentials from Password Stores"
70reference = "https://attack.mitre.org/techniques/T1555/"
71
72
73[rule.threat.tactic]
74id = "TA0006"
75name = "Credential Access"
76reference = "https://attack.mitre.org/tactics/TA0006/"
77[[rule.threat]]
78framework = "MITRE ATT&CK"
79[[rule.threat.technique]]
80id = "T1059"
81name = "Command and Scripting Interpreter"
82reference = "https://attack.mitre.org/techniques/T1059/"
83[[rule.threat.technique.subtechnique]]
84id = "T1059.001"
85name = "PowerShell"
86reference = "https://attack.mitre.org/techniques/T1059/001/"
87
88
89
90[rule.threat.tactic]
91id = "TA0002"
92name = "Execution"
93reference = "https://attack.mitre.org/tactics/TA0002/"
Triage and analysis
Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
Investigating PowerShell Script with Veeam Credential Access Capabilities
PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats.
Possible investigation steps
- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts.
- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin.
- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications.
- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information.
- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack.
False positive analysis
- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators.
- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system.
- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts.
- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring.
- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening.
Response and remediation
- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts.
- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access.
- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred.
- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.
- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future.
- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege.
References
Related rules
- Potential Invoke-Mimikatz PowerShell Script
- Potential PowerShell Pass-the-Hash/Relay Script
- PowerShell Kerberos Ticket Dump
- PowerShell Invoke-NinjaCopy script
- PowerShell Kerberos Ticket Request