Microsoft today released updates to fix 113 security vulnerabilities in its various Windows operating systems and related software. Those include at least three flaws that are actively being exploited, as well as two others which were publicly detailed prior to today, potentially giving attackers a head start in figuring out how to exploit the bugs.

Nineteen of the weaknesses fixed on this Patch Tuesday were assigned Microsoft’s most-dire “critical” rating, meaning malware or miscreants could exploit them to gain complete, remote control over vulnerable computers without any help from users.

Near the top of the heap is CVE-2020-1020, a remotely exploitable bug in the Adobe Font Manager library that was first detailed in late March when Microsoft said it had seen the flaw being used in active attacks.

The Adobe Font Manager library is the source of yet another zero-day flaw — CVE-2020-0938 — although experts at security vendor Tenable say there is currently no confirmation that the two are related to the same set of in-the-wild attacks. Both flaws could be exploited by getting a Windows users to open a booby-trapped document or viewing one in the Windows Preview Pane.

The other zero-day flaw (CVE-2020-1027) affects Windows 7 and Windows 10 systems, and earned a slightly less dire “important” rating from Microsoft because it’s an “elevation of privilege” bug that requires the attacker to be locally authenticated.

Many security news sites are reporting that Microsoft addressed a total of four zero-day flaws this month, but it appears the advisory for a critical Internet Explorer flaw (CVE-2020-0968) has been revised to indicate Microsoft has not yet received reports of it being used in active attacks. However, the advisory says this IE bug is likely to be exploited soon.

Researchers at security firm Recorded Future zeroed in on CVE-2020-0796, a critical vulnerability dubbed “SMBGhost” that was rumored to exist in last month’s Patch Tuesday but for which an out-of-band patch wasn’t released until March 12. The problem resides in a file-sharing component of Windows, and could be exploited merely by sending the victim machine specially-crafted data packets. Proof-of-concept code showing how to exploit the bug was released April 1, but so far there are no indications this method has been incorporated into malware or active attacks.

Recorded Future’s Allan Liska notes that one reason these past few months have seen so many patches from Microsoft is the company recently hired “SandboxEscaper,” a nickname used by the security researcher responsible for releasing more than a half-dozen zero-day flaws against Microsoft products last year.

“SandboxEscaper has made several contributions to this month’s Patch Tuesday,” Liska said. “This is great news for Microsoft and the security community at large.”

Once again, Adobe has blessed us with a respite from updating its Flash Player program with security fixes. I look forward to the end of this year, when the company has promised to sunset this buggy and insecure program once and for all. Adobe did release security updates for its ColdFusion, After Effects and Digital Editions software.

Speaking of buggy software platforms, Oracle has released a quarterly patch update to fix more than 400 security flaws across multiple products, including its Java SE program. If you’ve got Java installed and you need/want to keep it installed, please make sure it’s up-to-date.

Now for my obligatory disclaimers. Just a friendly reminder that while many of the vulnerabilities fixed in today’s Microsoft patch batch affect Windows 7 operating systems — including all three of the zero-day flaws — this OS is no longer being supported with security updates (unless you’re an enterprise taking advantage of Microsoft’s paid extended security updates program, which is available to Windows 7 Professional and Windows 7 enterprise users).

If you rely on Windows 7 for day-to-day use, it’s to think about upgrading to something newer. That something might be a computer with Windows 10. Or maybe you have always wanted that shiny MacOS computer.

If cost is a primary motivator and the user you have in mind doesn’t do much with the system other than browsing the Web, perhaps a Chromebook or an older machine with a recent version of Linux is the answer (Ubuntu may be easiest for non-Linux natives). Whichever system you choose, it’s important to pick one that fits the owner’s needs and provides security updates on an ongoing basis.

Keep in mind that while staying up-to-date on Windows patches is a must, it’s important to make sure you’re updating only after you’ve backed up your important data and files. A reliable backup means you’re not losing your mind when the odd buggy patch causes problems booting the system.

So do yourself a favor and backup your files before installing any patches. Windows 10 even has some built-in tools to help you do that, either on a per-file/folder basis or by making a complete and bootable copy of your hard drive all at once.

