Threat Intelligence

The Timestamp That Gave It Away: Oracle Identity Cloud Phishing Targets K-12 with a Stale Timezone

Written by Audian Paxson | Apr 10, 2026 11:00:00 AM
TL;DR Attackers sent a fake Oracle Identity Cloud password reset email to a K-12 employee in Florida. The kit used 'CDT' in the timestamp even though Daylight Saving Time had ended on November 2, 2025, meaning the correct abbreviation was 'CST.' The reset link pointed to richard-woof.com, a UK-hosted domain with no connection to Oracle, and its Base64-decoded token revealed explicit per-recipient targeting. A Google 404 redirect cloaked the destination from automated scanners. The case illustrates a low-tech detection method available to any recipient: check whether the timezone in a security notification matches the current time of year.
Severity: High Credential Harvesting Phishing Impersonation MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1598.003', 'name': 'Phishing for Information: Spearphishing Link'} MITRE: {'id': 'T1036', 'name': 'Masquerading'} MITRE: {'id': 'T1027', 'name': 'Obfuscated Files or Information'}

The email arrived on a Sunday morning in mid-November 2025, addressed to a staff member at a Florida K-12 school district. It looked like a routine Oracle Identity Cloud password reset notification: Oracle branding, Oracle Sans font, a copyright footer reading "© 2022 Oracle." Two buttons, "Reset Password" and "Security Link," in that dark charcoal Oracle style.

There was a timestamp in the body. It read "Sunday, November 16, 2025 09:09:18 PM CDT."

Daylight Saving Time ended on November 2, 2025. The correct abbreviation for Central time after that date is CST, not CDT. The kit hadn't been updated. That single stale abbreviation is a reliable signal that the email was generated by a phishing kit built or last configured before DST ended, the kind of detail that slips through because nobody tests the timezone logic when they're assembling a credential-harvest campaign in a hurry.

A Domain That Has Nothing to Do with Oracle

