We have a product in our organization that sends false phishing messages to our staff, in order to catch who is susceptible and provide training. We're trying to whitelist this service so that it's allowed through to our staff, but I can't seem to fully do so.
There's a list of IPs and domains to whitelist. I've added the IPs to:
For the domains, I put them in a list, and added that list to the "Bypass spam filters for messages received from addresses or domains within these approved senders lists" section in Apps > Google Workspace > Settings for Gmail > Spam, phishing, and malware > Spam (and also turned on "Bypass spam filters for messages received from internal senders.")
This gets the messages through to the inbox. However, the message goes through with a large gray banner that says "This messages was not sent to Spam based on your organization's settings". How can I get rid of that?
Oh yeah, great technique for better employee relations and team building ... ENTRAPMENT.
This is just plain wrong, no matter the intention of better security.
I disagree. Fake phishes are a very much tried and true method used by information security teams to educate users about the dangers of phishing prior to them being caught by a real phishing attempt. They also have the benefit of reaching people (like extremely senior leadership) who would otherwise be highly resistant to completing trainings. Itโs also great to see the comprehension of how important the information security teamโs work is when a senior leader does get caught by a fake phish.
Just my 2 cents, of course!
Ian
My school district (~8000 teachers and other employees) was just hit with such a "campaign". Many saw it as just another "gotcha".
I would rather see an education campaign first - touting the dangers, showing examples, what to look for, etc. - and then the "exam". Otherwise, you are testing on material that has not been taught, and that just frustrates people.
2 cents,
David
100% agreed! Fake phishing emails definitely need to be a component of a larger educational campaign, not just a standalone thing. I still think theyโre a pretty useful component of that sort of campaign, thoughโsee my previous comments.
Cheers,
Ian
Yeah ours is part of an educational campaign. Soon after we started with ours, the state started their own that I don't have any control over... so I need to figure out the whitelisting for that one as well ๐ Figured if I could figure out ours then the settings would translate to the state's as well.
Given that Google is one of the two largest suppliers of email on the planet, Iโd imagine that whoever created the product that sends the fake phishes would be very likely to have good documentation about what to do in this case. Iโd suggest getting in touch with the vendorโs support team and asking them.
Yeah I've spoken with their support. The initial issue was that I could whitelist the messages enough that they'd come to the users' inboxes, but would have a big red "This email is not safe" message at the top. It was through the vendor's support that I was given the direction to add the phishing IPs to our Inbound Gateway list and turn off SPAM evaluation on messages coming from anything in the Inbound Gateways list, and this seemed to work for the first campaign we sent out a couple months ago. Now when testing out our second campaign I'm getting this gray "This message was not sent to Spam based on your organization's settings" banner instead.
I mean, kudos to Google for being proactive, but we're trying to simulate a zero day situation as part of phishing awareness training. I've spoken with both the vendor support and Google support at this point, and Google support's suggestion was to submit on these forums ยฏ\_(ใ)_/ยฏ I'll contact the vendor again to see if they may have any new guidance as well.
If anyone wants further reading on the effectiveness of phishing your employees, there's a good research paper on it here: https://arxiv.org/pdf/2112.07498.pdf
In this paper, we present findings from a largescale and long-term phishing experiment that we conducted in
collaboration with a partner company. Our experiment ran for 15
months during which time more than 14,000 study participants
(employees of the company) received different simulated phishing
emails in their normal working context. We also deployed a
reporting button to the companyโs email client which allowed
the participants to report suspicious emails they received. We
measured click rates for phishing emails, dangerous actions such
as submitting credentials, and reported suspicious emails.
The results of our experiment provide three types of contributions. First, some of our findings support previous literature
with improved ecological validity. One example of such results is
good effectiveness of warnings on emails. Second, some of our results contradict prior literature and common industry practices.
Surprisingly, we find that embedded training during simulated
phishing exercises, as commonly deployed in the industry today,
does not make employees more resilient to phishing, but instead
it can have unexpected side effects that can make employees
even more susceptible to phishing. And third, we report new
findings. In particular, we are the first to demonstrate that using
the employees as a collective phishing detection mechanism is
practical in large organizations. Our results show that such
crowd-sourcing allows fast detection of new phishing campaigns,
the operational load for the organization is acceptable, and the
employees remain active over long periods of time.
Gmail simply does too good a job of flagging these messages to your users in an effort to prevent them from falling for a real phishing attempt... no matter what steps you try to take, there seems to always be something there to 'tip them off.'
If all of your users are accessing Gmail via the native Gmail (web) interface and/or mobile apps, you're in the best possible spot because they'll receive these warnings (grey/yellow/red banners).
Those who are most vulnerable to phishing and other malicious messages are those who access Gmail via third-party mail clients (using legacy protocols like POP or IMAP)... Apple Mail, Outlook, etc.