Analytic Rules with subtechniques fail to deploy

[Kaloszer]

Describe the bug
Analytic rules with subtechniques fail to deploy:

id: 6345c923-99eb-4a83-b11d-7af0ffa75577

{
    "status": "Failed",
    "error": {
        "code": "BadRequest",
        "message": "Invalid data model. [: The technique 'T1071.001' is invalid. The expected format is 'T####', where '#' represents a digit.]"
    }
}

To Reproduce

1. Deploy ARM template against a LA workspace

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "workspace": {
            "type": "String"
        }
    },
    "resources": [
        {
            "id": "[concat(resourceId('Microsoft.OperationalInsights/workspaces/providers', parameters('workspace'), 'Microsoft.SecurityInsights'),'/alertRules/6345c923-99eb-4a83-b11d-7af0ffa75577')]",
            "name": "[concat(parameters('workspace'),'/Microsoft.SecurityInsights/6345c923-99eb-4a83-b11d-7af0ffa75577')]",
            "type": "Microsoft.OperationalInsights/workspaces/providers/alertRules",
            "kind": "Scheduled",
            "apiVersion": "2022-11-01-preview",
            "properties": {
                "displayName": "Beacon Traffic Based on Common User Agents Visiting Limited Number of Domains",
                "description": "This query searches web proxy logs for a specific type of beaconing behavior by joining a number of sources together: \n- Traffic by actual web browsers - by looking at traffic generated by a UserAgent that looks like a browser and is used by multiple users\nto visit a large number of domains.\n- Users that make requests using one of these actual browsers, but only to a small set of domains, none of which are common domains.\n- The traffic is beacon-like; meaning that it occurs during many different hours of the day (i.e. periodic). \n",
                "severity": "Medium",
                "enabled": true,
                "query": "let timeframe = 1d; // Timeframe during which to search for beaconing behavior.\nlet lookback = 7d; // Look back period to find if browser was used for other domains by user.\nlet min_requests=50; // Minimum number of requests to consider it beacon traffic.\nlet min_hours=8; // Minimum number of different hours during which connections were made to consider it beacon traffic.\nlet trusted_user_count=10; // If visited by this many users a domain is considered 'trusted'.\nlet max_sites=3; // Maximum number of different sites visited using this user-agent.\n// Client-specific query to obtain 'browser-like' traffic from proxy logs.\nlet BrowserTraffic = (p:timespan) {\nCommonSecurityLog\n| where DeviceVendor == \"Zscaler\" and DeviceProduct == \"NSSWeblog\"\n| where TimeGenerated >ago(p)\n| project TimeGenerated, SourceUserName, DestinationHostName, RequestClientApplication\n| where (RequestClientApplication startswith \"Mozilla/\" and RequestClientApplication contains \"Gecko\")\n};\nlet CommonDomains = BrowserTraffic(timeframe)\n| summarize source_count=dcount(SourceUserName) by DestinationHostName\n| where source_count>trusted_user_count\n| project DestinationHostName;\nlet CommonUA = BrowserTraffic(timeframe)\n| summarize source_count=dcount(SourceUserName), host_count=dcount(DestinationHostName) by RequestClientApplication\n| where source_count>trusted_user_count and host_count > 100 // Normal browsers are browsers used by many people and visiting many different sites.\n| project RequestClientApplication;\n// Find browsers that are common, i.e. many users use them and they use them to visit many different sites,\n// but some users only use the browser to visit a very limited set of sites.\n// These are considered suspicious, since they might be an attacker masquerading a beacon as a legitimate browser.\nlet SuspiciousBrowers = BrowserTraffic(timeframe)\n| where RequestClientApplication in(CommonUA)\n| summarize BrowserHosts=make_set(DestinationHostName),request_count=count() by RequestClientApplication, SourceUserName\n| where array_length(BrowserHosts) <= max_sites and request_count >= min_requests\n| project RequestClientApplication, SourceUserName,BrowserHosts;\n// Just reporting on suspicious browsers gives too many false positives.\n// For example, users that have the browser open on the login screen of 1 specific application.\n// In the suspicious browsers we can search for 'beacon-like' behavior.\n// Get all browser traffic by the suspicious browsers.\nlet PotentialAlerts=SuspiciousBrowers\n| join BrowserTraffic(timeframe) on RequestClientApplication, SourceUserName\n// Find beaconing-like traffic - i.e. contacting the same host in many different hours.\n| summarize hour_count=dcount(bin(TimeGenerated,1h)), BrowserHosts=any(BrowserHosts), request_count=count() by RequestClientApplication, SourceUserName, DestinationHostName\n| where hour_count >= min_hours and request_count >= min_requests\n// Remove common domains like login.microsoft.com.\n| join kind=leftanti CommonDomains on DestinationHostName\n| summarize RareHosts=make_set(DestinationHostName), TotalRequestCount=sum(request_count), BrowserHosts=any(BrowserHosts) by RequestClientApplication, SourceUserName\n// Remove browsers that visit any common domains.\n| where array_length(RareHosts) == array_length(BrowserHosts);\n// Look back for X days to see if the browser was not used to visit more hosts.\n// This is to get rid of someone that started up the browser a long time ago, and left only a single tab open.\nPotentialAlerts\n| join BrowserTraffic(lookback) on SourceUserName, RequestClientApplication\n| summarize RareHosts=any(RareHosts),BrowserHosts1d=any(BrowserHosts),BrowserHostsLookback=make_set(DestinationHostName) by SourceUserName, RequestClientApplication\n| where array_length(RareHosts) == array_length(BrowserHostsLookback)\n",
                "queryFrequency": "P1D",
                "queryPeriod": "P7D",
                "triggerOperator": "GreaterThan",
                "triggerThreshold": 0,
                "suppressionDuration": "PT1H",
                "suppressionEnabled": false,
                "tactics": [
                    "CommandAndControl"
                ],
                "techniques": [
                    "T1071.001"
                ],
                "alertRuleTemplateName": "6345c923-99eb-4a83-b11d-7af0ffa75577",
                "customDetails": null,
                "entityMappings": [
                    {
                        "entityType": "Account",
                        "fieldMappings": [
                            {
                                "identifier": "FullName",
                                "columnName": "SourceUserName"
                            }
                        ]
                    }
                ],
                "status": "Available",
                "OriginalUri": "https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/FalconFriday/Analytic Rules/RecognizingBeaconingTraffic.yaml",
                "templateVersion": "1.0.0"
            }
        }
    ]
}

