SEGs vs ICES Solutions: Email Security Fundamentals

Email is the largest security attack surface for most companies. You’re probably here because you want to learn about improving your email security posture and prevent phishing, impersonations, malware and account compromises. You came to the right place. Let’s start with the Email security basics: SPF, DKIM, and DMARC.

SPF is an email authentication protocol that allows a domain owner to specify which mail servers are authorized to send email on behalf of their domain. SPF works by adding a DNS record to the domain’s DNS configuration, which lists the IP addresses of authorized mail servers. When an email is received, the recipient’s mail server can check the SPF record to verify that the sending mail server is authorized to send email on behalf of the domain.

To configure SPF for a domain, the domain owner needs to create an SPF record in their domain’s DNS configuration. The SPF record includes a list of IP addresses that are authorized to send email on behalf of the domain. The syntax of the SPF record is typically in the format of “v=spf1 ip4:XXX.XXX.XXX.XXX -all”, where “ip4” specifies an IPv4 address of an authorized mail server.

DKIM is another email authentication protocol that uses public-key cryptography to verify the authenticity of an email message. DKIM works by adding a digital signature to the email header, which is generated using the domain’s private key. When the email is received, the recipient’s mail server can verify the signature using the domain’s public key, which is published in the domain’s DNS configuration.

To configure DKIM for a domain, the domain owner needs to generate a public-private key pair and publish the public key in their domain’s DNS configuration. The private key is used to generate the digital signature, which is added to the email header by the mail server.

DMARC is an email authentication protocol that builds on SPF and DKIM to provide more comprehensive protection against email spoofing and phishing attacks. DMARC allows a domain owner to specify how their domain’s email should be handled if it fails SPF or DKIM checks. DMARC also provides feedback to the domain owner on how their email is being handled by email receivers.

To configure DMARC for a domain, the domain owner needs to create a DMARC record in their domain’s DNS configuration. The DMARC record specifies how the domain’s email should be handled if it fails SPF or DKIM checks, as well as how to send feedback to the domain owner. The syntax of the DMARC record is typically in the format of “_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:[email protected]”, where “p” specifies the policy to apply if the email fails SPF or DKIM checks, and “rua” specifies the email address to send feedback to.

In summary, SPF, DKIM, and DMARC are email authentication protocols that can help verify the authenticity of email messages and protect against email spoofing and phishing attacks. Implementing these protocols requires configuring DNS records for the domain, and it is essential to ensure that they are correctly configured and maintained to provide maximum protection against email-based threats.

How do hackers spoof SPF records to appear as trusted senders?

Hackers can use several techniques to spoof SPF records and make their emails appear to come from a trusted sender. Here are some of the most common techniques:

Domain Hijacking: Hackers can hijack a trusted sender’s domain by gaining access to their DNS settings and modifying the SPF record to include the IP address of the malicious mail server. This technique allows the hacker to send emails that appear to come from the trusted sender’s domain.

Open SMTP Servers: Hackers can use open SMTP servers to send emails that appear to come from a trusted sender’s domain. Open SMTP servers are mail servers that do not require authentication to send emails, allowing anyone to use them to send emails that appear to come from any domain.

IP Spoofing: Hackers can spoof the IP address of the mail server to make it appear as though the email was sent from a trusted sender’s mail server. This technique requires the hacker to have access to an IP address that is associated with the trusted sender’s mail server.

SMTP Relay: Hackers can use an SMTP relay to send emails that appear to come from a trusted sender’s domain. An SMTP relay is a mail server that forwards email messages to other mail servers. By relaying the email through a trusted sender’s mail server, the hacker can make it appear as though the email was sent from the trusted sender’s domain.

Typo-Squatting: Hackers can use a technique called typo-squatting to create a domain name that is similar to a trusted sender’s domain name, but with a small typo. For example, they may create a domain name like “gmial.com” instead of “gmail.com”. This technique allows the hacker to send emails that appear to come from the trusted sender’s domain.

To protect against SPF record spoofing, organizations should implement email authentication protocols such as DKIM and DMARC, which can help verify the authenticity of the sender’s email address. It is also important for organizations to monitor their DNS records for any unauthorized changes and to use strong authentication and access control measures to prevent unauthorized access to their DNS settings.

