• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar

Red Sift Blog

Red Sift Blog
  • redsift.com
  • Featured
  • Who are we?
  • Get in touch
You are here: Home / Email / DMARC / What is a beg bounty? How to avoid paying out for DMARC vulnerability 

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

by Red Sift
August 9, 2022August 15, 2022Filed under:
  • DMARC

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?

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)

Related

Tagged:
  • bug bounty
  • DMARC
  • dmarc vulnerability
  • email security

Post navigation

Previous Post Join Red Sift and SecurityScorecard at Black Hat 2022 Las Vegas
Next Post Catch up on our Ask the Expert Podcast Series here

Primary Sidebar

Subscribe to our blog and be the first to get updates!

Categories

  • AI
  • BEC
  • BIMI
  • Brand Protection
  • Coronavirus
  • Cybersecurity
  • Deliverability
  • DMARC
  • DORA
  • Email
  • Finance
  • Labs
  • News
  • OnINBOX
  • Partner Program
  • Red Sift Tools
  • Work at Red Sift
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • October 2016

Copyright © 2023 · Milan Pro on Genesis Framework · WordPress · Log in