diff --git a/detections/aws_activity_from_non_approved_accounts.json b/detections/aws_activity_from_non_approved_accounts.json
index f55261d0fe..a4c80295c9 100644
--- a/detections/aws_activity_from_non_approved_accounts.json
+++ b/detections/aws_activity_from_non_approved_accounts.json
@@ -53,7 +53,7 @@
   "entities": [
     "user"
   ],
-  "how_to_implement": "You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. You must also populate the `identity_lookup_expanded` lookup shipped with the Asset and Identity framework to be able to look up users in your identity table in Enterprise Security (ES). Leverage the support search called \"Create a list of approved AWS service accounts\": run it once every 30 days to create and validate a list of service accounts.\n\nThis search produces fields (`eventName`,`firstTime`,`lastTime`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** AWS Event Name, **Field:** eventName</li><li>**Label:** First Time, **Field:** firstTime</li><li>**Label:** Last Time, **Field:** lastTime</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. You must also populate the `identity_lookup_expanded` lookup shipped with the Asset and Identity framework to be able to look up users in your identity table in Enterprise Security (ES). Leverage the support search called \"Create a list of approved AWS service accounts\": run it once every 30 days to create and validate a list of service accounts.\n\nThis search produces fields (`eventName`,`firstTime`,`lastTime`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** AWS Event Name, **Field:** eventName\n\n1. \n\n1. **Label:** First Time, **Field:** firstTime\n\n1. \n\n1. **Label:** Last Time, **Field:** lastTime\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "ada0f478-84a8-4641-a3f1-d82362d4bd55",
   "investigations": [
     {
diff --git a/detections/aws_cross_account_activity_from_new_account.json b/detections/aws_cross_account_activity_from_new_account.json
index 0008ee459e..831f9441a4 100644
--- a/detections/aws_cross_account_activity_from_new_account.json
+++ b/detections/aws_cross_account_activity_from_new_account.json
@@ -49,7 +49,7 @@
       }
     }
   },
-  "eli5": "This search\n\n1. Retrieves the **AssumeRole** event</li><li>Verifies that the log entry contains a value for the account ID of the requesting account</li><li>Ensures that the requesting account ID does not match the account ID of the requested account</li><li>Pulls in the previously seen requesting and requested account IDs</li><li>Splits up and executes multiple search paths at the same.</li><li>The first path determines the **firstTime** and **lastTime** entries for the cache file</li><li>Outputs the data to the cache file.</li><li>Creates a conditional statement that is always false (both because we don't want these values to exit the search pipeline and because we think we're clever).</li></ol>The second pipeline adds the **firstTime** and **lastTime** entries to search results. Next, it filters out any account pairs that haven't been seen for the first time within the last hour. The `isnotnull(_time)` will remove the entries from the cache file.\n\nThe search finishes by gathering the data that it will display to the user.",
+  "eli5": "This search\n\n1. Retrieves the **AssumeRole** event\n\n1. Verifies that the log entry contains a value for the account ID of the requesting account\n\n1. Ensures that the requesting account ID does not match the account ID of the requested account\n\n1. Pulls in the previously seen requesting and requested account IDs\n\n1. Splits up and executes multiple search paths at the same.\n\n1. The first path determines the **firstTime** and **lastTime** entries for the cache file\n\n1. Outputs the data to the cache file.\n\n1. Creates a conditional statement that is always false (both because we don't want these values to exit the search pipeline and because we think we're clever).The second pipeline adds the **firstTime** and **lastTime** entries to search results. Next, it filters out any account pairs that haven't been seen for the first time within the last hour. The `isnotnull(_time)` will remove the entries from the cache file.\n\nThe search finishes by gathering the data that it will display to the user.",
   "entities": [
     "dest_user"
   ],
diff --git a/detections/aws_spike_acl_activity.json b/detections/aws_spike_acl_activity.json
index f32cf49a3f..fc0027a082 100644
--- a/detections/aws_spike_acl_activity.json
+++ b/detections/aws_spike_acl_activity.json
@@ -49,7 +49,7 @@
       }
     }
   },
-  "eli5": "This search and its corresponding subsearch run through the following series of steps: \n\n1. Retrieve all the AWS CloudTrail log entries that have recorded AWS API calls specifically for creating/modifying/replacing network Access Control Lists (ACLs).</li><li>Kick off a subsearch that retrieves the same data and pulls out the ARN into a more friendly format.</li><li>Count the number of API calls per Amazon Resource Name (ARN).</li><li>Load the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.</li><li>Drop the count from the latest hour, since it is not necessary, and merge the rest of the data with the results of the stats command. </li><li>Rename `apiCalls` as `latestCount`.</li><li>Calculate the new average value for each ARN with the latest count, weighting the past much more heavily than the current hour. They do the same for the standard deviation--weighting the past more heavily than the current.</li><li>Update the cache file with the latest results.</li><li>Set the minimum threshold for the number of data points and set the number of standard deviations away from the mean it must be to be considered a spike.</li><li>Make a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.</li><li>Filter out anything that it determines is not a spike and return the list of ARNs to the main search. </li></ol>The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
+  "eli5": "This search and its corresponding subsearch run through the following series of steps: \n\n1. Retrieve all the AWS CloudTrail log entries that have recorded AWS API calls specifically for creating/modifying/replacing network Access Control Lists (ACLs).\n\n1. Kick off a subsearch that retrieves the same data and pulls out the ARN into a more friendly format.\n\n1. Count the number of API calls per Amazon Resource Name (ARN).\n\n1. Load the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.\n\n1. Drop the count from the latest hour, since it is not necessary, and merge the rest of the data with the results of the stats command. \n\n1. Rename `apiCalls` as `latestCount`.\n\n1. Calculate the new average value for each ARN with the latest count, weighting the past much more heavily than the current hour. They do the same for the standard deviation--weighting the past more heavily than the current.\n\n1. Update the cache file with the latest results.\n\n1. Set the minimum threshold for the number of data points and set the number of standard deviations away from the mean it must be to be considered a spike.\n\n1. Make a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.\n\n1. Filter out anything that it determines is not a spike and return the list of ARNs to the main search. The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
   "entities": [
     "user"
   ],
diff --git a/detections/clients_connecting_to_multiple_dns_servers.json b/detections/clients_connecting_to_multiple_dns_servers.json
index 2c03d63101..6be5a17920 100644
--- a/detections/clients_connecting_to_multiple_dns_servers.json
+++ b/detections/clients_connecting_to_multiple_dns_servers.json
@@ -49,7 +49,7 @@
     "dest",
     "src"
   ],
