WEBVTT

1
00:00:00.080 --> 00:00:02.960
<v Speaker 1>Welcome to the deep Dive. Today, we're plunging into a

2
00:00:03.000 --> 00:00:08.439
<v Speaker 1>stack of sources focused on a genuinely fascinating and critical topic,

3
00:00:09.000 --> 00:00:13.480
<v Speaker 1>how security tools can programmatically detect mego s malware.

4
00:00:13.679 --> 00:00:16.920
<v Speaker 2>That's right, you've shared excerpts from the Art of Mac Malware,

5
00:00:17.199 --> 00:00:21.039
<v Speaker 2>which really gets deep into the technical underpinnings. You know

6
00:00:21.079 --> 00:00:25.399
<v Speaker 2>how security software spots malicious activity IMAX, often at a

7
00:00:25.480 --> 00:00:26.120
<v Speaker 2>very low level.

8
00:00:26.359 --> 00:00:29.399
<v Speaker 1>Think of this as your shortcut. Really, our mission is

9
00:00:29.399 --> 00:00:32.159
<v Speaker 1>to pull out the most important insights from these pages.

10
00:00:32.560 --> 00:00:34.880
<v Speaker 1>We want to help you understand what makes Mac malware

11
00:00:34.960 --> 00:00:38.200
<v Speaker 1>tick and critically, how tools can find it, even the

12
00:00:38.280 --> 00:00:38.840
<v Speaker 1>nie stuff.

13
00:00:39.039 --> 00:00:41.840
<v Speaker 2>Exactly getting to the core knowledge without you having to

14
00:00:41.880 --> 00:00:43.719
<v Speaker 2>weighe through every line of code yourself.

15
00:00:43.799 --> 00:00:47.600
<v Speaker 1>It's about moving beyond just like lists of known threats.

16
00:00:47.359 --> 00:00:49.759
<v Speaker 2>Right, understanding the fundamental mechanics of detection.

17
00:00:49.960 --> 00:00:52.280
<v Speaker 1>Okay, let's unpack this. So the first big challenge you hit,

18
00:00:52.320 --> 00:00:55.560
<v Speaker 1>maybe the most fundamental one, is the flaw and traditional

19
00:00:55.640 --> 00:00:56.759
<v Speaker 1>signature based detection.

20
00:00:57.000 --> 00:01:01.520
<v Speaker 2>Absolutely scanning for known malicious bites as it's efficient, sure

21
00:01:01.679 --> 00:01:03.119
<v Speaker 2>for malware you've already seen.

22
00:01:03.039 --> 00:01:05.280
<v Speaker 1>But the drawback is huge massive.

23
00:01:05.760 --> 00:01:09.519
<v Speaker 2>It completely fails against anything new, unique, or even just

24
00:01:09.560 --> 00:01:10.480
<v Speaker 2>slightly tweaked.

25
00:01:10.640 --> 00:01:12.719
<v Speaker 1>And you see this play out perfectly with that fruitfly

26
00:01:12.799 --> 00:01:15.319
<v Speaker 1>example from the material. Oh yeah, this thing spied on

27
00:01:15.400 --> 00:01:19.680
<v Speaker 1>people for what over a decade, completely undetected.

28
00:01:19.280 --> 00:01:22.319
<v Speaker 2>Just because no signature existed for it. Yet it was

29
00:01:22.400 --> 00:01:24.920
<v Speaker 2>actively using mics and webcams, which.

30
00:01:24.760 --> 00:01:28.159
<v Speaker 1>Is an incredibly observable behavior, right, even if the code

31
00:01:28.159 --> 00:01:29.079
<v Speaker 1>bytes were unknown.

32
00:01:29.280 --> 00:01:30.480
<v Speaker 2>Exactly behavior.

33
00:01:30.519 --> 00:01:33.480
<v Speaker 1>So the core idea here, the real shift is understanding

34
00:01:33.560 --> 00:01:36.480
<v Speaker 1>that all malware doesn't matter how new or stealthy it is,

35
00:01:36.879 --> 00:01:39.040
<v Speaker 1>it has to interact with the system somehow.

36
00:01:39.319 --> 00:01:43.120
<v Speaker 2>It has to leave a trace. These interactions generate events.

37
00:01:43.000 --> 00:01:46.200
<v Speaker 1>Things like spawning processes, accessing files.

38
00:01:45.799 --> 00:01:46.799
<v Speaker 2>Connecting to networks.

39
00:01:46.879 --> 00:01:50.840
<v Speaker 1>Yeah, all observable, and these behaviors they often reflect the

40
00:01:50.879 --> 00:01:52.519
<v Speaker 1>malware's goals right directly.

41
00:01:52.879 --> 00:01:55.879
<v Speaker 2>Adwaar messes with your browser, a back door opens, a

42
00:01:55.879 --> 00:02:00.719
<v Speaker 2>listening port. Anything wanting persistence must modify this system.

43
00:02:00.359 --> 00:02:03.000
<v Speaker 1>Somehow, writing files, changing settings.

44
00:02:02.560 --> 00:02:07.319
<v Speaker 2>Precisely, and programmatically detecting those behaviors. That's where the real

