While other answers here are addressing the question asked, I get the impression that the OP is not really addressing the problem. So this is really a comment rather than an answer.
getting the hash of admin password...without knowing the SALT
This rather implies that the salt is held independently of the hash - which suggests that the salt is not randomly generated and unique for each account. That's not good.
just sql-injected our website
While I presume that you are already looking to prevent the SQL injection vulnerabilities, this also implies that the application has direct access to the tables containing authentication information. Erk! Even if you fix the known SQLI vulnerabilities, the application's access to this data should be mediated via SQL procedures with privilege separation.
Obviously we will have to change the algorithm to something unpredictable
Firstly, the sha256 is only part of the algorithm you use to validate passwords. There are a lot of other things to consider here. Simply replacing sha256 with something which is computationally more expensive won't fix an issue elsewhere in your password validation.
I would encourage you to consider the larger picture.
In his answer, SomeGuy suggests using a large, random password. While this will address brute forcing of the hash, it still doesn't help if you've made a mistake elsewhere. It also means that people are more likely to make a record of the password somewhere. Hopefully they do that in a proper password manager rather than on a post-it note, but even the former are not necessarily 100% reliable. You've increased the attack surface.
we would change password every month.
Both NIST and GCHQ have been challenging this received wisdom relatively recently. It certainly wouldn't have provided any protection against the attack you describe. As per the discussion on password complexity, the more frequently you change a password, the more likely it will get communicated and written down.
Given that you can change the code of the application and its open source, I would recommend:
you take a long look at the code round about the call to sha256() - make sure you are using a password stretching function
you use unique, randomly generated salts for each account
you implement two-factor authentication (with a facility to enable this based on privilege or user preference)
you consider privilege isolation of the password hash data