Hoe voorkom je aanvallen met uitvoering van externe code (RCE) in WordPress: 9 tips

Van de vele bedreigingen waarmee website-eigenaren te maken krijgen, behoren aanvallen met externe code-uitvoering (RCE) in WordPress tot de gevaarlijkste.

Een succesvolle RCE-aanval geeft een aanvaller de mogelijkheid om willekeurige kwaadaardige code rechtstreeks op uw server uit te voeren, en tegen de tijd dat u merkt dat er iets mis is, is de schade al aangericht.

Deze handleiding legt uit wat RCE is, hoe aanvallers het uitvoeren en op welke waarschuwingssignalen je moet letten. We bespreken ook de praktische stappen die je direct kunt nemen om je WordPress-site te beschermen.

Kort samengevat: Voorkom aanvallen met externe code-uitvoering (RCE) in WordPress

• RCE is een van de gevaarlijkste WordPress-kwetsbaarheden , omdat het aanvallers in staat stelt om kwaadaardige code rechtstreeks op uw server uit te voeren.

• De meeste RCE-aanvallen vinden plaats via verouderde plug-ins, kwetsbare thema's of slecht beveiligde bestandsuploads.

• Aanvallers kunnen RCE-toegang gebruiken om malware te installeren, gegevens te stelen, verborgen beheerdersaccounts aan te maken of de volledige controle over uw server over te nemen.

• Veelvoorkomende waarschuwingssignalen zijn onder andere onverwachte beheerders, verdachte PHP-bestanden, ongebruikelijke serveractiviteit en beveiligingswaarschuwingen van plug-ins.

• Het voorkomen van RCE vereist gelaagde beveiliging, zoals regelmatige updates, veilige validatie van bestandsuploads, serverbeveiliging en het beperken van onnodige plug-ins.

• Hulpmiddelen zoals webapplicatiefirewalls, tweefactorauthenticatie en continue malware-scans verminderen het risico op misbruik aanzienlijk.

• Als u een RCE-aanval vermoedt, onderneem dan onmiddellijk actie. Scan op malware, wijzig uw inloggegevens, controleer de logboeken en herstel indien nodig een schone back-up.

Wat is een Remote Code Execution Attack in WordPress?

Remote code execution is een type beveiligingslek waarmee een aanvaller naar eigen keuze code op uw webserver kan uitvoeren zonder fysieke of directe toegang.

Dit gebeurt op afstand door gebruik te maken van zwakke punten in uw WordPress-installatie, plug-ins of thema's.

Zie het zo: je server is je huis. Normaal gesproken heb jij als enige de sleutels. Een RCE-kwetsbaarheid is als een verborgen achterdeur die een aanvaller heeft ontdekt voordat jij dat deed. Ze kunnen binnenlopen, rondkijken, pakken wat ze willen en weer vertrekken zonder dat jij er ooit iets van merkt.

In tegenstelling tot een defacement-aanval of een brute-force-aanval, die zichtbaar zijn, verlopen RCE-aanvallen vaak volledig geruisloos. De aanvaller probeert uw site niet plat te leggen. Ze willen permanente, ongemerkte toegang tot uw omgeving.

Dit is wat een succesvolle RCE-aanval een aanvaller doorgaans in staat stelt te doen:

• Het stelen van gevoelige gegevens, waaronder klantgegevens, betalingsinformatie en inloggegevens

• Installeer malware of ransomware rechtstreeks op uw server

• Maak frauduleuze beheerdersaccounts aan om langdurige toegang te behouden

• Gebruik je server niet om spam te versturen of deel te nemen aan botnetactiviteiten

• Uw site en database volledig wissen of beschadigen

RCE wordt, afhankelijk van de context, ook wel code-injectie, remote command execution of arbitrary code execution genoemd. Maar ze beschrijven allemaal dezelfde fundamentele dreiging.

Hoe voeren hackers RCE-aanvallen uit op WordPress-sites?

Het is cruciaal om de aanvalsvectoren te begrijpen, want je kunt je niet verdedigen tegen iets wat je niet begrijpt.

