Unless you're really good at cleansing Malware from the command line, you best hire someone to assist you.
A complete site cleanse can take days to complete + be very expensive.
Best rule of thumb is avoid every being hacked by using a Hard-To-Hack Hosting company which locks down their machines so hacking is difficult + also blocks installation of any theme or plugin which includes any code which remotely seems like it contains any hack. Unfortunately this quality of Hosting is rare.
If you're on a budget, you can always export your pages + posts + menus, cleanse the database records (especially wp_options table) by hand + reimport these into a pristine WordPress site, which is hosted with a Hard-To-Hack Hosting company, then reinstall your themes + plugins + reconfigure your site from scratch.
_______
Here's how I cleanse sites for clients.
1) Clone site files + database into an LXC container to effect fixes.
2) Bring up site in LXC container
3) Use wp-cli to disable all plugins + change active theme to Twenty Sixteen (or most recent http://WordPress.org theme shipped with core)
Now for the fun...
4) Locate + download + unzip all site's themes + plugins into separate directories + rename them with version strings. For example, core becomes wordpress-4.5.2 so you have a pristine copy of all code on your site.
5) Block any attempts which might run during removal process...
a) Remove any non-core (default) WordPress cron jobs.
b) Using Filesmatch Apache directive to recursively block execution of any files in your WordPress install, unless execution originates via localhost (127.0.0.1 or ::1) address. If you miss this, any external attacker can randomly run any .php script on your site, which has been has been placed onsite as part of the hack.
6) Run a script against core + themes + plugins pristine directories which does this.
a) For any site file that differs from pristine copy, move hacked file out of site into quarantine + copy pristine file to site file location.
b) For any site file that exists that is missing from pristine files, move new file out of site to quarantine area with .new extension.
7) Scan all non-core site files for occurrences of evil strings like base64_debug() + eval() + curl calls. Anything which can download or execute a Malware payload on your site. If any neferiousness is identified, move the entire related wp-content/themes/foo or wp-content/plugins/foo into quarantine adding .nefarious to offending file that triggered this action.
8) Scan wp_options for .css + .js content + remove from wp_options + quarantine into directory called wp-options/option-name.$reason where $reason is what triggered the action.
9) Scan every database record looking for same signatures as #7. Only really stupid hacks will attempt this as these signatures can easily be determined as being out of place + there are many stupid hacks.
For database records which contain Malware payloads, record the original database row, as-is to databases/$dbname/$dbtable/$sequential-number.record.$reason where reason is what triggered action.
Then make an attempt to cleanse record + update database. You can also record the cleansed record in your quarantine to go back later + refine any code required + apply new code to original record + update record again. This is very handy when there are 1000s of hacked database records which must be script edited again.