Featured post

Dynamic DNS… With Google Domains?

I recently switched all of my domains over to Google Domains. While I didn’t have an issue with my previous domain registrar, I wanted to try something new. The primary allure of moving to Google Domains was the fact that private info domain registrations cost nothing additional over public registrations. I’ve never experienced issues as a direct result of public registrations… most likely because I always created email aliases instead of using actual email addresses. Regardless, I haven’t felt completely at ease giving phishers/spammers another way to lookup data on me or my customers. BTW, I’m sure there are other providers possibly doing the same with no cost private upgrades; I just decided on Google because I heard they were doing it and my current registrar changed $/yr for this service.

So with my initial reasoning out of the way, here’s where the main narrative comes in. I was messing in my lab and I realized I needed a few dynamic IP addresses associated with hostnames of my choosing. I first turned to DynDNS because I used them for years in my business and they always worked well. That being said, there wasn’t anything special about what they were doing and I knew there were hundreds of other options that had popped up (and went away) over the years. I figured “why not” until I saw the price had increased substantially over what I had last remembered. The header on the Dyn website also reminded me that Oracle now owned them. Did that play a role in the price increase? I don’t know if that was necessarily the case, but it gave me enough of a reason for me to move on and find an alternative. Without getting into details, I believe Oracle is the scourge of the tech world beyond their significant contributions to early databases.

Anywho, I looked through the dynamic DNS list of vendors the firewall vendor provided and I discovered a reference to Google Domains. Huh? Was I about to pay for something I already had and didn’t know existed? To my surprise, yes!

Google actually has a nice write-up on how to create a dynamic DNS record with an existing domain. This guide will overlap with that guide to some degree, but we’ll finish this up by adding this information into pfSense.

https://support.google.com/domains/answer/6147083?hl=en

Start by going to https://domains.google.com/registrar, which will bring up your list of domains you already own.

Click on the Configure DNS icon next to your domain of choice.

Configure DNS

Scroll down to the “Synthetic records” section and switch the dropdown to “Dynamic DNS.” Type in the subdomain name of your choosing and then click Add.

Synthetic Records

Click the arrow > next to your newly created domain and then click “View credentials” to view the generated username and password. Take note of the domain as well as the username/password as we’ll use them in a bit. Note: The fact Google Domains provides a separate username/password combination for each domain actually gives it a distinct security advantage over services like DynDNS.

Dynamic DNS

If you’re using something other than a pfSense, skip to the bottom and you’ll find some settings for DDclient. Otherwise, read on!

Now, on your pfSense firewall, go to Services > Dynamic DNS. Keep in mind these steps will be similar on any other device that supports Google Domains as a valid Dynamic DNS vendor!

pfSense Dynamic DNS

Click Add and then enter your necessary details in the next screen. Remember the domain name, username, and password from the Google Domains section? Also make sure you input the entire domain and *not* just the subdomain. For example, use mydomainofchoice.example.com instead of mydomainofchoice with no domain.

dynamic_dns_client

If all goes well, you’ll get back to the dynamic DNS clients page and you’ll see your newly created domain as well a green IP address, which means it updated!

pfsense clients list

Last but not least, you need to test and verify your domain name resolves. You can do this by going to any command line (Linux or Windows) and typing “ping mydomainofchoice.example.com” and verifying it resolves. Note: I usually try to wait about 5 minutes or so even though the TTL for Google Domains (or most all dynamic DNS services) is 1 minute.

That’s it! Also, if you don’t have a pfSense or similar device, keep in mind that Google Domains also provides support for DDclient although I haven’t tried it out.

So whatever your situation, Google Domains provides a cheap (free) and easy way to access your dynamic public IP address via a hostname for any domain you already own and have registered with them! So don’t pay your ISP for a static… instead, do it with dynamic DNS and Google Domains. Very cool!

Uncovering Indicators of Compromise

Last updated: 16 October 2016

This is the new version of a paper and script I originally wrote as part of my SANS gold paper for the GCCC certification. The paper re-write was primarily in preparation for my presentation of the topic at the 2016 Nagios World Conference… Unfortunately, the conference was canceled. <sigh> Nonetheless, the paper now covers version 6 of the Critical Security Controls instead of 5.1.

The original paper in PDF format can still be retrieved from the SANS Reading Room. If you have never visited the SANS Reading Room, I would strongly urge you to do so. There are many really great papers regarding a ridiculously wide-range of security topics. 

https://www.sans.org/reading-room/

If you are here simply to get a copy of the check_ioc.ps1 PowerShell script associated with the paper, you can find it at the Github link below. I’ve been told folks use the script as a standalone for incident response and based on that feedback, it helps them out. That’s great! There’s no reason you need to implement the beginning to end automated solution I describe in the solution to get some use from it. If you happen to think of other event IDs that should be added, by all means please let me know via Twitter and I will get them added. I’ve made a few minor updates to the PowerShell script since the original version. The most notable changes now include some points from Dave Kennedy (@hackingdave) on reliably detecting pass-the-hash and Jessica Payne (@jepayneMSFT) on event IDs indicating code has been loaded into the LSA or SAM that is watching for password changes. Including those folks does not mean they endorse this solution in any way, but rather I’m simply giving credit where credit is due and their work helped me. 

https://github.com/oneoffdallas/check_ioc

The original script and paper would not be possible without the inspiration and fantastic legwork by some very smart folks at the NSA. If this topic interests you I would highly recommend reading the Spotting the Adversary whitepaper, which is now in version 2. It is a great technical read for both red and blue teams in my opinion. Blue can learn what indicators they should be looking for while red can try to find ways to avoid “tripping” any potential indicators.

If you are unfamiliar with the Critical Security Controls, go download the latest version as well as the associated metrics at the Center for Internet Security website. I cannot say enough good things about the CSCs and I believe they should be the foundation of every security program regardless of organizational size. I cannot count the number of security conversations I’ve started  based solely on someone’s interest in the prioritization of  the CSCs.

Uncovering Indicators of Compromise (IoC)
Using PowerShell, Event Logs, and Nagios

Abstract

What security concerns keep you up at night? Is it pivoting, persistent access, the time to detect compromise, or one of a thousand other possibilities? What if you were told that without a doubt, you have tools at your disposal to periodically verify your security posture and you are not presently using them? Why spend more hours and more budget implementing a new product with new agents and new headaches that will not effectively reduce your workload or anxiety level? Even if you have commercial tools already monitoring your systems for security events, how do you know they are working? Is it even practical to use a customized PowerShell scripts/plugins, built-in event logs, and a traditional monitoring tool such as Nagios to monitor for indicators of compromise on Windows systems? In addition, you will be presented with some applied research as well as easy-to-follow guidelines you can integrate into your own environment(s).

1. Introduction

