Typically this happens through a combination of disabling default security measures (only bind to localhost) and not correctly configuring security measures like access control and firewalls. If you do not have access control enabled on your deployment and anyone can connect remotely, those remote connections will have full administrative access to your deployment. If you do not enable network encryption and connect to your deployment remotely over the public internet (without an encrypted path like a VPN or SSH tunnel), all of your data is exchanged in plaintext and could be subject to eavesdropping.
As @chris noted, there is no hacking effort required if there are no effective security measures in place.
Direct access to your database server should ideally only be allowed from a limited set of origin application IPs that themselves would like be inside the same VPN or firewall perimeter. User access should be authenticated using Role-Based Access Control following the Principle of least privilege. The general security measures are similar for any infrastructure service you want to host and secure.
You can test to make sure the security measures are effective. For example, if access control is enabled you should not be able to run any commands to view or modify data as an authorised user. If firewall configuration is correct, you should be able to connect from whitelisted IPs but not from any other IPs.
Good security involves multiple layers of defence. Normally I would configure & test the inner layers of security (access control, enforcing authentication, TLS/SSL) before opening up to broader levels of exposure (binding to a non-local IP, firewall configuration). Since you have already had some unwelcome connections, I would start by limiting network exposure via your firewall so you can configure and test the other security measures.