Jul 31 2024

How Millions of Phishing Emails were Sent from Trusted Domains: EchoSpoofing Explained

Category: DNS Attacks,Information Security,Phishingdisc7 @ 11:44 am

Injecting spoofed headers with email relaying involves manipulating the email headers to disguise the true origin of an email, making it appear as if it was sent from a legitimate source. Here’s a detailed explanation of how this process works:

1. Understanding Email Headers

Email headers contain vital information about the sender, recipient, and the path an email takes from the source to the destination. Key headers include:

  • From: The email address of the sender.
  • To: The recipient’s email address.
  • Subject: The subject line of the email.
  • Received: Information about the mail servers that handled the email as it traveled from sender to recipient.
  • Return-Path: The email address where bounces and error messages should be sent.

2. Email Relaying

Email relaying is the process of sending an email from one server to another. This is typically done by SMTP (Simple Mail Transfer Protocol) servers. Normally, email servers are configured to relay emails only from authenticated users to prevent abuse by spammers.

3. Spoofing Headers

Spoofing email headers involves altering the email headers to misrepresent the email’s source. This can be done for various malicious purposes, such as phishing, spreading malware, or bypassing spam filters. Here’s how it can be done:

a. Crafting the Spoofed Email

An attacker can use various tools and scripts to create an email with forged headers. They might use a command-line tool like sendmailmailx, or a programming language with email-sending capabilities (e.g., Python’s smtplib).

b. Setting Up an Open Relay

An open relay is an SMTP server configured to accept and forward email from any sender to any recipient. Attackers look for misconfigured servers on the internet to use as open relays.

c. Injecting Spoofed Headers

The attacker crafts an email with forged headers, such as a fake “From” address, and sends it through an open relay. The open relay server processes the email and forwards it to the recipient’s server without verifying the authenticity of the headers.

d. Delivery to Recipient

The recipient’s email server receives the email and, based on the spoofed headers, believes it to be from a legitimate source. This can trick the recipient into trusting the email’s content.

4. Example of Spoofing Email Headers

Here’s an example using Python’s smtplib to send an email with spoofed headers:

import smtplib
from email.mime.text import MIMEText

# Crafting the email
msg = MIMEText("This is the body of the email")
msg['Subject'] = 'Spoofed Email'
msg['From'] = 'spoofed.sender@example.com'
msg['To'] = 'recipient@example.com'

# Sending the email via an open relay
smtp_server = 'open.relay.server.com'
smtp_port = 25

with smtplib.SMTP(smtp_server, smtp_port) as server:
    server.sendmail(msg['From'], [msg['To']], msg.as_string())

via Frontend Transport

The statement about the term “via Frontend Transport” in header values refers to a specific configuration in Microsoft Exchange Server that could suggest a misconfiguration allowing email relaying without proper verification. Let’s break down the key elements of this explanation:

1. Frontend Transport in Exchange

In Microsoft Exchange Server, the Frontend Transport service is responsible for handling client connections and email traffic from the internet. It acts as a gateway, receiving emails from external sources and forwarding them to the internal network.

2. Email Relaying

Email relaying is the process of forwarding an email from one server to another, eventually delivering it to the final recipient. While this is a standard part of the SMTP protocol, it becomes problematic if a server is configured to relay emails without proper authentication or validation.

3. The Term “via Frontend Transport”

When email headers include the term â€śvia Frontend Transport”, it indicates that the email passed through the Frontend Transport service of an Exchange server. This can be seen in the Received headers of the email, showing the path it took through various servers.

4. Suggestion of Blind Email Relaying

The concern arises when these headers suggest that Exchange is configured to relay emails without altering them or without proper checks. This could imply that:

  • The Exchange server is not adequately verifying the sender’s authenticity.
  • The server might be forwarding emails without checking if they come from trusted sources.
  • Such a configuration can be indicative of an open relay, where the server forwards any email it receives, which is highly vulnerable to abuse.

5. Abuses of Open Relays

Open relays are notorious for being exploited by spammers and malicious actors because they can be used to send large volumes of unsolicited emails while obscuring the true origin of the message. This makes it difficult to trace back to the actual sender and can cause the relay server’s IP address to be blacklisted.

https://www.securitynewspaper.com/2023/12/20/how-to-send-spoof-emails-from-domains-that-have-spf-and-dkim-protections/embed/#?secret=pu82rHzNqA#?secret=1UMPUIgHIO