Your systems are talking, but are you listening? There are indicators of compromise (IoC) in standard “off the shelf” monitoring systems that may provide possible symptoms. The problem is none of them are absolute signs of malicious activity and they do not necessarily throw up alarms clearly stating, “You have been hacked.” For example, 1) a compromised system used to host cracked applications or even movies might fill up a drive partition, 2) uncommon programs taxing the system and causing uncommonly high CPU or memory usage, 3) hung applications or services crashing that previously hummed along for years without issue, 4) logs with numerous warnings and errors in recent history, or 5) unexpected system reboots. How many of us have seen or heard of administrators who simply expanded the drive space, added memory or processors, or simply restarted services rather than digging in to determine the root cause? Maybe the administrator did not have time or maybe they were tasked with keeping the systems up and running, i.e. they did not know what to look for beyond basic stability? Whatever the reasoning, the other key component in all of these scenarios is the system administrator must have the understanding of what normal is in order to determine what is abnormal. Furthermore, they must have previously setup monitoring for “ordinary” and understood the day-to-day nuances of the system rather than struggling to learn on the fly when any semblance of normal has been tossed out the window. Perhaps a system is writing an error to an event log every 5 minutes. Did it start displaying that behavior yesterday, a month ago, or since the day it was installed? The bottom line is the administrator must have knowledge of the system and know whether the currently exhibited behavior displayed by the system or application is normal.

There are a number of systems that provide standard monitoring metrics in a nice, neat, and concise package. It is important to understand that with some event correlation, many standard system baselines — CPU, memory, hard drive, errors/warnings — may very well point us in that direction. However, this is not going to be a discussion over the aforementioned possible indicators of compromise regardless of how invaluable they may be in a root cause investigation. I am going to dig into the act of monitoring for what are more often than not, absolute indicators of compromise. Although there will invariably be false positives if the environment or system is unknown, at the very least all of these suspect events should be investigated with a watchful eye. While this could be used as a standalone solution, this solution would likely better serve as a “checks and balances” detection solution. For example, how does one know Splunk is catching relevant logged events and alerting? It is fairly common practice to utilize a vulnerability scanning engine such as Nessus to double-check patch management or a WSUS implementation. Similarly, a monitoring system with a bit of tweaking can absolutely double-check for meaningful security events to assist in recognizing compromised systems. Also worth noting, this does not way eliminate or alleviate the need for centralized log management. In fact, log management and centralized collection actually yields benefits far beyond simply identifying the occurrence of an attack. While the techniques covered may determine if someone is trying to cover their tracks or set up a persistent backdoor, centralized log management allows the admin to see what activity took place prior to the log clears. In many cases, centralized logging will also help lead an incident handling team to the original entry point where the attacker gained access to the system(s). Last but not least, centralized log management may help significantly with event correlation between disparate systems. For example, a new Windows service was created on this server and then another, similar service was created on an unrelated server. Was there expected maintenance on those systems? Can one tie this activity back to a change control request? Is it malicious?

Before jumping into the monitoring system and accompanying script, there is one important question often asked… “Why not focus on mitigating the attacks rather than after the fact?” As today’s systems and networks grow more complex, it inevitably becomes more difficult to protect and defend them. Some would argue the sheer notion of attempting to prevent all attacks is an agonizing lesson in futility. “Prevention is ideal, but detection is a must.” This phrase has become a tenant of information security, but what does it mean? The best illustration of this concept in an easily explainable format may be found in a recent Mandiant Threat Report (Mandiant, 2015). Based on the data gathered across multiple industries, only 31% of breaches were detected internally. With only 31% detected internally, that means a staggering 69% of breach notifications were a result of external parties — the FBI, other companies, ISPs, auditors, etc. (Figure 1). In addition, the median time to detect compromise was over 200 days with the longest presence of compromise over 8 years (Figure 2). Clearly, preventing these breaches would have been preferred. However, early detection and appropriate countermeasures absolutely would have minimized the damage experienced by these organizations as well as limited the amount of sensitive data lost.

Figure 1: Breach Detection

figure1

Figure 2: Discovery Time

figure2

2. What is Nagios?

The monitoring tool I integrated my script and this general technique with is Nagios. This particular integration takes place with the Nagios XI server, although integrating with the Nagios Core product would work as well because the agent is available on both of them. According to the Nagios website, “Nagios is a powerful monitoring system that enables organizations to identify and resolve IT infrastructure problems before they affect critical business processes” (“About Nagios,” 2015). Nagios is essentially a way to monitor nearly every aspect of a computing environment.

Nagios is built on a client-server architecture. This architecture allows the Nagios server processes to communicate directly with the clients regardless of whether the interaction is passive or active. In some cases, the communication channel is an agent built-in to the system such as SNMP or even SSH. In these instances, no additional software is necessary and only minor configuration changes are needed to allow the flow of communication. Other times, a software agent must be installed to give the system administrator added functionality beyond the information standardly received from a native and/or “basic” client. The client may be a Linux system, a Windows server, a router, a switch, etc. Regardless of the means of communication, the Nagios server runs a user defined set of checks against the client system. These checks can vary wildly in their capability from simply pinging a host to testing VPN connectivity. Typically, Nagios and similar monitoring tools are utilized for testing the stability and overall performance of systems and networks. For example, on a standard server, Nagios might monitor for running services or processes, a lack of hard space (Figure 3), or too much CPU or memory usage. On a network device, it may monitor for interface link utilization and whether links are up or down. The types of devices Nagios can monitor and the level of monitoring is quite substantial; in fact, one could argue that depending on the skillset of the implementer, the device list and level of detail is endless.

Figure 3: Example Nagios Disk Usage

figure3

For the purpose of this paper, the Nagios NCPA agent is used exclusively. Even if one is familiar with Nagios, one may or may not be familiar with the NCPA agent as there are a number of agents available beyond even the base ones previously mentioned. So what is the NCPA agent? The acronym NCPA stands for Nagios Cross Platform Agent. The agent was designed to “maintain cross-platform servitude” and also as “an abstraction between the sysadmin and the system” (Introduction — NCPA). How the NCPA client fits into the Nagios architecture is represented in Figure 4. The NCPA script on the server calls the NCPA client, which in turn runs the individual desired checks on the system and returns the appropriate value(s). The original NCPA script call on the server specifies (whether by default or user-supplied parameters) whether a returned value is within tolerance. Going back to the graphical representation in Figure 3, if the disk usage is greater than 90%, the system might report back an error if it is above the defined threshold. In this case, since disk usage is less than 90%, the system would report back a status of “OK”.

Figure 4: Standard NCPA Agent

figure4

The NCPA agent was selected as a component of this security monitoring solution [over other possibilities] for a number of reasons. First and foremost, it is cross-platform as the acronym implies; it can be installed for Windows, Linux, and Macintosh with identical API calls. While cross-platform is not a necessary requirement for this security-focused integration, it is essential to a more holistic strategy in any environment. Second, all traffic to and from the NCPA client is encrypted. Once again, encryption is not necessarily a requirement for our needs, but rather a must for protecting both internal and external network data. Lastly, NCPA allows for easy integration of numerous scripting languages including Visual Basic, PowerShell, shell and many more. For this reason alone, NCPA is the perfect choice to mesh Nagios and any desired checks.

