Category: Cyber News

It all started when DNS resolution issues within AWS’s own infrastructure caused services to fail at connecting properly. Basically, the system that tells computers where to find each other stopped working the way it should. Once that broke, the effects cascaded into other services like storage, databases, and computing instances.

The Ripple Effect

When something like this happens inside a provider as large as Amazon, it doesn’t just stay within their ecosystem. Businesses that depend on AWS for hosting, analytics, or even authentication suddenly find themselves offline. Streaming platforms, banking apps, e-commerce stores, and even schools felt the hit.

Even though AWS resolved the issue within hours, the damage was already done — downtime, lost transactions, delayed services, and frustrated users everywhere.

My Take on It

This outage reinforced something I’ve always said: no system is too big to fail. Even a company with the resources and experience of Amazon can run into infrastructure breakdowns.

That’s why redundancy and smart design matter so much. Relying on a single cloud region or provider is a recipe for disruption. I always recommend setting up multi-region backups, strong monitoring tools, and clear response plans so that when an outage hits, your operations don’t grind to a halt.

Another key lesson is transparency — if your users are affected, communicate quickly. People are more forgiving when they’re informed.

Final Thoughts

Whether it’s a misconfiguration, an internal update, or something more serious, incidents like this remind us that resilience is just as important as performance. For me, it’s not about pointing fingers at AWS — it’s about learning from the chaos and using it to build systems that can withstand it.

The cloud gives us incredible power and flexibility, but it also means we all share the same risks when something that big goes down.

On October 19, 2025 in the US-East-1 region, I noticed elevated error rates and latency across multiple AWS services. It began around 11:49 PM PDT.
The root cause was traced by 12:26 AM PDT the next day to a faulty DNS update. This prevented applications from resolving server IPs — like a broken phonebook for the internet.
Because of that, more than 100 AWS services were affected. Services that relied on the core database service DynamoDB in particular caused cascading failures — for example, EC2 launches stalled, Lambda functions had issues, load balancer health checks failed.

As a user or system administrator, the ripple effects were visible everywhere: gaming platforms went offline, financial apps had login failures, even Amazon’s own systems (like Prime Video and e-commerce checkout) saw disruption.

How It Was Fixed

Here’s what AWS did to bring the systems back online:

• They flushed DNS caches and applied the fix for the core DynamoDB DNS issue by about 2:24 AM PDT.
• They temporarily throttled some operations (for example, asynchronous Lambda invocations, EC2 instance launches) to stabilize dependent subsystems.
• By around 3:01 PM PDT, AWS had confirmed that all services were fully restored, though some data-processing backlogs (for example in Redshift and Connect) remained to be cleared.

Final Thoughts

Contrary to what many people thought, this outage wasn’t caused by a cyberattack — rather, it appears to have been an internal update gone wrong.

Still, it’s a vivid reminder: even the biggest cloud provider can experience a disruption, and when they do, many of us feel it. Thinking proactively about architectural resilience and dependent-service risk is more important than ever.

In my review, I found that Happy DOM’s Node.js VM context isn’t truly isolated. Because JavaScript evaluation (via eval() and Function()) is enabled by default, untrusted code can escape the sandbox. In other words, an attacker could craft malicious JavaScript that climbs the constructor chain and gains access to the process-level Function constructor, breaking out of the supposed safe environment.

The type of module system (CommonJS vs ESM) matters here. In a CommonJS setup, the attacker might get access to the require() function, load Node.js modules, and perform unauthorized actions.

This vulnerability is a major concern especially for server-side rendering (SSR) frameworks or any server that processes external HTML content. Here are some of the attack scenarios I identified:

• Data exfiltration: The attacker could access environment variables, configuration files, secrets.
• Lateral movement: If the compromised server has network access, internal systems could be reached.
• Full code execution: Executing arbitrary commands by spawning child processes is possible.
• Persistence: The attacker could modify the filesystem to keep long-term footholds inside the system.

What to do

Here are the steps I’m recommending:

Disable evaluation: If an immediate update isn’t possible, turn off JavaScript evaluation unless you’re confident all processed content is fully trusted.

Update: Move to Happy DOM version 20 or newer, which disables JavaScript evaluation by default and shows a warning if you turn it on in an insecure environment.

Configuration: If you must use safe JavaScript evaluation, run Node.js with the --disallow-code-generation-from-strings flag. That blocks eval() and Function() at the process level.

