1
00:00:00,000 --> 00:00:06,480
Today on our Tech for Business podcast, we're joined by Nate, our Director of Cybersecurity,

2
00:00:06,480 --> 00:00:10,680
and Andrew, our Security Incident Response Team Lead.

3
00:00:10,680 --> 00:00:15,520
October is Cybersecurity Awareness Month, and we'll recap incident scenarios and

4
00:00:15,520 --> 00:00:18,760
proactive measures you can take to prevent them.

5
00:00:18,760 --> 00:00:21,800
This week, we're talking about close calls.

6
00:00:21,800 --> 00:00:25,600
All personal information has been changed to protect confidentiality.

7
00:00:25,600 --> 00:00:31,920
Yeah, so I guess today one of the things that we could maybe just start off talking about

8
00:00:31,920 --> 00:00:36,680
is just some of the close calls that we've seen when it comes to security incidents.

9
00:00:36,680 --> 00:00:41,840
Number one, we'll never say breaches or hacked unless there is an actual compromise breach

10
00:00:41,840 --> 00:00:42,840
or hack.

11
00:00:42,840 --> 00:00:47,720
So through this, one of my first takeaways is please always say security incidents for

12
00:00:47,720 --> 00:00:52,680
whenever you're communicating this type of stuff within your organization because there

13
00:00:52,680 --> 00:00:55,880
may be legal ramifications to that.

14
00:00:55,880 --> 00:00:58,280
But that being said, close calls.

15
00:00:58,280 --> 00:01:06,760
There's a lot of different situations where we see organizations have some type of potential

16
00:01:06,760 --> 00:01:11,880
failure in some of the controls that they put in place to prevent a security incident,

17
00:01:11,880 --> 00:01:17,960
but then also there's maybe a second step that comes into play where it was successful.

18
00:01:17,960 --> 00:01:23,800
And so one of the core concepts of this is defense in depth or security in layers is

19
00:01:23,800 --> 00:01:29,400
there's a reason why you have multiple layers is so that when one potentially fails, you

20
00:01:29,400 --> 00:01:35,560
can maybe catch the threat at a second stage before it becomes a bigger incident.

21
00:01:35,560 --> 00:01:43,600
So while we're going through this, Andrew and I do have some notes here just because

22
00:01:43,600 --> 00:01:45,760
we tend to communicate with customer names.

23
00:01:45,760 --> 00:01:49,160
Obviously, we're not going to do that for the privacy of these organizations.

24
00:01:49,160 --> 00:01:55,120
So we're going to start calling out org one or two or three as we go through this.

25
00:01:55,120 --> 00:02:04,880
But so in org one's situation here, we saw an incident where they did have endpoint detection

26
00:02:04,880 --> 00:02:07,440
response or EDR deployed in their environment.

27
00:02:07,440 --> 00:02:12,960
If you're not familiar with what EDR is, we have podcasts about that, tons of resources,

28
00:02:12,960 --> 00:02:14,480
everything like that.

29
00:02:14,480 --> 00:02:17,320
But they had EDR in place.

30
00:02:17,320 --> 00:02:23,680
And what we saw was one of their users downloaded some type of malicious software on that system.

31
00:02:23,680 --> 00:02:29,920
And what happened at that point was we saw attempts to download additional malicious

32
00:02:29,920 --> 00:02:31,480
software.

33
00:02:31,480 --> 00:02:37,960
And so the software was used to try and download the passwords out of that user's browser.

34
00:02:37,960 --> 00:02:42,800
So then if they are potentially reusing passwords across multiple sites, they could then go log

35
00:02:42,800 --> 00:02:43,800
into there.

36
00:02:43,800 --> 00:02:47,280
So the EDR solution pulled that piece of software out.

37
00:02:47,280 --> 00:02:54,840
They also ripped out software that was designed to dump admin password hashes, which is an

38
00:02:54,840 --> 00:03:00,160
encrypted version of your password on that system, and then use that to log into the

39
00:03:00,160 --> 00:03:02,040
servers.

40
00:03:02,040 --> 00:03:07,680
And in that environment, all of their users had local admin on their system.

41
00:03:07,680 --> 00:03:13,320
So that was an extremely close call to a potential ransomware incident and privileged

42
00:03:13,320 --> 00:03:16,280
escalation.

43
00:03:16,280 --> 00:03:20,080
I believe there was a couple other pieces of software that was associated with it to

44
00:03:20,080 --> 00:03:23,840
try and actually remove the EDR's agent.

45
00:03:23,840 --> 00:03:28,040
And so that was really interesting, seeing that whoever the threat actor was on that

46
00:03:28,040 --> 00:03:33,800
system was actively trying to remove the EDR because it kept removing their software.

