Attackers have been known to take advantage of world events to increase their use of phishing, social engineering, malware delivery, and numerous other nefarious attacks. The recent COVID-19 pandemic is no exception as attackers are currently creating custom campaigns to lure users to malicious and nefarious content. Two threat researchers at Sophos, Sean Gallagher, and Andrew Brandt, have written a great blog named Facing down the myriad threats tied to COVID-19 that goes into detail around the new phishing campaigns being deployed.
New phishing campaigns, combined with the explosion of remote workforces, have dramatically increased the likelihood of an attack being successful. At the same time, detection capabilities have weakened due to the sheer number of user systems no longer being protected by corporate perimeter defenses.
New, customized detection content is needed to meet these challenges head-on. The following post will explore new custom content recently developed by the LogRhythm SOC team. While these watchlists and custom AI Engine rules will not be released to the public, these use cases show how custom content can be used to detect COVID-19 and other similar theme-based campaigns. Additionally, these customizations presented below use the Endpoint Detection and Response (EDR) solution from VMware Carbon Black and the Identity and Access Management (IAM) solution from Okta. The flexibility of the LogRhythm platform allows you to create custom content with any EDR or IAM solution.
LogRhythm Custom Phishing Detections
Detecting suspicious activity that might be a phish occasionally requires thinking outside the box. Zack Rowland, senior security engineer, and Eric Brown, senior security analyst, in the LogRhythm SOC department under CSO James Carder, have created several new AI Engine automation rules to detect suspicious email activity. These rules can be adapted to help you detect COVID-19-, coronavirus-, and other crisis-based variants being used to lure and phish users. The following custom rules are examples of how LogRhythm can be used to detect unique use cases.
Outlook Link: Internationalized Domain Name
Background Information
For more information on how Punycode (Internationalized Domain Name) phishing attacks occur, please read the blog titled Phishing with ‘punycode’ – when foreign letters spell English words from Sophos.
Using LogRhythm and VMware Carbon Black to Detect Threats
Figure 1. AI Engine Rule: Outlook Link: Internationalized Domain Name
This AI Engine rule uses logs from the VMware Carbon Black EDR. These logs are generated by a custom watchlist configured in VMware Carbon Black EDR and ingested into the LogRhythm NextGen SIEM Platform through a custom Message Processing Engine (MPE) rule. These specific customizations allow you to see your security data from a different perspective. They were influenced by internal feedback from the LogRhythm SOC.
Figure 2. VMware Carbon Black custom watchlist
The key in this detection method is in the custom watchlist. As such, take a moment to review the description of this custom watchlist in Figure 2. Here you can see the purpose of the watchlist, along with an important note: “The watchlist itself does not necessarily indicate suspicious behavior, only that a link was opened.”
To reduce false positives, the watchlist is built to exclude known URLs before sending the log to AI Engine. And the AI Engine rule is built to serve an event only on suspicious activity. By coupling this custom watchlist with AI Engine, you now have an AI Engine event worth prioritizing.
Figure 3. AI Engine rule: Focus on “Include Filters” and URL is : xn--.
As mentioned earlier, this AI Engine rule also uses a custom MPE parsing rule. You can learn more about custom MPE rules by reviewing the LogRhythm Community post titled Custom MPE Rules using Regular Expression Training Materials. The differences between the default rule (Figure 4), and the custom rule (Figure 5) are highlighted.
Figure 4. Default MPE rule with RegEx differences highlighted
Figure 5. Custom MPE rule with RegEx differences highlighted
As you can see, there are considerable differences. The major difference between the two is the parsing out of the log message the URL as shown here:
Figure 6. MPE rule focus: Adding URL parsing
Once everything is set up, you can see how this custom dashboard displays the resulting AI Engine events, with the URL field being parsed from the LogRhythm WebUI.
Figure 7. WebUI custom dashboard (redacted)
Outlook Link: Custom Malware Detection
Background Information
Some specific malware has strong indicators of compromise (IOC) that are worth tracking in an EDR solution. You can learn more about what an IOC is by reviewing definitions in LogRhythm’s End User Agreement.
To get a picture of specific IOC, a custom detection is sometimes needed in your EDR solution, along with custom MPE rules in LogRhythm to parse out the specific information. Tying this security data with IOCs delivered via the LogRhythm Threat Intelligence Service enables the detection to be more targeted, and for false positives to be filtered.
Using LogRhythm and VMware Carbon Black to Detect Threats
Figure 8. AI Engine rule: Outlook Link: Custom Malware Detection
This custom AI Engine rule leverages the log source type of VMware Carbon Black EDR LEEF, and two custom VMware Carbon Black watchlists. Two custom MPE rules are also being utilized. The differences between the default Watchlist Hit: Storage Process rule (Figure 9), and the custom Watchlist Hit: Process rule (Figure 10) are highlighted below.
Figure 9. Default Watchlist Hit: Storage process with RegEx differences highlighted
Figure 10. Custom Watchlist Hit: Storage process with RegEx differences highlighted
As you can see there are considerable differences between the two. The custom MPE rule can be used in not just for this use case, but in other use cases where you want more details from the log you can use during an investigation, or in the construction of custom AI Engine rules like this one.
This custom AI Engine rule also uses lists that house the IOCs. As seen below, lists may be populated from LogRhythm’s Threat Intelligence Service which provides IOCs from both commercial and open-source vendors and supports both versions of STIX/TAXII.
Figure 11. Custom lists containing URL, host, and IP address information
This custom rule can be easily cloned to look for IOCs around the increase of COVID-19 phishing lures, phishing scams, spearphishing, etc., by creating new lists with known bad domains and IPs.
LogRhythm Custom Multi-Factor Authentication Detections
OKTA: Repeated MFA Push Denials
Background Information
With a remote workforce, it’s very important that you embrace a Zero Trust model and use multifactor authentication (MFA). You can read more about Zero Trust from James Carder in the blog, What is the Zero Trust Model for Cybersecurity, Really?.
One of the great benefits of using an MFA is the single source of authentication logs. This AI Engine rule is centered around OKTA logs to event on suspicious activity that could demonstrate compromised credentials by an attacker. To associate this activity to attackers using COVID-19 opportunistic attacks would take additional investigation efforts, but the important action is to investigate the suspicious activity around MFA.
AI Engine Rule and OKTA Logs
Figure 12. AI Engine Rule: OKTA: Repeated MFA Push Denials
This custom rule is using a log source type of API – Okta Event and looking for user.mfa.okta_verify.deny_push. Deny push in Okta may indicate that credentials have been compromised, and the adversary performed a push request which went to the real user. The user wasn’t trying to authenticate and therefore denied the request.
Looking at the region a request came from, along with a number of user accounts could also reveal suspicious indicators where an adversary has multiple user credentials and is successfully authenticating with the passwords, but trying to get a user to accept the push notification so they can gain access to corporate information. When investigating this type of activity, it’s best to reach out to the user and see if they requested a push notification or not. If not, having the user change their password is highly advisable.
Below you can find two WebUI analyze dashboards, showcasing region information and activity associated with remote workers accessing VPN and MFA services.
Figure 13. WebUI Analyze Dashboard: Juniper SSLVPN Region Activity
Figure 14. WebUI Analyze Dashboard: Okta Region Activity
LogRhythm Custom Suspicious Top-Level Domain (TLD) Detection
Outlook Link: Suspicious Country TLD
Background Information
There are some Top-Level Domains and Generic Top-Level Domains (TLD) that are more suspicious than others. You can find out more about looking for TLDs in the blog, DPA-Powered Dashboards. It is difficult to spot suspicious activity from a system that is remote, and not going through corporate infrastructure for DNS queries, web filtering, etc. Today’s remote workforce is likely going straight to the internet for corporate resources, such as Microsoft Office 365 or Box.
With the increase of malicious phishes end users are receiving, and the only thing standing between users opening a phish or not seeing the phish in the first place are email filters, phishes are likely still going to get through. With the additional challenges of logging endpoint activity when remote, sometimes you can only visibility through your EDR solution and the logs they deliver into the SIEM. By leveraging the custom VMware Carbon Black watchlist titled, Browser opened outlook e-mail link, you can create additional AI Engine rules that look at more specific items of interest like known TLDs and gTLDs that users should not be directed to.
AI Engine and VMware Carbon Black
Figure 15. AI Engine rule: Outlook Link: Suspicious Country TLD
This AI Engine rule uses components that were discussed earlier. What’s inherently different about this one is the use of RegEx in the URL field to look for suspicious TLDs. You can clone this rule and change the URL to look for other types of suffixes. For example, there are known phishing attacks taking advantage of the COVID-19 pandemic where the email link may look official, but the TLD is .org or .net instead of .gov. Additionally, users can be socially engineered to click on the link if the URL looks legitimate. In this example, an attacker could include .gov inside the URL: phishing.gov.org. This rule would fire if a user clicked a link containing .gov in an Outlook message and would be a good suspicious indicator for you to follow-up on.
LogRhythm Custom Phishing Link Detection with Microsoft Sysmon
MITRE ATT&CK: Initial Access: Spearphishing Link (T1192)
Background Information
The SOC team at LogRhythm has been very focused on creating detections based on the MITRE ATT&CK framework. The team has produced multiple blogs, videos, and webinars that go into detail around how LogRhythm is using the MITRE ATT&CK framework, as well as resources that help demonstrate what the MITRE ATT&CK framework is. We also have a MITRE ATT&CK module to be used in your LogRhythm SIEM, and dashboards to be used in the LogRhythm WebUI.
The final rule works to detect when someone clicks on a link in Outlook. Much like the VMware Carbon Black custom watchlist hit, the primary criteria are looking for a parent process named Outlook, and the child process is a browser. This type of detection can work across several log source types. By leveraging Microsoft Sysmon, or Microsoft audit event id 4688 with command line logging enabled, you will see what URL the browser went to from the email link click. Without the command line visibility, you could still detect when someone clicks a link, but unfortunately, you will not have the visibility as to what URL they clicked on through this detection method.
AI Engine and Combined Process Detection
Figure 16. AI Engine Rule: MITRE ATT&CK: Initial Access: Spearphishing Link (T1192)
As discussed, this experimental base rule is looking for a parent process name of Outlook.exe and a child process named Firefox.exe. The process name would be expanded upon based on the browsers in your environment. The rule leverages a log source type of Microsoft Sysmon, where event ID 1 will record the process execution of Outlook spawning Firefox and passing the URL in the command line. Below, you can see the detection in the WebUI.
Figure 17. WebUI Analyze Dashboard: Custom Spearphishing Link
The command captures the “-url” which then could be matched to a list of suspicious IOCs via RegEx. Another option you could explore is creating a custom MPE rule to parse out the domain in a way that you can more easily match your IOCs without RegEx.
In Summary
Attackers are leveraging world events, such as the COVID-19 pandemic, to increase their success rates via phishing and other methods. Combined with the fact a large portion of organizations are transitioning to a remote workforce without the typical enterprise defenses, detecting suspicious activity is only becoming more challenging.
The good news is there are a lot of ways you can detect suspicious activity. In times like these, finding novel and custom ways of detecting suspicious activity becomes paramount. Creating your first custom rule, whether it be an AI Engine rule, MPE rule, or EDR rule may seem daunting to try at first, but know subsequent rules are increasingly easier to make. To lower the learning curve, LogRhythm has a robust Community and Slack channel. Additionally, the Professional Services organization is here to help you deploy custom content specific to your environment!
Have you developed any custom content to detect suspicious activity that you would like to share? If so, leave a comment below.
Contributors to this blog include the following members of the LogRhythm team; Brian Coulson, James Carder, Zack Rowland, and Eric Brown.