2. Fail

Expected behavior

Analytic rule deploys

Screenshots

Additional context

I suspect any and all Analytic Rules that have subtechniques fail to deploy. Using newest api (2023-02-01-preview) yields the same result.

[github-actions]

Thank you for submitting an Issue to the Azure Sentinel GitHub repo! You should expect an initial response to your Issue from the team within 5 business days. Note that this response may be delayed during holiday periods. For urgent, production-affecting issues please raise a support ticket via the Azure Portal.

[v-sudkharat]

Hi @ thanks for flagging this issue, we will soon get back to you on this. Thanks!

[v-sudkharat]

Hello @Kaloszer, please can you install the FalconForce FalconFriday Analytics solution and create that analytic rule rather than custom deploying the rule.
Sharing the screenshot for reference: -

[Kaloszer]

@v-sudkharat No, analytic rules should be deployable using their arm templates, this is a GUI action, this needs to be possible to be done using code.

[v-sudkharat]

Hello @Kaloszer, as per above failed message The technique 'T1071.001' is invalid. The expected format is 'T####', this issue is occurred due to the extra value in Techniques "T1071.001".
If you want the deploy rule using the ARM templates, can you please custom deploy below shared analytic rule and let us know if you are facing same issue again. Thanks

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "workspace": {
            "type": "String"
        }
    },
    "resources": [
        {
            "id": "[concat(resourceId('Microsoft.OperationalInsights/workspaces/providers', parameters('workspace'), 'Microsoft.SecurityInsights'),'/alertRules/6345c923-99eb-4a83-b11d-7af0ffa75577')]",
            "name": "[concat(parameters('workspace'),'/Microsoft.SecurityInsights/6345c923-99eb-4a83-b11d-7af0ffa75577')]",
            "type": "Microsoft.OperationalInsights/workspaces/providers/alertRules",
            "kind": "Scheduled",
            "apiVersion": "2022-11-01-preview",
            "properties": {
                "displayName": "Beacon Traffic Based on Common User Agents Visiting Limited Number of Domains",
                "description": "This query searches web proxy logs for a specific type of beaconing behavior by joining a number of sources together: \n- Traffic by actual web browsers - by looking at traffic generated by a UserAgent that looks like a browser and is used by multiple users\nto visit a large number of domains.\n- Users that make requests using one of these actual browsers, but only to a small set of domains, none of which are common domains.\n- The traffic is beacon-like; meaning that it occurs during many different hours of the day (i.e. periodic). \n",
                "severity": "Medium",
                "enabled": true,
                "query": "let timeframe = 1d; // Timeframe during which to search for beaconing behavior.\nlet lookback = 7d; // Look back period to find if browser was used for other domains by user.\nlet min_requests=50; // Minimum number of requests to consider it beacon traffic.\nlet min_hours=8; // Minimum number of different hours during which connections were made to consider it beacon traffic.\nlet trusted_user_count=10; // If visited by this many users a domain is considered 'trusted'.\nlet max_sites=3; // Maximum number of different sites visited using this user-agent.\n// Client-specific query to obtain 'browser-like' traffic from proxy logs.\nlet BrowserTraffic = (p:timespan) {\nCommonSecurityLog\n| where DeviceVendor == \"Zscaler\" and DeviceProduct == \"NSSWeblog\"\n| where TimeGenerated >ago(p)\n| project TimeGenerated, SourceUserName, DestinationHostName, RequestClientApplication\n| where (RequestClientApplication startswith \"Mozilla/\" and RequestClientApplication contains \"Gecko\")\n};\nlet CommonDomains = BrowserTraffic(timeframe)\n| summarize source_count=dcount(SourceUserName) by DestinationHostName\n| where source_count>trusted_user_count\n| project DestinationHostName;\nlet CommonUA = BrowserTraffic(timeframe)\n| summarize source_count=dcount(SourceUserName), host_count=dcount(DestinationHostName) by RequestClientApplication\n| where source_count>trusted_user_count and host_count > 100 // Normal browsers are browsers used by many people and visiting many different sites.\n| project RequestClientApplication;\n// Find browsers that are common, i.e. many users use them and they use them to visit many different sites,\n// but some users only use the browser to visit a very limited set of sites.\n// These are considered suspicious, since they might be an attacker masquerading a beacon as a legitimate browser.\nlet SuspiciousBrowers = BrowserTraffic(timeframe)\n| where RequestClientApplication in(CommonUA)\n| summarize BrowserHosts=make_set(DestinationHostName),request_count=count() by RequestClientApplication, SourceUserName\n| where array_length(BrowserHosts) <= max_sites and request_count >= min_requests\n| project RequestClientApplication, SourceUserName,BrowserHosts;\n// Just reporting on suspicious browsers gives too many false positives.\n// For example, users that have the browser open on the login screen of 1 specific application.\n// In the suspicious browsers we can search for 'beacon-like' behavior.\n// Get all browser traffic by the suspicious browsers.\nlet PotentialAlerts=SuspiciousBrowers\n| join BrowserTraffic(timeframe) on RequestClientApplication, SourceUserName\n// Find beaconing-like traffic - i.e. contacting the same host in many different hours.\n| summarize hour_count=dcount(bin(TimeGenerated,1h)), BrowserHosts=any(BrowserHosts), request_count=count() by RequestClientApplication, SourceUserName, DestinationHostName\n| where hour_count >= min_hours and request_count >= min_requests\n// Remove common domains like login.microsoft.com.\n| join kind=leftanti CommonDomains on DestinationHostName\n| summarize RareHosts=make_set(DestinationHostName), TotalRequestCount=sum(request_count), BrowserHosts=any(BrowserHosts) by RequestClientApplication, SourceUserName\n// Remove browsers that visit any common domains.\n| where array_length(RareHosts) == array_length(BrowserHosts);\n// Look back for X days to see if the browser was not used to visit more hosts.\n// This is to get rid of someone that started up the browser a long time ago, and left only a single tab open.\nPotentialAlerts\n| join BrowserTraffic(lookback) on SourceUserName, RequestClientApplication\n| summarize RareHosts=any(RareHosts),BrowserHosts1d=any(BrowserHosts),BrowserHostsLookback=make_set(DestinationHostName) by SourceUserName, RequestClientApplication\n| where array_length(RareHosts) == array_length(BrowserHostsLookback)\n",
                "queryFrequency": "P1D",
                "queryPeriod": "P7D",
                "triggerOperator": "GreaterThan",
                "triggerThreshold": 0,
                "suppressionDuration": "PT1H",
                "suppressionEnabled": false,
                "tactics": [
                    "CommandAndControl"
                ],
                "techniques": [
                    "T1071"
                ],
                "alertRuleTemplateName": "6345c923-99eb-4a83-b11d-7af0ffa75577",
                "customDetails": null,
                "entityMappings": [
                    {
                        "entityType": "Account",
                        "fieldMappings": [
                            {
                                "identifier": "FullName",
                                "columnName": "SourceUserName"
                            }
                        ]
                    }
                ],
                "status": "Available",
                "OriginalUri": "https://github.com/Azure/Azure-Sentinel/blob/master/Solutions/FalconFriday/Analytic Rules/RecognizingBeaconingTraffic.yaml",
                "templateVersion": "1.0.0"
            }
        }
    ]
}