47
00:03:33,800 --> 00:03:38,000
And then I think one of the most interesting things was they actually sent an uninstall

48
00:03:38,000 --> 00:03:44,760
request to CIT to try and have us approve the removal of it.

49
00:03:44,760 --> 00:03:45,880
And obviously that was shut down.

50
00:03:45,880 --> 00:03:52,600
And then we completely isolated that device off the network and had them completely re-imaged.

51
00:03:52,600 --> 00:03:57,320
But that's probably one of my favorite close call stories.

52
00:03:57,320 --> 00:04:00,280
It's definitely top there for me as well.

53
00:04:00,280 --> 00:04:05,760
It was funny to see the attacker putting on EDR uninstall applications and seeing those

54
00:04:05,760 --> 00:04:06,960
get ripped out.

55
00:04:06,960 --> 00:04:13,400
So I got a kick out of that looking at the logs after the fact.

56
00:04:13,400 --> 00:04:20,280
Another organization where we had another close call, this second organization, a user

57
00:04:20,280 --> 00:04:25,760
had been receiving many multiple MFA requests.

58
00:04:25,760 --> 00:04:29,520
Got to the point where it annoyed the person enough that they then called the help desk

59
00:04:29,520 --> 00:04:34,920
and we found out that because of MFA, the attacker couldn't get it.

60
00:04:34,920 --> 00:04:38,960
They knew the username, they knew the password, but they kept sending MFA calls and texts

61
00:04:38,960 --> 00:04:44,680
and push notifications and tell it annoyed the person enough to ask why this is happening.

62
00:04:44,680 --> 00:04:46,320
And so that created that alert there.

63
00:04:46,320 --> 00:04:52,600
So one accidental yes, this is me signing in, the attacker would have had access to do

64
00:04:52,600 --> 00:04:55,560
whatever they wanted to do.

65
00:04:55,560 --> 00:05:04,560
So yeah, in that case, the multi-factor was successful, but the user initially failed

66
00:05:04,560 --> 00:05:09,880
by giving up their password in a previous incident or maybe a user password somewhere

67
00:05:09,880 --> 00:05:10,880
along the lines.

68
00:05:10,880 --> 00:05:12,280
It was a compromised password.

69
00:05:12,280 --> 00:05:15,880
The multi-factor helped protect that, but then to give user credit, even though they

70
00:05:15,880 --> 00:05:21,880
failed before, they were also the ones that helped bring light of the situation back to

71
00:05:21,880 --> 00:05:30,680
the IT once they were able to basically rectify the issue in the first place.

72
00:05:30,680 --> 00:05:34,480
And then this is another really interesting one that comes to mind was again, a kind of

73
00:05:34,480 --> 00:05:39,160
third organization here, they had a compromised account.

74
00:05:39,160 --> 00:05:48,800
So it was one of their finance employees that had accidentally fell for a phishing email.

75
00:05:48,800 --> 00:05:53,080
The threat actor was actually sitting in the mailbox because again, they did not have multi-factor

76
00:05:53,080 --> 00:05:54,320
in place.

77
00:05:54,320 --> 00:05:59,000
And so in these cases, the threat actor would sit in the mailbox for any given period of

78
00:05:59,000 --> 00:06:00,000
time.

79
00:06:00,000 --> 00:06:05,600
It might be a day, it could be weeks, we've seen them sit there just for months, monitoring

80
00:06:05,600 --> 00:06:10,000
a mailbox, just laying low, looking at all the emails that are coming through and waiting

81
00:06:10,000 --> 00:06:12,320
for the perfect opportunity.

82
00:06:12,320 --> 00:06:17,280
And so in this case, they went and noticed that a wire transfer hadn't been completed

83
00:06:17,280 --> 00:06:18,560
in quite some time.

84
00:06:18,560 --> 00:06:27,040
And so they reached out and said, sorry, they spun up a domain similar to the customer

85
00:06:27,040 --> 00:06:33,520
and then sent a fraudulent email to them saying, we'd like to pay this or receive these funds

86
00:06:33,520 --> 00:06:34,720
or whatever it was.

87
00:06:34,720 --> 00:06:41,920
Can you please process it to this bank account because that's changed.

88
00:06:41,920 --> 00:06:47,000
The finance individual reached out to their internal IT and said, I'm actually concerned.

89
00:06:47,000 --> 00:06:50,520
I think there's maybe something going on in my mailbox.

90
00:06:50,520 --> 00:06:58,240
And unfortunately, that IT employee completely disregarded that concern and closed out the

91
00:06:58,240 --> 00:07:00,600
ticket in their environment.

92
00:07:00,600 --> 00:07:06,640
And then once they saw that there was a true wire transfer request, they called that company

