Caught a .git/config crawler
My infinite web site generator
caught a .git/config crawler.
Last November, I updated my program bork.php to do a better job
of creating .git/config files.
I noticed in my Apache log files that some apparent bad actors
were requesting URLs with a path of .git/config.
That particular file name contains the per repository configuration
information for the git
version control system.
Due to its superiority, git has become the single most popular
version control system ever.
Just for reference, here’s what request body asking my web server
for a .git/config URL gives back:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@github.com:yorgi-gromolski/spintronic-tractor-parts.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
remote = origin
merge = refs/heads/main
[branch "fuck-you-moron"]
url = git@github.com:richard-nixon/fartpipe.git
remote = origin
merge = refs/heads/fuck-you-moron
[branch "nRqEtp3gAecLhY"]
url = git@github.com:bZPVQxEKkSVAqw0mrnI/TbdQETY1MxUb1ETu8j.git
remote = origin
merge = refs/heads/sNvilUBPj8xooSTH
The last branch has a randomly-selected name,
and a randomly-selected URL.
They’re different every time someone asks for /.git/config
I actually have no idea if this is a valid format for a .git/config file.
Some time in mid-2025, people started actively collecting
.git/config files.
I am not all that knowledgeable about git, but it looks to me like
the contents of .git/config aren’t intrinsically valuable.
People apparently keep credentials of various sorts,
user names and passwords, TLS certificates, etc,
in repositories that are under git version control.
I found a bad actor that requested /.git/config,
then spidered an entirely fictional git repository.
Discovery
Between March and September of 2025, I had my web server send Meta (a.k.a. Facebook) web crawlers into an infinite swamp of garbage. I was curious about the effect on Meta’s crawlers, and also leery of the effect on my $4.37 a month VPS, so I kept Apache “combined” format log files. I still keep them, because then I can look through them for other odd behavior.
From the Apache log files, I made myself a chart showing the number of HTTP requests a day my VPS receives.
The dates in the above chart are UTC.
Notice the tall, narrow spike in June 2026. That’s two days, June 19 and 20, where 563057 and 339286 requests arrived respectively. For some sense of magnitude, the other days in June 2026 range between 96,000 and 120,000 requests per day. Meta ramped up to a maximum of 270,000 requests a day.
After a little futzing around, I discovered that a single IPv4 address, 195.178.110.18, had made 434039 of the requests on 2026-06-19, and 220239 of the requests on 2026-06-20.
| Date | Request count |
|---|---|
| 2025-12-24 | 4 |
| 2025-12-25 | 5 |
| 2025-12-28 | 8 |
| 2026-01-01 | 8 |
| 2026-01-11 | 4 |
| 2026-01-12 | 4 |
| 2026-01-14 | 4 |
| 2026-02-26 | 1 |
| 2026-03-04 | 1 |
| 2026-03-07 | 1 |
| 2026-03-15 | 1334 |
| 2026-03-16 | 380 |
| 2026-03-24 | 1 |
| 2026-03-26 | 1 |
| 2026-03-28 | 1 |
| 2026-03-30 | 1 |
| 2026-04-06 | 21 |
| 2026-04-07 | 355 |
| 2026-04-10 | 2 |
| 2026-04-13 | 2 |
| 2026-04-17 | 2 |
| 2026-04-23 | 1 |
| 2026-04-30 | 2 |
| 2026-05-01 | 1 |
| 2026-05-16 | 2 |
| 2026-05-24 | 110 |
| 2026-06-17 | 110 |
| 2026-06-19 | 434039 ← |
| 2026-06-20 | 220239 ← |
| 2026-06-22 | 225 |
| 2026-06-24 | 115 |
| 2026-06-25 | 108 |
| 2026-06-30 | 225 |
I piously hope that garbage responses to 650K requests help 195.178.110.18 through its cybercrime journey.
I ran whois against 195.178.110.18 soon after seeing the request count.
195.178.110.18 is part of 195.178.110.0/24.
Looking through my Apache log files,
I found 59 IP addresses in 195.178.110.0/24 that made 699,774 requests.
| IP Address | Request count |
|---|---|
| 195.178.110.2 | 10 |
| 195.178.110.15 | 420 |
| 195.178.110.18 | 657317 |
| 195.178.110.21 | 2 |
| 195.178.110.25 | 39 |
| 195.178.110.28 | 11 |
| 195.178.110.31 | 19 |
| 195.178.110.33 | 1474 |
| 195.178.110.34 | 748 |
| 195.178.110.38 | 5 |
| 195.178.110.39 | 2 |
| 195.178.110.48 | 557 |
| 195.178.110.54 | 19 |
| 195.178.110.57 | 1 |
| 195.178.110.64 | 9 |
| 195.178.110.65 | 1490 |
| 195.178.110.68 | 258 |
| 195.178.110.75 | 56 |
| 195.178.110.100 | 12 |
| 195.178.110.101 | 172 |
| 195.178.110.102 | 1598 |
| 195.178.110.103 | 1102 |
| 195.178.110.104 | 2 |
| 195.178.110.108 | 3298 |
| 195.178.110.109 | 4027 |
| 195.178.110.125 | 1 |
| 195.178.110.130 | 12 |
| 195.178.110.131 | 2 |
| 195.178.110.132 | 6094 |
| 195.178.110.133 | 672 |
| 195.178.110.135 | 2108 |
| 195.178.110.144 | 1 |
| 195.178.110.146 | 10 |
| 195.178.110.152 | 87 |
| 195.178.110.155 | 17 |
| 195.178.110.157 | 2289 |
| 195.178.110.159 | 3272 |
| 195.178.110.160 | 439 |
| 195.178.110.161 | 633 |
| 195.178.110.162 | 71 |
| 195.178.110.163 | 976 |
| 195.178.110.164 | 429 |
| 195.178.110.186 | 12 |
| 195.178.110.187 | 10 |
| 195.178.110.190 | 70 |
| 195.178.110.191 | 16 |
| 195.178.110.195 | 4 |
| 195.178.110.199 | 8424 |
| 195.178.110.201 | 200 |
| 195.178.110.204 | 11 |
| 195.178.110.218 | 26 |
| 195.178.110.222 | 4 |
| 195.178.110.223 | 410 |
| 195.178.110.224 | 7 |
| 195.178.110.228 | 12 |
| 195.178.110.240 | 431 |
| 195.178.110.241 | 42 |
| 195.178.110.242 | 261 |
| 195.178.110.246 | 73 |
The 195.178.110.0/24 requests date to 2025-03-13,
in the earliest log file I kept.
Most of the URLs requested by 195.178.110.0/24
look like they’re going fishing:
many variations on /$SOMETHING/.git/config, /wp-config.php.save,
/.env, /wp-config.php and other
After reading through the logs, I divide up the requests into 4 categories:
- General scanning for vulnerabilities, with emphasis on,
but not limited to
.git,.env, other config files. Requests in this category arrive throughout the period I have log files for. Requests use 1 or 2 user agents every day. - Scanning for low-hanging PHP vulnerabilities -
phpinfo.php,wp-config.php, etc 2026-03-28, -29, 2026-06-26, -27- only 4 user agents used each day
- Spidering
.git/configcontents 2026-06-19, -20 - Reading front page of blog, reading HTML contents of posts and tags,
trying to parse out referenced URLs, requesting some of them.
- 2026-03-15, -16 large number of user agents relative to other scanning
Category 3 contains the requests which drew my attention in the first place.
Category 1: emphasis on .git/config, .env, other config files
The entire period that I have Apache log files for,
addresses in 195.178.110.0/24 have made requests
for /.git/config, /wp-config.php,
/docker-compose.prod.yml and lots of other obvious
config files.
Because my web site’s HTML does not link to
any of these config files, or even provide them,
the URLs 195.178.110.0/24 requests indicate that it’s
asking for likely URLs, not URLs known to exist.
195.178.110.0/24 even guesses about older
config files, like /.env.save,
and /.env.backup.
In a lot of instances,
the scanner made two GET requests for /.git/config in the same wallclock second,
apparently via HTTP.
My webserver returned a 301 status code, redirecting to an https: schema URL,
which 195.178.110.x promptly asked for.
The 195.178.110.0/24 probing system does HTTP first, then falls back on HTTPS.
My experience with feral, grey area software
written in PHP is that
doing two redundant calls is a common practice.
I’ve wondered how cybercriminals distinguish
which of the redundant calls’ returns to use.
Given that my web server is configured to return different,
randomly-chosen contents for /.git/config HTTP requests,
I’m amazed that 195.178.110.0/24 came back after probing
for various config files and getting multiple different results.
Category 2: PHP low hanging vulnerabilities
During 2026-04-06 and -07, 195.178.110.18 requested
some debug or development PHP programs,
URLs with paths like /server_info.php,
/info.php, /phpinfo.php and /php_info.php.
It’s common to have a PHP file with such a name
that invokes the PHP system function phpinfo().
That system function generates nice HTML about the PHP interpreter
that runs the phpinfo.php program, its configuration, installed modules,
and other information that could give clues about PHP vulnerabilities.
It’s so common to have this kind of program,
and for web spiders to ask for it,
that I have a phpinfo.php program that generates HTML similar to
what the phpfinfo() function outputs, but accurate only by chance.
Some of the requests have “referer” URLs, containing a mix of
“http://bruceediger.com”, “http://crudhammer.com” and “http://stratigery.com”,
3 FQDNs that all resolve to a single IP address, that of my $5 a month VPS.
These are the only requests with referers.
This might be a separate spider operating out of 195.178.110.18,
specializing in PHP and likely vulnerabilities.
These requests spanned 2026-04-06T23 to 2026-04-07T01, 377 requests in 1 hour and 52 minutes, about 0.06 requests per second.
Category 3: Extensive .git related spidering
At 2026-06-19T03:16:46Z, 195.178.110.18 did a GET method
on /.git/HEAD.
It rapidly moved along from there.
During this phase, 195.178.110.18 used no referrers, and only one user agent string:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
After this, I’m not certain of what to make of 195.178.110.18’s
choice of URLs.
The randomly-chosen branch names do show up
as part of HTTP requests for URLs like /.git/refs/heads/M4_bNpd2507HvUJ,
or /.git/refs/remotes/origin/XHgfqRg6Z
I’m not an expert on git internals, so these things escape me.
The .git/config file parsing in this phase wasn’t very good, either.
195.178.110.18 ended up requesting “doubled paths” of some files,
as in /.git/config/.git/config
and /.git/config/.git/logs/refs/heads/A03DSnrylm1LPT
The alternative to “not very good parsing”
is that the parser got confused by my maybe-illegitimate,
randomly-generated .git/config files.
The scanner for this particular phase make just over 210K requests per hour. 2026-06-19 all requests made in the 8pm and 9pm UTC hours. 2026-06-20, all requests made in the 3am hour. That’s about 56 requests per second, which is rather a lot.
Category 4: Front page spidering
2026-03-15, 2026-06-22, -26, -27, it asks for /, posts that were on my web site’s front page,
some “tags” URLs that group posts by topic,
and some odd, apparently garbage URLs whose paths appear to be mis-parsed HTML elements,
and erroneously parsed hyperlink URLs.
The 195.178.110.0/24 system clearly asks for URLs that might exist.
The first URLs I have a log of are requests for /.git/config.
Just as clearly, it tries to parse HTML that it gets in responses.
It doesn’t do a great job of parsing HTML,
because it asks for URLs with paths like //en.wikipedia.org/wiki/Voltage_doubler.
It mistakenly trims off the https: part of the href attributes
of a hyperlink HTML tags, then asks for that as a URL path.
It asks for lots of URLs where the path begins with //
and is part of a hyperlink in my website’s HTML.
It also asks for /body, /dev, /h2, /form
and many other pieces of HTML “end tags”.
I bet it uses regular expressions to parse HTML.
Some of the requests have referrers, all with an http: schema.
The 195.178.110.0/24 system made HTTP requests, then fell back on HTTPS.
2026-05-09, the 195.178.110.0/24 system made 8 requests
which had a path of //cdn.usefathom.com/script.js.
This is a reference to the script that
that Fathom Analytics
has you link to in your HTML.
I removed all the references to script.js
Mon Jul 28 22:14:48 2025 -0600.
The 195.178.110.0/24 system retained information
from a request made at least 9 months previously.
What about 195.178.110.0/24?
iplocation.net says that 195.178.110.18 is in Andorra. Join the Internet, and encounter new people, I guess.
According to whois on 2026-07-01,
the address 195.178.110.18 is part of 195.178.110.0/24,
registered to
Techoff SRV Limited, in London, England.
None of the
195.178.110.0/24 addresses have DNS records.
Looks like Techoff presents itself publicly as
dmzhost.co.
The whois record for 195.178.110.18 lists an abuse
address of dmzhostabuse@gmail.com,
which also appears on the dmzhost.co contacts page.
Techoff SRV Limited is Company number 16090235, according to the quaint UK Company House. A British company operating servers in Andorra seems complicated, like the political and legal arrangements of the Channel Islands. There are certainly allegations of abuse from 195.178.110.0/24 IP addresses.
The dmzhost.co web site offers “offshore KVM private servers”, but I can’t scrounge up a physical location. The “DMZHOST Offshore Webhosting” page claims “EU/RU” physical locations. All prices are given in Euros, not Pounds. The cheapest KVM VPS is €5/mo. July 2026, €5 is $5.70, which isn’t extreme.
Summary
I discovered that 195.178.110.18 had made 650,000 HTTP
requests on my $5 a month VPS web server.
Virtually all of these were for /.git/config,
URLs that might have been composed from the randomly-chosen
contents of /.git/config, and apparently mis-parsing of the config file.
195.178.110.18 is in CIDR 195.178.110.0/24, owned by a UK company, but assigned to machines in a data center in Andorra. All the IP addresses in 195.178.110.0/24 have been reported multiple times for all kinds of abusive behaviors.
Machines using addresses in 195.178.110.0/24 have made low-intensity scans of my web server, concentrating on URLs that are configuration files or credentials of various sorts, often mistakenly left behind after web site development, or just overlooked.
Occasionally, those machines spider the front page of my web site. They apparently parse the HTML they obtain using some method that when looking for hyperlinks, often gives them incorrect URLs. The data from this spidering is retained for months at least.
Rarely, these machines look for PHP files that when requested can reveal PHP interpreter configuration, or WordPress configuration and credentials.
One time 195.178.110.18, a machine in 195.178.110.0/24,
asked form 650,000 URLs all clearly gathered by initially
requesting /.git/config, which my web site generator program
replies to with a plausible, yet randomly-chosen incorrect config
file contents.