45
00:02:07.400 --> 00:02:09.159
<v Speaker 2>power in modern detection lies.

46
00:02:09.479 --> 00:02:12.759
<v Speaker 1>So if behavior is the key, then a logical starting

47
00:02:12.759 --> 00:02:15.360
<v Speaker 1>point is looking at what's running right now on the system.

48
00:02:15.960 --> 00:02:20.280
<v Speaker 2>Makes sense. Most Mac malware tends to run as a standalone.

49
00:02:19.680 --> 00:02:24.159
<v Speaker 1>Process, So analyzing the info, the metadata about these processes

50
00:02:24.199 --> 00:02:27.360
<v Speaker 1>is a great first step, definitely. One simple technique highlighted

51
00:02:27.560 --> 00:02:30.360
<v Speaker 1>is just looking for hidden files or directories in the

52
00:02:30.400 --> 00:02:31.479
<v Speaker 1>process's path.

53
00:02:31.439 --> 00:02:34.560
<v Speaker 2>You know, the leading dot trick. Malware loves hiding things

54
00:02:34.560 --> 00:02:38.680
<v Speaker 2>that way. What legitimate apps almost never benign system stuff

55
00:02:38.800 --> 00:02:42.599
<v Speaker 2>user apps, They just don't hide their main executable path

56
00:02:42.719 --> 00:02:45.280
<v Speaker 2>like that. So finding a process running from a dot path,

57
00:02:45.319 --> 00:02:49.280
<v Speaker 2>that's a really strong heuristic, a good early flag.

58
00:02:49.360 --> 00:02:51.319
<v Speaker 1>You can also pull out the run time arguments, like

59
00:02:51.680 --> 00:02:54.520
<v Speaker 1>what command line options were used when it launched.

60
00:02:54.120 --> 00:02:56.039
<v Speaker 2>And these can screen what a process is up to.

61
00:02:56.120 --> 00:02:59.319
<v Speaker 2>The calendar two ad example is just perfect right, looked legit,

62
00:02:59.439 --> 00:03:03.199
<v Speaker 2>but but when it launched its hidden cryptomnor xmr stack.

63
00:03:03.599 --> 00:03:07.719
<v Speaker 2>The arguments literally mentioned monarow and a mining pool address.

64
00:03:07.759 --> 00:03:08.400
<v Speaker 2>Hard to miss.

65
00:03:08.639 --> 00:03:10.039
<v Speaker 1>Yeah, not exactly subtle.

66
00:03:10.280 --> 00:03:14.199
<v Speaker 2>Even just having unusually long or complex arguments for a

67
00:03:14.240 --> 00:03:17.000
<v Speaker 2>simple looking app can be suspicious in itself.

68
00:03:17.080 --> 00:03:21.759
<v Speaker 1>Okay, what about process hierarchies. The parent child relationship.

69
00:03:21.280 --> 00:03:25.560
<v Speaker 2>Also crucial helps you trace the chain of execution. How

70
00:03:25.599 --> 00:03:26.919
<v Speaker 2>did this thing actually start?

71
00:03:27.319 --> 00:03:30.080
<v Speaker 1>Because sometimes the malware gets launched by something else.

72
00:03:29.960 --> 00:03:32.919
<v Speaker 2>Exactly and the source points out some simple ways to

73
00:03:32.960 --> 00:03:35.680
<v Speaker 2>get the parent process ID. They often just point back

74
00:03:35.680 --> 00:03:39.840
<v Speaker 2>to launched, the main system launcher, which isn't that helpful.

75
00:03:39.520 --> 00:03:41.840
<v Speaker 1>Sometimes ah okay, But using the.

76
00:03:41.800 --> 00:03:45.680
<v Speaker 2>More specific Application Services APIs things like get process for

77
00:03:45.719 --> 00:03:49.280
<v Speaker 2>PD with process serial numbers. That gives you the true

78
00:03:49.400 --> 00:03:50.520
<v Speaker 2>user level of parent.

79
00:03:50.400 --> 00:03:53.759
<v Speaker 1>So you'd see finder or the dock launching calculator for instance,

80
00:03:53.800 --> 00:03:55.080
<v Speaker 1>precisely or spotlight.

81
00:03:55.280 --> 00:03:57.919
<v Speaker 2>You get the real origin, which is vital context.

82
00:03:58.159 --> 00:04:01.439
<v Speaker 1>You mentioned launched. Can you get infodirectly from it too? Oh?

83
00:04:01.560 --> 00:04:04.400
<v Speaker 2>Yeah. Launch keeps a ton of details about running processes.

84
00:04:04.599 --> 00:04:07.520
<v Speaker 2>You can programmatically query it and parse out key value

85
00:04:07.520 --> 00:04:10.000
<v Speaker 2>pairs looking for suspicious settings or properties.

86
00:04:10.159 --> 00:04:13.800
<v Speaker 1>And another technique mentioned is programmatically running command line tools

87
00:04:14.039 --> 00:04:17.279
<v Speaker 1>like automating what an analyst might do manually.

88
00:04:16.959 --> 00:04:20.399
<v Speaker 2>Exactly, using something like the NS task API m code,

89
00:04:20.600 --> 00:04:21.360
<v Speaker 2>n S task.

