Update Sysmon.md

Sysmon.md

@@ -2,11 +2,11 @@
 
 Sysmon is a free tool initially developed by Mark Russinovich and has contributions by Tomas Garnier, David Magnotti, Mark Cook, Rob Mead, Giulia Biagini, and others at Microsoft. The tool is designed to extend the current logging capabilities in Windows to aid in understanding and detecting attackers by behavior. It was developed originally for internal use at Microsoft. (Note: There are still two versions of the tool—internal and external.) Currently, the tool supports 64-bit and 32-bit systems and uses a single command line tool for installation and configuration management.
 
-For ease of collecting the logs, all of the events generated are saved in Microsoft-Windows-Sysmon/Operational EventLog, which allows current security products that already leverage collection from the EventLog in Windows.
+All of the events generated by Sysmon are saved in Microsoft-Windows-Sysmon/Operational EventLog in order to accomodate security products that already leverage the EventLog, and to make the events easier to view and collect.
 
 Sysmon is able to monitor for a series of actions on a Windows host that relate to existing behavior that is abused by threat actors. With this view on the actions, defenders are able to better detect abnormal behavior and abuses on a system.
 
-The table below shows the evet types and event ID for each.
+The table below shows the event types and event ID for each.
 
 | EventType| EventId|
 |---|---|
@@ -33,13 +33,15 @@ The table below shows the evet types and event ID for each.
 |WMI Event Consumer|20
 |WMI Consumer to Filter|21
 |DNS Query|22
+|File Delete|23
 |Error|255
 
+
 ## The Sysmon Driver
 
 All of the monitoring is performed thanks to a driver that Sysmon installs called SysmonDrv. The driver will hook into Windows APIs and leverage Event Tracing for Windows (ETW) to capture the information on the actions it wants to monitor.
 
-This Sysmon Driver has a unique attitude number of 385201 that determines the order of loading of the driver in comparison to other drivers on the system. Some blog posts recommend changing this number in the registry for obfuscation, but this may cause a conflict with another driver and prevent Sysmon from working or cause other errors on the system.
+This Sysmon Driver has a unique altitude number of 385201 that determines the order of loading of the driver in comparison to other drivers on the system. Some blog posts recommend changing this number in the registry for obfuscation, but this may cause a conflict with another driver and prevent Sysmon from working or cause other errors on the system.
 
 The driver is loaded by a service at system startup and a secondary service then queries the cached information.
 
@@ -321,6 +323,12 @@ sysmon.exe -i [configfile path]
 sysmon.exe -c [configfile path]
 ```
 
+* **-a** : Archive Folder
+
+```shell
+sysmon.exe -a [archive folder]
+```
+
 * **-u** : un-install Sysmon
 
 ```shell
@@ -428,6 +436,7 @@ Each of these operators execute against the value in a given field for each of t
 
 ## Event Schema
 
+
 Under the events element each event that Sysmon generates is defined as an event element. Each event is defined as shown below:
 
 * **name** : Name of event
@@ -494,7 +503,8 @@ Previous schemas can be used in newer releases of the binary allowing for upgrad
 
 ![config file](./media/image13.png)
 
-We can optionally specify a hashing algorithm with the HashAlgorithms elements. More than one can be specified in this element or all of them using the \* symbol. The presence of the CheckRevocation element is enough to allow for checking whether a certificate used to sign an image has been revoked. There are three main ways to organize filters with the latest version of Sysmon.
+We can optionally specify a hashing algorithm with the HashAlgorithms elements. More than one can be specified in this element or all of them using the \* symbol.
+The presence of the CheckRevocation element is enough to allow for checking whether a certificate used to sign an image has been revoked. There are three main ways to organize filters with the latest version of Sysmon.
 
 * EventType filters.
 
@@ -516,7 +526,7 @@ This type of configuration is only good with Schema 4.22 and above. It is recomm
 
 The RuleGroup element allows for the modification of the logic of the filters and also allows for more complex logic since multiple Rule elements with multiple filters can be created and the logic for the filters can be modified in order to capture actions in a more granular way.
 
-![RuleGroup](./media/image16.png)
+![](./media/image16.png)
 
 Remember: You can only have one single EventType per RuleGroup. Sysmon will not error if you have more than one, but only the first EventType filters will be loaded.
 
