Be careful, we're not joking, this page is not here to scare you but rather to collect all the good ideas and comments on this subject as we go along.
A skilled hacker could get in without leaving too many traces, modify the RIB of your bank account and send your invoices to your customers with his RIB … by the time you realise the problem (generally 1 month or 2, the time to follow up customers telling them “you haven't paid” and them replying “yes, look”) … you will then be in the classic case of the fake RIB scam, it doesn't just happen to other people. (https://www.cybermalveillance.gouv.fr/tous-nos-contenus/fiches-reflexes/que-faire-en-cas-de-fraude-au-virement-ou-au-faux-rib)
If he's a little less of a “Dolibarr specialist”, stealing your e-mail account login and password will already be a nice trophy …
This is all the more urgent if your dolibarr is old. Don't leave a “roughly repaired” Dolibarr online if it's not on a “current” or “just previous” version. (For example, today the latest stable version is 17.0.2, 16.0.5 is considered reliable, but don't leave 11.0.0 online, for example).
You might say to yourself “the shot has been fired” … yes but no, don't go to sleep or wait until “next Monday” to move on …
Is it just a hacking attempt? A simple message on the home page? Or something more serious, with the creation of an administrator account and an open session? Or even worse, a local system account created with escalation of privileges (the absolute horror in this case is a total reinstallation of the server, which you need to plan, plus a security audit of your infrastructure to check that there has been no contagion).
At this stage, only a security and Dolibarr expert can really analyse the situation.
In any case, you will need to consult your web server's system logs (which are outside Dolibarr): copy them as soon as possible to avoid them being deleted by a scheduled log cleaning task (although normally there is a fairly long retention period).
With these logs you will be able to isolate the queries that have been carried out and thus take the measure of reality.
Example:
No big deal, he only downloaded the country flags … well, it would be strange if he'd stopped there!
192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/ax.png HTTP/1.1" 200 693 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/ky.png HTTP/1.1" 200 701 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/ck.png HTTP/1.1" 200 695 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/fo.png HTTP/1.1" 200 670 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/fk.png HTTP/1.1" 200 700 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/fj.png HTTP/1.1" 200 700 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/gs.png HTTP/1.1" 200 691 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/hm.png HTTP/1.1" 200 707 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/mh.png HTTP/1.1" 200 699 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/um.png HTTP/1.1" 200 698 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/sb.png HTTP/1.1" 200 697 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/pn.png HTTP/1.1" 200 697 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/sj.png HTTP/1.1" 200 684 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/tc.png HTTP/1.1" 200 695 ... 192.168.99.99 - - [20/Jun/2023:23:08:19 +0200] "GET /theme/common/flags/vi.png HTTP/1.1" 200 704 ...
Another, much more critical example: he has downloaded the backup of your database. In this case, consider that you are dealing with a total data leak (see the RGPD paragraph at the end of this message).
192.168.99.99 - - [13/Apr/2023:12:24:17 +0200] "GET /document.php?modulepart=systemtools&attachment=1&file=backup%2Fmysqldump_dolibarr_13.0.5_202304131224.sql.gz HTTP/1.1" 200 6349611
Some older versions of dolibarr stored user passwords “in clear text”, so it is absolutely urgent and a priority to inform your colleagues by phone or SMS but above all not by email (imagine that their email password is the same as the dolibarr password, it's bad practice but it's common) … explain the situation to them and tell them to change their password if it's the same on their mailbox and other online services.
And even if your recent Dolibarr stores encrypted passwords, consider them to be cracked: the hacker has the result of the encrypted password in his hands and with the help of recent techniques (and/or high computing power) he can possibly discover your password. Consider that it was in clear text and apply the same approach.
This list is not exhaustive:
Think about YOUR bank details and also those of your customers/suppliers if you store this information in your dolibarr.
Check that this information has not been altered, otherwise in a few months you may discover that you have transferred money to the account of a pirate who thought he was paying your supplier. Conversely, your invoices could show your pirate's bank details instead of your bank details and your customers will think they are paying you by sending them money.
The best solution in this case is to make a “diff” with a backup of your database prior to the attack…
The attacker's sole aim may have been to use your hosting as a spam relay, so the security audit should ensure that no tools have been installed for this purpose.
It is also possible that the attacker's objective was to use your hosting as a pivotal platform for hacking into another site. This is especially true now that there are organisations that refuse all incoming connections from an IP address geographically located in certain countries. Hackers in these countries set up “bounce” servers, and yours may be one of them.
etc.
If the hacker has managed to connect, you should undoubtedly initiate the ad-hoc procedures required by law (the RGPD in this case):
To avoid such a situation happening again as much as possible:
If you have access to your dolibarr server a number of simple measures can be taken to avoid or slow down this kind of problem: