Our Blog

Our news

All you need to know

Analysis of a UDP worm

Reading time ~4 min


From time to time I like to delve into malware analysis as a pastime and post interesting examples, and recently we  received a malware sample that had a low-detection rate. Anti-Virus coverage was 15/43 (35.7%) based on a virustotal.com report and Norman sandbox did not detect any suspicious activity as shown in the report below:

norman sandbox report

Norman sandbox report did not show any registry or network activity. This might be due to the use of virtual CPU or sandbox bypass techniques by the malware. Sunbelt sandbox was down at the time of the analysis.

Dynamic analysis indicated that the malware copies itself to the “application data” directory of the current logged-on user and achieves automatic startup by adding the following registry entry:

  • key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman
  • Value: %AppData%\ygmdrm.exe

It then starts communicating via UDP with the following C&C servers on port number 14000:

  • jebena.ananikolic.su
  • peer.pickeklosarsk.ru
  • teske.pornicarke.com
  • juice.losmibracala.org

The UDP traffic was scrambled and had the following sequence:

Code analysis of the malware resulted in the following findings:

Virtual CPU bypass

Anti-virus programs achieve heuristic detection of unknown malware code by parsing the binary code inside a virtual CPU to detect suspicious pattern (packers, encryptors, etc) and OS activities. Most modern AVs are able to detect and skip “code traps” designed to evade detection, such as time delays, intentional loops and unsupported CPU instructions. However, based on the AV coverage report this malware was able to evade huristic detection in a number of AV products by causing indirect execution delays through crafted calls to GDI functions as shown in the following API call log:

Code injection

The actual malware code is launched after evasive GDI calls. A page of memory is allocated using VirtualAlloc API, 1760 bytes are copied to the newly allocated area and the control is passed to this code with the “call eax” insturction as shown in the following code anippet:
The second stage searches for explorer.exe process and injects its code into it using CreateRemoteThread technique.

Network communications

The first 5 UDP packets were found to be connect request packets (starting with 0x18 command code) and sequence number exchange. The 6th packet with data size of 269 bytes seems interesting and could contain bot commands:

The decryption function was found at offset 0x58be of the second code stage :

The decryption algorithm can be presented by the following formula:

D(buff[n])=buff[n] XOR (buff[n-1]*pow(2,(n-1 AND 3))  where n values range from 1 to data_size-1.

The decrypted buffer contents are not completely readable and contain some metadata inserted at various positions. This indicates that the buffer is also compressed using a byte level compression algorithm. Further debugging reveals a decompression function at offset 0x1118 and decompressed command content is shown in the figure below:

The command instructs the bot to change the startup home page of the victim’s browser to “http://www.juniormind.com/” for a possible SEO campaign.

Other features

Analysis of the text strings in the second stage code indicates that the malware has other capabilities such as:

  1. USB drive infector (via autorun.inf)
  2. Download and execute
  3. Remote Firefox cookie dump

This is cause for concern and warrants a a high risk rating, as opposed to the “low risk” in provided in ThreatExpert.com’s report.


Apart from signatures, it’s still pretty easy to write malware to bypass A/V heuristic checks, as the GDI calls in this sample showed.