Feeding the Attack Simulator

Iron Contributor

Previous commentators have noted the simulator's tendency to send attacks in a single wave. This can lead to a comment from one recipient warning another. Additionally, the wave may overwhelm local IT support.

 

To my mind it makes sense to split a large recipient base up into slices to be attacked at different times and possibly with minor variations in the payload. I had been looking at dynamic groups to do this.

 

Am I correct in saying no type of dynamic group is acceptable to the attack simulator? I have tried the new Microsoft 365 groups, but with the group features suppressed to prevent the group itself from mailing, the simulator will not mail the membership either.

 

set-UnifiedGroup -Identity $Group.Name -HiddenFromExchangeClientsEnabled
set-UnifiedGroup -Identity $Group.Name -UnifiedGroupWelcomeMessageEnabled:$false
set-UnifiedGroup -Identity $Group.Name -SubscriptionEnabled:$false
set-UnifiedGroup -Identity $Group.Name -AlwaysSubscribeMembersToCalendarEvents:$false
set-UnifiedGroup -Identity $Group.Name -AutoSubscribeNewMembers:$false

 

5 Replies
Vasil, that was exactly what I was looking for. I gave it a try and the Randomize Send Times feature did not work - everything arrived at the same time. I was using a single attack to a group of eight recipients over a short period of four days, which may have caused the random algorithm a problem. Does anyone know if there is documentation for the new feature beyond the June announcement, or am I better off speaking to Product Support?
Opening a support case wouldn't hurt.
I'd argue that opening a support case would hurt the sanity of anyone doing so.

I have yet to have a single Phishing Attack Simulator ticket NOT take weeks or months to resolve, and most result in outright changes to the entire product due to the abysmal QC Microsoft has shown with their O365 product suite in the past few years, and the attack simulator top among that.

There was a stretch of a month that it outright wouldn't load reports correctly on any browser including the newly GA Edge, and it took around 3 months for them to allow us to delete simulations that we ran as internal trial run/tests (hiding didn't remove them from the report metrics) - and 8 months later I'm still seeing metrics reporting deleted run clicks/trainings and trainings that are spamming users months later.

Support meanwhile likes to respond with a few days of gathering data you provided them in the initial email/ticket but have to explain 2-3 times in different ways, and then radio silence as they 'escalate' the issue to someone that doesn't communicate any form of helpful or even informational updates outside of 'we're working on this' or some shade of that.

I should make a post about this, come to think on it.
I agree with @JR_Tayschrenn 3 months in and still to see results... Product design is very cluncky and some "features" don't make sense. We have issues with payload harvesting and according to them in order for a payload to be harvested the following needs to happen:
1. Email needs to be delivered to inbox (i.e not marked as spam)
2. A user needs to report it
3. Harvesting runs every 7 days

I queried why for example a campaign email does not get harvested if that is setup and the answer was: if the email is already identified by our systems as spam, we do not see the benefit of harvesting it as the next one will be stopped. I queried then, once an email is reported should AI not stop any further variations of it therefore getting back to the same argument... They try to over engineer basic things with bad non-sense results.