The script-friendliness of NCPA and the general flexibility of scripting really allow for limitless possibilities. Fortunately, integrating a custom script into Nagios via the NCPA agent is extremely straightforward. For example, to add a PowerShell script so NCPA can call it, simply place the script in the appropriate directory; on a standard Windows install, the full path for the plugins directory is %programfiles%\Nagios\NCPA\plugins. The addition of a PowerShell script into Nagios is a rather simple change to the overall NCPA design. In fact, the only real change (red box) is the addition of the script itself (Figure 5). Absolutely nothing more is required to get a script working on the client side. On the server side, simply configure the server check to call the name of the script, e.g. script.ps1. Those few, uncomplicated steps are how easy it is to get a PowerShell script working in Nagios. Though it will not be discussed further here, it is worth mentioning that after a script is verified as working, there are additional changes that can and should be made for enhanced security. For improved security, PowerShell script(s) should get signed and also have “-ExecutionPolicy Bypass” removed from the ncpa.cfg file, which is added by default. These two changes simply ensure no one can modify the script once it is in place and use a script for nefarious purposes.

Figure 5: NCPA Agent with PowerShell

figure5

3. Spotting the Adversary

Much of this work is based on a wonderfully concise whitepaper from the NSA titled, Spotting the Adversary with Windows Event Log Monitoring. According to the document author(s), “Windows includes monitoring and logging capabilities and logs data for many activities occurring within the operating system. The vast number of events which can be logged does not make it easy for an administrator to identify specific important events. This document defines a recommended set of events to collect and review on a frequent basis.” (National Security Agency, 2013). As one might expect, the whitepaper goes into a fair level of detail on various Windows events and even outlines the importance of why various events are significant. These events are easily discovered by searching for the specified event IDs within the Windows Event Viewer or even the XML filter query, which is built into every modern Windows installation. Although there is no need to re-hash the whitepaper in its entirety, the following is a quick rundown of some of the more advantageous checks assuming their usage and subsequent value in one’s environment.

3.1.   New Windows Services

Why is there a new service on that system? Is the new service related to new, authorized application someone forgot to perform change control on? Or is it a persistent backdoor? Windows Services are a great way to create persistence because the functionality is built-in to the operating system. One can easily add a new, “automatic” service from a command line in seconds so when the system is booted, the service and associated program are started. However, locating new services is as easy as searching for event ID 7045 in the System event log.

Searching for added services also provides a number of other benefits that might not be as obvious at first glance. The Sysinternals tool, psexec, creates a service and leaves the service behind after doing so. Of course it writes a log entry when it runs, but what about other means of exploitation? The Metasploit module also named psexec is a well-known means of pivoting in a Windows environment. Although the service is deleted immediately execution (Figure 6), the exploit still leaves a log entry when the service is initially created (Figure 7).

Figure 6: Metasploit psexec

figure6

Figure 7: Service Log Entry Created by Metasploit psexec  

figure7

3.2.   Windows Firewall Modifications

Even in the most basic form, host-based firewalls can point to possible issues. If the default Windows Firewall is utilized, one can easily check for event IDs 2004, 2005, and 2006/2033; those event IDs represent firewall rule adds, changes, and deletes respectively. Monitoring for these changes is vital to the overall integrity of a system. An attacker will often make modifications to allow persistent tools a means of inbound or outbound communication. Even if the Windows Firewall is turned off entirely or disabled for any single profile, an event is still logged (Figure 88).

Figure 8: Disabled Firewall

figure8

3.3.   Event Log Clears

Other event types worth monitoring are related to event log clears. To check for System log clears, look for event ID 104. Meanwhile, to check for Audit log event clears, instead look for event ID 1102. Also, clearing the Application log puts nothing in the actual Application event log. However, clearing the Application log does write an entry to the System log and this event ID was previously mentioned.

Granted, the act of log clearing may not always result from malicious intent, but it should be considered a non-standard event that warrants closer examination. When log clears are performed in conjunction with other events, it is obviously a great way for an attacker to cover their tracks. This is especially true in cases where previous “acts” included creating services, changing firewall rules, etc. In some cases, if a system is functioning on an island without log forwarding or any other outside communication, this singular event might be the only indication of a much larger issue.

There are several ways to clear out log files. How do they work and more importantly, will standard log monitoring detect them? Naturally, using the Windows native method of clearing event logs (Figure 9) is going to generate the event IDs described above. Event ID 104 is created as expected when clearing out the System log.

Figure 9: Standard Log Clear

figure9

What about some not-so-standard methods of clearing the event logs? Clearing the logs via PowerShell (Figure 10), WMIC (Figure 11), or even a non-Microsoft program like clearlogs.exe (Figure 12) all produced the same results. Regardless of what method was chosen, all of them wrote a “log clear” entry as expected.

Figure 10: PowerShell Log Clear Entry

figure10

Figure 11: WMIC Log Clear Entry

figure11

Figure 12: Clearlogs.exe Log Clear Entry

figure12

The list of significant events to possible look for based the NSA whitepaper is quite large and only a handful of them were covered in the examples above. In fact, there are a number of pertinent log events that may prove more useful than the ones described above depending on the environment. For example, what if an organization uses Microsoft EMET (Enhanced Mitigation Experience Toolkit) or Microsoft AppLocker? If so, there are event IDs specific to those applications. Would it be useful to know if an application was blocked by AppLocker? Maybe the blocks point to a malicious application trying to break out of the confines of AppLocker? What if a server that rarely, if ever, has applications installed (or removed) beyond Windows Updates? Then it is painless to search for the event IDs associated with new MSI installs, new application installs, or even anytime an application is updated or removed.

It is also important to note that some of the event log searches may yield false indicators. This goes back to the underlying importance of setting up monitoring when the system is “known good” rather than after thoughts of a possible compromise. For example, the queries specified in the NSA whitepaper for pass-the-hash events are somewhat incomplete. While both successful and failed pass-the-hash (PtH) events are detected (Figure 13), some Remote Desktop and RemoteApp events create identical PtH-identified events when tested in several production environments. My independently discovered false positives for PtH seem to coincide with a BlackHat paper from 2014 where the authors state, “Our conclusion after studying this data (and exploring a great many failed assertions) was that detecting the characteristics of stolen credentials in use requires context around typical behavior in an environment than simple rules-based alerting can provide” (Hathaway & Myers, 2014). Dave Kennedy performed some additional analysis of PtH and its relation to event ID 4624. He discovered the inclusion “Key Length: 0” significantly improved the detection of PtH (Kennedy, 2016). My testing in live environments discovered his findings to be true as it removed the extraneous false positives associated with RemoteApp and Remote Desktop.

How about searching for changes related to another persistent access favorite such as scheduled tasks? Scheduled are easily found (Figure 14), however, to avoid false positives the implementer will need to disable all jobs related to the Microsoft Windows Application Experience as well as the Customer Experience Improvement Program. If not, scheduled tasks modified throughout the day will generate false positives as the scheduled jobs run. How about account lockouts? If the number of “invalid password attempts to lockout” group policy is set low enough and a helpdesk already receives plenty of support calls about locked accounts, then it is strongly advised to make changes before relying on that particular metric as an unconditional indicator of compromise.