Aanvallers gebruiken verschillende, goed gedocumenteerde toegangspunten om op afstand code uit te voeren op WordPress-sites. Laten we de meest voorkomende eens nader bekijken.

Misbruik maken van verouderde plugins en thema's

Dit is verreweg de meest voorkomende manier waarop RCE-aanvallen worden uitgevoerd. Wanneer een beveiligingsonderzoeker een kwetsbaarheid ontdekt in een veelgebruikte plugin, meldt hij of zij dit doorgaans eerst privé aan de ontwikkelaar.

Maar zodra er een patch wordt uitgebracht en de kwetsbaarheid publiekelijk bekend wordt, beginnen aanvallers onmiddellijk miljoenen sites te scannen op installaties die nog steeds de ongepatchte versie draaien.

Een praktijkvoorbeeld: in februari 2024 werd in het Bricks Builder-thema, dat meer dan 25.000 actieve installaties heeft, een RCE-kwetsbaarheid ontdekt die niet geverifieerd kon worden en die geregistreerd staat als CVE-2024-25600.

Binnen 24 uur na de openbare bekendmaking maakten aanvallers al actief misbruik van sites die de kwetsbare versie gebruikten.

Een ander veelbesproken voorbeeld uit 2024 betrof de Bit File Manager-plugin, waarbij een zeldzame kwetsbaarheid aanvallers in staat stelde willekeurige PHP-bestanden te uploaden en uit te voeren op getroffen websites.

De periode tussen het uitbrengen van een patch en het daadwerkelijke misbruik ervan wordt vaak in uren, niet in dagen, gemeten. Zo snel gaan aanvallers te werk zodra een kwetsbaarheid openbaar wordt.

Belangrijkste conclusie: Als een plugin of thema dat je gebruikt meer dan 10.000 actieve installaties heeft en er een onopgeloste kritieke kwetsbaarheid wordt aangekondigd, ga er dan vanuit dat je site al wordt gescand en doelwit is van aanvallen.

Onbeperkte of slecht gevalideerde bestandsuploads

WordPress biedt talloze websites de mogelijkheid om bestanden te uploaden, van contactformulieren met bijlageopties tot mediarijke portfolio's en ledenplatformen. Wanneer de afhandeling van bestandsuploads slecht is geprogrammeerd, vormt dit een direct toegangspunt voor Remote Code Execution (RCE).

De aanval werkt als volgt. Een aanvaller uploadt een bestand dat er op het eerste gezicht onschadelijk uitziet, maar in werkelijkheid een PHP-webshell is. Een webshell is een klein script waarmee de aanvaller via een browser commando's naar uw server kan sturen, waardoor hij in feite een externe terminal in uw omgeving krijgt.

Aanvallers gebruiken vaak de volgende technieken om zwakke uploadvalidatie te omzeilen:

• Het gebruik van dubbele extensies zoals malware.png.php om standaard extensiecontroles te omzeilen

• De Content-Type-header wijzigen zodat een PHP-bestand als een legitieme afbeelding wordt weergegeven

• Het uploaden van bestanden met injectie van null-bytes om de werkelijke extensie af te korten tijdens de serververwerking

Het kernprobleem is dat veel ontwikkelaars alleen de bestandsextensie aan de clientzijde controleren. Of ze valideren alleen het MIME-type zonder dit aan de serverzijde af te dwingen. Beide controles zijn nodig, maar geen van beide is op zichzelf voldoende.

Objectinjectie- en deserialisatie-aanvallen

PHP heeft een ingebouwde functie genaamd unserialize() die een tekenreeks terug omzet in een PHP-object.

Als een aanvaller kan bepalen wat er aan unserialize() wordt doorgegeven, kan hij een kwaadaardige payload maken die een reeks methodeaanroepen in uw applicatie activeert, een zogenaamde POP-keten, die uiteindelijk willekeurige code op de server uitvoert.

WordPress zelf heeft in versie 6.4.2 een aanzienlijke kwetsbaarheid in de POP-keten verholpen.

De kernkwetsbaarheid op zich was niet direct exploiteerbaar. Echter, in combinatie met bepaalde plugins die hun eigen objectinjectiefouten bevatten, ontstond er een volledig RCE-aanvalspad.

