Splunk Security Research Went on a Phishing Trip – Here's What Happened

The Security Research Team at Splunk is devoted to carefully observing the behaviors of attackers in the wild and then creating ways for you to monitor for, investigate, and respond to any signs of these behaviors and activities in your environment using Splunk security products (Splunk Enterprise Security Content Update, Splunk User Behavior Analytics, and Splunk Phantom). That's why we recently tackled one of cybersecurity's most nefarious attack techniques: phishing.

We built two Analytic Stories to highlight two separate issues—phishing frameworks and phishing payloads. Because we know that the best way to catch a phish is to get your own pole and learn how to do it yourself (sorry—we had to!), these stories provide you with tools to track down signs of these activities and immediately take action on them.

Phishing is one of the world's most insidious and effective attack vectors. Because its success depends on the fact that no human can detect 100% of the suspicious emails they receive, it's also one of the most difficult to defend against. No matter how much training they might receive or how much awareness they may have, someone in your organization will eventually hover their mouse above a fraudulent "see attached" link and click. Bam! They've invited the vampire inside. Because it's so effective, there's a large market devoted to sales of exploitation kits and obfuscated post-exploitation payloads, making it progressively easier for even rookie attackers to jump in the pond with the big phish. The bottom line is that it should be a priority to ensure that you can quickly detect, investigate, and respond to signs that your environment has been compromised by a phishing attack.

The first story, "Common Phishing Frameworks," is designed to detect DNS and web requests to fake websites generated by the EvilGinx2 toolkit. EvilGinx2 creates a transparent proxy between the targeted site and the user, setting up a man-in-the-middle (MiTM) attack that allows the attacker to intercept credentials and two-factor identification tokens.

The search above looks for DNS requests being made to phishing sites that were generated with the EvilGinx2 toolkit.  

The EvilGinx2 framework uses proxy templates called "phishlets" that allow a registered domain to impersonate targeted sites, such as Linkedin, Amazon, Okta, Github, Twitter, Instagram, Reddit, Office 365, and so on. It can register SSL certificates via Let’s Encrypt or allow the operator to import their own. This is especially dangerous, because a registered site with a legitimate SSL certificate, camouflaged via puny code or a URL shortener, can be difficult to spot—even for the trained eye.

The searches in "Common Phishing Frameworks" look for signs of MiTM attacks enabled by EvilGinx2. Read this blog post to learn more about Evilginx2, other common phishing frameworks, and the research behind this Analytic Story.

Defending Against Phishing Payloads

Also included in the April release is a new "Phishing Payloads" Analytic Story. While almost any kind of file may contain a malicious payload, Microsoft Office files, .zip files, and PDF files are the most commonly employed by attackers, since they're used frequently in business contexts and are therefore less likely to attract attention by the average email recipient. In a typical scenario, the unwitting user would download an attached file containing an embedded .lnk object. That .lnk file executes a PowerShell script, which executes a reverse shell. Some phishing payload frameworks allow attackers to incorporate customized payloads (which may be easier to obfuscate) as well as recent or unpublished exploitation code. They can usually compress the actual payload into a password-protected .zip file, which helps it bypass security product scanning.

The Phishing Payloads story includes searches that look for signs of unexpected behavior—such as outlook.exe writing a .zip file or suspicious .lnk files launching processes—that may indicate that a malicious payload has been injected into your environment.

Phishing Payloads search "Suspicious .LNK file launching a process."

Read this blog post to learn more about detecting and defending against phishing payloads and the research behind this Analytic Story.

New Machine-Learning Capabilities

In other news, we recently added some ESCU searches that leverage the new DensityFunction algorithm in the Splunk Machine Learning Toolkit. The new ML related content in ESCU takes the form of six searches: three support searches that are used to create the ML models and three detection searches that use the models built by the support searches to look at new data and identify the outliers relative to historical norms. The new searches are designed to look for spikes in SMB connections, unusually long command lines on your endpoints, and unusually long DNS queries, which could be attributed to activity with machine-generated domain names or misuse of the DNS protocol for nefarious purposes. Following are the titles of these searches:

• Baseline of DNS Query Length - MLTK
• Baseline of SMB Traffic - MLTK
• Baseline of Command Line Length - MLTK
• DNS Query Length Outliers - MLTK
• SMB Traffic Spike - MLTK
• Unusually Long Command Line - MLTK
   

Policing DNS Hijacking

ESCU also recently added an Analytic Story focusing on DNS Hijacking. DNS plays an essential role in routing web traffic. Unfortunately, because it relies on unstructured connections between millions of clients and servers over inherently insecure protocols, it is also extraordinarily vulnerable. Successful DNS attacks can expose your organization's most confidential information, emails, and login credentials, making prevention of utmost importance.

In January of 2019, DHS issued Emergency Directive 19-01, which summarized some recent high-profile DNS hijacking campaigns and required government agencies to take a series of actions to secure their environments, such as auditing DNS records, reporting DNS servers that do not resolve to intended locations, updating passwords for all accounts on all systems that can make changes to DNS records, implementing MFA, and so on. Such changes make sense for every secure environment.  

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. 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.

The searches in this Analytic Story help you detect and investigate activities that may indicate that DNS hijacking has taken place within your environment.

One of the detection searches, "DNS record changed," helps you keep tabs on changing DNS records to ensure that there is no unauthorized activity.

The "DNS record changed" search looks both at the DNS records and the results of the discovereddnsrecords lookup to see if any records have changed within the last day.

Another search detects DNS requests resolved by unauthorized DNS servers. Legitimate DNS servers should be identified in the Enterprise Security Assets and Identity Framework. Clients should be resolving their DNS requests via a trusted DNS server. This search will identify DNS queries being sent to unauthorized DNS servers by comparing the destination and source of the traffic with assets marked as DNS servers. See screenshot below.

The Security Research team continues to build out and develop these Analytic Stories over time, so don't forget to stay up to date with the most recent version of ESCU. Download Splunk Enterprise Security Content Update from Splunkbase now!