Sounds like someone had a Java app and mistakenly exposed all of the JMX endpoints over HTTP. It's not the default configuration, and likely done out of carelessness.
From the Wired article, it may not have even been a mistake, depending on the version of Spring Boot.
"Spring Boot Actuator. “Up until version 1.5 (released in 2017), the /heapdump endpoint was configured as publicly exposed and accessible without authentication by default."
Right!? I learned with a colleague: Didn’t you restrict everything to the Tailnet? Yes, feel free to check UFW. Hmm, then why does nmap show all this stuff when scanning from the lan? Wtf??
Similar here, UFW setup to only enable access via Caddy to our http services - wait, why can I connect directly to our redis instance?
Took a while to workout that for some reason docker-compose is messing directly with iptables to shoot holes in the firewall we'd configured. Figured out you have to write your compose in some super special way to disable that functionality. Compose should never ever open network ports, ever in my book - to do so without a warning or anything though is like I said, insane!
Or intentionally. There could be an APM agent which just lets you run heap dumps any time you want, or they enabled heap-dump-on-crash, or had a heap dump shutdown hook, etc. There's a lot of ways to trigger dumps. If we're talking about a full dump, and the apps were using most of the memory allocated to their container/VM/etc, 410GB is actually not that many dumps (we're probably talking uncompressed). At 4GB/dump, that's around 100, over possibly several years.
I just wonder where they were storing them all? At one place I worked, we jiggered up an auto shutdown dump that then automatically copied the compressed dump to an S3 bucket (it was an ephemeral container with no persistent storage). Wonder if they got in through excessive cloud storage policies and this was just the easiest way to exfiltrate data without full access to a DB.