@@ -526,22 +536,25 @@ When using AND in a Rule element, the name used to populate the RuleName will be
 
 Rules are processed in the order they are placed in the configuration file. This is important because once a Rule matches and the information for that EventType is included in the Windows EventLog, no other rule will be processed against that action. Filters that are not in a Rule element will be processed in the order that they appear in the schema. This also applies to multiple filters inside a Rule where the schema order is used.
 
+![](./media/image17.png)
+
 ![RuleGroup Order](./media/image17.png)
 
 ## Configuration File Best Practices
 
 It is important to track what a configuration does and keep a changelog. For this reason, it is recommended to add headers to track basic information like changelog, version, sysmon version tested against, etc.
 
-![Comment Header](./media/image18.png)
+![](./media/image18.png)
 
 For RuleGroups, Rules and Filters use comments to organize filters and to provide information on what each filter is doing.
 
-![XML Comments](./media/image19.png)
+![](./media/image19.png)
 
 Hash configurations that are deployed and keep a log of them for later
 verification.
 
-Hash configurations that are deployed and keep a log of them for later verification. On a system where the Sysmon service process consumes a lot of CPU resources, the number of filters and operators should be reviewed. The operators that use slightly more CPU are:
+Hash configurations that are deployed and keep a log of them for later verification.
+On a system where the Sysmon service process consumes a lot of CPU resources, the number of filters and operators should be reviewed. The operators that use slightly more CPU are:
 
 * contains
 
@@ -553,7 +566,7 @@ A method for checking applied configuration is hashing the configuration
 in the registry.
 <https://github.com/PSGumshoe/PSGumshoe/blob/master/EventLog/Get-SysmonRuleHash.ps1>
 
-![Get-SysmonRuleHash](./media/image20.png)
+![](./media/image20.png)
 
 Since getting stated can be complex, some great resources that serve as starting points for Rule development and reference include:
 
@@ -579,20 +592,21 @@ This does not mean that an attacker will not use more advanced methods to enumer
 
 Detection of Sysmon is achieved by looking at the areas that cannot be changed.
 
-  **Indicator**                **Can it be Changed**
-  ---------------------------- -----------------------
-  Driver Name                  YES
-  Service Name                 YES
-  Registry Config Path         YES
-  Driver altitude Number       NO
-  EventLog Path and Name       NO
-  Sysmon Service Description   NO (Manually)
+  **Indicator**               | **Can it be Changed**
+  ----------------------------| -----------------------
+  |Driver Name|                  YES
+  |Service Name|                 YES
+  |Registry Config Path|         YES
+  |Driver altitude Number|       NO
+  |EventLog Path and Name|       NO
+  |Sysmon Service Description|   NO (Manually)
 
 When Sysmon configuration is modified using the Sysmon command line tool, an **EventId 16** is generated. If the registry binary value is modified directly, no event is generated, and configuration is applied as soon as the value is modified.
 
 When a GPO is used to update configuration by default every 90 minutes, the configuration will be updated. A better solution is to use a configuration management solution like DSC that can monitor for changes and update as soon as a change is detected.
 
-Sysmon can be configured to monitor its own conjuration to detect whether an attacker deletes or alters it. In the event that it is cleared, this will be the last event logged by Sysmon itself from its configured filters.
+Sysmon can be configured to monitor its own configuration to detect whether an attacker deletes or alters it. In the event that it is cleared, this will be the last event logged by Sysmon itself from its configured filters.
+
 
 ![](./media/image21.png)
 
@@ -620,7 +634,7 @@ Existing tools for parsing rules out of the registry break often as Sysmon is up
 
 ## Configuration Deployment
 
-Most environments that have the capabilities to leverage Sysmon enhanced log collection also have software deployment systems like Altiris, System Center Configuration Manager, Desired State Configuration, etc. This is why these are just general recommendations.
+Most environments that have the capabilities to leverage Sysmon enhanced log collection also have software deployment systems like Altiris, System Center Configuration Manager, Desired State Configuration, etc. This is why these are just general recommendations. 
 
 ### Deployment Script
 
@@ -648,7 +662,7 @@ if ($Present) {
     } else {
         # Execute upgrade process.
         Write-Host -Object "[-] Sysmon needs upgrade." -ForegroundColor Red
-        <path to Sysmon.exe> -U
+	    <path to Sysmon.exe> -U
         <path to Sysmon.exe> -I
     }
 } else {