93
00:07:06,640 --> 00:07:07,640
said, is this legitimate?

94
00:07:07,640 --> 00:07:09,560
And they said, no.

95
00:07:09,560 --> 00:07:14,040
Then they reached out to their IT director who then reached out to CIT for additional

96
00:07:14,040 --> 00:07:15,960
investigation on that.

97
00:07:15,960 --> 00:07:20,920
But again, it was because they had did not have a multi-factor.

98
00:07:20,920 --> 00:07:21,920
So that failed.

99
00:07:21,920 --> 00:07:26,760
The employee, again, they gave up their password and everything like that.

100
00:07:26,760 --> 00:07:28,880
Attacker sat in the mailbox for a long given period of time.

101
00:07:28,880 --> 00:07:33,800
So there was no detection on that mailbox looking for anomalous logins or anything like

102
00:07:33,800 --> 00:07:34,800
that.

103
00:07:34,800 --> 00:07:37,040
So multiple failures along the way.

104
00:07:37,040 --> 00:07:42,440
And then again, the concerns to the IT that was disregarded, that was another failure.

105
00:07:42,440 --> 00:07:48,200
However, because that finance person had the proper procedures in place to validate that

106
00:07:48,200 --> 00:07:56,200
wire transfer, that was a success that made that go from a successful fraudulent wire

107
00:07:56,200 --> 00:07:59,680
transfer to our close call category.

108
00:07:59,680 --> 00:08:00,680
So really interesting.

109
00:08:00,680 --> 00:08:01,680
Wow.

110
00:08:01,680 --> 00:08:02,680
I'm hearing.

111
00:08:02,680 --> 00:08:09,400
So we talked a lot about close calls and I'm hearing a lot of things like MFA and EDR

112
00:08:09,400 --> 00:08:10,920
and this human element.

113
00:08:10,920 --> 00:08:19,400
And as we sort of look at all of these, what is something, what are these key takeaways?

114
00:08:19,400 --> 00:08:23,320
What are the things that customers, and you've covered it a little bit, but what are the

115
00:08:23,320 --> 00:08:27,040
things that the customers and businesses are supposed to be doing so that hopefully this

116
00:08:27,040 --> 00:08:28,040
never happens?

117
00:08:28,040 --> 00:08:35,120
And if it does, they're in this close call category, non-successful.

118
00:08:35,120 --> 00:08:39,520
The one thing I want to add about Nate talking about that earlier with is the defense in

119
00:08:39,520 --> 00:08:40,680
depth.

120
00:08:40,680 --> 00:08:43,840
I like to call it the security onion.

121
00:08:43,840 --> 00:08:49,880
Obers have layers, security has layers, quote from Shrek, I guess.

122
00:08:49,880 --> 00:08:51,760
It's not just one size fits all.

123
00:08:51,760 --> 00:08:52,760
One thing is perfect.

124
00:08:52,760 --> 00:08:54,560
It's going to protect you 100% of the time.

125
00:08:54,560 --> 00:08:56,200
You need to have EDR.

126
00:08:56,200 --> 00:08:57,440
You need to have MFA.

127
00:08:57,440 --> 00:09:03,280
You need to have other solutions in place that are going to layer your defenses because

128
00:09:03,280 --> 00:09:05,560
things fail, users fail.

129
00:09:05,560 --> 00:09:09,880
Users are the last point of defense there.

130
00:09:09,880 --> 00:09:15,160
Using your users, MFA, EDR, those types of things are very important and you can't just

131
00:09:15,160 --> 00:09:17,160
have one single solution.

132
00:09:17,160 --> 00:09:18,160
Ditto.

133
00:09:18,160 --> 00:09:19,160
I agree.

134
00:09:19,160 --> 00:09:28,360
I guess the biggest thing that I have is if you go take a look at the statistics that

135
00:09:28,360 --> 00:09:34,880
get pushed out every single year, the human element accounts for about 90% of all of these

136
00:09:34,880 --> 00:09:35,880
compromises.

137
00:09:35,880 --> 00:09:44,960
As we continue to go through different situations during our cybersecurity month here, continue

138
00:09:44,960 --> 00:09:50,440
to think that there is some type of human element associated with these in most of these

139
00:09:50,440 --> 00:09:56,200
cases.

140
00:09:56,200 --> 00:10:02,320
Sometimes again, the employee has acts like giving up a credential or accepted some type

141
00:10:02,320 --> 00:10:07,960
of multi-factor push even though the tool is in place and they failed that.

142
00:10:07,960 --> 00:10:14,160
Like I had mentioned in that last one, sometimes the human element can also be that last line

143
00:10:14,160 --> 00:10:19,480
of defense like Andrew said, of when the tools and the people failed along the way