The intrusion happened sometime between November 5 and November 11, 2024, when attackers gained unauthorized access to the group’s network and copied files containing patients’ data. Once they detected unusual activity, they launched a full investigation. That process took many months. The detailed review was completed by August 29, 2025, and the breach was publicly reported on September 24, 2025.

Scale

During the investigation they confirmed that both Protected Health Information (PHI) and Personally Identifiable Information (PII) had been compromised. Exposed data includes names, addresses, dates of birth, Social Security numbers, medical records, insurance and billing details, treatment data, and even financial account numbers. Because finance data was part of the leak, affected people face real risk of identity theft or fraud.

In response, the company alerted law enforcement and regulatory bodies, began notifying the individuals whose data was exposed, and said it is reviewing internal security practices and looking into additional cybersecurity tools. They also advised that all impacted individuals monitor their financial statements, medical explanation of benefits, and credit reports for signs of trouble.

My Take:

I think this breach emphasizes a truth: even organizations in critical and highly regulated sectors like healthcare are still failing to keep up with data security. If you ask me, I feel like breaches like this could be prevented with stronger network monitoring and consistent patch management, but too often, security becomes an afterthought until it’s too late.

Zero-day vulnerabilities in Cisco firewalls enable unauthenticated remote code execution and Denial-of-Service attacks. CISA mandates these devices be patched immediately and urges organizations to follow heightened monitoring and mitigation procedures until updates are active.

Details of the Vulnerabilities

The vulnerabilities exist in the firewall management plane and packet-processing modules. In some cases, crafted packets can bypass authentication altogether. Attackers could leverage malformed network traffic to trigger buffer overflows, memory corruption, or logic errors—leading to RCE or DoS against firewall systems. These flaws pose particular risk to perimeter defenses that directly face the internet.

Risk & Urgency

Because these are zero-day vulnerabilities—with publicly known proof-of-concept code or active exploitation—attackers may be able to compromise firewalls before patches are applied. Since firewalls guard critical infrastructure, successful exploits can lead to broad network compromise, traffic interception, or lateral movement.

CISA has added these issues to its Known Exploited Vulnerabilities catalog, putting organizations on notice to treat them as high priority.

Mitigation & Recommended Actions

1. Patch immediately — install Cisco’s security updates for ASA and FTD software as soon as they’re available.
2. Temporarily limit exposure — block management interfaces from untrusted networks and restrict access to trusted IPs.
3. Use access control lists (ACLs) — restrict incoming traffic to firewall control interfaces.
4. Enable logging and alerts — monitor for suspicious connections, anomalous traffic patterns, or unexpected firmware behavior.
5. Employ segmentation — isolate firewall management components where possible and reduce their attack surface.
6. Coordinate with vendors — track Cisco’s advisory, confirm patch applicability to your variants, and validate configuration integrity.

Main Takeaways

• Attackers are misusing Oracle’s internal job scheduling capability to hide payload execution, making their actions look like routine DB tasks.
• By running malicious tasks via the Scheduler, they can survive restarts and stay under the radar of many security controls.
• Defense recommendations include auditing scheduled jobs regularly, restricting who can create new jobs, and enabling alerting when unusual jobs are added.

The Oracle DB Scheduler is a component that allows administrators to schedule jobs (such as PL/SQL scripts or shell commands) to run at defined intervals or triggers. Threat actors with sufficient database privileges are leveraging this component to:

• Insert malicious or unauthorized jobs that execute commands or scripts.
• Operate under the guise of maintenance or backup jobs, blending into typical database activity.
• Ensure persistence even across database restarts or maintenance windows.

Because many monitoring tools look at external services or suspicious processes, a malicious job operating internally within Oracle can slip past detection.

Attack vectors & mechanics

• The attacker must first gain elevated privileges within the Oracle environment (e.g. DBA role or access to scheduler privileges).
• Using the DBMS_SCHEDULER API or SQL packages, they create or modify jobs that invoke shell commands or scripts.
• These jobs can execute on a schedule or in response to specific events/triggers.
• The commands run under the context of the database user, which may have access to file systems or other services.
• Because the job definitions are stored within the Oracle database, they’re harder to spot via OS-level monitoring tools.

Risks & impacts

• Persistence: Even after system reboots or routine cleanups, the scheduled jobs can re-run malicious code.
• Stealth: Activity appears as a legitimate database operation rather than an external attacker process.
• Privilege escalation / lateral movement: Malware or commands launched via these jobs can attempt privilege escalation, data exfiltration, or further infrastructure compromises.