90
00:04:21.600 --> 00:04:24.199
<v Speaker 1>That's Apple's way to run external commands, right.

91
00:04:24.040 --> 00:04:27.000
<v Speaker 2>So you can automate running say vmap to see what

92
00:04:27.079 --> 00:04:30.279
<v Speaker 2>libraries a process is loaded into memory, or LSOLF to

93
00:04:30.319 --> 00:04:32.240
<v Speaker 2>list its open files and network connections.

94
00:04:32.560 --> 00:04:35.920
<v Speaker 1>We saw that trojanized I term example earlier. Vmap could

95
00:04:35.959 --> 00:04:37.839
<v Speaker 1>spot that weird library.

96
00:04:37.399 --> 00:04:41.519
<v Speaker 2>Load absolutely, or LSoft could show you unexpected network sockets

97
00:04:41.519 --> 00:04:45.199
<v Speaker 2>opened by a process, very powerful for dynamic analysis.

98
00:04:45.279 --> 00:04:48.160
<v Speaker 1>The source also mentions getting file descriptors using proppit info.

99
00:04:48.360 --> 00:04:52.560
<v Speaker 2>Yes, file descriptors are how processes handle files, network sockets pipes.

100
00:04:53.000 --> 00:04:56.000
<v Speaker 2>By filtering for the network types like afinet for IPv

101
00:04:56.120 --> 00:04:58.680
<v Speaker 2>four or a finet six for IV six.

102
00:04:58.560 --> 00:05:00.920
<v Speaker 1>You can find open network connections.

103
00:05:00.319 --> 00:05:03.319
<v Speaker 2>And extract the local and remote IP addresses. The ports

104
00:05:03.680 --> 00:05:05.839
<v Speaker 2>basically map out as network activity.

105
00:05:05.480 --> 00:05:08.639
<v Speaker 1>And you can even figure out the architecture Intel, Apple, Silicon.

106
00:05:08.879 --> 00:05:13.120
<v Speaker 2>Yeah, programmatically check if it's native or running translated under Rosetta.

107
00:05:13.199 --> 00:05:15.759
<v Speaker 2>All this process info builds a really rich picture.

108
00:05:16.000 --> 00:05:19.360
<v Speaker 1>Okay, so that's looking at live processes. What about analyzing

109
00:05:19.399 --> 00:05:23.800
<v Speaker 1>the actual files the executables before they run static analysis? Right?

110
00:05:23.879 --> 00:05:27.040
<v Speaker 2>Static analysis is inspecting the bleed print the binary file

111
00:05:27.079 --> 00:05:30.480
<v Speaker 2>itself without running it. It's different from dynamic analysis where

112
00:05:30.480 --> 00:05:31.279
<v Speaker 2>you watch it run.

113
00:05:31.439 --> 00:05:33.360
<v Speaker 1>And this static look can reveal a lot.

114
00:05:33.639 --> 00:05:36.560
<v Speaker 2>Definitely. You can see its direct dependencies, the shared libraries

115
00:05:36.560 --> 00:05:38.319
<v Speaker 2>it links against, so you.

116
00:05:38.360 --> 00:05:41.759
<v Speaker 1>Know what system capabilities it intends to use.

117
00:05:41.720 --> 00:05:46.199
<v Speaker 2>Exactly that trojanized I term against. Statically parsing it show

118
00:05:46.279 --> 00:05:49.759
<v Speaker 2>that suspicious link to lib crypto using a relative path

119
00:05:49.879 --> 00:05:52.040
<v Speaker 2>inside the app bundle not typical.

120
00:05:52.160 --> 00:05:55.439
<v Speaker 1>You can also pull out symbols like function names YEP.

121
00:05:55.279 --> 00:05:58.120
<v Speaker 2>The names of functions and APIs inside the binarya that

122
00:05:58.199 --> 00:06:00.600
<v Speaker 2>it calls. These can really give away its purpose.

123
00:06:00.720 --> 00:06:03.600
<v Speaker 1>So if you see function names related to network sockets

124
00:06:03.680 --> 00:06:05.160
<v Speaker 1>or key logging, big.

125
00:06:05.000 --> 00:06:08.120
<v Speaker 2>Red flag using a tool like MM on malware like

126
00:06:08.199 --> 00:06:12.240
<v Speaker 2>DAZZLESFI can show you functions clearly related to its malicious activities.

127
00:06:12.680 --> 00:06:15.920
<v Speaker 2>You can even do programmatic introspection to explore properties within

128
00:06:15.959 --> 00:06:16.439
<v Speaker 2>the code.

129
00:06:16.560 --> 00:06:20.120
<v Speaker 1>Static analysis can also spot packers right mm hmm malware

130
00:06:20.120 --> 00:06:21.199
<v Speaker 1>trying to hide its code.

131
00:06:21.360 --> 00:06:25.680
<v Speaker 2>It can sometimes packers leave obvious clues like section names.

132
00:06:26.199 --> 00:06:29.399
<v Speaker 2>The IP store malware had that up xdeast section pretty

133
00:06:29.399 --> 00:06:31.160
<v Speaker 2>clear giveaway it was packed with UPX.