Here’s a detailed breakdown of the key points:

Scenario Breakdown

  1. Attackers Use a Genuine Microsoft Office 365 Account
    • The attackers have managed to send an email from a genuine Microsoft Office 365 account. This could be through compromising an account or using a trial account.
  2. Email Branded as Disney
    • The email is branded as coming from Disney (disney.com). This branding could involve setting the “From” address to appear as if it’s from a Disney domain, which can trick recipients into believing the email is legitimate.
  3. Gmail’s Handling of Outlook’s Servers
    • Gmail has robust mechanisms to handle high volumes of emails from trusted servers like Outlook’s (Microsoft’s email service). These servers are built to send millions of emails per hour, so Gmail will not block them due to rate limits.
  4. SPF (Sender Policy Framework)
    • SPF is a protocol that helps prevent email spoofing by allowing domain owners to specify which mail servers are authorized to send emails on their behalf. The attackers benefit from this because:
      • The email is sent through Microsoft’s official relay server, protection.outlook.com.Disney’s SPF record includes spf.protection.outlook.com, which means emails sent through this relay server are authorized by Disney’s domain.
      .
  5. Spoofed Headers
    • Spoofed headers involve altering the email headers to make the email appear as if it originated from a different source. In this scenario, the attackers have spoofed headers to make the email look like it’s from Disney.
  6. SPF Check Passed
    • Since the email is sent via a server included in Disney’s SPF record (protection.outlook.com), it will pass the SPF check, making it seem legitimate to the recipient’s email server.

DKIM (DomainKeys Identified Mail)

DKIM is another email authentication method that allows the receiver to check if an email claiming to come from a specific domain was indeed authorized by the owner of that domain. This is done by verifying a digital signature added to the email.

Points of Concern

  • SPF Check Passed
    • The email passed the SPF check because it was sent through an authorized server (protection.outlook.com) included in Disney’s SPF record.
  • Spoofed Headers
    • The headers were manipulated to make the email appear as if it came from Disney, which can deceive recipients.
  • Gmail Handling
    • Gmail will trust and not rate-limit emails from Outlook’s servers, ensuring the email is delivered without being flagged as suspicious due to high sending volumes.

Potential for DKIM

To fully understand if the email can pass DKIM checks, we would need to know if the attackers can sign the email with a valid DKIM key. If they manage to:

  • DKIM Alignment
    • Ensure the DKIM signature aligns with the domain in the “From” header (disney.com).
  • Valid DKIM Signature
    • Use a valid DKIM signature from an authorized domain (which would be difficult unless they have compromised Disney’s signing keys or a legitimate sending infrastructure).

Proofpoint and similar services are email security solutions that offer various features to protect organizations from email-based threats, such as phishing, malware, and spam. They act as intermediaries between the sender and recipient, filtering and relaying emails. However, misconfigurations or overly permissive settings in these services can be exploited by attackers. Here’s an explanation of how these services work, their roles, and how they can be exploited:

Roles and Features of Proofpoint-like Services

  1. Email Filtering and Protection
    • Spam and Phishing Detection: Filters out spam and phishing emails.
    • Malware Protection: Scans and blocks emails containing malware or malicious attachments.
    • Content Filtering: Enforces policies on email content, attachments, and links.
  2. Email Relay and Delivery
    • Inbound and Outbound Filtering: Manages and filters both incoming and outgoing emails to ensure compliance and security.
    • Email Routing: Directs emails to the appropriate recipients within an organization.
    • DKIM Signing: Adds DKIM signatures to outgoing emails to authenticate them.
  3. Authentication and Authorization
    • IP-Based Authentication: Uses IP addresses to authenticate incoming email servers.
    • SPF, DKIM, and DMARC Support: Implements these email authentication protocols to prevent spoofing.

