[kmd]

i told you, it not working. No infected services at all. code from your attach i can extract from dropper (file w32 from cab archive). i'm interested in extended attribute data. can you attach it please :?:

[rkhunter]

i told you, it not working. No infected services at all. code from your attach i can extract from dropper (file w32 from cab archive). i'm interested in extended attribute data. can you attach it please :?:

Ea data in x32 infected case is a e32 file from payload that posted before http://www.kernelmode.info/forum/viewto ... 390#p13959, with size of 22 892 bytes.
In attach cutted PE from this Ea.
19/41 https://www.virustotal.com/file/50ddaa6 ... /analysis/

[EP_X0FF]

i told you, it not working. No infected services at all. code from your attach i can extract from dropper (file w32 from cab archive). i'm interested in extended attribute data. can you attach it please :?:

Make sure this VM wasn't infected by anything before and for full debug it must have Internet access. Complete Sirefef "services.exe" infection working scheme:

1. services.exe hijacked by Sirefef dropper, depending on OS type it will be patched by contents of "w32" (x86) or by "w64" (x64).
2. once Sirefef dropper code called it executes loader shellcode reading contents of services.exe extended attribute. Can be verified with disk editor, see example with WinHex.

123jk.jpg (150.59 KiB) Viewed 338 times

3. shellcode reads EA data into ERW memory region and call it directly.
4. EA data represented by "e32" file for x86 and "e64" for x64. In the beginning of data block placed second shellcode - services.exe calls exactly it.
5. Code of eXX is a miniloader with few similar to wXX routines (such as PEB working, functions hashing etc) - it's purpose load actual payload stored next to shellcode.
...
PROFIT -> multiple sockets connections from services.exe with massive UDP traffic.

P.S.

There are special greets to kmd inside. kmddsp.tsp :) Don't take it seriously, it is a joke.

[kmd]

@EP_X0FF
one question - how to interpret this screenshot? :shock:

[EP_X0FF]

Hope you are not "security expert", otherwise I'm giving you Gostev-style facepalm.

The data on this screenshot is a NTFS Extended Attribute. Each file has such attributes, like for example Filename, standard_information, data. Not taking deep excurse in NTFS internals on this screenshot is data structure of non resident attribute (Sirefef payload is too big for be stored directly in MFT). First 16 bytes of this structure is header. It is not impotant. Now take a look on magic value "4000". This is offset from the beginning of data (depends of some flag, also not important for us). Now add this offset. Data+sizeof(Header) + offset. You are at 31 08 DF 1F 09. "31" stands for: size of field length "1", sizeof of address field length "3". "08" - length in clusters (0x1000 NTFS cluster size formatted). Next is the cluster number "091FDF".

Now take a WinHex, open logical disk, goto -> cluster number. You are at the beginning of "e64" attribute data. Cut it off, you know size. Of course valid only for my screenshot :)

[rkhunter]

He-he, parse NTFS-structure in the mind is a great idea, but would be logical use some tool that give you this data already in interpreted format (such as disk explorer). Hope that now time not for parse structure in the mind, hope we are not living in DOS-times. :shock:
[I remember Kris Kaspersky old-school style, that was great, but today.... :? ]

[Quads]

Anyone seen a variant where System Restore has problems afterwards, plus no Internet connection and Windows is stuck in classic view (taskbar etc.).

Quads

Worked out it was a problem with the netsvcs registry key afterwards. Screwed key meant all services like SRservice, Themes and ones for networking wouldn't start / run

Quads

[EP_X0FF]

Sirefef CLSID backdoor version and Virus:Win32/Sirefef, Virus:Win64/Sirefef discussion moved here.

Old thread about rootkit can be found here.

[FoolishTech]

Does anyone have a sample of Sirefef.Y (as reported by MSE)?? Haven't managed to catch it myself, but I'm told that it (either by itself or perhaps with a botched removal attempt) would put Windows in an infinite reboot loop with about 60 seconds of desktop time before the reboot - and that shutdown -a will not abort it. Anyone heard of this or is it likely a different malware payload downloaded by the Sirefef infection causing this?

[rkhunter]

Does anyone have a sample of Sirefef.Y (as reported by MSE)?? Haven't managed to catch it myself, but I'm told that it (either by itself or perhaps with a botched removal attempt) would put Windows in an infinite reboot loop with about 60 seconds of desktop time before the reboot - and that shutdown -a will not abort it. Anyone heard of this or is it likely a different malware payload downloaded by the Sirefef infection causing this?

Do you have a more accurate name? "Sirefef.Y" as I remember there is no droppers with such name. Actual droppers detected by it as Trojan:Win32/Sirefef.P.
If you mean Trojan:Win64/Sirefef.Y, for example, https://www.virustotal.com/file/073b1f9 ... /analysis/ - this is payload n64 from dropper container that was posted before.