Counter spear-phishing with DMARC mitigation methods

As adversaries, like the North Korean state-backed hacker group Kimsuky, continue to evolve their tactics and techniques, organizations must use proactive measures like DMARC mitigation measures to reduce the risk of falling victim to email spoofing, phishing attacks, and other malicious activities, ultimately safeguarding their digital assets.

What is spear-phishing?

CrowdStrike defines spear-phishing as “a type of phishing attack that targets specific individuals or organizations typically through malicious emails”, to steal sensitive information like login credentials or infect the targets’ device with malware.

Unlike traditional phishing attacks that “cast a wide net in hopes of luring any unsuspecting victims”, spear phishing campaigns are crafted to appear legitimate and personalized, often using information from social engineering and reconnaissance.

How do spear-phishing attacks work?

CrowdStrike explains “Spear-phishing emails, texts, or phone calls are highly personalized for a specific organization or individual.” 

So, email-based spear-phishing attacks often involve research on the target to make the email seem even more convincing. “Many people let their guard down because of the personalized messages and don’t think twice before clicking on a link or downloading an attachment. However, this mistake can lead to serious consequences such as stolen personal information or a malware infection,” CrowdStrike continues.

More specifically, “a spear phishing email uses social engineering techniques to urge the victim to click on a malicious link or attachment…” and once the victim “completes the intended action, the attacker can steal the credentials of a targeted legitimate user and enter a network undetected.”

Social engineering in spear-phishing

IBM explains, “Social engineering attacks manipulate people into sharing information that they shouldn’t share, downloading software that they shouldn’t download, visiting websites they shouldn’t visit, sending money to criminals, or making other mistakes that compromise their personal or organizational security.”

Examples include, “An email that seems to be from a trusted coworker requesting sensitive information, [like] personal data or financial information, including login credentials, credit card numbers, bank account numbers, and Social Security numbers.”

Social engineering is also called ‘human hacking’ since it “uses psychological manipulation and exploits human error or weakness rather than technical or digital system vulnerabilities,” IBM further explains.

Reconnaissance in spear-phishing

“In the context of cybersecurity, reconnaissance is the practice of covertly discovering and collecting information about a system,” Blumira explains.

While reconnaissance (also known as ‘recon’) is used in ethical hacking or penetration testing, hackers also use reconnaissance methods in their research to increase the likelihood of a successful attack. 

According to Blumira, recon “generally follows seven steps:

• Collect initial information
• Determine the network range
• Identify active machines
• Find access points and open ports 
• Fingerprint the operating system
• Discover services on ports
• Map the network

Using these steps, an attacker will aim to gain the following information about a network:

• File permissions
• Running network services
• OS platform
• Trust relationships
• User account information”

Examples of using recon in spear-phishing

Open Source Intelligence (OSINT): Hackers can use information publicly available through sources like social media platforms, company websites, news articles, and public databases to gather intelligence about their target. For example, a hacker could “use Facebook and LinkedIn to gather personal information about their target… [and] map out their target’s network of personal contacts, which gives them more context to crafting a trustworthy message,” CrowdStrike elaborates. Further explaining “More sophisticated attackers may also use machine learning algorithms to scan through massive amounts of data and identify high-level individuals they most want to target.”

Vulnerability scanning: Hackers can use sophisticated scanning tools like OpenVAS to find weaknesses within an organization's email infrastructure. They can search email servers for known vulnerabilities, outdated software versions, or misconfigurations for potential entry points for exploitation. 

These vulnerabilities can include flaws in email server software, insecure email protocols, or inadequately configured authentication mechanisms like SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

More specifically, hackers then assess the susceptibility of an organization's email system to malware-infected emails, phishing attempts, or unauthorized access, focusing their exploitation efforts on the vulnerabilities that offer them the highest chance of success. 

Implications of spear-phishing campaigns 

The FBI, U.S. Department of State, and NSA, recently issued a Joint CyberSecurity Advisory, following attempts by North Korean cyber actors Kimsuky, to exploit improperly configured DMARC policies and hide social engineering attempts. 

Kimsuky sends spoofed emails that appear to originate from legitimate domains, like reputable journalists, academics, or experts in East Asian affairs, with convincing narratives to lure unsuspecting victims into releasing sensitive information or granting access to confidential data.

These North Korean spear-phishing campaigns aim to gather intelligence on geopolitical events, adversary foreign policy strategies, and information pertinent to North Korean interests. Once they access private documents, research materials, and communications, they seek to gain strategic insights and use sensitive data to advance their agenda, threatening national security and international stability.

So, the advisory recommends that all organizations improve their cybersecurity posture of DMARC security policies, explaining, “Without properly configured DMARC policies, malicious cyber actors are able to send spoofed emails as if they came from a legitimate domain’s email exchange.”

DMARC and email authentication

According to DMARC.org, “DMARC is designed to fit into an organization’s existing inbound email authentication process. The way it works is to help email receivers determine if the purported message ‘aligns’ with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the ‘non-aligned’ messages.”

So, at a high level, DMARC is designed to “minimize false positives, provide robust authentication reporting, assert sender policy at receivers [and ultimately] reduce successful phishing delivery.”

Cross-Sector Cybersecurity Performance Goals (CPGs)

The Joint CyberSecurity Advisory suggests mitigating potential threats, in line with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and NIST. 

While the CPGs are broadly intended as:

