When deploying these templates (that are also available in the Portal) it will not flag correctly that the template is in use. I have tried to link the original template with the deployment by adding AlertRuleTemplateName (tried both name and guid):
Scheduled:
- id: cecdbd4c-4902-403c-8d4b-32eb1efe460b
displayname: Solorigate Network Beacon
description: |
'Identifies a match across various data feeds for domains IOCs related to the Solorigate incident.
References: https://blogs.microsoft.com/on-the-issues/2020/12/13/customers-protect-nation-state-cyberattacks/,
https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html?1'
severity: High
enabled: true
alertRuleTemplateName: Solorigate Network Beacon
requiredDataConnectors:
- connectorId: DNS
dataTypes:
- DnsEvents
- connectorId: AzureMonitor(VMInsights)
dataTypes:
- VMConnection
- connectorId: CiscoASA
dataTypes:
- CommonSecurityLog
- connectorId: PaloAltoNetworks
dataTypes:
- CommonSecurityLog
- connectorId: MicrosoftThreatProtection
dataTypes:
- DeviceNetworkEvents
queryFrequency: 6h
queryPeriod: 6h
triggerOperator: gt
triggerThreshold: 0
tactics:
- CommandAndControl
relevantTechniques:
- T1102
tags:
- Solorigate
query: |
let domains = dynamic(["incomeupdate.com","zupertech.com","databasegalore.com","panhardware.com","avsvmcloud.com","digitalcollege.org","freescanonline.com","deftsecurity.com","thedoccloud.com","virtualdataserver.com","lcomputers.com","webcodez.com","globalnetworkissues.com","kubecloud.com","seobundlekit.com","solartrackingsystem.net","virtualwebdata.com"]);
(union isfuzzy=true
(CommonSecurityLog
| parse Message with * '(' DNSName ')' *
| where DNSName in~ (domains) or DestinationHostName has_any (domains) or RequestURL has_any(domains)
| extend AccountCustomEntity = SourceUserID, HostCustomEntity = DeviceName, IPCustomEntity = SourceIP
),
(DnsEvents
| extend DNSName = Name
| where isnotempty(DNSName)
| where DNSName in~ (domains)
| extend IPCustomEntity = ClientIP
),
(VMConnection
| parse RemoteDnsCanonicalNames with * '["' DNSName '"]' *
| where isnotempty(DNSName)
| where DNSName in~ (domains)
| extend IPCustomEntity = RemoteIp
),
(DeviceNetworkEvents
| where isnotempty(RemoteUrl)
| where RemoteUrl has_any (domains)
| extend DNSName = RemoteUrl
| extend IPCustomEntity = RemoteIP
| extend HostCustomEntity = DeviceName
)
)
entityMappings:
- entityType: Account
fieldMappings:
- identifier: FullName
columnName: AccountCustomEntity
- entityType: Host
fieldMappings:
- identifier: FullName
columnName: HostCustomEntity
- entityType: IP
fieldMappings:
- identifier: Address
columnName: IPCustomEntity
- entityType: DNS
fieldMappings:
- identifier: DomainName
columnName: DNSName
When a rule is deployed from the portal (GUI) Get-AzSentinelAlertRule gives the following response:
AlertRuleTemplateName : 95dc4ae3-e0f2-48bd-b996-cdd22b90f9af
DisplayName : Modified domain federation trust settings
Description : This will alert when a user or application modifies the federation settings on the domain or Update domain authentication from Managed to Federated.
For example, this alert will trigger when a new Active Directory Federated Service (ADFS) TrustedRealm object, such as a signing certificate, is added to the domain.
Modification to domain federation settings should be rare. Confirm the added or modified target domain/URL is legitimate administrator behavior.
To understand why an authorized user may update settings for a federated domain in Office 365, Azure, or Intune, see: https://docs.microsoft.com/office365/troubleshoot/active-directory/update-federated-domain-office-365
.
For details on security realms that accept security tokens, see the ADFS Proxy Protocol (MS-ADFSPP) specification: https://docs.microsoft.com/openspecs/windows_protocols/ms-adfspp/e7b9ea73-1980-4318-96a6-da559486664b.
For further information on AuditLogs please see https://docs.microsoft.com/azure/active-directory/reports-monitoring/reference-audit-activities.
Enabled : True
When a rule is deployed using Import-AzSentinelAlertRule and a YAML as input I get the following response from Get-AzSentinelAlertRule
AlertRuleTemplateName :
DisplayName : Solorigate Network Beacon
Description : 'Identifies a match across various data feeds for domains IOCs related to the Solorigate incident.
References: https://blogs.microsoft.com/on-the-issues/2020/12/13/customers-protect-nation-state-cyberattacks/,
https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html?1'
Enabled : True
Is linking of the original template not possible with Import-AzSentinelAlertRule and YAML, or am I doing something wrong in the code?
hi @Jaa9 Thanks for your feedback. alertRuleTemplateName needs to be the GUID name of the template rule and not the display name. you can use Get-AzSentinelAlertRuleTemplates to get the correct GUID name
I'm able to use Import-AzSentinelAlertRule and import the YAML based Detection Rules from https://github.com/Azure/Azure-Sentinel/tree/master/Detections after tweaking a couple of elements:
When deploying these templates (that are also available in the Portal) it will not flag correctly that the template is in use. I have tried to link the original template with the deployment by adding AlertRuleTemplateName (tried both name and guid):
When a rule is deployed from the portal (GUI) Get-AzSentinelAlertRule gives the following response:
When a rule is deployed using Import-AzSentinelAlertRule and a YAML as input I get the following response from Get-AzSentinelAlertRule
Is linking of the original template not possible with Import-AzSentinelAlertRule and YAML, or am I doing something wrong in the code?