Figure 13: Successful PtH Log Entry

figure13

Figure 14: Scheduled Tasks Log Entry

figure14

4. Automate, Automate, Automate

While the work in the NSA whitepaper is superb, it would require a fleet of support personnel to painstakingly comb through all of the logs manually. Even if someone created and saved filters as custom views it would still be extremely tedious. What if this process could be automated? The possibility of automating these checks was the initial thought and foundation for the entire project. A secondary goal was the concept of using a tool traditionally meant for stability monitoring and re-tool it to monitor for security events. This, in essence, would combine the functionality of a NOC (network operations center) with the functionality of a SOC (security operations center). Is there really that much of a fundamental difference between an alert for a router link dropping and a system alert for the installation of a new or questionable service?

As it turns out, the act of combining the two was greatly simplified because of two important factors. As previously discussed, adding a PowerShell script to the Nagios NCPA client is trivial. As trivial as it may seem, without that capability, the project would have required a drastic course correction assuming it still would have been feasible from a time standpoint. Second, Microsoft has greatly enhanced the power of the command line with PowerShell. The functionality of PowerShell has expanded more and more over the years as it has transformed into its own, full-fledged scripting language with numerous native features. One of the built-in capabilities added in later versions is the “Get-WinEvent” cmdlet; this cmdlet allows for quickly searching and parsing the Windows event logs. With the number of filters used in the various queries, the Get-WinEvent cmdlet offers significant speed improvements over the Get-EventLog cmdlet (Berry, 2011). Get-WinEvent is actually enough of a gain in speed that during testing, the usage of Get-EventLog would not even have been sufficient to return values back to Nagios in a timely fashion.

So the goal was to create an easy-to-use, security-driven PowerShell script that anyone could read through and make modifications to with the eventual goal of Nagios integration for the purpose of automation. The script was named “check_ioc.ps1” to fall in line with the general naming convention of Nagios scripts and those found on Nagios Exchange. Throughout its design, the NSA whitepaper was heavily referenced. In fact, even the “selectable” options in the script point back to the corresponding section in the NSA whitepaper. For example, the option to enable checks for successful pass-the-hash events is aptly named “SuccessfulPtHCheck.” Shortly after the variable is set for the check (0 for disable or 1 for enable) there is a “4.15” reference in the comments (Figure 15); furthermore, going back to the NSA whitepaper, section 4.15 is titled “Pass the Hash Detection.” This allows the implementer to easily reference additional documentation for details about a check if necessary. In addition, other than a few exceptions, all of the event IDs discussed in the NSA whitepaper are available in the check_ioc.ps1 PowerShell script as a selectable option.

Figure 15: Successful Pass-The-Hash Check

figure15

5. Mapping Controls to Script Checks

The Critical Security Controls are a well-known methodology for prioritizing various components of security maintained by the Center for Internet Security. At the time of this paper, the Critical Security Controls are at version 6. The purpose of the Critical Security Controls is to “focus on the most fundamental and valuable actions that every organization should take” (Center for Internet Security, 2015). While not all of the checks from the check_ioc script translate to a specific control, a significant number of them do. In fact, many of the checks discussed in the NSA whitepaper and implemented in the PowerShell script have a direct relationship to the Critical Security Controls (Table 1). In a quick rundown of the controls, one could easily argue a minimum of seven Critical Security Controls are either bolstered or nearly satisfied by implementing the script and various “checks” in an environment.

Table 1: Critical Security Controls Relationships

CSC Title Relevant checks
2 Inventory of Authorized and Unauthorized Software AppLockerBlockCheck

AppLockerWarningCheck

MSIInstallCheck

AppInstallCheck

5 Controlled Use of Administrative Privileges UserAddPrivGroupCheck

SecEnabledGroupModCheck

6 Maintenance, Monitoring, and Analysis of Audit Logs Overall
8 Malware Defenses EMETCheck

Various Kernel Driver Signing Checks

Various Persistence Checks

9 Limitation and Control of Network Ports FirewallRuleModCheck
16 Account Monitoring and Control FailedUserAccountLoginCheck

AccountLockoutCheck

19 Incident Response and Management Overall

 

5.1.   Critical Security Control #2 – Software Inventory

Critical Security Control #2 handles the inventory of authorized and unauthorized software. The control specifically mentions application whitelisting and monitoring for the installation of unauthorized software. AppLocker is an application whitelisting technology developed by Microsoft and if implemented, writes event log entries whenever a warning or block occurs. Why is this important? Similar to monitoring or auditing access log files for user login attempts, what does the last failed entry mean? Does the last failed entry mean the attacker gave up trying to access the system? Or does it mean they were successful in their very next attempt, i.e. no point into continuing to try if access was gained? In the same manner, a successful bypass of application whitelisting technology is often preceded by at least one or more failed attempts. For this reason alone, failed or blocked application executions should be monitored closely. It is also worth noting that other industry leading application whitelisting technologies such as those provided by Bit9 write to the event logs as well. As a result, checks for Bit9 or any other technology could easily be added to the PowerShell script for the purpose of automation in lieu of using AppLocker (and related checks).

To further assist with software inventory, why not look for new application installs? On a deployed and stable server, it is normal to see a new application installed on a regular basis? Granted, this check alone will not detect every application executed, however, it will quickly and easily find any new applications installed. Going back to the point made on another check, at the very least a new application install [and alert] should merit an additional level of scrutiny. The relevant check_ioc configuration variable for testing this is called AppInstallCheck. On Windows 8 and newer systems, the MSIInstallCheck variable should be used instead as the event IDs associated with AppInstallCheck have been removed.

5.2.   Critical Security Controls #5 and #16 – User Accounts

Multiple controls reference user accounts, user account privileges, and administrative groups. Critical Security Control #5 deals specifically with the limitation of administrative privileges while Critical Security Control #16 is focused account monitoring and control. By limiting administrative privileges, one can often slow down or thwart attackers and malware alike from escalating and performing additional damage. In many cases, a limited user account (non-admin) can mitigate an attack entirely by itself. Therefore, any changes to privileges or additional privileges should be monitored as it could be the sign of a malicious attack. At the very least, it is a way to prevent a future attack. The UserAddPrivGroupCheck tests for any user additions to privileged groups at the active directory level while the SecEnabledGroupModCheck test checks for somewhat similar functionality at the local, system level.

