Who else would spend the time and effort to figure out you leaked your stipe key to your front end? Sure people have bots to do that, but it’s kinda unbelievable someone would run such a bot on their vibe coded website.
Half an hour after the push I got an email and text from GitHub that I had exposed credentials. I quickly logged in to my AWS to turn off the service, to see that AWS had suspended that service because the bounce rate on the 80000 emails sent in that 15 minute period was too high. It was crazy just how fast it was exploited.
People underestimate the speed, but also the number of pivots that advanced attackers will make. Sure, these kinds of problems are easy to exploit, but with major organizations that employ reasonable defenses, the attackers will pivot through 50+ exploits/machines/layers to get to the target(s). This can take place over weeks or months.
1. Distracting from a more important vulnerability
2. Later contacting customers, advising them of the "accidental" refund and redirecting them to a more appropriate payment mechanism (one without the KYC Stripe does, were they to try to steal funds directly)
3. Testing stolen credit cards before using them elsewhere
Etc. Scamming people is a big industry, and not all of the plots are immediately obvious.
The internet is a wild place in any aspect of it. You should try spinning up a random virtual private server on any cloud provider, plug in a public IP address,and listen to traffic. Sometimes it takes seconds to get your first traffic from vulnerability scanners.
Basically a simple server listening on a port will experience hundreds of random script-probing attacks per day. And if any of them show the slightest hint of succeeding then that escalates quickly to thousands per minute.
You don't need a DNS entry to "expose" the IP address (there are only 4 billion). Moving to another port reduces, but doesn't eliminate the traffic.
Telling people this freaks them out. But as long as the server is done well its just noise.
There are groups out there just looking at the certificate transparency logs to get the newly added certs to scan.
Back then, I mostly only ran Linux, but for some reason, I needed to run something on a Windows machine, so started installing Windows 98 SE onto a machine, and set it up with a public IP address without even thinking about it. It crashed before it'd even finished installing [0], and investigation showed that it'd been whacked by an automated RCE exploit scanner.
I immediately decided it was never worth the risk of putting a Windows machine on a public IP, and set up a NAT even though I had 3 spare public IPs.
[0] There was already a published update to protect against this exploit, but I was scanned and hacked between the base install exposing the bug and the automatic update patching it.
Create a new Github repo, within minutes there's someone (or something) poking around it.
Similarly if you post any credentials, they'll either get nabbed and used or a friendly scanner service will notify you about it and will tell you exactly where the credential is if you make an account in their service.
# zcat -f /var/log/auth.log* | awk '/sshd/ && /Invalid user/ && $6 != "from" {print $6}' | sort | uniq -c | sort -bnr | head -n 30
5190 #redacted: my domain name
3063 admin
1891 #redacted: another domain name
931 user
724 ubuntu
287 test
268 solv
206 odoo15
200 solana
197 sol
184 ubnt
173 wialon
170 Antminer
169 guest
168 odoo17
159 oracle
157 postgres
151 git
150 support
142 ftp
135 ftpuser
120 debian
118 pi
91 nginx
85 baikal
82 docker
81 perl
74 operator
74 deploy
72 dev $ journalctl | awk '/sshd/ && /Invalid user/ && $6 != "from" {print $8}' | sort | uniq -c | sort -bnr | head -n 30
34 admin
26 oracle
21 postgres
20 user
18 test
18 seekcy
17 ftpuser
15 ubuntu
15 inspur
9 zabbix
8 nginx
8 mysql
8 jenkins
8 hadoop
7 server
7 nagios
6 teste
6 amax
5 support
5 backup
5 administrator
4 git
4 demo
4 a
3 zyfwp
3 usuario
3 tomcat
3 testuser
3 test1
3 teamspeakI wonder why this features so low in the list. The default user:pass combo for Raspbian/Raspberry Pi OS is pi:raspberry
22307 admin
19668 user
15396 ubuntu
7038 user2
6954 test
6375 debian
3938 ftpuser
3433 postgres
3416 oracle
3076 deploy
3003 steam
2917 user1
2830 dev
2570 test1
2352 es
2187 server
1957 hadoop
1680 alex
1676 guest
1517 testuser
1494 sammy
1392 mysql
1228 minecraft
1218 pi
1184 support
1148 sysadmin
1140 ubnt
1120 from
1090 123456
1035 test2You can download a few of them out of GitHub and run them immediately, too.
In high school in the early 2000’s, I ran a small Apache server from my home that was basically Geocities but even less discoverable - I used it to learn PHP, SQL, and frontend. One day my log started filling rapidly as someone effectively ddos’d my home server. If they’d bothered to actually poke, they likely would’ve been able to exploit it relatively quickly even without all of today’s tools. I imagine the process of discovery and exploitation is magnitudes more impressive and performant today.
I could offer some anecdata as a counterargument but I'm a bit ashamed about how it happened so I'll just say, you friend was lucky it only ended at that.
Your friends' service was just the proverbial paper car in a thunderstorm: the thunderstorm doesn't care about the paper car but destroys it just the same.
I was mirroring this to another machine, and I'd foolishly already configured haproxy to serve from either machine. In the 10 minutes (guesstimate) between starting to populate the directory and closing off access, I had one bot scrape every single file in there. What was worse was that it'd cached the index, and continued scraping these files from the other backend too, so I had to shut off access to that directory on the live server as well as the backup.
Whilst technically, all of these files were "public" because I wanted to share them, some of them weren't publicly linked to (things like my CV etc) which I'd rather hadn't been scraped by some random bot (that of course, didn't identify itself or respect robots.txt).