Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
macOS malware used run-only AppleScripts to avoid detection for five years (zdnet.com)
112 points by abawany on Jan 15, 2021 | hide | past | favorite | 24 comments



"Run-only" AppleScript is compiled to a bytecode format that is very poorly documented. In 2017, I released a CTF reverse-engineering challenge called Scriptabble, in which contestants had to understand a compiled AppleScript file which very slowly computed a flag, then fix or reimplement the algorithm to compute it faster.

Teams generally solved it by reverse engineering the AppleScript runtime to understand the VM bytecode; one writeup is here: https://twitter.com/_niklasb/status/856594863294472193

So, I guess I can't be too surprised that run-only AppleScript ended up as a good malware vector - it's so poorly documented, and there are so few tools to understand it, that it could easily fly under the radar.


I have to compliment you on the design of this challenge. That sounds really hard (but also really fun).

How'd it go?


It was harder than expected! One of the big difficulties with releasing macOS challenges is that not everyone or every team has access to macOS (unlike, say, Linux which is freely available). In principle, contestants could have reversed it by piecing together scattered bits of documentation from the web; in practice, it's a lot easier to debug and reverse with the actual runtime in hand. I was sincerely impressed that several teams were able to solve it by reversing the AppleScript VM.

For future competitions featuring macOS problems, we'll probably rent a cloud Mac for the duration of the contest (24-48h) and give contestants gated access to it, to remove that particular handicap.


> Since "run-only" AppleScript come in a compiled state where the source code isn't human-readable, this made analysis harder for security researchers.

Surely no more difficult than your average malware binary blob?


It's a custom bytecode, so it's definitely harder than just throwing it into a disassembler - you have to understand the VM it runs in, and depending on how it's implemented, that can be a whole other skill set - especially since AppleScript bytecode seems to be mostly undocumented.

If you're an experienced security researcher, you'll get there of course, but definitely not a thing you press F5 at in IDA and go "ah yes, that's how it works".


Shouldn’t malware be detectable even if the binary is entirely a black box? In other words, I would expect certain patterns of system calls to be flagged as malware, regardless of the program.

I’m curious what additional information is derived from static analysis of a program that helps identify it as malware.


I'd guess that the applescript isn't calling syscalls directly, there's probably a translation layer in the middle that is also compiled and the "linkage" is only clear if you understand the bytecode format/runtime.


MalwarehunterTeam on Twitter regularly posts analysis of machine code, so yes. Very true.


A run-only AppleScript shouldn’t be fundamentally any harder to detect than any other form of compiled binary. Does this just mean that security researchers and antivirus tools simply haven’t paid attention to run-only AppleScripts as a vector worth investigating?


Doesn't "run-only" just mean "compiled"?


In this case yes. From the headline I thought there was some kind of weird Apple permission thing where you could mark a binary as unreadable but somehow could still be run to evade malware detection, but it seems like this technical article author is just unfamiliar with the concept of compiling.


It looks like "run-only" is a term-of-the-art in AppleScript, since that label appears on the UI that generates such binaries.


EDIT: Whoops I misread, I thought you were saying that "run-only" was just a flag of sorts.

osacompile[0] does actually produce some form of bytecode when you pass the "x" execute only flag.

Here's a script that opens Safari[1] and the compiled output[2].

[0] https://ss64.com/osx/osacompile.html

[1] https://pastebin.com/raw/u94cwDj7

[2] https://pastebin.com/raw/9uuF39jW


Right, looks like you could choose to distribute an editable version of a script or a compiled version: https://superuser.com/a/14765


> since at least 2015 disguised in pirated (cracked) games and software such as League of Legends

LoL is free, though. Why would anyone use a pirated/cracked version? What would that even mean?


Perhaps a "cracked" version can either use unofficial servers, or permits/includes cheating mods?


>Why would anyone use a pirated/cracked version?

Doesn't even have to be pirated or cracked. ESEA put surreptitious bitcoin miners into their installer/client software back in 2013.

Greed talks.


There's always people who do not know that and download it anyway.


On top of that, there are people who actively avoid official distribution, thinking e.g. anything should come through a middle man. Diversity is weird.


I think this is just poorly written, and what they are trying to say is the bad actors would add their malware to an LOL distro and the redistribute it as "official".


This is a huge security hole. The modified script can be used as a backdoor for all your data and 100% control your computer, because AppleScript can do anything. Probably a legal NSA backdoor that hackers have taken over and a lot of people are in danger. It is not necessary to install pirated software, the download can happen through a hole in the browser. I an old school security researcher, once saw how hacker control a Mac and could turn on/off Wi-Fi, modify files, paint over windows, etc. AppleScript can install new backdoors on the target system with manual control, which allows the hacker to hide his activities by playing along with the victim. Be careful, stay safe.


Does this evade Gatekeeper?


Yes, apparently.


Yes if it's compiled as a standalone script or script bundle and then run using osascript.

You can also compile osa scripts into .app bundles, since these are new, standalone apps they need to have a valid signature.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: