Merge pull request #31 from splunk/dns_hijack_update

Dns hijack update

Author: josehelps

escu/searches/contextual_get_risk_for_endpoint.json

@@ -32,7 +32,7 @@
     }
   ],
   "search": "| from datamodel:Risk.All_Risk | search risk_object_type=system risk_object={dest} | stats count sum(risk_score) as risk_score values(search_name)  min(_time) as firstTime max(_time) as lastTime by risk_object | `ctime(firstTime)` | `ctime(lastTime)`",
-  "search_description": "For the last 7 days, the search will query the Risk data model in Splunk Enterprise Security and calculate the count, sum of the risk_scores, names of the correlation searches that contributed to create a risk score for a specific endpoint(machine_name) ",
+  "search_description": "For the last 7 days, the search will query the Risk data model in Splunk Enterprise Security and calculate the count, sum of the risk\\_scores, names of the correlation searches that contributed to create a risk score for a specific endpoint(machine\\_name) ",
   "search_id": "fdcfb369-1725-4c24-824a-22972d7f0d65",
   "search_name": "Get Risk Modifiers For Endpoint",
   "search_type": "contextual",

escu/searches/detection_dyn_dns_queries.json

@@ -33,7 +33,7 @@
       "Bro"
     ]
   },
-  "eli5": "The search is querying an accelerated Network_Resolution data model to count and list the values of resolved domains for each DNS query and checks that against the list of Dynamic DNS providers (lookup - dynamic_dns_providers) by each host (DNS.src)",
+  "eli5": "The search is querying an accelerated `Network_Resolution` data model to count and list the values of resolved domains for each DNS query and checks that against the list of Dynamic DNS providers (lookup - `dynamic_dns_providers`) by each host (DNS.src)",
   "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 similar solutions. 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, <code>dynamic_dns_providers_default.csv</code>, 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 <code>dynamic_dns_providers_local.csv</code>.",
   "known_false_positives": "Some users and applications may leverage Dynamic DNS to reach out to some domains on the Internet since dynamic DNS by itself is not malicious, however this activity must be verified.",
   "maintainers": [

escu/searches/support_discover_dns_records.json

@@ -35,7 +35,7 @@
     "latest_time": "-10m@m"
   },
   "search": "| inputlookup cim_corporate_email_domains.csv | inputlookup append=T cim_corporate_web_domains.csv | inputlookup append=T cim_cloud_domains.csv | eval domain = trim(replace(domain, \"\\*\", \"\")) | join domain [|tstats summariesonly=true count values(DNS.record_type) as type, values(DNS.answer) as answer from datamodel=Network_Resolution where DNS.message_type=RESPONSE DNS.answer!=\"unknown\" DNS.answer!=\"\" by DNS.query | rename DNS.query as query | where query!=\"unknown\" | rex field=query \"(?<domain>\\w+\\.\\w+?)(?:$|/)\"] | makemv delim=\" \" answer |  makemv delim=\" \" type | sort -count | table count,domain,type,query,answer | outputlookup createinapp=true discovered_dns_records.csv",
-  "search_description": "The search takes corporate and common cloud provider domains configured under cim_corporate_email_domains.csv, cim_corporate_web_domains.csv, and cloud_domains.csv and finds their responses across the last 30 days from data in the Network Traffic datamodel, then stores the output under the discovered_dns_records.csv lookup",
+  "search_description": "The search takes corporate and common cloud provider domains configured under `cim_corporate_email_domains.csv`, `cim_corporate_web_domains.csv`, and `cloud_domains.csv` finds their responses across the last 30 days from data in the `Network_Traffic` datamodel, then stores the output under the `discovered_dns_records.csv` lookup",
   "search_id": "c096f721-8842-42ce-bfc7-74bd8c72b7c3",
   "search_name": "Discover DNS records",
   "search_type": "support",

escu/stories/dns_hijacking.json

@@ -13,7 +13,7 @@
   ],
   "modification_date": "2019-02-14",
   "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. Its distributed nature is one reason, as it relies on unstructured connections between millions of clients and servers over inherently insecure protocols.<br></br>The 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. <br></br>On 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 2019s DNS records.</li><li>Implement multi-factor authentication (MFA) for all accounts on systems that can make changes to each agency 2019s 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. <br></br>In 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.<br></br>The 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.<br></br>The 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. <br></br>On 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. <br></br>In 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.<br></br>The 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",