Dit lijkt mij een goede test.
Hoe zet je zo'n test in elkaar?
Bedoel de link en zien wie erop klikt?

hoe...
Blind ben je ???

20% is wel erg veel zeg.

Ach voor iemand die niks met IT heeft ziet het er aardig echt uit. Goede test dus.

Er zijn wel frameworks welke kunnen bijhouden wie er op een link klikt.

Zo te zien gophish. Domein registreren, vps met smtp server incl. spf, dmarc, dkim, certificaat van letsencrypt en gaan.

Wat probeerde men met deze test te achterhalen?

Was dat “kunnen processen beter”?
Was dat “zijn we als SOC snel genoeg in het opvolgen”?
Was dat “is onze awareness goed genoeg geweest”?

Of was dit gewoon eindgebruiker testen? (Wat je niet wilt doen!)

Domeinnaam
hogescholrotterdam.nl

Houder
Hogeschool Rotterdam


Niets mis met dat domein dus. Als je het doet, doe het dan goed en zet zo een domein achter een privacy filtered naam.

Met een beetje OS zou het klikken op een link geen probleem moeten zijn. Pas als je wat in gaat vullen...

Zit in Microsoft 365:
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/attack-simulation-training?view=o365-worldwide

Wellicht al deze dingen. Als ze in de voorafgaande periode een awareness training gehad hebben kun je dit ook beschouwen als een test van de effectiviteit van die training .

Ik denk dat zoiets (ook) het geval is , omdat het artikel meldt dat zeshonderd mensen die phish gemeld hebben, en dat dat vijftig procent meer was dan vier jaar geleden.

Dan kan alleen maar als je de boodschap omtrent verdachte emails , en wat een medewerker dan moet doen , in de voorgaande tijd heel uitgebreid gecommuniceerd hebt .

Het aantal 'erin-trappers' is meer beperkt gedaald (25 %naar 20%) , maar het aantal 'goed herkend en goed gereageerd [melding] was dus 50% beter .

In de link van de HR blijkt dat er wel een forse variatie zit 'erin trappen' .


Ze zullen vast gaan kijken waarom hun campagne en training op sommige plaatsen niet aanslaat.

Het lijkt erop dat (al) het openen van de link telt als 'erin getrapt' . Sommige testen zijn wat precieser en onderscheiden 'alleen klikken' en 'klikken en credentials invullen op de form' .
Het lijkt me terecht - een 'drive by exploit' op browsers is beduidend zeldzamer dan gewoon credentials oogsten.

Tenzij ik je reactie helemaal verkeerd begrijp komt het op mij over dat jij erin zou trappen. Zoek de verschillen tussen:
hogescholrotterdam.nl
hogeschoolrotterdam.nl

Hint: volg de eerste link in het artikel en zoek daar naar het woord "doel".

Met een bugvrije browser zou het klikken op een link geen probleem moeten zijn. Pas als je wat in gaat vullen...

Het probleem is, dat deze lieden die link aanklikken. Niet de software is de schuld.

Ik denk dat bijna iedereen tegenwoordig wel het verzoek om zijn energie meterstanden door te geven via een email ontvangt, of een email van een bedrijf waar men iets via internet heeft gekocht, of een email van een instantie met een verzoek om een vragenlijst in te vullen, of men tevreden is over de dienstverlening.

Wat al deze verzoeken gemeen hebben, is dat je dan op een link moet klikken, waarvan je niet weet of dit betrouwbaar is.
Zelfs al je de link controleert naar waar de url toe verwijst blijft het een risico, omdat de url vaak niet eens logisch is, en regelmatig naar een ingehuurd bedrijf verwijst, bijvoorbeeld bij verzoeken om een vragenlijst in te vullen.

Eigenlijk zou elke email afkomstig van een bedrijf of organisatie net als een website door een certificaat moeten worden geauthenticeert.

"moet" niet. Ik had laatst ook weer de mail van de meterstanden en behalve een kant-en-klare link staat daar ook
een getal in (opnamekenmerk) en je kunt zelf naar de website van de leverancier gaan en dat getal invoeren en
je huisnummer en dan kun je ook de standen doorgeven.

Tja vragenlijsten vul ik meestal niet in...

Dat is al zo (DKIM!) maar het probleem is dat er alleen een authenticatie is van de DOMEINNAAM en niet van het BEDRIJF.
En doordat bedrijven zo'n gigantisch puinzooi gemaakt hebben van hun gebruik van domeinnamen, heb je hier in feite weinig aan. Meestal wordt voor ieder doel weer een apart domein gebruikt en hoe moet je nou weten of dit het te verwachten domein voor dat doel is?
Als je dat niet weet, kun je ook niet weten of de betreffende mail inderdaad door dat bedrijf gestuurd is.