As always, if you experience glitches or problems installing any of these patches this month, please consider leaving a comment about it below; there’s a better-than-even chance other readers have experienced the same and may chime in here with some helpful tips. Also, keep an eye on the AskWoody blog from Woody Leonhard, who keeps a close eye on buggy Microsoft updates each month.

Further reading:

Qualys breakdown on April 2020 Patch Tuesday

SANS Internet Storm Center on Patch Tuesday

The U.S. federal government is now in the process of sending Economic Impact Payments by direct deposit to millions of Americans. Most who are eligible for payments can expect to have funds direct-deposited into the same bank accounts listed on previous years’ tax filings sometime next week. Today, the Internal Revenue Service (IRS) stood up a site to collect bank account information from the many Americans who don’t usually file a tax return. The question is, will those non-filers have a chance to claim their payments before fraudsters do?

The IRS says the Economic Impact Payment will be $1,200 for individual or head of household filers, and $2,400 for married filing jointly if they are not a dependent of another taxpayer and have a work eligible Social Security number with adjusted gross income up to:

• $75,000 for individuals
• $112,500 for head of household filers and
• $150,000 for married couples filing joint returns

Taxpayers with higher incomes will receive more modest payments (reduced by $5 for each $100 above the $75,000/$112,500/$150,000 thresholds). Most people who who filed a tax return in 2018 and/or 2019 and provided their bank account information for a debit or credit should soon see an Economic Impact Payment direct-deposited into their bank accounts. Likewise, people drawing Social Security payments from the government will receive stimulus payments the same way.

But there are millions of U.S. residents — including low-income workers and certain veterans and individuals with disabilities — who aren’t required to file a tax return but who are still eligible to receive at least a $1,200 stimulus payment. And earlier today, the IRS unveiled a Web site where it is asking those non-filers to provide their bank account information for direct deposits.

However, the possibility that fraudsters may intercept payments to these individuals seems very real, given the relatively lax identification requirements of this non-filer portal and the high incidence of tax refund fraud in years past. Each year, scam artists file phony tax refund requests on millions of Americans, regardless of whether or not the impersonated taxpayer is actually due a refund. In most cases, the victim only finds out when he or she goes to file their taxes and has the return rejected because it has already been filed by scammers.

In this case, fraudsters would simply need to identify the personal information for a pool of Americans who don’t normally file tax returns, which may well include a large number of people who are disabled, poor or simply do not have easy access to a computer or the Internet. Armed with this information, the scammers need only provide the target’s name, address, date of birth and Social Security number, and then supply their own bank account information to claim at least $1,200 in electronic payments.

Unfortunately, SSN and DOB data is not secret, nor is it hard to come by. As noted in countless stories here, there are multiple shops in the cybercrime underground that sell SSN and DOB data on tens of millions of Americans for a few dollars per record.

A review of the Web site set up to accept bank account information for the stimulus payments reveals few other mandatory identity checks to complete the filing process. It appears that all applicants need to provide a mobile phone number and verify they can receive text messages at that number, but beyond that the rest of the identity checks seem to be optional.

For example, Step 2 in the application process requests a number of data points under the “personal verification” heading,” and for verification purposes demands either the amount of the applicant’s Adjusted Gross Income (AGI) or last year’s “self-selected signature PIN.” The instructions say if you do not have or do not remember your PIN, skip this step and follow the instructions in step A above.

More importantly, it appears one doesn’t really need to supply one’s AGI in 2018. “If you didn’t file a return last year, enter 0,” the site explains.

In the “electronic signature,” section at the end of the filing, applicants are asked to provide a cell phone number, to choose a PIN, and provide their date of birth. To check the filer’s identity, the site asks for a state-issued driver’s license ID number, and the ID’s issuance and expiration dates. However, the instructions say “if you don’t have a driver’s license or state issued ID, you can leave the following fields blank.”

Alas, much may depend on how good the IRS is at spotting phony applications, and whether the IRS has access to and bothers to check state driver’s license records. But given the enormous pressure the agency is under to disburse these payments as rapidly as possible, it seems likely that at least some Americans will get scammed out of their stimulus payments.

The site built to collect payment data from non-filers is a slight variation on the “Free File Fillable Forms” product, which is a free tax filing service maintained by Intuit — a private company that also processes a huge percentage of tax returns each year through its paid TurboTax platform. According to a recent report from the Treasury Inspector General for Tax Administration, more than 14 million Americans paid for tax preparation services in 2019 when they could have filed them for free using the free-file site.