Mitigation & defense strategies

• Audit scheduler jobs: Regularly review all jobs in the Oracle database and compare them against known baselines.
• Restrict scheduler permissions: Limit who can create, alter, or drop jobs via DBMS_SCHEDULER to a small set of trusted admins.
• Alert on anomalies: Trigger alerts if new or modified jobs are created, especially those invoking external scripts or shell commands.
• Harden database access: Enforce least privilege, role separation, and monitor for suspicious privilege assignments.
• Use forensic logging: Enable audit logs for scheduler activity and track job execution history.
• Isolate sensitive environments: Where possible, separate mission-critical DB servers from environments where attacker access is more probable.

Main Takeaways

• The flaw is due to incorrect permissions on configuration directories and files, allowing privileged users to tamper with rules, logging, or settings.
• The vulnerability’s CVSS 3.1 base score is 2.3, reflecting a low-severity rating—because it requires local privileged access.
• IBM has released UP13 IF02 to fix the permissions issue; administrators should also limit who holds local admin rights and monitor the QRadar config folder.

This vulnerability stems from a CWE-732: Incorrect Permission Assignment for Critical Resource. In the affected QRadar versions, configuration files under /opt/qradar/conf and associated folders are writable by privileged users beyond the intended service account.

With local privileged access (e.g. a sysadmin or support engineer), an attacker—or a misbehaving insider—can alter logging rules, disable detection mechanisms, or otherwise manipulate QRadar’s behavior. These changes could persist until manually discovered and reversed and might skew audit trails or hide malicious activity.

Risk & Impact

• Who’s vulnerable: QRadar SIEM installations running 7.5 through 7.5.0 UP13 IF01.
• What is possible: Unauthorized modifications to configuration files, disabling detection or logging rules, or otherwise undermining the system’s integrity.
• Exploit prerequisites: The attacker must already have privileged local access. Remote exploitation is not in scope.
• Severity rating: CVSS 3.1 score of 2.3 (low) — the limited impact is due to the required level of access.

Mitigations & Recommendations

• Patch: Upgrade to QRadar 7.5.0 UP13 IF02, which corrects the permissions so only the QRadar service account can write the configuration files.
• Restrict admin privileges: Only allow trusted personnel to hold local administrator or system-level access on QRadar hosts.
• Monitor config folder: Set up alerts to detect changes in /opt/qradar/conf (or equivalent paths) and review file modifications regularly.
• Harden host security: Use file integrity monitoring, limit shell access, and enforce separation of duties to reduce the chance a privileged account is misused.
• Audit user roles: Regularly review who holds local privilege, especially on security monitoring systems, and ensure least privilege principles.

Main Takeaways

• Threat actors are using Amazon SES accounts (often via compromised/abused credentials or misconfigured tenant accounts) to send high-volume phishing and credential-harvesting emails.
• The campaign can push 50k+ malicious emails per day, increasing reach while blending into legitimate bulk-mail traffic.
• Attack messages are high-quality, personalized, and frequently use dynamic landing pages or reply-forward chains that evade common filters.

What happened (high level)

Attackers leveraged Amazon SES — a trusted mail-sending service — to distribute large-scale phishing messages. Because SES is a legitimate infrastructure used by many organizations, emails routed through it can bypass reputation-based blocks and achieve higher inbox placement. The campaign’s combination of volume, personalization, and valid sending infrastructure makes it especially effective for credential theft and fraud.

How the campaign works

• Account abuse & access: Adversaries are obtaining SES sending ability via stolen AWS credentials, abused trial/tenant setups, or by compromising third-party vendors that have SES configured. Once they control an SES identity, they can send from verified domains or subdomains that look legitimate.
• High-volume, trusted senders: Using SES’s scalability, the attackers can deliver tens of thousands of messages per day without the typical spammer infrastructure fingerprints. This raises the delivery rate and reduces bounce/blacklist signals.
• Sophisticated lures: Emails use tailored templates, dynamic content, and short-lived landing pages (or disposable hosting) for credential harvesting. Some messages use reply chains or invoice/receipt formats to trick recipients into interacting.
• Filter evasion: Because messages originate from a reputable mail service and often pass DKIM/SPF checks when attackers control the sending identity, many automated filters and basic heuristics are less effective.

Impact & scale

Researchers observed that the operation can exceed 50,000 malicious emails per day, allowing attackers to massively scale credential-harvesting campaigns and payment-fraud schemes. The use of legitimate cloud email infrastructure complicates takedown and detection efforts.

