Exploit Attempts After Every Certificate Renewal

I have a Windows server running IIS and a number of websites all secured with Let's Encrypt SSL certs. A few of the sites auto-renewed today via Win-Acme and while I was on the server at the time I noticed my defence software had blocked a couple of IP addresses shortly after the renewals completed.

Searching for these IPs in the web logs revealed they had been trying what seemed to be a short exploit scan on the same seven websites that had just been renewed only seconds earlier. When looking back through the logs for the month I can see the same thing has happened after every single certificate renewal.

A lookup of these IPs usually reveals a hostname similar to xxxxxxxx.dont.youlovethat.company

The company I work for also runs Windows servers with Let's Encrypt certs and Win-Acme handling renewals, I've just had a quick scan through their logs and the exact same thing is present following their renewals too - totally unconnected to my private server.

I'm not sure if it's specific to Windows or Win-Acme but I'm wondering if anyone else has seen similar behaviour like this after renewing their certificates?

All certificates are logged in public logs. There may be (cough) some bad actors who scan these logs looking for attack candidates.

One way to view these logs is with https://crt.sh but there are other ways.

Sounds like your defense software is working just fine.


Ahh I see, I didn't realise renewal logs were public. That would most likely explain it, damn bad actors!


This is a well-known attack vector since at least 2017 if not sooner. All certificates are logged to the public Certificate Transparency logs. Bad actors monitor those logs, and then attempt some exploit scripts against the domain.

Most of these are aimed at exploiting Wordpress installations. It's been covered here before, and in many security newsletters.

By default, Wordpress (and some other targeted apps) do not require any authentication on their initial setup. In this exploit, hackers are looking for newly setup servers that have not setup or locked down wordpress yet. When they find one, they install a malicious payload - which can get them control of the installation or even server - and then erase their activity.

A few webhosts that offer quick-installs of wordpress avoid this by either setting up the initial default user, or installing into an .htacess protected directory.

Sometimes the CT log attacks are looking for other things, but according to everything I've read, the majority of them are looking for just-installed applications (like wordpress) and are basically using the logs to identify a site that is potentially vulnerable.


It certainly seems to be very consistent, although the exploits I'm seeing after renewals don't seem to be specifically targeted at Wordpress - this is a short example from today:

/ rest_route=/wp/v2/users/ 80 - Go-http-client/1.1 - 301 0 64 76
/ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application - 80 - Go-http-client/1.1 - 301 0 0 75
/debug/default/view panel=config 80 - Go-http-client/1.1 - 301 0 64 77
/s/3134392e3130322e3135332e3837/_/;/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties - 80 - Go-http-client/1.1 - 301 0 0 77
/.env - 80 - Go-http-client/1.1 - 301 0 0 121
/.git/config - 80 - Go-http-client/1.1 - 301 0 0 120
/telescope/requests - 80 - Go-http-client/1.1 - 301 0 0 120
/server-status - 80 - Go-http-client/1.1 - 301 0 0 122
/info.php - 80 - Go-http-client/1.1 - 301 0 0 121
/api/search folderIds=0 80 - Go-http-client/1.1 - 301 0 64 77
/v2/_catalog - 80 - Go-http-client/1.1 - 301 0 64 76
/about - 80 - Go-http-client/1.1 - 301 0 0 117
/login.action - 80 - Go-http-client/1.1 - 301 0 0 116
/config.json - 80 - Go-http-client/1.1 - 301 0 0 117
/.DS_Store - 443 - Go-http-client/1.1 - 404 0 0 83
/ rest_route=/wp/v2/users/ 443 - Go-http-client/1.1 - 302 0 0 75
/debug/default/view panel=config 443 - Go-http-client/1.1 - 404 0 0 73

But yes I definitely agree that the majority of attacks I see overall are aimed at Wordpress, I'd say over 50% of the entire logs for my smaller sites are filled with these alone!

1 Like

Yeah, it's (like all engineering) all about tradeoffs: Having all certificates publicly logged helps with accountability of the Certification Authorities (which the users of the web have bestowed a lot of trust to, so having measures to oversee them is good), but then on the flip side it means that all web sites (pretty much) that might exist anywhere are in a list that anyone can get to. (For an interesting visualization, go to Certstream and click "Open the Fire Hose".)

But really, if a site wasn't listed in Certificate Transparency, then the Bad Guys would just get their list of sites some other way. Lists of domain registrations are pretty open, and the search engine web crawlers manage to find every new page fairly quickly as it is. If you have a server publicly accessible, expect it to get hit by anything and everyone (as you seem to be).

One mitigation that some people find worth doing is hiding the actual hostname by only issuing a wildcard certificate. So if you have a server at some.thing.example.com, issue the certificate for *.thing.example.com (which can be a bit trickier since it needs you to use the DNS-based challenge), and then that's the only thing that shows up in the logs and not the full hostname. But that's not really going to prevent a computer from scanning that site, as I said, and for many typical cases won't really help (since if you want to hide www.example.net, if you issue a certificate for *.example.net it's fairly easy for an attacker to guess that one might want to try putting www in there.)

Some links to learn more about certificate transparency, in case it interests you and you want to learn about what benefits it provides:


This is great info, thanks!


An attacker doesn't need to know your domain name either. It can just use the IP address. There are friendly scanners that look at all IPv4 addresses as general security analysis for example. I see this user-agent in my logs regularly:

Expanse, a Palo Alto Networks company, searches across the global IPv4 space multiple times per day to identify customers' presences on the Internet. If you would like to be excluded from our scans, please send IP addresses/domains to: scaninfo@redacted.but.palo.alto.net

I have never been a Palo Alto Networks customer


Two things that could reduce the number of such log entries:

  • use wildcard certificate to conceal the FQDN
    [not as easy to manage - they require DNS-01 authentication]

  • use IP block lists to thwart off those would be attackers/reconnaissance bots


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.