Critical Security Control #16 handles accounts monitoring and control. While the necessary registry or group policy changes must be made before the script is even capable of monitoring, it can assist tremendously after doing so. For example, assume user account lockouts are configured to lockout the user for 15 minutes after 25 failed attempts. Is a normal user going to fail logging in 25 times in a row? Stereotypically, the only instance this might occur is if a client (such as an email client) is set to login automatically and the end user recently changed their password. Despite the possibility for the occasional false positive, receiving an alert for a locked account is essential to the Critical Security Controls as well as the security of any environment. But what happens in the same scenario with an attacker using password spraying techniques, i.e. they are only attempting 20 password attempts at a time on each of the 500 users in the environment? In this example, the account lockout would never trigger if there is enough time in between subsequent rounds of attempts on any particular user. For this reason, there is a separate check called FailedUserAccountLoginCheck. The corresponding variable to this check is FailedUserAcctThreshold and it requires some knowledge of the various systems in order to be “sized” appropriately. Maybe an environment never sees more than 100 failed user account logins for the specified time period? By setting the threshold variable to 100, the prior example would have triggered an alert because it resulted in 1000 total failed attempts (500 users X 20 password attempts).

5.3.   Critical Security Control #8 – Malware

Malware defenses appear in Critical Security Control #8. The use of Enhanced Mitigation Experience Toolkit (EMET) is characterized as a “Quick Win” in the Critical Security Controls under section 8-4 (Center for Internet Security, 2015). Furthermore, checking the Windows event logs for EMET related entries can help identify possible spear phishing attempts as well as other exploits successfully mitigated by the toolkit. A number of checks in the check_ioc script test for Kernel driver signing. These are also used to detect malicious or malware activity. Any alteration of a kernel driver should prompt immediate follow-up as this is non-standard behavior and is likely an indication of compromise.

The next step after successful exploitation for any attacker or malware is typically directed at gaining persistence. Why go through the trouble of getting entry to a system only to have someone reboot it and all of the prior work to be lost? Persistence is the foothold that allows the attacker continued access to a system after successive reboots or when any other changes are made. Fortunately, there are a limited number of ways attackers (or malware) typically maintain control of a system. As described earlier, if persistence is achieved through the creation of a new service, a log entry is written and subsequently checked for by the script. Several registry keys are often modified as a way to have a malicious application automatically start each time during boot or logon. With a few changes (described in the next section), one can easily keep an eye on the registry keys in question. Last but not least, malicious applications will often write an entry to any number of standard file locations so Windows auto-starts the application on boot or logon. Much in the way registry keys can be monitored for changes, files and folders can go through a similar process, which is built into the check_ioc script.

5.4.   Critical Security Control #9 – Network Ports

The limitation and control of network ports, protocols, and services is included in Critical Security Control #9. This control discusses the need for host-based firewalls and the necessity for said firewall to drop any traffic that is not explicitly allowed (Center for Internet Security, 2015). While the built-in Windows Firewall does not default to deny outbound traffic, it does explicitly deny all inbound traffic when it is enabled. In addition, the behavior for outbound traffic can be altered rather easily with readily available documentation. After the required changes are made to deny outbound communication, firewall modifications are absolutely essential to allow communication on any port or program not already allowed. Any changes then become simple to identify because Microsoft logs all additions, modifications, or deletions of Windows Firewall rules to the event viewer. The FirewallRuleModCheck in the check_ioc script tests for any firewall related changes to the system.

5.5.   Critical Security Controls #6 and #19 – Overall

The final two controls covered by the implementation of the check_ioc script are #6 and #19. Critical Security Control #6 is the maintenance, monitoring, and analysis of audit logs, which is the fundamental basis for the script. In fact, one could argue the script improves on some of the control recommendations because it automates a fair amount of searching for anomalies. While the solution is not an all-encompassing log review of every device, any level of automation should be welcomed and viewed as a step toward improvement. Last but not least, incident response and management is represented in Critical Security Control #19. While the automated solution does not lend itself to incident response whatsoever, the script may be used as a quick and easy tool for the incident response team to determine what changed on any previously unmonitored system.

6. Getting Started and Implementation

Before going any further, we will need to do a little housekeeping to ensure the data we are looking for is written to the event logs. Several of the IoC checks require audit policies enabled on the monitored machine in order to work properly. To modify these policies for a local machine, follow the steps below.

  • Click Start, click Run, type “gpedit.msc” and hit Enter
  • On the left hand side, navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy
  • On the right hand side, double-click “Audit logon events”
  • Place a check-box in the “Success” and “Failure” boxes and click “OK” (Figure 168)
  • On the right-hand side, double-click “Audit object access”
  • Place a check-box in the “Success” and “Failure” boxes and click “OK” (Figure 179)
Figure 16: Audit Logon Events

figure16

Figure 17: Audit Object Access

figure17

These changes add numerous security related events to the Windows Event Logs. For more details on what the changes made here specifically entail, please refer to their respective section in the Appendix for additional information from Microsoft.

If the audit object access is enable to allow for monitoring files or registry keys, some secondary settings must be configured as well. A common attack method for gaining a permanent foothold into a system is adding a persistent backdoor via one of the standard startup registry keys specified by Microsoft (Understand and Control…). To monitor these for changes, the implementer will need to follow the steps below for each of the “Standard Persistent Registry Key” entries found in the Appendix.

  • Click Start, click Run, type “regedit” and hit Enter
  • Navigate to the key, right-click on it and go to Permissions”
  • Click on “Advanced” (Figure 188)
  • Go to the “Auditing” tab and click “Add” (Figure 18)
  • Select “Everyone” as the principal and change “Type” to “All” (Figure 19)
  • Change the “Advanced permissions” as seen in Figure 199
  • Click “OK” multiple times to get back to the base Registry Editor screen

Figure 18: Changing Registry Key Audit Level (1 of 2)

figure18

Figure 19: Changing Registry Key Audit Level (2 of 2)

figure19

With the Windows housekeeping out of the way, we can move onto the PowerShell script itself. The script is freely downloadable on GitHub. It is now open source software distributed under the GPL licensing structure. The easiest method to get the file for usage is by simply going to the link below and then clicking on the check_ioc.ps1 file listed there.

https://github.com/oneoffdallas/check_ioc

Once the file is downloaded, open it using the text editor of choice. There are quite a few “selectable” options in the PowerShell script and it is important to remember to reference the NSA whitepaper if any additional information is needed on a particular check. Although it may take a little extra time during implementation, it is highly recommended all options are scrutinized to determine which ones make sense in the chosen environment; investing time during the setup phase will absolutely save time later and it will also help familiarity with the various options. The latter option will also provide value if and when there are changes in the environment. For example, although the environment may not have AppLocker currently configured, what about a year from now when it is rolled out company-wide? Keep in mind, several indicators are enabled out of the box to begin with. However, that should not prevent the implementer from enabling/disabling as appropriate to match the specific needs of a specific environment. Once completed, simply save the file.

Once all of the necessary changes are made, the script is ready for execution. It should initially run from the command line to ensure it works as expected before integrating it with Nagios or another monitoring engine. One can also easily specify a longer “check” timeframe at the command line to identify if false positives exist and eliminate them. If the script is run without any modifications (and it does not trigger any alerts), the output should look similar to the following:

