Installing the Azure Arc Agent for Windows Event Collection(and more)

If your SIEM is Microsoft Sentinel, then you likely need to collect Windows security events.
If you’ve never heard of ‘Arc’ then you’re likely collecting Windows logs using the legacy ‘Log Analytics Agent (Microsoft Monitoring Agent)’.
Microsoft recommends using the Azure Arc agent, along with the Azure Monitoring Agent, which will get push out automatically once configured in Arc, or Azure Monitor, or Sentinel.

The Arc agent extends the security controls you normally only get from cloud servers to your on-prem servers, and simplifies the number of agents needed for on-prem servers to work with Azure.

A discussion about Arc/CSPM/Azure Policy/Defender for Cloud/Asset Inventory/Attack Surface is out of the scope of this article, but trust me, you want to use Arc for all your on-prem windows and linux servers.

Prerequisites for Arc:

  • Local admin access to the on-prem windows/linux server
  • Global Admin access to Azure
  • On-prem server must have Internet access or a direct connection to Azure.
  • Sentinel Log Analytics Workspace

ARC agent installation:

Azure Monitor Agent (AMA) Installation

  • You actually don’t need to install AMA.
  • You configure a ‘Data Collection Rule’ in Sentinel or Azure Monitor with the preferred parameters, and this will enable the AMA as an ‘Arc Extension’

Sentinel Connector AMA Setup

  • Since most of the topics in this blog are around Sentinel, that will be the configuration discussed here.
    • You can also configure this in Azure Monitor and in Azure Arc, but the data might not then be accessible as easily in Sentinel (it may get stored in the Events table vs the SecurityEvents table – see references below)
  • In Sentinel go to: Connectors > “Windows Security Events via AMA”
  • Create a ‘Data Connection Rule (DCR)’:
    • Add your servers
    • Select the ‘Common’ filter – this is the best choice for all of the Security Events.
  • After a few minutes you should see your on-prem security events in the SecurityEvents table.

References:

https://docs.microsoft.com/en-us/azure/azure-monitor/faq#azure-monitor-agent

https://docs.microsoft.com/en-us/azure/azure-monitor/agents/azure-monitor-agent-windows-client

Troubleshooting CEF syslog feeding up to Microsoft Sentinel

There are some excellent tips on testing CEF logs here.

https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/ingest-sample-cef-data-into-azure-sentinel/ba-p/1064158

I’d suggest:

Run this command as a validation test:

logger -p local4.warn -t CEF “CEF:0|Microsoft|ATA|1.9.0.0|AbnormalSensitiveGroupMembershipChangeSuspiciousActivity|Abnormal modification of sensitive groups|5|start=2018-12-12T18:52:58.0000000Z app=GroupMembershipChangeEvent suser=krbtgt msg=krbtgt has uncharacteristically modified sensitive group memberships. externalId=2024 cs1Label=url cs1=https://192.168.0.220/suspiciousActivity/5c113d028ca1ec1250ca0491

Then replace the sample log with your own and see if it also gets through.

Also verify that if you remove your rsyslog CEF filter that the logs at least get to syslog. If they do, then it’s possible this is an unsupported CEF format. Which isn’t terrible because you can still parse the logs using KQL.

To check if your logs are event getting to your syslog server use tcpdump eg:
tcpdump -i any port syslog -A -s0 -nn

And note that you could be seeing your logs with the above tcpdump command but they’re still not getting to Sentinel. In that case check if the local firewall rules are blocking syslog.

If you find out it’s an unsupported CEF format it’s still possible to fix but it likely involves regex changes to the rsyslog configuration in security_events.conf or elsewhere. (see reference below).

Reference:
https://docs.microsoft.com/en-us/azure/sentinel/troubleshooting-cef-syslog?tabs=rsyslog

Pkexec could affect many Linux operating systems

https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

I’m on a linux VM now and yep, there’s pkexec…

“iconv_open() executes small shared libraries…”

“Unfortunately, CVE-2021-4034 allows us to re-introduce GCONV_PATH into
pkexec’s environment, and to execute our own shared library, as root.”

Shouldn’t be long before we see a lot of demonstrations for this.