Wellicht zou er iets gemaakt moeten worden met behulp van een well-known file op een website per bedrijf (dus op een startpunt waarvan je nog wel kunt aannemen dat dit van het bedrijf is) waar dan alle domeinnamen in staan die dat bedrijf gebruikt.
En dat uiteraard gecombineerd met tooling in mailsoftware en browsers zodat je met een simpele klik kunt checken of "meterstandeneneco.nl" een domein is wat Eneco gebruikt, bijvoorbeeld.
Want nu kan iedere phisher domeinen aanmaken met zo-te-zien-aannemelijke namen en daar de hele certificaat en DKIM kermis rond opbouwen die bevestigen dat dit allemaal 100% in orde is, terwijl het toch fake is.

Meneer wil vertellen dat ie zo slim is om bij een mis-gespelde domein naam de houder/registrant op te zoeken, te constateren dat _die_ wel juist is, en omdat het de juiste entiteit is die het domein geregistreerd heeft het dus eigenlijk geen fout (of vooral : niet zijn fout) was dat ie erop geklikt heeft.

Elke bedrijf kan in principe ook een email certificaat uitgeven, en aan hun email klanten uitgeven, en dat hoeft niet eens veel geld te kosten. Het probleem zijn natuurlijk de webmail aanbieders, zoals Gmail bijvoorbeeld, die hier vermoedelijk niet vrijwillig aan zal meewerken, en dan blijft over, enkele email programma's zoals Microsoft Outlook, waarvoor wel betaalt moet worden, of het gratis Thunderbird programma van Mozilla, waar eenvoudig een authenticatie certificaat in kunnen worden opgenomen.

Het mooiste zou zijn, als een grote internet en dus ook webmail aanbieder zoals Ziggo deze email certificaten in hun servers zouden opnemen. Verplicht dit maar voor deze categorie, en natuurlijk ook voor bedrijven, zoals energieleveranciers etc... die beroepsmatig veel mails naar hun klanten sturen.

Nee, dat is niet het probleem.