In any case, perhaps Intuit can help the IRS identify fraudulent applications sent through the non-filers site (such as by flagging users who attempt to file multiple applications from the same Internet address, browser or computer).

There is another potential fraud storm brewing with these stimulus payments. An app is set to be released sometime next week called “Get My Payment,” which is designed to be a tool for people who filed tax returns in 2018 and 2019 but who need to update their bank account information, or for those who did not provide direct deposit information in previous years’ returns.

It’s yet not clear how that app will handle verifying the identity of applicants, but KrebsOnSecurity will be taking a look at the Get My Payment app when it launches later this month (the IRS says it should be available in “mid-April”).

In February, KrebsOnSecurity told the story of a private citizen auctioning off the dangerous domain corp.com for the starting price of $1.7 million. Domain experts called corp.com dangerous because years of testing showed whoever wields it would have access to an unending stream of passwords, email and other sensitive data from hundreds of thousands of Microsoft Windows PCs at major companies around the globe. This week, Microsoft Corp. agreed to buy the domain in a bid to keep it out of the hands of those who might abuse its awesome power.

Wisconsin native Mike O’Connor, who bought corp.com 26 years ago but has done very little with it since, said he hoped Microsoft would buy it because hundreds of thousands of confused Windows PCs are constantly trying to share sensitive data with corp.com. Also, early versions of Windows actually encouraged the adoption of insecure settings that made it more likely Windows computers might try to share sensitive data with corp.com.

From February’s piece:

At issue is a problem known as “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.

Windows computers on an internal corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” which is a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.

For instance, if a company runs an internal network with the name internalnetwork.example.com, and an employee on that network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; typing “\\drive1\” alone will suffice, and Windows takes care of the rest.

But things can get far trickier with an internal Windows domain that does not map back to a second-level domain the organization actually owns and controls. And unfortunately, in early versions of Windows that supported Active Directory — Windows 2000 Server, for example — the default or example Active Directory path was given as “corp,” and many companies apparently adopted this setting without modifying it to include a domain they controlled.

Compounding things further, some companies then went on to build (and/or assimilate) vast networks of networks on top of this erroneous setting.

Now, none of this was much of a security concern back in the day when it was impractical for employees to lug their bulky desktop computers and monitors outside of the corporate network. But what happens when an employee working at a company with an Active Directory network path called “corp” takes a company laptop to the local Starbucks?

Chances are good that at least some resources on the employee’s laptop will still try to access that internal “corp” domain. And because of the way DNS name devolution works on Windows, that company laptop online via the Starbucks wireless connection is likely to then seek those same resources at “corp.com.”

In practical terms, this means that whoever controls corp.com can passively intercept private communications from hundreds of thousands of computers that end up being taken outside of a corporate environment which uses this “corp” designation for its Active Directory domain.

The story went on to describe how years of testing — some of which was subsidized by grants from the U.S. Department of Homeland Security — showed hundreds of thousands of Windows computers were constantly trying to send this domain information it had no business receiving, including attempts to log in to internal corporate networks and access specific file shares on those networks.

O’Connor told me he was selling the domain after doing basically nothing with it for 26 years because he was getting on in years and didn’t want his kids to inherit this mess. When he put the domain up for sale, I asked if he’d agree to let me know if and when he sold it.

On Monday evening, he wrote to say that Microsoft had agreed to purchase it. O’Connor said he could  not discuss the terms of the deal, nor could he offer further comment beyond acknowledging the sale of corp.com to Microsoft.

In a written statement, Microsoft said it acquired the domain to protect its customers.

“To help in keeping systems protected we encourage customers to practice safe security habits when planning for internal domain and network names,” the statement reads. “We released a security advisory in June of 2009 and a security update that helps keep customers safe. In our ongoing commitment to customer security, we also acquired the Corp.com domain.”

Over the years, Microsoft has shipped several software updates to help decrease the likelihood of namespace collisions that could create a security problem for companies that still rely on Active Directory domains that do not map to a domain they control.

However, experts say hardly any vulnerable organizations have deployed these fixes for two reasons. First, doing so requires the organization to take down its entire Active Directory network simultaneously for some period of time.