How do hackers spoof DKIMs to appear as a trusted sender?

Hackers can use several techniques to spoof DKIM signatures and make their emails appear to come from a trusted sender. Here are some of the most common techniques:

DKIM Key Compromise: Hackers can compromise the private key used to generate the DKIM signature for a trusted sender’s domain. With access to the private key, the hacker can generate a DKIM signature that is indistinguishable from the legitimate signature.

Domain Hijacking: Hackers can hijack a trusted sender’s domain by gaining access to their DNS settings and modifying the DKIM public key published in the domain’s DNS configuration. This technique allows the hacker to generate a DKIM signature that is validated by the recipient’s mail server.

Brute Force Attack: Hackers can use a brute force attack to guess the private key used to generate the DKIM signature. This technique requires the hacker to have a high degree of computational power and the ability to make many attempts to guess the private key.

Malware Injection: Hackers can inject malware into a trusted sender’s mail server, allowing them to modify the DKIM signature generated by the server. This technique allows the hacker to generate a DKIM signature that is validated by the recipient’s mail server.

Using Similar Domains: Hackers can use a domain that is similar to a trusted sender’s domain to generate a DKIM signature that is validated by the recipient’s mail server. For example, they may use a domain like “gmial.com” instead of “gmail.com” to generate a DKIM signature that appears to come from Gmail.

To protect against DKIM signature spoofing, organizations should implement email authentication protocols such as DMARC, which can help verify the authenticity of the sender’s email address and ensure that DKIM signatures are validated correctly. Organizations should also monitor their DNS records for any unauthorized changes and use strong authentication and access control measures to prevent unauthorized access to their DNS settings and private keys. Additionally, it is important for organizations to educate their employees on the dangers of phishing attacks and to encourage them to be vigilant when opening emails, especially those that contain links or attachments.

How do hackers spoof DMARC to appear as a trusted sender?

It is not possible to spoof DMARC records directly, as DMARC records are published in the DNS configuration of the sender’s domain and cannot be modified by external parties. However, hackers can use a range of techniques to bypass or evade DMARC checks and make their emails appear to come from a trusted sender. Here are some of the most common techniques:

Domain Spoofing: Hackers can create a domain that is similar to a trusted sender’s domain and use it to send emails that appear to come from the trusted sender’s domain. This technique can be difficult to detect because the email address may look very similar to the trusted sender’s email address.

Forwarding Attacks: Hackers can use email forwarding to forward a legitimate email from a trusted sender to a victim with malicious content or links embedded in it. This way, the email appears to come from the trusted sender, and the DMARC record of the trusted sender’s domain is not used in the email authentication checks.

Phishing Attacks: Hackers can use phishing attacks to trick users into providing their login credentials, allowing the hacker to access the trusted sender’s email account and send emails that appear to come from the trusted sender. In this case, the DMARC record of the trusted sender’s domain is not used in the email authentication checks.

Zero-day Exploits: Hackers can use zero-day exploits to exploit vulnerabilities in email clients or email servers, allowing them to bypass email authentication checks and send emails that appear to come from a trusted sender.

To protect against DMARC spoofing, organizations should implement a multi-layered approach to email security that includes user awareness training, advanced threat protection, and continuous monitoring and analysis of email traffic. Organizations should also configure their DMARC records correctly and ensure that their DNS records are not vulnerable to domain hijacking or other types of attacks. Additionally, it is important to regularly review and update DMARC policies to ensure that they are aligned with the organization’s security goals and threat landscape.

What are the key indicators that SEG platforms look at for inspecting emails?
Example: DNS reputation, SPF records, etc.

Secure Email Gateway (SEG) platforms typically inspect various components of an email message to determine whether it is legitimate or potentially malicious. Some of the key indicators that SEG platforms look at when inspecting emails include:

Sender Identity: SEG platforms check the sender’s email address and compare it with the domain’s Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records to verify the sender’s identity.

IP Reputation: SEG platforms check the sender’s IP address against various reputation databases to determine if it is known to send spam or other malicious emails.

Content Analysis: SEG platforms use machine learning algorithms to analyze the content of an email message, looking for patterns or characteristics that may indicate a malicious intent, such as suspicious links or attachments.

URL Reputation: SEG platforms check the reputation of URLs included in the email message to determine if they are known to host malware or phishing scams.