144
00:10:19,480 --> 00:10:23,520
or maybe you didn't have a tool in place and everything failed up to that point, they can

145
00:10:23,520 --> 00:10:28,040
be that last line of defense to keep you from having a major security incident because

146
00:10:28,040 --> 00:10:36,960
they are the ones that can at least notify you if a tool didn't notify you already.

147
00:10:36,960 --> 00:10:42,400
So to wrap up today, I'm going to kind of open it up for anything else you'd like to

148
00:10:42,400 --> 00:10:46,880
share and then I'm actually going to ask a little bit of a personal question with all

149
00:10:46,880 --> 00:10:51,520
of these crazy incident scenarios we're going to talk about this month.

150
00:10:51,520 --> 00:10:56,840
Why are you both in this field of work?

151
00:10:56,840 --> 00:11:01,640
Why do you enjoy this type of work?

152
00:11:01,640 --> 00:11:03,800
I'll let you go first, Nate.

153
00:11:03,800 --> 00:11:07,560
I was wondering if you were going to go.

154
00:11:07,560 --> 00:11:13,280
For me personally and something that I've seen at least across our team is that people

155
00:11:13,280 --> 00:11:20,680
who work in the cybersecurity industry tend to have a desire to be a protector.

156
00:11:20,680 --> 00:11:28,160
So think of maybe you're in the armed forces or some type of police officer or something

157
00:11:28,160 --> 00:11:29,160
like that.

158
00:11:29,160 --> 00:11:32,280
You tend to want to help and protect for the most part.

159
00:11:32,280 --> 00:11:38,320
Same thing applies to here is we like to be kind of the guardians of helping reduce risk

160
00:11:38,320 --> 00:11:39,320
to organizations.

161
00:11:39,320 --> 00:11:43,200
We just happen to be really good at technology as well.

162
00:11:43,200 --> 00:11:50,400
And so taking that is we don't want to be the people that are disrupting a business

163
00:11:50,400 --> 00:11:54,520
or trying to impact it too much and say shut everything off.

164
00:11:54,520 --> 00:11:55,520
That's the most secure.

165
00:11:55,520 --> 00:12:00,840
We're trying to keep you moving forward, but there's a passion to keep you protected along

166
00:12:00,840 --> 00:12:06,720
the way and saying yes, you can do that, but let's take additional considerations along

167
00:12:06,720 --> 00:12:08,120
the way.

168
00:12:08,120 --> 00:12:13,560
And then likewise, I think there's also just the human element is having empathy for those

169
00:12:13,560 --> 00:12:19,360
that are going through a very, very stressful situation.

170
00:12:19,360 --> 00:12:24,120
In some of these cases, especially when we get into the true deep ransomware discussions

171
00:12:24,120 --> 00:12:28,520
and everything like that, we've had people crying on the phone with us.

172
00:12:28,520 --> 00:12:32,880
Wire transfers crying on the phone saying, I think I might need to shut down my business.

173
00:12:32,880 --> 00:12:37,920
That's their lifelong work and being able to say you don't need to do that because we'll

174
00:12:37,920 --> 00:12:39,520
get you through it, right?

175
00:12:39,520 --> 00:12:42,840
And being able to successfully keep their businesses afloat.

176
00:12:42,840 --> 00:12:44,840
That is super rewarding.

177
00:12:44,840 --> 00:12:53,160
As far as the reason that I enjoy my job is I'm very interested in how things work, along

178
00:12:53,160 --> 00:12:55,760
with what Nate said, of course, because Nate said the very, very...

179
00:12:55,760 --> 00:13:00,920
I'm a sentimental one, I guess.

180
00:13:00,920 --> 00:13:07,000
I really like to see how things work and how to protect that.

181
00:13:07,000 --> 00:13:12,640
As Nate had mentioned, it's kind of a protective mentality.

182
00:13:12,640 --> 00:13:17,240
It's crazy what people can do without a moral compass.

183
00:13:17,240 --> 00:13:24,080
If some of these attackers just had that moral compass, they would be amazing security professionals.

184
00:13:24,080 --> 00:13:29,760
But because they're incentivized by money or other malicious behaviors, they don't do

185
00:13:29,760 --> 00:13:31,760
it for the right reason.

186
00:13:31,760 --> 00:13:34,800
Thanks to Nate and Andrew for joining us this week.

187
00:13:34,800 --> 00:13:38,200
If you enjoyed this podcast, please like and subscribe.

188
00:13:38,200 --> 00:13:43,080
If you have a question or topic you'd like us to discuss, reach out to us at info at

189
00:13:43,080 --> 00:13:49,200
cIT-net.com or head out to our website, cIT-net.com slash podcast.

190
00:13:49,200 --> 00:14:11,480
And we'll be back next week with more incident scenarios.