I would strongly advise you not try an refactor this code.
You are in a no win situation here, any new features you add may introduce a bug in an existing feature for which there is no test. However, if you refactor that existing feature you are just as likely to create bugs in other features.
If you sell refactoring to the business as "we need to spend some time making the system less buggy and testable", in 3 months you will end up with an even more buggy system with a few more tests the business will not be pleased!
Furthermore you will probably find that the requirements for the system are "whatever it does now". Writing tests for it will not be easy.
Your best bet is to get firm requirements on new features and make sure you make tests for them. Bugs in old features, well you can say "do you want me to write tests for that feature? what are the requirements of how it should work?".
Once you are more familiar with the project only then start replacing bits as they are upgraded with new features.
Advanced user advice:
If you really want to have the product working 100% then you absolutely need to have the business buy in for a "big rewrite" project.
This goes well beyond the scope of the development team, as before you can start programming you will need to gather and understand both the original requirements of the system and also how it is actually used day to day.
You'll need to setup a separate test environment for the existing system. Assume that normal business as usual development will continue while the rewrite project is in progress.
Once you have these you can start writing functional tests for the current system. Don't touch the code until these are done. You're bound to find a number of existing bugs, or shall we say differences between what people thought the requirements were and what the system does. These will require extensive meetings to resolve, maybe the system is right and the requirements are wrong, maybe they are both wrong, maybe they are right but not what the business needs anymore.
Only once you have a full suite of functional tests all passing can you even think out changing the code; and remember, while your doing that another team is plugging away adding more features that you will have to duplicate on the 'new system' before you can go live.
If you manage to do all this, overtake the business as usual team and release then you have a product with the exact same features it had at the start of the process. It's a very hard sell to make to a business if the product is basically working ok.