There is no way an attacker could be doing this unless:
- You or another account on the shared hosting server has some kind of shell installed
- And/or attacker has an account on the same server, the host hasn't properly "jailed" accounts/processes (ie CloudLinux), and is SSH'ing to see your account name, files, runtime, etc
- And/or the attacker has compromised (and you are using) server software auto-installer such as Softalicious or Plesk WP manager
- And/or the attacker is originating from your physical network, device, or PC (ie RDP, SSH, backdoor, trojan, keylogger)
- And/or the attacker has your high level login such as Gmail/Lastpass, and is able to see your saved logins/passwords
- And/or you are using a vulnerable plugin that is allowing file/folder traversal/execution. Or you have vulnerable code in place(s) like functions.php (look in default themes too)
- And/or you are using the same hosting password, FTP(s), WebDAV(s), WP login(s), password(s), path(s), or DB name/schema/credentials on the new install
To answer your question regarding localhost install: You can install at localhost, or using host domain (ie like, srv-12ayx.myhosting.com), or anywhere really, then easily migrate to live env. Create a blank WP DB first, import your new DB, and find+replace instances of the localhost/other domain string in DB (ie, settings table).
Then upload a zipped archive of the files of the new WP to wherever you want WP to live. Unzip, make sure config.php DB credentials match new DB, then login as usual. Using a zip is important because uploading all the WP files via something like FTP is slow.
Finally, installing a WAF plugin such as Wordfence can help automate the blocking of nefarious IP's, vulnerable routes, and directory traversal vectors. This plugin also provides whitelisting for your own safe IPs (assuming your PC isn't itself compromised).
I would not recommend static IP blocks/allows in .htaccess, as this is not an effective solution to the issue. It's simply a block, and if/when it's lifted, they will continue to attack the same vector that previously allowed them to exploit you. Additionally, .htaccess will only block IP's at the web root + subfolder level. There are like 20 other levels this attacker could be exploiting that .htaccess can't block.