Configure a "hardened" user account that an attacker would have a hard time abusing

By default, users can not write to C:\Program Files. They have Read, List Folder Contents, and Read & Execute. If that's not the case with you, then someone or something has modified those permissions.

A limited user can read much of the filesystem, but can only write to locations that it has explicitly been given access to, like its user profile.

If you grant Modify only to that one text file, the only thing that account will be able to write to on the filesystem is that file, plus things in its profile directory (My Documents, etc) which should be of no consequence.

If you have the built-in Users group having modify permissions all over your filesystem, then this is non-standard. Out of the box, limited user accounts can do very little damage.

By itself an arbitrary code execution bug is not especially harmless if the service account running its process is limited in privilege. The problem is that there are so many privilege escalation exploits out there that once you can arbitrarily execute code, you can just execute something that will allow you to break out of your privilege level. By itself, arbitrary code execution isn't a big deal, but in the real world it's almost always bundled with a privilege escalation exploit. So, yes, I'd be concerned.

Some quite interesting answers here.

Taking an empirical stance, with numerous post-penetration test "things to fix lists" under my belt, I would actually say that Microsoft have done a great job in recent years of providing the tools and options to harden a server very well.

Of course, MS still fuzz their code, and they and the community continue to find remote execution / privilege escalation exploits, but I've got to say, their patching is on-the-ball compared to some other vendors (SonicWall, Tivoli and Oracle spring to mind).

My recommendations would be:

• Make sure User Account Control (UAC) is enabled
• Ensure Data Execution Prevention (DEP) is enabled
• Use managed service accounts (Windows 7 or Windows Server 2008 R2 and above)
• Start with the absolute minimum privileges, and only add more if absolutely required. I mean file system privs and User Rights Assignment (Local Security Policy or Group Policy)
• Use Microsoft's Process Monitor to diagnose privilege issues (when experimenting ^^^)
• Make sure the server is patched (Security patches at least, via WSUS)
• If you have 3rd party software installed, keep that patched too.
• Uninstall Java. Unless you really need it. Patch it. Then patch it again 'cause the patch you applied didn't fix the fault that Oracle said it would. Sorry, Oracle have ruined Sun Java!
• Keep your hardware vendor's systems software up-to-date (BIOS, device drivers, Etc.)
• Use Windows auditing to monitor activity of your new shiny account.
• Forward events somewhere central.
• Examine forwarded events daily or at least configure triggers to alert where necessary.
• Enable the Windows Firewall (it's a shame, but so many people turn it off)
• Ensure your server is backed up, so if the worst happens, you have your data.
• Develop a plan for what you would do if the worst did happen.
• Don't allow your server access to the Internet. Again, I can't believe the number of data centres I've been to where there is open HTTP(S) access to the Internet for all servers. Some people need to be taken aside for a chat.

It's important to remember, there is no such thing as a completely secure o/s, application or network. It's all about layers of prevention, and identifying when things look different. Don't get sold on Intrusion Detection either, unless of course, you a) are susceptible to hyped up sales pitches, b) have lots of free time on your hands and c) have plenty of spare $$$.

Finally, the most devious "attacks" these days aren't about disruption; quite the opposite. The focus (and funding!) has switched to data exfiltration.

In the Linux world, we would use SELinux or another mandatory access control mechanism to mitigate this sort of threat.

Windows doesn't have anything quite so robust, but since Vista/2008 it does have a basic integrity mechanism which you might be able to use. (Though, this has a rather high learning curve and explaining it fully would require more length than is permitted here.)

I think your best short-term mitigation would be to isolate the service in a virtual machine.

If "execute arbitrary code" means the process can create directories, it may be possible for them to create directories either in the current directory, the service account's user profile directory, the root of the C:\ drive, or simply search for a directory where it can create directories.

Last time I checked, Windows usually conferred the permission to create directories in the root of C:. You may not see this in the gui due to you would need to view the Advanced property page or use ICACLS to get a complete list of permissions.

Even if the C:\ root directory permission had been hardened, it is trivial to search all directories on C:\ and test for one where permissions allow the service account to create directories. Chances are there will be one.

If the process exploit can create directories somewhere on C:, then it is fairly straightforward to disable the system by creating millions or billions of empty directories/subdirectories.

Empty directories are zero bytes, so are not subject to quotas. These directories are also stored directly in the MFT (due to their small size), so even if the process could be stopped and the directories deleted, the MFT is effectively trashed - so large and/or fragmented that the system may need to be restored from backup.