Per https://www.computerminds.co.uk/articles/quickly-update-drupal-core, Github itself can create patch-files for you. You can use commandline
wget to download the appropriate patch easily:
curl 'https://github.com/drupal/drupal/compare/7.66..7.67.patch' > "drupal-7.66-to-7.67.patch"
Alternatively, you can download the tar'd (or zipped) packages for both your current version of Drupal and the target and recursively diff them as described here, resulting in a functionally-identical patch-file.
This can then be tested out in the normal way:
patch -p1 --dry-run < "drupal-7.66-to-7.67.patch"
And then applied if no hunks failed:
patch -p1 < "drupal-7.66-to-7.67.patch"
Note of course that just because patching succeeded, it doesn't mean the successfully-applied patch hasn't broken your site in some way, so be sure to back up everything (files and Drupal database) before patching, trying this first on your dev site, running tests, etc. before repeating the process for real in production.
If you've upgraded using fuerstnet.de before, Drupal may falsely continue showing security-update warnings, because at least one package with
$project['project_type']=='core' will still be considered out of date. That's because some of your .info files may contain extra lines which override standard version-numbers:
; Information added by Drupal.org packaging script on 2019-04-17
version = "7.66"
project = "drupal"
datestamp = "1555533576"
Based off of experience, generating your own patch as described above will not remove this information, since it is not present in the vanilla packages, and the files containing these extra lines won't necessarily fail to patch either, if no changes to the vanilla editions' code occurred in the last update. (Common because .info files don't change very often.)
These extra lines need to be removed (or adjusted, if you prefer) before Drupal will stop complaining that you're behind on core updates, even though you're actually up-to-date.