Detection & mitigation

• Monitor SES usage: Alert on unusual SES activity (spikes in send volume, new verified identities, new sending regions, or unexpected DKIM/SPF changes). Require multi-factor authentication and restrict IAM permissions for sending.
• Harden cloud credentials: Enforce least privilege for AWS/IAM roles, rotate keys, enable MFA for console access, and use AWS CloudTrail and AWS Config to detect anomalies.
• Inspect content & URLs: Use URL reputation and runtime detonation for landing pages; flag short-lived domains and newly minted TLS certs used in credential harvesters.
• Improve recipient defenses: Train users to verify unexpected requests, enable strong anti-phishing controls (BIMI, DMARC with quarantine/enforce where possible), and deploy advanced mail-scanning that looks beyond SPF/DKIM to behavioral indicators.
• Coordinate takedown: If you identify abusive SES identities or hosting, report to AWS abuse with detailed logs (headers, sending identity, timestamps) to speed remediation.

Final note

This campaign underscores a growing trend: attackers prefer abusing trusted cloud platforms to improve delivery and evade traditional defenses. Defenders should shift from solely relying on sender reputation to combining infrastructure monitoring, cloud security hygiene, and content-aware detection.

Main Takeaways

• Researchers found hundreds of suspicious domains (many using “fifa”, “worldcup”, or host-city names) that mimic legitimate services to trick fans into visiting and transacting. Cyber Security News
• The malicious sites can deliver staged JavaScript that fetches in-memory payloads, avoids disk artifacts, and injects code into legitimate processes. Cyber Security News
• Campaigns rely on aged or low-friction domains across major registrars and cheap TLDs (.online, .shop) to gain credibility and resist takedown.

What researchers observed

Hundreds of domains registered with names referencing FIFA, World Cup, and host cities, with a registration surge in August 2025. Threat actors intentionally register domains well in advance (up to 18 months) so the sites look established when fan interest peaks.

These fraudulent pages are crafted to lure visitors into interacting with content (ticket lookups, schedule pages, streaming links). Once a visitor lands on an infected page, obfuscated JavaScript performs environment checks and, if conditions match, pulls a second-stage payload from a dynamically computed CDN hostname. The loader then unpacks encrypted modules in memory and injects them into legitimate processes (for example, svchost.exe), minimizing forensic traces.

Why this matters

By exploiting fan interest and high transaction volumes, attackers can scale credential-harvesting and financial fraud. Using aged domains and polymorphic loaders makes detection, attribution, and takedown harder — a problem that will grow as the tournament approaches and related domains proliferate.

Recommended actions

• Proactively monitor and blacklist suspicious domains and newly created domains that contain tournament-related keywords.
• Harden web filtering and block known low-reputation TLDs where appropriate (.online, .shop) and enforce allowlists for corporate ticketing or streaming vendors.
• Inspect web pages for injected JavaScript and deploy runtime protection that detects in-memory unpacking and reflective injection.
• Educate users to buy tickets only from official FIFA channels or trusted vendors and verify URLs before entering payment or personal information.

How it infects and stays resident

The campaign relies on social engineering and sideloading (users manually installing the APK) rather than exploiting software flaws. After installation the app registers background services and an Accessibility Service in its manifest—this grants powerful capabilities such as keystroke and in-app data interception. The malware runs continuous health checks and automatically restarts its services so it survives reboots and force-stops.

What the spyware can do

When active, operators can:

• Harvest call logs, SMS, and contact lists.
• Track device geolocation.
• Stream microphone audio, capture camera video, and take screen snapshots.
• Access stored images and execute arbitrary shell commands.
• Use the Accessibility API to block removal attempts by overlaying fake system dialogs or disabling uninstall options.

The malware’s configuration is flexible: it can use up to fifteen hosting providers and shifts between active C2 servers to resist takedowns. Domain registrar actions have disabled some infrastructure, but the campaign remains resilient.

Detection & mitigation

Dr.Web’s Android product detects and removes known variants of this backdoor. However, because the attacks are customized and highly targeted, organizations—especially those with high-value personnel—should exercise extra caution:

• Avoid installing APKs from untrusted sources or links received over private messaging.
• Disable sideloading on corporate devices where possible.
• Turn off Accessibility permissions for apps that do not explicitly need them.
• Monitor for unusual permission requests, rapid background services, or repeated C2 connections.
• Use reputable mobile-security solutions and keep threat intelligence feeds updated.