How Misconfigurations Allow Exploitation

  1. Permissive IP-Based Authentication
    • Generic Configuration: Proofpoint is often configured to accept emails from entire IP ranges associated with services like Office365 or Google Workspace without specifying particular accounts.
    • IP Range Acceptance: Once a service like Office365 is enabled, Proofpoint accepts emails from any IP within the Office365 range, regardless of the specific account.
  2. Exploitation StepsStep 1: Setting Up the Attack
    • Attacker’s Office365 Account: The attacker sets up or compromises an Office365 account.
    • Spoofing Email Headers: The attacker crafts an email with headers that mimic a legitimate sender, such as Disney.
    Step 2: Leveraging Proofpoint Configuration
    • Sending Spoofed Emails: The attacker sends the spoofed email from their Office365 account.
    • Proofpoint Relay Acceptance: Proofpoint’s permissive configuration accepts the email based on the IP range, without verifying the specific account.
    Step 3: Proofpoint Processing
    • DKIM Signing: Proofpoint processes the email, applying DKIM signatures and ensuring it passes SPF checks because it comes from an authorized IP range.
    • Email Delivery: The email is then delivered to the target’s inbox, appearing legitimate due to the DKIM signature and SPF alignment.

Example of a Permissive Configuration in Proofpoint

  1. Admin Setup
    • Adding Hosted Services: Proofpoint allows administrators to add hosted email services (e.g., Office365) with a single-click configuration that relies on IP-based authentication.
  2. No Specific Account Configuration
    • Generic Acceptance: The setup does not specify which particular accounts are authorized, leading to a scenario where any account within the IP range is accepted.
  3. Exploitation of Misconfiguration
    • Blind Relay: Due to this broad acceptance, attackers can send emails through Proofpoint’s relay, which then processes and delivers them as if they were legitimate.

A recent attack exploited a misconfiguration in Proofpoint’s email routing, allowing millions of spoofed phishing emails to be sent from legitimate domains like Disney and IBM. The attackers used Microsoft 365 tenants to relay emails through Proofpoint, bypassing SPF and DKIM checks, which authenticate emails. This “EchoSpoofing” method capitalized on Proofpoint’s broad IP-based acceptance of Office365 emails. Proofpoint has since implemented stricter configurations to prevent such abuses, emphasizing the need for vigilant security practices.

For more details, visit https://labs.guard.io/echospoofing-a-massive-phishing-campaign-exploiting-proofpoints-email-protection-to-dispatch-3dd6b5417db6

The Domain Name System: Understand Why Domain Name Is Still Relevant

How to Catch a Phish: A Practical Guide to Detecting Phishing Emails 

Step-by-step instructions on what to do if you fall prey to this type of cyber crime.  (Phishing in 2024)

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot

Tags: EchoSpoofing, trusted domains


Sep 25 2023

BIND DNS System Flaws Let Attackers Launch DoS Attacks

Category: DDoS,DNS Attacksdisc7 @ 9:28 am

In a recent disclosure, BIND 9, a widely-used DNS (Domain Name System) server software, has been found vulnerable to two critical security flaws, labeled CVE-2023-4236 and CVE-2023-3341. 

These vulnerabilities, if exploited, could have serious consequences, making it imperative for users to take swift action.

CVE-2023-4236: DNS-over-TLS Query Load Vulnerability

This vulnerability arises from a flaw in the networking code responsible for handling DNS-over-TLS queries in BIND 9. 

Under high DNS-over-TLS query load, an internal data structure is incorrectly reused, leading to an assertion failure. Consequently, a vulnerable named instance may terminate unexpectedly.

Thankfully, this flaw does not affect DNS-over-HTTPS code, as it employs a distinct TLS implementation. However, for those relying on DNS-over-TLS, the impact can be severe.

CVE-2023-3341: Control Channel Stack Exhaustion

The second critical vulnerability, CVE-2023-3341, relates to the control channel code within BIND 9. 

This flaw allows attackers to exploit a stack exhaustion issue by sending specially crafted messages over the control channel. 

This can lead to names unexpectedly terminating, causing potential disruption.

Notably, the attack is effective in environments with limited stack memory available to each process or thread, making it difficult to predict its impact.

For users of BIND 9, immediate action is necessary to address these vulnerabilities. ISC (Internet Systems Consortium), the organization behind BIND, has provided solutions to mitigate these risks.

For CVE-2023-4236:

– Upgrade to BIND 9.18.19 or BIND Supported Preview Edition 9.18.19-S1.

– Consider disabling DNS-over-TLS connections if not required.

For CVE-2023-3341:

– Upgrade to BIND 9.16.44, 9.18.19, or 9.19.17, depending on your current version.

– Ensure that control-channel connections are limited to trusted IP ranges when enabling remote access.

No active exploits have been reported for these vulnerabilities. However, proactive measures are crucial to safeguard your systems against potential threats.

ISC extends its gratitude to the individuals who responsibly reported these vulnerabilities. 

