The first thing I think you should know is that a common "hack" we've been seeing lately is various bad actors finding their way into one of the verification methods for the domain, and then claiming the domain and putting their own sitemap into the Google Search Console. I'd suggest changing the passwords for each attack vector (regularly), and enable MFA/2FA on all of them, if possible.  Then, go back into your Google Search Console and be sure your Sitemap is still active.  You may want to delete it and add it back again, even.  

Next, are the URLs actually 404-ing?  If they are, do you see anything related in your errors logs?  

I'd also suggest running the Security Analyzer, just in case something else known is occurring.  You'll find this in the Security portion of the persona bar (logged in as a superuser).  

Hi Will. Thank you so much for your reply. 

You suggest "changing the passwords for each attack vector (regularly), and enable MFA/2FA on all of them, if possible." I'm not sure I understand what you mean. If you are talking about the credentials for someone to login to Google Search Console, then I can assure you that I have 2FA enabled for each one of them, using Ybikeys. If that's not the case, could you please clarify what you mean?

Regarding the sitemap, I've already tried to remove it and add it back to the Search Console with no success. I always get a "Your Sitemap appears to be an HTML page. Please use a supported sitemap format instead." status, although the Sitemaps opens perfectly in the browser and it certainly is an XML. I even tried to save it as a static XML file and submit this to Google Search Console, with no success.

About the 404s, they are not actual 404 errors but they seem to have been indexed by Google somehow. One strange behavior that I've found though, is that there are some non-existing indexed paths (eg /android) that do not redirect to 404 error page and they produce a blank page. While all other non-existing paths redirect to the 404 error pages as they were supposed to.

Finally, the Security Analyzer hasn't revealed any findings. 

Thanks again for your response.

Posted By Batcic on 6/25/2023 10:11 PM

You suggest "changing the passwords for each attack vector (regularly), and enable MFA/2FA on all of them, if possible." I'm not sure I understand what you mean. If you are talking about the credentials for someone to login to Google Search Console, then I can assure you that I have 2FA enabled for each one of them, using Ybikeys. If that's not the case, could you please clarify what you mean?

Your server, your hosting control panel, your FTP, your domain management/DNS, etc.  Change your password everywhere, is what the suggestion was - along with enabling multi-factor authentication in each place that allows you to do so.  The root reason is below, but the short of it is that you need to keep people out of the places that allows one to verify "ownership" over the website/domain.  Only YOU should be able to do that - or specific authorized personnel.  

Posted By Batcic on 6/25/2023 10:11 PM

Regarding the sitemap, I've already tried to remove it and add it back to the Search Console with no success. I always get a "Your Sitemap appears to be an HTML page. Please use a supported sitemap format instead." status, although the Sitemaps opens perfectly in the browser and it certainly is an XML. I even tried to save it as a static XML file and submit this to Google Search Console, with no success.

This is usually just a warning, but you can add a redirect rule to your web-dot-config to get rid of this message entirely.  Some earlier versions of DNN allowed the site map to be delivered as an XML path out of the box, but it's since disappeared.  Here's an example URL rewrite rule, but it requires first installing the IIS URL Rewrite Module on your web server first.  (It's possible that it's already installed.)  

        <rule name="XML SiteMap" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*sitemap.xml" />
          <action type="Rewrite" url="{R:1}sitemap.aspx" appendQueryString="true" />
        </rule>

Posted By Batcic on 6/25/2023 10:11 PM

About the 404s, they are not actual 404 errors but they seem to have been indexed by Google somehow. One strange behavior that I've found though, is that there are some non-existing indexed paths (eg /android) that do not redirect to 404 error page and they produce a blank page. While all other non-existing paths redirect to the 404 error pages as they were supposed to.

This so far appears to be because someone else in another Google Search Console account has likely compromised one of the verification methods for your domain/site.  Once they entered their own site map, those URLs are attempted to be indexed by Google.  Hence, the 404 errors.  It may not make a ton of sense at first glance, but there are likely other (unintended and/or unwanted) URLs that are working fine that you have no log for.  This is part of the hack... Raising awareness on the search engine index for other content you may not be aware of - potentially related to another attack. 

This doesn't mean that another attack was successful, but if it were, this hack has huge benefits for those who accomplish it.  If they were to hack both the site map verification, and certain URLs/content, this allows them to artificially bump up other non-reputable websites using your site/domain/site map.  

Posted By Batcic on 6/25/2023 10:11 PM

Finally, the Security Analyzer hasn't revealed any findings. 

This is good news.  I'd also suggest pulling a copy of the files and running them through a virus scan, merely as a precaution.  It's most likely that this will not yield any new issues. 🤞🏽