134
00:06:31.399 --> 00:06:33.959
<v Speaker 1>But I guess malware authors could just rename that section.

135
00:06:34.079 --> 00:06:37.800
<v Speaker 2>Oh absolutely, custom packers modified ones, they won't have those

136
00:06:37.839 --> 00:06:40.360
<v Speaker 2>obvious names. Name based detection.

137
00:06:40.160 --> 00:06:43.079
<v Speaker 1>Is brittle, So how else do you detect packing?

138
00:06:43.480 --> 00:06:48.360
<v Speaker 2>Entropy? Calculation is a good alternative. Packed code is usually compressed.

139
00:06:47.879 --> 00:06:50.720
<v Speaker 1>Or encrypted, which makes it look more random.

140
00:06:50.879 --> 00:06:54.360
<v Speaker 2>Exactly, it increases the randomness the entropy. You can measure

141
00:06:54.399 --> 00:06:58.319
<v Speaker 2>this programmatically, and if a binaries code section has anomalously

142
00:06:58.360 --> 00:07:01.680
<v Speaker 2>high entropy compared to typical piled code, it's a strong

143
00:07:01.680 --> 00:07:02.680
<v Speaker 2>sign it might be packed.

144
00:07:02.800 --> 00:07:06.120
<v Speaker 1>Okay, shifting gear slightly. Code signing, how does that fit in?

145
00:07:06.360 --> 00:07:09.839
<v Speaker 2>Code signing is absolutely vital on macOS. It helps security

146
00:07:09.839 --> 00:07:13.240
<v Speaker 2>tools reduce false positives. If something is properly signed by

147
00:07:13.240 --> 00:07:14.600
<v Speaker 2>a trusted developer.

148
00:07:14.439 --> 00:07:16.560
<v Speaker 1>You're less likely to flag it just because it does

149
00:07:16.560 --> 00:07:18.360
<v Speaker 1>something slightly unusual.

150
00:07:18.160 --> 00:07:20.680
<v Speaker 2>Right, and it confirms the software hasn't been tampered with

151
00:07:20.720 --> 00:07:23.000
<v Speaker 2>since it was signed. Apple System's pretty.

152
00:07:22.800 --> 00:07:25.680
<v Speaker 1>Robust here, but malware authors try to get around it

153
00:07:26.240 --> 00:07:28.519
<v Speaker 1>using maybe fake certificates or stolen ones.

154
00:07:28.639 --> 00:07:33.839
<v Speaker 2>They do ad hoc signing, fraudule inserts, yeah, stolen developer IDs, Yeah,

155
00:07:34.000 --> 00:07:36.360
<v Speaker 2>we see it all. But here's a really interesting point

156
00:07:36.399 --> 00:07:41.480
<v Speaker 2>from the source. Okay, malware is rarely notorized. Notorization is

157
00:07:41.519 --> 00:07:44.279
<v Speaker 2>that extra step where developers submit their app to Apple

158
00:07:44.319 --> 00:07:45.279
<v Speaker 2>before distributing it.

159
00:07:45.360 --> 00:07:46.839
<v Speaker 1>Apple scans it for malware.

160
00:07:46.920 --> 00:07:48.959
<v Speaker 2>The scan it, so if an app is notorized, it's

161
00:07:49.040 --> 00:07:53.480
<v Speaker 2>past that check it's highly likely to be benign. Malware

162
00:07:53.519 --> 00:07:57.439
<v Speaker 2>authors generally can't or won't go through that notorization process,

163
00:07:57.560 --> 00:07:58.199
<v Speaker 2>so lack.

164
00:07:58.040 --> 00:08:01.519
<v Speaker 1>Of notorization isn't proof of malice, but having notorization is

165
00:08:01.560 --> 00:08:03.399
<v Speaker 1>a strong sign of legitimacy, a.

166
00:08:03.439 --> 00:08:05.800
<v Speaker 2>Very strong signal yes. And you can check all this

167
00:08:05.839 --> 00:08:09.879
<v Speaker 2>programmatically using Apple's built in security frameworks, the secypis so

168
00:08:09.920 --> 00:08:10.480
<v Speaker 2>your tool.

169
00:08:10.279 --> 00:08:13.399
<v Speaker 1>Can automatically check is it signed, is the cert valid?

170
00:08:13.519 --> 00:08:14.199
<v Speaker 1>Is it revoked?

171
00:08:14.319 --> 00:08:17.079
<v Speaker 2>Is it notarized exactly? You can automate what the code

172
00:08:17.120 --> 00:08:20.120
<v Speaker 2>design command line tool does detect if something like evil

173
00:08:20.160 --> 00:08:24.079
<v Speaker 2>Quest is unsigned or if Creative Update certificate was revoked.

174
00:08:23.800 --> 00:08:26.639
<v Speaker 1>And you can specifically check if it's signed by Apple itself.

175
00:08:27.000 --> 00:08:31.240
<v Speaker 2>Yeah, using the anchor Apple requirement string crucial for verifying

176
00:08:31.240 --> 00:08:34.279
<v Speaker 2>that core system components haven't been tampered with or replaced.

177
00:08:34.320 --> 00:08:36.639
<v Speaker 1>All right, So beyond analyzing the code or the process,

