The Activity Log provides information on subscription level events that have occurred in Azure, with the following relevant information:
Administrative Data: Covers the logging of all creation, update, deletion and action operations performed through the Resource Manager. All actions performed by an user or application using the Resource Manager are interpreted as an operation on a specific resource type. Operations such as write, delete, or action involve logging both the start and the success or failure of that operation in the Administrative category. The Administrative category also includes any changes to the role-based access control of a subscription.
Alert Data: Contains the log of all activations of Azure alerts. For example we will be able to obtain an alert when the percentage of CPU usage of one of the virtual machines of the infrastructure exceeds a certain threshold. Azure provides the option to elaborate customized rules to receive notifications when an event coincides with the rule. When an alert is activated it is logged in the Activity Log.
Security Data: Here we contemplate the log of alerts generated by the Azure Security Center. For example, a log could be related to the execution of suspicious files.
Service HealthData: Covers the log of any service health incident that has occurred in Azure. There are five different types of health events: Action Required, Assisted Recovery, Incident, Maintenance, Information or Security, logged when a subscription resource is affected by the event.
Autoscale Data: Contains the logging of any event related to the autoscale engine based on the autoscale settings in your subscription. Autoscale start events and successful or failed events are logged in this category.
Recomendation Data: Includes Azure Advisor recommendation events.
To monitor the activities of our infrastructure we can use the Azure Log Analytics REST API or we can directly access the content of Azure Storage accounts. This section explains the two ways to proceed, looking at the steps to follow in the Microsoft Azure portal and using the azure-logs module on the Wazuh manager.
Azure Log Analytics is a service that monitors your infrastructure offering query capabilities that allow you to perform advanced searches specific to your data.
The Log Analytics solution helps you to analyze and search the Azure activity log in all your Azure subscriptions, providing information about the operations performed with the resources of your subscriptions.
We can consult all the data collected by Log Analytics through the Azure Log Analytics REST API. The Azure Log Analytics API uses the Azure Active Directory authentication scheme. Part of the installation guide is based on this tutorial.
In order to use Azure Log Analytics, we need to perform additional configuration on the Microsoft Azure portal. The goal is to have an application or client qualified to use the Azure Log Analytics REST API.
The process explained below details the creation of an application that will use the of Azure Log Analytics REST API. You can also configure an existing application, the process is similar from the creation of the application, in this case, start directly at step 1.2.
1.1 - In the
Azure Active Directory section select the option
App registrations and once inside, select
New application registration.
1.2 - Proceed to create our application
2.1 - Whether we have created a new application or are using an existing one, we need to access the application
Settings and select
Required permissions. Note that we can also see the
Application ID, a necessary field to authenticate the application later.
2.2 - We choose the API we want to access.
2.3 - Select the permissions. Choose the permissions you want to provide to the application.
3.1 - Select
Keys and fill in the
EXPIRES fields. Once we
save the key we will get its
value. This will be the key with which we will authenticate our application in order to use the API.
4.1 - Finally, we must configure Log Analytics to ensure our access once we have authenticated ourselves in our application. First select the
Log Analytics entry. Next we will choose the workspace. Here we can see the
Workspace Id field, which we will use to make requests to the API.
4.2 - Now select the
Access control (IAM) input and choose the
add option. In the
add permissions window we will set the desired
select our application, ending with the
Next will see the options we have to configure for the Wazuh integration.
5.1 - Proceed to configure the
azure-logs wodle in the Wazuh manager. We will use the data that we took previously as the key and ID of the application. In this case, we have introduced both fields in a file for authentication. You will also need the workspace ID. Through the following configuration, Wazuh is ready to search for any query accepted by Azure Log Analytics. In this case we are going to monitor all the activity by means of the query AzureActivity. Finally we add a representative
tag and we will indicate that request will be made every Monday at 02:00 and the first search will be made two days ago and that does not run on start:
When we choose to use a file for authentication, its content must be
field = value. For example:
application_id = 317...764 application_key = wUj...9cj
<wodle name="azure-logs"> <disabled>no</disabled> <wday>monday</wday> <time>02:00</time> <run_on_start>no</run_on_start> <log_analytics> <auth_path>/home/manager/Azure/log_analytics_auth.txt</auth_path> <tenantdomain>wazuh.onmicrosoft.com</tenantdomain> <request> <tag>azure-activity</tag> <query>AzureActivity</query> <workspace>d6b...efa</workspace> <time_offset>2d</time_offset> </request> </log_analytics> </wodle>
You can see the module reference here.
tenantdomain is necessary and we can obtain it easily. In the azure portal, we can see it leaving the cursor in the upper right corner.
Adding this section to the configuration file of our Wazuh manager, we will start with the monitoring of activities using Azure Log Analytics.
Using the previously mentioned configuration, we will see an example of monitoring the activity of our infrastructure.
As the records are in
.json format, with these rules already included in the integration, we can start generating alerts:
<rule id="87801" level="5"> <decoded_as>json</decoded_as> <field name="azure_tag">azure-log-analytics</field> <description>Azure: Log analytics</description> </rule> <rule id="87810" level="3"> <if_sid>87801</if_sid> <field name="Type">AzureActivity</field> <description>Azure: Log analytics activity</description> </rule> <rule id="87811" level="3"> <if_sid>87810</if_sid> <field name="OperationName">\.+</field> <description>Azure: Log analytics: $(OperationName)</description> </rule>
We will see as example, the creation of a new virtual machine. We are going to deploy an Ubuntu 18.04 server.
In this example we have prepared a minimum configuration when creating the virtual machine.
We select the
Log Analytics entry, write our query
run the search. This log shows that a virtual machine has been created or updated. If we take a look at the Resource column we can see what have just been deployed.
When our integration performs the query, we will be able to see the results in Kibana. In this case we can notice that the
87811 rule has been triggered and that the fields
EventSubmissionTimestamp coincide among others.
Azure Storage refers to Microsoft Azure cloud storage by providing a massively scalable object store for data objects, a messaging store for reliable messaging, a file system service for the cloud, and a NoSQL store.
Next we will show how to use the Azure portal to archive the Azure activity log in a storage account, how to configure the
azure-logs wodle and show a usage case for a better understanding.
As an alternative to the Azure Log Analytics REST API, Wazuh offers the possibility to access Azure Storage accounts in a simple way. The activity logs of the Microsoft Azure infrastructure can be exported to the storage accounts.
We will search the
Activity logs entry from the
All services entry. Just type “Activity” in the search engine.
Once we access the log of activities, select the option to export.
Select the option to export to a storage account, establish the subscription we want to monitor and choose the account where the activity logs will be stored.
2.1 - We will be able to see the credentials needed to access the desired storage account in the
Storage accounts section. We add a representative
tag and select our account, then we choose the Access keys entry, where we use the
When we choose to use a file for authentication, its content must be field = value. For example:
account_name = wazuhgroupdiag665 account_key = wr+...jOQ
In this case, the integration will be executed with an
interval of one day, the credentials will be taken from a file and we will proceed to search in the container
insights-operational-logs, all the blobs that have the extension
.json in the last
24 hours. We also indicate the type of content that have the blobs that we are going to recover, in this case
As of November 1st 2018, the format of logs stored in Azure accounts became inline JSON (
json_inline in Wazuh) and the previous format became obsolete (
json_file in Wazuh).
<wodle name="azure-logs"> <disabled>no</disabled> <interval>1d</interval> <run_on_start>yes</run_on_start> <storage> <auth_path>/home/manager/Azure/storage_auth.txt</auth_path> <tag>azure-activity</tag> <container name="insights-operational-logs"> <blobs>.json</blobs> <content_type>json_inline</content_type> <time_offset>24h</time_offset> </container> </storage> </wodle>
You can see the module reference here.
Using the previously mentioned configuration, we will see an example of monitoring the infrastructure activity.
The logs are stored in JSON files, therefore, with these rules, already included in the integration, we will be able to obtain the related alerts.
<rule id="87803" level="3"> <decoded_as>json</decoded_as> <field name="azure_tag">azure-storage</field> <description>Azure: Storage</description> </rule> <rule id="87813" level="3"> <if_sid>87803</if_sid> <field name="operationName">\.+</field> <description>Azure: Storage: $(OperationName)</description> </rule>
As an example we are going to remove the virtual machine we created for the example of Azure Log Analytics. From the
Storage accounts entry, select our virtual machine and choose the
delete option. Confirm the deletion and proceed.
Again from the
Storage accounts section, we select the account we want to access. Once there we access the
We select the container where we store the blobs.
Navigate through the directories until we find the blob we want to check, in this case will be
Download the blob to check its content.
In the downloaded blob we found several logs, we focus on this particular log, which refers to the removal of the virtual machine.
When our integration performs the access, we will be able to see the results in Kibana. In this case we can notice that the
87813 rule has been triggered and see that the fields
time match among others.