Dit is een perfect voorbeeld van hoe twee ogenschijnlijk ongerelateerde kwetsbaarheden samen een kritieke bedreiging kunnen vormen.

Server-side template-injectie

Sommige WordPress-thema's en paginabouwers gebruiken sjabloonengines om dynamische inhoud.

Als gebruikersinvoer zonder de juiste validatie in deze sjablonen terechtkomt, kan een aanvaller sjabloonsyntaxis injecteren die door de server wordt geëvalueerd en uitgevoerd.

De eerder genoemde Bricks Builder CVE-2024-25600 was in feite een kwetsbaarheid voor template-injectie aan de serverzijde.

Gebruikersgestuurde gegevens werden rechtstreeks via de template-renderingengine doorgegeven aan een PHP-evaluatiefunctie. Dit maakte het zo gevaarlijk en zo gemakkelijk om op afstand te misbruiken.

Remote File Inclusion-aanvallen

Het opnemen van bestanden op afstand maakt misbruik van verkeerd geconfigureerde PHP-instellingen.

Wanneer de `allow_url_include`-richtlijn is ingeschakeld en een applicatie dynamische bestandspaden gebruikt die gebruikersinvoer bevatten, kan een aanvaller uw server dwingen een PHP-script op te halen en uit te voeren dat volledig op hun eigen server wordt gehost.

Hoewel moderne PHP-configuraties allow_url_include standaard uitschakelen, bevatten veel shared hosting-omgevingen en oudere WordPress-installaties nog steeds onveilige configuraties die na de initiële implementatie nooit meer zijn herzien.

Wat zijn de waarschuwingssignalen dat uw WordPress-site mogelijk is gehackt?

Veel RCE-aanvallen blijven weken of zelfs maanden verborgen. Aanvallers geven de voorkeur aan stille, aanhoudende toegang boven duidelijke verstoring. Er zijn echter signalen die u kunnen waarschuwen, zelfs als de schade niet direct zichtbaar is aan de voorkant van uw website.

Dit zijn de belangrijkste waarschuwingssignalen waar u op moet letten:

• Beveiligingsplugin- waarschuwingen die verdachte of onbekende PHP-scripts signaleren die in uw uploads- of pluginmap verschijnen.

• Er verschijnen nieuwe beheerdersaccounts in je WordPress-dashboard die je niet zelf hebt aangemaakt

• Ongebruikelijke pieken in het CPU-gebruik van de server of de uitgaande bandbreedte. Dit kan erop wijzen dat uw server zonder uw medeweten wordt gebruikt voor spam- of botnetactiviteiten

• Onverwachte wijzigingen in de kernbestanden van WordPress, themabestanden of pluginbestanden in vergelijking met hun geverifieerde originele versies

• Verdachte POST-verzoeken in uw serverlogboeken gericht op bestanden in de map wp-content/uploads

• Uitgaande netwerkverbindingen afkomstig van PHP-processen die communiceren met onbekende externe IP-adressen

• Zoekmachines die uw site markeren met malwarewaarschuwingen of uw hostingprovider die uw account zonder duidelijke uitleg opschort.

De meest betrouwbare manier om deze signalen vroegtijdig te herkennen, is door middel van geautomatiseerde monitoring en het scannen op bestandsintegriteit. Als u al meerdere waarschuwingssignalen ziet, ga dan naar het gedeelte over incidentrespons aan het einde van dit artikel.

Hoe voorkom je aanvallen met uitvoering van code op afstand in WordPress?

Het voorkomen van RCE-aanvallen draait niet om één enkele plugin of één enkele configuratiewijziging. Het vereist gelaagde verdedigingsmechanismen in uw gehele WordPress-omgeving.

Elke laag verkleint het aanvalsoppervlak en maakt het voor een aanvaller aanzienlijk moeilijker om een ​​bruikbaar toegangspunt te vinden.

Houd de WordPress-kern, plug-ins en thema's direct up-to-date

Dit is het allerbelangrijkste wat je kunt doen. De meeste succesvolle RCE-aanvallen zijn gericht op bekende kwetsbaarheden in verouderde software.

