Website security
& malware cleanup
in Dubai

A hacked site in the UAE is usually handled like a hacked site anywhere. Access is closed, files and database are cleaned, passwords change, the hole gets patched. Two things are different enough to plan for. There is a national team that receives incident reports, and a site published in Arabic and English gives attackers a second language to hide in.

The team is aeCERT, the computer emergency response team of the UAE. It was set up under the telecommunications regulator, which today operates as the Telecommunications and Digital Government Regulatory Authority, TDRA. It publishes security advisories, collects reports of incidents and coordinates responses with other response teams and with service providers. It does not clean websites. It will not restore a broken theme either. That work stays with your developer.

So when is a report worth the effort? Mostly when the damage reaches beyond your own server. A phishing page placed on your domain that imitates a bank, a courier or a government payment portal harms people who never visited your site on purpose. Your server may be sending attack traffic to other systems. Customer records may have been copied. Here the incident belongs to more parties than you and your developer. A report makes sense.

A report also helps when the attacker is still active somewhere you cannot reach. A hosting provider abroad that ignores an abuse email may respond differently to a national response team. Hosts, banks and larger partners often ask whether the incident was reported. A reference number answers that question in one line.

Timing matters too. Do not wait for the cleanup to finish before reporting. The report can go out on the first day, with a note that work is under way. Details can follow. Waiting a week means the phishing page keeps collecting card numbers while the paperwork is polished.

What should go into the report? Keep it factual. List the affected domain and addresses, the time the problem was noticed, what was found, which pages or files were involved, and what has already been done. Keep copies of the malicious files and the relevant server logs before deleting anything. The cleanup team should hand these over in a tidy folder, with a short timeline written in plain language.

The second problem is the injected content itself. A common pattern on bilingual sites is a batch of Arabic pages that the owner never wrote. They advertise medicines, betting, fake visa services or loans. Some sell nothing. Some copy the layout of a real service and ask for card details. Because the site already has an Arabic section, these pages look at home. Search engines index them next to the genuine ones, under the same language folder and often in the same sitemap.

An English-speaking reviewer can miss them entirely. The page titles look plausible in a list, and right-to-left text in an admin table is hard to scan. Cleanup therefore needs someone who reads Arabic, or at least a method that does not depend on reading. Compare the list of published Arabic URLs with the list the content team actually approved. Check sitemaps, the translation tables of the multilingual plugin, hreflang pairs and the language switcher links. Injected pages often have no English twin at all, which gives them away.

Search results are the other place to look. A site search with typical spam words in Arabic shows what an engine has already collected. Each removed address should answer with a gone status instead of redirecting to the home page. Remove the addresses in the search console, then resubmit a clean sitemap.

Finally, check what outside readers saw. Phishing pages may have been reported by users already. If the domain appears in a browser warning list, the review request comes after the Arabic and English sections are both clean. Clean one language only and the review can fail. Then the wait starts again.