The "Reset Password" button did not link to Oracle. After the Barracuda email security gateway rewrote the URL (standard behavior for the district's inbound filtering service), the destination was hxxps://richard-woof[.]com/i/?c3Y9Z2VuZXJhbCZyPWh0JnVpZD1VU0VSMTMxMTIwMjVVNTIxMTEzNTkmcz1hMw==N0123N.

richard-woof[.]com is a domain registered in the year 2000, currently hosted in the UK (A record resolving to 109[.]123[.]69[.]211, PTR pointing to freehandproductions.co.uk). It has no DMARC record, no DNSSEC, and no connection to Oracle Corporation or any school district. WHOIS shows it was last updated in July 2025, suggesting recent repurposing for this campaign.

Decode the Base64 token in that URL and you get: sv=general&r=ht&uid=USER13112025U52111359&s=a3. That uid value is a per-recipient identifier. This wasn't a spray-and-pray campaign. The attacker built individualized lure URLs for each target.

The Evasion Layer That Fooled the Gateway

When IRONSCALES sandbox analysis tested the link, it resolved to google.com/404/. That's the cloaking mechanism: the redirector checks whether the visiting client looks like an automated scanner. If it does, it serves a Google 404, which most link reputation systems score as clean. If a real user clicks from a real mail client, the redirector serves the credential harvest page instead.

The Barracuda gateway that processed this email scored it a 0.00 spam score. The link returned clean in automated scanning. SPF passed for the sending domain agrogreenalax.com (registered June 2025, privacy-shielded at Namecheap), and while DKIM failed body hash verification at Google's MX, that was a side effect of Barracuda's legitimate link-rewriting modifying the message body in transit. The email sailed through every filter the district had deployed.

See Your Risk: Calculate how many threats your SEG is missing

The attacker also embedded a Disposition-Notification-To header pointing at value1consultings@gmail[.]com. Any mail client that honors read receipts would have silently notified the attacker the moment the target opened the email, before they clicked anything.

Why K-12 Districts Keep Showing Up in This Data

This is not an isolated case. K-12 education is a reliably soft target in credential phishing campaigns. The FBI IC3 2024 Internet Crime Report documents education as a consistently high-complaint sector, and across the IRONSCALES customer base of 1,921 organizations, education sector deployments show attack volumes that outpace similarly sized organizations in other industries.

The reasons aren't complicated. School districts run lean IT teams, often one or two people covering hundreds of staff. Many use legacy gateways or bundled email security from their district's cloud provider. Security awareness training budgets compete with classroom technology. And the accounts matter: staff credentials unlock payroll systems, student records, and in many cases federal grant portals.

According to the Verizon 2024 Data Breach Investigations Report, over 80% of hacking-related breaches still involve stolen or brute-forced credentials (https://www.verizon.com/business/resources/reports/dbir/). The Oracle Identity Cloud lure format works because it targets the identity layer directly. The attacker isn't trying to install malware. They want the password, and Oracle Identity Cloud is a real product that real school districts use.

What the Attack Chain Looks Like

Step by step, this is how it was constructed:

  1. Sender infrastructure: New domain agrogreenalax[.]com (registered June 2025), configured with SPF and DKIM to pass authentication checks. DMARC set to p=reject, which looks legitimate to automated assessments. A-record at 172[.]93[.]120[.]235, consistent PTR record.
  2. Lure email: Pixel-perfect Oracle Identity Cloud password reset template. Per-recipient email address in the subject line, salutation, and embedded in the reset URL. Timestamp with stale CDT timezone.
  3. Read receipt trap: Disposition-Notification-To header pointing to attacker-controlled Gmail address for open-notification telemetry.
  4. Payload URL: Base64-encoded token with unique user ID routed through richard-woof[.]com, a repurposed 25-year-old UK domain.
  5. Cloaking: Google 404 redirect served to scanners; credential harvest page served to real users. Link returns clean in automated analysis.

MITRE ATT&CK mapping: T1566.002 Spearphishing Link, T1036 Masquerading, T1027 Obfuscated Files or Information.

Themis flagged the message through behavioral analysis: the combination of a newly registered sender domain, off-brand reset link destination, and per-recipient URL token pattern matched known credential harvesting signatures in the IRONSCALES platform data. The district's Barracuda gateway had already rewritten the link and scored it clean before Themis reviewed it, illustrating exactly the gap that layered email security is designed to close.

The Timezone Check Anyone Can Do

Most phishing detection advice focuses on domains, visual design, or link destinations. Those require at least some technical investigation. The timezone tell in this case requires nothing but calendar awareness.

If a security notification claims to have been sent on a date in November, December, January, February, or March and shows a Daylight Time abbreviation (CDT, EDT, MDT, PDT), the email was generated by a kit that hadn't been updated since before DST ended. That's a forgery signal visible to anyone who knows what month it is.

The same logic applies in reverse: a notification sent in July claiming CST instead of CDT is equally suspicious. Phishing kits are built once, tested against a few targets, and reused. Timezone handling is an afterthought. That makes it a reliable tell.

The CISA phishing guidance covers many of the standard tells: check the sender domain, hover before clicking, look for urgency language. Add timezone verification to that list. It's low-tech, requires no tools, and in this case, it was the clearest indicator that something was wrong before any link analysis happened.

Indicators of Compromise

TypeIndicatorContext
Domainrichard-woof[.]comCredential harvest redirector, UK-hosted
Domainagrogreenalax[.]comSending infrastructure, registered June 2025
IP109[.]123[.]69[.]211A record for richard-woof[.]com
IP172[.]93[.]120[.]235Sending MTA for agrogreenalax[.]com
URLhxxps://richard-woof[.]com/i/?c3Y9Z2VuZXJhbCZyPWh0JnVpZD1VU0VSMTMxMTIwMjVVNTIxMTEzNTkmcz1hMw==N0123NPhishing redirect URL (cloaked)
Emailadmin@agrogreenalax[.]comPhishing sender address
Emailvalue1consultings@gmail[.]comAttacker read-receipt collection address
Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 30,000+ security professionals. Each post breaks down one attack — what it looked like, why it worked, and what you can do about it.