Malware Analysis: SEG platforms scan email attachments and links for malware using signature-based detection, behavior-based detection, and sandboxing techniques.

Data Leakage Prevention (DLP): SEG platforms use DLP technology to identify and prevent the transmission of sensitive data, such as credit card numbers or social security numbers.

Email Authentication: SEG platforms can also verify that the email message has been authenticated using DMARC (Domain-based Message Authentication, Reporting, and Conformance) to detect and prevent email spoofing attacks.

Overall, SEG platforms use a variety of indicators to determine whether an email is legitimate or malicious, with a focus on identifying and preventing spam, phishing, malware, and other email-based threats.

Hackers are continually finding new ways to evade Secure Email Gateway (SEG) detection and bypass email security systems. Here are some common techniques that hackers use to bypass SEG tools:

Social Engineering: Hackers use social engineering techniques to trick users into providing sensitive information or clicking on links that lead to malware. These attacks can be difficult for SEG tools to detect because they rely on human interaction rather than automated patterns.

Obfuscation: Hackers use techniques such as obfuscation, encryption, and polymorphism to hide malicious content from SEG tools. For example, they may use Base64 encoding to hide the contents of a malicious attachment, making it difficult for SEG tools to recognize.

Zero-day attacks: Zero-day attacks are attacks that exploit vulnerabilities that are unknown to the security community, including SEG tools. Hackers use these vulnerabilities to bypass security controls and deliver malware or other malicious content.

Domain Spoofing: Hackers can create domains that look similar to legitimate domains, making it difficult for SEG tools to differentiate between legitimate and fake domains. This technique is often used in phishing attacks to trick users into providing sensitive information.

Business Email Compromises (BECs) and Vender Email Compromises (VECs): Hackers that successfully harvest credentials from victim companies will gain access to their email services and thread hijack real email conversations with the intent of sending fraudulent invoices, or spawning additional credential harvest phishing amongst the initial victim’s contacts.

Fileless Attacks: Hackers can use fileless attacks that leverage legitimate processes or applications to deliver malware. These attacks do not rely on the delivery of a malicious file, making it difficult for SEG tools to detect.

Evading Reputation-Based Filters: Hackers can use tactics such as sending small quantities of spam or changing IP addresses frequently to evade reputation-based filters used by SEG tools.

Cloud Service Usage: Hackers may use cloud-based services to host and distribute malicious content, making it difficult for SEG tools to detect and block these threats.

Overall, hackers use a range of techniques to bypass SEG tools, highlighting the need for a multi-layered approach to email security that includes user awareness training, advanced threat protection, and continuous monitoring and analysis of email traffic.

How do hackers evade Email Attachment sandbox detections?

Sandboxing is a technique used by some email security solutions to detect and prevent malware by running it in a simulated environment to observe its behavior. However, hackers can use several techniques to evade sandbox detections, including:

Anti-Sandbox Detection Techniques: Malware authors often include anti-sandbox techniques in their code to detect if their malware is running in a sandbox. For example, malware may look for specific registry keys or files that are present in a sandbox environment and behave differently if they are found.

Time-Based Evasion: Malware authors may use time-based evasion techniques to evade sandbox detection. They may use a time delay before the malware begins to execute, or they may change the behavior of the malware after a certain amount of time has passed.

Memory-Based Evasion: Malware authors may use memory-based evasion techniques to evade sandbox detection. They may use techniques such as reflective DLL injection, which injects the malware directly into memory without leaving a trace on disk.

Fileless Malware: Fileless malware does not rely on the delivery of a malicious file, making it difficult for sandboxes to detect. This type of malware leverages legitimate processes or applications to deliver malware, making it challenging for sandboxes to identify.

IP Address Evasion: Malware authors may use IP address evasion techniques to evade sandbox detection. They may use different IP addresses when communicating with their command-and-control (C&C) servers, making it difficult for the sandbox to identify the malicious traffic.

Dynamic Malware: Malware authors may use dynamic malware that is designed to mutate and change its behavior over time, making it difficult for sandboxes to detect.

Encrypted Malware: Malware authors may encrypt the malware payload to evade detection by sandboxes. Encrypted malware can be difficult for sandboxes to analyze because the sandbox may not have the encryption key to decrypt the payload.