Second, according to Microsoft applying the patch(es) will likely break or at least slow down a number of applications that the affected organization relies upon for day-to-day operations. Faced with either or both of these scenarios, most affected companies probably decided the actual risk of not applying these updates was comparatively low.

It should be noted that while Microsoft’s purchase of corp.com will safeguard companies that built Active Directory infrastructures on top of “corp” or “corp.com,” any company that has tied their internal Active Directory network to a domain they do not control is opening itself to a similar potential security nightmare.

Further reading:

Mitigating the Risk of DNS Namespace Collisions (PDF)

DEFCON 21 – DNS May Be Hazardous to your Health (Robert Stucke)

Mitigating the Risk of Name Collision-Based Man-in-the-Middle Attacks (PDF)

As the Coronavirus pandemic continues to force people to work from home, countless companies are now holding daily meetings using videoconferencing services from Zoom. But without the protection of a password, there’s a decent chance your next Zoom meeting could be “Zoom bombed” — attended or disrupted by someone who doesn’t belong. And according to data gathered by a new automated Zoom meeting discovery tool dubbed “zWarDial,” a crazy number of meetings at major corporations are not being protected by a password.

Each Zoom conference call is assigned a Meeting ID that consists of 9 to 11 digits. Naturally, hackers have figured out they can simply guess or automate the guessing of random IDs within that space of digits.

Security experts at Check Point Research did exactly that last summer, and found they were able to predict approximately four percent of randomly generated Meeting IDs. The Check Point researchers said enabling passwords on each meeting was the only thing that prevented them from randomly finding a meeting.

Zoom responded by saying it was enabling passwords by default in all future scheduled meetings. Zoom also said it would block repeated attempts to scan for meeting IDs, and that it would no longer automatically indicate if a meeting ID was valid or invalid.

Nevertheless, the incidence of Zoombombing has skyrocketed over the past few weeks, even prompting an alert by the FBI on how to secure meetings against eavesdroppers and mischief-makers. This suggests that many Zoom users have disabled passwords by default and/or that Zoom’s new security feature simply isn’t working as intended for all users.

New data and acknowledgments by Zoom itself suggest the latter may be more likely.

Earlier this week, KrebsOnSecurity heard from Trent Lo, a security professional and founder of SecKC, Kansas City’s longest-running monthly security meetup. Lo and fellow SecKC members recently created zWarDial, which borrows part of its name from the old phone-based war dialing programs that called random or sequential numbers in a given telephone number prefix to search for computer modems.

Lo said zWarDial evades Zoom’s attempts to block automated meeting scans by routing the searches through multiple proxies in Tor, a free and open-source software that lets users browse the Web anonymously.

“Zoom recently said they fixed this but I’m using a totally different URL and passing a cookie along with that URL,” Lo said, describing part of how his tool works on the back end. “This gives me the [Zoom meeting] room information without having to log in.”

Lo said a single instance of zWarDial can find approximately 100 meetings per hour, but that multiple instances of the tool running in parallel could probably discover most of the open Zoom meetings on any given day. Each instance, he said, has a success rate of approximately 14 percent, meaning for each random meeting number it tries, the program has a 14 percent chance of finding an open meeting.

Only meetings that are protected by a password are undetectable by zWarDial, Lo said.

“Having a password enabled on the meeting is the only thing that defeats it,” he said.

Lo shared the output of one day’s worth of zWarDial scanning, which revealed information about nearly 2,400 upcoming or recurring Zoom meetings. That information included the link needed to join each meeting; the date and time of the meeting; the name of the meeting organizer; and any information supplied by the meeting organizer about the topic of the meeting.

The results were staggering, and revealed details about Zoom meetings scheduled by some of the world’s largest companies, including major banks, international consulting firms, ride-hailing services, government contractors, and investment ratings firms.

KrebsOnSecurity is not naming the companies involved, but was able to verify dozens of them by matching the name of the meeting organizer with corporate profiles on LinkedIn.

By far the largest group of companies exposing their Zoom meetings are in the technology sector, and include a number of security and cloud technology vendors. These include at least one tech company that’s taken to social media warning people about the need to password protect Zoom meetings!

A GREMLIN IN THE DEFAULTS?

