I love investigating internet background radiation, this is interesting research. I've definitely seen spa504g.cfg (IP Phone) and spa112.cfg (Cisco analog terminal adapter) before; you should actually serve these a proper config file and spin up a disposable SIP server so you can (potentially) call them on the phone, send them a fax or even better ATDT ;)
Though, come to think of it these requests are more likely from credential harvesting bots as most ITSP's provision their CPE with a <macaddr>.cfg or similar.
Were the spa504g.cfg pulls coming from the same infosec scanner IPs as everything else or from another source? Curious whether the targeted-looking requests actually separate out from the background noise.
I was thinking the other day that the AI bot infested internet we have now is some sort of Eternal December that is even worse than Eternal September. But we never get Christmas.
Eternal september is more of a concept than a real thing; you had to have seen that by now; almost everything gets ruined when there's no discriminating force.
This reminds me of Slashdot commenters back in the day that tried to include words like "bomb" in their signatures in the hopes of flagging some government system. I am glad that people haven't gotten tired of this sort of tomfoolery and have adapted it for a modern world :)
On the shell host they provided, it would reliably hang up lots of modems if someone ‘fingered’ you back in the day. You could do it in busy IRC channels well onto the 2000’s and still see some people drop off line.
That only works on modems that don't support the (patented) delay requirement betwixt +++ and a command that Hayes instituted...which was actually quite a large percentage of them by the time v.34 came 'round.
Plus, the string needs to come from the DTE side of things (the user's local PC), not the remote end. So, with finger and IRC channels alike: The hack relies upon the ISP's modem to behave in that way, and not the end-user's.
As a workaround for the latter, a person could encapsulate the string into payloads for ICMP pings. User's machine receives and responds to the ping, and this response packet hangs up their connection.
As a way to weaponize that without things like IRC that leak WAN network addresses, a person could sometimes finger the target's ISP's terminal servers to see which users were logged into which ports and deduce the target's IP address from that. This way, the ping can show up before they even get back onto IRC.
The non Hayes version was called Time Independent Escape Sequence or TIES, but there were multiple versions of these problems, with the later attacks documented in CVE-1999-1228 where you did have to have some form of echo/ping/icmp to work on a client device.
The earlier issue with finger was due to manufactures having brain dead firmware and using AT commands for voice features in the 14.4 modems etc... I can't seem to find it in the usenet archives that are still around, or at least with current search engine tuning.
Similarly some AV software would “listen” to your IRC comms to check for c&c indicators which meant you could paste it into a channel and a pile of people would disconnect (and you’d be quickly banned).
Not sure if it counts but I point many DNS records to 169.254.169.254 so that skiddies will scan the cloud init management interface of their VPS in hopes to draw attention. The result was the skiddies on Amazon AWS and DigitalOcean filtered my domains from their scan target lists.
If I'm not mistaken, it's not a prompt injection attempt, but a training data pollution, in order to prepare for a prompt injection later :) great idea
No kidding. I have a few personal services running on Internet-facing servers and they get hammered 24/7.
One of my projects is written in Rails and I had left the server on the default verbosity during development. It accumulated several GB of systemd/journald logs in a matter of weeks.
Though, come to think of it these requests are more likely from credential harvesting bots as most ITSP's provision their CPE with a <macaddr>.cfg or similar.
reply