Robert Story from the USC/ISI DNS root server operations team brought CVE-2023-4236 to ISC’s attention, while Eric Sesterhenn from X41 D-Sec GmbH identified CVE-2023-3341.

The Hidden Potential of DNS In Security: Combating Malware, Data Exfiltration, and more – The Guide for Security Professionals

InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory

Tags: BIND DNS System Flaws, DNS In Security


Aug 20 2023

Microsoft DNS boo-boo breaks Hotmail for users around the globe

Category: DNS Attacks,Information Securitydisc7 @ 11:05 pm

https://www.theregister.com/2023/08/21/microsoft_dns_booboo_breaks_hotmail

Someone at Microsoft has some explaining to do after a messed up DNS record caused emails sent from Hotmail accounts using Microsoft’s Outlook service to be rejected and directed to spam folders starting on Thursday.

Late on Thursday evening, Hotmail users began reporting that some emails were being returned with errors related to Sender Policy Framework (SPF), and thus recipient email services were unable “to confirm that [a] message came from a trusted location.” 

SPF, for those unfamiliar with it, is a method of outbound email authentication that helps avoid email spoofing, impersonation and phishing. If, for example, a service like Hotmail were to have one of its subdomains removed from the DNS TXT record that stores its SPF list, then recipient services may assume it’s junk. 

And that appears to be just what happened. 

Reddit users posting to the Sysadmin subreddit verified they were experiencing SPF issues with Hotmail. One user pulled up Hotmail’s SPF record and found that Redmond had made two changes: removing spf.protection.outlook.com from the record, and changing the SPF failure condition from soft to hard. That meant any suspicious messages from Hotmail should be rejected rather than just sent to spam. 

Microsoft support forum advisors confirmed that the issue was known, which was further confirmed by a look at the Office service status page. Per Microsoft: “Some users may receive non-delivery reports when attempting to send emails from hotmail.com.” 

At time of writing, the status page indicated that “a recent change to email authentication” was the potential root cause of the outage. Microsoft said it made a configuration change to remediate impact, but shortly after said the problem may have been worse than it appeared at first glance. 

“We’ve identified that additional configuration entries are impacted, and we’re implementing further configuration changes to resolve the issue,” Microsoft said. Not long after that was posted, Microsoft indicated configuration changes were complete and the problem was fixed. 

Microsoft didn’t respond to our questions about the incident, only saying the issue had been resolved.

Tags: Microsoft DNS


Jan 24 2023

Serious Security: How dEliBeRaTe tYpOs might imProVe DNS security

Category: DNS AttacksDISC @ 10:41 am

Over the years, we’ve written and spoken on Naked Security many times about the thorny problem of DNS hijacking.

DNS, as you probably know, is short for domain name system, and you’ll often hear it described as the internet’s “telephone directory” or “gazetteer”.

If you’re not familiar with the word gazeteer, it refers to the index at the back of an atlas where you look up, say, Monrovia, Liberia in a convenient alphabetic list, and it says something like 184 - C4. This tells you to turn straight to page 184, and to follow the grid lines down from the letter C at the top of the map, and across from the number 4 on the left. Where the lines meet, you’ll find Monrovia.

For most users, most DNS lookups go out containing a server name, asking for a reply to come back that includes what’s known as its A-record or its AAAA-record.

(A-records are used for 32-bit IPv4 internet numbers, such as 203.0.113.42; AAAA-records are the equivalent answers for a 128-bit IPv6 addresses, such as 2001:db8:15a:d0c::42 – in this article, we’ll just use A-records and IPv4 numbers, but the same security issues apply to the lookup process in both cases.)

Here’s an example, where we’re looking up the imaginary domain name naksec.test via a DNS server that was specially created to track and teach you about DNS traffic.

We’ve used the old-school Linux tool dig, short for domain internet groper, to generate a simple DNS request (dig defaults to looking up A-records) for the server we want:

$ dig +noedns @127.42.42.254 naksec.test

;; QUESTION SECTION:
;naksec.test.			IN	A

;; ANSWER SECTION:
NAKSEC.TEST.		5	IN	A	203.0.113.42

;; Query time: 1 msec
;; SERVER: 127.42.42.254#53(127.42.42.254) (UDP)
;; WHEN: Mon Jan 23 14:38:42 GMT 2023
;; MSG SIZE  rcvd: 56