PS > .\check_ioc.ps1
OK: SuccessfulPtH:0 FailedPtH:0 LogClear:0 FirewallRuleMod:0 ServiceAdd:0 FailedUserAcctLogin below threshold:0 InvalidImageHashFile:0 InvalidPageHashFile:0 FailedKernelDriver:0 RegKeyMod:0 in the last 30 minutes

So what does the output mean? By default, the script is checking for Windows event log entries in the last 30 minutes related to 1) successful pass-the-hash, 2) failed pass-the-hash, 3) event log clears, 4) Windows firewall rule modifications, 5) added Windows services, 6) failed user account logins above a specified threshold, 7) invalid image hash files, 8) invalid page hash files, 9) failed kernel drivers, and 10) registry key modifications on configured keys. In this example, all of the checks came back with values of 0 so an alert was not triggered and instead a value of “OK” was returned.

Once the client-side configuration is complete, the only remaining configuration is on the server side of Nagios. If the NCPA python script (check_ncpa.py) is already downloaded and the Nagios command is working on the server, the next step is to configure the host service check. In the case of Nagios XI, the following line should be copied to the $ARG1$ text box.

-t ‘<token>’ -P <port number> -M ‘agent/plugin/check_ioc.ps1/<ArgLastMinutes>’

This is located within the Core Config Manager under the individual service and the “Service Management” section. Obviously, the token, port number, and ArgLastMinutes should all be filled in with the appropriate values for an environment. The full command-line when re-configuring the service from the main interface will look similar to the following assuming the check command “check_xi_ncpa_agent” is aliased to “$USER1$/check_ncpa.py -H $HOSTADDRESS$ $ARG1$”.

check_xi_ncpa_agent!-t ‘mytoken’ -P 5693 -M ‘agent/plugin/check_ioc.ps1/30’

The “-M” is the path to the script on the client with the main application directory as the working directory. If any issues are discovered at this point, it is worth mentioning the setup can easily get tested via any browser using a string such as https://<HostIPAddress>:5693/api/agent/plugin/check_ioc.ps1/30 and manually inputting the authentication token.

After saving the configuration changes, the next time the newly installed indicators of compromise service check runs, it will provide a service detail view similar to Figure 20. What happens if someone triggers an IoC such as clearing the security log? If any of the indicators are triggered, a critical error is placed on the screen (Figure 21). In addition, the actual log entry is recorded below it. This allows for a quick view of the event log viewer and what caused the alarm without actually logging into the server. Also, depending on how the Nagios server is configured, any number of emails, SMS messages, etc. might be sent to alert someone regarding the issue.

Figure 20: Nagios – No IoC

figure20

Figure 21: Nagios – IoC (Log Clear)

figure21

7. Conclusion

Doing security well has become increasingly difficult as our environments continue to grow more complex. At the same time, the desire to be connected has never been greater than it is now. As a result, breaches will continue to happen. The next evolution in security must be the realization that prevention is not the only need in a good security plan. While prevention should continue to receive a majority of our focus, supplying little to no resources to detection can only be described as poor planning. By monitoring our internal networks for known attack vectors or methods of persistence an attacker might utilize, we can begin to swing the pendulum back to the side of the defense and continue improving the resiliency of our networks.

The Critical Security Controls should be referenced regardless of the size of an organization. They can serve as a basis for any security program in any industry. While the controls are far from perfect, they can significantly enhance the security of any environment when properly consulted and followed. Although the check_ioc script and interrelated infrastructure only cover a small subset of the Critical Security Controls and security measures necessary to keep information secure, it can greatly improve security when customized appropriately for an organization.

Is there a need for yet another security tool such as check_ioc? Often times, more products and complexity are part of the problem rather than part of the answer. Many organizations have SIEM solutions, next generation firewalls, and numerous other security products already in place, yet they continue to experience breaches. If the solutions are not the issue, then maybe the problem is shaping those solutions to meet the needs of our environments. More importantly, why not integrate existing solutions into our networks and use existing tools wherever possible? That is why the check_ioc script was needed and developed. It was designed as a simple, yet effective tool to assist network defenders in detecting indicators of compromise using products many organizations already have in place. Is the check_ioc script meant to eliminate existing tools? Perhaps it could, but not necessarily. Instead, it was meant as another layer in the defense-in-depth approach, which is mandatory for the sustainability and security of any organization in the network age.

References

About Nagios. Retrieved May 3, 2015, from http://www.nagios.org/about

Berry, M. (2011, April 1). PowerShell: Get-WinEvent vs. Get-EventLog. Retrieved July 1, 2015, from http://www.mcbsys.com/blog/2011/04/powershell-get-winevent-vs-get-eventlog/

Center for Internet Security. (October 2015). The Critical Security Controls for Effective Cyber Defense: Version 6.0. Retrieved from http://www.cisecurity.org/critical-controls.cfm

Hathaway, M., & Myers, J. (August 2014). Black Hat USA 2014: Why You Need to Detect More Than PtH. Retrieved from https://www.blackhat.com/docs/us-14/materials/us-14-Hathaway-Why-You-Need-To-Detect-More-Than-PtH-WP.pdf

Introduction — NCPA 1.8.0 documentation. (n.d.). Retrieved from             https://assets.nagios.com/downloads/ncpa/docs/html/introduction.html#what-is-ncpa

Kennedy, Dave. (October 2016). Reliably Detecting Pass the Hash Through Event Log Analysis. Retrieved from https://www.binarydefense.com/bds/reliably-detecting-pass-the-hash-through-event-log-analysis

Mandiant. Mandiant M-Trends: A View From The Front Lines. (n.d.). Retrieved from
https://www2.fireeye.com/rs/fireye/images/rpt-m-trends-2015.pdf

National Security Agency. (2013, December 16). Spotting the Adversary with Windows Event Log Monitoring. Retrieved from https://www.nsa.gov/ia/_files/app/spotting_the_adversary_with_windows_event_log_monitoring.pdf

Understand and Control Startup Apps with the System Configuration Utility. (n.d.). Retrieved    from https://technet.microsoft.com/en-us/magazine/ee851671.aspx

Windows Security Log Encyclopedia. (n.d.). Retrieved from             https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/Default.aspx

Appendix

Audit logon events

This security setting determines whether the OS audits each instance of a user attempting to log on to or to log off to this computer.

Log off events are generated whenever a logged on user account’s logon session is terminated. If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).

Default values on Client editions:
Logon: Success
Logoff: Success
Account Lockout: Success
IPsec Main Mode: No Auditing
IPsec Quick Mode: No Auditing
IPsec Extended Mode: No Auditing
Special Logon: Success
Other Logon/Logoff Events: No Auditing
Network Policy Server: Success, Failure

Default values on Server editions:
Logon: Success, Failure
Logoff: Success
Account Lockout: Success
IPsec Main Mode: No Auditing
IPsec Quick Mode: No Auditing
IPsec Extended Mode: No Auditing
Special Logon: Success
Other Logon/Logoff Events: No Auditing
Network Policy Server: Success, Failure

Important: For more control over auditing policies, use the settings in the Advanced Audit Policy Configuration node. For more information about Advanced Audit Policy Configuration, see http://go.microsoft.com/fwlink/?LinkId=140969.

