4 ms·

The author says the binary looks like malware because it self-deletes, sleeps and touches this uninstaller thing. But the script he proposes, which would be tri

• PcChip 3y ago
  >How is the proposed solution better than the original thing? I'm only assuming here, but maybe because it won't crash explorer and it's just a few lines of self-documenting code?
  • sim7c00 3y ago
    Haha, well fair enough the crash is bad indeed, good point! This isn't intended behavior though and presumably, it doesn't crash on in cases of this technique being implemented in uninstallers. (a bit of a guess i admit!)
    • ChrisSD 3y ago
      The fact it injects into another process means they can't know if it'll crash or not. You're just one Explorer update away from things changing enough for the hack to crash it. I guess they could do this more robustly. I.e pause the entire explorer process, save all its state, remotely allocate new memory to inject their code, remotely create a new thread, run only that thread using the injected code, restore all the process' state and finally start it running where it left off. A script would be easier though.
      • xp84 3y ago
        Agree completely. I would have assumed (naively?) that they could just copy their uninstaller into a temp folder and run it from there, and just rely on the OS to nuke it in due time, but as a consumer I appreciate the thoroughness of an uninstaller that leaves no trace.
        • sim7c00 3y ago
          honestly your idea about the tmp dir i think is better than the no trace option. especially given the hacky nature of self deleting stuff. if you have so many uninstallers around that the disk fills up the tmp.dir cleaning would fix it, which is a common first thing to clean when cleaning the filesystem. i like your idea :)
      • nneonneo 3y ago
        The problem isn’t that the injected thread is racing explorer - indeed, pausing the entirety of explorer to run your uninstaller would probably be strictly more dangerous than what they’re doing - the problem is that the injected thread is using function pointers that do not exist in explorer.exe. Most likely, the reason is that the uninstaller itself has been “detoured” by yet another program to patch calls to certain functions, and it’s copying the detoured addresses instead of the addresses to the real functions. Both detouring and remote thread injection are supported on Windows, but fall into the category of gray-hat techniques; there are some legitimate uses but quite a lot of illegitimate uses, and using these techniques correctly (without crashing anything!) can be a real challenge.
    • Arainach 3y ago
      You find the instructions to sweep your floor cumbersome so you reprogram your neighbor's Roomba to come clean your floor. Sure, it may well go back to their house and no harm done, but it's hacky, socially unacceptable, and no matter how hard your broom is to use it's not OK.
    • S3rM5Y5 3y ago
      The technique could have been made a little more robust by calling GetProcAddress to get the function pointers in Explorer's context, assuming GetProcAddress wasn't itself detoured.
• oefrha 3y ago
  Maybe it’s less likely to be flagged or interfered with by antivirus? Antivirus uses all kinds of shitty heuristics, seeing that my Go executables built with -ldflags="-H windowsgui" are flagged as malware by Windows Defender and co. all the time. It’s maddening.
  • sim7c00 3y ago
    that's fair enough. perhaps they can more easily in AV land make some kind of signature that whitelists this self-deletion javascript method because the script is more readable. though i'd expect a good AV to be at least worried if some executable on my system runs a script file via a scripthost.
• kazinator 3y ago
  The .js script isn't injecting code into another program in order to deletee itself; it is deleeting itself directly. It can do that because, I'm guessing, the file isn't open; the run-time isn't executing instructions from that file. The file was read, the content compiled into memory, and closed. The script is deleting its source code, not itself. What actually deletes the script itself is the garbage collector in the run-time. Once the fso.Deletefile call and the for loop are executed, they are no longer reachable and so they are garbage. If there is a way for the "var fso" and "var path" variables to go out of scope, they become garbage also. A binary executable is mapped into memory while the process is running it. In Windows, an open file cannot be deleted. But, even on Windows, a prog.exe could delete the prog.c source code it was compiled from, right? Same thing, sort of.
  • masfuerte 3y ago
    Being pedantic, you can delete open files on Windows if you open them with FILE_SHARE_DELETE.
  • sim7c00 3y ago
    The script doesn't inject. But a lot of malware downloads a script and runs it, so you'd hit another rule.
    • kazinator 3y ago
      The way I understand it, the uninstaller program that wants to delete itself doesn't have to download the script from anywhere; it generates the script out to a file.
      • sim7c00 3y ago
        this is true, a good heuristic would see the difference perhaps. but malicious scripts can also be generated rather than downloaded (or more commonly decrypted from some seemonly random data) so it can be hard to tell, especially given threat actors having access to security products easily while the opposite is not always true.
  • 3y ago