Dit zijn kwetsbaarheden waarvoor al patches beschikbaar zijn die nog moeten worden toegepast. Het uitstellen van updates is de belangrijkste reden waarom websites het doelwit worden van grootschalige aanvallen.

Zo ziet een degelijke update-strategie er in de praktijk uit:

• Schakel automatische achtergrondupdates voor kleine WordPress-core-releases in door define('WP_AUTO_UPDATE_CORE', 'minor'); aan uw wp-config.php-bestand.

• Abonneer u op kwetsbaarheidsmeldingen van Patchstack Intelligence, zodat u direct op de hoogte bent wanneer een plugin die u gebruikt een nieuw beveiligingsprobleem meldt.

• Controleer maandelijks uw pluginlijst en verwijder alles wat al meer dan 12 maanden geen ontwikkelaarsupdate heeft ontvangen, aangezien verlaten plugins consistent een hoog risico vormen

• Test updates eerst in een testomgeving voordat u ze naar de productieomgeving uitrolt. Bij grote versie-upgrades is de kans op compatibiliteitsproblemen namelijk groter.

Als u meerdere klantlocaties beheert, maakt een gecentraliseerd dashboard het aanzienlijk eenvoudiger om elke installatie up-to-date te houden zonder handmatig op elke locatie in te loggen.

Beveilig alle bestandsuploadpaden op uw site

Als uw website functionaliteit biedt waarmee gebruikers bestanden kunnen uploaden, bijvoorbeeld via een contactformulier, een ledenplugin, een WooCommerce-webshop of een portfoliobuilder, beschouw die uploadmogelijkheid dan standaard als een kwetsbaar punt voor aanvallen.

Zo ziet een goede beveiliging van het uploaden van bestanden eruit:

• Valideer zowel de bestandsextensie als het MIME-type aan de serverzijde bij elke upload; vertrouw nooit alleen op JavaScript-validatie aan de clientzijde

• Hanteer een expliciete whitelist van toegestane bestandstypen en weiger alles wat niet op die lijst staat met een harde foutmelding

• Blokkeer dubbele bestandsextensies op serverniveau, zodat bestanden zoals image.php.jpg worden geweigerd voordat ze uw applicatielogica bereiken

• Bewaar geüploade bestanden buiten de webrootmap, waar de applicatiearchitectuur dat toelaat, zodat ze niet rechtstreeks via een URL kunnen worden benaderd of uitgevoerd

• Blokkeer de uitvoering van PHP in de map 'uploads' volledig door een .htaccess-bestand met de volgende regels in de map wp-content/uploads te plaatsen:

weigeren van alle opties -ExecCGI AddType text/plain .php .php5 .phtml

Pro-tip: Zelfs als een aanvaller erin slaagt een PHP-webshell naar je uploadmap te uploaden, zorgt het blokkeren van PHP-uitvoering in die map ervoor dat het bestand niet daadwerkelijk kan worden uitgevoerd. Deze ene .htaccess-regel heeft talloze RCE-pogingen tegengehouden die anders zouden zijn geslaagd.

Implementeer een webapplicatiefirewall met virtuele patching

Een webapplicatiefirewall bevindt zich tussen uw website en inkomend verkeer en controleert verzoeken voordat ze WordPress bereiken.

Een goede WAF blokkeert bekende kwaadaardige payloads, inclusief de aanvalspatronen die geassocieerd worden met RCE-pogingen, voordat ze kunnen interageren met kwetsbare code op uw server.

De meest waardevolle WAF-functie voor het voorkomen van RCE (Remote Code Execution) is virtuele patching. Wanneer een kritieke kwetsbaarheid publiekelijk bekend wordt gemaakt, implementeren gerenommeerde WAF-providers binnen enkele uren een virtuele patch, waardoor bekende exploitatiepogingen worden geblokkeerd nog voordat de plugin- of themaontwikkelaar een officiële oplossing uitbrengt.

Dit dicht het gevaarlijke tijdsvenster tussen openbaarmaking en beschikbaarheid van patches, een venster dat aanvallers agressief uitbuiten.

Voor WordPress Cloudflare WAF met zijn WordPress-specifieke regelset uitstekende bescherming en krachtige DDoS-mitigatie.

