Archive for Security
Malware/Virus delivered through fake e-mail from UPS
Posted by: | CommentsI have had several incidents this week of customer systems being infected by executables attached to e-mails appearing to be from UPS.
Looking around the blogs, these e-mails seem to be having a higher than normal infection rate. It is time consuming to get rid of and makes the infected machines unusable and creates a huge number of network connections.
The exact subject line of the email’s that have been received is:
UPS Tracking Number 5440074870
Attached to the e-mail is a zip file containing an executable which when executed installs "XP Security Center".
Much more information about the detail of the actual email can be found on the Trend Malware Blog. The worrying thing about this e-mail is that both of the machines that it infected have their e-mail filtered by very well known external 3rd party mail systems, then have virus scanning on their own Exchange servers and finally on their desktop machines. At the moment this e-mail is still slipping through the net.
This virus does a LOT of clever things to prevent you getting rid of it. I noticed that when trying to run Autoruns from Sysinternals that it just would not work. Renaming the autoruns executable allows it to run. It also stops you being able to install/download Windows Defender, disables system restore, removes the system tools program group amongst other things.
Not a very sophisticated solution but for now I have edited the Exchange IMF custom weighting file on customer systems to ensure that messages with "UPS Tracking" in the subject line are never delivered to the recipients and definitely classed as spam.
I had written a separate post on how to remove the virus manually, but at the moment I am still monitoring the infected machines to ensure they are completely clean.
Using packet capture to find virus infected clients
Posted by: | CommentsToday a customer started to get a lot of their e-mails bounced. In fact they could not even e-mail me to let me know about the problem as my own mail servers were rejecting their messages.
The reason for this was because their IP address had been listed on the CBL.
I had a poke around the server and everything seemed to be in good order; patched up to date, virus scanner had nothing interesting to report, netstat did not show any abnormal connections and Exchange queues seemed normal. So I assumed that the problem must be coming from one of the network PCs.
This customer has a dual nic SBS 2003 Standard edition server, not my preferred set-up, but the system had to be implemented in this way to fit in with existing infrastructure. It is not possible to see what traffic is passing through the NAT gateway on RRAS with the built in tools, but Microsoft Netmon 3.1 should be able to show up any strange network traffic. I installed it and ran the following filter:
Tcp.dstport == 25 and ipv4.Address != 192.168.200.1
192.168.200.1 is the IP address of the internet facing NIC on the SBS machine.
Within a couple of minutes this filter showed all the machines on the network sending SMTP based traffic except for the SBS server itself. Fortunately there was only one. I took remote control of the machine and from the command line ran:
netstat -ano |find ?��Ǩ?�:25?��Ǩ�?
The output of this command showed me the local processes which were attempting to communicate with other hosts on port 25 and gave me confirmation that this PC was definitely infected with some kind of mass mailing virus or worm. Killing the process listed by the netstat command stopped the mass mailer and gave some breathing space to find the cause of the problem.
Turns out the machine in question had its virus checker disabled. So I turned it back on and ran a full scan which turned up almost 6,000 files infected with W32/MyDoom.
Once the problem had been found it was easy to sort, but because I have so few customers with this set-up it had not occurred to me how little visibility you get over network traffic with the SBS 2003 standard edition tools.
The joys of travelling sales laptops 
Windows update automatic e-mail notification
Posted by: | CommentsAs the number of servers that I am responsible for managing increases, it becomes more difficult to ensure that they are all patched up to date.
As most of the machines I manage are SBS boxes I thought that it would be nice to put something together which behaves in much the same way as the SBS generated e-mail alerts.
So, the result is a script which sends e-mail notifications to a specified address and gives details of which patches are available to be installed. The administrator can choose which of the four patch levels will trigger an e-mail alert (Critical, Important, Moderate & Low).
If there are no outstanding patches at the appropriate alert levels to be installed then the script will quit without sending an e-mail.
The script is then run as a scheduled task every evening and I can quickly see if I have anything to action. The report includes links to the relevant KB articles and further information made available by Microsoft.
The script only takes a couple of minutes to setup as there are only six settings at the top of the file…
Setting any of the following to 1 will generate trigger alerts for that particular update severity:
- AlertCritical
- AlertImportant
- AlertModerate
- AlertLow
- EmailFrom – Specifies the e-mail address the report will be sent from.
- EmailTo – Specifies the e-mail address to send the reports to.
As shown above I have been running with AlertCritical/AlertImportant set to 1 and the other two set to 0.
So, if you want to receive email alerts all you need to do is download this Zip file, extract the contents to a folder on your server and then edit the variables at the top of the script. To perform a test run go into a command prompt and change directory to the location where you extracted the script and run:
cscript winupdates.vbs
With any luck you should get an e-mail soon after with the results. If you find that it is not generating you an e-mail as expected, one reason may be that there are no patches available to install. Bear in mind that not all items from Windows update will appear. For example “Internet Explorer 7″ is not a patch and therefore will not be listed.
Running the script interactively as above will take a few moments while Windows Update(or WSUS if you have it installed) are checked for new updates.
Once you have completed a successful test you can go ahead and setup a scheduled task. Assuming an installation directory of “c:\scripts” the scheduled task command should look something like this:
C:\WINDOWS\system32\cscript.exe c:\scripts\winupdates.vbs
Also worth a mention that I have used this on standard(non-sbs) Windows servers and it works well.
Perhaps if enough people use this script, it will actually save as much time as it took to make it, but I doubt it. 