Over the past 6 months, a new rootkit known as Max++, ZeroAccess, Sirefef (and others) has been impacting a significant number of businesses and home users.
Recently, OSI Security responded to a client affected by this malware:
To fix this issue, the TCP/IP stack needs to be working (check Device Management, Hidden Devices and TCP/IP may have the yellow exclamation mark if the device is not working).
In our situtation, TCP/IP would not start because a group dependency failed. The IPSEC Service wouldn't start, and a check of the system32\drivers directory showed ipsec.sys driver was missing.
To fix, get the ipsec.sy_ (cab) file from the Windows CD-ROM in the i386 directory and extract it to C:\Windows\system32\drivers\ipsec.sys.
For example, go to Start -> Run -> cmd.exe, then in the command prompt type (assuming D:\ is your Windows install CD).
extract d:\i386\ipsec.sy_ c:\Windows\system32\drivers\ipsec.sys
If the above command worked as expected, you should now be able to go to Services (services.msc) and start the IPSEC Service. If it started as hoped, you should now reboot and find that the issue with ipconfig / the network adapter not being able to obtain an IP address is now resolved. If not, consider doing the same extract for tcpip.sy_ and doing a 'netsh ip reset all' and 'netsh winsock reset catalog' then rebooting.
Once we resolved this matter, we encountered another issue:
This occurs because the Microsoft Windows TCP/IP stack or Winsock API is corrupted. Specifically, the nslookup tool works because it is sending DNS lookup information directly across the wire, whereas everything else uses the Windows host operating system's Winsock gethostbyname() API which is broken.
To fix, firstly reboot into the Microsoft Windows Recovery Console, then (where D:\ is the Windows install CD-ROM);
expand D:\i386\dnsapi.dl_ C:\Windows\system32\dnsapi.dll
expand D:\i386\dnsrslvr.dl_ C:\Windows\system32\dnsrslvr.dll
Reboot and you should find that nslookup, ping, Internet Explorer etc is now functioning as expected.
Note 1: Under normal Windows, the command is 'extract' to extract a CAB file (the .sy_ or .dl_ files). Under the Recovery Console, the command is 'expand'. Using either is fine for ipsec, tcpip, dnsapi, dnsrslvr files however you will likely find using 'extract' is denied as the destination file is in use by Windows and cannot be replaced - thus, you may wish to use the Recovery Console and 'expand' for all 4 files to avoid the file in use / access denied message.
Note 2: We observed other users with similar issues i.e. nslookup works but ping does not. The above dnsapi.dll and dnsrslvr.dll replacement should in theory resolve the issue, irrespective of presence of any malware. Worth trying..
The portal requires users submit a username and password to authenticate. This communication is not encrypted.
Check the HTML source code on the form page, and examine whether the FORM ACTION is GET/POST to a HTTPS:// URI.
1) Enable SSL and disable HTTP for the portal
2) Use two-factor tokens (one time password) for strong authentication.
3) Modify the HTML source to ensure the data is POST'ed to a HTTPS URL.