178
00:08:36.840 --> 00:08:38.279
<v Speaker 1>malware needs to stick around.

179
00:08:38.799 --> 00:08:43.039
<v Speaker 2>Persistence the fundamental goal for most threats, yeah, surviving a reboot,

180
00:08:43.519 --> 00:08:45.960
<v Speaker 2>and to do that it has to modify the system

181
00:08:46.120 --> 00:08:47.399
<v Speaker 2>in some detectable way.

182
00:08:47.559 --> 00:08:49.720
<v Speaker 1>These modifications leave footprints, like.

183
00:08:49.679 --> 00:08:53.879
<v Speaker 2>What common mechanisms are launch agents and launched demons. These

184
00:08:53.960 --> 00:08:57.679
<v Speaker 2>use configuration files plists in specific system folders like.

185
00:08:57.639 --> 00:09:02.200
<v Speaker 1>That dazzles by example, pretending to be software update exactly.

186
00:09:02.480 --> 00:09:07.679
<v Speaker 2>Others include browser extensions injecting dynamic libraries dlibs, into legitimate

187
00:09:07.720 --> 00:09:09.639
<v Speaker 2>processes adding log in items.

188
00:09:09.720 --> 00:09:12.200
<v Speaker 1>The source goes into detail on the background Task Management

189
00:09:12.279 --> 00:09:14.519
<v Speaker 1>subsystem BTM. That's Apple's internal thing.

190
00:09:14.759 --> 00:09:17.720
<v Speaker 2>Yeah, it manages certain types of persistent items storing info

191
00:09:17.759 --> 00:09:20.279
<v Speaker 2>in a database file. You can dump it manually with

192
00:09:20.399 --> 00:09:23.679
<v Speaker 2>cephal tool dumptium, but programmatically.

193
00:09:22.919 --> 00:09:24.200
<v Speaker 1>You can get fancier right.

194
00:09:24.360 --> 00:09:27.879
<v Speaker 2>Security tools can actually load the BTM damon's code dynamically,

195
00:09:28.240 --> 00:09:31.799
<v Speaker 2>open access its internal functions, read and de serialize that

196
00:09:31.919 --> 00:09:35.679
<v Speaker 2>database file directly, and enumerate all the registered items. Find

197
00:09:35.799 --> 00:09:36.440
<v Speaker 2>that ones.

198
00:09:36.440 --> 00:09:39.559
<v Speaker 1>Getting details like the path, the developer.

199
00:09:39.120 --> 00:09:41.080
<v Speaker 2>Id tmid how it runs. Yeah, and the.

200
00:09:41.080 --> 00:09:44.360
<v Speaker 1>Knock knock tool is mentioned as doing this comprehensively.

201
00:09:44.720 --> 00:09:48.120
<v Speaker 2>Knock Knock is a great example. It uses various plugins, checks, BTM,

202
00:09:48.240 --> 00:09:51.720
<v Speaker 2>browser extensions, dillib hijacks, log in items, a whole lot

203
00:09:51.759 --> 00:09:54.480
<v Speaker 2>more to try and find everything set to run automatically, and.

204
00:09:54.440 --> 00:09:57.000
<v Speaker 1>It shows you the critical details for each item path,

205
00:09:57.240 --> 00:09:59.320
<v Speaker 1>hash's signature status.

206
00:09:59.039 --> 00:10:03.600
<v Speaker 2>Virus total results. The plist file involves signing status. If

207
00:10:03.639 --> 00:10:07.200
<v Speaker 2>flagg windtail is a malicious login item, show dazzle spy

208
00:10:07.320 --> 00:10:10.080
<v Speaker 2>as unsigned. Really useful for an analyst or a tool?

209
00:10:10.200 --> 00:10:13.200
<v Speaker 1>What about bypassing these checks malware tries that too, right,

210
00:10:13.360 --> 00:10:13.759
<v Speaker 1>always a.

211
00:10:13.759 --> 00:10:16.240
<v Speaker 2>Cat and mouse game. One simple bypass mentioned is just

212
00:10:16.360 --> 00:10:18.480
<v Speaker 2>running cell tool reset BTM.

213
00:10:18.120 --> 00:10:20.519
<v Speaker 1>Wipes the BTM database, clean clears.

214
00:10:20.240 --> 00:10:23.360
<v Speaker 2>The database, stops alerts until the next reboot. But you

215
00:10:23.399 --> 00:10:27.600
<v Speaker 2>can detect that specific behavior using Apple's Endpoint Security framework.

216
00:10:28.279 --> 00:10:32.480
<v Speaker 2>You monitor for process executions at seven TPU dexic and

217
00:10:32.519 --> 00:10:34.919
<v Speaker 2>if you see seven to fel tool running with the

218
00:10:34.960 --> 00:10:37.440
<v Speaker 2>reset BTM argument, you can block it. You can deny

219
00:10:37.480 --> 00:10:40.279
<v Speaker 2>the execution right there, prevent the bypass clever.

220
00:10:40.639 --> 00:10:43.440
<v Speaker 1>What about the other bypass sending a stop signal?

221
00:10:43.519 --> 00:10:47.480
<v Speaker 2>Sending sig stop to the BTM agent process itself just

