The battle with the "dark genius" or Microsoft-HTTPAPI / 2.0 strikes the first blow

One day, after returning from vacation, having done enough, I decided to pile something divine in PHP. He opened his beloved Denwer and was struck by an unexpected change: Apache completely refused to listen to port 80, which means that my noble intentions for this evening were in jeopardy. The situation is, in general, quite banal - immediately the cherished trigger worked in my head: Skype! However, to my surprise, Skype immediately announced that he was not involved in this incident by not having a check mark in front of the corresponding setting. To finally check the alibi of a foreign videophone, I decided to see who is listening to port 80 at the moment.

What I saw did not add to my optimism, but rather made me scratch my crown in thought:



PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 900
RpcSs
[svchost.exe]
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

TCP 0.0.0.0:990 0.0.0.0:0 LISTENING 2428
WcesComm
[svchost.exe]
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING 4


It became clear that illegal armed gangs operate on the computer. Moreover, they act by partisan methods, since PID = 4 belonged to the System process.
The first thought came quite by accident: if someone listens to the port, then maybe he’s answering something there, because having armed with a bunch of Firefox + Firebug, I sent a request to localhost . Oddly crazy thought bore fruit. Unknown enemy replied:



HTTP/1.1 404 Not Found
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Sep 2010 11:20:20 GMT
Connection: close
Content-Length: 315

So the name of the suspect (or his accomplice) has become clear: Microsoft-HTTPAPI / 2.0. The beast is new to me, unfamiliar up to this point, because it was decided to go to the world wide web for information. Googling, questions in Habr-Q & A and askdev.ru in general, did not bring much benefit. Mostly people pointed to some Reporting Services from MS SQL Server or IIS remnants in the system. I didn’t have either one or the other (although just in case I still checked these versions with an intensive search by file names). So the prospect loomed irrelevant - a trojan or a worm. I spent the next few days (or rather evenings) in unsuccessful searches for “unwanted software” with the help of various antivirus software. There were no results. In the distance, the specter of a complete system reinstallation loomed.
')
At the same time, the questions to the respected community were not in vain: one comrade suggested stupidly deleting the file c: \ Windows \ System32 \ httpapi.dll, since it is he who is responsible for all the iniquities. I, of course, did not delete the library, however I took the file to note. Having hung myself with utilities from SysInternals, I rushed into battle:

C:\Windows\system32>tasklist /M httpapi.dll

PID
========================= ======== ============================================
svchost.exe 1328 HTTPAPI.dll
svchost.exe 2628 HTTPAPI.dll
svchost.exe 3856 HTTPAPI.dll

tasklist is a standard Windows utility, in essence, a console Task Manager. With the / M key you can see which processes use the given library. It became clear "direct performers." Next, by running Process Explorer from SysInternals, I found the processes with the given identifiers. Having opened the properties dialog, on the Services tab, I saw quite a few different Windows services that were registered in these processes. There were many services, so there was no choice - I turned off everything just to check the correctness of my guess. Among the services were: Smart Card, BranchCache, Smart Card Removal Policy, HomeGroup Listener, SSDP Detection, Discovery Provider Host, etc. Only about 15. After the reboot, the local network refused to work (though the Internet still worked ), however, to my joy, the 80th port was freed. After that, there was a routine: to turn on the services that had just been turned off one by one and check whether the 80th port is busy. Here it is necessary to make a small remark: the fact that several services are registered in the process that listens to a certain port does not mean at all that all these services listen to this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: he was the BranchCache service, which, as follows from the description: caches network content received from the caching nodes of the local subnet.

Well, then - the matter of technology. The BranchCache manual was found in MSDN, from which it appeared that BranchCache could work in different modes: a dedicated server (a server with a Windows Server 2008 R2 machine is needed) and distributed storage (it can work on regular versions of Windows 7). Accordingly, two things had to be done: change the port and set the operation mode as distributed storage:

REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\DownloadManager\Peers\Connection" /v ListenPort /t REG_DWORD /d 4455 /f

REG ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\PeerDist\DownloadManager\Peers\Connection" /v ConnectPort /t REG_DWORD /d 4455 /f

netsh br set service mode=distributed

After that, we switch back BranchCache and make sure that port 80 is free (port 4455 is now listening). The combat mission was successfully completed.

UPD : At the request of comrades in the comments, I inform you that BranchCache is a normal Windows service. You can disable it by setting the Startup type: “Disabled” in the parameters. By default, this service is of the “Manual” startup type and runs on demand of applications. So for most users, it should be disabled immediately.