Author Topic: Installshield  (Read 9861 times)

0 Members and 1 Guest are viewing this topic.

July 06, 2008, 09:51:28 am
Read 9861 times

CM_MWR

  • Special Members
  • Hero Member

  • Offline
  • *

  • 319
Quote
1)Have you come across some malware that was wrapped with InstallShield?
If that's the case,I'd be really curious to see it...

Actually yes,its over at uploadmalware,wrapped with installshield to reveal yet more fugly packings.

I had asked about this then but its been some months ago and will take some doing to find it again.

Ive never seen malware use it before and havent paid enough attention to say i have seen it again.

Indeed the answer to the question would be "Yes" but for now,without living proof.

July 06, 2008, 11:16:50 am
Reply #1

bobby

  • Special Members
  • Hero Member

  • Offline
  • *

  • 322
    • Malzilla
Wait, wait...
Please make difference between setups/installers and exe-packers/protectors.
You can't say "malware wrapped with InstallShield", that is simply wrong.
InstallShield is an installer (very common one), and you can use it to make setup/install routines for any possible application.
You can imagine an installer like a ZIP with small EXE that will extract the files from the ZIP to pre-defined folders (according to the installer script, written by the one who compiled the installtion), eventually setting some values in registry etc.

Now, one can use InstallShield to bundle adware/spyware/any_other_pest with legit application, so that the malware installs along with the installation of legit app.
This way you get various toolbars along with installing Nero etc.

July 06, 2008, 04:08:30 pm
Reply #2

sowhat-x

  • Guest
Actually,it is my mistake using the expression "wrapped"...
as I just couldn't come up with a better suitable word at that moment.
The rest,I agree...I've seen mirc-based bots that came in the form of installer...
can't remember exactly what they had used though to build the setup.exe,
but it was not a that much common installer out there.
Malware bundled into Nsis and/or Inno setup packages as well a couple of times...
InstallShield seems to have been less misused though,don't know...
that's why I had got curious about it in the first place,lol...


July 06, 2008, 04:23:04 pm
Reply #3

JohnC

  • Special Members
  • Hero Member

  • Offline
  • *

  • 1964
Winrar is often used to make SFX Executables.

July 06, 2008, 05:28:15 pm
Reply #4

bobby

  • Special Members
  • Hero Member

  • Offline
  • *

  • 322
    • Malzilla
Winrar is often used to make SFX Executables.
I've seen quite a lot of RAR SFX installers, mostly for Zapchast/Zaphast.
I also saw a lot of hacked RAR SFX archives that can't be unpacked by using WinRAR.
They have changed the magic number for the archive, so it is not RAR anymore, but RAP.
Just get some hex editor, change RAP to RAR and unpack them with WinRAR.

There is also a chinese RAR hack (also SFX), but I didn't found how to unpack it.

One more interesting thing was malware arhived with pass-protected RAR, and bundled into NSIS installer after that. CLI unrar.exe was also included in the bundle.
At unpacking, NSIS would drop the unrar.exe and protected archive into temp folder, run unrar.exe to unpack the archive (and also providing password for unpacking), and run unpacked files after that.
The idea was to protect the malware so it can't be scanned by the AV, but most of the AVs added a generic detection if a pass-protected RAR was found inside an installer.

As for other installers, there is no rules what will be used for bundling an installer together.
NSIS was particularly interesting for early Zlob infections, because it could be used as a downloader/dropper.

July 06, 2008, 05:51:14 pm
Reply #5

sowhat-x

  • Guest
Quote
One more interesting thing was malware arhived with pass-protected RAR,and bundled into NSIS installer after that.
Lmao,I've seen another totally lame and "uber-el33t" variation of the above couple of times,he-he...
not installers,but exe binders that used unrar.exe in order to extract the joined/embedded malware.
Ie.like joiner's stub.exe + innocent .exe + unrar.exe + password protected rar containing malware,
usually appended as an overlay in the end of the file...

July 06, 2008, 06:02:52 pm
Reply #6

bobby

  • Special Members
  • Hero Member

  • Offline
  • *

  • 322
    • Malzilla
Thats the same hack - do not let the AV see whats inside the archive. If name encryption is also used (RAR supports such feature), AV can't even see if an EXE is packed inside. I know a couple of AVs that will throw heuristic detection if EXE extension is found in pass-protected archive. One can always get the name of files in the archive, except if the names are also encrypted (RAR can do this).

btw. marking a signature of the joiner is Solomon's solution here (http://en.wikipedia.org/wiki/Judgment_of_Solomon). Just take a look at detections of Tibs packed malware - all the AVs have a signature of packer's stub, none can unpack it.

July 06, 2008, 08:44:37 pm
Reply #7

sowhat-x

  • Guest
