Toolkit

Story: Windows admin 'feature' poses latest hazard

• 
• 

This is a bit of a stretch, as the NET SEND command would have to be locally executed in order to blindly send a pop-up message box to all users in the machine's domain. Otherwise the initiator would need to know specifics such as network usernames and network domains (which is unlikely for an external exploit).

Disabling the Messenger service is an obvious preventative measure, but I am wondering where/how an external party could locally execute the NET SEND command. If the attack is coming from the outside through a TCP/UDP port exploit then NetBIOS/SMB ports like 137, 138, etc. should be blocked on the external interface. If the attack is coming in the form of an e-mail script I suppose the unknowing recipicient party could simply launch the script and perform the command.

Most current Microsoft e-mail application versions now automatically block attachments that are .BAT, .PIF, .CMD, .EXE and those versions that don't can be aided with current antivirus definitions running on the e-mail server and e-mail client. But the scripting capability could be a lot more damaging than sending a NET SEND message box. Imagine one that appended 'format c:' or something to the local startup environment on Windows 9x hosts ?

That being said I still fail to see how a NET SEND message box could contain malicious code. I can appreciate the foresight and proactive nature of this article yet would like some perspective on things.

• 
• 

• 
• 
• 

Full Talkback thread