Sucuri Firewall is speciaal ontwikkeld voor WordPress en combineert malware-scanning, CDN-prestaties en virtuele patches in één beheerde oplossing.

Een belangrijk onderscheid om te weten: sommige beveiligingsplugins bevatten een ingebouwde firewall, maar deze werkt op PHP-eindpuntniveau, wat betekent dat deze nog steeds binnen WordPress zelf wordt geladen.

Een cloudgebaseerde WAF filtert verkeer voordat het uw server bereikt, waardoor het een sterkere eerste verdedigingslinie vormt tegen RCE-aanvallen.

Schakel de WordPress-bestandseditor uit in het dashboard

WordPress wordt geleverd met een ingebouwde code-editor waarmee beheerders thema- en pluginbestanden rechtstreeks vanuit het dashboard kunnen wijzigen.

Hoewel deze editor handig is tijdens de ontwikkeling, vormt hij een groot risico als een aanvaller ooit toegang krijgt tot een beheerdersaccount. Met deze functie ingeschakeld kunnen ze direct kwaadaardige PHP-code in elk bestand op de site injecteren, zonder dat ze FTP- of SSH-gegevens nodig hebben.

Schakel het permanent uit in wp-config.php:

define('DISALLOW_FILE_EDIT', true); define('DISALLOW_FILE_MODS', true);

De tweede constante gaat nog een stap verder door de installatie van plugins en thema's via het dashboard volledig te voorkomen.

Dit is een optionele, maar sterk aanbevolen instelling voor productieomgevingen. Het voorkomt dat een gecompromitteerd beheerdersaccount wordt gebruikt om een ​​schadelijke plugin te installeren via de WordPress-interface.

Dit was ook de aanbevolen oplossing voor CVE-2024-31210 voordat WordPress versie 6.4.3 uitbracht.

Beveilig PHP en uw serverconfiguratie

Een groot deel van de WordPress-beveiliging heeft te maken met serverbeveiliging. Zelfs als alle plugins op je site volledig zijn bijgewerkt, kan een verkeerd geconfigureerde server je nog steeds kwetsbaar maken voor RCE-aanvallen op infrastructuurniveau.

Werk samen met uw hostingprovider of systeembeheerder om deze beveiligingsmaatregelen te implementeren:

• Voeg eval(), system(), shell_exec(), passthru(), proc_open()en popen() toe aan de disable_functions-richtlijn in uw php.ini om te voorkomen dat de gevaarlijkste PHP-uitvoeringsfuncties worden uitgevoerd.

• Stel de juiste bestandsrechten in: wp-config.php moet 400 of 440 zijn, mappen moeten 755 zijn en individuele bestanden moeten 644 zijn.

• Maak wp-config.php alleen-lezen op bestandsniveau, zodat zelfs gedeeltelijke code-uitvoering niet kan worden gebruikt om uw databasegegevens of beveiligingssleutels te wijzigen

• Schakel allow_url_include uit in de PHP-configuratie om de aanvalsvector voor het includeren van bestanden op afstand te elimineren

• Zorg ervoor dat PHP nooit als root op de server wordt uitgevoerd, aangezien uitvoering op rootniveau betekent dat een succesvolle RCE-aanval onbeperkte toegang heeft tot uw volledige hostingomgeving

Als je een managed WordPress hostingpakket hebt , worden veel van deze configuraties op infrastructuurniveau door je provider afgehandeld. Het is echter nog steeds verstandig om te controleren wat wel en niet is inbegrepen.

Verklein de voetafdruk van je plugins en controleer welke je installeert

Elke plugin op je website is code die op je server draait. Elk stukje code is een potentieel aanvalsoppervlak. Hoe meer plugins je hebt, vooral inactieve of verlaten plugins, hoe meer toegangspunten er zijn voor misbruik.

Volg deze richtlijnen voor het onderhoud van plug-ins consequent:

• Deactiveer en verwijder plugins die u niet langer actief gebruikt. Alleen deactivering zorgt ervoor dat de code op de server blijft staan, waar deze nog steeds potentieel kan worden aangevallen via achtergebleven bestandspaden