He-he,here's a simple contest,a small toy for people to have fun around  ;)
It's an .exe generated with a malware joiner,somewhat similar to the stuff described above:
it uses the password protection abilities of WinRAR ,
supposedly in order to "hide" the joined .exes from the prying eyes,lmao...
Goal obviously is...to find the password used.

This was quickly made...haven't spared my time in fully analyzing the joiner itself:
meaning that I would strongly suggest doing the reversing work/tricks against it under a vm.
The .exes I've joined though are simply good old notepad.exe along with calc.exe.
Prize for the contest is...the direct link to the rar-based joiner itself,ha-ha...  ;D

As for detection rates...well,the joiner in question was released at 17.09.2007,
and at least for it's "stub",10 months later...here are VirusTotal's results:
http://www.virustotal.com/analisis/7d1c70e65ec8af2411b118804f9998ec

July 07, 2008, 05:04:31 pm
Reply #8

tjs

  • Special Members
  • Sr. Member

  • Offline
  • *

  • 248
I don't want to ruin the challenge for others, so I will post the md5 of the password:
4ea8a063169921dcc5dee129fde78bba

It's too easy to pull the cmdline params off the stack.

Archive:
0012FC74  43 3A 5C 57 49 4E 4E 54 5C 31 32 38 2E 72 61 72  C:\WINNT\128.rar

Password:
0012FD74  63 3A 5C 70 72 6F 67 72 61 6D 20 66 69 6C 65 73  c:\program files
0012FD84  5C 77 69 6E 72 61 72 5C 72 61 72 2E 65 78 65 20  \winrar\rar.exe
0012FD94  65 20 2D 6F 2B 20 2D 79 20 2D 70 XX XX XX XX     e -o+ -y -pXXXX

;)

TJS

July 07, 2008, 06:00:51 pm
Reply #9

sowhat-x

  • Guest
...he-he,I was 100% sure about it...and the winner is...tjs ;D


July 07, 2008, 06:18:19 pm
Reply #10

sowhat-x

  • Guest
...and here's the 'prize' as well,under "Releases" page...few other stuff there possibly:
hxxp://gew.org.ru/
(Doh,forgot mentioning explicity...for those having trouble to translate,
joiner is called "JVA",password is "JVA" as well...)
=====================================

No need for a very detail tutorial or so,just a really quick explanation for other people...
It's a joined .exe: well,about 99% of such executables,
contain the rest of embedded .exes/data either as an overlay appended to the end of the file,
or,even more usually,in the .rsrc section...

The above joined.exe poses no exception to the rule...
if you fire up XN Resource Editor,or any other similar app of you choice,
you'll see that .exe has two resources..."136" and "137" namely.
It's easy to guess these are the embedded pass-protected archives,
and even the "Rar!" header is there in plain view...it's not even obfuscated or something.
Ie.if all someone wants is to get the .exes out of there,
he/she simply has to extract these two resources/.rar files...
and then use the approriate password,which is "cult" in this case.

How to find the pass in the first place without spending hours of bruteforcing?
Lmao,exactly as tjs said,"too easy to pull the cmdline params off the stack":
nothing more needed than couple of minutes tracing around with F7/F8 in Olly...

July 07, 2008, 06:31:43 pm
Reply #11

tjs

  • Special Members
  • Sr. Member

  • Offline
  • *

  • 248
Some comments...

- The 'joined' binary can easily be packed to try and protect against very easy attacks like this
- You can find the cmd line params very easily by setting a breakpoint on all references to KERNEL32.WinExec (there's only one)
   - For the uber1337 you can set a breakpoint on the mem structure that passes params to WinExec (look for PUSH EAX)
- Brute forcing 4 character password will only take a few seconds (minutes if it's not in the dictionary).

Thanks for the prize and fun challenge. Hope to see more challenges soon. :)

TJS

July 07, 2008, 06:59:03 pm
Reply #12

sowhat-x

  • Guest
Quote
The 'joined' binary can easily be packed to try and protect against very easy attacks like this
Lol,why should I waste your time like this in the first place...
it wouldn't take you more than 3-4 extra minutes to restore the 'original' .exe  :D

Quote
You can find the cmd line params very easily by setting a breakpoint on all references to KERNEL32.WinExec (there's only one)
Exactly where the "flaw" in the above implementation is in my opinion...as a guess in the wild,
maybe it would make it just a tiny bit harder if the author had used WinRAR's libs/sdk,
instead of calling rar.exe directly...not completely sure though.

Quote
For the uber1337 you can set a breakpoint on the mem structure that passes params to WinExec (look for PUSH EAX)
Not that much 1337 myself,yet...  ;)

Quote
Brute forcing 4 character password will only take a few seconds
Well,we can't be sure for the password length in advance...else,yeah,no debugger would be needed...

Quote
Thanks for the prize and fun challenge. Hope to see more challenges soon.
Lmao,what are you doing here...off to crackmes.de immediately!  ;D  ;)