1) They took action after getting the Stripe key by refunding all customers
2) They drafted an email to all customers after a hack that got the mailing list and API route to send emails
3) Not once has the hacker asked for compensation of any kind nor a ransom
Your friend should take this as a lesson instead of trying to deflect blame to their competitors.
I think you mean “for the lulz”
Definitely not a good idea but it's not an unreasonable motivation.
Breaking things is just fun for them and the internet is their video game.
Also the vibe I am getting from places like reddit/etc... is that it's currently open season on vibe coded apps. Lot's of internet points to be had for destroying them.
I am not saying it is the most likely case or even ethically justified but it is definitely not a super unlikely one. Anyone who thinks that's an impossible scenario has not been in the hacker's shoes.
He's lucky they didn't find a way to use it for card washing.
If someone took money out of your pocket would you call it stealing? What if they gave it to someone else, like a past employer or your parents or a humanitarian organization?
By the way, you should check a dictionary. The definition of "stealing" is literally taking something away without permission.
Protect your keys.
No, it doesn't.
So if I get your house key I can use your bathroom?
Seriously, what hill are you trying to die on here?
Can you name an instance of stealing that could not be described as a forced refund?
Respectfully, what the hell are you talking about?
Imagine you work 40 hours making an app and I pay you for those 40 hours. A third party comes in and says, I'm forcing a refund here - you lose the money you made, but you get the app you made.
How do you feel about this forced refund?
I remember when I was a kid running a tiny forum with phpbb or something, and some script kiddies from g00nsquad (can't remember exact spelling, but something like that) defaced it. They didn't ask for money, they just did it for fun.
Sure things have changed now and the internet has become more corporate, but I reckon there are still people out there doing this stuff l because they can.
I recall a while back there was a story here about a recipe app that used LLMs to generate recipes. It didn't took long before posters started showcasing recipes they tricked the LLM to generate, involving ingredients such as cyanide and computer chips.
The pull is always there.
You can download a few of them out of GitHub and run them immediately, too.
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 test2In 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.
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).
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.
Most of what I see is looking for very specific vulnerabilities - a very high proportion are looking for hidden files and directories being served (e.g. .git, .env) or specific software (e.g. Wordpress), or similar.
In over 20 years of dealing with many mostly smallish businesses the compromises have been:
1. A client who insisted on using Wordpress for one of their sites (against my advice) because they had people who knew it so it was the cheap option. It was easy to see what would happen because those people were not available long term. 2. A very carefully set up server with a hardened kernel etc. I did not set it up so cannot give all details and neither do I know how it was compromised. It was carefully set up because it was a target for political reasons so I would guess it was a targetted attack.
On the other hand I know there have been many vulnerabilities. There have been many vulnerabilities in the applications - the outstanding examples being creating queries by concatenating user input with SQL (no escaping at all) in multiple places across a small site (years ago), and (recently) finding code that called (python) exec on user input. Many other flaws that have been present for years. Not updating OSes, server software and frameworks for many years is usual.
In spite of all that, just those two compromises. You will probably get away with a high degree of bad code and bad practices in deployment and maintenance with a small site.
One those vulnerabilities are found, the hackers will pounce, and, whilst ransomware is one potential outcome, they might instead do all of the kinds of things GP has described. They don't care what the site is for or what industry you're in.
...and work to exploit your code to their own benefit. They don't do this just so that they can refund your customers.