Given the preponderance of Zoom meetings exposed by security and technology companies that ostensibly should know better, KrebsOnSecurity asked Zoom whether its approach of adding passwords by default to all new meetings was actually working as intended.

In reply, Zoom said it was investigating the possibility that its password-by-default approach may fail under certain circumstances.

“Zoom strongly encourages users to implement passwords for all of their meetings to ensure uninvited users are not able to join,” the company said in a written statement shared with this author.

“Passwords for new meetings have been enabled by default since late last year, unless account owners or admins opted out,” the statement continues. “We are looking into unique edge cases to determine whether, under certain circumstances, users unaffiliated with an account owner or administrator may not have had passwords switched on by default at the time that change was made.”

The acknowledgment comes amid a series of security and privacy stumbles for Zoom, which has seen its user base grow exponentially in recent weeks. Zoom founder and chief executive Eric Yuan said in a recent blog post that the maximum number of daily meeting participants — both paid and free — has grown from around 10 million in December to 200 million in March.

That rapid growth has also brought additional scrutiny from security and privacy experts, who’ve found plenty of real and potential problems with the service of late. TechCrunch’s Zack Whittaker has a fairly comprehensive breakdown of them here; not included in that list is a story he broke earlier this week on a pair of zero-day vulnerabilities in Zoom that were publicly detailed by a former NSA expert.

Zoom CEO Yuan acknowledged that his company has struggled to keep up with steeply growing demand for its service and with the additional scrutiny that comes with it, saying in a blog post that for the next 90 days all new feature development was being frozen so the company’s engineers could focus on security issues.

Dave Kennedy, a security expert and founder of the security consultancy TrustedSec, penned a lengthy thread on Twitter saying while Zoom certainly has had its share of security and privacy goofs, some in the security community are unnecessarily exacerbating an already tough situation for Zoom and its tens of millions of users who rely on it for day-to-day meetings.

“What we have here is a company that is relatively easy to use for the masses (comes with its challenges on personal meeting IDs) and is relatively secure,” Kennedy wrote. “Yet the industry is making it out to be ‘this is malware’ and you can’t use this. This is extreme. We need to look at the risk specific applications pose and help voice a message of how people can leverage technology and be safe. Dropping zero-days to the media hurts our credibility, sensationalizes fear, and hurts others.”

“If there are ways for a company to improve, we should notify them and if they don’t fix their issues, we should call them out,” he continued. “We should not be putting fear into everyone, and leveraging the media as a method to create that fear.”

Zoom’s advice on securing meetings is here. SecKC’s Lo said organizations using Zoom should avoid posting the Zoom meeting links on social media, and always require a meeting password when possible.

“This should be enabled by default as a new customer or a trial user,” he said. “Legacy organizations will need to check their administration settings to make sure this is enabled. You can also enable ‘Embed password in meeting link for one-click join.’ This prevents an actor from accessing your meeting without losing the usability of sharing a link to join.”

In addition, Zoom users can disable “Allow participants to join the meeting before the host arrives.”

“If you have to have this feature enabled at least enable “notify host when participants join the meeting before them,” Lo advised. “This will notify you that someone might be using your meeting without your knowledge. If you must keep your meeting unprotected you should enable ‘Mask phone number in the participant list.’ Using the waiting list feature will prevent unwanted participants from accessing your meeting but it will still expose your meeting details if used without a password.”

A spear-phishing attack this week hooked a customer service employee at GoDaddy.com, the world’s largest domain name registrar, KrebsOnSecurity has learned. The incident gave the phisher the ability to view and modify key customer records, access that was used to change domain settings for a half-dozen GoDaddy customers, including transaction brokering site escrow.com.

Escrow.com helps people safely broker all sorts of transactions online (ironically enough, brokering domain sales is a big part of its business). For about two hours starting around 5 p.m. PT Monday evening, Escrow.com’s website looked radically different: Its homepage was replaced with a crude message in plain text:

DomainInvesting.com’s Elliot Silver picked up on the change and got a statement from Matt Barrie, the CEO of freelancer.com, which owns escrow.com.

“During the incident, the hackers changed the DNS records for Escrow.com to point to to a third party web server,” Barre wrote, noting that his security team managed to talk to the hacker responsible for the hijack via telephone.