• Controleer voordat u een plugin installeert de datum van de laatste update, het aantal actieve installaties en de geschiedenis van bekende beveiligingslekken in de officiële WordPress-pluginrepository

• Installeer nooit plugins van onofficiële bronnen of illegale repositories, aangezien deze vaak vooraf geïnstalleerde backdoors en verborgen kwaadaardige code bevatten

• Gebruik Patchstack of een vergelijkbare dienst voor het monitoren van kwetsbaarheden om automatisch waarschuwingen te ontvangen wanneer een plug-in die momenteel op uw site actief is een nieuw ontdekt beveiligingsprobleem heeft

In een veelbesproken incident uit 2025 hebben aanvallers duizenden WordPress-sites gehackt door zich te richten op stopgezette plugins die wel waren gedeactiveerd, maar niet verwijderd.

De plugin-code was nog steeds aanwezig op de server en nog steeds toegankelijk via een URL, wat voldoende was voor de succesvolle exploitatie.

Schakel tweefactorauthenticatie in voor alle beheerdersaccounts

RCE-aanvallen via gestolen beheerdersgegevens komen minder vaak voor dan aanvallen gebaseerd op exploits, maar ze vormen wel degelijk een reële en gedocumenteerde methode.

Een aanvaller die beheerdersrechten verkrijgt, kan binnen enkele seconden een kwaadaardige plug-in installeren, themabestanden bewerken of de bestandseditor van het dashboard gebruiken om willekeurige code uit te voeren.

Tweefactorauthenticatie voegt een verificatielaag toe die aanvallen op basis van inloggegevens aanzienlijk moeilijker maakt, zelfs wanneer wachtwoorden elders bij een datalek zijn gelekt.

Schakel het minimaal in voor alle beheerders- en editoraccounts. Plugins zoals WP 2FA of de ingebouwde 2FA-functies van Wordfence maken de implementatie eenvoudig voor elke website-eigenaar.

Voor een diepere analyse van de beveiliging van je beheerderslogin, de WordPress-loginbeveiliging meer aandacht dan alleen wachtwoorden.

Stel continue beveiligingsmonitoring en bestandsintegriteitsscans in

Je kunt niet reageren op een aanval waarvan je niet weet dat die plaatsvindt.

Continue monitoring en het scannen op bestandsintegriteit stellen u in staat een inbreuk vroegtijdig te ontdekken, voordat aanvallers de tijd hebben gehad om diepgaande, permanente toegang te verkrijgen die veel moeilijker te herstellen is.

Een degelijke monitoringopstelling omvat:

• Bestandsintegriteitsbewaking die elke wijziging in essentiële WordPress-bestanden, thema's en actieve plug-ins in realtime bijhoudt en u direct waarschuwt wanneer onverwachte wijzigingen worden gedetecteerd

• Geplande malware-scans die zoeken naar bekende kwaadaardige signatures, versleutelde PHP-patronen zoals eval(base64_decode(...))en ongeautoriseerde backdoor-bestanden binnen uw installatie.

• Logboekregistratie van inlogactiviteiten die elke mislukte en geslaagde inlogpoging vastlegt, en ongebruikelijke geografische toegangspatronen of snelle opeenvolgende inlogfouten vanaf hetzelfde IP-adres signaleert

• Monitoring van uitgaande verbindingen op serverniveau om PHP-processen te detecteren die proberen te communiceren met externe command-and-control-servers

Wordfence, Sucuri en MalCare zijn de meest gebruikte tools voor het monitoren van de beveiliging van WordPress.

Als u liever wilt dat experts deze laag afhandelen, WordPress-onderhoudsdiensten met proactieve monitoring het overwegen waard voor elke bedrijfskritische website.

Zorg voor veilige, geteste back-ups en weet hoe u ze kunt herstellen

Backups zijn uw laatste vangnet wanneer al het andere faalt. Als een RCE-aanval slaagt en uw site wordt gecompromitteerd of vernietigd, is een schone back-up wat u weer online brengt.

Een back-upstrategie werkt echter alleen als uw herstelproces daadwerkelijk is getest voordat een crisis zich voordoet.

Volg deze back-upprocedures:

• Bewaar back-ups extern en volledig gescheiden van uw hostingomgeving, aangezien een aanval op serverniveau lokale back-ups samen met uw websitebestanden kan vernietigen of versleutelen

• Voer minimaal dagelijks geautomatiseerde back-ups uit, en altijd vóór elke belangrijke update of code-implementatie

• Test je herstelproces minstens elk kwartaal, zodat je precies weet hoe lang het duurt en welke stappen erbij komen kijken voordat je het daadwerkelijk onder druk nodig hebt

• Bewaar meerdere herstelpunten, zodat u kunt terugkeren naar een versie van vóór de inbreuk en niet alleen naar de meest recente momentopname

Wat moet u direct doen als u een RCE-aanval vermoedt?

Als u alarmerende signalen ziet of een beveiligingswaarschuwing hebt ontvangen, is snelheid geboden. Volg hiervoor de volgende stappen:

• Schakel de site onmiddellijk offline of zet deze in de onderhoudsmodus om te voorkomen dat de aanvaller gebruik blijft maken van bestaande toegangspunten of extra gegevens steelt terwijl u het probleem onderzoekt.

• Voer een volledige malware-scan uit om schadelijke bestanden, backdoors en geïnjecteerde code in uw installatie te identificeren.

• Controleer alle WordPress-beheerdersaccounts en verwijder alle accounts die u niet zelf hebt aangemaakt. Besteed daarbij speciale aandacht aan recent toegevoegde accounts met beheerdersrechten.

• Wijzig alle inloggegevens, waaronder WordPress-beheerderswachtwoorden, databasewachtwoorden, FTP- en SFTP-gegevens, SSH-sleutels, wachtwoorden voor het hostingcontrolepaneel en uw WordPress-beveiligingssleutels en -salts in wp-config.php.

• Controleer de toegangslogboeken en foutenlogboeken van uw server op aanwijzingen van een inbreuk, zoals POST-verzoeken gericht aan bestanden in de uploadmap, PHP-uitvoering vanaf onverwachte locaties of uitgaande verbindingen naar externe IP-adressen.

• Herstel de website vanuit een schone back-up, indien beschikbaar, van vóór de vermoedelijke inbreukdatum, en voer vervolgens direct alle openstaande updates uit voordat u de site weer online zet.

• Identificeer en verhelp de oorspronkelijke kwetsbaarheid , zodat het herstellen van de site niet simpelweg dezelfde omstandigheden creëert die de aanval in eerste instantie mogelijk maakten.

Als u niet zeker bent of u incidenten zelf kunt afhandelen, professioneel WordPress-siteherstel beschikbaar. Dit is vaak sneller en grondiger dan een handmatige opruimpoging zonder de juiste tools en ervaring.

Slotgedachten

Aanvallen waarbij code op afstand wordt uitgevoerd, behoren tot de ernstigste bedreigingen voor de WordPress-beveiliging, maar ze zijn zeker niet onvermijdelijk.

De websites die gehackt worden, zijn bijna altijd de websites die beveiliging als iets voor later beschouwden. Aanvallers hebben het niet specifiek op jouw website gemunt.

Ze scannen miljoenen sites tegelijk, op zoek naar sites met ongepatchte plugins, open uploaddirectory's, uitgeschakelde monitoring en geen actieve beveiligingsmaatregelen.

De beveiligingsmaatregelen die in deze handleiding worden beschreven, zijn afzonderlijk niet ingewikkeld. Hun kracht schuilt in het gebruik ervan als een gelaagde strategie. Zorg dat alles up-to-date is. Beveilig het uploaden van bestanden. Implementeer een WAF (Web Application Firewall). Beveilig uw PHP-omgeving. Monitor continu. En zorg dat u een schone, geteste back-up klaar hebt voordat u die ooit nodig hebt.

Als u deskundige hulp nodig heeft bij het implementeren van deze beveiligingsmaatregelen of een professionele audit van uw huidige WordPress-beveiligingsinstellingen wilt laten uitvoeren, staat het team van Seahawk Media voor u klaar. Neem contact met ons op en laat ons bekijken wat uw website nodig heeft.

Veelgestelde vragen over WordPress RCE-aanvallen