Listen to this Post
Introduction:
Many organizations deploying serverless functions on Microsoft Azure operate under a dangerous misconception: that enabling standard platform logging provides comprehensive security visibility. In reality, a critical gap exists between control-plane management logs and application-level execution logs, allowing malicious activity to go completely undetected. This article dissects this visibility blind spot, explains how attackers can abuse anonymous or parameter-driven functions without leaving a trace in primary audit trails, and provides a roadmap for enabling the necessary diagnostic logging and crafting effective detections.
Learning Objectives:
- Understand the critical difference between Azure Activity Logs (control plane) and Diagnostic Logs/Application Insights (data plane) for Azure Functions.
- Learn how to properly configure full request logging and user attribution for Azure Function Apps.
- Build a detection rule to identify unauthorized or anomalous function executions that evade standard monitoring.
You Should Know:
- The Control Plane vs. Data Plane Logging Divide
Azure provides distinct logging pipelines. The Azure Activity Log records control-plane operations: management events like creating a Function App, updating configuration, or deleting a resource. It does not record the actual execution of a function. The data-plane operations—each individual HTTP trigger invocation—are logged only if Diagnostic Settings are enabled to send logs to a Log Analytics workspace or if Application Insights is integrated.
Step-by-Step Guide to Verify and Enable Diagnostic Logs:
- Navigate to your Function App in the Azure Portal.
2. Under the Monitoring section, select Diagnostic settings.
3. Click + Add diagnostic setting.
4. Select the log categories to forward:
FunctionAppLogs: Contains application logs from your function code.
AppServiceHTTPLogs: Crucial for security; includes HTTP request data (source IP, URL, user-agent, status code).
5. Choose a destination, ideally a Log Analytics workspace for querying via KQL (Kusto Query Language).
6. For Application Insights:
In the Function App sidebar, select Application Insights under the Settings section.
Click Turn on Application Insights, select a linked resource or create a new one.
Ensure the `.NET SDK` version is current for full feature support.
2. The Anonymous Attacker Problem: Missing Identity Context
Even with Diagnostic Logs enabled, a significant shortfall remains. By default, these logs may not capture the identity of the user or principal that invoked the function. If an attacker exploits a function configured with `authLevel: anonymous` or finds a way to bypass authentication, the logs will show an execution but might not answer who triggered it. Context is limited to network-level information like IP address.
Step-by-Step Guide to Enrich Logs with Identity Context:
- Enable Detailed Request Logging in Application Insights: Modify your `ApplicationInsights.config` or use code-based configuration to collect request headers.
// Example for .NET: In Startup.cs, ensure request collection is enabled. services.AddApplicationInsightsTelemetry(options => { options.EnableRequestTrackingTelemetryModule = true; }); - Log Authentication Claims in Function Code: Manually inject and log user identity from the request context.
public static async Task<IActionResult> Run(HttpRequest req, ILogger log) { // Extract and log principal identity from headers or token var principal = req.HttpContext.User; log.LogInformation($"Function executed by: {principal.Identity.Name}"); // ... function logic ... } - For Authenticated Functions: Ensure you are passing and validating tokens, and that the `X-MS-CLIENT-PRINCIPAL-NAME` header (or similar) is being logged via the HTTPLogs.
3. Building Detections for Unauthorized Executions
With logs flowing to Log Analytics, you can construct Kusto (KQL) queries to hunt for suspicious activity. The goal is to identify executions that are anomalous in pattern, source, or identity.
Step-by-Step Guide to a Core Detection Rule:
This query looks for function executions from unexpected locations or principals outside a defined allow list.
// KQL Query for Log Analytics
AppServiceHTTPLogs
| where TimeGenerated > ago(1h)
| where CsUriStem contains "/api/" // Adjust to match your function route pattern
// Parse the client principal from headers if available
| extend Principal = parse_json(CsHeaders)["X-MS-CLIENT-PRINCIPAL-NAME"]
| where Principal !in ("[email protected]", "system_identity")
// Or detect anomalous source IPs not in a trusted network range
| where ClientIp !startswith "10.0." and ClientIp !startswith "192.168."
| project TimeGenerated, CsMethod, CsUriStem, ClientIp, Principal, UserAgent, ScStatus
| order by TimeGenerated desc
This query should be scheduled as an alert rule in Azure Sentinel or a scheduled query in Log Analytics to trigger incidents for investigation.
4. Hardening the Function App Configuration
Prevention is key. Tighten the configuration of your Function App to reduce the attack surface.
Step-by-Step Hardening Guide:
- Eliminate Anonymous Auth: Set the `authLevel` for HTTP triggers to `function` or
admin. Use Azure AD or Function Keys for authentication.
In `function.json`: `”authLevel”: “function”`
- Implement IP Restrictions: In the Function App’s Networking settings, configure Access Restrictions to allow only traffic from specific VPNs, known APIs, or Azure Front Door.
- Use Private Endpoints: For functions processing sensitive data, deploy them inside a VNet and use Private Endpoints to eliminate public internet exposure.
- Regularly Audit Function Keys: Rotate and audit function access keys stored in Azure Key Vault.
5. Exploitation Scenario: Parameter Tampering & Data Exfiltration
An attacker discovers a publicly accessible function that queries a database based on a user ID parameter. By tampering with the parameter (e.g., changing `?userid=123` to ?userid=123 OR 1=1), they could exfiltrate entire datasets. Without proper HTTP logging, this attack leaves no trace beyond potential spikes in database DTUs.
Mitigation Step-by-Step Guide:
- Input Validation: Implement strict input validation and parameterized queries in your function code.
Python Example with SQL parameterization import pyodbc user_id = req.params.get('userid') DO NOT concatenate. Use parameters. cursor.execute("SELECT FROM users WHERE id = ?", user_id) - Log All Inputs: Ensure the diagnostic logging configuration captures query strings (
CsUriQueryfield in HTTPLogs). - Create Content-Based Detections: Build a KQL query that alerts on unusual parameter patterns or excessive data volume in responses (
ScBytesfield).AppServiceHTTPLogs | where CsUriQuery has_any ("union", "select", "--", "waitfor", "exec") | project TimeGenerated, CsUriStem, CsUriQuery, ClientIp
What Undercode Say:
- Visibility is Not Default: The cloud shared responsibility model extends to logging. Platform-level logs are for platform health, not your application security. Assuming they provide full coverage is a fundamental and dangerous error.
- Identity is the Keystone: Without positively linking an action to an identity, detection becomes mere anomaly detection on network traffic. In modern cloud environments, where IPs are ephemeral, embedding user and service principal context into every log is non-negotiable for effective security operations.
The core analysis reveals a systemic issue in cloud adoption: the disconnect between DevOps agility and SecOps visibility. Functions are deployed for speed and scale, but security logging is often an afterthought, treated as a “platform feature” rather than a critical application component. This creates a perfect environment for “feature abuse,” where attackers operate within the allowed mechanics of the service but towards malicious ends, completely invisible to standard cloud governance tooling.
Prediction:
This logging gap will be a primary vector for sustained, undetected breaches in cloud environments over the next 2-3 years. As more critical business logic moves to serverless architectures, attackers will increasingly scan for anonymously accessible functions, poorly logged APIs, and misconfigured triggers. Major incidents will result not from sophisticated zero-days, but from the exploitation of these visibility failures, leading to large-scale data exfiltration and manipulation. The regulatory and legal fallout will force a shift-left in logging strategy, making detailed audit trails a mandatory requirement in the CI/CD pipeline for cloud functions, much like code testing is today.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Liora Itkin – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