Barrie said escrow.com would be sharing more details about the incident in the coming days, but he emphasized that no escrow.com systems were compromised, and no customer data, funds or domains were compromised.

KrebsOnSecurity reached out to Barrie and escrow.com with some follow-up questions, and immediately after that pinged Chris Ueland, CEO of SecurityTrails, a company that helps customers keep track of their digital assets.

Ueland said after hearing about the escrow.com hack Monday evening he pulled the domain name system (DNS) records for escrow.com and saw they were pointing to an Internet address in Malaysia — 111.90.149[.]49 (that domain is hobbled here because it is currently flagged as hosting a phishing site). The attacker also obtained free encryption certificates for escrow.com from Let’s Encrypt.

Running a reverse DNS lookup on this 111.90.149[.]49 address shows it is tied to fewer than a dozen domains, including a 12-day-old domain that invokes the name of escrow.com’s registrar — servicenow-godaddy[.]com. Sure enough, loading that domain in a browser reveals the same text that appeared Monday night on escrow.com, minus the redaction above.

It was starting to look like someone had gotten phished. Then I heard back from Matt Barrie, who said it wasn’t anyone at escrow.com that got phished. Barrie said the hacker was able to read messages and notes left on escrow.com’s account at GoDaddy that only GoDaddy employees should have been able to see.

Barrie said one of those notes stated that certain key changes for escrow.com could only be made after calling a specific phone number and receiving verbal authorization. As it happened, the attacker went ahead and called that number, evidently assuming he was calling someone at GoDaddy.

In fact, the name and number belonged to escrow.com’s general manager, who played along for more than an hour talking to the attacker while recording the call and coaxing information out of him.

“This guy had access to the notes, and knew the number to call,” to make changes to the account, Barrie said. “He was literally reading off the tickets to the notes of the admin panel inside GoDaddy.”

In a statement shared with KrebsOnSecurity, GoDaddy acknowledged that on March 30 the company was alerted to a security incident involving a customer’s domain name. An investigation revealed a GoDaddy employee had fallen victim to a spear-phishing attack, and that five other customer accounts were “potentially” affected — although GoDaddy wouldn’t say which or how many domains those customer accounts may have with GoDaddy.

“Our team investigated and found an internal employee account triggered the change,” the statement reads. “We conducted a thorough audit on that employee account and confirmed there were five other customer accounts potentially impacted.”

The statement continues:

“We immediately locked down the impacted accounts involved in this incident to prevent further changes. Any actions done by the threat actor have been reverted and the impacted customers have been notified. The employee involved in this incident fell victim to a spear-fishing or social engineering attack. We have taken steps across our technology, processes and employee education, to help prevent these types of attacks in the future.”

There are many things domain owners can and should do to minimize the chances that domain thieves can wrest control over a business-critical domain, but much of that matters little if and when someone at your domain name registrar gets phished or hacked.

But increasingly, savvy attackers are focusing their attention on targeting people at domain registrars, and at their support personnel. In January, KrebsOnSecurity told the harrowing story of e-hawk.net, an online fraud prevention and scoring service that had its domain name fraudulently transferred to another provider after someone social engineered a customer service representative at e-hawk’s registrar.

Nation-state level attackers also are taking a similar approach. A massive cyber espionage campaign targeting a slew of domains for government agencies across the Middle East region between 2018 and 2019 was preceded by a series of targeted attacks on domain registrars and Internet infrastructure firms that served those countries.

While there is very little you can do to prevent your domain registrar from getting phished or tricked by scammers, there are several precautions that you can control. For maximum security on your domains, consider adopting some or all of the following best practices:

-Use 2-factor authentication, and require it to be used by all relevant users and subcontractors.

-In cases where passwords are used, pick unique passwords and consider password managers.

-Review the security of existing accounts with registrars and other providers, and make sure you have multiple notifications in place when and if a domain you own is about to expire.

-Use registration features like Registry Lock that can help protect domain name records from being changed. Note that this may increase the amount of time it takes going forward to make key changes to the locked domain (such as DNS changes).

-Use DNSSEC (both signing zones and validating responses).

-Use access control lists for applications, Internet traffic and monitoring.

-Monitor the issuance of new SSL certificates for your domains by monitoring, for example, Certificate Transparency Logs.