Overall, hackers use a range of techniques to evade sandbox detections, highlighting the need for a multi-layered approach to email security that includes advanced threat protection, user awareness training, and continuous monitoring and analysis of email traffic.

Hackers can use several techniques to send emails that appear to come from a trusted sender. Here are some of the most common techniques:

Spoofing the sender’s email address: Hackers can spoof the sender’s email address by modifying the “From” field in the email header to make it appear as though the email came from a trusted sender. This technique is known as email spoofing.

Creating a fake email account: Hackers can create a fake email account that uses a domain name that is similar to a trusted sender’s domain name. For example, they may create an email account with the domain name “gmial.com” instead of “gmail.com.”

Compromising the sender’s email account: Hackers may gain access to a trusted sender’s email account and use it to send malicious emails to the sender’s contacts.

Email Forwarding: Hackers may use email forwarding to forward a legitimate email from a trusted sender to a victim with malicious content or links embedded in it. This way, the email appears to come from the trusted sender.

Email Reply Spoofing: Hackers may spoof the reply-to address in the email header to make it appear as though the email came from a trusted sender.

Using stolen credentials: Hackers may steal the email credentials of a trusted sender and use them to send emails that appear to come from the trusted sender.

Overall, email spoofing is a common technique used by hackers to send emails that appear to come from a trusted sender. To protect against email spoofing, organizations can implement email authentication protocols such as SPF, DKIM, and DMARC, which can help verify the authenticity of the sender’s email address. It is also important for users to be vigilant when opening emails, especially those that contain links or attachments, and to report any suspicious emails to their IT department.

In a BEC attack, the attacker gains access to an employee’s email account and uses it to send fraudulent emails to other employees or vendors in the organization. The emails may request payments or transfers of funds to bank accounts controlled by the attacker, or may contain malware or phishing links to steal sensitive information.

In a VEC attack, the attacker gains access to a vendor’s email account and uses it to send fraudulent emails to the organization. The emails may request payments or transfers of funds to bank accounts controlled by the attacker, or may contain malware or phishing links to steal sensitive information.

Integrated cloud email security is a set of technologies and techniques used to protect cloud-based email systems from various types of cyber threats such as spam, malware, phishing attacks, and other email-borne threats. Just as we’ve seen SSE and WAFs replace legacy Firewalls, we are seeing the same trends in ICES platforms replacing legacy SEGs.

ICES platforms typically involve the use of highly advanced email filtering techniques, such as content analysis, reputation analysis, and behavioral analysis, to identify and block malicious emails before they reach the end-users. This may include various security features such as anti-virus and anti-malware protection, email encryption, data loss prevention (DLP), and advanced threat protection. Some ICES platforms even have a Natural Language Processing (NLP) capability built in to further detect email anomalies… Pretty cool stuff!

Integrated Cloud Email Security (ICES) technologies and Secure Email Gateway (SEG) technologies both aim to protect cloud-based email systems from various types of cyber threats. However, there are some key differences between these two technologies:

Deployment: ICES solutions are typically cloud-based and delivered as a service, while SEG solutions can be deployed either as an on-premises hardware or software solution or as a cloud-based service.

Scope of protection: ICES solutions provide broader protection for cloud-based email systems beyond just email security, including email encryption, data loss prevention (DLP), and advanced threat protection. On the other hand, SEG solutions primarily focus on email security, including spam and malware protection and phishing prevention.

Scalability: ICES solutions are often more scalable than SEG solutions because they are designed to handle large volumes of email traffic from multiple organizations. SEG solutions, however, may have limitations in terms of scalability when deployed as on-premises solutions.

Management: ICES solutions are typically easier to manage because they are provided as a service, with the service provider handling the maintenance, updates, and monitoring of the system. SEG solutions, especially when deployed as on-premises solutions, may require more management and administration from the organization’s IT team.

Next Gen Features: a few of the new ICES platforms that we at Defensive are excited about use advanced AI and Machine Learning to look into every single email for abnormalities that would signal an indicator of email attack.

In summary, in benchmark tests we have run, we have found a few ICES vendors providing significant improvements in both detection coverage and accuracy, especially for instances of Vendor Email Compromises (VECs) and Open Redirect phishing URLs.