Audit object access

This security setting determines whether the OS audits user attempts to access non-Active Directory objects. Audit is only generated for objects that have system access control lists (SACL) specified, and only if the type of access requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.

The administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).

If Success auditing is enabled, an audit entry is generated each time any account successfully accesses a non-Directory object that has a matching SACL specified.

If Failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a non-Directory object that has a matching SACL specified.

Note that you can set a SACL on a file system object using the Security tab in that object’s Properties dialog box.

Default: No auditing.

Important: For more control over auditing policies, use the settings in the Advanced Audit Policy Configuration node. For more information about Advanced Audit Policy Configuration, see http://go.microsoft.com/fwlink/?LinkId=140969.

Standard Persistent Registry Keys
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
* RunonceEx keys no longer exist in Vista and later OSes

Stop CEO/CFO Domain Spear Phishing

Pretty bold title… While it is nearly impossible to stop any motivated attacker/phisher, I also believe in doing every bit you can to improve your environment and these steps will go a long way to helping your situation. I will talk about two primary ways to put an end to CEO/CFO spear phishing. Realize upfront that you should not do one step without the other. I will also talk about the ins and outs of these techniques as well as some of the remaining phishing issues that you would need to still be wary of.

The CEO/CFO spear phishing scheme has seen another significant uptick and there’s a good likelihood they are going to continue increasing in numbers.
Even Brian Krebs raised awareness as early as August 2015 to this growing trend.
https://krebsonsecurity.com/2015/08/fbi-1-2b-lost-to-business-email-scams/

Brian then followed it up in April 2016 with a report about how $2.3 billion (yes, with a ‘B’) have been lost to CEO email scams.
https://krebsonsecurity.com/2016/04/fbi-2-3-billion-lost-to-ceo-email-scams/

Suffice to say that if Brian is writing about it, it is a huge problem and he is usually a little ahead of the curve!

Most solutions come from necessity and this one is no different. The “novel” 2nd solution hit me after what could have been a disastrous event. I honestly can’t say I’ve ever seen anyone mention it and it’s so simple that after you read about it, you’ll wonder why not. Anyway, a customer was sent a single spear phish email from a homoglyph domain. A homoglyph is a character or character combination that look similar. For example, the number ‘1’ looks like the letter ‘l’, 2 consecutive of the letter ‘v’ look like a ‘w’ in many fonts, ‘r’ followed by ‘n’ looks like an ‘m’, etc. Suffice to say, a homoglyph domain has absolutely no purpose on this earth except for sending phishing emails.

Fortunately, the customer recognized the spear phish and alerted us so we could look into it (break out the happy dance). Within minutes of running a whois on the new domain, I easily found it was a Vista Print created domain with Tucows acting as the registrar. I then looked at the Vista Print website and found exactly what I suspected. Right on the page you can sign-up for a free, 30-day trial domain name and domain hosting account. Barrier to entry… zero. What’s the worse that can happen?

I sent the tweet above and to my surprise, both companies replied rather quickly. I sent them both DMs explaining what I found and I waited… and waited… and waited… As of several weeks later, still nothing. At the same time, I also sent an email to domainabuse@ for Tucows and they responded 8 days later that it wasn’t their domain; of course, in their reply email they clearly show they are checking the whois for the actual domain rather than the homoglyph-ed domain. <SMH> Either their support didn’t see the homoglyph themselves when re-typing it or they grabbed the first domain in the email they saw even though if they actually read the email, they would have seen I said the bad guys were copying domain XYZ. Regardless, still nothing more from that front either…

Update: I still haven’t heard anything from either one, but I’ve seen multiple reports across the internet that they have cleaned up their act and closed this apparent “loophole.” I would like to think I might have had something to do with this, but probably not! 😉

It was pretty clear early on I wasn’t going to get any help from them. Still, the underlying issue was even if they shut the domain (or free account) down, what about the next spear phish domain created by the crooks? I wanted something that was going to provide some level of protection and I didn’t care if it was a homoglyph, character substitution, character omission, etc. Was I doing everything I could to stop this type of attack? I quickly discovered the answer was ‘no.’ I’ll go into two separate techniques that you need to employ today in order to combat this issue before you and your organization fall victim. The good news is that it doesn’t take long to implement both and both solutions cost absolutely nothing other than time to implement. In fact, if you are familiar with many of the technologies and your environment, you can likely have both solutions up and going within 30 minutes.


#1 – Sender Policy Framework (SPF)

If you know what SPF is and you are using it, congratulations! Skip ahead to #2. If you are not sure, skip ahead to the section below on “Testing for SPF.”

What is SPF? Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain’s administrators. [1]

There are tons of resources on SPF that describe what it is so I’m not going to re-hash it. Worth mentioning is that SPF not only prevents others from spear phishing you, it also prevents someone from spoofing your domain and damaging your reputation so it really is a win-win.

http://www.openspf.org/Introduction

I’m also not going to get into the individual configuration of devices for SPF because that would be a book, not a blog post. Suffice to say, you need to have an anti-spam server, firewall, or mail server that respects SPF. Contact your vendor to find out for sure if you don’t know.

At a high level, you are going to create a TXT DNS record and that entry is going to get referenced by other spam servers (including your own) when the mail is received. When an email is received, the anti-spam server (or firewall or mail server) checks the SPF record and determines whether the originating IP address or host name is “valid.” This is best shown in the image below.

Image from dmarc.org

Creating the SPF Record

There are many ways to figure out how to use this and determine the formulation of the TXT string you should use, but by far the easiest is to use SPF Wizard at the site below. The site does a great job explaining what each individual item means and it also walks you through building the TXT record.

https://www.spfwizard.net/

I would argue the SPF below (substitute your domain of course) would probably work for most setups.

linuxincluded.com.  IN TXT “v=spf1 mx a -all”

You absolutely need to double and triple-check this. If you get it wrong, it will likely result in valid emails getting rejected! If you have another IP address or hostname that send mail on your behalf, you will need to add them to this line as well. Also keep in mind that if those IP addresses or hostnames ever change, you would need to change it in the TXT record.

If your hosting provider uses cPanel, follow the few steps below and you will be in business.

1) Go to “Advanced DNS Zone Editor”

advanced
2) Add the information you created in the prior step(s) and click “add record.

advanced3

Assuming you did everything correct, your new TXT record will show up at the bottom of the zone file records section.

If you use some sort of graphical interface for your DNS such as GoDaddy, Wix, etc. please refer to their support on how to add a custom TXT entry. In most cases, you need to create a TXT record for your domain and add *just* the line below. It’s worth mentioning that some systems will require the beginning and ending double quotes while others do not. That is the importance of testing!

“v=spf1 mx a -all”

Testing the SPF Record

In my experience, your SPF records will start showing up within 10 minutes if they are newly created. This is perfect as it will give you an opportunity to check it for correctness before emails are potentially blocked.

Windows Command Line Testing

