What is a beg bounty? How to avoid paying out for DMARC vulnerability 

Every business has vulnerabilities, and the attack surface for larger and enterprise organizations is vast. In an ideal world, you’d be able to spot, mitigate, weed out, and secure each and every one of these vulnerabilities yourself. But in the ever-evolving age of online, this just isn’t feasible. This is where responsible disclosure and bug bounty programs come in. They give organizations insight into potential vulnerabilities, while bug bounty hunters (often zealous ethical hackers and keen security researchers) earn a few bucks too. 

Bug bounties and responsible disclosure programs are important for maintaining security and mitigating the many vulnerabilities in the armor of global organizations. But as with most things, where there are opportunities to take advantage, some people will. That’s right, we’re talking about the increasingly bothersome craze of ‘beg bounty hunting’, where aptly named ‘bounty beggars’ surface easily-discoverable issues to organizations in the hope of making a quick buck.

So how can businesses avoid falling foul of beg bounties? One way is by implementing DMARC at p=reject by default, mitigating their DMARC vulnerability for good. DMARC (Domain-Based Message Authentication, Reporting, and Conformance) is crucial to organizational security, and with the right tools, it’s a lot easier to implement than you might think.

What is a responsible disclosure program/bug bounty program?

A responsible disclosure program (sometimes called a vulnerability disclosure program or bug bounty program) is essentially a deal an organization makes with security researchers (bug bounty hunters), compensating them if they find vulnerabilities within their websites, systems, platforms, or wider attack surface. 

Responsible disclosure is nothing new. Since it began in 1983, more than 181,000 vulnerabilities have been reported, and a hefty $100 million paid out in bug bounty hunter salaries. In essence, responsible disclosure is a win-win: organizations can discreetly fix vulnerabilities fast, and bug bounty hunters are fairly rewarded. The most high-profile tech companies have responsible disclosure programs, including Mozilla, Facebook, Yahoo, Google, Reddit, and Microsoft. 

Most companies will have a vulnerability disclosure policy in place, with a specific set of rules or agreements for bug bounty hunters to adhere to. The NCSC (National Cyber Security Centre) offers a useful vulnerability discovery toolkit for businesses here.

What is a beg bounty program?

A beg bounty is a term used to describe the surfacing of an easily discoverable issue by a ‘bounty beggar’. These aren’t deemed worthy of payment, either because they’re not a legitimate vulnerability, or are considered as an issue that could have been easily spotted by the company itself. Sometimes, bounty beggars also request payment before exposing the supposed ‘bug’. Examples of beg bounties include broken DMARC records, broken SPF records, or a missing CSP.

Is DMARC a beg bounty?

Missing DMARC records are considered beg bounties. Reasons for this range from DMARC being easily discoverable, the idea that it’s unimportant, too complex to implement, and even the incorrect belief that DMARC is synonymous with SPF and DKIM – it isn’t.

While we agree companies shouldn’t be paying out for DMARC beg bounties, we also feel that by striking DMARC off as ‘unimportant’, Security and IT professionals are missing a trick. While DMARC isn’t specifically a website vulnerability or ‘bug’, not having it fully configured does make your domain – and organization – extremely vulnerable to impersonation and phishing attacks, such as BEC. 

  • Phishing accounts for 90% of all data breaches, with 65% of cyber attackers using spear phishing as a primary infection vector.
  • BEC accounted for around $2.4 billion USD in reported losses – up 28% since 2020.
  • Impersonation attacks were named the second most disruptive to a business by the UK Government Cyber Security Breaches Survey in 2021.

Having no DMARC record (or a record at none/quarantine) does mean you’re vulnerable to impersonation. It’s a protocol that should be foundational to your email security and domain infrastructure, and organizations should be securing it by default

DMARC is a vulnerability in your attack surface

DMARC (Domain-Based Message Authentication, Reporting, and Conformance) is a globally recognized protocol that, when properly configured at p=reject, works to stop bad actors from impersonating (spoofing) your domain to send phishing emails and carry out phishing and impersonation attacks, such as Business Email Compromise (BEC).

Often combined with social engineering, spoofed emails are incredibly difficult to spot. After all, why wouldn’t you trust a well-crafted, personalized email if it’s coming from your organization’s exact domain? It’s because of this that not implementing a strong DMARC policy is one of the biggest mistakes a company can make, as it leaves your domain open to attackers to hijack and send phishing emails targeting your employees, customers, and entire supply chain.

What does DMARC vulnerability look like worldwide?

Using data from Red Sift’s BIMI Radar, which covers 64 million apex domains, we’ve found that DMARC vulnerability around the world is high. Based on the data from more than 64 million apex domains:

  • Only 2.1% have DMARC at enforcement, meaning 97.9% are at risk of impersonation attacks.
  • Of 2,380 domains owned by the largest publicly traded companies in the largest economies in the world, 70.5% are not DMARC protected.
  • 51% of public companies in the U.S., as measured by the Fortune 500, do not have an adequate DMARC policy in place.

DMARC vulnerability needs to be secured by default, SPF and DKIM aren’t enough

SPF and DKIM records are important, but having them correctly configured isn’t enough when it comes to improving your DMARC vulnerability and stopping domain spoofing. Your DMARC record combines the signals from these and gives instructions to receiving servers, telling them what to do with emails from your domain that don’t pass authentication. This can only happen when DMARC is in p=reject.

Avoid beg bounty hunters by implementing DMARC easily

DMARC is the bread and butter of email and domain security, the number one foundational layer of protection for one of your most valuable and vulnerable digital assets: your domain. It’s ready and waiting to secure your most sensitive threat vector (email) and in turn, safeguard your entire organization. 

Red Sift’s flagship product OnDMARC helps organizations across the globe get to p=reject quickly, easily, and reliably. Why not get started with securing your DMARC vulnerability today with a free OnDMARC trial?

PUBLISHED BY

Red Sift

9 Aug. 2022

SHARE ARTICLE:

Categories

Recent Posts

VIEW ALL
Email

The best tools to protect yourself from SubdoMailing

Francesca Rünger-Field

In late February 2024, ‘SubdoMailing’ became a trending search term overnight. Research by Guardio Labs uncovered a massive-scale phishing campaign that had been going on since at least 2022. At the time of reporting, the campaign had sent 5 million emails a day from more than 8,000 compromised domains and 13,000 subdomains with several…

Read more
Product Release

Red Sift’s Spring 2024 Quarterly Product Release

Francesca Rünger-Field

This early into 2024, the cybersecurity space is already buzzing with activity. Emerging standards, such as Google and Yahoo’s bulk sender requirements, mark a new era of compliance for businesses reliant on email communication. At the same time, the prevalence of sophisticated cyber threats, such as the SubdoMailing campaign, emphasizes the continual hurdles posed…

Read more
Email

Navigating the “SubdoMailing” attack: How Red Sift proactively identified and remediated a…

Rebecca Warren

In the world of cybersecurity, a new threat has emerged. Known as “SubdoMailing,” this new attack cunningly bypasses some of the safeguards that DMARC sets up to protect email integrity.  In this blog we will focus on how the strategic investments we have made at Red Sift allowed us to discover and protect against…

Read more
Email

Where are we now? One month of Google and Yahoo’s new requirements…

Rebecca Warren

As of March 1, 2024, we are one month into Google and Yahoo’s new requirements for bulk senders. Before these requirements went live, we used Red Sift’s BIMI Radar to understand global readiness, and the picture wasn’t pretty.  At the end of January 2024, one-third of global enterprises were bound to fail the new…

Read more