Here’s how our DNS server dealt with the request, showing a hex dump of the incoming request, and the successful reply that went back:

---> Request from 127.0.0.1:57708 to 127.42.42.254:53
---> 00000000  62 4e 01 20 00 01 00 00  00 00 00 00 06 6e 61 6b  |bN. .........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01           |sec.test.....   |

DNS lookup: A-record for naksec.test ==> A=203.0.113.42

<--- Reply from 127.42.42.254:53 to 127.0.0.1:57708
<--- 00000000  62 4e 84 b0 00 01 00 01  00 00 00 00 06 6e 61 6b  |bN...........nak|
     00000010  73 65 63 04 74 65 73 74  00 00 01 00 01 06 4e 41  |sec.test......NA|
     00000020  4b 53 45 43 04 54 45 53  54 00 00 01 00 01 00 00  |KSEC.TEST.......|
     00000030  00 05 00 04 cb 00 71 2a                           |......q*        |

Note that, for performance reasons, most DNS requests use UDP, the user datagram protocol, which works on a send-and-hope basis: you fire off a UDP packet at the server you want to talk to, and then wait to see if a reply comes back.

This makes UDP much simpler and faster than its big cousin TCP, the transmission control protocol, which, as its name suggests, automatically takes care of lots of details that UDP doesn’t.

Notably, TCP deals with detecting data gets lost and asking foir it again; ensuring that any chunks of data arrive in the right order; and providing a single network connection that, once set up, can be used for sending and receiving at the same time.

UDP doesn’t have the concept of a “connection”, so that requests and replies essentially travel independently:

  • A DNS request arrives at the DNS server in a UDP packet of its own.
  • The DNS server keeps a record of which computer sent that particular packet.
  • The server sets about finding an answer to send back, or deciding that there isn’t one.
  • The server sends a reply to the original sender, using a second UDP packet.

From the level of the operating system or the network, those two UDP packets above are independent, standalone transmissions – they aren’t tied together as part of the same digital connection.

It’s up to the server to remember which client to send each reply to; and it’s up to the client to figure out which replies relate to which requests it originally sent out.

How can you be sure?

Learning CoreDNS: Configuring DNS for Cloud Native Environments

InfoSec books | InfoSec tools | InfoSec services

Tags: DNS flaw, DNS Security


Jul 11 2022

The impact of DNS attacks on global organizations

Category: DNS Attacks,Information SecurityDISC @ 9:32 am

Often we see stories about cyber attacks that breached an organisations’ security parameters, and advice on how we can protect against future threats. However, what is often missed, is just how these threat actors managed to breach a system, and as such, the fact that the Domain Name System (DNS) probably played a very large role in the attacker’s entry point.

In this Help Net Security video, Chris Buijs, Chief Evangelist at EfficientIP, talks about the importance of making the DNS as part of an organisation’s security strategy.

Internet

DNSSEC Mastery

Tags: DNS attacks, DNSSEC


May 03 2022

A DNS flaw impacts a library used by millions of IoT devices

Category: DNS AttacksDISC @ 8:29 am

A vulnerability in the domain name system (DNS) component of the uClibc library impacts millions of IoT products.

Nozomi Networks warns of a vulnerability, tracked as CVE-2022-05-02, in the domain name system (DNS) component of the uClibc library which is used by a large number of IoT products. The flaw also affects DNS implementation of all versions of the uClibc-ng library, which is a fork specifically designed for OpenWRT, a common OS for routers used in various critical infrastructure sectors.

An attacker can exploit the vulnerability for DNS poisoning or DNS spoofing and redirect the victim to a malicious website instead of the legitimate one.

“The flaw is caused by the predictability of transaction IDs included in the DNS requests generated by the library, which may allow attackers to perform DNS poisoning attacks against the target device.” reads the advisory published by Nozomi Networks.

The uClibc library is used by major vendors, including Linksys, Netgear, and Axis, or Linux distributions such as Embedded Gentoo.

Security experts did not disclose the details of the flaw because the vendor has yet to address it.

The researchers from Nozomi discovered the issue by reviewing the trace of DNS requests performed by an IoT device in their test environment. They were able to determine the pattern of DNS requests performed from the output of Wireshark, the transaction ID is first incremental, then resets to the value 0x2, then is incremental again. The transaction ID of the requests was predictable, a circumstance that could allow an attacker to perform DNS poisoning under certain circumstances.

DNS

“A source code review revealed that the uClibc library implements DNS requests by calling the internal “__dns_lookup” function, located in the source file “/libc/inet/resolv.c”.” continues the advisory. “Given that the transaction ID is now predictable, to exploit the vulnerability an attacker would need to craft a DNS response that contains the correct source port, as well as win the race against the legitimate DNS response incoming from the DNS server. Exploitability of the issue depends exactly on these factors. As the function does not apply any explicit source port randomization, it is likely that the issue can easily be exploited in a reliable way if the operating system is configured to use a fixed or predictable source port.”

If the OS uses randomization of the source port, the only way to exploit the issue is to bruteforce the 16-bit source port value by sending multiple DNS responses, while simultaneously winning the race against the legitimate response.

“As anticipated, as of the publication of this blog, the vulnerability is still unpatched. As stated in a public conversation, the maintainer was unable to develop a fix for the vulnerability, hoping for help from the community. The vulnerability was disclosed to 200+ vendors invited to the VINCE case by CERT/CC since January 2022, and a 30-day notice was given to them before the public release.” concludes Nozomi.

Managing Mission – Critical Domains and DNS: Demystifying nameservers, DNS, and domain names

DNSSEC Mastery

Tags: DNS flaw, IoT devices


Mar 17 2022

B1txor20 Linux botnet use DNS Tunnel and Log4J exploit

Category: DNS Attacks,Linux Security,Log4jDISC @ 8:50 am

Researchers uncovered a new Linux botnet, tracked as B1txor20, that exploits the Log4J vulnerability and DNS tunnel.

Researchers from Qihoo 360’s Netlab have discovered a new backdoor used to infect Linux systems and include them in a botnet tracked as B1txor20.

The malware was first spotted on February 9, 2022, when 360Netlab’s honeypot system captured an unknown ELF file that was spreading by exploiting the Log4J vulnerability.

The name B1txor20 is based on the file name “b1t” used for the propagation and the XOR encryption algorithm, and the RC4 algorithm key length of 20 bytes.

The B1txor20 Linux backdoor uses DNS Tunnel technology for C2 communications, below is the list of the main features implemented by the threat:

  • SHELL
  • Proxy
  • Execute arbitrary commands
  • Install Rootkit
  • Upload sensitive information
B1txor20

The researchers also noticed the presence of many developed features that have yet to be used, and some of them are affected by bugs. Experts believe the B1txor20 botnet is under development.

“In short, B1txor20 is a Backdoor for the Linux platform, which uses DNS Tunnel technology to build C2 communication channels. In addition to the traditional backdoor functions, B1txor20 also has functions such as opening Socket5 proxy and remotely downloading and installing Rootkit.” reads the analysis published by the experts.

Once the system has been compromised, the threat connects the C2 using the DNS tunnel and retrieves and executes commands sent by the server. The researchers noticed that the bot supports a total of 14 commands that allows it to execute arbitrary commands, upload system information, manipulate files, starting and stopping proxy services, and creating reverse shells.

“Generally speaking, the scenario of malware using DNS Tunnel is as follows: Bot sends the stolen sensitive information, command execution results, and any other information that needs to be delivered, after hiding it using specific encoding techniques, to C2 as a DNS request; After receiving the request, C2 sends the payload to the Bot side as a response to the DNS request. In this way, Bot and C2 achieve communication with the help of DNS protocol.” continues the analysis.

The post includes additional technical details along with Indicators of Compromise (IoCs) for this threat.

Indicators of Compromise Associated with BlackByte Ransomware: Joint Cybersecurity Advisory

Tags: B1txor20 Linux botnet, Indicators of Compromise, IoC


Apr 09 2021

How do I select an attack detection solution for my business?

Category: Attack Matrix,Cyber Attack,DNS Attacks,MitM AttackDISC @ 8:33 am

When selecting an attack detection solution, no single product will provide the adequate detection needed that is required to detect and defend against the current advanced threat landscape. The holistic aspect of defending against threat actors requires technology, expertise, and intelligence.

The technology should be a platform of integrated technologies providing detection at each point of entry that a threat actor may use such as email, endpoint, network, and public cloud. These should not be disparate technologies that don’t work together to holistically defend the organization.