222
00:10:47.720 --> 00:10:50.120
<v Speaker 2>pauses it stops it from reporting.

223
00:10:49.799 --> 00:10:51.639
<v Speaker 1>And endpoint security can catch that too.

224
00:10:51.759 --> 00:10:55.399
<v Speaker 2>Yep. Endpoint security has events related to signal delivery. You

225
00:10:55.399 --> 00:10:58.559
<v Speaker 2>can monitor for signals targeting critical security processes like the

226
00:10:58.600 --> 00:10:59.960
<v Speaker 2>BTM agent and block them.

227
00:11:00.519 --> 00:11:03.840
<v Speaker 1>So snapshots are good, persistence checks are good, but you

228
00:11:03.960 --> 00:11:07.320
<v Speaker 1>really need continuous real time monitoring.

229
00:11:06.919 --> 00:11:09.519
<v Speaker 2>Absolutely essential to catch things as they happen.

230
00:11:09.679 --> 00:11:11.639
<v Speaker 1>One source for this is the system log.

231
00:11:12.080 --> 00:11:14.879
<v Speaker 2>Huge amount of data in the unified log. Now there

232
00:11:14.879 --> 00:11:17.960
<v Speaker 2>aren't public APIs for efficiently streaming it in real time,

233
00:11:18.480 --> 00:11:22.320
<v Speaker 2>but reverse engineering the log stream command reveals private APIs

234
00:11:22.320 --> 00:11:25.240
<v Speaker 2>you could use programmatically okay, and crucially you can apply

235
00:11:25.320 --> 00:11:28.559
<v Speaker 2>filters predicates to only get the log messages you care.

236
00:11:28.440 --> 00:11:30.960
<v Speaker 1>About, like only messages about webcam access.

237
00:11:31.200 --> 00:11:35.320
<v Speaker 2>It's exactly filter for the core media IO subsystem. Maybe

238
00:11:35.360 --> 00:11:39.879
<v Speaker 2>specific strings like cmio extension property device control PID which

239
00:11:39.960 --> 00:11:43.639
<v Speaker 2>indicates hardware access, then pull out the process ID, path,

240
00:11:43.679 --> 00:11:47.480
<v Speaker 2>et cetera from the log message. Oversight uses this method.

241
00:11:47.559 --> 00:11:52.200
<v Speaker 1>Network monitoring too, continuously using the network extension framework.

242
00:11:52.320 --> 00:11:55.279
<v Speaker 2>Right. Network extension is key for host based monitoring because

243
00:11:55.320 --> 00:11:58.240
<v Speaker 2>it tells you which process is making the connection. Using

244
00:11:58.240 --> 00:12:01.960
<v Speaker 2>APIs like endstat manager Create, you get callbacks with network

245
00:12:02.000 --> 00:12:03.480
<v Speaker 2>statistics and connection info.

246
00:12:03.759 --> 00:12:08.320
<v Speaker 1>But the source really emphasizes DNS monitoring as being particularly effective.

247
00:12:08.519 --> 00:12:11.840
<v Speaker 2>It is highly effective and efficient. Why because almost any

248
00:12:11.840 --> 00:12:14.639
<v Speaker 2>malware calling home to a command and control server needs to.

249
00:12:14.639 --> 00:12:16.360
<v Speaker 1>Look up the server's domain name first.

250
00:12:16.559 --> 00:12:20.519
<v Speaker 2>Right, So monitoring DNS requests and responses instantly flags any

251
00:12:20.559 --> 00:12:23.360
<v Speaker 2>new process trying to use the network and reveals where

252
00:12:23.360 --> 00:12:26.200
<v Speaker 2>it's trying to connect, often to suspicious domains like.

253
00:12:26.120 --> 00:12:30.440
<v Speaker 1>The iweb updater example, begonning to iweb services cloud dot com.

254
00:12:30.519 --> 00:12:33.000
<v Speaker 2>Just seeing a request for that known bad domain is

255
00:12:33.039 --> 00:12:35.720
<v Speaker 2>a strong indicator, or the three CX.

256
00:12:35.360 --> 00:12:38.519
<v Speaker 1>Attack that was huge customers notice traffic to MS storage

257
00:12:38.519 --> 00:12:40.000
<v Speaker 1>boxes dot com.

258
00:12:39.600 --> 00:12:43.200
<v Speaker 2>And comparing that domain registered via name cheap with weird

259
00:12:43.440 --> 00:12:49.200
<v Speaker 2>whis to the legit THREECX dot cloud domain. That unusual

260
00:12:49.240 --> 00:12:51.120
<v Speaker 2>network behavior was the critical.

261
00:12:50.840 --> 00:12:54.080
<v Speaker 1>First clue and the DNS monitor tool implents.

262
00:12:53.639 --> 00:12:57.120
<v Speaker 2>This YEP uses network extension to watch DNS traffic cash

263
00:12:57.159 --> 00:13:01.799
<v Speaker 2>it potentially block suspicious requests. Need special entitlements, of course,

264
00:13:01.919 --> 00:13:03.480
<v Speaker 2>since it's system wide monitoring.

265
00:13:03.639 --> 00:13:06.639
<v Speaker 1>Okay, you've mentioned it a few times now endpoint security,

