Speaker 1: Welcome to the deep Dive. Today, we're plunging into a
Speaker 1: stack of sources focused on a genuinely fascinating and critical topic,
Speaker 1: how security tools can programmatically detect mego s malware.
Speaker 2: That's right, you've shared excerpts from the Art of Mac Malware,
Speaker 2: which really gets deep into the technical underpinnings. You know
Speaker 2: how security software spots malicious activity IMAX, often at a
Speaker 2: very low level.
Speaker 1: Think of this as your shortcut. Really, our mission is
Speaker 1: to pull out the most important insights from these pages.
Speaker 1: We want to help you understand what makes Mac malware
Speaker 1: tick and critically, how tools can find it, even the
Speaker 1: nie stuff.
Speaker 2: Exactly getting to the core knowledge without you having to
Speaker 2: weighe through every line of code yourself.
Speaker 1: It's about moving beyond just like lists of known threats.
Speaker 2: Right, understanding the fundamental mechanics of detection.
Speaker 1: Okay, let's unpack this. So the first big challenge you hit,
Speaker 1: maybe the most fundamental one, is the flaw and traditional
Speaker 1: signature based detection.
Speaker 2: Absolutely scanning for known malicious bites as it's efficient, sure
Speaker 2: for malware you've already seen.
Speaker 1: But the drawback is huge massive.
Speaker 2: It completely fails against anything new, unique, or even just
Speaker 2: slightly tweaked.
Speaker 1: And you see this play out perfectly with that fruitfly
Speaker 1: example from the material. Oh yeah, this thing spied on
Speaker 1: people for what over a decade, completely undetected.
Speaker 2: Just because no signature existed for it. Yet it was
Speaker 2: actively using mics and webcams, which.
Speaker 1: Is an incredibly observable behavior, right, even if the code
Speaker 1: bytes were unknown.
Speaker 2: Exactly behavior.
Speaker 1: So the core idea here, the real shift is understanding
Speaker 1: that all malware doesn't matter how new or stealthy it is,
Speaker 1: it has to interact with the system somehow.
Speaker 2: It has to leave a trace. These interactions generate events.
Speaker 1: Things like spawning processes, accessing files.
Speaker 2: Connecting to networks.
Speaker 1: Yeah, all observable, and these behaviors they often reflect the
Speaker 1: malware's goals right directly.
Speaker 2: Adwaar messes with your browser, a back door opens, a
Speaker 2: listening port. Anything wanting persistence must modify this system.
Speaker 1: Somehow, writing files, changing settings.
Speaker 2: Precisely, and programmatically detecting those behaviors. That's where the real
Speaker 2: power in modern detection lies.
Speaker 1: So if behavior is the key, then a logical starting
Speaker 1: point is looking at what's running right now on the system.
Speaker 2: Makes sense. Most Mac malware tends to run as a standalone.
Speaker 1: Process, So analyzing the info, the metadata about these processes
Speaker 1: is a great first step, definitely. One simple technique highlighted
Speaker 1: is just looking for hidden files or directories in the
Speaker 1: process's path.
Speaker 2: You know, the leading dot trick. Malware loves hiding things
Speaker 2: that way. What legitimate apps almost never benign system stuff
Speaker 2: user apps, They just don't hide their main executable path
Speaker 2: like that. So finding a process running from a dot path,
Speaker 2: that's a really strong heuristic, a good early flag.
Speaker 1: You can also pull out the run time arguments, like
Speaker 1: what command line options were used when it launched.
Speaker 2: And these can screen what a process is up to.
Speaker 2: The calendar two ad example is just perfect right, looked legit,
Speaker 2: but but when it launched its hidden cryptomnor xmr stack.
Speaker 2: The arguments literally mentioned monarow and a mining pool address.
Speaker 2: Hard to miss.
Speaker 1: Yeah, not exactly subtle.
Speaker 2: Even just having unusually long or complex arguments for a
Speaker 2: simple looking app can be suspicious in itself.
Speaker 1: Okay, what about process hierarchies. The parent child relationship.
Speaker 2: Also crucial helps you trace the chain of execution. How
Speaker 2: did this thing actually start?
Speaker 1: Because sometimes the malware gets launched by something else.
Speaker 2: Exactly and the source points out some simple ways to
Speaker 2: get the parent process ID. They often just point back
Speaker 2: to launched, the main system launcher, which isn't that helpful.
Speaker 1: Sometimes ah okay, But using the.
Speaker 2: More specific Application Services APIs things like get process for
Speaker 2: PD with process serial numbers. That gives you the true
Speaker 2: user level of parent.
Speaker 1: So you'd see finder or the dock launching calculator for instance,
Speaker 1: precisely or spotlight.
Speaker 2: You get the real origin, which is vital context.
Speaker 1: You mentioned launched. Can you get infodirectly from it too? Oh?
Speaker 2: Yeah. Launch keeps a ton of details about running processes.
Speaker 2: You can programmatically query it and parse out key value
Speaker 2: pairs looking for suspicious settings or properties.
Speaker 1: And another technique mentioned is programmatically running command line tools
Speaker 1: like automating what an analyst might do manually.
Speaker 2: Exactly, using something like the NS task API m code,
Speaker 2: n S task.
Speaker 1: That's Apple's way to run external commands, right.
Speaker 2: So you can automate running say vmap to see what
Speaker 2: libraries a process is loaded into memory, or LSOLF to
Speaker 2: list its open files and network connections.
Speaker 1: We saw that trojanized I term example earlier. Vmap could
Speaker 1: spot that weird library.
Speaker 2: Load absolutely, or LSoft could show you unexpected network sockets
Speaker 2: opened by a process, very powerful for dynamic analysis.
Speaker 1: The source also mentions getting file descriptors using proppit info.
Speaker 2: Yes, file descriptors are how processes handle files, network sockets pipes.
Speaker 2: By filtering for the network types like afinet for IPv
Speaker 2: four or a finet six for IV six.
Speaker 1: You can find open network connections.
Speaker 2: And extract the local and remote IP addresses. The ports
Speaker 2: basically map out as network activity.
Speaker 1: And you can even figure out the architecture Intel, Apple, Silicon.
Speaker 2: Yeah, programmatically check if it's native or running translated under Rosetta.
Speaker 2: All this process info builds a really rich picture.
Speaker 1: Okay, so that's looking at live processes. What about analyzing
Speaker 1: the actual files the executables before they run static analysis? Right?
Speaker 2: Static analysis is inspecting the bleed print the binary file
Speaker 2: itself without running it. It's different from dynamic analysis where
Speaker 2: you watch it run.
Speaker 1: And this static look can reveal a lot.
Speaker 2: Definitely. You can see its direct dependencies, the shared libraries
Speaker 2: it links against, so you.
Speaker 1: Know what system capabilities it intends to use.
Speaker 2: Exactly that trojanized I term against. Statically parsing it show
Speaker 2: that suspicious link to lib crypto using a relative path
Speaker 2: inside the app bundle not typical.
Speaker 1: You can also pull out symbols like function names YEP.
Speaker 2: The names of functions and APIs inside the binarya that
Speaker 2: it calls. These can really give away its purpose.
Speaker 1: So if you see function names related to network sockets
Speaker 1: or key logging, big.
Speaker 2: Red flag using a tool like MM on malware like
Speaker 2: DAZZLESFI can show you functions clearly related to its malicious activities.
Speaker 2: You can even do programmatic introspection to explore properties within
Speaker 2: the code.
Speaker 1: Static analysis can also spot packers right mm hmm malware
Speaker 1: trying to hide its code.
Speaker 2: It can sometimes packers leave obvious clues like section names.
Speaker 2: The IP store malware had that up xdeast section pretty
Speaker 2: clear giveaway it was packed with UPX.
Speaker 1: But I guess malware authors could just rename that section.
Speaker 2: Oh absolutely, custom packers modified ones, they won't have those
Speaker 2: obvious names. Name based detection.
Speaker 1: Is brittle, So how else do you detect packing?
Speaker 2: Entropy? Calculation is a good alternative. Packed code is usually compressed.
Speaker 1: Or encrypted, which makes it look more random.
Speaker 2: Exactly, it increases the randomness the entropy. You can measure
Speaker 2: this programmatically, and if a binaries code section has anomalously
Speaker 2: high entropy compared to typical piled code, it's a strong
Speaker 2: sign it might be packed.
Speaker 1: Okay, shifting gear slightly. Code signing, how does that fit in?
Speaker 2: Code signing is absolutely vital on macOS. It helps security
Speaker 2: tools reduce false positives. If something is properly signed by
Speaker 2: a trusted developer.
Speaker 1: You're less likely to flag it just because it does
Speaker 1: something slightly unusual.
Speaker 2: Right, and it confirms the software hasn't been tampered with
Speaker 2: since it was signed. Apple System's pretty.
Speaker 1: Robust here, but malware authors try to get around it
Speaker 1: using maybe fake certificates or stolen ones.
Speaker 2: They do ad hoc signing, fraudule inserts, yeah, stolen developer IDs, Yeah,
Speaker 2: we see it all. But here's a really interesting point
Speaker 2: from the source. Okay, malware is rarely notorized. Notorization is
Speaker 2: that extra step where developers submit their app to Apple
Speaker 2: before distributing it.
Speaker 1: Apple scans it for malware.
Speaker 2: The scan it, so if an app is notorized, it's
Speaker 2: past that check it's highly likely to be benign. Malware
Speaker 2: authors generally can't or won't go through that notorization process,
Speaker 2: so lack.
Speaker 1: Of notorization isn't proof of malice, but having notorization is
Speaker 1: a strong sign of legitimacy, a.
Speaker 2: Very strong signal yes. And you can check all this
Speaker 2: programmatically using Apple's built in security frameworks, the secypis so
Speaker 2: your tool.
Speaker 1: Can automatically check is it signed, is the cert valid?
Speaker 1: Is it revoked?
Speaker 2: Is it notarized exactly? You can automate what the code
Speaker 2: design command line tool does detect if something like evil
Speaker 2: Quest is unsigned or if Creative Update certificate was revoked.
Speaker 1: And you can specifically check if it's signed by Apple itself.
Speaker 2: Yeah, using the anchor Apple requirement string crucial for verifying
Speaker 2: that core system components haven't been tampered with or replaced.
Speaker 1: All right, So beyond analyzing the code or the process,
Speaker 1: malware needs to stick around.
Speaker 2: Persistence the fundamental goal for most threats, yeah, surviving a reboot,
Speaker 2: and to do that it has to modify the system
Speaker 2: in some detectable way.
Speaker 1: These modifications leave footprints, like.
Speaker 2: What common mechanisms are launch agents and launched demons. These
Speaker 2: use configuration files plists in specific system folders like.
Speaker 1: That dazzles by example, pretending to be software update exactly.
Speaker 2: Others include browser extensions injecting dynamic libraries dlibs, into legitimate
Speaker 2: processes adding log in items.
Speaker 1: The source goes into detail on the background Task Management
Speaker 1: subsystem BTM. That's Apple's internal thing.
Speaker 2: Yeah, it manages certain types of persistent items storing info
Speaker 2: in a database file. You can dump it manually with
Speaker 2: cephal tool dumptium, but programmatically.
Speaker 1: You can get fancier right.
Speaker 2: Security tools can actually load the BTM damon's code dynamically,
Speaker 2: open access its internal functions, read and de serialize that
Speaker 2: database file directly, and enumerate all the registered items. Find
Speaker 2: that ones.
Speaker 1: Getting details like the path, the developer.
Speaker 2: Id tmid how it runs. Yeah, and the.
Speaker 1: Knock knock tool is mentioned as doing this comprehensively.
Speaker 2: Knock Knock is a great example. It uses various plugins, checks, BTM,
Speaker 2: browser extensions, dillib hijacks, log in items, a whole lot
Speaker 2: more to try and find everything set to run automatically, and.
Speaker 1: It shows you the critical details for each item path,
Speaker 1: hash's signature status.
Speaker 2: Virus total results. The plist file involves signing status. If
Speaker 2: flagg windtail is a malicious login item, show dazzle spy
Speaker 2: as unsigned. Really useful for an analyst or a tool?
Speaker 1: What about bypassing these checks malware tries that too, right,
Speaker 1: always a.
Speaker 2: Cat and mouse game. One simple bypass mentioned is just
Speaker 2: running cell tool reset BTM.
Speaker 1: Wipes the BTM database, clean clears.
Speaker 2: The database, stops alerts until the next reboot. But you
Speaker 2: can detect that specific behavior using Apple's Endpoint Security framework.
Speaker 2: You monitor for process executions at seven TPU dexic and
Speaker 2: if you see seven to fel tool running with the
Speaker 2: reset BTM argument, you can block it. You can deny
Speaker 2: the execution right there, prevent the bypass clever.
Speaker 1: What about the other bypass sending a stop signal?
Speaker 2: Sending sig stop to the BTM agent process itself just
Speaker 2: pauses it stops it from reporting.
Speaker 1: And endpoint security can catch that too.
Speaker 2: Yep. Endpoint security has events related to signal delivery. You
Speaker 2: can monitor for signals targeting critical security processes like the
Speaker 2: BTM agent and block them.
Speaker 1: So snapshots are good, persistence checks are good, but you
Speaker 1: really need continuous real time monitoring.
Speaker 2: Absolutely essential to catch things as they happen.
Speaker 1: One source for this is the system log.
Speaker 2: Huge amount of data in the unified log. Now there
Speaker 2: aren't public APIs for efficiently streaming it in real time,
Speaker 2: but reverse engineering the log stream command reveals private APIs
Speaker 2: you could use programmatically okay, and crucially you can apply
Speaker 2: filters predicates to only get the log messages you care.
Speaker 1: About, like only messages about webcam access.
Speaker 2: It's exactly filter for the core media IO subsystem. Maybe
Speaker 2: specific strings like cmio extension property device control PID which
Speaker 2: indicates hardware access, then pull out the process ID, path,
Speaker 2: et cetera from the log message. Oversight uses this method.
Speaker 1: Network monitoring too, continuously using the network extension framework.
Speaker 2: Right. Network extension is key for host based monitoring because
Speaker 2: it tells you which process is making the connection. Using
Speaker 2: APIs like endstat manager Create, you get callbacks with network
Speaker 2: statistics and connection info.
Speaker 1: But the source really emphasizes DNS monitoring as being particularly effective.
Speaker 2: It is highly effective and efficient. Why because almost any
Speaker 2: malware calling home to a command and control server needs to.
Speaker 1: Look up the server's domain name first.
Speaker 2: Right, So monitoring DNS requests and responses instantly flags any
Speaker 2: new process trying to use the network and reveals where
Speaker 2: it's trying to connect, often to suspicious domains like.
Speaker 1: The iweb updater example, begonning to iweb services cloud dot com.
Speaker 2: Just seeing a request for that known bad domain is
Speaker 2: a strong indicator, or the three CX.
Speaker 1: Attack that was huge customers notice traffic to MS storage
Speaker 1: boxes dot com.
Speaker 2: And comparing that domain registered via name cheap with weird
Speaker 2: whis to the legit THREECX dot cloud domain. That unusual
Speaker 2: network behavior was the critical.
Speaker 1: First clue and the DNS monitor tool implents.
Speaker 2: This YEP uses network extension to watch DNS traffic cash
Speaker 2: it potentially block suspicious requests. Need special entitlements, of course,
Speaker 2: since it's system wide monitoring.
Speaker 1: Okay, you've mentioned it a few times now endpoint security,
Speaker 1: this seems like a really core piece.
Speaker 2: It's the modern low level framework from Apple for building
Speaker 2: security tools. It lets you monitor and critically control system.
Speaker 1: Events, stress starts, file access, network events.
Speaker 2: All sorts of things. It requires specific entitlements from Apple
Speaker 2: on Apple Dot Developer, Dot, Endpoint, dash Security, dot Client,
Speaker 2: and needs proper packaging even for background tools.
Speaker 1: The slogger tool is mentioned for exploring the events.
Speaker 2: Super useful. Let's you see what's available. It seven type
Speaker 2: pin notive xx for process execution, notify, create or unlink
Speaker 2: for file events.
Speaker 1: Lots more, and you mentioned the key difference notify versus OFUTH.
Speaker 2: Events critical distinction notify events notify tell you after something happened,
Speaker 2: useful for logging ofth events. AUX, however, intercept the action
Speaker 2: before it happens.
Speaker 1: Giving the security tool a chance to say.
Speaker 2: Yes or no exactly. Your tool receives the authorization request
Speaker 2: and can respond with EASE RESULTALLO or ESOS results then
Speaker 2: a real preventative power.
Speaker 1: And the event data is rich process path, arguments.
Speaker 2: Path RGS, essexacarg CPU type, imaging, apotype, full code signing details,
Speaker 2: id T, id C to hash.
Speaker 1: And on newer mac os you get parent and responsible
Speaker 1: process info. Two audit tokens.
Speaker 2: Yeah. Audit tokens bundle up the security context, helping you
Speaker 2: accurately track process lineage right within the event data.
Speaker 1: Hugely valuable, and you can mute noisy events.
Speaker 2: You don't need right control the fire hose. Yeah, but
Speaker 2: the authodents are where you block things.
Speaker 1: Like we discussed blocking a settle tool reset BTM or
Speaker 1: SIG stop signals to the BTM agent.
Speaker 2: Using EZEPOPEXAC or the appropriate signal off event.
Speaker 1: You could also protect specific files or folders like my documents.
Speaker 2: Definitely monitor a seven timee puth opin it's fifthempeth in
Speaker 2: the link for files and sensitive locations if the process
Speaker 2: trying to access or delete them isn't trusted.
Speaker 1: Deny it stop malware like Windtail from grabbing or deleting
Speaker 1: your stuff.
Speaker 2: Percisely.
Speaker 1: Block block is the tool example here using endpoint security
Speaker 1: for real time persistence detection.
Speaker 2: Yes, block block uses endpoint security and some file monitoring
Speaker 2: specifically to catch persistence attempts in real time. It alerts
Speaker 2: the user immediately and lets them block the action. Uses
Speaker 2: a privileged demon for monitoring and a user agent for
Speaker 2: the UI.
Speaker 1: So it really sounds like you need to put all
Speaker 1: these techniques together. It's not just one magic bullet.
Speaker 2: Not at all. That's the key takeaway. Sophisticated detection is layered.
Speaker 2: A tool might spot suspicious network traffic first.
Speaker 1: From the DNS or a network monitor right then.
Speaker 2: It pivots, checks the process, arguments the code signing, looks
Speaker 2: for persistence attempts. Maybe it does a quick static scan
Speaker 2: of the binary. It combines the evidence.
Speaker 1: The Dazzle spy case fits that persistence caught by file monitoring.
Speaker 1: Maybe endpoint security is notified create for the betlist and.
Speaker 2: It's network C and C access caught by network or
Speaker 2: DNS monitoring looking for that hard coded IP and three CX.
Speaker 1: The initial flag was that we your DNS look up
Speaker 1: via network monitor.
Speaker 2: Exactly Yeah, mcstorage boxes dot Com. That anomalous behavior was
Speaker 2: the trigger later data exfiltration to another domain as MSA
Speaker 2: dot Wiki would also be caught by the same network monitor.
Speaker 1: So wrapping this up, what's the big picture here? From
Speaker 1: this deep dive, I think it's clear.
Speaker 2: That detecting modern Mac malware isn't just about keeping lists
Speaker 2: of known bad files anymore. It's part of it, but
Speaker 2: not the whole game.
Speaker 1: It's really about observing and analyzing the behaviors. What are
Speaker 1: processes and files actually doing on the system exactly?
Speaker 2: Looking for those footprints malware has to leave how it persists,
Speaker 2: how it talks on the network, how it uses system resources.
Speaker 1: And understanding how security tools can tap into macOS itself.
Speaker 1: Using things like endpoint security logging network extensions to watch
Speaker 1: for these behaviors programmatically, it.
Speaker 2: Gives you much deeper, more resilient security insight. It shows
Speaker 2: that even clever threats often leave tracks if you know
Speaker 2: where and how to look.
Speaker 1: So even sophisticated stuff isn't invisible.
Speaker 2: Often not no, which leads to maybe final thoughts that
Speaker 2: you on Okay, if detection is increasingly focused on behavior,
Speaker 2: on spotting things that look unusual or interact with the
Speaker 2: system in sensitive ways, does that mean legitimate, non malicious
Speaker 2: software that just happens to be poorly written or maybe
Speaker 2: does something unconventional could end up getting flagged by these
Speaker 2: same tools. Where does legitimate but weird behavior end and
Speaker 2: potentially unwanted behavior begin.