When the "Read all properties" permission of a user object is set to be
audited in the AD, an event of ID 4662 (An operation was performed on an
object) is triggered whenever a property is accessed.
This rule detects these events by flagging any non-machine
`SubjectUserName` (i.e. another user) which accesses an object of the
`User` AD schema class.
Advantages of this rule include the detection of insider-enumeration
through automated tools such as BloodHound or manually through the usage
of the PowerShell ActiveDirectory module. Although this rule qualifies
as a medium severity one, this event could be qualified as high/critical
one if flagged on non-used canary user-accounts.
False positives may include administrators performing the initial
configuration of new users.
Fixing the problem described in HELK here: https://github.com/Cyb3rWard0g/HELK/issues/442 where when running sigmac to generate elastalert rules, this rule has a title collision with another rule in the same directory and causes elastalert to fail to start.
When Sysmon logs a "RegistryEvent" event of ID 13, the event might contain a field named "RuleName" as shown in the following excerpt.
```xml
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Events>
<Event
xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
<System>
<Provider Name='Microsoft-Windows-Sysmon' Guid='{5770385f-c22a-43e0-bf4c-06f5698ffbd9}'/>
<EventID>13</EventID>
<Version>2</Version>
<Level>4</Level>
<Task>13</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime='2020-03-18T03:52:07.173448000Z'/>
<EventRecordID>160631</EventRecordID>
<Correlation/>
<Execution ProcessID='2156' ThreadID='3628'/>
<Channel>Microsoft-Windows-Sysmon/Operational</Channel>
<Computer>win10.sec699-40.lab</Computer>
<Security UserID='S-1-5-18'/>
</System>
<EventData>
<Data Name='RuleName'>Context,ProtectedModeExitOrMacrosUsed</Data>
<Data Name='EventType'>SetValue</Data>
<Data Name='UtcTime'>2020-03-18 03:52:07.129</Data>
<Data Name='ProcessGuid'>{36aa6401-9acb-5e71-0000-0010e3ed6803}</Data>
<Data Name='ProcessId'>5064</Data>
<Data Name='Image'>C:\Program Files\Microsoft Office\Root\Office16\WINWORD.EXE</Data>
<Data Name='TargetObject'>HKU\S-1-5-21-1850752718-2055233276-2633568556-1126\Software\Microsoft\Office\16.0\Word\Security\Trusted Documents\TrustRecords\%USERPROFILE%/Documents/sec699.docm</Data>
<Data Name='Details'>Binary Data</Data>
</EventData>
</Event>
</Events>
```
When used in combination with Elastic's Winlogbeat, the resulting field is named `winlog.event_data.RuleName`.
This commit introduces a mapping between the Sigma `RuleName` field (pre-existing in the `arcsight.yml` config) and Elastic's `winlog.event_data.RuleName`.
The presence of this field could be leveraged to build Sigma rules detecting events such as the above where a malicious macro was executed.