• “A baseline set of cybersecurity practices broadly applicable across critical infrastructure with known risk-reduction value.  
• A benchmark for critical infrastructure operators to measure and improve their cybersecurity maturity. 
• A combination of recommended practices for information technology and operational technology owners, including a prioritized set of security practices.  
• Unique from other control frameworks as they consider not only the practices that address the risk to individual entities but also the aggregate risk to the nation.”

CPG 2.M, specifically recommends that enable DMARC and enhance email security by ensuring:

“(1) STARTTLS is enabled, 

(2) Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are enabled, 

(3) Domainbased Message Authentication, Reporting, and Conformance (DMARC) is enabled and set to ‘reject.’”

Additionally, DMARC implementation entails configuring the ‘p’ field, which controls how email servers handle messages that fail DMARC checks. In other words, “Missing DMARC policies or DMARC policies with ‘p=none’ indicate that the receiving email server should take no security action on emails that fail DMARC checks and allow the emails to be sent through to the recipient’s inbox.” 

Optimizing DMARC policy fields

The advisory recommends all organizations update their DMARC policies to either ‘p=quarantine’ or ‘p=reject’ configurations. While ‘quarantine’ directs email servers to isolate suspicious emails, marking them as probable spam, ‘reject’ takes will instruct servers to block such emails outright.

While these steps will “reduce risk from common email-based threats, such as spoofing, phishing, and interception”, helping organizations’ defense against fraudulent emails and phishing attempts, DMARC authentication is not a simple ‘flip of a switch’ process, especially for large-scale email systems.

Implementing the DMARC protocol

While the DMARC protocol itself is standardized and well-defined, the implementation process can be complex and require careful planning, configuration, and testing. Large organizations with extensive email infrastructures may have numerous email servers, domains, and users to manage. 

So, configuring and testing DMARC policies for each domain and ensuring compatibility with existing email systems can be time-consuming and may require coordination across various teams and departments. 

While transitioning to DMARC authentication may be complex, organizations can use parameters like ‘pct,’ ‘ruf,’ and ‘rua’ parameters in DMARC configuration to control the percentage of messages subjected to authentication, receive detailed forensic reports on authentication failures, and receive aggregate reports on authentication activity.

• pct (Percentage of messages subjected to filtering): The ‘pct’ parameter allows organizations to specify the percentage of incoming messages that should be subjected to DMARC authentication and filtering. For example, setting "pct=20" indicates that only 20% of incoming messages should be filtered, while the remaining 80% are exempt. Changing this parameter can help organizations gradually implement DMARC authentication without disrupting email delivery for all incoming messages. Organizations can then gradually increase the percentage over time, monitoring the impact of DMARC authentication on email traffic and adjust their policies accordingly.
• ruf (Reporting URI for forensic reports): The ‘ruf’ parameter specifies the Reporting URI for forensic reports, which are detailed reports generated by email servers when messages fail DMARC authentication. These forensic reports provide the reasons for authentication failures, including information like the sending domain, IP address, authentication results, and message headers. Organizations can specify a ‘ruf’ URI to receive forensic reports directly via email or through a designated reporting system, allowing them to investigate and address authentication failures promptly.
• rua (Reporting URI of aggregate reports): The ‘rua’ parameter reports URI for aggregate reports, which are summary reports generated by email receivers detailing DMARC authentication activity over a specified period. These aggregate reports provide statistical data on the volume of messages passing DMARC authentication, as well as the percentage of messages passing or failing authentication. So, a specified rua URI provides organizations with aggregate reports regularly, helping them monitor the effectiveness of their DMARC policies, identify trends, and take proactive measures to improve email security.

Using HIPAA compliant emails to transition to DMARC

Organizations can use a HIPAA compliant platform, like Paubox, which offers comprehensive email security services to help organizations of all sizes protect their emails from phishing attacks, data breaches, and other cyber threats. These platforms allow organizations to integrate DMARC authentication into their existing email infrastructure, using the platform's interface and features to streamline deployment.

More specifically, provider organizations can use DMARC to authenticate email messages, verifying their legitimacy while protecting sensitive patient data like protected health information (PHI). DMARC detects and blocks unauthorized emails, thwarting potential threats posed by cybercriminals seeking to exploit vulnerabilities in email systems. In this case, DMARC's ability to reduce the risk of email spoofing and phishing attacks enhances the overall security posture of healthcare organizations, safeguarding patient confidentiality and maintaining HIPAA compliance.

Furthermore, HIPAA compliant platforms offer security features like encryption, spam filtering, and threat detection, work with DMARC to provide comprehensive protection against email-based threats, mitigate unauthorized access or data loss, and maintain HIPAA compliance.

FAQs

Who needs to comply with HIPAA?

HIPAA compliance is required for covered entities, such as healthcare providers, health plans, and healthcare clearinghouses, as well as their business associates who handle protected health information (PHI).

Can DMARC help healthcare organizations prevent email-based breaches of patient information?

Yes, DMARC can help healthcare organizations prevent email-based breaches of patient information by verifying the authenticity of email messages, detecting and blocking unauthorized emails, and reducing the risk of email spoofing and phishing attacks.

How can healthcare organizations ensure compliance with DMARC policies while protecting patient privacy under HIPAA?

Healthcare organizations can ensure compliance with DMARC policies while protecting patient privacy under HIPAA by implementing appropriate security measures, conducting regular risk assessments, and training staff on email security best practices.