September 27, 2010 at 14:38The battle with the "gloomy genius" or Microsoft-HTTPAPI / 2.0 strikes first
Once, when I returned from vacation, having been pretty naughty enough, I decided to build something divine in PHP. He opened his beloved Denwer and was amazed at the unexpected change: Apache completely refused to listen to the 80th port, which means that my noble intentions for this evening were in jeopardy. The situation, in general, is pretty banal - immediately the coveted trigger worked in my head: Skype! However, to my surprise, Skype immediately announced its non-involvement in this incident by the absence of a checkmark opposite the corresponding setting. To finally check the alibi of a foreign video phone, I decided to see who is still listening to the 80th port.
What I saw did not add optimism to me, but rather made me scratch my crown in thought:
It became clear that illegal armed gangs were operating on the computer. Moreover, they act as partisan methods, since PID = 4 belonged to the System process.
The first thought came by accident: if someone is listening on the port, then maybe he is responding to something there, therefore, armed with a bunch of Firefox + Firebug, I sent a request to localhost . Strange as it may seem, the crazy thought bore fruit. The unknown enemy replied: So the name of the suspect (or his accomplice) became clear: Microsoft-HTTPAPI / 2.0. The beast is new to me, up to this point unfamiliar, so it was decided to go to the expanses of the World Wide Web for information. Googling, questions in Habr-Q & A and askdev.ru
in general, did not bring much benefit. Basically, people pointed to some Reporting Services from MS SQL Server or the remnants of IIS in the system. I didn’t have one or the other (although just in case, I still checked these versions with an intensive search for file names). So the prospect loomed a hopeless one - a trojan or a worm. The next few days (or rather evenings) I spent in unsuccessful searches for “unwanted software” using various anti-virus software. There were no results. In the distance loomed the ghost of a complete reinstallation of the system.
At the same time, 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 committed lawlessness. Of course, I didn’t delete the library, but I took note of the file. Having hung up with utilities from SysInternals, I rushed into battle:
tasklist is a standard Windows utility, essentially a console task manager. With the / M switch, you can see which processes use the given library. The "direct executors" became clear. Next, starting Process Explorer from SysInternals, I found 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, Home Group Listener, SSDP Discovery, Discovery Provider Host, etc. Only about 15. After the reboot, my local network refused to work (although the Internet still worked ), however, to my delight, the 80th port was freed. After this, there was a routine: turn on the services that were just turned off one by one and check if the 80th port was busy. Here it is necessary to make a small remark: the fact that several services are registered in a process that listens to a port does not mean at all that all these services are listening to this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: it turned out to be BranchCache, which, as follows from the description: caches network content received from caching nodes on the local subnet. which one port listens to does not mean at all that all these services are listening on this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: it turned out to be BranchCache, which, as follows from the description: caches network content received from caching nodes on the local subnet. which one port listens to does not mean at all that all these services are listening on this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: it turned out to be BranchCache, which, as follows from the description: caches network content received from caching nodes on the local subnet.
Well, then - a matter of technology. A guide to BranchCache was dug up on MSDN , from which it followed that BranchCache can operate in various modes: a dedicated server (a server with Windows Server 2008 R2 is needed as a server) and distributed storage (can run on regular versions of Windows 7). Accordingly, two things had to be done: change the port and set the mode of operation as distributed storage: After that, turn BranchCache back on and make sure that the 80th port is free (port 4455 is now listening). The combat mission has been successfully completed. UPD
: At the request of friends in the comments, I inform you that BranchCache is a regular Windows service. You can disable it by setting the Startup Type: “Disabled” in the parameters. By default, this service has a “Manual” startup type and is launched upon application demand. So for most users, it should be disabled immediately.
What I saw did not add optimism to me, 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 were operating on the computer. Moreover, they act as partisan methods, since PID = 4 belonged to the System process.
The first thought came by accident: if someone is listening on the port, then maybe he is responding to something there, therefore, armed with a bunch of Firefox + Firebug, I sent a request to localhost . Strange as it may seem, the crazy thought bore fruit. The unknown enemy replied: So the name of the suspect (or his accomplice) became clear: Microsoft-HTTPAPI / 2.0. The beast is new to me, up to this point unfamiliar, so it was decided to go to the expanses of the World Wide Web for information. Googling, questions in Habr-Q & A and askdev.ru
Заголовки ответа
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: 315in general, did not bring much benefit. Basically, people pointed to some Reporting Services from MS SQL Server or the remnants of IIS in the system. I didn’t have one or the other (although just in case, I still checked these versions with an intensive search for file names). So the prospect loomed a hopeless one - a trojan or a worm. The next few days (or rather evenings) I spent in unsuccessful searches for “unwanted software” using various anti-virus software. There were no results. In the distance loomed the ghost of a complete reinstallation of the system.
At the same time, 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 committed lawlessness. Of course, I didn’t delete the library, but I took note of the file. Having hung up 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.dlltasklist is a standard Windows utility, essentially a console task manager. With the / M switch, you can see which processes use the given library. The "direct executors" became clear. Next, starting Process Explorer from SysInternals, I found 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, Home Group Listener, SSDP Discovery, Discovery Provider Host, etc. Only about 15. After the reboot, my local network refused to work (although the Internet still worked ), however, to my delight, the 80th port was freed. After this, there was a routine: turn on the services that were just turned off one by one and check if the 80th port was busy. Here it is necessary to make a small remark: the fact that several services are registered in a process that listens to a port does not mean at all that all these services are listening to this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: it turned out to be BranchCache, which, as follows from the description: caches network content received from caching nodes on the local subnet. which one port listens to does not mean at all that all these services are listening on this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: it turned out to be BranchCache, which, as follows from the description: caches network content received from caching nodes on the local subnet. which one port listens to does not mean at all that all these services are listening on this port. They just turned out to be "at the wrong time, in the wrong place." Thus, the attacker was identified quite accurately: it turned out to be BranchCache, which, as follows from the description: caches network content received from caching nodes on the local subnet.
Well, then - a matter of technology. A guide to BranchCache was dug up on MSDN , from which it followed that BranchCache can operate in various modes: a dedicated server (a server with Windows Server 2008 R2 is needed as a server) and distributed storage (can run on regular versions of Windows 7). Accordingly, two things had to be done: change the port and set the mode of operation as distributed storage: After that, turn BranchCache back on and make sure that the 80th port is free (port 4455 is now listening). The combat mission has been successfully completed. UPD
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: At the request of friends in the comments, I inform you that BranchCache is a regular Windows service. You can disable it by setting the Startup Type: “Disabled” in the parameters. By default, this service has a “Manual” startup type and is launched upon application demand. So for most users, it should be disabled immediately.