266
00:13:07.120 --> 00:13:09.080
<v Speaker 1>this seems like a really core piece.

267
00:13:09.279 --> 00:13:12.159
<v Speaker 2>It's the modern low level framework from Apple for building

268
00:13:12.200 --> 00:13:16.480
<v Speaker 2>security tools. It lets you monitor and critically control system.

269
00:13:16.120 --> 00:13:19.519
<v Speaker 1>Events, stress starts, file access, network events.

270
00:13:19.080 --> 00:13:21.840
<v Speaker 2>All sorts of things. It requires specific entitlements from Apple

271
00:13:22.159 --> 00:13:25.120
<v Speaker 2>on Apple Dot Developer, Dot, Endpoint, dash Security, dot Client,

272
00:13:25.519 --> 00:13:27.960
<v Speaker 2>and needs proper packaging even for background tools.

273
00:13:27.960 --> 00:13:30.639
<v Speaker 1>The slogger tool is mentioned for exploring the events.

274
00:13:30.639 --> 00:13:33.200
<v Speaker 2>Super useful. Let's you see what's available. It seven type

275
00:13:33.200 --> 00:13:37.159
<v Speaker 2>pin notive xx for process execution, notify, create or unlink

276
00:13:37.200 --> 00:13:38.039
<v Speaker 2>for file events.

277
00:13:38.440 --> 00:13:42.360
<v Speaker 1>Lots more, and you mentioned the key difference notify versus OFUTH.

278
00:13:42.279 --> 00:13:48.240
<v Speaker 2>Events critical distinction notify events notify tell you after something happened,

279
00:13:48.519 --> 00:13:52.879
<v Speaker 2>useful for logging ofth events. AUX, however, intercept the action

280
00:13:53.000 --> 00:13:54.120
<v Speaker 2>before it happens.

281
00:13:53.799 --> 00:13:55.600
<v Speaker 1>Giving the security tool a chance to say.

282
00:13:55.480 --> 00:13:58.440
<v Speaker 2>Yes or no exactly. Your tool receives the authorization request

283
00:13:58.519 --> 00:14:02.519
<v Speaker 2>and can respond with EASE RESULTALLO or ESOS results then

284
00:14:02.559 --> 00:14:04.759
<v Speaker 2>a real preventative power.

285
00:14:04.639 --> 00:14:08.159
<v Speaker 1>And the event data is rich process path, arguments.

286
00:14:07.799 --> 00:14:13.440
<v Speaker 2>Path RGS, essexacarg CPU type, imaging, apotype, full code signing details,

287
00:14:13.440 --> 00:14:15.399
<v Speaker 2>id T, id C to hash.

288
00:14:15.440 --> 00:14:18.039
<v Speaker 1>And on newer mac os you get parent and responsible

289
00:14:18.080 --> 00:14:20.039
<v Speaker 1>process info. Two audit tokens.

290
00:14:20.120 --> 00:14:23.440
<v Speaker 2>Yeah. Audit tokens bundle up the security context, helping you

291
00:14:23.480 --> 00:14:26.559
<v Speaker 2>accurately track process lineage right within the event data.

292
00:14:26.639 --> 00:14:28.919
<v Speaker 1>Hugely valuable, and you can mute noisy events.

293
00:14:28.919 --> 00:14:31.159
<v Speaker 2>You don't need right control the fire hose. Yeah, but

294
00:14:31.240 --> 00:14:33.399
<v Speaker 2>the authodents are where you block things.

295
00:14:33.240 --> 00:14:35.799
<v Speaker 1>Like we discussed blocking a settle tool reset BTM or

296
00:14:35.840 --> 00:14:37.960
<v Speaker 1>SIG stop signals to the BTM agent.

297
00:14:37.840 --> 00:14:40.639
<v Speaker 2>Using EZEPOPEXAC or the appropriate signal off event.

298
00:14:40.679 --> 00:14:44.559
<v Speaker 1>You could also protect specific files or folders like my documents.

299
00:14:44.559 --> 00:14:48.240
<v Speaker 2>Definitely monitor a seven timee puth opin it's fifthempeth in

300
00:14:48.279 --> 00:14:52.200
<v Speaker 2>the link for files and sensitive locations if the process

301
00:14:52.279 --> 00:14:55.159
<v Speaker 2>trying to access or delete them isn't trusted.

302
00:14:54.879 --> 00:14:58.720
<v Speaker 1>Deny it stop malware like Windtail from grabbing or deleting

303
00:14:58.720 --> 00:14:59.240
<v Speaker 1>your stuff.

304
00:14:59.279 --> 00:14:59.759
<v Speaker 2>Percisely.

305
00:15:00.039 --> 00:15:03.519
<v Speaker 1>Block block is the tool example here using endpoint security

306
00:15:03.600 --> 00:15:05.519
<v Speaker 1>for real time persistence detection.

307
00:15:06.000 --> 00:15:09.399
<v Speaker 2>Yes, block block uses endpoint security and some file monitoring

308
00:15:09.960 --> 00:15:13.799
<v Speaker 2>specifically to catch persistence attempts in real time. It alerts

309
00:15:13.840 --> 00:15:17.080
<v Speaker 2>the user immediately and lets them block the action. Uses

