Many of you would have seen our anti-malware solution test website known as WICAR (think EICAR AV Test File, but for web based attacks).
This is just a quick email to let you know we now have SSL enabled for our test malware attacks, so not only can you test your firewall, IDS/IPS, proxies, content filtering and desktop antivirus, but you can also check if you are protected against payloads delivered over HTTP/S or verify your SSL-inspection products are working.
Simply open the Test Malware page and click the [SSL] hyperlink to conduct the test over SSL to ensure your organisation is adequately protected (most attacks today are delivered over SSL to get around proxy inspection).
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..