With the recent rash of Messenger PopUp SPAM there has been some confusion over exactly what methods are being employed to actually deliver these messages.
The usual way to send a popup is with the DOS 'net send' command. This command delivers a popup using Netbios and SMB (Server Message Block) protocols which utilize the udp/137 and tcp/139 ports.
As popups are traditionally sent using Netbios and SMB, some have assumed that the recent SPAM popups are being delivered in the same way. Our analysis of the DirectAdvertiser (DA) application shows that this assumption is incorrect. DA is delivering popups utilizing Microsoft RPC (remote procedure call) to udp/135.
This document compares these two methods of popup delivery in detail so that effective countermeasures can be put in place.
Here is an example 'net send' command:
D:\>net send 172.16.1.140 "hello there" The message was successfully sent to 172.16.1.140.
The above command produces the following packet trace:
Client issues a Netbios Adapter Status request to the target using udp/137. The purpose of this query is to identify the Netbios names that are registered on the target.
This is equivalent to doing a DOS NBTSTAT -A target_ip:
The targets response to the NBSTAT request, containing the list of registered names. Here's the same command from DOS so you can see what the response look like:
D:\>nbtstat -A 172.16.1.140
Local Area Connection:
Node IpAddress: [172.16.1.169] Scope Id: []
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
TMB <00> UNIQUE Registered
WORKGROUP <00> GROUP Registered
TMB <20> UNIQUE Registered
TMB <03> UNIQUE Registered
WORKGROUP <1E> GROUP Registered
ADMINISTRATOR <03> UNIQUE Registered
TMB <01> UNIQUE Registered
MAC Address = 00-01-02-3D-1A-4E
D:\>
Note that each name has a 1 Byte suffix (e.g. 00,20,03,1E, etc.) which indicates the type of name registered.
In the case of NET SEND, the important suffix is '03':
Name Number(h) Type Usage -------------------------------------------------------------------------- <computername> 03 U Messenger Service
If the target host responds with a registered name with a '03' suffix, then it knows that the Messenger Service is running and it can proceed with attempting to send the message. If there are no registered names of this type, then NET SEND will abort.
For a list of additional Netbios suffixes see:Netbios Name Suffixes
Since the NBSTAT returned a name with the Messenger suffix code, we now establish a connection using tcp/139 (NetBios session) and negoitiate a Netbios session.
Now we use the SMB 'Send Single Block Message Request' to actually send the message. If you look in the detail pane you can see the actual content of the message 'hello there'. In frame 9, the target acknowledges receipt of the message.
TCP connection is closed.
The following packet trace results from using the online DirectAdvertiser Demo:
DirectAdvertising server sends a RPC request...note target port udp/135. The text of the popup message is in the payload of the packet.
Also note the target Interface: '5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc'. I believe this is the unique identifier associated with the Messenger service (via RPC).
I can confirm this by running the rpcdump utility on the target host:
D:\>rpcdump 127.0.0.1 IfId: 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc version 1.0 Annotation: Messenger Service UUID: 00000000-0000-0000-0000-000000000000 Binding: ncalrpc:[appmgmt] ... [snip]
I'm no RPC expert so I don't completely understand the purpose of these frames...they appear to be the target to get needed information (e.g. a uuid) from the initiator to complete the request.
Note that the initial communication is targetted to udp/135. Subsequent communication is via random ephemeral (> 1024) ports... in this case udp/2307 and udp/5196. Since Frame 2 is generated FROM the target TO the initiator, this will be treated as outbound traffic by the clients firewall and thus will not likely be blocked. So it seems that all that is required for this technique to work is allowing inbound udp/135.
Frame 5 looks like it's an acknowledgement that the message was received.
I also experimented with firewall configurations to allow inbound udp/135, but to block the reset of the RPC communication above... was curious to see if a popup could be delivered with the single inbound udp/135 packet. When I tried this, no popup was displayed, so it appears that the conv_who_are_you2 and ACK packets are necessary for successful delivery.
I didn't really understand much of it, but some additional info on RPC calls is here:
CDE 1.1: Remote Procedure CallThose with Enterprise or hardware-based firewalls can effectively block RPC-generated popups by blocking inbound udp/135 Netbios generated popups require blocking udp/137 and tcp/139 inbound.
Users with NAT (Network Address Translation) routers should already be protected against this activity as all inbound communication should be blocked by default.
Users with personal firewalls need to exercise extreme care when granting permissions to RPC-related executables (e.g. svchost.exe or services.exe ). If you mistakenly give these applications full 'server' rights, then you may be susceptable to Messenger SPAM.