Repairing the DHCP Client service after a Conficker worm infection

If you’ve recently removed a Conficker infection from one of your machines, you might find that you can no longer start the DHCP Client service on the machine in question.

This is still a problem, even if the machine doesn’t rely on DHCP for it’s IP addressing, because the DHCP Client service still plays an important role in machines configured with static IP’s, in that it is responsible for dynamic registration and updating of it’s DNS record on it’s configured DNS servers. Without the service starting, the records will eventually get scavenged (if the DNS servers are configured for scavenging) because the records haven’t been “touched” by the DHCP Client service on the machine in question.

In fact, that might be how you determine that a problem exists, because you can no longer resolve machines in DNS that previously had a Conficker infection.

The service fails to start, because Conficker makes changes to services which call the svchost.exe process so that it can attach itself and attempt to spread throughout a network. During this process, permissions are reset on the registry keys which contain the service information for the DHCP Client service. Without looking too deep in to why these permissions are changed, I suspect that Conficker entirely removes and recreates the DHCP Client service registry keys, which will of course inherit the parent permissions by default. The DHCP Client service requires the following non-inherited permissions in order to be controlled:

HKLM\SYSTEM\CurrentControlSet\Services\Dhcp – NETWORK SERVICE, Read
HKLM\SYSTEM\CurrentControlSet\Services\Dhcp – NETWORK SERVICE, Full control

Setting these permissions will allow the service to be controller again. I recommend checking the Windows Event Logs to ensure that DNS registration occurs successfully once the service has been started.