Is sakdaphondongnok-adobe-cloud.sakda-ph.workers.dev safe?

A recognized brand name and a shared-document story

The captured page carries Adobe Creative Cloud branding and the hostname itself is built around the Adobe name, which is the only reason to trust the page at first glance. The supporting text tells you that a project workspace has been shared with you and that you should sign in with your email address to review the brief, files and collaboration details. That is a well-worn lure: it manufactures a plausible reason to type an address without any real shared document existing.

The next step on the same page repeats the prompt with a plain 'Sign in to continue' instruction, so the page is steering the visitor toward a single action from the first screen onward.

What the visitor is actually asked to submit

The page contains an email address input field with a Continue button next to it. On a legitimate Adobe or Microsoft document-sharing surface, that address would be checked against a real invitation before anything else occurred; here there is no visible invitation record, no sending organisation and no support or contact route on the captured page, so the field exists to collect whatever the visitor types.

Because the collection step happens on a host that is not Adobe's, a submitted address is disclosed to an unidentified third party rather than to the service the page claims to be. That is the harm this page is built to produce, and it is why the classification here is phishing-impersonation rather than a brand or content issue.

Hosting pattern and independent signals

The site lives on a workers.dev subdomain rather than a registered company domain. Published threat research has documented phishing campaigns using Cloudflare's workers.dev hosting specifically to evade anti-phishing detection while serving branded lure pages that impersonate Adobe and Microsoft, which matches the setup seen here.

One antivirus family returned an adverse result for this address while no vendor consensus was reached, and the browser threat feed returned no warning. The single detection is consistent with a freshly deployed page; the absence of a block elsewhere is not a clearance, because brand-new lure pages routinely outrun blocklists.

The scanned address was also served over plain HTTP with no redirect to HTTPS even though a valid certificate exists for the host, so anything entered on the page would travel unencrypted. On a page whose whole purpose is to accept an email address, that is a straightforward technical exposure on top of the phishing mechanism.