Deels wel, want webbrowsers (en e-mailprogramma's) beschermen gebruikers onvoldoende tegen phishing (naast dat het voortdurend barst van de kwetsbaarheden in webbrowsers, maar daar worden vooral targeted users slachtoffer van - waaronder Oeigoeren).

Het onderhavige probleem ontstaat pas als mensen vertrouwelijke gegevens (waaronder wachtwoorden) invoeren op een nepsite.

Dat 20% op een link in een e-mail klikt vind ik weinig. Bijv. op een iPhone, in de het standaard iOS mailprogramma, is het lastig om te zien welke link er onder tekst zoals "KLIK HIER OM ACCOUNT TE VERIFIEREN" zit, d.w.z. zonder meteen een "preview" van de pagina te zien te krijgen. Daarnaast, veel phishing-pagina's worden tegenwoordig onder *.google.com, *.microsoft.com of *.sharepoint.com gehost. Moet je dan ook maar niet op dat soort links klikken? Wat als een server, die echt van een onderwijsinstelling is ([1]), door cybercriminelen van een phishingpagina wordt voorzien? Waarom heeft hogeschoolrotterdam.nl trouwens zo'n belachelijk lange domeinnaam?

[1] https://www.security.nl/posting/710480/Universiteit+Leiden+meldt+datadiefstal+van+%22onvoldoende+beveiligde%22+server

Mijn insteek is dat je mensen moet leren dat, zodra hen gevraagd wordt (login- en/of andere vertrouwelijke-) gegevens in te vullen op een webpagina (of popup daaruit), je als eerste moet checken of de domeinnaam van de bedoelde organisatie is [*] en voor het kennelijke doel bestemd is (zoals webmail.hogeschoolrotterdam.nl), en dat je vervolgens moet vaststellen dat er sprake is van een foutloze https-verbinding (een slotje op de juiste plaats betekent dat de server is geauthenticeerd: de brouwser heeft dan gecheckt dat er daadwerkelijk een verbinding is met de server met de in de URL-balk getoonde domeinnaam, en de browser heeft dan een verbinding met die server opgezet die versleuteld is en beveiligd is tegen modificatie).

[*] Het is m.i. noodzakelijk dat elke internetter weet dat de domeinnaam vpn.example.com van dezelfde organisatie is als example.com, www.example.com en werkenbij.example.com - maar dat werkenbijexample.com dat mogelijk niet is (in elk geval kun je dat niet afleiden uit de domeinnaam).

M.a.w. jouw browser weet niet dat als deze verbinding heeft met https://hogescholrotterdam.nl/, dat dit niet een server van hogeschoolrotterdam.nl is (sterker, dat is die server wel, zoals iemand hierboven terecht opmerkt) en dus dat je daar niet met inloggegevens van hogeschoolrotterdam.nl op moet proberen in te loggen. Je zult dus zelf op de een of andere manier moeten vaststellen dat de domeinnaam van de bedoelde organisatie is, en als je in moet loggen, dat je exact de domeinnaam van de gebruikelijke logonserver in de URL-balk ziet. Belangrijk: negeer wat je ziet in webpagina's bij het "herkennen" van een website; alles wat je ziet op een nepsite kan eenvoudig gekopieerd zijn van de echte site. En denk ook niet dat 2FA/MFA je tegen phishing beschermt; dat is in veel situaties domweg niet het geval!

Nb. Met de beschreven phishingaanval zouden gebruikers kunnen denken dat ze vooral op spelfouten (in mails, domeinnamen en/of webpagina's moeten letten, wat natuurlijk onzin is - denk aan accountdeblokkerenbijhogeschoolrotterdam.nl).

Het risico is toch echt de software en niet het klikken op de link. Daarom is de test ook fout uitgevoerd. De test wordt al afgebroken na het klikken op de link. De echte test zou dan pas moeten beginnen: "Hoeveel mensen vullen ook daadwerkelijk iets in?"

Ala je als bedrijf vind dat het klikken al gevaarlijk is, dan maakt het niet uit of er 1006 (zoals hier) of slechts één persoon op die link klikt. Binnen een bedrijf zullen overal computers staan met vergelijkbare versies van dezelfde software. Als je bang bent voor zero days of slecht update beleid, dan had je bij de vorige test al moeten ingrijpen. Het is nml niet reëel om aan te nemen dat geen enkele medewerker op zo'n link klikt.

Je zult je netwerk zo moeten inrichten dat alleen het klikken geen kwaad kan. Desnoods haal je software in huis dat alle links uit binnenkomende mail al op serverniveau verwijderd. (behalve eventueel gewhiteliste links.) Zelf gebruiken we het MailScanner pakket. Die kan ook specifieke HTML code uit mailtjes verwijderen en verdachte links zeer opvallend markeren. Links selectief verwijderen niet, zover ik kan zien. De opmaak blijft bij dit soort aanpassingen behouden wat toch aangenamer is dan het volledig strippen van alle html code uit mail.

En daar gaan we weer. De zoveelste phishing test, het zoveelste percentage klikkers en veevolgens security.nl waarop uitsluitend naar techniek wordt gekeken. Wanneer gaan we snappen dat awareness geen IT ding is en de oplosaing ervoor ook niet voor het overgrote deel in IT zit.

Net zoals dat een groenteboer geen brood maakt en een automonteur geen wonden hecht is de gemiddelde IT'er en information security officer niet geequipeerd om houding en gedrag te beïnvloeden.

Wanneer beginnen we nu eens met het inhuren van gedragspsychologen om houding en gedrag te beinvloeden en laten we die samen metde eerdergenoemde mewr technische mensen kijken naar dit vraagstuk?

Je doet de aanname dat de awareness trainingen en communicatie erover gedaan worden door security nerds .
Hoe zeker ben je ervan dat die aanname juist is ?

Degenen die ik gezien heb of heb moeten doen kwamen van 'extern' (trainingsburo) - niet van de IT Security office , en hadden nogal een communicatie-gevoel . Misschien met review input van de sme's .

Ook vergelijkbare overheids/sector campages ('3x kloppen' e.d. ) komen niet over als zelfbouw van meneer SANS CISSP CEH
.
Ik denk dat wat er over het algemeen gedaan wordt aan training/awareness nu al afkomstig is van de plek waar je expertise omtrent training/communicatie/gedragsbeinvloeding verwacht .

Zoals in de afbeelding te zien bevat de url een parameter: ?rid=jqgvofg

Die parameter is voor iedere geadresseerde uniek, dus door te bekijken met welke parameters er allemaal requests binnengekomen zijn bij je server weet je wie er allemaal op de link geklikt hebben.

Die 20% komt overeen met wat we in mijn organisatie gezien hebben, daar klikte 21% op de phishing simulatie link.

14%, dus 2/3e van de klikkers, hadden ook werkelijk inloggegevens ingevuld op de achterliggende pagina.