Monitor for, Investigate, and Respond to Phishing Payloads with Splunk Enterprise Security Content Update

While phishing is one of the world's most effective attack vectors, it still relies on effective payloads to survive the first stage of the attack, where the victim either visits a malicious website or opens a deceptive attachment, bypassing security controls. Phishing is a technique practiced by criminals, but also for penetration testing and red team exercises, which use this type of social engineering to help assess a target organization’s security posture.

There are plenty of off-the-shelf tools available to help even a less-skilled attacker craft and obfuscate payloads for phishing attacks, lowering the barrier to entry. One of the most popular post-exploitation frameworks for payloads is Empire. Empire is a very effective tool for crafting and obfuscating post-exploitation payloads based on Powershell 2.0 or Python. These payloads act like agents that communicate back and forth and can execute multiple post-exploitation functions, including payload injections, exfiltration, lateral movement, persistence, and more.

The screenshot below shows the Empire framework: Once the victim has executed the payload, Empire provides the attacker with a number of functions to help them maneuver through a victim's system, escalate privileges, and navigate through the compromised network.

The screenshot below shows Empire's post-exploitation module detecting Windows Defender (ATT&CK T1063):

Many of these phishing payload frameworks also allow the attacker to incorporate customized payloads, which usually enable more effective obfuscation, as well as recent or unpublished exploitation code. One such payload in the wild is CVE-2017-8464 (Code execution via .lnk file), which has been seen in recent malicious campaigns. This type of payload is usually delivered via email. The actual payload will likely be compressed into a password-protected .zip file to bypass security product scanning, as demonstrated in the following image.

Tactical SIEM Detection and Investigation

Once the file is opened, it is placed in a temporary folder. We can obtain this information from log sources of many EDR/ETDR tools. In this case, such information was obtained using Sysmon logs (where this operation will register an EventCode 15).

Find the process id of outlook.exe OR explorer.exe and output process_id as parent_process_id

| tstats `summariesonly` min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Processes where Processes.process_name=outlook.exe OR Processes.process_name=explorer.exe by _time span=5m Processes.parent_process_id Processes.process_id Processes.dest Processes.process_name Processes.parent_process_name Processes.user

| `drop_dm_object_name(Processes)`

| `ctime(firstTime)`

| `ctime(lastTime)`

| rename process_id as malicious_id

| rename parent_process_id as outlook_id

Join parent_process_id with any child process that wrote a .zip file with a .lnk in it under the C:\Users* or *Local\Temp* paths.

| join malicious_id type=inner

   [| tstats `summariesonly` count values(Filesystem.file_path) as file_path values(Filesystem.file_name) as file_name FROM datamodel=Endpoint.Filesystem where (Filesystem.file_path=*zip* OR Filesystem.file_name=*.lnk ) AND (Filesystem.file_path=C:\\Users* OR Filesystem.file_path=*Local\\Temp*) by _time span=5m Filesystem.process_id Filesystem.file_hash Filesystem.dest

   | `drop_dm_object_name(Filesystem)`

   | `ctime(firstTime)`

   | `ctime(lastTime)`

   | rename process_id as malicious_id

Display the fields

| fields malicious_id outlook_id dest file_path file_name file_hash count file_id]

| table firstTime lastTime user malicious_id outlook_id process_name parent_process_name file_name file_path

| where file_name != ""

The screenshot below shows the first phase of the .zip file's extraction:

The search shows the process outlook.exe (email client) or explorer.exe (Windows File Explorer) extracting a .zip with a .lnk file. From there, depending on the payload, the .lnk file execution will either download an additional payload or execute a file (usually embedded in the same .zip file).

For detection, the Security Research Team's goal was to pinpoint the exact path of the malicious file. We accomplished this by ingesting and searching Sysmon log files. We can identify the application that initially opened the file (Microsoft Outlook). Also, notice Sysmon EventCode 11, which shows the name of the malicious file, plus :Zone.Identifier, which is file metadata used for location and execution of next payload.

In the following graphic, you can see the next phases after .zip extraction and .lnk file execution. Also, note how the execution of the .lnk file is followed by the spawning of a powershell.exe process, then the download and execution of a powershell file (.ps1). 


Splunk Phantom can also be used to perform a wide range of investigation and response actions involving email attachments. The recently released Phantom Community Playbook called “Suspicious Email Attachment Investigate and Delete” is an example of how Splunk ES and Splunk Phantom can be used together to repeatedly detect, investigate, and delete suspicious emails with attachments in a highly automated fashion. This playbook can be triggered by either of the detection searches in the "Suspicious Emails" Analytic Story. Once initiated, the playbook detonates the file attachment in a sandbox, extracts network indicators from the detonation, checks them against threat-intelligence databases and internal Splunk data models, and notifies the appropriate analyst with all of the results. From there, the analyst can approve an action to delete the email from the user’s inbox--hopefully before they have opened it or executed the attachment.

The following screen capture shows an example of an email payload triage performed via Splunk Phantom. This playbook combines several log sources and defense technologies to triage the file and orchestrate a response. Some of the components used below include file extraction, sandbox detonation, IP reputation check, DNS checks, and URL checks, and more.

Oh, Phishy, Phishy, Phishy, Phish... 

The Splunk Security Research Team hopes that our Analytic Stories on phishing help you develop a formidable defense against this attack vector. We welcome your feedback, as well. Feel free to leave comments below and/or click on the Feedback Center tab in ESCU and let us know how to improve! (Of course, we love compliments, too.)


The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.

Read more Splunk Security Content


Monitor for, Investigate, and Respond to Phishing Payloads with Splunk Enterprise Security Content Update

Show All Tags
Show Less Tags

Join the Discussion