Phishingcampagne gebruikt naam van Webshop Bloemtuin

Illustratie bij dit bericht.
Criminelen versturen phishingmails die afkomstig lijken van Webshop Bloemtuin. De ontvangers worden naar een nagemaakte inlogpagina geleid.
De organisatie benadrukt nooit per mail om inloggegevens te vragen en roept op verdachte berichten te melden.
Reactie
De mails zijn opvallend goed verzorgd: geen taalfouten en een afzenderadres dat sterk lijkt op het echte domein.
De nagemaakte pagina vraagt naast het wachtwoord ook om een eenmalige code, die direct wordt doorgespeeld aan de echte omgeving.
De kwaliteit van deze mails gaat hard vooruit. Taalfouten kun je niet meer als signaal gebruiken.
Alleen phishingbestendige MFA helpt hier nog tegen.
Mooi dat er een patch is, maar wat doe je met apparatuur die end-of-life is? Die staat er over vijf jaar nog.
Backups. Getest. Offline. Blijft het saaiste maar beste advies dat er is.
Dat valt in de praktijk tegen. In een kleine omgeving lukt dat prima, met duizend werkplekken wordt het een ander verhaal.
Het is te makkelijk om de beheerder de schuld te geven. Als je geen budget en geen tijd krijgt, gebeurt het gewoon niet.
Zit hier al een uur naar te kijken. De kern is een ontbrekende inputvalidatie, de rest is ruis.
Ik zou toch echt eerst willen weten of er data is weggesluisd voordat ik zeg dat het meevalt.
Wij hebben dit vanochtend gepatcht, downtime was ongeveer tien minuten. Prima te doen als je het voorbereidt.
Dat valt in de praktijk tegen. Dat is precies wat de leverancier vorig jaar ook beloofde, en kijk waar we nu staan.
Ik hou mijn hart vast voor al die kleine bedrijven zonder ict-afdeling. Die lezen dit soort berichten nooit.
Zolang leveranciers geen SBOM meeleveren blijft dit dweilen met de kraan open. Je weet gewoon niet wat er in dat ding zit.
Grappig hoe zo'n woordvoerder altijd spreekt van 'een beperkt aantal klanten'. Dat blijkt achteraf structureel anders.
Weer een update die je binnen 24 uur uitgerold moet hebben. Bij ons draait de patchcyclus op maandag, dus dat wordt handmatig ingrijpen.
Niet helemaal. Formeel klopt het, praktisch schiet je er weinig mee op.
Het echte risico zit in de koppelingen. Systeem A is misschien veilig, maar de API-token in systeem B niet.
De gemiddelde gebruiker merkt hier niets van, tot het misgaat. Bewustwording blijft het lastigste stuk.
Voor de thuisgebruiker: controleer even je router. Die dingen krijgen zelden vanzelf een update.
Dank voor het artikel. Kort, concreet en met bronvermelding, precies wat je wil lezen op een vrijdagmiddag.
Iedereen roept zero trust, maar in de praktijk hangt er nog een plat netwerk achter de firewall.
90 dagen bewaartermijn voor logs is echt het minimum. Bij een gemiddelde inbraak zit je daar zo overheen.
Ik snap nooit waarom dit soort beheerinterfaces standaard aan het internet hangt. Dat is toch vragen om problemen?
Er is een verschil tussen 'geen bewijs van misbruik' en 'geen misbruik'. Dat wordt structureel door elkaar gehaald.
Vraag me af of de AVG hier ook een rol speelt. Er zijn duidelijk persoonsgegevens mee gemoeid.
Wat mij vooral opvalt: geen woord over hoe lang de aanvallers binnen zaten. Dat zegt meestal genoeg.
Precies dat. Alert fatigue is een onderschat beveiligingsrisico op zichzelf.
Mooi voorbeeld waarom open source niet automatisch veiliger is, maar wel controleerbaarder.
@hierboven: de leverancier noemt een configuratie-optie als tijdelijke mitigatie, maar dat kost je wel functionaliteit.
Dank, dat verklaart wel het een en ander. Dat is precies wat de leverancier vorig jaar ook beloofde, en kijk waar we nu staan.
Nog steeds geen verplichte meldplicht met sancties voor dit soort trage patches. Zonder pijn verandert er niets.
Goed punt, maar Dat geldt voor de zakelijke variant, thuisgebruikers hebben die knop helemaal niet.