-  "how_to_implement": "This search requires that DNS data is being ingested and populating the `Network_Resolution` data model. This data can come from DNS logs or from solutions that parse network traffic for this data, such as Splunk Stream or Bro.\n\nThis search produces fields (`dest_count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** Distinct DNS Connections, **Field:** dest_count</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "This search requires that DNS data is being ingested and populating the `Network_Resolution` data model. This data can come from DNS logs or from solutions that parse network traffic for this data, such as Splunk Stream or Bro.\n\nThis search produces fields (`dest_count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** Distinct DNS Connections, **Field:** dest_count\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "74ec6f18-604b-4202-a567-86b2066be3ce",
   "investigations": [
     {
diff --git a/detections/common_ransomware_extensions.json b/detections/common_ransomware_extensions.json
index d9d3723838..405ccaf8d0 100644
--- a/detections/common_ransomware_extensions.json
+++ b/detections/common_ransomware_extensions.json
@@ -48,7 +48,7 @@
   "entities": [
     "dest"
   ],
-  "how_to_implement": "You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.\n\nThis search produces fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** Name, **Field:** Name</li><li>**Label:** File Extension, **Field:** file_extension\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "You must be ingesting data that records the filesystem activity from your hosts to populate the Endpoint file-system data model node. If you are using Sysmon, you will need a Splunk Universal Forwarder on each endpoint from which you want to collect data.\n\nThis search produces fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** Name, **Field:** Name\n\n1. \n\n1. **Label:** File Extension, **Field:** file_extension\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "a9e5c5db-db11-43ca-86a8-c852d1b2c0ec",
   "investigations": [
     {
diff --git a/detections/dns_query_length_mltk.json b/detections/dns_query_length_mltk.json
index 29fcc5f4bb..a261504489 100644
--- a/detections/dns_query_length_mltk.json
+++ b/detections/dns_query_length_mltk.json
@@ -54,7 +54,7 @@
   "entities": [
     "src"
   ],
-  "how_to_implement": "To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, the Machine Learning Toolkit (MLTK) version 4.2 or greater must be installed on your search heads, along with any required dependencies. Finally, the support search \"Baseline of DNS Query Length - MLTK\" must be executed before this detection search, because it builds a machine-learning (ML) model over the historical data used by this search. It is important that this search is run in the same app context as the associated support search, so that the model created by the support search is available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\n\nThis search produces fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** DNS Query, **Field:** query</li><li>**Label:** DNS Query Length, **Field:** query_length</li><li>**Label:** Number of events, **Field:** count</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, the Machine Learning Toolkit (MLTK) version 4.2 or greater must be installed on your search heads, along with any required dependencies. Finally, the support search \"Baseline of DNS Query Length - MLTK\" must be executed before this detection search, because it builds a machine-learning (ML) model over the historical data used by this search. It is important that this search is run in the same app context as the associated support search, so that the model created by the support search is available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\n\nThis search produces fields (`query`,`query_length`,`count`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** DNS Query, **Field:** query\n\n1. \n\n1. **Label:** DNS Query Length, **Field:** query_length\n\n1. \n\n1. **Label:** Number of events, **Field:** count\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "85fbcfe8-9718-4911-adf6-7000d077a3a9",
   "investigations": [
     {
diff --git a/detections/dyn_dns_queries.json b/detections/dyn_dns_queries.json
index 8e3a5ea7a2..052ca8db20 100644
--- a/detections/dyn_dns_queries.json
+++ b/detections/dyn_dns_queries.json
@@ -49,7 +49,7 @@
     "dest",
     "query"
   ],
-  "how_to_implement": "First, you'll need to ingest data from your DNS operations. This can be done by ingesting logs from your server or data, collected passively by Splunk Stream or a similar solution. Specifically, data that contains the domain that is being queried and the IP of the host originating the request must be populating the `Network_Resolution` data model. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating the local lookup periodically by adding new domains to the list of `dynamic_dns_providers_local.csv`.\n\nThis search produces fields (query, answer, isDynDNS) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable event. To see the additional metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** DNS Query, **Field:** query</li><li>**Label:** DNS Answer, **Field:** answer</li><li>**Label:** IsDynamicDNS, **Field:** isDynDNS</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "First, you'll need to ingest data from your DNS operations. This can be done by ingesting logs from your server or data, collected passively by Splunk Stream or a similar solution. Specifically, data that contains the domain that is being queried and the IP of the host originating the request must be populating the `Network_Resolution` data model. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating the local lookup periodically by adding new domains to the list of `dynamic_dns_providers_local.csv`.\n\nThis search produces fields (query, answer, isDynDNS) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable event. To see the additional metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** DNS Query, **Field:** query\n\n1. \n\n1. **Label:** DNS Answer, **Field:** answer\n\n1. \n\n1. **Label:** IsDynamicDNS, **Field:** isDynDNS\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "c77162d3-f93c-45cc-80c8-22f6v5464g9f",
   "investigations": [
     {
diff --git a/detections/dyn_dns_web_traffic.json b/detections/dyn_dns_web_traffic.json
index 613aa24625..3a125ffaa2 100644
--- a/detections/dyn_dns_web_traffic.json
+++ b/detections/dyn_dns_web_traffic.json
@@ -49,7 +49,7 @@
   "entities": [
     "src"
   ],
-  "how_to_implement": "This search requires you to be ingesting web-traffic logs. You can obtain these logs from indexing data from a web proxy or by using a network-traffic-analysis tool, such as Bro or Splunk Stream. The web data model must contain the URL being requested, the IP address of the host initiating the request, and the destination IP. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of dynamic DNS providers. Consider periodically updating this local lookup file with new domains.\n\nThis search produces fields (`isDynDNS`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** IsDynamicDNS, **Field:** isDynDNS</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "This search requires you to be ingesting web-traffic logs. You can obtain these logs from indexing data from a web proxy or by using a network-traffic-analysis tool, such as Bro or Splunk Stream. The web data model must contain the URL being requested, the IP address of the host initiating the request, and the destination IP. This search also leverages a lookup file, `dynamic_dns_providers_default.csv`, which contains a non-exhaustive list of dynamic DNS providers. Consider periodically updating this local lookup file with new domains.\n\nThis search produces fields (`isDynDNS`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** IsDynamicDNS, **Field:** isDynDNS\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "134da869-e264-4a8f-8d7e-fcd01c18f301",
   "investigations": [
     {
diff --git a/detections/local_admin_account_creation.json b/detections/local_admin_account_creation.json
index 1e857827d7..3c7a60795e 100644
--- a/detections/local_admin_account_creation.json
+++ b/detections/local_admin_account_creation.json
@@ -46,7 +46,7 @@
   "entities": [
     "user"
   ],
-  "how_to_implement": "You must be ingesting Windows Security logs. You must also enable the account change auditing here:http://docs.splunk.com/Documentation/Splunk/7.0.2/Data/MonitorWindowseventlogdata. Additionally, this search requires you to enable your Group Management Audit Logs in your Local Windows Security Policy and to be ingesting those logs.  More information on how to enable them can be found here: http://whatevernetworks.com/auditing-group-membership-changes-in-active-directory/. Finally, please make sure that the local administrator group name is \"Administrators\" to be able to look for the right group membership changes.\n\nThis search produces fields (`Security_ID`,`Group_Name`,`Message`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** Security ID, **Field:** Security_ID</li><li>**Label:** Group Name, **Field:** Group_Name</li><li>**Label:** Message, **Field:** Message</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "You must be ingesting Windows Security logs. You must also enable the account change auditing here:http://docs.splunk.com/Documentation/Splunk/7.0.2/Data/MonitorWindowseventlogdata. Additionally, this search requires you to enable your Group Management Audit Logs in your Local Windows Security Policy and to be ingesting those logs.  More information on how to enable them can be found here: http://whatevernetworks.com/auditing-group-membership-changes-in-active-directory/. Finally, please make sure that the local administrator group name is \"Administrators\" to be able to look for the right group membership changes.\n\nThis search produces fields (`Security_ID`,`Group_Name`,`Message`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** Security ID, **Field:** Security_ID\n\n1. \n\n1. **Label:** Group Name, **Field:** Group_Name\n\n1. \n\n1. **Label:** Message, **Field:** Message\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "b25f6f62-0712-43c1-b203-083231ffd97d",
   "investigations": [
     {
diff --git a/detections/smb_traffic_spike_mltk.json b/detections/smb_traffic_spike_mltk.json
index ec249ef4c7..44c8f53267 100644
--- a/detections/smb_traffic_spike_mltk.json
+++ b/detections/smb_traffic_spike_mltk.json
@@ -54,7 +54,7 @@
   "entities": [
     "src"
   ],
-  "how_to_implement": "To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, the Machine Learning Toolkit (MLTK) version 4.2 or greater must be installed on your search heads, along with any required dependencies. Finally, the support search \"Baseline of SMB Traffic - MLTK\" must be executed before this detection search, because it builds a machine-learning (ML) model over the historical data used by this search. It is important that this search is run in the same app context as the associated support search, so that the model created by the support search is available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\n\nThis search produces a field (Number of events,count) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. This field contributes additional context to the notable. To see the additional metadata, add the following field, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry): **Label:** Number of events, **Field:** count\n\nDetailed documentation on how to create a new field within Incident Review is found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "To successfully implement this search, you will need to ensure that DNS data is populating the Network_Resolution data model. In addition, the Machine Learning Toolkit (MLTK) version 4.2 or greater must be installed on your search heads, along with any required dependencies. Finally, the support search \"Baseline of SMB Traffic - MLTK\" must be executed before this detection search, because it builds a machine-learning (ML) model over the historical data used by this search. It is important that this search is run in the same app context as the associated support search, so that the model created by the support search is available for use. You should periodically re-run the support search to rebuild the model with the latest data available in your environment.\n\nThis search produces a field (Number of events,count) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. This field contributes additional context to the notable. To see the additional metadata, add the following field, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry): \n\n1. **Label:** Number of events, **Field:** count\n\nDetailed documentation on how to create a new field within Incident Review is found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "d25773ba-9ad8-48d1-858e-07ad0bbeb828",
   "investigations": [
     {
diff --git a/detections/spike_aws_api_call_per_account.json b/detections/spike_aws_api_call_per_account.json
index 335f596bbc..de6d956e11 100644
--- a/detections/spike_aws_api_call_per_account.json
+++ b/detections/spike_aws_api_call_per_account.json
@@ -49,11 +49,11 @@
       }
     }
   },
-  "eli5": "This search and its corresponding subsearch run through a series of steps, as per the following: \n\n1. Retrieves all the AWS CloudTrail log entries that have recorded AWS API calls.</li><li>Kicks off a subsearch that retrieves the same data and pulls out the ARN into a more friendly format.</li><li>Counts the number of API calls per ARN.</li><li>Loads the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.</li><li>Drops the count from the latest hour, since it is not necessary, and merges the rest of the data with the results of the stats command. </li><li>Renames `apiCalls` as `latestCount`.</li><li>Calculates the new average value for each ARN with the latest count, weighting the past much more heavily than the current hour. It does the same for the standard deviation--weighting the past more heavily than the current.</li><li>Updates the cache file with the latest results.</li><li>Sets the minimum threshold for the number of data points and sets the number of standard deviations away from the mean it must be to be considered a spike.</li><li>Makes a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.</li><li>Filters out anything that it determines is not a spike and returns the list of ARNs to the main search. </li></ol>The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
+  "eli5": "This search and its corresponding subsearch run through a series of steps, as per the following: \n\n1. Retrieves all the AWS CloudTrail log entries that have recorded AWS API calls.\n\n1. Kicks off a subsearch that retrieves the same data and pulls out the ARN into a more friendly format.\n\n1. Counts the number of API calls per ARN.\n\n1. Loads the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.\n\n1. Drops the count from the latest hour, since it is not necessary, and merges the rest of the data with the results of the stats command. \n\n1. Renames `apiCalls` as `latestCount`.\n\n1. Calculates the new average value for each ARN with the latest count, weighting the past much more heavily than the current hour. It does the same for the standard deviation--weighting the past more heavily than the current.\n\n1. Updates the cache file with the latest results.\n\n1. Sets the minimum threshold for the number of data points and sets the number of standard deviations away from the mean it must be to be considered a spike.\n\n1. Makes a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.\n\n1. Filters out anything that it determines is not a spike and returns the list of ARNs to the main search. The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
   "entities": [
     "user"
   ],
-  "how_to_implement": "You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike.\n\nThis search produces fields (`eventName`,`numberOfApiCalls`,`uniqueApisCalled`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** AWS Event Name, **Field:** eventName</li><li>**Label:** Number of API Calls, **Field:** numberOfApiCalls</li><li>**Label:** Unique API Calls, **Field:** uniqueApisCalled</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. You can modify `dataPointThreshold` and `deviationThreshold` to better fit your environment. The `dataPointThreshold` variable is the minimum number of data points required to have a statistically significant amount of data to determine. The `deviationThreshold` variable is the number of standard deviations away from the mean that the value must be to be considered a spike.\n\nThis search produces fields (`eventName`,`numberOfApiCalls`,`uniqueApisCalled`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** AWS Event Name, **Field:** eventName\n\n1. \n\n1. **Label:** Number of API Calls, **Field:** numberOfApiCalls\n\n1. \n\n1. **Label:** Unique API Calls, **Field:** uniqueApisCalled\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "ada0f478-84a8-4641-a3f1-d32362d4bd55",
   "investigations": [
     {
diff --git a/detections/spike_aws_security_group_activity.json b/detections/spike_aws_security_group_activity.json
index 522336e6a5..2fbb23ecb4 100644
--- a/detections/spike_aws_security_group_activity.json
+++ b/detections/spike_aws_security_group_activity.json
@@ -49,7 +49,7 @@
       }
     }
   },
-  "eli5": "This search and its corresponding subsearch run through the following series of steps: \n\n1. Retrieves all the AWS CloudTrail log entries that have recorded AWS API calls specifically for security groups.</li><li>Kicks off a subsearch that retrieves the same data and pulls out the ARN into a more friendly format.</li><li>Counts the number of API calls per ARN.</li><li>Loads the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.</li><li>Drops the count from the latest hour, since it is not necessary, and merges the rest of the data with the results of the stats command. </li><li>Renames `apiCalls` as `latestCount`.</li><li>Calculates the new average value for each ARN with the latest count, weighting the past much more heavily than the current hour. It does the same for the standard deviation--weighting the past more heavily than the current.</li><li>Updates the cache file with the latest results.</li><li>Sets the minimum threshold for the number of data points and sets the number of standard deviations away from the mean it must be to be considered a spike.</li><li>Makes a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.</li><li>Filters out anything that it determines is not a spike and returns the list of ARNs to the main search. </li></ol>The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
+  "eli5": "This search and its corresponding subsearch run through the following series of steps: \n\n1. Retrieves all the AWS CloudTrail log entries that have recorded AWS API calls specifically for security groups.\n\n1. Kicks off a subsearch that retrieves the same data and pulls out the ARN into a more friendly format.\n\n1. Counts the number of API calls per ARN.\n\n1. Loads the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.\n\n1. Drops the count from the latest hour, since it is not necessary, and merges the rest of the data with the results of the stats command. \n\n1. Renames `apiCalls` as `latestCount`.\n\n1. Calculates the new average value for each ARN with the latest count, weighting the past much more heavily than the current hour. It does the same for the standard deviation--weighting the past more heavily than the current.\n\n1. Updates the cache file with the latest results.\n\n1. Sets the minimum threshold for the number of data points and sets the number of standard deviations away from the mean it must be to be considered a spike.\n\n1. Makes a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.\n\n1. Filters out anything that it determines is not a spike and returns the list of ARNs to the main search. The main search subsequently gets the names of all the API calls, the number of unique API calls, and the total number of API calls for each of these ARNs. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
   "entities": [
     "user"
   ],
diff --git a/detections/spike_s3_deletion.json b/detections/spike_s3_deletion.json
index be7dada673..2bbd4ba9cc 100644
--- a/detections/spike_s3_deletion.json
+++ b/detections/spike_s3_deletion.json
@@ -49,7 +49,7 @@
       }
     }
   },
-  "eli5": "This search and its corresponding subsearch run through the following series of steps: \n\n1. Retrieve all the AWS CloudTrail log entries that have recorded AWS API calls specifically for deletion of S3 buckets.</li><li>Kick off a subsearch that retrieves the same data and pulls out and converts the ARN into a more friendly format.</li><li>Count the number of API calls per ARN.</li><li>Load the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.</li><li>Drop the count from the latest hour, since it is unnecessary, and merge the rest of the data with the results of the `stats` command. </li><li>Rename `apiCalls` as `latestCount`.</li><li>Calculate the new average value for each ARN with the latest count, weighting the past more heavily than the current hour. It does the same for the standard deviation&#151;weighting the past more heavily than the current.</li><li>Update the cache file with the latest results.</li><li>Set the minimum threshold for the number of data points and the number of standard deviations away from the mean it must be to be considered a spike.</li><li>Make a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and if the count is a sufficient number of standard deviations away from the average.</li><li>Filter out anything that it determines is not a spike and returns the list of ARNs to the main search. </li></ol>The main search subsequently gets the names of the deleted S3 buckets, the number of unique API calls, and the total number of API calls for each of these user ARNs.",
+  "eli5": "This search and its corresponding subsearch run through the following series of steps: \n\n1. Retrieve all the AWS CloudTrail log entries that have recorded AWS API calls specifically for deletion of S3 buckets.\n\n1. Kick off a subsearch that retrieves the same data and pulls out and converts the ARN into a more friendly format.\n\n1. Count the number of API calls per ARN.\n\n1. Load the cache file that contains the number of data points, the count from the latest hour, the API call average, and the standard deviation for each ARN.\n\n1. Drop the count from the latest hour, since it is unnecessary, and merge the rest of the data with the results of the `stats` command. \n\n1. Rename `apiCalls` as `latestCount`.\n\n1. Calculate the new average value for each ARN with the latest count, weighting the past more heavily than the current hour. It does the same for the standard deviation&#151;weighting the past more heavily than the current.\n\n1. Update the cache file with the latest results.\n\n1. Set the minimum threshold for the number of data points and the number of standard deviations away from the mean it must be to be considered a spike.\n\n1. Make a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and if the count is a sufficient number of standard deviations away from the average.\n\n1. Filter out anything that it determines is not a spike and returns the list of ARNs to the main search. The main search subsequently gets the names of the deleted S3 buckets, the number of unique API calls, and the total number of API calls for each of these user ARNs.",
   "entities": [
     "user"
   ],
diff --git a/detections/spike_vpc_blocked_traffic.json b/detections/spike_vpc_blocked_traffic.json
index 66a82fbd2a..cab42e18ae 100644
--- a/detections/spike_vpc_blocked_traffic.json
+++ b/detections/spike_vpc_blocked_traffic.json
@@ -49,7 +49,7 @@
       }
     }
   },
-  "eli5": "This search retrieves all the VPC Flow log entries that have recorded a blocked outbound network connection originating from your AWS environment. Then it kicks off a subsearch, which looks at the same data and performs the following series of steps: \n\n1. Counts the number of blocked outbound connections by each source IP</li><li>Loads the cache file that contains the number of data points, the count from the latest hour, the average blocked connections, and the standard deviation for each source IP.</li><li>Drops the count from the latest hour, since it is not necessary, and merges the rest of the data with the results of the stats command. </li><li>Renames `numberOfBlockedConnections` as `latestCount`.</li><li>Calculates the new average value for each source IP with the latest count, weighting the past much more heavily than the current hour. It does the same for the standard deviation, weighting the past more heavily than the current.</li><li>Updates the cache file with the latest results.</li><li>Sets the minimum threshold for the number of data points and sets the number of standard deviations away from the mean it must be to be considered a spike.</li><li>Makes a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.</li><li>Filters out anything that it determines is not a spike and returns the list of source IPs to the main search. </li></ol>The main search subsequently gets the list of all destination IPs for which the traffic was blocked, the network interface ID, the number of unique destination IP, and the total number of blocked connections for each of these source IP addresses. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
+  "eli5": "This search retrieves all the VPC Flow log entries that have recorded a blocked outbound network connection originating from your AWS environment. Then it kicks off a subsearch, which looks at the same data and performs the following series of steps: \n\n1. Counts the number of blocked outbound connections by each source IP\n\n1. Loads the cache file that contains the number of data points, the count from the latest hour, the average blocked connections, and the standard deviation for each source IP.\n\n1. Drops the count from the latest hour, since it is not necessary, and merges the rest of the data with the results of the stats command. \n\n1. Renames `numberOfBlockedConnections` as `latestCount`.\n\n1. Calculates the new average value for each source IP with the latest count, weighting the past much more heavily than the current hour. It does the same for the standard deviation, weighting the past more heavily than the current.\n\n1. Updates the cache file with the latest results.\n\n1. Sets the minimum threshold for the number of data points and sets the number of standard deviations away from the mean it must be to be considered a spike.\n\n1. Makes a determination regarding whether or not the current count is a spike by checking to see if the minimum data-point threshold has been met and the count is a sufficient number of standard deviations away from the average.\n\n1. Filters out anything that it determines is not a spike and returns the list of source IPs to the main search. The main search subsequently gets the list of all destination IPs for which the traffic was blocked, the network interface ID, the number of unique destination IP, and the total number of blocked connections for each of these source IP addresses. Finally, it looks up the average and standard deviation and returns both the average and the number of standard deviations the spike is from the average.",
   "entities": [
     "src_ip"
   ],
diff --git a/detections/users_without_mfa.json b/detections/users_without_mfa.json
index 5240ec1175..e2dbba7414 100644
--- a/detections/users_without_mfa.json
+++ b/detections/users_without_mfa.json
@@ -46,7 +46,7 @@
   "entities": [
     "user"
   ],
-  "how_to_implement": "You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. Leverage the support search `Create a list of approved AWS service accounts`: run it once every 30 days to create a list of service accounts and validate them.\n\nThis search produces fields (`eventName`,`userIdentity.type`,`userIdentity.arn`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n<ul><li>**Label:** AWS Event Name, **Field:** eventName</li><li>**Label:** AWS User ARN, **Field:** userIdentity.arn</li><li>**Label:** AWS User Type, **Field:** userIdentity.type</li></ul>\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
+  "how_to_implement": "You must install the AWS App for Splunk (version 5.1.0 or later) and Splunk Add-on for AWS (version 4.4.0 or later), then configure your CloudTrail inputs. Leverage the support search `Create a list of approved AWS service accounts`: run it once every 30 days to create a list of service accounts and validate them.\n\nThis search produces fields (`eventName`,`userIdentity.type`,`userIdentity.arn`) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable. To see the additional metadata, add the following fields, if not already present, to Incident Review - Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n\n\n\n1. **Label:** AWS Event Name, **Field:** eventName\n\n1. \n\n1. **Label:** AWS User ARN, **Field:** userIdentity.arn\n\n1. \n\n1. **Label:** AWS User Type, **Field:** userIdentity.type\n\nDetailed documentation on how to create a new field within Incident Review may be found here: `https://docs.splunk.com/Documentation/ES/5.3.0/Admin/Customizenotables#Add_a_field_to_the_notable_event_details`",
   "id": "2a9b80d3-6340-4345-w5ad-212bf5d1dac4",
   "investigations": [
     {
diff --git a/stories/dns_hijacking.json b/stories/dns_hijacking.json
index 830f00f5ae..2f737c5fdb 100644
--- a/stories/dns_hijacking.json
+++ b/stories/dns_hijacking.json
@@ -37,7 +37,7 @@
   ],
   "modification_date": "2018-09-06",
   "name": "DNS Hijacking",
-  "narrative": "Dubbed the Achilles heel of the Internet (see https://www.f5.com/labs/articles/threat-intelligence/dns-is-still-the-achilles-heel-of-the-internet-25613), DNS plays a critical role in routing web traffic but is notoriously vulnerable to attack. One reason is its distributed nature. It relies on unstructured connections between millions of clients and servers over inherently insecure protocols.\n\nThe gravity and extent of the importance of securing DNS from attacks is undeniable. The fallout of compromised DNS can be disastrous. Not only can hackers bring down an entire business, they can intercept confidential information, emails, and login credentials, as well. \n\nOn January 22, 2019, the US Department of Homeland Security 2019's Cybersecurity and Infrastructure Security Agency (CISA) raised awareness of some high-profile DNS hijacking attacks against infrastructure, both in the United States and abroad. It issued Emergency Directive 19-01 (see https://cyber.dhs.gov/ed/19-01/), which summarized the activity and required government agencies to take the following four actions, all within 10 days: <ol><li>For all .gov or other agency-managed domains, audit public DNS records on all authoritative and secondary DNS servers, verify that they resolve to the intended location or report them to CISA.</li><li>Update the passwords for all accounts on systems that can make changes to each agency 2019's DNS records.</li><li>Implement multi-factor authentication (MFA) for all accounts on systems that can make changes to each agency's 2019 DNS records or, if impossible, provide CISA with the names of systems, the reasons why MFA cannot be enabled within the required timeline, and an ETA for when it can be enabled.</li><li>CISA will begin regular delivery of newly added certificates to Certificate Transparency (CT) logs for agency domains via the Cyber Hygiene service. Upon receipt, agencies must immediately begin monitoring CT log data for certificates issued that they did not request. If an agency confirms that a certificate was unauthorized, it must report the certificate to the issuing certificate authority and to CISA.</li></ol>Of course, it makes sense to put equivalent actions in place within your environment, as well. \n\nIn DNS hijacking, the attacker assumes control over an account or makes use of a DNS service exploit to make changes to DNS records. Once they gain access, attackers can substitute their own MX records, name-server records, and addresses, redirecting emails and traffic through their infrastructure, where they can read, copy, or modify information seen. They can also generate valid encryption certificates to help them avoid browser-certificate checks. In one notable attack on the Internet service provider, GoDaddy, the hackers altered Sender Policy Framework (SPF) records a relatively minor change that did not inflict excessive damage but allowed for more effective spam campaigns.\n\nThe searches in this Analytic Story help you detect and investigate activities that may indicate that DNS hijacking has taken place within your environment.",
+  "narrative": "Dubbed the Achilles heel of the Internet (see https://www.f5.com/labs/articles/threat-intelligence/dns-is-still-the-achilles-heel-of-the-internet-25613), DNS plays a critical role in routing web traffic but is notoriously vulnerable to attack. One reason is its distributed nature. It relies on unstructured connections between millions of clients and servers over inherently insecure protocols.\n\nThe gravity and extent of the importance of securing DNS from attacks is undeniable. The fallout of compromised DNS can be disastrous. Not only can hackers bring down an entire business, they can intercept confidential information, emails, and login credentials, as well. \n\nOn January 22, 2019, the US Department of Homeland Security 2019's Cybersecurity and Infrastructure Security Agency (CISA) raised awareness of some high-profile DNS hijacking attacks against infrastructure, both in the United States and abroad. It issued Emergency Directive 19-01 (see https://cyber.dhs.gov/ed/19-01/), which summarized the activity and required government agencies to take the following four actions, all within 10 days: \n\n1. For all .gov or other agency-managed domains, audit public DNS records on all authoritative and secondary DNS servers, verify that they resolve to the intended location or report them to CISA.\n\n1. Update the passwords for all accounts on systems that can make changes to each agency 2019's DNS records.\n\n1. Implement multi-factor authentication (MFA) for all accounts on systems that can make changes to each agency's 2019 DNS records or, if impossible, provide CISA with the names of systems, the reasons why MFA cannot be enabled within the required timeline, and an ETA for when it can be enabled.\n\n1. CISA will begin regular delivery of newly added certificates to Certificate Transparency (CT) logs for agency domains via the Cyber Hygiene service. Upon receipt, agencies must immediately begin monitoring CT log data for certificates issued that they did not request. If an agency confirms that a certificate was unauthorized, it must report the certificate to the issuing certificate authority and to CISA. Of course, it makes sense to put equivalent actions in place within your environment, as well. \n\nIn DNS hijacking, the attacker assumes control over an account or makes use of a DNS service exploit to make changes to DNS records. Once they gain access, attackers can substitute their own MX records, name-server records, and addresses, redirecting emails and traffic through their infrastructure, where they can read, copy, or modify information seen. They can also generate valid encryption certificates to help them avoid browser-certificate checks. In one notable attack on the Internet service provider, GoDaddy, the hackers altered Sender Policy Framework (SPF) records a relatively minor change that did not inflict excessive damage but allowed for more effective spam campaigns.\n\nThe searches in this Analytic Story help you detect and investigate activities that may indicate that DNS hijacking has taken place within your environment.",
   "original_authors": [
     {
       "company": "Splunk",
diff --git a/stories/jboss_vulnerabilities.json b/stories/jboss_vulnerabilities.json
index 481ec47c78..b376471bd2 100644
--- a/stories/jboss_vulnerabilities.json
+++ b/stories/jboss_vulnerabilities.json
@@ -27,7 +27,7 @@
   ],
   "modification_date": "2017-09-14",
   "name": "JBoss Vulnerability",
-  "narrative": "This Analytic Story looks for probing and exploitation attempts targeting JBoss application servers. While the vulnerabilities associated with this story are rather dated, they were leveraged in a spring 2016 campaign in connection with the Samsam ransomware variant. Incidents involving this ransomware are unique, in that they begin with attacks against vulnerable services, rather than the phishing or drive-by attacks more common with ransomware. In this case, vulnerable JBoss applications appear to be the target of choice.\n\nIt is helpful to understand how often a notable event generated by this story occurs, as well as the commonalities between some of these events, both of which may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. It may also help to understand whether the issue is restricted to a single user/system or whether it is broader in scope.\n\nWhen looking at the target of the behavior uncovered by the event, you should note the sensitivity of the user and or/system to help determine the potential impact. It is also helpful to identify other recent events involving the target. This can help tie different events together and give further situational awareness regarding the target host.\n\nVarious types of information for external systems should be reviewed and, potentially, collected if the incident is, indeed, judged to be malicious. This data may be useful for generating your own threat intelligence, so you can create future alerts.\n\nThe following factors may assist you in determining whether the event is malicious: <ul><li>Country of origin</li><li>Responsible party</li><li>Fully qualified domain names associated with the external IP address</li><li>Registration of fully qualified domain names associated with external IP address</li></ul> Determining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you qualify and understand the event and possible motivation for the attack. In addition, there are various sources that may provide reputation information on the IP address or domain name, which can assist you in determining whether the event is malicious in nature. Finally, determining whether there are other events associated with the IP address may help connect data points or expose other historic events that might be brought back into scope.\n\nGathering various data on the system of interest can sometimes help quickly determine whether something suspicious is happening. Some of these items include determining who else may have logged into the system recently, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and/or whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.\n\nWhen a specific service or application is targeted, it is often helpful to know the associated version, to help determine whether it is vulnerable to a specific exploit.\n\nIf you suspect an attack targeting a web server, it is helpful to look at some of the behavior of the web service to see if there is evidence that the service has been compromised. Some indications of this might be network connections to external resources, the web service spawning child processes that are not associated with typical behavior, and whether the service wrote any files that might be malicious in nature.\n\nIf a suspicious file is found, we can review more information about it to help determine if it is, in fact, malicious. Identifying the file type, any processes that opened the file, the processes that may have created and/or modified the file, and how many other systems potentially have this file can you determine whether the file is malicious. Also, determining the file hash and checking it against reputation sources, such as VirusTotal, can sometimes help you quickly determine if it is malicious in nature.\n\nOften, a simple inspection of a suspect process name and path can tell you if the system has been compromised. For example, if svchost.exe is found running from a location other than `C:\\Windows\\System32`, it is likely something malicious designed to hide in plain sight when simply reviewing process names. \n\nIt can also be helpful to examine various behaviors of and the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see whether the parent process spawned other processes that might also warrant further scrutiny. If a process is suspect, a review of the network connections made around the time of the event and noting whether the process has spawned any child processes could be helpful in determining whether it is malicious or executing a malicious script.",
+  "narrative": "This Analytic Story looks for probing and exploitation attempts targeting JBoss application servers. While the vulnerabilities associated with this story are rather dated, they were leveraged in a spring 2016 campaign in connection with the Samsam ransomware variant. Incidents involving this ransomware are unique, in that they begin with attacks against vulnerable services, rather than the phishing or drive-by attacks more common with ransomware. In this case, vulnerable JBoss applications appear to be the target of choice.\n\nIt is helpful to understand how often a notable event generated by this story occurs, as well as the commonalities between some of these events, both of which may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. It may also help to understand whether the issue is restricted to a single user/system or whether it is broader in scope.\n\nWhen looking at the target of the behavior uncovered by the event, you should note the sensitivity of the user and or/system to help determine the potential impact. It is also helpful to identify other recent events involving the target. This can help tie different events together and give further situational awareness regarding the target host.\n\nVarious types of information for external systems should be reviewed and, potentially, collected if the incident is, indeed, judged to be malicious. This data may be useful for generating your own threat intelligence, so you can create future alerts.\n\nThe following factors may assist you in determining whether the event is malicious: \n\n1. Country of origin\n\n1. Responsible party\n\n1. Fully qualified domain names associated with the external IP address\n\n1. Registration of fully qualified domain names associated with external IP address Determining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you qualify and understand the event and possible motivation for the attack. In addition, there are various sources that may provide reputation information on the IP address or domain name, which can assist you in determining whether the event is malicious in nature. Finally, determining whether there are other events associated with the IP address may help connect data points or expose other historic events that might be brought back into scope.\n\nGathering various data on the system of interest can sometimes help quickly determine whether something suspicious is happening. Some of these items include determining who else may have logged into the system recently, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and/or whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.\n\nWhen a specific service or application is targeted, it is often helpful to know the associated version, to help determine whether it is vulnerable to a specific exploit.\n\nIf you suspect an attack targeting a web server, it is helpful to look at some of the behavior of the web service to see if there is evidence that the service has been compromised. Some indications of this might be network connections to external resources, the web service spawning child processes that are not associated with typical behavior, and whether the service wrote any files that might be malicious in nature.\n\nIf a suspicious file is found, we can review more information about it to help determine if it is, in fact, malicious. Identifying the file type, any processes that opened the file, the processes that may have created and/or modified the file, and how many other systems potentially have this file can you determine whether the file is malicious. Also, determining the file hash and checking it against reputation sources, such as VirusTotal, can sometimes help you quickly determine if it is malicious in nature.\n\nOften, a simple inspection of a suspect process name and path can tell you if the system has been compromised. For example, if svchost.exe is found running from a location other than `C:\\Windows\\System32`, it is likely something malicious designed to hide in plain sight when simply reviewing process names. \n\nIt can also be helpful to examine various behaviors of and the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see whether the parent process spawned other processes that might also warrant further scrutiny. If a process is suspect, a review of the network connections made around the time of the event and noting whether the process has spawned any child processes could be helpful in determining whether it is malicious or executing a malicious script.",
   "original_authors": [
     {
       "company": "Splunk",
diff --git a/stories/malicious_powershell.json b/stories/malicious_powershell.json
index c2ef152530..5d0994af24 100644
--- a/stories/malicious_powershell.json
+++ b/stories/malicious_powershell.json
@@ -42,7 +42,7 @@
   ],
   "modification_date": "2017-08-23",
   "name": "Malicious PowerShell",
-  "narrative": "The searches in this Analytic Story monitor for parameters often used for malicious purposes. It is helpful to understand how often the notable events generated by this story occur, as well as the commonalities between some of these events. These factors may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. Likewise, it is important to determine whether the issue is restricted to a single user/system or is broader in scope.\nThe following factors may assist you in determining whether the event is malicious: <ul><li>Country of origin</li><li>Responsible party</li><li>Fully qualified domain names associated with the external IP address</li><li>Registration of fully qualified domain names associated with external IP address</li></ul>Determining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you answer some questions surrounding the attacker and details related to the external system. In addition, there are various sources--such as VirusTotal&#151; that can provide some reputation information on the IP address or domain name, which can assist in determining whether the event is malicious. Finally, determining whether there are other events associated with the IP address may help connect data points or show other events that should be brought into scope.\nGathering data on the system of interest can sometimes help you quickly determine whether something suspicious is happening. Some of these items include finding out who else may have recently logged into the system, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.\nOften, a simple inspection of the process name and path can tell you if the system has been compromised. For example, if `svchost.exe` is found running from a location other than `C:\\Windows\\System32`, it is likely something malicious designed to hide in plain sight when cursorily reviewing process names. Similarly, if the process itself seems legitimate, but the parent process is running from the temporary browser cache, that could be indicative of activity initiated via a compromised website a user visited.\nIt can also be very helpful to examine various behaviors of the process of interest or the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see if the parent to that process spawned other processes that might be worth further scrutiny. If a process is suspect, a review of the network connections made in and around the time of the event and/or whether the process spawned any child processes could be helpful, as well.\nIn the event a system is suspected of having been compromised via a malicious website, we suggest reviewing the browsing activity from that system around the time of the event. If categories are given for the URLs visited, that can help you zero in on possible malicious sites.",
+  "narrative": "The searches in this Analytic Story monitor for parameters often used for malicious purposes. It is helpful to understand how often the notable events generated by this story occur, as well as the commonalities between some of these events. These factors may provide clues about whether this is a common occurrence of minimal concern or a rare event that may require more extensive investigation. Likewise, it is important to determine whether the issue is restricted to a single user/system or is broader in scope.\nThe following factors may assist you in determining whether the event is malicious: \n\n1. Country of origin\n\n1. Responsible party\n\n1. Fully qualified domain names associated with the external IP address\n\n1. Registration of fully qualified domain names associated with external IP addressDetermining whether it is a dynamic domain frequently visited by others and/or how third parties categorize it can also help you answer some questions surrounding the attacker and details related to the external system. In addition, there are various sources--such as VirusTotal&#151; that can provide some reputation information on the IP address or domain name, which can assist in determining whether the event is malicious. Finally, determining whether there are other events associated with the IP address may help connect data points or show other events that should be brought into scope.\nGathering data on the system of interest can sometimes help you quickly determine whether something suspicious is happening. Some of these items include finding out who else may have recently logged into the system, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.\nOften, a simple inspection of the process name and path can tell you if the system has been compromised. For example, if `svchost.exe` is found running from a location other than `C:\\Windows\\System32`, it is likely something malicious designed to hide in plain sight when cursorily reviewing process names. Similarly, if the process itself seems legitimate, but the parent process is running from the temporary browser cache, that could be indicative of activity initiated via a compromised website a user visited.\nIt can also be very helpful to examine various behaviors of the process of interest or the parent of the process of interest. For example, if it turns out the process of interest is malicious, it would be good to see if the parent to that process spawned other processes that might be worth further scrutiny. If a process is suspect, a review of the network connections made in and around the time of the event and/or whether the process spawned any child processes could be helpful, as well.\nIn the event a system is suspected of having been compromised via a malicious website, we suggest reviewing the browsing activity from that system around the time of the event. If categories are given for the URLs visited, that can help you zero in on possible malicious sites.",
   "original_authors": [
     {
       "company": "Splunk",
diff --git a/stories/mudcarp.json b/stories/mudcarp.json
index 42fd8a57ea..f099326dc2 100644
--- a/stories/mudcarp.json
+++ b/stories/mudcarp.json
@@ -42,7 +42,7 @@
   ],
   "modification_date": "2018-07-24",
   "name": "Possible Backdoor Activity Associated With MUDCARP Espionage Campaigns",
-  "narrative": "This story was created as a joint effort between iDefense and Splunk.\n\niDefense analysts have recently discovered a Windows executable file that, upon execution, spoofs a decryption tool and then drops a file that appears to be the custom-built javascript backdoor, \"Orz,\" which is associated with the threat actors known as MUDCARP (as well as \"temp.Periscope\" and \"Leviathan\"). The file is executed using Wscript.\n\nThe MUDCARP techniques include the use of the compressed-folders module from Microsoft, zipfldr.dll, with RouteTheCall export to run the malicious process or command. After a successful reboot, the malware is made persistent by a manipulating `[HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run]'help'='c:\\\\windows\\\\system32\\\\rundll32.exe c:\\\\windows\\\\system32\\\\zipfldr.dll,RouteTheCall c:\\\\programdata\\\\winapp.exe'`. Though this technique is not exclusive to MUDCARP, it has been spotted in the group's arsenal of advanced techniques seen in the wild.\n\nThis Analytic Story searches for evidence of tactics, techniques, and procedures (TTPs) that allow for the use of a endpoint detection-and-response (EDR) bypass technique to mask the true parent of a malicious process. It can also be set as a registry key for further sandbox evasion and to allow the malware to launch only after reboot.\n\nIf behavioral searches included in this story yield positive hits, iDefense recommends conducting IOC searches for the following:\n\n<ul><li>www.chemscalere[.]com</li><li>chemscalere[.]com</li><li>about.chemscalere[.]com</li><li>autoconfig.chemscalere[.]com</li><li>autodiscover.chemscalere[.]com</li><li>catalog.chemscalere[.]com</li><li>cpanel.chemscalere[.]com</li><li>db.chemscalere[.]com</li><li>ftp.chemscalere[.]com</li><li>mail.chemscalere[.]com</li><li>news.chemscalere[.]com</li><li>update.chemscalere[.]com</li><li>webmail.chemscalere[.]com</li><li>www.candlelightparty[.]org</li><li>candlelightparty[.]org</li><li>newapp.freshasianews[.]com</li></ul>In addition, iDefense also recommends that organizations review their environments for activity related to the following hashes:\n\n<ul><li>cd195ee448a3657b5c2c2d13e9c7a2e2</li><li>b43ad826fe6928245d3c02b648296b43</li><li>889a9b52566448231f112a5ce9b5dfaf</li><li>b8ec65dab97cdef3cd256cc4753f0c54</li><li>04d83cd3813698de28cfbba326d7647c</li></ul>",
+  "narrative": "This story was created as a joint effort between iDefense and Splunk.\n\niDefense analysts have recently discovered a Windows executable file that, upon execution, spoofs a decryption tool and then drops a file that appears to be the custom-built javascript backdoor, \"Orz,\" which is associated with the threat actors known as MUDCARP (as well as \"temp.Periscope\" and \"Leviathan\"). The file is executed using Wscript.\n\nThe MUDCARP techniques include the use of the compressed-folders module from Microsoft, zipfldr.dll, with RouteTheCall export to run the malicious process or command. After a successful reboot, the malware is made persistent by a manipulating `[HKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run]'help'='c:\\\\windows\\\\system32\\\\rundll32.exe c:\\\\windows\\\\system32\\\\zipfldr.dll,RouteTheCall c:\\\\programdata\\\\winapp.exe'`. Though this technique is not exclusive to MUDCARP, it has been spotted in the group's arsenal of advanced techniques seen in the wild.\n\nThis Analytic Story searches for evidence of tactics, techniques, and procedures (TTPs) that allow for the use of a endpoint detection-and-response (EDR) bypass technique to mask the true parent of a malicious process. It can also be set as a registry key for further sandbox evasion and to allow the malware to launch only after reboot.\n\nIf behavioral searches included in this story yield positive hits, iDefense recommends conducting IOC searches for the following:\n\n\n\n1. www.chemscalere[.]com\n\n1. chemscalere[.]com\n\n1. about.chemscalere[.]com\n\n1. autoconfig.chemscalere[.]com\n\n1. autodiscover.chemscalere[.]com\n\n1. catalog.chemscalere[.]com\n\n1. cpanel.chemscalere[.]com\n\n1. db.chemscalere[.]com\n\n1. ftp.chemscalere[.]com\n\n1. mail.chemscalere[.]com\n\n1. news.chemscalere[.]com\n\n1. update.chemscalere[.]com\n\n1. webmail.chemscalere[.]com\n\n1. www.candlelightparty[.]org\n\n1. candlelightparty[.]org\n\n1. newapp.freshasianews[.]comIn addition, iDefense also recommends that organizations review their environments for activity related to the following hashes:\n\n\n\n1. cd195ee448a3657b5c2c2d13e9c7a2e2\n\n1. b43ad826fe6928245d3c02b648296b43\n\n1. 889a9b52566448231f112a5ce9b5dfaf\n\n1. b8ec65dab97cdef3cd256cc4753f0c54\n\n1. 04d83cd3813698de28cfbba326d7647c",
   "original_authors": [
     {
       "company": "iDefense",
diff --git a/stories/phishing_payloads.json b/stories/phishing_payloads.json
index f567d0074f..9ea5b15aa1 100644
--- a/stories/phishing_payloads.json
+++ b/stories/phishing_payloads.json
@@ -27,7 +27,7 @@
   ],
   "modification_date": "2019-04-29",
   "name": "Phishing Payloads",
-  "narrative": "Despite its simplicity, phishing remains the most pervasive and dangerous cyberthreat. In fact, research shows that as many as [91% of all successful attacks](https://digitalguardian.com/blog/91-percent-cyber-attacks-start-phishing-email-heres-how-protect-against-phishing) are initiated via a phishing email. \n\nAs most people know, these emails use fraudulent domains, [email scraping](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), familiar contact names inserted as senders, and other tactics to lure targets into clicking a malicious link, opening an attachment with a [nefarious payload](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), or entering sensitive personal information that perpetrators may intercept. This attack technique requires a relatively low level of skill and allows adversaries to easily cast a wide net. Worse, because its success relies on the gullibility of humans, it's impossible to completely \"automate\" it out of your environment. However, you can use ES and ESCU to detect and investigate potentially malicious payloads injected into your environment subsequent to a phishing attack. \n\nWhile any kind of file may contain a malicious payload, some are more likely to be perceived as benign (and thus more often escape notice) by the average victim&#151;especially when the attacker sends an email that seems to be from one of their contacts. An example is Microsoft Office files. Most corporate users are familiar with documents with the following suffixes: .doc/.docx (MS Word), .xls/.xlsx (MS Excel), and .ppt/.pptx (MS PowerPoint), so they may click without a second thought, slashing a hole in their organizations' security. \n\nFollowing is a typical series of events, according to an [article by Trend Micro](https://blog.trendmicro.com/trendlabs-security-intelligence/rising-trend-attackers-using-lnk-files-download-malware/):<ol><li>Attacker sends a phishing email. Recipient downloads the attached file, which is typically a .docx or .zip file with an embedded .lnk file</li><li>The .lnk file executes a PowerShell script</li><li>Powershell executes a reverse shell, rendering the exploit successful </ol>As a side note, adversaries are likely to use a tool like Empire to craft and obfuscate payloads and their post-injection activities, such as [exfiltration, lateral movement, and persistence](https://github.com/EmpireProject/Empire).\n\nThis Analytic Story focuses on detecting signs that a malicious payload has been injected into your environment. For example, one search detects outlook.exe writing a .zip file. Another looks for suspicious .lnk files launching processes.",
+  "narrative": "Despite its simplicity, phishing remains the most pervasive and dangerous cyberthreat. In fact, research shows that as many as [91% of all successful attacks](https://digitalguardian.com/blog/91-percent-cyber-attacks-start-phishing-email-heres-how-protect-against-phishing) are initiated via a phishing email. \n\nAs most people know, these emails use fraudulent domains, [email scraping](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), familiar contact names inserted as senders, and other tactics to lure targets into clicking a malicious link, opening an attachment with a [nefarious payload](https://www.cyberscoop.com/emotet-trojan-phishing-scraping-templates-cofense-geodo/), or entering sensitive personal information that perpetrators may intercept. This attack technique requires a relatively low level of skill and allows adversaries to easily cast a wide net. Worse, because its success relies on the gullibility of humans, it's impossible to completely \"automate\" it out of your environment. However, you can use ES and ESCU to detect and investigate potentially malicious payloads injected into your environment subsequent to a phishing attack. \n\nWhile any kind of file may contain a malicious payload, some are more likely to be perceived as benign (and thus more often escape notice) by the average victim&#151;especially when the attacker sends an email that seems to be from one of their contacts. An example is Microsoft Office files. Most corporate users are familiar with documents with the following suffixes: .doc/.docx (MS Word), .xls/.xlsx (MS Excel), and .ppt/.pptx (MS PowerPoint), so they may click without a second thought, slashing a hole in their organizations' security. \n\nFollowing is a typical series of events, according to an [article by Trend Micro](https://blog.trendmicro.com/trendlabs-security-intelligence/rising-trend-attackers-using-lnk-files-download-malware/):\n\n1. Attacker sends a phishing email. Recipient downloads the attached file, which is typically a .docx or .zip file with an embedded .lnk file\n\n1. The .lnk file executes a PowerShell script\n\n1. Powershell executes a reverse shell, rendering the exploit successful </ol>As a side note, adversaries are likely to use a tool like Empire to craft and obfuscate payloads and their post-injection activities, such as [exfiltration, lateral movement, and persistence](https://github.com/EmpireProject/Empire).\n\nThis Analytic Story focuses on detecting signs that a malicious payload has been injected into your environment. For example, one search detects outlook.exe writing a .zip file. Another looks for suspicious .lnk files launching processes.",
   "original_authors": [
     {
       "company": "Splunk",
diff --git a/stories/splunk_vulnerabilities.json b/stories/splunk_vulnerabilities.json
index b23431114d..19b1699541 100644
--- a/stories/splunk_vulnerabilities.json
+++ b/stories/splunk_vulnerabilities.json
@@ -22,7 +22,7 @@
   ],
   "modification_date": "2017-09-19",
   "name": "Splunk Enterprise Vulnerability",
-  "narrative": "This Analytic Story is associated with CVE-2016-4859, an open-redirect vulnerability in the following versions of Splunk Enterprise:\n\n<ul><li>Splunk Enterprise 6.4.x, prior to 6.4.3</li><li>Splunk Enterprise 6.3.x, prior to 6.3.6</li><li>Splunk Enterprise 6.2.x, prior to 6.2.10</li><li>Splunk Enterprise 6.1.x, prior to 6.1.11</li><li>Splunk Enterprise 6.0.x, prior to 6.0.12</li><li>Splunk Enterprise 5.0.x, prior to 5.0.16</li><li>Splunk Light, prior to 6.4.3</li></ul>CVE-2016-4859 allows attackers to redirect users to arbitrary web sites and conduct phishing attacks via unspecified vectors. (Credit: Noriaki Iwasaki, Cyber Defense Institute, Inc.).\n\nIt is important to ensure that your Splunk deployment is being kept up to date and is properly configured. This detection search allows analysts to monitor internal logs to ensure users are properly authenticated and cannot be redirected to any malicious third-party websites.",
+  "narrative": "This Analytic Story is associated with CVE-2016-4859, an open-redirect vulnerability in the following versions of Splunk Enterprise:\n\n\n\n1. Splunk Enterprise 6.4.x, prior to 6.4.3\n\n1. Splunk Enterprise 6.3.x, prior to 6.3.6\n\n1. Splunk Enterprise 6.2.x, prior to 6.2.10\n\n1. Splunk Enterprise 6.1.x, prior to 6.1.11\n\n1. Splunk Enterprise 6.0.x, prior to 6.0.12\n\n1. Splunk Enterprise 5.0.x, prior to 5.0.16\n\n1. Splunk Light, prior to 6.4.3CVE-2016-4859 allows attackers to redirect users to arbitrary web sites and conduct phishing attacks via unspecified vectors. (Credit: Noriaki Iwasaki, Cyber Defense Institute, Inc.).\n\nIt is important to ensure that your Splunk deployment is being kept up to date and is properly configured. This detection search allows analysts to monitor internal logs to ensure users are properly authenticated and cannot be redirected to any malicious third-party websites.",
   "original_authors": [
     {
       "company": "Splunk",
diff --git a/stories/suspicious_emails.json b/stories/suspicious_emails.json
index 78894521ff..49f784b69e 100644
--- a/stories/suspicious_emails.json
+++ b/stories/suspicious_emails.json
@@ -32,7 +32,7 @@
   ],
   "modification_date": "2017-09-19",
   "name": "Suspicious Emails",
-  "narrative": "It is a common practice for attackers of all types to leverage targeted spearphishing campaigns and mass mailers to deliver weaponized email messages and attachments. Fortunately, there are a number of ways to monitor email data in Splunk to detect suspicious content.\n\nOnce a phishing message has been detected, the next steps are to answer the following questions: <ul><li>Which users have received this or a similar message in the past?</li><li>When did the targeted campaign begin?</li><li>Have any users interacted with the content of the messages (by downloading an attachment or clicking on a malicious URL)?</li></ul>This Analytic Story provides detection searches to identify suspicious emails, as well as contextual and investigative searches to help answer some of these questions.",
+  "narrative": "It is a common practice for attackers of all types to leverage targeted spearphishing campaigns and mass mailers to deliver weaponized email messages and attachments. Fortunately, there are a number of ways to monitor email data in Splunk to detect suspicious content.\n\nOnce a phishing message has been detected, the next steps are to answer the following questions: \n\n1. Which users have received this or a similar message in the past?\n\n1. When did the targeted campaign begin?\n\n1. Have any users interacted with the content of the messages (by downloading an attachment or clicking on a malicious URL)?This Analytic Story provides detection searches to identify suspicious emails, as well as contextual and investigative searches to help answer some of these questions.",
   "original_authors": [
     {
       "company": "Splunk",