[Kaloszer]

No, that seems to be an invalid solution. Unless by design this repository provides invalid .yaml files that cannot be 'more or less' converted to a valid ARM templates.
I have also found that supposedly Sentinel is aligned with MITRE 11 which contains subtechniques. According to this GH issue this is working in Hunting Queries but not for Analytic Rules?

#5425

MITRE framework in v11 contains subtechniques
https://attack.mitre.org/versions/v11/

Obviously, when you remove the subtechnique, which seems not be supported in the current Microsoft Sentinel solution this will work, that's what I do something for analytic rules pre-deplyoment now to fix this issue. Then you are able to deploy the analytic rule, but that does not explain why there are analytic rules within this repository with an invalid technique. Just look for it:

https://github.com/search?q=repo%3AAzure%2FAzure-Sentinel+path%3A*.yaml+.001&type=code

1. If this is by design, please confirm
2. This should be documented somewhere that Microsoft Sentinel does not support subtechniques (couldn't find any information about it, other than the error message - if there is - please point to it for reference)
3. If this is an upcoming feature it would be nice to know when to expect it

[v-sudkharat]

Hello @Kaloszer, we are connecting with our concerned team for this issue, once we get any information on this, we will update you. Thanks!

[v-sudkharat]

@Kaloszer, we acknowledge that some of these templates have subtechniques that will cause the deployment to fail. As per discussion with concern team, this is by design and Sentinel currently doesn’t support sub techniques.
Thanks!

[Kaloszer]

@Kaloszer, we acknowledge that some of these templates have subtechniques that will cause the deployment to fail. As per discussion with concern team, this is by design and Sentinel currently doesn’t support sub techniques. Thanks!

Please reflect this in the docs someplace as this is something that is not defined anywhere, it's misleading. As soon as this is done this matter can be considered closed :)

[v-sudkharat]

Hi @Kaloszer, We are getting in touch with concern team about the documentation. Please expect an update by - 28 Sep. 2023 Thanks!

[v-sudkharat]

Hi @Kaloszer, we connected with concerned team for this issue. They will check on this. Once we get any further information, we will update you. Thanks!

[v-sudkharat]

Hi @Kaloszer, as per discussion with concern team, we are not currently updating the document, but team is considering this fix and will be available in upcoming few months. but with no ETA as of now.
so, closing this issue. If you still need support for this issue, feel free to re-open it any time. Thank you for your co-operation.