We must use technologies that can scale against threat actors that have a very large number of resources. The technology should also be driven by intelligence cultivated from the frontlines where incident responders have an unmatched advantage. It is also important to remember that post-exploitation, threat actors masquerade as your own employee’s making it difficult to know legitimate from non-legitimate activity occurring on the network or your endpoints.

This is where intelligence and expertise is extremely valuable to determine when a threat actor is operating within the organization. Being able to identify the threat actors “calling card” and potential next moves, is paramount. While many solutions will claim they defend against advanced threats, it is important to understand the experience that a vendor has and how that is included into their product offering.

How do I select an attack detection solution for my business?

Tags: attack detection solution


Jan 20 2021

List of DNSpooq vulnerability advisories, patches, and updates

Category: DNS Attacks,Information SecurityDISC @ 11:37 am
DNSpooq

Yesterday, seven Dnsmasq vulnerabilities were disclosed, collectively known as DNSPooq, that attackers can use to launch DNS Cache Poisoning, denial of service, and possibly remote code execution attacks, on affected devices.

Dnsmasq is a widely used open-source Domain Name System (DNS) forwarding application commonly installed on routers, operating systems, access points, and other networking equipment. 

Vendors have started to release information on how customers can protect themselves from DNSPooq. To make it easier to find this information, BleepingComputer will be listing security advisories as they are released. 

The related CVEs from JSOF’s DNSpooq advisory are listed below, along with their descriptions.

NameCVSSDescription
CVE-2020-256818.1Dnsmasq versions before 2.83are susceptible to a heap-based buffer overflow in sort_rrset() when DNSSEC is used. This can allow a remote attacker to write arbitrary data into target device’s memory that can lead to memory corruption and other unexpected behaviors on the target device.
CVE-2020-256828.1Dnsmasq versions before 2.83 are susceptible to buffer overflow in extract_name() function due to missing length check, when DNSSEC is enabled. This can allow a remote attacker to cause memory corruption on the target device.
CVE-2020-256835.9Dnsmasq versions before 2.83 are susceptible to a heap-based buffer overflow when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in get_rdata() and cause a crash in dnsmasq, resulting in a Denial of Service.
CVE-2020-256875.9Dnsmasq versions before 2.83are vulnerable to a heap-based buffer overflow with large memcpy in sort_rrset() when DNSSEC is enabled. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in sort_rrset() and cause a crash in dnsmasq, resulting in a Denial of Service.
CVE-2020-256844A lack of proper address/port check implemented in dnsmasq versions
CVE-2020-256854A lack of query resource name (RRNAME) checks implemented in dnsmasq’s versions before 2.83 reply_query function allows remote attackers to spoof DNS traffic that can lead to DNS cache poisoning.
CVE-2020-256864Multiple DNS query requests for the same resource name (RRNAME) by dnsmasq versions before 2.83 allows for remote attackers to spoof DNS traffic, using a birthday attack (RFC 5452), that can lead to DNS cache poisoning.

BleepingComputer suggests checking this page throughout the coming days to see if new information is available for devices you may be using.

Source: List of DNSpooq vulnerability advisories, patches, and updates


Aug 06 2020

Hackers abuse lookalike domains and favicons for credit card theft

Category: DNS Attacks,HackingDISC @ 10:58 pm

Hackers are abusing a new technique: combining homoglyph domains with favicons to conduct credit card skimming attacks.

Source: Hackers abuse lookalike domains and favicons for credit card theft



Credit Card Scammers on the Dark Web
httpv://www.youtube.com/watch?v=jT-jmq8KBw0



Preventing Credit Card Fraud: A Complete Guide for Everyone from Merchants to Consumers




PCI Compliance

Download a Security Risk Assessment Steps paper!

Subscribe to DISC InfoSec blog by Email

Take an awareness quiz to test your basic cybersecurity knowledge

DISC InfoSec 🔒 securing the business 🔒 via latest InfoSec titles




Tags: abuse lookalike domains, credit card theft


Feb 20 2019

A Deep Dive on the Recent Widespread DNS Hijacking Attacks

Category: DNS AttacksDISC @ 5:24 pm

The U.S. government — along with a number of leading security companies — recently warned about a series of highly complex and widespread attacks that allowed suspected Iranian hackers to siphon huge volumes of email passwords and other sensitive data from multiple governments and private companies. But to date, the specifics of exactly how that attack went down and who was hit have remained shrouded in secrecy.

  • Source: A Deep Dive on the Recent Widespread DNS Hijacking Attacks