• thombat 3y ago
  It's more about how it does it: injecting executable code directly into the stack so that some other code unwittingly transfers control to it. Stack-smashing is a lot more malware-ISH than a few lines of shell script.
  • sim7c00 3y ago
    They inject something into Explorer. I would assume that to be some DLL that is injected? ---- Neither code injection nor detouring is officially supported. I can’t tell who did the detouring. Maybe somebody added a detour to the uninstaller, unaware that the uninstaller is going to inject a call to the detour into Explorer. Or maybe the detour was injected by anti-malware software. Or maybe the detour was injected by Windows’ own application compatibility layer. Whatever the reason, the result was a crash in Explorer. ---- I'd think the anti-malware guess here would be correct, and that (DLL) injection was stopped, and thus some crash happened. Thanks for your reply. The DLL would execute something from its stack so it can be somewhat dynamic (perhaps some path or something is generated before the injection or so - really little to go on here...) and not need to make a heap allocation within Explorer.exe. (this is perhaps a bit too much to assume idk.) Thanks for your insights!
    • darkclouds 3y ago
      >I can’t tell who did the detouring I was thinking hmm and so it continues that game of whack a mole. If a new OS could be designed from scratch, there must be a way to prevent this sort of stuff.
      • sim7c00 3y ago
        i am making an os from scratch. but admittedly, i am so far from this stuff i will never ever have anything even closely related to such a problem hah. its so much work :'( (fun tho!)
• ghostpepper 3y ago
  Once you move past comparing hashes against known malware (by definition useless against novel malware), and the slightly more complex matching of specific binary strings, detecting malware with "shitty heuristics" is basically all we've got. Companies that buy AV/EDR products expect them to detect unwanted behaviour while allowing any sort of weird, hacky, abuses of the system that they rely upon for their business. It's never been entirely clear to me why windows provides such a rich interface for one process to inject and start executing code in the address space of another but IMHO I want to know when this is happening even when it's done by a "legitimate" uninstaller.
  • sim7c00 3y ago
    The first point is true i admit. There are very complex and good ways to identify stuff but those perform so bad they cannot be used in practice. AV/EDR products do try to prevent a lot of stuff. They can 'generically' block things like injection etc. by 'hooking all the things' and injecting into everything (yes, yuck :D and still kind of heuristic based i admit!) to make certain sections read only or remove executable mappings etc. (got/plt/stack/...) Linux or more specifically ELF files also have an easy vector to allow injection by having a dynamic table entry for debugging purposes which can be trivially overwritten for example. "ibc.so" :(). I'm not sure anyone uses that entry validly... especially since there's better/less awkward debugging interfaces than injecting a debugger DLL into something :') at least in x86/64 Linux land. (ELFShell sure was fun tho!)
    • monocasa 3y ago
      If you're talking about LD_PRELOAD, I used it for an integration test suite of low level system components.
      • sim7c00 3y ago
        im not sure how the implementation of ld preload works, but this is a linker directive if i am correct. the thing i am on about is the DT_DEBUG dynamic table entry. its an entry meant to allow a debugging dll to be loaded. you can overwrite it and point it to a malicious dll (with a bit of difficulties) to get injection going. its then hardcoded into tue binary by your modification. admittedly maybe ld preload is easier if thats allowed on a system
• some_random 3y ago
  Cybersecurity is pretty much all bad heuristics with the belief that if you use enough of them they average out to an ok determination of maliciousness. It works alright, sometimes.