310
00:15:17.120 --> 00:15:19.879
<v Speaker 2>a privileged demon for monitoring and a user agent for

311
00:15:19.919 --> 00:15:20.440
<v Speaker 2>the UI.

312
00:15:20.600 --> 00:15:21.960
<v Speaker 1>So it really sounds like you need to put all

313
00:15:21.960 --> 00:15:24.919
<v Speaker 1>these techniques together. It's not just one magic bullet.

314
00:15:24.840 --> 00:15:28.480
<v Speaker 2>Not at all. That's the key takeaway. Sophisticated detection is layered.

315
00:15:28.559 --> 00:15:31.440
<v Speaker 2>A tool might spot suspicious network traffic first.

316
00:15:31.240 --> 00:15:33.600
<v Speaker 1>From the DNS or a network monitor right then.

317
00:15:33.519 --> 00:15:37.600
<v Speaker 2>It pivots, checks the process, arguments the code signing, looks

318
00:15:37.600 --> 00:15:40.279
<v Speaker 2>for persistence attempts. Maybe it does a quick static scan

319
00:15:40.320 --> 00:15:42.440
<v Speaker 2>of the binary. It combines the evidence.

320
00:15:42.440 --> 00:15:46.320
<v Speaker 1>The Dazzle spy case fits that persistence caught by file monitoring.

321
00:15:46.600 --> 00:15:50.360
<v Speaker 1>Maybe endpoint security is notified create for the betlist and.

322
00:15:50.320 --> 00:15:53.960
<v Speaker 2>It's network C and C access caught by network or

323
00:15:54.039 --> 00:15:58.559
<v Speaker 2>DNS monitoring looking for that hard coded IP and three CX.

324
00:15:58.639 --> 00:16:01.200
<v Speaker 1>The initial flag was that we your DNS look up

325
00:16:01.320 --> 00:16:02.639
<v Speaker 1>via network monitor.

326
00:16:02.440 --> 00:16:07.159
<v Speaker 2>Exactly Yeah, mcstorage boxes dot Com. That anomalous behavior was

327
00:16:07.200 --> 00:16:12.120
<v Speaker 2>the trigger later data exfiltration to another domain as MSA

328
00:16:12.159 --> 00:16:15.519
<v Speaker 2>dot Wiki would also be caught by the same network monitor.

329
00:16:15.799 --> 00:16:19.240
<v Speaker 1>So wrapping this up, what's the big picture here? From

330
00:16:19.320 --> 00:16:21.399
<v Speaker 1>this deep dive, I think it's clear.

331
00:16:21.200 --> 00:16:24.399
<v Speaker 2>That detecting modern Mac malware isn't just about keeping lists

332
00:16:24.399 --> 00:16:27.519
<v Speaker 2>of known bad files anymore. It's part of it, but

333
00:16:27.639 --> 00:16:28.440
<v Speaker 2>not the whole game.

334
00:16:28.600 --> 00:16:31.759
<v Speaker 1>It's really about observing and analyzing the behaviors. What are

335
00:16:31.919 --> 00:16:35.320
<v Speaker 1>processes and files actually doing on the system exactly?

336
00:16:35.559 --> 00:16:39.200
<v Speaker 2>Looking for those footprints malware has to leave how it persists,

337
00:16:39.360 --> 00:16:43.120
<v Speaker 2>how it talks on the network, how it uses system resources.

338
00:16:42.679 --> 00:16:46.039
<v Speaker 1>And understanding how security tools can tap into macOS itself.

339
00:16:46.240 --> 00:16:50.159
<v Speaker 1>Using things like endpoint security logging network extensions to watch

340
00:16:50.159 --> 00:16:51.919
<v Speaker 1>for these behaviors programmatically, it.

341
00:16:51.879 --> 00:16:55.480
<v Speaker 2>Gives you much deeper, more resilient security insight. It shows

342
00:16:55.480 --> 00:16:58.519
<v Speaker 2>that even clever threats often leave tracks if you know

343
00:16:58.600 --> 00:16:59.720
<v Speaker 2>where and how to look.

344
00:16:59.559 --> 00:17:02.360
<v Speaker 1>So even sophisticated stuff isn't invisible.

345
00:17:02.080 --> 00:17:05.319
<v Speaker 2>Often not no, which leads to maybe final thoughts that

346
00:17:05.400 --> 00:17:09.119
<v Speaker 2>you on Okay, if detection is increasingly focused on behavior,

347
00:17:09.480 --> 00:17:12.160
<v Speaker 2>on spotting things that look unusual or interact with the

348
00:17:12.160 --> 00:17:16.119
<v Speaker 2>system in sensitive ways, does that mean legitimate, non malicious

349
00:17:16.160 --> 00:17:19.440
<v Speaker 2>software that just happens to be poorly written or maybe

350
00:17:19.480 --> 00:17:22.079
<v Speaker 2>does something unconventional could end up getting flagged by these

351
00:17:22.119 --> 00:17:25.640
<v Speaker 2>same tools. Where does legitimate but weird behavior end and

352
00:17:25.640 --> 00:17:27.200
<v Speaker 2>potentially unwanted behavior begin.