If you open a command prompt in Windows, type the following commands to test whether your newly added SPF record is there. Red is what you will need to type while blue is what you should expect back if it is working. In this example, I’m testing against Google’s public DNS server at 8.8.8.8.

C:\Users\Dallas>nslookup
Address: 192.168.1.1> server 8.8.8.8Default Server: google-public-dns-a.google.com
Address: 8.8.8.8> set type=txt
> linuxincluded.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8Non-authoritative answer:
linuxincluded.com text =“v=spf1 mx a -all”

As you can see, the proper SPF record comes back. If you didn’t receive anything, either a) your DNS didn’t propagate yet or you have something wrong.

Linux Command Line Testing

Open a command prompt in Linux, type the following commands to test whether your newly added SPF record is there. Again, red is what you will need to type while blue is what you should expect back if it is working. In this example, I’m testing against Google’s public DNS server at 8.8.8.8 again.

dallas@deb:~# dig linuxincluded.com TXT @8.8.8.8

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> linuxincluded.com TXT @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57732
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;linuxincluded.com. IN TXT

;; ANSWER SECTION:
linuxincluded.com. 14399 IN TXT “v=spf1 mx a -all”

;; Query time: 78 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 18 19:55:42 CDT 2016
;; MSG SIZE rcvd: 75

Other Testing Methods

If you’re not a command line person, you can also test via some websites and they work very well too. They also evaluate whether your SPF records are formatted properly, which your eyeball test on the TXT records from the command line might overlook. I’ve included a couple of free sites that do this service as well as many more.

https://mxtoolbox.com/NetworkTools.aspx – Simply type in your domain next to the SPF box

http://www.kitterman.com/spf/validate.html? – Not as pretty, but same concept and it does the trick


#2 – Blacklisting

So you understand SPF, but you wanted something more? You want to protect against the previously mentioned absolutely evil domains, i.e. the type that use character substitution, character omissions, homoglyphs, etc. Blacklisting often gets a bad wrap because it often doesn’t go far enough to block the bad guys (and I would mostly agree), but this is an example where blacklisting works perfectly.

If you have a place to enter blacklisted domains on your mail server, firewall, or anti-spam server, then you are in business because that is all you need! But what can you use to create your blacklist? No reason to dream them up yourself… Instead, create your blacklist with a tool that comes by default on Kali Linux called URLCrazy. The tool is also available on Github (link below) if you don’t have access to a Kali system or your current Linux distro doesn’t have it in the repository.

https://github.com/Eisler/URLCrazy

Open a command prompt in Linux, type the following commands to output which domains are similar to yours. As you can see, the linuxincluded.com domain has a total of 184 variations. Ouch! That’s a lot of potential for spear phishing! Make sure you look through the domain names and their aren’t any that you use and/or you may potentially communicate with. I would say the mostly likely example is if you own both a .com version of your domain as well as the .net version.

dallas@deb:~# urlcrazy linuxincluded.com

URLCrazy Domain Report
Domain : linuxincluded.com
Keyboard : qwerty
At : 2016-04-18 20:35:00 -0500

# Please wait. 184 hostnames to process

Typo Type Typo DNS-A CC-A DNS-MX Extn
———————————————————————————————-
Character Omission linuincluded.com ? com

Character Repeat llinuxincluded.com ? com

Character Swap ilnuxincluded.com ? com

Homoglyphs 1inuxinc1uded.com ? com
Homoglyphs 1inuxincluded.com ? com
Homoglyphs linuxinc1uded.com ? com
Homoglyphs linuxincluclecl.com ? com
Homoglyphs linuxinclucled.com ? com
Homoglyphs linuxincludecl.com ? com
Homoglyphs linuxinduded.com ? com
Homoglyphs linuxlncluded.com ? com
Homoglyphs llnuxincluded.com ? com
Homoglyphs llnuxlncluded.com ? com

Interested in getting a little cleaner list of domains that you can copy/paste into your blacklist? With a few options and our friend cut and tail, you can get a rather nicely formatted output.

dallas@deb:~# urlcrazy –format=CSV linuxincluded.com | cut -d’,’ -f2 |tail -n +2

linuincluded.com
linuxicluded.com
linuxinclded.com
linuxincludd.com
linuxinclude.com
linuxincluded.cm
linuxinclued.com
linuxincuded.com

Last but not least, if you happen to have a system that has somewhat of an odd duck format, not a problem. Just add sed followed by a ^ and the string to insert. For example, one particular system I’m familiar with requires the text “blacklist_from *@” (minus the quotes) before each individual domain name. Note the red text should all be on one line in order to work properly!

dallas@deb:~# urlcrazy –format=CSV linuxincluded.com | cut -d’,’ -f2 |tail -n +2 | sed ‘s/^/blacklist_from *@/’

blacklist_from *@linuincluded.com
blacklist_from *@linuxicluded.com
blacklist_from *@linuxinclded.com
blacklist_from *@linuxincludd.com
blacklist_from *@linuxinclude.com
blacklist_from *@linuxincluded.cm
blacklist_from *@linuxinclued.com
blacklist_from *@linuxincuded.com

That’s it! Easy as pie!

Other Types of Phishing

Obviously, the only phishing attacks that were covered above were ones that specifically used your domain name or ones that used variations of your domain name. I would be remiss to not mention other types of phishing. What I mean by this is none of the techniques above will stop an email from [yourorganization]@gmail.com, [yourhelpdesk]@hotmail.com, or the millions of other possibilities — fake UPS, FedEx, etc. For those types, nothing beats a healthy security awareness plan and making sure your users know the difference.

Next Steps And Additional Thoughts?

As with anything, the techniques are not perfect and you could do more if you choose to do so.

The first thought one might consider is the “newness” of the domain. As you might have guessed, the domain from the example above was just a day old when the spear phish email was sent. If the anti-spam system had a “newness” test it would have likely caught it. But what if the spear phish was highly targeted and the attackers decided to sit on the domain for a few days, a few weeks, or even a few months? Would the “newness” check have worked? What if a similar domain name expired and the attacker just backordered that domain which was originally registered in 1999?

Second, these techniques do end the ridiculousness of having to purchase 10+ like domains for fear of getting spear phished by one of them, which is a recommendation I’ve heard at least once… maybe the person worked for a domain registrar? 😉 That being said, I would still strongly suggest buying similar domains where mis-types might land your customer on a competitor’s page. A mis-typed domain URL similar to gooogle.com (with the extra ‘0’) comes to mind.

Finally, you’ve added the 100 or so domain name variations generated from your domain name as specified above. Now, do you have a way to receive notifications when your anti-spam server blocks an email from one of those domains? This could prove to be ridiculously useful if you start seeing multiple emails come in from those domains because it would give you an opportunity to raise awareness across your organization. It’s like seeing the enemy congregate at the gates before the real attack! Security awareness FTW… again!

[1] https://en.wikipedia.org/wiki/Sender_Policy_Framework
[
2] https://dmarc.org/2015/07/email-authentication-basics-slide-deck-now-available/