Drupal website malware - malicous code injected

You'll need to describe what form the code you talk about takes, provide a link to the website and examples of what you are seeing.
It's hard to guess what you are talking about without any facts to start with at all.

You will not be getting any 'code being injected into files' if you have the file permissions set up as recommended in the install docs - unless the attacks are actually coming from elsewhere in your server, and not through the web interface at all.
If you don't understand how file permissions work, you should start by finding a tutorial on that for your chosen system (you don't describe that, so we can't suggest links). But understanding file permissions is vital to building a secure system.

Looks similar to what happened to my site. Look at the "trojan mailer" post and my comment here: https://www.drupal.org/node/2470059#comment-9866087

And my own posting: https://www.drupal.org/node/2476265

Interestingly, when I scan the .tar archive with the same virus checker, it shows a "no threats" result. It's only with the .zip file (created from my shared hosting account with whatever the hosting company is using) that the virus checker (Avast) gave an accurate threat result.

In some of the site folders, you can simply do a visual scan of the file listing, and look for files that don't have the same date as the other files. But for a long list of modules, some of them having several subfolders and deeper levels, that's too much work. Try automated searching, but on my host computer, that's not easy to do with the tools the hosting company provides. In my case, there were two specific dates where the back door trojan files were inserted. So you could search for that.

The file names vary, so not much luck there if you search. But if it helps, this is what they were in my case (all ending in .php): article; diff; press; page; file; javascript; error; admin; include; config; system; login;wysiwyg-dialog-page.tpl; and of course the insertion into the correct file of my subtheme: node.tpl

In my situation, the Drupageddon advice about checking the menu_router table in your database didn't show anything.

My comment above focuses on the /sites folder, but of course it's possible that the trojan files could have been inserted anywhere into at least the /public_html folder (whatever it's called at your host). Meaning: go thru your site methodically.

As I mentioned in the comment, the really scary insertion was the one into my node.tpl.php file in my subtheme folder. Just the first few lines of inserted code.

We use WinSCP to update our website. We unpack update files on a local Windows computer and then upload (FTP) to our server with a drag and drop method. Which of course only replaces the proper files in the module, so if there are any extra files those stay. So in the future, we'll have to first delete the module folder we want to update and then copy it over. (Webhost only allows FTP access, not the more secure methods.)

Here are some other things to do:

1. Find your server logs and review them. My server provides logs called "access", "access_ssl" and "error". In the error log, there are two kinds of entries to look for. And take a look at the access logs, too.

a. One is the insertion effort. Here's what mine looked like. I've bolded the POST item that does the insertion.

**date and time*** [INFO] [212.129.56.198:33450-0#APVH_***mysite.com***] Connection idle time: 61 while in state: 5 watching for event: 25,close!
**date and time*** [NOTICE] [212.129.56.198:33450-0#APVH_***mysite.com***] Content len: 1150, Request line: 'POST /drupal7/sites/all/modules/webform/templates/view.php HTTP/1.1'
**date and time*** [INFO] [212.129.56.198:33450-0#APVH_***mysite.com***] HttpExtConnector state: 8, request body sent: 1150, response body size: 0, response body sent:0, left in buffer: 0, attempts: 0.
**date and time*** [INFO] [212.129.56.198:33450-0#APVH_***mysite.com***] Lsapi connection state: 2, watching event: 25, respState: 1, m_iTotalPending:0, m_iPacketLeft:0, m_iCurRespHeader:1, req sent for 61 seconds,Total processing time: 61.
**date and time*** [INFO] [212.129.56.198:33450-0#APVH_***mysite.com***] abort request..., code: 4
**date and time*** [INFO] [212.129.56.198:33450-0#APVH_***mysite.com***] Abort request processing by PID:334457, kill: 1, begin time: 61, sent time: 61, req processed: 4

b. The second kind of entry is the POST entry that calls the newly inserted file. You'll see a bunch of these once the new file is in place. (Regular traffic to your site will be mostly GET entries.)

c. But those things only show you the newly inserted file. Which should be deleted. It will slow them down at any rate.

d. And in Config you can block the IP address.

2. Then (or before) you consult your Drupal logs for recent activity:

a. Once you delete the newly inserted file, you'll see a lot of "page not found" results for the deleted file. Which I assume is all the other infected computers trying to access the one that's supposed to be on your machine. In my case, it's about a dozen an hour. Though they do seem to die out after a few days.

b. Now that I have deleted the previously missed trojan files, I find that there are now access attempts (resulting in page not found results) to three of those files. A breakin attempt. FWIW, I block that IP address in Drupal. On the thinking that there's probably some intelligence behind that attempt, whereas the para a. activity is just automated stuff.

3. The results of items 1 and 2.a. are only effective for monitoring for new insertions, so you can shut them down quickly. The only way to actually clean the back-door trojans still left on the site is to review the site (visually and with a zip-and-virus-check for out-of-place files) and/or be absolutely scrupulous in installing absolutely everything from known clean sources (ie, replacing all the /modules in your /sites folder) [to the extent you can -- with a working site, it may not be every last little bit].

Hope that helps.